유니코드와 문자 체계, 개발자라면 한 번은 제대로 알아야 할 이야기

우리가 매일 쓰는 글자, 컴퓨터는 어떻게 이해할까?

개발하다 보면 한 번쯤은 깨진 글자를 마주한 적 있을 거예요. 한글이 물음표로 바뀌어 나온다거나, 일본어가 네모 상자로 출력된다거나. 이런 문제의 뿌리를 파고 들어가면 결국 유니코드(Unicode)와 문자 체계(Writing Systems)라는 주제에 닿게 되는데요. Richard Ishida가 정리한 "An Introduction to Writing Systems and Unicode" 튜토리얼이 이 주제를 아주 체계적으로 풀어놓고 있어서, 오늘은 이 내용을 바탕으로 개발자가 꼭 알아야 할 핵심을 정리해볼게요.

사실 유니코드는 단순히 "글자에 번호를 붙인 것"이라고만 알고 있는 분이 많거든요. 그런데 실제로는 훨씬 복잡하고 정교한 시스템이에요. 세상에는 라틴 알파벳처럼 왼쪽에서 오른쪽으로 쓰는 문자만 있는 게 아니라, 아랍어처럼 오른쪽에서 왼쪽으로 쓰는 문자도 있고, 한국어처럼 자음과 모음을 조합해서 하나의 글자를 만드는 문자도 있잖아요. 유니코드는 이 모든 걸 하나의 표준으로 담아내려는 시도예요.

문자 체계의 종류, 생각보다 다양하다

이 튜토리얼에서 가장 흥미로운 부분 중 하나는 세계의 문자 체계를 유형별로 분류하는 거예요. 크게 나눠보면 이렇게 돼요.

먼저 알파벳(Alphabet) 방식이 있어요. 영어의 라틴 문자가 대표적인데, 자음과 모음이 각각 독립된 글자로 존재하는 방식이에요. a, b, c 같은 것들이요. 그다음 아부기다(Abugida)라는 방식이 있는데, 이게 뭐냐면 자음 글자에 모음을 표시하는 기호를 붙여서 쓰는 거예요. 인도의 데바나가리 문자가 대표적이죠. 자음이 기본형이고, 거기에 모음 마크를 더하는 식이에요.

그리고 아브자드(Abjad)라는 것도 있어요. 아랍어나 히브리어가 이 방식인데, 기본적으로 자음만 쓰고 모음은 생략하거나 선택적으로 표시하는 거예요. 한국어를 공부한 외국인 개발자들이 놀라는 게 바로 한국어의 한글인데, 한글은 자음과 모음을 조합해서 하나의 음절 블록을 만드는 독특한 구조를 가지고 있거든요. 이런 다양한 방식들이 유니코드 안에서 전부 표현되어야 하니까, 단순히 글자마다 번호를 매기는 것만으로는 부족한 거예요.

유니코드의 핵심 개념들

유니코드를 제대로 이해하려면 몇 가지 핵심 개념을 알아야 해요.

첫 번째는 코드 포인트(Code Point)예요. 이게 뭐냐면, 유니코드에서 각 문자에 부여한 고유 번호를 말해요. 예를 들어 한글 "가"는 U+AC00이라는 코드 포인트를 가지고 있어요. 현재 유니코드에는 약 15만 개 이상의 코드 포인트가 정의되어 있는데, 이론적으로는 약 110만 개까지 확장할 수 있게 설계되어 있어요.

두 번째는 인코딩(Encoding)이에요. 코드 포인트를 실제 컴퓨터 메모리에 어떻게 저장할지를 정하는 방식이죠. UTF-8, UTF-16, UTF-32 같은 게 바로 인코딩 방식이에요. UTF-8이 웹에서 가장 널리 쓰이는 이유는, 영어 같은 ASCII 문자는 1바이트만 쓰고, 한글이나 한자 같은 문자는 3바이트를 쓰는 식으로 가변 길이를 지원하기 때문이에요. 저장 공간을 효율적으로 쓸 수 있는 거죠.

세 번째로 정말 중요한 개념이 결합 문자(Combining Characters)예요. 예를 들어 "é"라는 글자가 있다고 해볼게요. 이걸 유니코드에서는 두 가지 방법으로 표현할 수 있어요. 하나는 "é"를 통째로 하나의 코드 포인트(U+00E9)로 쓰는 것이고, 다른 하나는 "e"(U+0065) 뒤에 악센트 결합 문자(U+0301)를 붙이는 거예요. 눈으로 보면 똑같은데 내부 표현이 다른 거죠. 이게 왜 중요하냐면, 문자열 비교할 때 이 차이를 모르면 "같은 글자인데 다르다"고 판단하는 버그가 생기거든요. 그래서 정규화(Normalization)라는 과정이 필요한 건데, NFC, NFD 같은 정규화 형식을 통해 같은 문자를 일관된 방식으로 통일시켜주는 거예요.

