[🛠] 다국어 블로그 Codex Goal이 13시간 넘게 걸린 이유

✨ GPT-5.5의 요약 　

hyuk.blog를 /en/ 영어판에서 8개 locale 운영 기준까지 확장하는 Codex Goal을 진행하며, 번역 품질과 언어 전환, 조회수 공유, p 규칙, 사용량 소모까지 다시 정리한 기록.

처음엔 /en/만 고르면 될 줄 알았다

처음 질문은 단순했다.

en.hyuk.blog가 나을까?
/en/이 나을까?

SEO, GitHub Pages 운영, 원문과 번역본의 연결, 조회수 공유, 앞으로 확장할 언어 구조까지 같이 따져봤고, 결론은 /en/이었다.

이 블로그는 영어판을 완전히 다른 제품처럼 운영하려는 게 아니다. 한국어 원문을 기준으로 번역본을 붙이는 구조다. 그러면 같은 도메인 안에서 언어 URL만 나누고, hreflang으로 서로 연결하는 편이 더 단순하다.

하지만 여기서 끝이 아니었다.

/en/ 하나를 고르는 순간, 홈, 소개, 카테고리, 검색, sitemap, language switcher, 조회수, 번역 품질, 앞으로 글을 push하는 방식까지 같이 움직이기 시작했다.

번역 파일이 아니라 collection 경계였다

영어 글을 _posts 안에 섞으면 안 됐다.

Jekyll에서 _posts는 site.posts에 들어간다. 그러면 한국어 홈, feed, pagination, related posts가 영어 글까지 같이 먹는다. 겉으로는 글이 하나 더 생긴 것처럼 보여도, 실제로는 블로그 전체 목록이 오염된다.

그래서 번역 글은 locale별 collection으로 분리했다.

_posts/...         -> /daily-review/.../
_en_posts/...      -> /en/daily-review/.../
_ja_posts/...      -> /ja/daily-review/.../
_zh_hans_posts/... -> /zh-Hans/daily-review/.../

가장 먼저 확인한 건 이거였다.

다국어 블로그는 번역 파일을 추가하는 일이 아니라, collection 경계를 정하는 일이다.

당시 Goal 아카이브

작업은 2026년 6월 7일부터 시작되어 2026년 6월 8일까지 이어졌다.

처음에는 영어판을 붙이는 정도로 보였지만, Goal은 곧 이렇게 커졌다.

hyuk.blog를 ko 기본 + en, ja, zh-Hans, es, pt-BR, fr, id 확장 locale로 운영 가능한 다국어 블로그로 전환한다.
단순 번역이 아니라 UI, routing, SEO, sitemap, search, language switcher, 조회수 공유, today dedupe까지 맞춘다.
타닥바이블 홍보와 확장성을 기준으로 기독교권 언어를 고려한다.
유료 번역 API는 쓰지 않는다.
번역은 최신 GPT worker/subagent 기준으로 진행한다.
저품질 로컬 번역 결과는 신뢰하지 않는다.
원문 확정 전에는 번역하지 않는다.
글을 수정해 p할 때는 active locale 번역도 같이 맞춘다.
build는 번역 batch마다 돌리지 않고 끝에서 필요한 범위로 확인한다.

이 Goal 자체가 틀렸던 건 아니다.

문제는 Goal이 실행 기준으로 작아지지 못하고, 상태 보고와 검수 항목과 번역 범위가 계속 붙으면서 너무 커졌다는 점이었다.

번역 품질에서 한 번 크게 맞았다

번역은 제일 먼저 신뢰가 깨진 지점이었다.

처음에는 많은 글을 한 번에 번역하면 될 줄 알았다. 그런데 샘플에서 프롬프트 지시문이 그대로 섞인 파일이 나왔다.

Return only the translated content. Do not add notes or fences.

이건 문장 몇 개가 어색한 문제가 아니었다. 생성 경로를 믿을 수 없다는 뜻이었다.

그래서 “저품질 번역을 검수해서 살릴 것인가, 아니면 재생성할 것인가”를 샘플로 다시 봤다. 결론은 재생성 쪽이었다. 특히 Ollama나 Argos 같은 로컬 번역 결과는 공개 글 기준으로 믿기 어려웠다. 번역이 빠르게 나오는 것보다, 어떤 모델로 어떤 기준을 통과했는지가 더 중요했다.

이번에 남은 기준은 분명하다.

번역은 완료율보다 신뢰 경로가 먼저다.
원문이 확정되기 전에는 번역하지 않는다.
공개 글 번역은 저품질 로컬 번역으로 때우지 않는다.

언어 전환과 조회수도 같이 흔들렸다

영어판은 직접 URL로는 열렸다.

그런데 사용자가 한/영 전환을 못 찾았다.

