'🍄'.length === 2? 자바스크립트에서 이모지 문자열 길이의 함정과 해결법

글자 수 제한을 거는 코드는 세상에서 제일 단순한 코드라고 생각했습니다. str.length와 숫자 하나면 끝나는 일이니까요. 프론트에서 검사하고, 서버에서 한 번 더 검사하고, DB 컬럼 크기만 맞춰두면 되는 줄 알았습니다.

그러다 이모지 하나가 들어옵니다.

"이모지 하나를 넣었는데 길이가 2로 계산돼?" '🍄'.length // 2

버그처럼 보이지만 버그가 아닙니다. 자바스크립트의 문자열 모델이 유니코드와 맞물리는 지점에서 생기는, 아주 흔하지만 헷갈리는 문제입니다.

자바스크립트는 글자가 아니라 조각을 센다

자바스크립트 문자열은 UTF-16 코드 유닛 단위로 저장됩니다. 즉, String.prototype.length는 실제 "보이는 글자 수"가 아니라 "16비트 조각 개수"를 반환하는 거죠.

"🍄" (U+1F344)은 BMP(기본 다국어 평면) 밖의 문자라 16비트 두 조각(서로게이트 페어)으로 표현됩니다. BMP는 U+0000부터 U+FFFF까지의 범위인데, 이 안에 드는 문자는 코드 유닛 하나로 표현되지만 그 밖의 문자는 두 개의 코드 유닛, 즉 서로게이트 페어로 표현해야 하니까요. 이모지 대부분이 이 범위 밖에 있어서 .length가 2가 되는 겁니다.

"🍄".length; // 2
"🍄".charCodeAt(0).toString(16); // "d83c"
"🍄".charCodeAt(1).toString(16); // "df44"
"🍄".codePointAt(0).toString(16); // "1f344"

결국 '🍄'은 코드 유닛 2개로 구성되니까 .length === 2가 되는 겁니다.

"길이"는 무엇을 세느냐에 따라 달라진다

자바스크립트에서 문자열의 "길이"는 생각보다 여러 층위로 나뉩니다. 같은 🍄 문자라도 무엇을 기준으로 세느냐에 따라 결과가 달라집니다.

먼저 바이트 수 기준으로 보면, 🍄은 UTF-8에서 4바이트를 차지합니다. 이건 저장 공간이나 네트워크 전송 시 용량을 계산할 때의 관점이죠.

코드 유닛 수 기준으로 보면 2입니다. UTF-16의 16비트 단위 조각을 세는 것이고, 자바스크립트의 String.prototype.length가 바로 이 값을 반환합니다.

코드 포인트 수 기준에서는 1이 됩니다. 유니코드에서 🍄은 하나의 고유한 코드 포인트(U+1F344)로 식별되니까요.

마지막으로 그래핌 수, 즉 화면에서 사용자가 인식하는 "보이는 글자 수"로 보면 역시 1입니다. 이게 우리가 일반적으로 "문자 하나"라고 느끼는 UX 기준의 단위죠.

정리하자면, 🍄 하나는 저장 시 4바이트, JS의 .length로는 2, 유니코드 문자 기준으로는 1, 그리고 시각적으로도 1글자입니다. 같은 문자 하나를 두고 네 개의 답이 나오는 셈입니다. "길이"는 기술적 관점에 따라 전혀 다르게 정의될 수 있습니다.

눈에 보이는 글자 수는 따로 세야 한다

요즘 이모지들은 스킨톤, 가족, 성별 조합 같은 ZWJ 시퀀스가 흔합니다. 눈에 보이는 글자 하나가 여러 코드 유닛 또는 여러 코드 포인트로 이루어질 수 있습니다.

그래서 "보이는 글자 수"를 세려면 아래 두 가지 방식 중 하나를 써야 합니다.

코드 포인트로 세면 대부분은 맞는다

[..."🍄👍🏽"].length; // 2

const sliceByCodePoints = (str, n) => Array.from(str).slice(0, n).join("");

ES2015 이상이면 어디서나 작동한다는 장점이 있지만, ZWJ 조합(👨‍👩‍👧‍👦)은 여러 글자로 잘릴 수 있다는 한계가 있습니다.

그래핌으로 세야 사용자와 눈높이가 맞는다

const countGraphemes = (str) => {
  const seg = new Intl.Segmenter("ko", { granularity: "grapheme" });
  return [...seg.segment(str)].length;
};

const sliceByGraphemes = (str, n) => {
  const seg = new Intl.Segmenter("ko", { granularity: "grapheme" });
  return [...seg.segment(str)]
    .slice(0, n)
    .map((s) => s.segment)
    .join("");
};

