자동화2026년 8월 24일

번역이 실패하면 원문이라도 보여줘야 할까 — 안 보여주기로 한 이유

해외 커뮤니티 글을 모으는 피드를 만들며 부딪힌 선택. 번역 실패 시 원문 노출(fail-open)을 막고 상태를 세 개로 나눠 관리한 이유를 정리했다.

국내외 커뮤니티와 뉴스를 한곳에서 모아보는 피드를 만들었다. 클리앙, 디시인사이드, 루리웹 같은 국내 커뮤니티와 Reddit, V2EX 같은 해외 소스를 함께 본다.

해외 소스가 들어오면서 번역이 필요해졌고, 여기서 생각보다 어려운 선택을 하게 됐다.

번역 서버가 죽었을 때 어떻게 할 것인가

번역은 백그라운드에서 돈다. 글을 수집한 뒤 제목, 본문, 댓글을 차례로 번역한다. 그런데 번역 서버가 느려지거나 죽거나 재시도 중일 때가 있다.

이때 선택지는 둘이다.

fail-open: 번역이 안 됐으면 원문이라도 보여준다. 아무것도 안 보이는 것보다 낫다.

fail-closed: 번역이 끝나기 전에는 아예 안 보여준다.

일반적인 시스템 설계에서는 fail-open이 자주 옳다. 기능 하나가 죽었다고 서비스 전체가 멈추면 안 되니까. 나도 처음엔 그렇게 만들었다.

문제는 피드가 시간순으로 흐른다는 점이었다.

번역이 안 된 영어 글이 원문으로 먼저 뜬다. 나는 그걸 보고 넘긴다. 몇 분 뒤 번역이 완료되지만, 그 글은 이미 피드 아래로 밀려 있다. 결과적으로 번역된 버전을 영영 못 보게 된다.

읽으려고 만든 기능인데, 원문을 먼저 보여주는 바람에 번역본이 사라지는 셈이다.

더 나쁜 경우도 있었다. 제목만 번역되고 본문은 원문인 상태로 노출되면, 제목을 보고 클릭한 뒤 영어 본문을 만난다. 클릭 한 번을 낭비하고 기분도 상한다.

그래서 뒤집었다. 번역이 완료된 글만 화면에 노출한다. 번역 서버에 장애가 있거나 지연되거나 재시도 중이어도, 원문으로 먼저 내보내지 않는다.

여기서 구현상의 함정이 있었다. 처음엔 글마다 translated: true/false 하나만 뒀다.

이러면 “제목은 번역됐고 본문은 아직”인 중간 상태를 표현할 수 없다. 번역을 어느 시점에 완료로 칠지 애매해지고, 결국 부분 번역된 글이 새어 나간다.

상태를 셋으로 나눴다.

그리고 셋이 모두 ready일 때만 글 전체를 ready로 본다.

이렇게 바꾸니 “제목만 번역된 글이 노출되는” 문제가 사라졌다. 상태가 나뉘어 있으니 어디서 막혔는지도 바로 보인다. 본문은 됐는데 댓글에서 계속 실패한다면 댓글 번역 쪽만 보면 된다.

비슷한 문제가 본문 수집에도 있었다.

커뮤니티 글의 본문을 가져오지 못하면 “원문 보기” 링크만 남는 fallback 화면이 뜬다. 처음엔 이걸 그냥 결과로 저장했다.

문제는 이 fallback이 정상 결과처럼 캐시된다는 것이었다. 일시적으로 수집에 실패한 글이 영영 “원문 보기”만 남은 채 굳는다.

그래서 fallback을 임시 응답으로만 쓰기로 했다. 상세 조회가 가능한 소스라면, 사용자가 글을 열 때 원문 본문을 다시 가져온다. 끝내 못 가져왔을 때만 fallback을 유지한다.

두 결정은 같은 이야기다.

미완성 상태를 완성처럼 취급하면, 나중에 고칠 기회가 사라진다.

번역 안 된 글을 노출하면 사용자가 이미 읽고 지나가 버린다. 실패한 본문 수집을 캐시하면 다시 시도하지 않는다. 둘 다 “일단 뭐라도 보여주자”는 선의에서 나왔는데, 결과적으로는 제대로 된 것을 볼 기회를 없앤다.

수집·가공 파이프라인을 만든다면 처음부터 이렇게 하는 편이 낫다.