Hacker News 2026.03.28 27

텍스트 레이아웃의 미래는 CSS가 아닐 수도 있다 — Pretext 프로젝트가 던지는 질문

우리가 당연하게 여긴 것에 대한 도전

웹 개발을 하면서 텍스트 레이아웃은 당연히 CSS의 영역이라고 생각해 왔잖아요. font-size, line-height, text-align 같은 속성을 쓰면 브라우저가 알아서 글자를 배치해 주니까요. 그런데 Cheng Lou라는 개발자가 흥미로운 주장을 들고 나왔어요. "텍스트 레이아웃의 미래는 CSS가 아니다"라는 거예요. Pretext라는 프로젝트의 "에디토리얼 엔진" 편에서 이 이야기를 풀어내고 있는데요.

이게 갑자기 튀어나온 이야기가 아니에요. 사실 CSS로 텍스트를 다루다 보면 한계에 부딪히는 순간이 꽤 있거든요. 특히 출판 품질의 타이포그래피, 복잡한 다국어 레이아웃, 정교한 텍스트 에디터 같은 걸 만들려고 하면 CSS만으로는 부족하다는 걸 느끼게 돼요.

CSS 텍스트 레이아웃의 근본적 한계

우리가 쓰는 CSS 텍스트 레이아웃의 원리를 간단히 설명하면요. 브라우저가 텍스트를 받으면, 내부적으로 각 글자의 크기를 계산하고, 줄바꿈 위치를 정하고, 줄 간격을 조정해서 화면에 그려줘요. 이 과정을 텍스트 셰이핑(text shaping)과 레이아웃(layout)이라고 하는데요.

문제는 이 과정이 브라우저의 "블랙박스" 안에서 일어난다는 거예요. 개발자가 제어할 수 있는 건 CSS 속성을 통해 힌트를 주는 정도지, 실제로 글자가 어디에 어떻게 배치되는지를 픽셀 단위로 제어하기는 매우 어려워요.

예를 들어볼게요. 전문 출판물에서는 저스티피케이션(양쪽 맞춤)을 할 때 단순히 단어 사이 간격만 늘리는 게 아니라, 글자 간격(tracking)도 미세하게 조정하고, 하이프네이션(단어 분리) 규칙도 언어별로 다르게 적용해요. CSS의 text-align: justify는 이런 정교함과는 거리가 멀죠. 게다가 한글 같은 경우는 영어와 줄바꿈 규칙이 완전히 다른데, CSS 스펙이 이를 제대로 커버하는 데 오랜 시간이 걸렸어요.

또 하나 큰 문제는 텍스트 에디터 같은 인터랙티브한 경우예요. 구글 독스, 노션, 피그마 같은 도구들을 생각해 보세요. 이런 앱들은 텍스트의 커서 위치, 선택 영역, 줄바꿈 위치를 정확히 알아야 하는데요. 브라우저의 contentEditable에 의존하면 크로스 브라우저 호환성 문제도 있고, 커스터마이징의 한계도 심해요. 그래서 많은 팀이 결국 브라우저의 텍스트 레이아웃을 우회하고 자체 레이아웃 엔진을 만들게 되는 거예요.

Pretext가 제안하는 방향

Pretext 프로젝트는 이런 문제의식에서 출발해요. 핵심 아이디어는 텍스트 레이아웃을 브라우저(CSS)에 맡기는 대신, 애플리케이션 레벨에서 직접 제어할 수 있는 엔진을 만들자는 거예요.

이게 뭔 소리냐면요. 지금까지는 "텍스트를 화면에 예쁘게 보여주는 일"을 브라우저에게 위임했잖아요. Pretext는 그 일을 개발자가 직접 할 수 있는 도구를 제공하겠다는 거예요. 마치 게임 엔진이 그래픽 렌더링을 직접 제어하듯, 텍스트 레이아웃도 개발자가 직접 제어할 수 있어야 한다는 관점이에요.

이 "에디토리얼 엔진"이라는 개념은 특히 리치 텍스트 에디터 영역에서 의미가 있어요. 기존에는 에디터를 만들 때 브라우저의 DOM과 CSS에 의존해서 텍스트를 렌더링했는데요. 이 접근의 문제는 브라우저마다 렌더링 결과가 다를 수 있고, 복잡한 레이아웃(다단 편집, 인라인 수식, 복잡한 테이블 안의 텍스트 등)에서 예측 불가능한 동작이 발생한다는 거예요.

비슷한 움직임들

사실 이런 방향의 시도는 Pretext만 하고 있는 게 아니에요. 텍스트 레이아웃을 CSS 밖에서 해결하려는 움직임은 이미 여러 곳에서 진행 중이거든요.

피그마(Figma)가 대표적인 사례예요. 피그마는 WebGL(이제는 WebGPU도)을 사용해서 자체 렌더링 엔진으로 텍스트를 그려요. CSS를 쓰지 않아요. 그래서 OS나 브라우저에 상관없이 모든 사용자에게 동일한 텍스트 렌더링 결과를 보여줄 수 있는 거예요. 구글 독스도 2021년부터 canvas 기반 렌더링으로 전환했어요. DOM 기반이 아니라 직접 캔버스에 텍스트를 그리는 방식이죠.

오픈소스 쪽에서는 Typst라는 프로젝트가 있어요. LaTeX의 대안을 목표로 하는 조판 시스템인데, 자체 텍스트 레이아웃 엔진을 가지고 있어서 학술 논문이나 기술 문서의 고품질 타이포그래피를 지원해요. cosmic-text 같은 Rust 기반 텍스트 레이아웃 라이브러리도 주목할 만해요. 이 라이브러리는 크로스 플랫폼 텍스트 셰이핑과 레이아웃을 제공하는데, 브라우저에 의존하지 않아요.

이런 흐름을 보면 하나의 큰 방향이 보여요. "범용 브라우저의 텍스트 레이아웃이 모든 요구를 충족시킬 수는 없다"는 인식이 퍼지고 있고, 필요에 따라 전문화된 텍스트 엔진을 선택하는 시대가 오고 있다는 거예요.

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

한국어 텍스트 처리는 사실 영어보다 훨씬 까다로운 면이 있어요. 한글은 조합형 문자인 데다가, 한글-영문-숫자가 섞인 텍스트에서 줄바꿈 규칙이 복잡하고, CJK(중국어·일본어·한국어) 문자의 타이포그래피 규칙은 서양 텍스트와 상당히 달라요. CSS 스펙에서 word-break: keep-all 같은 속성이 제대로 작동하기까지 꽤 오래 걸렸던 걸 기억하는 분도 계실 거예요.

만약 여러분이 리치 텍스트 에디터, 문서 도구, 또는 정교한 타이포그래피가 필요한 제품을 만들고 있다면 이 흐름을 주의 깊게 볼 필요가 있어요. 당장 Pretext를 도입하라는 이야기는 아니지만, "텍스트 레이아웃 = CSS"라는 등식에 의문을 품어보는 건 가치가 있어요.

특히 노션 같은 에디터, 한글 문서 편집기, 웹 기반 이북 리더 같은 프로덕트를 만드는 팀이라면, 브라우저 렌더링의 한계를 이미 체감하고 있을 가능성이 높아요. 이런 맥락에서 canvas 기반 렌더링이나 자체 레이아웃 엔진에 대한 이해가 점점 중요해지고 있다는 점은 분명해 보여요.