유니코드 폰트 변환기가 한글에서 안 되는 이유

인스타그램 프로필이나 디스코드 닉네임에 "𝐁𝐨𝐥𝐝 텍스트"나 "𝓕𝓪𝓷𝓬𝔂 텍스트" 같은 걸 본 적 있을 겁니다. 복사해서 붙여넣기만 하면 진짜 볼드체나 필기체처럼 보이죠. 폰트를 따로 설치할 필요도 없고, 어떤 앱이든 상관없이 그대로 붙여넣기만 하면 스타일이 그대로 유지됩니다. 인스타그램 소개글, 디스코드 닉네임, 트위터 프로필 어디에 붙여도 똑같이 보입니다.

그런데 같은 방식으로 한글을 "굵게" 바꾸려고 하면 대부분 안 됩니다. 검색해서 나오는 "한글 폰트 변환기"들도 막상 써보면 한글 부분만 원래 글자 그대로 나오거나, 아예 입력조차 받지 않는 경우가 많습니다. 왜 영어는 되고 한글은 안 될까요? 답은 폰트 파일이 아니라 유니코드 자체의 구조에 있습니다. 텍스트 스타일링 도구를 여러 언어로 직접 만들어 보면서 이 질문을 가장 먼저 파고들 수밖에 없었는데, 그 과정에서 정리한 내용을 공유합니다.

"가짜 볼드체"의 정체

먼저 이 트릭이 실제로 어떻게 동작하는지부터 짚고 넘어가겠습니다. "𝐁𝐨𝐥𝐝"처럼 보이는 텍스트는 폰트가 적용된 결과가 아닙니다. 진짜 알파벳 B, o, l, d가 아니라, 유니코드에 별도로 존재하는 "수학 영문자 기호(Mathematical Alphanumeric Symbols)"라는 블록 안의 전혀 다른 문자입니다.

유니코드는 원래 수학 논문에서 볼드체 변수(𝐱), 프락투어체(𝔉), 스크립트체(𝒜) 등을 문맥으로 구분해서 표기해야 할 필요 때문에, 스타일별로 A부터 Z, a부터 z, 0부터 9까지를 통째로 복제한 코드포인트 블록을 여러 개 추가했습니다. 즉 "B"라는 글자가 볼드체용, 이탤릭체용, 프락투어체용, 스크립트체용, 모노스페이스체용으로 전부 다른 코드포인트를 따로 가지고 있는 겁니다.

그래서 "폰트 변환기"라고 불리는 도구들이 실제로 하는 일은 폰트를 바꾸는 게 아니라, 입력한 일반 B를 저 수학 기호 블록에 있는 "볼드체처럼 생긴 B"로 통째로 치환하는 것뿐입니다. 렌더링 자체는 여러분의 기기에 이미 깔려 있는 시스템 폰트가 담당하고, 스타일이 다른 코드포인트를 그 폰트가 그럭저럭 흉내 내서 그려주는 것입니다. 폰트 설치가 필요 없는 이유, 어떤 사이트에 붙여넣어도 스타일이 유지되는 이유가 바로 여기에 있습니다.

그럼 한글은 왜 안 될까

문제는 이 수학 기호 블록이 애초에 라틴 알파벳(그리고 일부 그리스 문자, 숫자) 수십 자 정도만 다루도록 설계됐다는 점입니다. 라틴 알파벳은 26자뿐이라, 스타일 하나당 A-Z, a-z를 복제해도 코드포인트 몇백 개면 충분합니다.

한글은 상황이 완전히 다릅니다. 초성-중성-종성을 조합해서 만들 수 있는 완성형 한글 음절이 11,172자에 달합니다. 유니코드 치환 방식으로 "굵은 한글"을 지원하려면, 스타일 하나당 11,172개의 새 코드포인트를 통째로 추가해야 한다는 뜻입니다. 볼드체, 이탤릭체, 필기체 몇 가지 스타일만 지원해도 몇만 개의 코드포인트가 새로 필요해지는 셈입니다.

유니코드 컨소시엄이 이런 확장을 한글, 한자, 가나 같은 문자 체계에 적용한 적은 없습니다. 애초에 수학 표기용으로 만들어진 블록이라 굳이 확장할 이유도 없었습니다. 그래서 "한글도 지원한다"고 홍보하는 앱들도 실제로는 한글 입력 자체를 받지 않거나, 입력해도 아무 변화 없이 원래 글자 그대로 나오는 경우가 대부분입니다. 이건 개발이 덜 된 게 아니라, 애초에 이 방식 자체가 한글에는 적용될 수 없는 구조적인 한계입니다.

카오모지가 예외인 이유

반면 (づ ◡‿◡ )づ 같은 카오모지는 언어와 무관하게 어디서나 잘 작동합니다. 이유는 단순합니다. 카오모지는 애초에 "글자 스타일을 바꾸는" 게 아니라, 이미 존재하는 괄호-문장 부호-기호 문자를 조합해서 얼굴 모양을 만드는 것뿐이기 때문입니다. 새로운 코드포인트가 전혀 필요 없기 때문에, 한글이든 영어든 일본어든 아무 텍스트 옆에 붙여도 문제없이 똑같이 표시됩니다.

이 원리를 직접 확인해 보고 싶다면 https://glyphdrip.com/ko/kaomoji 에서 감정별-상황별로 정리된 카오모지를 검색해 보시면 됩니다. GlyphDrip 팀이 카오모지 800개 이상을 47개 카테고리로 직접 분류하면서 확인한 것도, 결국 이 조합형 구조 덕분에 언어와 무관하게 전부 정상 작동한다는 사실이었습니다.

