폰트 하나로 QR코드를 그린다고? 트루타입에 숨어있던 '계산 능력'

폰트가 계산을 한다니, 그게 무슨 말이죠?

우리는 보통 폰트를 그냥 '글자 모양 모음'이라고 생각해요. 'ㄱ'을 누르면 ㄱ 모양이 나오고, 'A'를 누르면 A 모양이 나오는, 문자와 그림을 짝지어둔 표 정도로요. 그런데 짐 파리스(Jim Paris)라는 개발자가 만든 'TrueType QR Code Font'는 이 상식을 유쾌하게 깨버려요. 이 폰트를 적용한 상태에서 어떤 글자나 URL을 입력하면, 그 자리에 진짜 스캔 가능한 QR코드가 그려지거든요. 그림판도, 자바스크립트도, 별도 프로그램도 없이, 오직 폰트 하나로요.

처음 들으면 '에이, 그게 어떻게 가능해?' 싶을 거예요. 저도 그랬고요. 그런데 여기엔 대부분의 개발자가 잘 모르는, 폰트 기술의 숨겨진 능력이 숨어 있어요.

폰트는 사실 작은 프로그램이다

요즘 폰트 파일(OpenType/TrueType)에는 단순한 글자 그림만 들어있는 게 아니에요. 'GSUB(glyph substitution)'라고 불리는, 글자를 상황에 따라 다른 글자로 바꿔치는 규칙 엔진이 들어있거든요. 이게 뭐냐면, '이 글자 다음에 저 글자가 오면, 둘을 합쳐 이런 모양으로 바꿔라' 같은 규칙을 폰트가 스스로 실행하는 기능이에요.

제일 흔한 예가 코딩 폰트의 '합자(ligature)'예요. FiraCode 같은 폰트에서 = 다음에 >를 치면 두 글자가 예쁜 화살표(⇒) 하나로 합쳐지죠? 이게 바로 GSUB의 문맥 치환(contextual substitution)이에요. 앞뒤 글자를 살펴보고 조건에 맞으면 모양을 바꾸는 거죠. 원래는 아랍어처럼 앞뒤 글자에 따라 형태가 바뀌는 문자를 제대로 표현하려고 만든 정교한 기능인데, 발상을 뒤집으면 이걸로 '연산'을 시킬 수 있어요.

QR코드는 특히 어려운 도전이다

QR코드가 이 마술의 소재로 대단한 이유가 따로 있어요. QR코드는 단순히 글자를 점 패턴으로 바꾸기만 하면 되는 게 아니거든요. 일부가 손상돼도 읽히도록 '오류 정정 부호(Reed-Solomon)'라는 걸 계산해서 넣어야 해요. 이건 GF(256)라는 특수한 수 체계 위에서 다항식 나눗셈을 하는, 꽤 묵직한 수학 연산이에요.

그런데 이 폰트는 그 복잡한 계산을, 프로그래밍 언어가 아니라 폰트의 글자 치환 규칙들을 촘촘하게 엮어서 해내요. 글자를 입력하면 폰트 렌더링 엔진이 규칙을 하나씩 적용해가면서, 마치 도미노처럼 데이터를 인코딩하고 오류 정정 부호까지 만들어 최종 QR 패턴을 그려내는 거죠. 말하자면 폰트 엔진을 하나의 '작은 계산기'로 삼아 연산을 돌린 셈이에요. 이론적으로 이런 치환 규칙 시스템은 상당히 복잡한 계산까지 표현할 수 있다고 알려져 있는데, 이 프로젝트가 그걸 실물로 아주 극적으로 보여준 거예요.

업계 맥락에서 보면

이런 '폰트로 계산하기'는 사실 개발자들이 사랑하는 장르예요. 폰트로 미로를 그리거나, 특정 언어의 문법 하이라이팅을 흉내 내거나 하는 실험들이 종종 나왔거든요. 공통점은 '원래 그 용도가 아닌 시스템을 비틀어 예상 못 한 일을 시킨다'는 해커 정신이에요.

동시에 이건 살짝 진지한 교훈도 줘요. 폰트 렌더링 엔진이 이 정도로 복잡한 로직을 수행한다는 건, 그만큼 공격 표면(attack surface)이 넓다는 뜻이기도 하거든요. 실제로 과거에 폰트 처리 취약점으로 이미지·문서만 열어도 해킹당하는 사고들이 있었어요. '글자 그리는 코드가 뭐 얼마나 위험하겠어'라는 방심이 위험하다는 걸 이 프로젝트가 역설적으로 보여주는 셈이죠.

한국 개발자에게

이걸 실무에 바로 쓸 일은 솔직히 없어요. QR코드가 필요하면 라이브러리 한 줄 부르는 게 백배 낫죠. 하지만 얻어갈 게 분명히 있어요. 우선 '텍스트가 화면에 찍히기까지 폰트 엔진이 얼마나 많은 일을 하는지'를 알게 되면, 렌더링 성능 문제나 이모지·다국어 처리 버그를 만났을 때 원인을 훨씬 빨리 짚을 수 있어요.

그리고 더 큰 배움은 '제약 안에서의 창의력'이에요. 자바스크립트도 못 쓰고 오직 폰트 규칙만 허용되는 극한의 제약 속에서, 누군가는 QR코드 생성기를 만들어냈잖아요. 좋은 엔지니어링은 종종 이렇게 '주어진 도구의 한계를 끝까지 밀어붙이는' 데서 나오거든요.

한 줄 정리하면, 이 프로젝트는 '평범해 보이는 폰트 안에 얼마나 큰 계산 능력이 잠들어 있는가'를 QR코드라는 화끈한 결과물로 증명한 사례예요. 여러분은 지금까지 '설마 이런 것까지 될까' 싶은 도구로 뭔가를 억지로 해낸 경험, 있으신가요? 그런 장난 같은 실험이 의외로 실력을 키워주더라고요.