애플이 30년 묵은 폰트 렌더링 코드를 Swift로 다시 쓴 이유

화면에 보이는 이 글자들이 어떻게 그려지는지 생각해보신 적 있나요? 애플이 공식 Swift 블로그의 'Swift at Apple' 시리즈를 통해, 맥과 아이폰에서 수십 년간 글자를 그려온 핵심 코드인 TrueType 힌팅 인터프리터를 C에서 Swift로 옮긴 이야기를 공개했어요. 앱 개발 언어로만 알려져 있던 Swift가 OS의 가장 깊숙한 곳, 그것도 성능에 극도로 민감한 폰트 렌더링 파이프라인까지 들어갔다는 점에서 의미가 큰 소식이거든요.

힌팅이 뭐냐면요

폰트 파일 안의 글자는 픽셀이 아니라 수학적인 외곽선(벡터)으로 저장돼 있어요. 이걸 화면에 그리려면 픽셀 격자에 맞춰 채워 넣어야 하는데, 글자가 작아질수록 문제가 생겨요. 획이 픽셀 사이에 어중간하게 걸치면 어떤 획은 두껍게, 어떤 획은 흐릿하게 나와서 글자가 지저분해 보이거든요.

그래서 나온 게 힌팅(hinting)이에요. 작은 크기에서도 글자가 또렷하게 보이도록 외곽선을 픽셀 격자에 맞춰 살짝살짝 변형해주는 기술인데요. 재미있는 건 TrueType의 힌팅이 단순한 설정값이 아니라 '프로그램'이라는 거예요. 폰트 파일 안에 바이트코드 명령어가 들어 있고, OS에 내장된 작은 가상머신, 즉 인터프리터가 이 명령어를 한 줄씩 실행하면서 글자 모양을 다듬어요. 폰트 하나하나가 사실은 실행 가능한 코드를 품고 있는 셈이죠. 이 구조는 1980년대 말 애플이 TrueType을 만들 때 설계된 것이고, 그 인터프리터는 오랫동안 C로 작성된 채 유지돼 왔어요.

왜 굳이 옮겼을까: 폰트는 '외부 입력'이거든요

여기서 보안 이야기가 나와요. 폰트는 웹페이지, 문서, 메신저를 통해 외부에서 들어오는 데이터예요. 그런데 그 안에 든 바이트코드를 OS가 실행한다? 공격자 입장에서는 너무 매력적인 표적이죠. 실제로 폰트와 이미지 파서는 OS를 노리는 제로클릭 공격에서 단골로 등장해온 영역이에요. C는 배열 경계를 벗어나는 접근을 막아주지 않기 때문에, 악의적으로 조작된 폰트가 인터프리터의 버그를 찔러 메모리를 침범하면 곧바로 심각한 보안 취약점이 되거든요.

Swift는 이 지점에서 태생적으로 달라요. 배열 접근에 경계 검사가 기본으로 들어가고, 정수 오버플로도 기본적으로 잡아주고, 널 포인터 문제는 옵셔널 타입으로 컴파일 단계에서 걸러져요. 같은 로직이라도 언어를 바꾸는 것만으로 메모리 안전성 버그라는 취약점 한 종류 전체가 구조적으로 사라지는 거예요.

성능은 어떻게 지켰을까

'안전 검사를 넣으면 느려지는 거 아니야?'라는 의문이 당연히 들 텐데요, 이게 바로 이런 마이그레이션의 핵심 난제예요. 힌팅 인터프리터는 글자를 그릴 때마다 도는 핫패스(가장 자주 실행되는 경로)라서, 조금만 느려져도 시스템 전체의 체감 성능에 영향을 주거든요. 그래서 이런 작업은 보통 기존 C 코드와 새 Swift 코드를 나란히 두고 렌더링 결과가 동일한지 비교 검증하면서, 컴파일러가 불필요한 경계 검사를 최적화로 제거할 수 있도록 코드를 다듬는 식으로 진행돼요. 한꺼번에 갈아엎는 빅뱅 방식이 아니라, Swift의 C 상호운용성을 활용해 모듈 단위로 점진적으로 교체하는 거죠. 애플은 앞서 수십억 건의 요청을 처리하는 비밀번호 모니터링 서비스를 C++에서 Swift로 옮긴 사례도 공개했었는데, 이번 건은 그보다 훨씬 저수준 영역이라는 점에서 한 발 더 나아간 셈이에요.

업계 전체가 같은 방향으로 가고 있어요

이 소식을 애플만의 이야기로 보면 절반만 보는 거예요. 지금 업계 전체가 '메모리 안전 언어로의 이주'를 진행 중이거든요. 구글은 안드로이드의 새 네이티브 코드에 Rust를 적극 도입해서 메모리 취약점 비율을 크게 떨어뜨렸다고 공개했고, 크롬 브라우저는 폰트 처리에 Rust 기반 라이브러리를 채택했어요. 미국 정부 기관들까지 나서서 C/C++ 대신 메모리 안전 언어를 쓰라고 권고하는 상황이고요. 애플은 그 답으로 Rust 대신 자사 언어인 Swift를 밀고 있는 거예요. 임베디드 기기나 펌웨어 수준까지 노리는 Embedded Swift 같은 기능이 계속 추가되는 것도 같은 맥락이에요.

우리에게 주는 시사점

한국 개발자 입장에서 챙겨갈 포인트는 두 가지예요. 첫째, Swift를 '아이폰 앱 언어'로만 보던 시각은 이제 좁아요. 서버, 임베디드, 시스템 프로그래밍까지 영역을 넓히고 있어서, 성능과 안전을 동시에 챙겨야 하는 곳이라면 충분히 선택지가 될 수 있어요. 둘째, 레거시를 옮기는 방법론이에요. 수십 년 된 C 코드를 '전부 새로 짜자'가 아니라, 상호운용 경계를 만들고 모듈 단위로 교체하면서 기존 출력과 결과를 비교해 검증하는 방식은, 언어가 무엇이든 오래된 시스템을 안고 사는 모든 팀에 통하는 전략이거든요.

한 줄로 정리하면, '글자 하나 그리는 코드까지 메모리 안전 언어로 바꾸는 시대가 왔다'예요. 여러분 팀에도 손대기 무서운 오래된 C/C++ 코드가 있나요? 다시 쓴다면 Rust와 Swift, 혹은 다른 무엇을 고르실 건가요?