아티클
단어, 문자, 대소문자: 텍스트 계산이 실제로 작동하는 방식
텍스트를 세는 일은 컴퓨터가 절대 틀릴 리 없는 유일한 작업처럼 들리지만, 같은 문단을 두고 두 도구가 서로 다른 숫자를 태연히 내놓기도 하고, 이모지 하나 때문에 SMS 글자 수가 70자로 줄어들기도 하며, X의 "280자"도 보이는 것과 다른 의미를 갖는다. 글자 수 제한에 맞춰 글을 쓰거나, 변수 이름을 바꾸거나, 목업을 채우는 일상적인 작업 뒤에는 알아둘 만한 몇 가지 규칙이 있다. 이 글에서는 이 사이트의 작은 텍스트 도구들을 실제 예시로 삼아 그 규칙들을 하나씩 살펴본다.
무엇이 하나의 단어로 계산되는가
우리 도구를 포함한 대부분의 카운터는 타이피스트와 같은 방식으로 단어를 정의한다. 즉 공백이나 줄바꿈으로 구분된 눈에 보이는 문자의 연속이다. 이 한 가지 규칙만으로도 대부분의 불일치가 설명된다. 영어의 "state-of-the-art"는 한 단어인가 네 단어인가? 공백 기준으로 나누면 한 단어다. 숫자, URL, 이메일 주소도 각각 하나의 단어로 계산된다. 이 관례는 공백 없이 쓰는 언어에서는 통하지 않는다. 한국어는 어절 단위로 띄어쓰기를 하지만 중국어나 일본어처럼 단어 경계가 아예 없는 언어도 있어, 그런 언어에서는 "단어 수"라는 개념 자체가 의미가 없고 대신 문자 수를 기준으로 삼아야 한다. 읽는 데 걸리는 시간 추정에는 또 다른 관례가 하나 더 얹힌다. 우리 단어 카운터는 묵독하는 성인의 일반적인 평균치인 분당 200단어로 단어 수를 나누므로, 그 결과는 약속이 아니라 계획을 세우기 위한 참고치로 받아들여야 한다.
문자 하나가 항상 기호 하나는 아니다
문자 수 계산은 더 까다롭다. 유니코드 텍스트에는 여러 층위가 있기 때문이다. 사람이 하나의 문자(그래핌)로 인식하는 것이 실제로는 여러 코드 포인트로 이루어져 있을 수 있고, 각 코드 포인트는 자바스크립트의 length 속성이 세는 16비트 단위를 한 개 또는 두 개 차지한다. 활짝 웃는 얼굴 이모지는 그래핌으로는 하나지만 그 단위로는 두 개이므로, 단순한 카운터는 2라고 답한다. 여러 사람 이모지를 결합해 만든 가족 이모지는 그래핌으로 하나, 코드 포인트로 다섯, 단위로 여덟이다. 평범한 텍스트에도 같은 문제가 있다. "café"의 é는 코드 포인트 하나로 저장될 수도 있고, e에 결합용 악센트 부호가 붙은 형태로 저장될 수도 있는데, 화면에는 똑같이 보이지만 세는 방식은 다르다. 두 카운터가 서로 다른 결과를 내는 이유는 서로 다른 층위를 측정하기 때문이다. 코드 포인트를 사용자가 인식하는 문자 단위로 묶는 규칙은 유니코드의 텍스트 분할 규격(UAX #29)에 표준으로 정의되어 있으며, 제대로 만들어진 카운터는 이를 따른다.
실제로 셈이 걸려 있는 제한들
글자 수 제한에서는 계산이 곧 돈 문제가 된다. SMS는 압축된 GSM-7 알파벳으로 160자를 담을 수 있지만, 그 안에 없는 문자(이모지나 그 알파벳에 없는 글자) 하나만 들어가도 메시지 전체가 UCS-2로 전환되어 제한이 70자로 줄어든다. 긴 메시지는 153자 또는 67자 단위로 나뉘어 각각 따로 과금된다. X는 게시물 하나에 280자를 허용하지만 문자마다 가중치를 둔다. URL은 실제 길이와 상관없이 모두 23자로 계산되고, 대부분의 이모지와 한중일(CJK) 문자는 2자로 계산된다. 검색 스니펫에는 대신 느슨한 제한이 적용된다. 구글은 제목과 설명을 픽셀 너비 기준으로 잘라내므로, 흔히 알려진 제목 60자, 설명 155자라는 수치는 보장이 아니라 실무상의 관례일 뿐이다. 제한이 중요한 상황에서는 해당 플랫폼이 쓰는 것과 같은 규칙으로 세고 여유를 남겨두는 것이 좋다.
대소문자는 관례이며, 스타일마다 쓰이는 자리가 있다
대소문자를 바꾸는 일은 사소해 보이지만, 그 위에 쌓인 관례들을 만나면 이야기가 달라진다. 라틴 문자로 쓰인 텍스트, 즉 코드 식별자나 영어 제목에 관련된 구분이다. 미국식 헤드라인이 선호하는 Title Case(단어마다 첫 글자를 대문자로)와 대부분의 유럽 스타일 가이드가 선호하는 sentence case(문장 첫 글자만 대문자로)가 있다. 코드에는 그 나름의 계열이 있다. 자바스크립트와 자바의 변수명에는 camelCase, 클래스나 컴포넌트 이름에는 PascalCase, 파이썬과 데이터베이스에는 snake_case, 상수에는 SCREAMING_SNAKE_CASE, CSS 클래스명·파일명·URL 슬러그에는 kebab-case가 쓰이며, 소문자를 쓰면 대소문자만 다른 링크라는 흔한 함정을 피할 수 있다. 식별자 몇 개를 손으로 바꾸는 것은 괜찮지만, 여든 개짜리 목록을 손으로 바꾸다 보면 오타가 생기기 마련이다. 대소문자 변환기는 이 변환을 기계적으로 적용하며, 약어를 어떻게 처리할지, 기존 구분 기호를 어떻게 다룰지 같은 까다로운 부분까지 처리해 준다.
채움용 텍스트, 그리고 휴대폰이 열어주지 않는 파일
이 목록을 마무리하는 작업이 두 가지 더 있다. 레이아웃은 흔히 자리표시자 텍스트로 확인한다. 진짜 문장은 그 의미 쪽으로 시선을 끌어당기기 때문이다. lorem ipsum이 효과적인 이유는 거의 읽히는 것 같으면서도 실제로는 읽을 수 없는 라틴어이기 때문이다. 우리 생성기는 단락, 문장, 단어 단위로 텍스트를 만들어 내므로, 같은 문단 하나를 복사해서 반복하는 대신 목업을 현실적인 길이로 채울 수 있다. 그리고 누군가 보낸 .md, .json, .csv, .log 파일을 휴대폰이 열어주지 않을 때, 브라우저 기반 텍스트 뷰어는 편집기를 설치하거나 파일을 어딘가의 변환 사이트로 보내지 않고도 내용을 보여준다. 계산을 포함해 위에서 다룬 모든 작업은 전적으로 브라우저 안에서 실행된다. 텍스트는 절대 기기 밖으로 나가지 않는다. 측정하려는 대상이 초안이나 계약서, 내부 경로가 가득한 로그일 때는 이 점이 평소보다 더 중요하다.
이 아티클의 도구
자주 묻는 질문
한 페이지에는 몇 단어가 들어가는가?
출판 관례상 줄 간격 1로 된 한 페이지에는 약 500단어, 줄 간격 2로 된 페이지에는 약 250단어가 들어간다고 본다. 이는 A4나 레터 용지에 표준 12포인트 글꼴을 쓴다는 전제에서 나온 수치다. 실제 문서는 글꼴, 여백, 제목 스타일이 바뀔 때마다 이 수치에서 벗어난다. 그래서 과제나 제출물에서는 점점 페이지 수 대신 단어 수를 지정하는 경우가 많아지고 있다. 텍스트가 이미 있다면 추정치를 건너뛰고 직접 세는 것이 낫다. 페이지 수 관례는 텍스트가 아직 존재하지 않는 단계에서만 쓸모가 있다.
lorem ipsum은 실제로 무슨 뜻인가?
이것은 뒤죽박죽 라틴어이지 의미 없는 글자 나열이 아니다. 표준 문단은 기원전 45년의 철학서 De finibus bonorum et malorum(선악의 극한에 관하여)에서 잘라내어 뒤섞은 것이며, 그중 "dolorem ipsum"이라는 조각은 "고통 그 자체"라는 뜻이다. 이렇게 뒤섞는 것이 핵심이다. 단어 길이와 문장의 리듬이 그럴듯해 자연어처럼 보이지만 실제로 읽히지는 않도록 만들어, 보는 사람이 내용이 아니라 레이아웃을 판단하게 한다. 이것이 현대에 널리 퍼진 계기로는 보통 1960년대의 레트라셋 전사지와 1980년대의 데스크톱 출판 소프트웨어가 꼽힌다.
왜 플랫폼은 내 카운터보다 적은 글자 수를 세는가?
플랫폼마다 자체 가중치로 세기 때문이다. X는 280자를 기준으로 하지만 모든 URL을 23자로, 대부분의 이모지와 한중일(CJK) 문자를 각각 2자로 계산한다. SMS 게이트웨이는 160자짜리 GSM-7 알파벳에 없는 문자가 하나라도 필요해지는 순간 메시지 전체를 70자짜리 UCS-2 모드로 전환한다. 그리고 어떤 플랫폼이든 그래핌이 아니라 코드 단위를 세는 경우가 있어, 가족 이모지 하나가 제한 중 8자를 소비할 수도 있다. 버튼에 표시된 숫자가 자신의 카운터와 다르다면 플랫폼의 규칙이 우선한다. 여유를 두고 작성하거나, 보내기 전에 해당 플랫폼 자체의 카운터로 확인하는 것이 좋다.