양방향 텍스트(Bidi)의 복잡함

웹 개발을 하다 보면 아랍어나 히브리어 지원 요청을 받을 수 있는데요, 여기서 양방향 텍스트(Bidirectional Text, 줄여서 Bidi) 문제가 등장해요. 아랍어는 오른쪽에서 왼쪽으로 읽는데, 그 안에 영어 단어나 숫자가 포함되면 그 부분만 왼쪽에서 오른쪽으로 써야 하거든요. 이게 한 문장 안에서 방향이 왔다 갔다 하는 거예요.

유니코드는 이걸 처리하기 위해 Bidi 알고리즘이라는 걸 정의해놓고 있어요. 각 문자에 방향성 속성을 부여하고, 텍스트를 렌더링할 때 어떤 순서로 배치할지를 자동으로 결정하는 거죠. HTML에서 dir="rtl" 속성을 쓰거나, CSS의 direction 속성을 쓰는 게 바로 이 맥락이에요. 그런데 자동 알고리즘만으로는 부족한 경우가 있어서, 유니코드에는 방향을 명시적으로 지정하는 제어 문자들도 포함되어 있어요.

한국 개발자에게 특히 중요한 이유

한국 개발자에게 이 주제가 특별히 중요한 이유가 몇 가지 있어요.

첫째, 한글 자체가 유니코드에서 꽤 특별한 위치를 차지하고 있어요. 한글은 자모를 조합해서 음절을 만드는 구조이기 때문에, 유니코드에서는 완성형 음절("가", "나" 등 11,172자)과 자모(ㄱ, ㄴ, ㅏ, ㅓ 등)를 모두 별도로 정의하고 있거든요. 검색 기능을 만들 때 초성 검색을 구현하려면 이 구조를 이해해야 해요.

둘째, 글로벌 서비스를 만들 때 유니코드 지식이 필수예요. 한국 기업들이 해외 시장에 진출하면서 다국어 지원은 더 이상 선택이 아닌 필수가 됐잖아요. 이때 문자 정규화를 안 하면 검색이 제대로 안 되고, Bidi 처리를 안 하면 아랍어권 사용자가 앱을 쓸 수 없게 되는 거죠.

셋째, 보안 측면에서도 중요해요. 유니코드에는 눈으로 보면 똑같은데 코드 포인트가 다른 문자들이 있어요. 예를 들어 라틴 문자 "a"와 키릴 문자 "а"는 화면에서 구분이 안 되거든요. 이런 걸 이용한 피싱 공격(호모그래프 공격이라고 해요)이 실제로 존재하기 때문에, URL이나 사용자 입력을 검증할 때 이런 부분을 고려해야 해요.

실무에서 바로 챙길 것들

당장 실무에 적용할 수 있는 팁을 몇 가지 정리하면, 데이터베이스 컬럼을 만들 때 utf8mb4 인코딩을 쓰는 게 좋아요. 일반 utf8은 이모지 같은 4바이트 문자를 저장 못 하거든요. 그리고 문자열 비교 전에는 정규화를 해주는 게 안전하고, 문자열 길이를 잴 때는 바이트 수가 아니라 코드 포인트 수(또는 grapheme cluster 수)를 기준으로 하는 게 맞아요. JavaScript에서 "가".length가 1이 나오지만, 이모지 "👨‍👩‍👧‍👦".length는 11이 나오는 것처럼, 눈에 보이는 글자 수와 내부 표현은 다를 수 있으니까요.

마무리

유니코드는 "전 세계의 모든 문자를 하나의 체계로 담겠다"는 거대한 프로젝트이고, 개발자라면 최소한 코드 포인트, 인코딩, 정규화 이 세 가지 개념은 확실히 이해해두는 게 좋아요. 특히 글로벌 서비스를 다루거나, 텍스트 처리를 하는 개발자에게는 필수 교양이라고 할 수 있죠.

여러분의 프로젝트에서 유니코드 관련해서 겪었던 황당한 버그가 있다면 공유해주세요. 한글 초성 검색, 이모지 처리, 인코딩 깨짐 등 경험담이 서로에게 큰 도움이 될 거예요!