슬라브 룬 문자가 나치 상징으로 변했습니다 — 폰트 렌더링이 초래한 최악의 PR 사고
GOG의 뉴스레터 사례로 본 유니코드 렌더링의 함정과 글로벌 서비스가 폰트 검수를 간과했을 때 벌어지는 일
예전에 글로벌 프로젝트를 진행하며 겪은 일인데요. 제 모니터에서는 분명 예쁘게 나오던 특수 문자가 고객사 담당자의 폰에서는 완전히 깨져서 ‘이상한 기호’로 보였던 적이 있어요. 그때는 그냥 “아, 폰트가 없어서 깨졌구나” 하고 가볍게 넘겼죠. 그런데 만약 그 깨진 문자가 하필이면 전 세계적으로 금기시되는 정치적 상징으로 보였다면 어떨까요? 상상만 해도 아찔합니다.
실제로 GOG는 슬라브 신화 기반 게임을 홍보하려고 ‘태양’을 뜻하는 Sowilō 룬 문자를 썼는데, 이게 일부 기기에서 나치 SS 상징으로 렌더링되어 전 세계 사용자에게 발송되는 대참사가 벌어졌습니다 [1]. 단순한 폰트 렌더링 오류가 문화적 맥락과 결합했을 때, 기술적 실수가 기업의 정체성을 위협하는 치명적인 사회적 메시지로 돌변할 수 있다는 걸 보여준 아주 뼈아픈 사례예요.
사건의 재구성: ‘태양’이 ‘나치’가 되기까지
사건의 발단은 슬라브 신화와 문화를 배경으로 한 판타지 게임 ‘The End of the Sun’의 홍보였습니다. GOG는 뉴스레터를 보내면서 분위기를 살리기 위해 슬라브 룬 문자를 넣었는데요. 원래 의도는 ‘태양’을 의미하는 Sowilō 룬 문자를 사용해 긍정적인 에너지를 전달하는 것이었습니다 [1].
그런데 문제가 터졌습니다. 메일을 받은 사용자의 기기나 플랫폼, 특히 모바일 환경에 따라 이 문자가 나치 SS와 연관된 상징으로 렌더링되어 보인 거예요 [1]. ‘태양’을 보냈는데 ‘나치’가 도착한 셈이죠.
나중에 GOG가 밝힌 원인은 전형적인 ‘운 나쁜 실수들의 연속’이었습니다.
attributing the inclusion to a ‘series of mistakes,’ including miscommunication with the German QA team, inconsistent font rendering, and being understaffed during a bank holiday
(독일 QA 팀과의 소통 오류, 일관성 없는 폰트 렌더링, 그리고 공휴일 인력 부족 등 일련의 실수들이 겹쳐 발생한 일이라고 설명했습니다.) [1]
결국 내부 소통 부재와 기술적 검토 미비, 그리고 타이밍 좋게 겹친 공휴일 인력 공백이 합쳐져 최악의 PR 사고로 이어진 겁니다.
기술적 배경: 왜 폰트마다 다르게 보일까?
여기서 우리는 “왜 똑같은 문자를 보냈는데 다르게 보일까?”라는 의문을 가져야 합니다. 개발자라면 유니코드를 잘 알겠지만, 사실 유니코드는 ‘문자’ 그 자체가 아니라 그 문자에 부여된 ‘고유 번호(코드 포인트)’일 뿐이에요.
실제로 우리 눈에 보이는 모양, 즉 ‘글리프(Glyph)’는 폰트 파일 안에 정의된 매핑 테이블과 OS의 렌더링 엔진이 결정합니다 [3]. 즉, U+XXXX라는 번호를 줬을 때, 어떤 폰트는 이걸 ‘태양’ 모양으로 그리고, 어떤 폰트는 ‘번개’ 모양으로 그릴 수 있다는 거죠.
특히 복잡한 스크립트에서는 ‘텍스트 셰이핑(Text Shaping)’이라는 과정이 들어갑니다.
Shaping – A process of converting a unicode text to a list of glyphs with their positions.
(셰이핑이란 유니코드 텍스트를 위치 정보가 포함된 글리프 리스트로 변환하는 과정입니다.) [3]
이 과정에서 문맥에 따라 글자 모양이 바뀌는 ‘문맥적 치환(Contextual substitution)’이나 두 글자가 합쳐지는 ‘리가처(Ligature)’ 처리가 일어나는데, 이 로직이 폰트나 엔진마다 다르면 완전히 다른 결과물이 나옵니다 [3, 6].
이해를 돕기 위해 텍스트 셰이핑의 흐름을 간단히 정리하면 다음과 같습니다.
| 단계 | 처리 내용 | 결과물 | 비고 | | :— | :— | :— | :— | | 1. 유니코드 입력 | U+XXXX (코드 포인트) | 추상적인 문자열 | 의미만 정의됨 | | 2. 셰이핑 (Shaping) | 문맥 분석 $\rightarrow$ 글리프 ID 매핑 | 글리프 리스트 + 위치 정보 | HarfBuzz 등이 수행 [3] | | 3. 래스터라이징 | 폰트 파일의 외곽선 $\rightarrow$ 픽셀화 | 최종 화면 출력 | FreeType 등이 수행 [3] |
또한, 폰트를 서비스에 직접 심는 ‘임베디드 폰트’보다 OS가 제공하는 ‘시스템 폰트’를 쓸 때, OS의 렌더링 엔진(예: 윈도우의 GDI)이 더 정확하게 처리하는 경우가 많습니다 [4]. 하지만 이 역시 OS 버전마다 다르기 때문에 100% 신뢰할 수는 없죠.
안티패턴: ‘내 화면에선 잘 나오는데’의 위험성
현업에서 가장 위험한 말이 뭔지 아세요? 바로 “제 화면에선 잘 나오는데요?”입니다. 이번 GOG 사례가 딱 그랬을 거예요. 담당자 PC나 특정 브라우저에서는 예쁜 태양 모양이었겠죠. 하지만 글로벌 서비스에서 이런 접근은 정말 위험합니다.
우리가 흔히 저지르는 안티패턴들을 짚어볼게요.
- 단일 환경 검수: 특정 OS나 최신 브라우저에서만 확인하고 배포하는 습관입니다. 실제로 유니코드 15.0 이상의 최신 심볼들은 윈도우 11 최신 버전에서도 제대로 렌더링되지 않고 박스로 깨져 나오는 사례가 있습니다 [5].
- 폰트 폴백(Fallback) 전략 부재: 지정한 폰트가 없을 때 어떤 폰트로 대체될지, 그 대체 폰트가 특수 문자를 어떻게 표현할지 고민하지 않는 경우입니다.
- 유니코드에 대한 과신: “표준이니까 당연히 다 똑같이 보이겠지”라고 생각하는 거죠. 하지만 룬 문자 같은 특수 문자는 기기와 이메일 클라이언트에 따라 렌더링 결과가 천차만별입니다. 그래서 GOG 측에서도 나중에 “스크린샷만이 가장 확실한 확인 방법”이라고 인정했죠 [7].
- 문화적 금기(Taboo) 검증 누락: 기술적으로 깨지는 것과, 깨진 모양이 하필 ‘나치 상징’이 되는 것은 차원이 다른 문제입니다. 특히 독일처럼 역사적 민감도가 높은 시장을 대상으로 할 때는 더 엄격한 교차 검증이 필요했습니다.
글로벌 서비스의 텍스트 안전망 구축하기
그렇다면 우리는 어떻게 이런 사고를 막을 수 있을까요? 제가 추천하는 안전망은 다음과 같습니다.
가장 확실한 방법은 “시각적 의미가 중요한 상징은 텍스트로 쓰지 않는 것”입니다. 룬 문자처럼 모양 자체가 메시지인 경우에는 유니코드 문자가 아니라 SVG나 이미지 파일로 처리하세요. 그러면 어떤 기기에서든 동일한 모양을 보장할 수 있습니다.
만약 반드시 텍스트로 구현해야 한다면, HarfBuzz 같은 표준 텍스트 셰이핑 엔진을 도입해 OS나 브라우저가 텍스트를 어떻게 렌더링할지 미리 시뮬레이션하고 검증하는 과정이 필요합니다 [3]. 또한 Noto Sans처럼 광범위한 유니코드를 지원하는 표준 폰트를 사용해 렌더링 불일치를 최소화해야 합니다 [5].
프로세스 측면에서는 ‘렌더링 매트릭스’ 기반의 QA를 수행하세요. 주요 OS(iOS, Android, Windows, macOS)와 주요 브라우저/메일 클라이언트 조합에서 실제로 어떻게 보이는지 전수 조사를 하는 겁니다. 특히 민감한 문화권의 현지 QA 팀이 있다면, 텍스트 데이터가 아니라 실제 렌더링된 ‘최종 결과물 스크린샷’을 공유하고 컨펌받는 절차를 반드시 넣으세요.
짚고 넘어갈 한계와 안티패턴
여기서 “그냥 Noto Sans 같은 표준 폰트로 다 바꾸면 해결되는 거 아니냐”고 물으실 수 있어요. 이론적으로는 도움이 되지만, 모든 환경에서 폰트를 강제할 수는 없습니다 [5].
특히 이메일 뉴스레터의 경우, 렌더링 제어권이 개발자가 아니라 수신자의 이메일 클라이언트(Gmail, Outlook, 네이버 메일 등)에 있습니다 [7]. 우리가 아무리 폰트를 지정해도 클라이언트가 무시하고 시스템 기본 폰트로 렌더링해버리면 끝이에요. 결국 텍스트 기반의 전달 방식에는 태생적인 한계가 있다는 점을 인정해야 합니다.
핵심 요약
- 유니코드 코드 포인트가 같다고 해서 모든 기기에서 동일한 글리프로 보이지 않습니다.
- 특수 문자나 고대 문자는 렌더링 엔진과 폰트의 조합에 따라 완전히 다른 의미로 해석될 수 있습니다.
- 글로벌 서비스에서 ‘시각적 의미’가 중요한 텍스트는 반드시 이미지(SVG)로 처리하거나 엄격한 렌더링 테스트를 거쳐야 합니다.
- 기술적 오류(Rendering bug)가 사회적 맥락(Political symbol)과 만나는 지점이 가장 위험한 사고 지점입니다.
기술적으로는 ‘단순한 렌더링 버그’였을지 모르지만, 사용자에게는 ‘기업의 가치관’으로 읽혔을 이번 사건을 보며 많은 생각을 하게 됩니다. 엔지니어가 다루는 1비트의 데이터, 문자 하나가 현실 세계에서는 얼마나 무거운 무게를 가질 수 있는지 다시금 깨닫게 되네요.
References
1. [theverge.com] GOG apologizes for emailing people Nazi symbols — https://www.theverge.com/games/945088/gog-apologizes-email-nazi-symbols-the-end-of-the-sun 2. [discussions.unity.com] Unicode font rendering broken with Devanagari fonts? — https://discussions.unity.com/t/unicode-font-rendering-broken-with-devanagari-fonts/540953 3. [tchayen.com] Unicode Text Rendering in Zig with FreeType and HarfBuzz — https://tchayen.com/unicode-text-rendering-in-zig-with-freetype-and-harfbuzz 4. [github.com] Embedded Unicode fonts do not render correctly. — https://github.com/airsdk/Adobe-Runtime-Support/discussions/1143 5. [learn.microsoft.com] Some symbols from Unicode 15.0 and later are not rendered properly — https://learn.microsoft.com/en-us/answers/questions/5694863/some-symbols-from-unicode-15-0-and-later-are-not-r 6. [unicode.org] Chapter 5 – Unicode 16.0.0 — https://www.unicode.org/versions/Unicode16.0.0/core-spec/chapter-5 7. [gog.com] Weird subject line choice for a Newsletter, page 4 — https://www.gog.com/forum/general/weird_subject_line_choice_for_a_newsletter/page4
관련 글 추천
- https://infobuza.com/2026/06/07/20260607-w8k03b/
- https://infobuza.com/2026/06/06/20260606-hk8x9f/
FAQ
GOG 뉴스레터에서 발생한 PR 사고의 원인은 무엇인가요?
슬라브 룬 문자인 'Sowilō(태양)'를 사용했으나, 일부 기기나 모바일 환경에서 이 문자가 나치 SS 상징으로 렌더링되어 사용자들에게 발송되었기 때문입니다.
동일한 유니코드 문자가 기기마다 다르게 보이는 이유는 무엇인가요?
유니코드는 문자의 고유 번호(코드 포인트)일 뿐이며, 실제로 눈에 보이는 모양(글리프)은 폰트 파일의 매핑 테이블과 OS의 렌더링 엔진, 그리고 텍스트 셰이핑 과정에 따라 결정되기 때문입니다.
GOG가 밝힌 이번 사고의 내부적인 원인은 무엇인가요?
독일 QA 팀과의 소통 오류, 일관성 없는 폰트 렌더링, 그리고 공휴일로 인한 인력 부족 등 일련의 실수들이 겹쳐 발생했습니다.
시각적 의미가 중요한 상징을 안전하게 전달하는 가장 확실한 방법은 무엇인가요?
유니코드 텍스트로 작성하지 않고, SVG나 이미지 파일로 처리하여 어떤 기기에서든 동일한 모양이 보장되도록 하는 것입니다.
글로벌 서비스에서 텍스트 렌더링 사고를 막기 위한 QA 방법은 무엇인가요?
주요 OS와 브라우저/메일 클라이언트 조합의 '렌더링 매트릭스' 기반 전수 조사를 수행하고, 특히 민감한 문화권의 현지 QA 팀으로부터 실제 렌더링된 최종 결과물 스크린샷을 컨펌받는 절차가 필요합니다.
