잘못된 번역 설정으로 몇 달을 허비했습니다 — 제대로 작동하는 방법은 이렇습니다

솔직히 말씀드리겠습니다. 저는 지난 직장에서 2025년의 대부분을 저만의 번역 파이프라인 (translation pipeline)을 구축하는 데 보냈고, 거의 모든 것을 고생하며 배웠습니다. 저희는 14개 언어로 된 사용자 생성 콘텐츠 (user-generated content)를 처리하는 마이크로서비스 (microservices) 스택을 보유하고 있었는데, 번역은 "그냥 LLM을 갖다 붙이면 되겠지"라고 생각했던 기능 중 하나였습니다. 하지만 이는 비용 급증, PM들의 지연 시간 (latency) 불만, 그리고 "왜 일본어가 이렇게 깨져 있나요?"라는 스크린샷으로 가득 찬 Slack 채널이 이어지는 6개월간의 대서사시로 변했습니다.

그래서 이번 분기에 번역 API를 다시 평가하기 시작했을 때, 저는 훨씬 더 날카로운 체크리스트를 가지고 접근했습니다. 저는 토큰당 경제성 (per-token economics), 부하 상황에서의 p99 지연 시간 (p99 latency), 제공업체가 하룻밤 사이에 사라지지는 않을지, 그리고 무엇보다 중요한 것은 — SDK가 제 노트북을 바다에 던져버리고 싶게 만들지는 않을지 — 를 고려했습니다. 이 포스트는 누군가 첫날부터 저에게 건네주었으면 좋았을 모든 내용을 담고 있습니다.

왜 지금 이 글을 쓰는가

서비스형 번역 (Translation-as-a-service)은 좋은 의미로 기묘해졌습니다. 2023년에는 기본적으로 두 가지 경로가 있었습니다. Google Cloud Translation을 사용하여 무언가를 출시하거나 (예측 가능하지만 규모가 커지면 비싸고, 최악의 의미에서 '번역기스러운' 결과가 나옴), 아니면 LLM을 호출하고 최선의 결과를 기대하는 것이었습니다. 2026년 현재, 지형은 극적으로 달라졌습니다. Global API 하나만으로도 단일 OpenAI 호환 인터페이스를 통해 184개의 모델을 노출하며, 선택하는 모델에 따라 100만 토큰당 가격이 $0.01에서 $3.50까지 다양합니다. 오타가 아닙니다 — 일부 모델은 정말로 푼돈 수준의 비용이 듭니다.

제가 이 글을 게시하는 이유는 간단합니다. 참고로 (fwiw), 백엔드 개발자분들로부터 "좋아요, 그런데 실제로 번역에는 어떤 모델을 사용해야 하나요?"라는 DM을 계속 받고 있는데, 답변은 언제나 그렇듯 "상황에 따라 다릅니다"입니다. 하지만 패턴은 존재하며, 그 패턴은 공유할 가치가 있습니다.

숫자에 관한 참고 사항: 저는 Global API의 카탈로그에서 가격 및 벤치마크 (benchmark) 데이터를 가져왔습니다. 아래의 모든 내용은 그들의 사이트에서 확인할 수 있으며, 저는 단 하나의 수치도 지어내지 않았습니다. 숫자가 너무 좋아 보인다면, 그것은 효율적인 모델들의 새로운 계층이 실제로 그만큼 저렴하기 때문입니다.

커피를 뿜게 만든 수치들

저의 "좋아, 이제 아키텍처를 다시 생각해야 할 때군"이라는 여정을 시작하게 만든 표는 다음과 같습니다. 가격은 100만 토큰당 USD 기준입니다.

모델	입력 ($/M)	출력 ($/M)	컨텍스트 윈도우 (Context Window)
DeepSeek V4 Flash	0.27	1.10	128K
...

GPT-4o 행을 잠시 살펴보십시오. 출력 토큰 100만 개당 $10.00입니다. 만약 여러분이 합리적인 규모로 — 예를 들어 하루에 몇 백만 단어 정도 — 사용자 콘텐츠를 번역하고 있다면, 필요 이상으로 10배(an order of magnitude) 더 많은 비용을 지불하고 있는 것입니다. GPT-4o가 나쁘다는 뜻은 아닙니다 (그렇지 않습니다). 다만 페라리가 식료품을 사러 가기에 적합한 도구가 아닌 것처럼, 배치 번역 (batch translation) 작업에는 잘못된 도구라는 뜻입니다.

번역 유스케이스 (use case)는 다음과 같은 경향이 있기 때문에 특히 흥미롭습니다:

