글자수 제한에 맞춰 줄이는 법: 날짜·조건·핵심 내용을 남기는 편집 순서

줄이기 전에 제한의 단위부터 적으세요

“40자 이내”와 “80바이트 이내”는 다른 조건입니다. 공백 포함 여부도 별개입니다. 제출 화면이 요구하는 단위, 최대값, 줄바꿈 허용 여부를 먼저 적어 두세요. 제한을 다 채워야 한다는 조건이 없다면 남는 칸을 억지로 채울 필요는 없습니다.

웹 입력창의 HTML maxlength는 UTF-16 코드 단위로 길이를 잽니다. 하지만 모든 서비스가 이 속성만 사용하는 것은 아닙니다. 자체 집계나 서버 검증을 할 수 있으므로, MDN에 설명된 브라우저 규칙을 모든 제출처의 규칙으로 일반화하면 안 됩니다.

Tooliv는 글자수를 UTF-16 코드 단위로, 바이트를 TextEncoder의 UTF-8 결과로 표시합니다. 아래 사례도 같은 연산으로 검산했습니다. 카운터끼리 값이 다를 때는 문장을 먼저 훼손하지 말고 공백·이모지·바이트의 집계 차이를 확인하세요.

먼저 보존할 정보와 확정 여부를 나누세요

다음은 길이를 줄이는 연습을 위해 만든 가상의 자료 발송 안내입니다. 실제 기관의 공지나 발송 약속이 아닙니다.

신청하신 자료는 검토를 마친 후 11월 6일 오후 3시까지 이메일로 보내드릴 예정입니다.

이 문장에서 보존할 정보는 자료를 보낸다는 행동, 검토 후 보낸다는 조건, 11월 6일 오후 3시라는 예정 기한, 이메일이라는 전달 수단입니다. 아직 예정된 일이라는 상태도 보존해야 합니다. 신청 경위나 예의 표현의 길이는 조정할 수 있지만, 날짜를 빼거나 “검토 완료”를 삭제하면 받는 사람이 이해하는 업무 상태가 달라집니다.

구분	이 예시에서 남길 내용	편집할 때 확인할 점
대상·행동	자료를 보냄	무엇을 누가 하는지 알 수 있는가
조건	검토 완료 후	발송 가능 조건이 사라지지 않았는가
기한	11월 6일 15시까지	날짜·시간·마감 의미가 유지되는가
전달 수단	이메일	사용자가 어디에서 확인할지 알 수 있는가
확정 여부	발송 예정	계획을 확정 약속으로 바꾸지 않았는가

지원서라면 이 구분을 그대로 복사하기보다 질문에 대한 결론, 본인의 역할, 행동, 확인 가능한 결과로 바꾸면 됩니다. 중요한 것은 문장의 모양보다 질문에 답하는 정보가 남았는지입니다. 근거를 삭제하고 성과 표현만 크게 만드는 방식은 길이를 줄여도 내용의 신뢰도를 낮춥니다.

49자를 38자, 36자로 줄인 결과 비교

다음 수치는 문장 앞뒤의 인용부호와 줄바꿈을 제외하고 계산했습니다. 표의 “글자수”는 공백 포함 UTF-16 코드 단위입니다.

단계	문장	글자수	UTF-8 바이트
원문	신청하신 자료는 검토를 마친 후 11월 6일 오후 3시까지 이메일로 보내드릴 예정입니다.	49	115
1차 편집	검토 후 11월 6일 오후 3시까지 이메일로 자료를 보낼 예정입니다.	38	86
2차 편집	검토 후 11월 6일 15시까지 이메일로 자료를 보낼 예정입니다.	36	80

가상의 제출 규격이 공백 포함 40자라면 1차 편집본이 들어갑니다. 최대 80바이트라면 1차 편집본은 넘고 2차 편집본은 들어갑니다. 이 결과는 UTF-8이라는 전제에서만 맞습니다. 제출처가 다른 문자 인코딩이나 자체 규칙을 쓰면 해당 화면의 판정을 다시 확인해야 합니다.

1차에서는 “신청하신”이라는 배경 표현을 덜고 “검토를 마친 후”를 “검토 후”로 줄였습니다. “예정”이라는 상태는 그대로 남겼습니다. 2차에서는 시간 표현을 24시간제로 줄였습니다. 실제 안내에서는 날짜의 연도나 시간대가 모호해질 수 있는 독자도 고려하세요. 해외 수신자에게 전달하는 문장이라면 시간대를 추가해야 하므로, 이 36자 예시를 그대로 최종 문구로 쓰기 어렵습니다.

