터미널에서 한글·아랍어·데바나가리가 깨지는 이유, 그리고 OSC 66이라는 해결책

터미널에서 글자가 깨져 보인 적 있으세요?

개발하다 보면 터미널을 정말 많이 쓰잖아요. 그런데 영어가 아닌 다른 문자—한글, 아랍어, 힌디어(데바나가리 문자), 태국어 같은—를 터미널에서 표시하려고 하면 글자가 깨지거나 겹치거나 이상하게 보이는 경험을 해본 적 있을 거예요. 이런 문제가 왜 생기는지, 그리고 이걸 근본적으로 해결하려는 새로운 표준인 OSC 66에 대해 알아볼게요.

이 주제를 다룬 글의 저자는 Santhosh Thottingal이라는 분인데요, 인도의 말라얄람어 등 다국어 타이포그래피와 폰트 엔지니어링 분야에서 활동하는 개발자예요. 복잡한 스크립트(complex scripts)를 터미널에서 제대로 렌더링하는 문제를 깊이 있게 파고든 글이에요.

"복잡한 스크립트"가 뭔가요?

여기서 "스크립트"는 프로그래밍 스크립트가 아니라 문자 체계를 뜻해요. 영어 알파벳처럼 글자 하나하나가 독립적으로 나열되는 문자를 "단순 스크립트"라고 한다면, "복잡한 스크립트"는 글자들이 서로 결합하거나, 위치에 따라 형태가 바뀌거나, 쓰는 순서와 표시 순서가 다른 문자 체계를 말해요.

한글도 사실 여기에 해당해요. 'ㅎ', 'ㅏ', 'ㄴ'이 합쳐져서 '한'이 되잖아요. 아랍어는 오른쪽에서 왼쪽으로 쓰이면서 같은 글자도 단어 안에서의 위치에 따라 모양이 달라져요. 데바나가리(힌디어 등에 쓰이는 문자)는 자음과 모음이 결합할 때 위아래로 붙거나 형태가 변하고요.

이런 복잡한 규칙들을 제대로 처리하려면 셰이핑(shaping)이라는 과정이 필요해요. 셰이핑이 뭐냐면, 유니코드 코드 포인트(각 글자의 번호)를 실제 화면에 표시할 글리프(글자의 시각적 형태)로 변환하는 작업이에요. 이 과정에서 글자 결합, 위치 조정, 형태 변환 등이 일어나죠.

터미널은 왜 이걸 못 하나요?

문제의 핵심은 터미널의 설계가 1970~80년대 텔레타이프 시절에 만들어졌다는 거예요. 그 시절에는 ASCII 문자(영어 알파벳, 숫자, 기본 기호)만 있으면 됐거든요. 터미널은 기본적으로 고정폭 격자(grid)에 글자를 하나씩 배치하는 방식으로 동작해요. 한 칸에 한 글자, 모든 글자가 같은 너비.

그런데 복잡한 스크립트에서는 여러 유니코드 코드 포인트가 하나의 글리프를 만들기도 하고, 하나의 코드 포인트가 여러 칸을 차지하기도 해요. 터미널의 격자 모델로는 이걸 정확히 표현할 수 없는 거예요. 그래서 글자가 겹치거나, 커서 위치가 어긋나거나, 글자 사이에 이상한 빈 공간이 생기는 문제가 발생하죠.

웹 브라우저나 일반 텍스트 에디터에서는 HarfBuzz 같은 셰이핑 엔진이 이 작업을 해주는데, 전통적인 터미널 에뮬레이터들은 이런 엔진을 제대로 통합하지 않았어요.

OSC 66은 어떤 해결책인가요?

OSC는 "Operating System Command"의 약자인데요, 터미널에서 특별한 기능을 제어하기 위한 이스케이프 시퀀스의 일종이에요. OSC 66은 터미널 안에서 돌아가는 프로그램(TUI 앱 등)이 터미널에게 "이 텍스트는 복잡한 스크립트니까 제대로 셰이핑해서 그려줘"라고 알려줄 수 있는 프로토콜이에요.

기존에는 터미널이 각 셀에 어떤 문자가 들어가는지만 알았다면, OSC 66을 통해 "이 범위의 텍스트는 하나의 덩어리로 셰이핑해야 해"라는 힌트를 줄 수 있게 되는 거예요. 이렇게 하면 터미널이 HarfBuzz 같은 셰이핑 엔진을 사용해서 복잡한 스크립트를 올바르게 렌더링할 수 있죠.

이건 기존 터미널 프로토콜의 확장이기 때문에, OSC 66을 지원하지 않는 터미널에서는 그냥 무시되고 기존대로 동작해요. 하위 호환성을 깨뜨리지 않으면서 새로운 기능을 추가하는 거죠.

업계 맥락: 터미널의 현대화

사실 터미널의 현대화는 여러 방면에서 진행 중이에요. Kitty 터미널의 그래픽 프로토콜, Ghostty 같은 새로운 터미널 에뮬레이터, Sixel 그래픽 지원 등 터미널을 단순한 텍스트 출력 장치 이상으로 발전시키려는 노력이 계속되고 있어요. OSC 66도 이런 터미널 현대화 흐름의 일부로 볼 수 있어요.

WezTerm, Kitty 같은 현대적 터미널들이 이미 부분적으로 복잡한 스크립트 렌더링을 지원하고 있고, OSC 66 같은 표준이 자리 잡으면 이런 지원이 더 일관되게 이루어질 수 있을 거예요.

한국 개발자에게 주는 시사점

한글도 복잡한 스크립트에 속하기 때문에 이 이슈는 우리에게도 직접적으로 관련 있어요. 터미널에서 한글 파일명이나 한글 로그 메시지가 가끔 이상하게 보이는 것도 비슷한 맥락의 문제예요. 한글은 그나마 상황이 나은 편이지만, 다국어를 지원하는 서비스를 개발하거나, 국제 팀과 협업하면서 다양한 언어의 텍스트를 다뤄야 하는 경우에는 이런 문제를 인지하고 있는 게 중요해요.

TUI(텍스트 기반 UI) 앱을 만드는 개발자라면 특히 관심을 가질 만한 주제예요. Go의 Bubble Tea, Python의 Rich/Textual, Rust의 Ratatui 같은 TUI 프레임워크를 사용할 때 다국어 텍스트 처리 문제를 겪을 수 있거든요.