내 일본어 유튜브는 존재하지 않는 페이지를 광고하고 있었다

유튜브 스튜디오에서 일본어 쇼츠를 하나 열었습니다. 영상 첫 프레임, 앱 화면 맨 위에 이렇게 적혀 있었습니다. "ページが見つかりません" — 페이지를 찾을 수 없습니다.

영상은 정상적으로 렌더돼 업로드됐고, 조회수도 붙고 있었습니다. 그런데 그 안에 박제된 화면은 404였습니다. 그리고 설명란의 링크는 당당하게 mbti.ootssu.com/ja를 가리키고 있었죠.

질문 하나 먼저 던지겠습니다. 당신의 자동화 파이프라인은, 자기가 만든 링크가 실제로 열리는지 확인합니까? 저는 아니라고 답할 수밖에 없었습니다.

링크를 눌러봤다

mbti.ootssu.com/ja는 500을 반환했습니다. /ko와 /en은 멀쩡했습니다. 앱을 열어보니 이유는 단순했습니다 — 이 앱은 ko와 en만 배포돼 있었습니다. LOCALES = ['ko', 'en']. 일본어판은 애초에 없었습니다.

그런데 일본어 쇼츠 채널은 존재하고, 매일 게시되고, 설명란마다 /ja를 링크하고 있었습니다. 화면 녹화는 한국어 앱을, 링크는 없는 일본어 페이지를 가리키는 — 앞뒤가 안 맞는 영상이 이미 시청자에게 나가고 있던 겁니다.

그럼 다른 앱은?

여기서 등골이 서늘해졌습니다. 저는 앱을 수십 개 굴립니다. 이 앱만 이럴 리가 없었죠. 그래서 매니페스트의 URL을 전부 뽑아 /ja를 하나씩 두드려봤습니다.

200  ja 정상 ............ 10개
500  서버 크래시 ......... 15개
404  깨끗한 없음 .......... 8개

33개 중 23개가 /ja에서 깨져 있었습니다. 그중 15개는 404도 아니고 500 — 에러 페이지를 뱉고 있었습니다. 일본어 영상이 그중 어느 것을 링크했든, 시청자는 서버 에러를 만났을 겁니다.

이걸 저는 로케일 부패(locale rot) 라고 부르기로 했습니다. 앱은 저마다 다른 로케일을 지원하는데(어떤 건 ko 전용, 어떤 건 ko/en, 몇 개만 ja까지), 콘텐츠 파이프라인은 "모든 앱은 4개 국어를 지원한다"고 가정하고 /ja 링크를 기계적으로 찍어내고 있었습니다. 앱과 파이프라인의 가정이 어긋난 채로, 아무도 안 보는 사이 조용히 쌓인 겁니다.

복구: 여기서 당신이라면 어떻게 하겠습니까

깨진 링크를 살리려면 그 앱의 일본어판이 필요했습니다. 이 앱은 136개 유형 조합 각각에 대해 궁합 콘텐츠(요약·연애·우정·직장·강점·마찰·팁)를 가진 SEO 사전입니다. 유형 페이지 16개까지 합치면 번역할 JSON이 152개.

여기서 갈림길입니다. 당신이라면 152개를 손으로 번역하겠습니까, 아니면 다른 길을 찾겠습니까?

저는 영어 콘텐츠를 열어보다 한 가지를 발견했습니다 — 영어판은 사람이 쓴 게 아니라 템플릿 생성물이었습니다. 문장 골격은 고정이고, 유형별 구절(그 유형의 인지 렌즈, 애정 표현 방식, 강점, 마찰 지점…)만 슬롯처럼 갈아끼워져 있었죠.

그래서 손번역 대신 이렇게 했습니다.

정규식으로 영어 136개 파일에서 유형별 구절을 역추출 → 유형당 9개 슬롯 사전.
슬롯이 겹치는 파일끼리 값을 대조해 0건 불일치 확인(추출이 정확하다는 증거).
슬롯 144개(16유형 × 9)만 일본어로 번역.
단일 일본어 템플릿에 슬롯을 끼워 136개를 재생성.

번역량은 152개 문서가 아니라 144개 짧은 구절로 줄었고, 결과는 훨씬 일관됐습니다. 스키마 검증·타입 체크·빌드 전부 통과, 라이브 /ja는 200으로 돌아왔습니다.

진짜 교훈은 번역 트릭이 아니다

트릭은 곁가지입니다. 핵심은 이겁니다.

자동화는 스스로를 검증하지 않으면, 자신 있게 거짓말을 합니다. 영상은 정상 렌더됐고, 업로드는 성공했고, 대시보드는 초록불이었습니다. 파이프라인의 어느 단계도 "이 링크가 실제로 200을 반환하나?"를 묻지 않았기 때문에, 아무도 몰랐을 뿐입니다. 규모가 커질수록 이런 침묵은 비싸집니다 — 검증되지 않은 가정이 33곳에 복제되니까요.

당신 파이프라인 자가진단

앱이나 콘텐츠를 자동으로 찍어내고 있다면, 오늘 세 가지만 확인해보세요.

외부 링크가 실제로 열리는가? 파이프라인이 만든 URL에 대해 HTTP 상태를 한 번이라도 검사합니까? (curl -o /dev/null -w "%{http_code}" 한 줄이면 됩니다.)
로케일/변형 매트릭스가 실제 배포와 일치하는가? "모든 항목이 모든 로케일을 지원한다"는 암묵적 가정이 어딘가에 박혀 있지 않습니까?
렌더 결과가 라이브 상태를 반영하는가? 영상·썸네일·OG가 캡처하는 화면이, 지금 실제로 서빙되는 것과 같습니까?

남은 빚

솔직히 말하면 아직 다 못 고쳤습니다. 이미 업로드된 영상 속 404 화면은 스크린 녹화라 앱을 고쳐도 바뀌지 않습니다 — 재렌더하거나 내려야 합니다. 나머지 22개 깨진 앱과, 애초에 앱 로케일을 무시하고 링크를 찍던 파이프라인도 남아 있습니다. 근본은 파이프라인이 앱의 실제 지원 로케일만 링크하도록 고치는 것이겠죠.

그래서 마지막으로 묻고 싶습니다. 당신의 자동화 제국에도, 아무도 안 눌러본 링크가 있지 않습니까? 지금 딱 하나만 curl 해보세요. 뭐가 나오는지 궁금합니다.