countGraphemes("👍🏽"); // 1

최신 브라우저와 Node(18+) 대부분에서 지원합니다. 미지원 환경에서는 grapheme-splitter 폴리필을 쓰면 됩니다.

프론트와 서버가 같은 자를 쓰게 만든다

// utils/charLength.ts
export type LengthMode = "grapheme" | "codePoint" | "codeUnit";

export function lengthOf(str: string, mode: LengthMode = "grapheme"): number {
  switch (mode) {
    case "codeUnit":
      return str.length;
    case "codePoint":
      return Array.from(str).length;
    case "grapheme": {
      const AnyIntl: any = Intl as any;
      if (AnyIntl?.Segmenter) {
        const seg = new AnyIntl.Segmenter("ko", { granularity: "grapheme" });
        return [...seg.segment(str)].length;
      }
      const { default: GraphemeSplitter } = require("grapheme-splitter");
      return new GraphemeSplitter().countGraphemes(str);
    }
  }
}

프론트와 서버가 같은 유틸을 쓰면 길이 계산 불일치 문제를 원천 차단할 수 있습니다.

DB는 또 다른 기준으로 센다

자바스크립트의 문자열 길이는 UTF-16 코드 유닛 수지만, MySQL은 문자열을 바이트(byte) 또는 문자(character) 기준으로 계산합니다.

이 차이를 혼동하면 특히 이모지·한글·특수문자 입력 시 제약 조건 오류나 데이터 잘림 같은 문제가 쉽게 발생합니다.

LENGTH()는 저장 용량을 센다

LENGTH()는 문자열이 실제로 저장소에서 차지하는 바이트 크기를 반환합니다. 즉, 같은 문자열이라도 인코딩에 따라 결과가 달라집니다.

MySQL이 utf8mb4를 쓸 때의 예시는 이렇습니다.

SELECT LENGTH('🍄');  -- 4
SELECT LENGTH('한');  -- 3
SELECT LENGTH('A');   -- 1

이모지는 4바이트, 한글은 3바이트, ASCII 문자는 1바이트를 차지합니다. LENGTH()는 컬럼 크기(VARCHAR(255) 등)를 계산하거나 저장 용량을 확인할 때는 유용한데, 사용자 입력 길이 제한처럼 "글자 수"가 중요한 로직에는 적합하지 않습니다.

CHAR_LENGTH()는 유니코드 문자를 센다

CHAR_LENGTH() (또는 CHARACTER_LENGTH())는 문자 개수, 그러니까 코드 포인트 수 기준으로 길이를 반환합니다.

SELECT CHAR_LENGTH('🍄');  -- 1
SELECT CHAR_LENGTH('한');  -- 1
SELECT CHAR_LENGTH('A');   -- 1

이 함수는 인코딩 방식(UTF-8, UTF-16, UTF-32)에 상관없이 "유니코드 문자 하나"를 1로 계산합니다. 따라서 닉네임, 댓글, 사용자 입력 필드처럼 UX 기준의 글자 수 검증에는 CHAR_LENGTH()를 쓰는 게 올바른 선택입니다.

그래핌 단위는 여전히 별개다

주의할 점은, 보이는 글자(그래핌)와 유니코드 문자(코드 포인트)가 항상 일치하진 않는다는 겁니다. 예를 들어 가족 이모지 👨‍👩‍👧‍👦 는 여러 코드 포인트를 ZWJ(Zero Width Joiner)로 연결한 조합이니까요.

SELECT CHAR_LENGTH('👨‍👩‍👧‍👦'); -- 7

눈으로는 "한 글자"지만, MySQL 입장에서는 7개의 문자로 계산됩니다. MySQL은 그래핌 단위를 이해하지 못하니까요.

결국 LENGTH()는 저장 용량(바이트) 기준이라 인코딩에 따라 값이 달라지고, CHAR_LENGTH()는 코드 포인트 기준으로 일반적인 "문자 수" 계산에 씁니다. 하지만 그래핌 기준의 보이는 글자 수는 DB에서 지원하지 않으니까 JS나 서버에서 계산해야 합니다.

그래서 저는 DB의 컬럼 제약(VARCHAR, TEXT)은 저장 용량 기준으로, 입력 검증은 "보이는 글자 수" 기준으로 나누어 설계하는 쪽이 맞다고 생각하게 됐습니다. 지금 만들고 있는 입력 폼이 있다면, 거기에 이모지 하나를 넣어보면 좋겠습니다. 어떤 자로 재고 있었는지가 바로 드러날지도 모릅니다.