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

프론트엔드에서 문자열 길이를 검사하다 보면 이런 경험이 있을 거예요.

"이모지 하나를 넣었는데 길이가 2로 계산돼?" '🍄'.length // 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);
    }
  }
}

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

MySQL에서 문자열 길이를 셀 때의 함정과 대처법

자바스크립트의 문자열 길이는 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)은 저장 용량 기준으로, 입력 검증은 "보이는 글자 수" 기준으로 나누어 설계하는 것이 UX 기준의 글자 수 제한을 정확히 적용하는 방법이에요.