이모지 하나 넣었는데, 글자수가 왜 늘어날까?

위의 같은 문자열, 네 가지 숫자에서 ‘완성형 가’와 ‘분리된 자모’를 번갈아 눌러 보세요. 둘 다 한 묶음으로 보일 수 있지만, 코드 포인트와 바이트 수는 같지 않습니다. 입력을 바꾸어도 원문을 정규화하거나 서버로 보내는 기능은 없습니다.

소개 문장을 다 쓰고 마지막에 웃는 얼굴을 하나 붙였습니다. 분명 한 칸처럼 보이는데, 글자수 표시가 두 칸 늘어납니다. 다른 입력창에 붙여 넣으면 숫자가 또 달라집니다.

이럴 때는 먼저 무엇을 한 글자로 세고 있는지를 봐야 합니다. 사람이 보는 모양과 프로그램이 저장하는 단위가 항상 같지는 않습니다.

같은 조건에서 직접 비교했습니다

아래 표는 각 문자열을 그대로 사용한 재현 결과입니다. 눈에 보이는 묶음은 Intl.Segmenter의 grapheme 기준, 저장 크기는 UTF-8 인코딩 기준입니다.

가족 이모지는 여러 사람 모양과 연결 문자가 모인 문자열입니다. 한 그림처럼 표시되어도 내부 단위는 여럿일 수 있습니다. 기기와 폰트가 조합을 어떻게 지원하느냐에 따라 보이는 모양도 달라질 수 있습니다.

여기서 ‘가’는 완성형 음절 하나를 사용했습니다. 겉모양이 비슷해도 자모가 분리된 문자열이라면 결과가 달라질 수 있으므로, 표의 값을 모든 한글 표현에 그대로 적용하지는 마세요.

그래서 어느 숫자가 맞는 걸까?

질문을 바꾸면 이해하기 쉽습니다. ‘세는 대상이 무엇인가?’라고 묻는 겁니다.

• 보이는 묶음: 사용자가 한 글자처럼 인식하는 단위에 가깝게 나눕니다.
• 코드 포인트: 문자열을 이루는 유니코드 값 단위로 셉니다.
• UTF-16 단위: JavaScript의 문자열 length가 세는 기준입니다.
• UTF-8 바이트: 해당 인코딩으로 바꿨을 때 데이터가 차지하는 크기입니다.

MDN은 String.length를 UTF-16 코드 단위의 길이라고 설명합니다. 반면 Intl.Segmenter에서는 grapheme 단위 분할을 선택할 수 있습니다. 하나는 틀리고 다른 하나가 맞는 관계가 아니라, 사용 목적이 다른 값입니다.

글자수 제한이 있는 곳에 붙여 넣을 때

자기소개서, 프로필, 게시물 입력창이 모두 같은 규칙을 쓴다고 가정하지 않는 것이 좋습니다. 해당 입력창이 공백을 포함하는지, 바이트 제한인지, 자체 계산 규칙이 있는지를 먼저 확인하세요.

실제로 제출할 문장을 최종 입력창에 붙여 넣고, 그곳의 카운터와 경고를 확인하는 과정이 필요합니다. 초안을 작성한 도구의 숫자가 같더라도 제출 시스템의 규칙을 대신 보장하지는 않습니다.

숫자가 예상과 다를 때는 이모지나 줄바꿈처럼 차이가 날 수 있는 부분을 하나씩 빼 보세요. 어떤 문자를 뺐을 때 숫자가 얼마나 줄어드는지 보면 해당 입력창의 기준을 추정하는 데 도움이 됩니다. 다만 중요한 제출물을 임의로 바꾸기 전에는 원문을 별도로 보관하세요.

피피의 글자수 도구는 무엇을 셀까?

현재 글자수 카운터의 기본 글자수는 코드 포인트 기준입니다. 따라서 이 글의 가족 이모지는 7글자, UTF-8 항목에서는 25바이트로 계산됩니다. 눈에 보이는 하나의 그림을 하나로 세는 grapheme 카운터와는 다릅니다.

위 표의 문자열을 하나씩 붙여 넣어 보세요. 중요한 것은 가장 작은 숫자를 보여 주는 도구를 찾는 게 아니라, 내가 제출할 곳과 같은 단위를 확인하는 것입니다.