그럼 한글을 "꾸미는" 방법은 아예 없을까

방법은 있습니다. 다만 텍스트가 아니라 이미지로 접근해야 합니다. 실제 폰트 파일을 불러와서, 브라우저의 캔버스(canvas)에 사용자가 입력한 글자를 그 폰트로 직접 렌더링한 다음 PNG로 내보내는 방식입니다. 복사-붙여넣기가 가능한 텍스트는 아니지만, 진짜 폰트로 한 글자씩 그려지기 때문에 스타일 제약이 사실상 없습니다. 한글이든 키릴 문자든 일본어든 상관없이 동일한 방식이 그대로 적용됩니다.

GlyphDrip 개발팀이 이 문제를 붙잡고 직접 검증해서 내놓은 결과물이 https://glyphdrip.com/ko/text-card-generator 의 "Real font" 모드입니다. 두꺼운 고딕체, 손글씨체 등 실제 한글 폰트 여러 개 중에서 골라, 입력한 텍스트를 그 자리에서 이미지로 만들어줍니다. 같은 방식으로 키릴 문자와 일본어 폰트까지 함께 지원하도록 만들었는데, 유니코드 치환으로는 애초에 불가능한 세 개 문자 체계를 하나의 도구에서 전부 커버하는 사례는 흔치 않습니다. 인스타그램 스토리 배경이나 유튜브 썸네일처럼 애초에 "이미지"가 필요한 자리에는, 사실 이 방식이 유일하게 통하는 답이기도 합니다.

실제 코드포인트로 확인해 보기

말로만 들으면 추상적이니, 실제 예시로 확인해 보겠습니다. 라틴 알파벳 "A"는 유니코드 안에 스타일별로 이렇게 여러 개의 서로 다른 코드포인트로 존재합니다.

• 볼드체: 𝐀 (U+1D400)

• 이탤릭체: 𝐴 (U+1D434)

• 볼드 이탤릭체: 𝑨 (U+1D468)

• 프락투어체: 𝔄 (U+1D504)

• 스크립트체: 𝒜 (U+1D49C)

• 모노스페이스체: 𝙰 (U+1D670)

• 원형: Ⓐ (U+24B6)

이 일곱 개가 전부 "같은 A"를 나타내지만, 유니코드 입장에서는 완전히 별개의 문자입니다. 화면에 보이는 모양만 다른 게 아니라, 코드 자체가 다릅니다. 라틴 알파벳은 26자뿐이라 이런 식으로 스타일마다 세트를 하나씩 복제해도 감당할 수 있는 규모였습니다. 그런데 이 방식을 한글의 11,172개 음절, 혹은 한자 수만 자에 그대로 적용한다고 생각해 보면, 스타일 하나 늘어날 때마다 코드포인트가 수만 개씩 늘어나는 셈이니 애초에 현실적인 접근이 아니었던 것입니다. 유니코드 자체 문서에서도 이 블록은 "compatibility" 목적, 즉 기존 수학 조판 문서를 그대로 옮기기 위한 용도로 설명되어 있고, 새로운 문자 체계를 위한 확장 통로로 설계된 적이 없습니다.

앱을 만든다면 왜 이 차이가 중요한가

이 구조적인 한계는 웹사이트뿐 아니라 모바일 앱을 설계할 때도 그대로 이어집니다. 라틴 문자 기반 "폰트 변환기" 앱들은 대부분 위에서 설명한 코드포인트 치환 로직만 구현하면 되기 때문에, 텍스트를 그대로 다른 앱에 붙여넣을 수 있는 가벼운 키보드 확장이나 유틸리티로 만들기 쉽습니다. 그런데 한글을 포함해 서비스를 넓히려는 순간, 같은 로직으로는 한글 부분에서 아무 일도 일어나지 않는 반쪽짜리 기능이 되어버립니다.

그래서 한글까지 제대로 지원하려면 접근 방식 자체를 바꿔야 합니다. 텍스트를 코드포인트로 치환하는 대신, 실제 폰트 파일을 불러와 캔버스에 렌더링하고 이미지로 내보내는 방식으로요. 텍스트가 아니라 이미지라는 제약은 있지만, 대신 폰트 종류에 사실상 제한이 없어지고 한글-키릴 문자-일본어처럼 유니코드 치환이 원천적으로 불가능한 문자 체계도 전부 동일한 방식으로 지원할 수 있게 됩니다. GlyphDrip이 웹에서 먼저 이 방식을 검증하고 있는 것도 같은 이유이고, 앞으로 앱 형태로 확장하더라도 결국 이 렌더링 방식이 기반이 될 수밖에 없습니다.

정리

• "가짜 볼드체" 트릭은 유니코드의 수학 기호 블록을 이용한 문자 치환일 뿐, 실제 폰트 렌더링이 아닙니다.

• 이 블록은 라틴 알파벳 기준 수십 자만 다루도록 설계되어 있어서, 음절 수가 11,172개에 달하는 한글에는 애초에 적용할 수 없습니다.

• 카오모지는 새 코드포인트가 필요 없는 조합형 기호라서 언어와 무관하게 작동합니다.

• 한글을 실제로 "꾸미려면" 텍스트 치환이 아니라, 진짜 폰트로 렌더링된 이미지를 만드는 방식이 필요합니다.

다음에 어떤 앱이나 사이트가 "한글도 지원하는 폰트 변환기"라고 홍보한다면, 실제로 한글을 입력해서 결과가 진짜로 바뀌는지 먼저 확인해 보시길 권합니다. 대부분은 라틴 문자에서만 작동하는 트릭을 재포장한 것일 가능성이 높습니다.