처음에는 English / 한국어 링크를 일반 메뉴 안에 넣었다. HTML에는 있었지만 사용자는 못 찾았다. 모바일에서는 더 그랬다. 그래서 언어 전환은 메뉴 항목이 아니라 global control로 봐야 한다는 기준이 생겼다.

조회수도 말처럼 간단하지 않았다.

영어 글은 다른 글이 아니라 같은 글의 번역이다. /daily-review/x/와 /en/daily-review/x/가 서로 다른 조회수 key를 쓰면 안 된다. 그래서 HTML의 data-page-view-path, 클라이언트 JS, Cloudflare Worker가 모두 locale prefix를 제거한 canonical path 기준으로 조회수를 세게 했다.

여기서도 일이 커졌다. Worker 코드만 고치면 끝나는 게 아니었다. Wrangler CLI로 배포해야 했고, dry-run에서 D1 DB binding이 빠질 수 있다는 신호도 봤다. 그래서 wrangler.toml에 Worker entrypoint와 D1 binding을 repo 설정으로 고정하고, binding이 잡힌 것을 확인한 뒤 배포했다.

특히 today dedupe가 중요했다.

같은 글을 한국어로 읽고 영어로 바꿨다고 today가 두 번 올라가면 안 된다. 언어 URL은 달라도 같은 canonical page라면 같은 dedupe key를 써야 한다.

Codex Goal 달성까지 13시간 넘게 걸린 이유

이 작업이 순수 개발 시간으로만 13시간이었다는 뜻은 아니다.

문제는 Codex에 걸어둔 Goal이 완료 상태에 도달하기까지 13시간을 넘겼다는 점이었다.

단순히 작업량이 많아서만은 아니었다. 판단이 흔들린 부분이 있었다.

전체 번역과 검수를 동시에 붙잡았다. “다 생성하고 나중에 검수할 것인가”, “지금처럼 검수하며 갈 것인가” 사이에서 기준이 흔들렸다. worker 모델을 제대로 확인하지 못한 상태에서 번역 품질을 믿으려 했고, 저품질 번역이 나오자 다시 만들었다.

원문이 확정되기 전에 번역부터 하려 한 것도 문제였다.

공개할 한국어 글이 계속 바뀌는데, 번역을 먼저 만들면 당연히 어긋난다. 결국 원문을 다시 쓰고, 기존 번역을 버리고, 또 번역해야 하는 상황이 생겼다.

build 판단도 흔들렸다.

번역 batch마다 build를 돌리려 하면 작업이 끝나지 않는다. build는 중요한 검증이지만, 매번 돌리는 의식이 아니다. 원문과 번역 범위가 확정된 뒤, 끝에서 필요한 범위로 확인해야 한다.

p의 의미도 뒤늦게 명확해졌다.

이제 post 변경이 있으면 p는 단순 commit/push가 아니다. 확정된 원문에 대해 active locale 번역까지 맞추고, 그 다음 push하는 흐름이다.

미쳐 날뛰는 주간 사용량

이번 번역 작업은 유료 API만 피하면 끝나는 문제가 아니었다.

바로 어제 결제했던 Pro x20 주간 사용 할당량이 이틀만에 100%에서 50%까지 감소했다.

이 소모는 번역을 무작정 병렬 생성하고, 실패 번역을 다시 만들고, 원문이 바뀐 뒤 다시 번역한 판단 비용이었다. 돈 드는 번역 API를 쓰지 않았다고 해서 비용이 0이 되는 건 아니었다. 모델 사용량, 시간, 집중력, 검수 피로가 전부 비용이었다.

그래서 앞으로는 먼저 잠가야 한다.

원문 확정
번역 범위
검수 방식
build 시점
push 기준

이 다섯 개가 흐릿하면, 다국어 작업은 금방 다시 커진다.

이번에 남긴 운영 기준

운영 기준도 같이 남겼다.

언어 URL은 같은 도메인 안에서 나눈다.
번역 글은 locale collection으로 분리한다.
번역은 완료율보다 신뢰 경로를 먼저 본다.
원문 확정 전에는 번역하지 않는다.
언어 전환은 항상 보이는 global control이어야 한다.
조회수와 today dedupe는 canonical page 기준으로 잡는다.
post를 p할 때는 active locale 번역 동기화까지 본다.
build는 batch마다가 아니라 끝에서 필요한 범위로 확인한다.
Goal은 장황한 상태 보고가 아니라 실행 기준으로 줄여야 한다.

영어판을 붙인 것도 중요하지만, 더 중요한 건 앞으로 블로그가 다국어 상태로 계속 운영될 수 있는 기준을 만든 것이다.

비싸게 배웠다.

그래도 필요한 기준이었다.