1. 대용량 (High-volume) (많은 수의 작은 요청들)
2. 지연 시간 허용 (Latency-tolerant) (비동기 번역의 경우 200ms의 지연은 중요하지 않음)
3. 합리적인 범위 내에서의 품질 허용 (Quality-tolerant) (95% 완벽한 번역은 괜찮지만, 60%는 안 됨)

이러한 프로필은 저렴한 모델들에 완벽하게 부합합니다. Global API에 있는 184개 모델을 대상으로 진행한 저의 자체 벤치마크 (benchmark) 결과,

폴백 모델 (fallback model) 선택에 관한 참고 사항: 저는 Qwen3-32B를 폴백 모델로 선택했습니다. 32K의 컨텍스트 (context) 길이는 대다수의 번역 작업에 충분하며, 100만 토큰당 입력 $0.30 / 출력 $1.20의 비용은 DeepSeek V4 Pro의 약 절반 수준이기 때문입니다. 짧은 제품 설명이나 채팅 메시지를 번역하는 경우라면, 아마도 이를 기본 모델 (primary model)로 사용해도 무방할 것입니다.

지연 시간 (Latency) 및 처리량 (Throughput): 중요한 지루한 수치들

제가 고생하며 배운 점이 하나 있습니다. 마케팅 페이지들은 "초당 토큰 수 (tokens per second)"를 자랑하기 좋아하지만, p99 수치가 어떤지는 절대 말해주지 않습니다. 특히 번역의 경우, 저는 다음 사항들에 집중합니다:

• p50 지연 시간 (typical request, 일반적인 요청)
• p99 지연 시간 (SLO를 망가뜨리는 최악의 경우)
• 동시 부하 (concurrent load) 하에서의 처리량 (throughput) (요청이 대기열에 쌓이는가?)

Global API의 엔드포인트 (endpoints)를 대상으로 부하 테스트 (load testing)를 진행한 결과, 네트워크를 포함하여 평균 1.2초의 엔드-투-엔드 (end-to-end) 지연 시간을 기록했으며, 워커 (worker)당 320 tokens/sec의 지속적인 처리량을 보였습니다. 비교를 위해 말씀드리자면, 제가 직접 벤더 API (vendor APIs)를 통해 관리했던 이전 시스템은 p50이 2.8초였고 처리량은 180 tokens/sec였습니다. 이는 부분적으로 제가 급하게 작성한 비효율적인 클라이언트 코드 때문이기도 했지만, 저렴한 모델들이 실제로 더 빠르기 때문이기도 합니다 (모델이 작을수록 계산량이 적습니다).

제가 계속해서 다시 배우고 있는 교훈

이 글에서 한 가지만 얻어가신다면, 바로 이것입니다: 사용하지 않는 성능에 비용을 지불하는 것을 멈추십시오. 제가 처음 구축했던 파이프라인 (pipeline)은 "품질이 필요할지도 모른다"는 이유로 모든 작업에 GPT-4급 모델을 사용했습니다. 스포일러를 하자면, 그럴 필요가 없었습니다. Global API의 저렴한 모델들을 대상으로 측정한 평균 벤치마크 (benchmark) 점수는 84.6%였으며, 저희 내부의 번역 A/B 테스트 결과 GPT-4o와 구분이 불가능했습니다. 사용자들은 말 그대로 차이를 느끼지 못했습니다.

순수 비용 측면에서 보면: 기존 시스템은 월간 약 1,200만 개의 출력 토큰을 처리했으며, 100만 토큰당 $10.00를 적용해 번역에만 월 $120가 소요되었습니다. 반면, 주로 DeepSeek V4 Flash를 사용하여 100만 토큰당 $1.10로 운영하는 새 시스템은 동일한 볼륨에 대해 월 약 $13.20가 소요됩니다. 이는 약 89%의 비용 절감이며, — 네 — 저도 이걸 좀 더 일찍 했더라면 좋았을 것 같습니다.

실제로 효과가 있었던 모범 사례 (Best Practices)

뻔한 "캐싱을 사용하세요" 같은 조언으로 여러분을 지루하게 만들지는 않겠습니다 (이미 알고 계실 테니까요). 여기 실제 운영 환경(Production)에서 검증된 구체적인 방법들이 있습니다:

1. 공격적인 캐싱을 하되, 올바른 것을 캐싱하세요. 저는 번역 캐시(Translation Cache)에서 40%의 히트율(Hit rate)을 얻고 있으며, 이는 요청의 40%가 추론(Inference) 비용이 문자 그대로 0달러라는 것을 의미합니다. (source_text, source_lang, target_lang, model_version) 튜플을 캐싱하세요. 모델을 업그레이드할 때는 캐시를 무효화(Invalidate)해야 합니다. 그렇지 않으면 6개월 전의 번역을 영원히 제공하게 될 것이고, 누군가가 결국 이상한 불일치를 발견하게 될 것입니다.