더 짧게 쓰려고 “11월 6일 15시까지 이메일로 자료를 보낼 예정입니다.”로 바꾸면 31자·69바이트가 됩니다. 숫자는 더 작지만 검토 완료라는 조건은 사라집니다. 조건이 실제 업무에 필요하다면 이 버전은 채택하면 안 됩니다. 편집의 통과 기준에는 길이와 의미가 모두 들어가야 합니다.

덜 중요한 표현부터 순서대로 덜어내세요

한 번에 많은 내용을 지우면 어떤 사실이 빠졌는지 추적하기 어렵습니다. 먼저 같은 뜻이 반복되는 수식어를 지우고, 그다음 긴 동사 표현을 바꿉니다. 마지막으로 배경 설명을 별도 문장이나 연결된 안내로 옮길 수 있는지 판단하세요. 금액·기한·대상·예외처럼 사용자의 행동을 바꾸는 조건은 마지막까지 남겨 두는 편이 좋습니다.

“상기”, “관련 제반 사항”, “진행할 예정에 있습니다” 같은 표현이 꼭 필요한지도 살펴보세요. 다만 특정 계약이나 제출 양식의 정확한 용어를 쉬운 말로 바꿀 때는 원래 의미가 달라지지 않는지 별도 확인이 필요합니다. W3C의 웹 작성 안내 역시 문맥에 맞는 단순한 언어와 짧고 명확한 문장, 처음 등장하는 약어의 설명을 권합니다.

띄어쓰기를 전부 없애거나 익숙하지 않은 약어로 바꾸는 방법은 피하세요. 바이트는 줄어도 독자가 내용을 해석하는 부담이 커질 수 있습니다. 글자수 제한 때문에 핵심 조건을 넣을 수 없다면 설명란을 나누거나 상세 안내 링크를 쓸 수 있는지 제출 형식을 확인하는 편이 낫습니다. 추가 링크를 허용하지 않는 양식에서는 질문에 직접 답하는 내용을 우선해야 합니다.

글자 제한과 바이트 제한을 따로 검수하세요

UTF-8 기준으로 가나다는 3자·9바이트이고 abc는 3자·3바이트입니다. 따라서 “한 글자만 줄였다”는 사실로 몇 바이트가 감소했는지 알 수 없습니다. 한글을 영어로 바꾸면 항상 좋은 편집이 되는 것도 아닙니다. 독자에게 익숙한 말과 정확한 의미가 우선입니다.

줄바꿈도 주의하세요. 이 글의 검산에서 a b와 a 뒤 줄바꿈 후 b는 각각 공백 포함 3자·3바이트입니다. Tooliv의 공백 제외 집계는 줄바꿈과 탭도 제외합니다. 받는 곳이 일반 스페이스만 제외한다면 같은 숫자가 나오지 않을 수 있습니다. 표시된 “공백 제외”라는 이름만 보고 동일한 규칙이라고 판단하지 마세요.

문장 뒤에 담당자 이름, 링크, 괄호 설명을 추가했다면 다시 세어야 합니다. 번역·표기 통일·날짜 수정도 모두 최종 길이를 바꿀 수 있습니다. 처음 맞춘 초안이 아니라 실제로 제출할 마지막 문자열을 기준으로 확인합니다.

제출 전에는 길이와 내용 검사를 나눠 하세요

1. 질문이나 공지 목적에 답하는 결론이 남았는지 읽습니다.
2. 날짜·숫자·조건·예외와 계획·확정 여부를 원문과 한 항목씩 대조합니다.
3. 최종 문장을 Tooliv에 붙여 넣어 요구하는 집계값을 확인합니다.
4. 실제 제출 화면에 붙여 넣고 잘림·자동 줄바꿈·오류 메시지를 확인합니다.
5. 제출 직전의 문장과 원문을 함께 남겨 수정 근거를 보존합니다.

길이·표기·인코딩을 한 번에 점검해야 한다면 붙여넣기 전 텍스트 규격 확인 순서를 이어 읽으세요. 카운터는 길이 조건을 확인하는 도구이고, 읽는 사람이 올바르게 이해할지는 편집자가 최종 확인해야 합니다.