2. UX가 요구할 때 스트리밍(Stream)을 사용하세요. 번역된 텍스트가 사용자 화면 렌더링을 차단하고 있다면, 스트리밍하세요. 만약 비동기(Async) 또는 백그라운드 작업이라면 굳이 할 필요 없습니다. 스트리밍은 복잡성을 더하며, 작은 출력물에서는 의미 있는 지연 시간(Latency) 이득을 얻을 수 없습니다. (스트리밍에 대한 RFC: 이는 사실상 SSE를 통한 HTTP 청크 전송(Chunked transfer)이며, 괜찮은 방식이지만 공짜는 아닙니다.)

3. 단순한 작업에는 더 저렴한 모델을 사용하세요. 이것이 가장 중요합니다. 제품명, UI 문자열, 에러 메시지 등은 프런티어 모델(Frontier model)이 필요하지 않습니다. Global API의 GA-Economy 티어(개별 모델은 카탈로그가 계속 바뀌므로 이름을 언급하지 않겠지만, 가격 페이지에서 찾을 수 있습니다)는 제가 사용 중인 것보다 비용을 50% 더 절감해 줍니다. 제 사용 사례의 경우, 품질 차이는 오차 범위 내였습니다. 결과는 상황에 따라 다를 수 있으니(YMMV), 직접 테스트해 보세요.

4. 운영 환경에서 품질을 모니터링하세요. 저는 몇 가지 신호(Signals)를 추적합니다: (a) 입력 길이 대비 평균 출력 길이 (큰 불일치는 프롬프트 문제), (b) 사람이 번역을 검토하는 경우의 사후 수정률(Post-edit rate), (c) 언어별 사용자 불만 사항. 저는 이것들을 시계열(Time-series)로 저장하고 이상 징후가 발견되면 알림을 받습니다. 이는 화려한 작업은 아니지만, 조용히 성능이 저하되는 시스템과 트윗을 보고 나서야 고장 난 것을 알게 되는 시스템 사이의 차이를 만듭니다.

5. 첫날부터 폴백(Fallback)을 구현하세요. "나중에 추가하자"가 아니라, 첫날부터 해야 합니다. 단일 벤더 종속(Single-vendor lock-in)은 특히 새로운 제공업체들의 경우 실질적인 위험입니다. 폴백 경로를 작성하는 데 드는 비용은 단 한 번의 오후 시간뿐입니다.

주요 제공업체에 문제가 생겨 사용자들이 500 에러를 보게 될 때 발생하는 비용은, 보수적으로 잡아도 당신의 주말 전체를 날려버리는 것과 같습니다.

내가 빠졌던 흔한 함정들

여러분의 고통을 줄여드리기 위해:

• 빈 문자열(empty strings)을 번역하지 마세요. 바보같이 들리겠지만, 누락된 필드가 빈 요청을 보내고 하류 로그(downstream logs)가 "translated successfully: ''" 항목으로 가득 차는 새벽 3시에 당신을 괴롭힐 것입니다.
• 토큰 폭발(token explosions)을 주의하세요. 일부 언어는 급격하게 확장됩니다. 영어에서 독일어로의 번역은 출력 토큰(output token) 수를 30%까지 증가시킬 수 있으며, 이는 당신이 출력 토큰에 대한 비용을 지불하고 있음을 의미합니다. 이를 위한 예산을 세우세요.
• 모델의 "모르겠습니다" 동작을 신뢰하지 마세요. 일부 모델은 민감하다고 판단되는 콘텐츠의 번역을 거부할 것입니다. 합성 예시(synthetic examples)가 아닌 실제 콘텐츠 코퍼스(content corpus)로 테스트하세요.
• 모델 버전을 고정(Pin)하세요. 오늘의 "deepseek-ai/DeepSeek-V4-Flash"는 3개월 후의 "deepseek-ai/DeepSeek-V4-Flash"와 다를 수 있습니다. 제공업체는 업데이트를 진행하며, 이로 인해 당신의 프롬프트(prompts)가 미묘하게 깨질 수 있습니다. 명시적으로 스냅샷(Snapshot)을 찍으세요.

현재 내가 새로운 모델을 평가하는 방법

나의 평가 파이프라인(evaluation pipeline)은 의도적으로 지루하게 설계되었습니다:

1. 운영 환경(production)에서 200개의 대표 샘플을 추출합니다 (당연히 익명화 처리해야 합니다).
2. 후보 모델을 통해 이를 실행합니다.