# X의 전체 자동번역은 얼마나 많은 계산을 요구하는가: 읽기 시점·캐시·GPU 비용

어느 날부터 다른 언어의 게시물이 피드에서 자연스럽게 한국어로 나타난다. 화면에는 한 줄의 번역문만 추가되었지만 서버에는 새로운 종류의 일이 생긴다. 원래의 글을 저장하고 전달하는 일과, 원래 존재하지 않던 문장을 모델로 생성하는 일은 연산 비용이 다르다. X(옛 트위터)만큼 큰 서비스가 이를 기본 동작으로 바꾸었다면, 모든 게시물을 올리는 즉시 여러 언어로 번역하는 것일까? 아니면 독자가 글을 요청할 때마다 GPU가 작동하는 것일까? 두 극단 사이에 얼마나 큰 캐시가 있는가?

이 문제의 출발점은 **전체 자동번역이라는 사용자 경험이 전체 게시물의 실시간 전언어 번역을 뜻하지는 않는다**는 사실이다. 동시에 “필요할 때만 번역한다”는 말만으로 엄청난 추론량이 사라지지도 않는다. 비용은 게시물 수, 서로 다른 목표 언어 수, 실제 노출, 번역 결과의 재사용률, 모델 처리속도에 따라 전혀 다르게 움직인다.

## 무엇이 공식적으로 알려졌고 무엇은 알려지지 않았는가

2026년 4월의 [X 자동번역 롤아웃 관련 보도](https://techcrunch.com/2026/04/08/x-is-rolling-out-automatic-translation-and-photo-editing-powered-by-grok/)에는 X의 제품 담당 Nikita Bier가 전세계 자동번역 확대와 Grok 기반 번역, 자동번역 해제 선택지를 알렸다는 내용이 소개되어 있다. [X의 기존 게시물 번역 도움말](https://help.x.com/en/using-x/translate-posts)은 번역 가능한 게시물에 수동 번역 항목이 표시되는 기능을 설명한다. 이것은 **제품 기능과 공개 발언**의 자료이지, 서버가 요청·큐·캐시를 어떤 순서로 처리하는지 보여 주는 설계 문서는 아니다.

X가 오래전부터 게시물의 언어 정보를 다뤄 왔다는 단서는 [2013년 Twitter 개발자 블로그의 게시물 메타데이터 설명](https://blog.x.com/developer/en_us/a/2013/introducing-new-metadata-for-tweets)에서, 추천 피드에 후보 선별·랭킹의 여러 단계가 있다는 단서는 [2023년 Twitter 추천 알고리즘 공개 글](https://blog.x.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm)에서 얻을 수 있다. 하지만 **기존 언어 식별과 후보 랭킹이 실제로 최신 번역 시스템의 구성요소로 재사용되었다는 것은 공개된 확인 사실이 아니다.** 역사적 역량과 현행 구현은 분리해야 한다.

결론적으로 “게시 시점 전번역”, “조회 시점 번역”, “인기 게시물 선계산”, “Grok 호출 후 언어별 캐시” 중 어느 조합이 X의 운영 환경에서 실제 사용되는지는 공개된 기술 설계 없이 단정하기 어렵다. 아래 구조와 숫자는 **서비스 설계에 관한 가설과 계산 예시**이지 X 내부 구조의 관측값이 아니다.

## 글을 쓰는 순간과 글을 읽는 순간은 다른 계산 문제다

게시물을 작성할 때에는 원문 저장, 언어 추정, 텍스트 정리, 색인 생성 같은 작업을 수행할 수 있다. 이것만으로 다른 언어로 된 번역본이 만들어지는 것은 아니다. 번역을 만드는 시점을 선택하면 구조가 세 갈래로 나뉜다.

| 방식 | 계산이 시작되는 순간 | 이점 | 부담 |
| --- | --- | --- | --- |
| 작성 시점 선번역 | 게시 직후 목표 언어들로 생성 | 읽기 지연이 작고 비용 예측이 상대적으로 쉬움 | 읽히지도 않을 글과 언어에 계산을 낭비 |
| 읽기 시점 온디맨드 | 특정 언어의 독자가 처음 필요로 할 때 생성 | 필요한 언어에만 계산 사용 | 첫 요청의 지연·모델 서빙의 피크 부하 |
| 혼합형 | 일반 글은 첫 요청, 노출 가능성이 큰 글은 일부 선계산 | 대량 반복 조회와 긴 꼬리 게시물을 다르게 처리 | 어떤 글·언어를 선계산할지 정해야 함 |

전언어 선번역은 게시물의 독자 수와 무관하게 비용이 발생한다. 온디맨드는 실제로 읽히는 내용에 집중하지만, 캐시가 없다면 사용자 수가 많을수록 추론 호출이 증식한다. **혼합형이 경제적으로 유력하다는 판단은 합리적인 아키텍처 추론이지 X의 구현에 대한 내부 증언이 아니다.**

## 지원 언어의 수와 실제 만들어지는 번역본 수

X 앱의 지원 언어 목록으로 앞선 논의에서 [앱스토어 페이지](https://apps.apple.com/us/app/x/id333903271)를 근거로 **약 42개 언어**라는 숫자가 거론되었다. 그러나 앱의 **사용자 인터페이스 지원 언어**와 **자동번역을 지원하는 언어**, **한 게시물에 실제 생성되는 목표 언어**는 다른 집합이다. 42를 곧바로 자동번역 언어 수로 놓아서는 안 된다.

한국어 사용자에게 영어 글을 보여 줄 때 필요한 것은 보통 영어에서 한국어로 번역한 결과 하나다. 같은 글을 일본어 사용자가 읽으면 일본어 번역본도 하나 더 필요할 수 있다. 수십 가지 언어쌍이 가능하다고 해서 모든 게시물에 수십 개 번역본을 미리 준비해야 하는 것은 아니다. [X의 언어 설정 안내](https://help.x.com/en/managing-your-account/how-to-change-language-settings) 역시 표시 언어와 콘텐츠 언어를 별도의 설정 문제로 취급한다. 어느 설정이 자동번역의 실제 목표 언어 결정에 쓰이는지는 그 자체로 별도 확인이 필요하다.

비용 산정에서 의미 있는 값은 지원 언어의 총수보다 **번역이 필요한 게시물 하나당 평균 몇 개의 서로 다른 목표 언어 번역본을 실제 생성하는가**다. 다국어를 읽는 사용자는 번역 자체를 원하지 않을 수도 있고, 같은 언어권의 많은 사용자는 한 번 생성된 결과를 공유할 수 있다.

## 캐시의 역할: 반복 노출과 반복 추론을 분리하기

하나의 게시물이 한국어 사용자 10만 명에게 노출될 때 같은 한국어 번역을 매번 새로 생성할 필요는 없다. 번역 결과를 `(게시물 ID, 목표 언어)`와 연결해 저장한다면 **첫 생성 1회와 이후 재사용 99,999회**라는 극단적인 예가 가능하다. 중요한 것은 노출 수와 생성 수가 같지 않다는 점이다.

실제 설계를 구체화한다면 원문 변경 여부, 모델 버전, 번역 정책과 품질에 따라 키 또는 만료 정책을 달리할 수 있다. 특히 모델을 개선했을 때 모든 과거 번역본을 영구 보존하는 것과, 새 요청에서 점진적으로 교체하는 것은 서로 다른 운영 선택이다. 이 역시 권장 가능한 설계의 예시이며 X가 이렇게 저장한다는 공개 증거는 아니다.

비용 최적화에는 두 종류의 캐시가 있다. 첫째는 **같은 번역 결과의 재사용**이다. 둘째는 **서버가 어떤 글을 번역해야 할지 결정하는 결과의 재사용**이다. 피드의 후보를 거르고 사용자 언어를 고려하는 가벼운 판단이 모델 호출보다 앞서면, 상당수 게시물에는 번역 GPU가 전혀 동원되지 않는다. 다만 선별과 사전 호출을 너무 적극적으로 하면 오히려 쓸모없는 번역을 대량 생성할 수 있다.

## 작동 구조의 가능한 한 가지 설계

아래 순서는 **가정한 하이브리드 구조**다. X가 공개한 내부 다이어그램이 아니다.

1. 게시물이 생성되면 원문을 저장하고 원문 언어를 추정한다.
2. 피드의 게시물 후보와 사용자의 언어 설정·자동번역 선호를 확인한다.
3. 언어가 다르고 번역할 실익이 있다고 판단되는 게시물만 번역 요청 대상으로 삼는다.
4. 목표 언어별 번역 캐시를 조회한다. 이미 있으면 저장된 결과를 반환한다.
5. 없는 경우 짧은 번역 작업을 추론 서비스에 보내고, 가능하면 여러 요청을 함께 묶어 처리한다.
6. 결과를 재사용 가능한 형태로 저장한다. 첫 요청이 늦어지면 원문을 먼저 표시하고 나중에 번역을 붙이는 식의 화면 정책도 고려할 수 있다.
7. 재사용이 매우 많을 것으로 예상되는 게시물에는 일부 언어를 사전 생성하는 정책을 적용할 수 있다.

이 단계마다 비용의 종류가 다르다. 언어 식별과 캐시 탐색은 비교적 가벼운 CPU·메모리·저장소 작업이고, 모델이 새 문장을 생성할 때에만 본격적인 추론 계산이 필요하다. **새 추론을 없애는 것이 아니라 동일한 일을 다시 하지 않게 하는 구조**다.

## 규모의 출발점: 하루 5억 개 게시물이라는 오래된 기준

[2023년 Twitter 추천 알고리즘 공개 글](https://blog.x.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm)을 바탕으로 이전 분석에서는 **하루 약 5억 개 게시물**을 계산의 분모로 사용했다. 이는 **2026년의 실측 게시량이라는 뜻이 아니다**. 초당으로 나누면 평균 약 5,787개다. 또한 게시물이 전부 타임라인에서 읽히는 것도 아니고, 하나의 게시물이 하나의 언어로만 읽히는 것도 아니다.

이 숫자를 `P = 5억 게시물/일`로 둔 *가상 계산*을 하자. 게시물 중 `f` 비율이 적어도 하나의 번역을 필요로 하고, 그 게시물마다 평균 `k`개의 목표 언어로 새로운 번역본을 만든다고 하면 첫 근사는 다음과 같다.

`일일 번역 생성 건수 T = P × f × k`

`k = 1`, 즉 번역 대상 게시물당 목표 언어 하나만 실제 생성한다고 놓으면:

| 번역 대상 게시물 비중 f | 하루 새로운 번역본 | 초당 평균 요청 |
| --- | ---: | ---: |
| 3% | 1,500만 건 | 약 174건 |
| 8% | 4,000만 건 | 약 463건 |
| 15% | 7,500만 건 | 약 868건 |
| 20% | 1억 건 | 약 1,157건 |

이 3%, 8%, 15%, 20%는 **X에서 관측된 번역 비율이 아니라 예시 입력값**이다. 15%라는 숫자가 현실적인 중앙값으로 검증된 것도 아니다. `k = 2`라면 같은 비율에서 호출 건수가 두 배가 된다. 반대로 전 게시물을 모든 앱 지원 언어로 번역한다는 가정에는 목표 언어 집합 자체가 확인되지 않았다는 문제가 있다.

## 토큰을 대입하면 GPU를 얼마나 쓸까

짧은 게시물에 대한 개략적인 번역 작업량을 **입력 40~80토큰, 출력 40~80토큰**, 총 80~160토큰으로 가정할 수 있다. 앞선 저비용 예에서는 60~120토큰도 사용했다. 실제로는 모델 지시문, 텍스트 이외의 입력, 다국어 토큰화 방식, 문맥 제공 여부에 따라 달라지므로 이 구간 역시 실측치가 아니다.

위 표에 총 80~160토큰을 대입한 평균 처리량은 다음과 같다. 이는 입력·출력을 하나로 합산한 **개략적인 토큰 회계**이며, GPU가 입력 토큰과 출력 토큰을 똑같은 속도로 처리한다는 뜻이 아니다.

| 가상 시나리오 | 총 토큰/일 | 평균 토큰/초 |
| --- | ---: | ---: |
| f=8%, k=1, 80토큰/건 | 32억 | 약 37,000 |
| f=15%, k=1, 120토큰/건 | 90억 | 약 104,000 |
| f=20%, k=1, 160토큰/건 | 160억 | 약 185,000 |
| f=15%, k=2, 120토큰/건 | 180억 | 약 208,000 |

[Red Hat의 MLPerf 추론 소개](https://www.redhat.com/ko/blog/efficient-and-reproducible-llm-inference-red-hat-mlperf-inference-v51-results)에서 단일 H100, 8B급 모델에 대해 약 **5,103토큰/초**라는 벤치마크 수치가 이전 논의에 인용되었다. 이를 중간 시나리오인 104,000토큰/초로 단순히 나누면 **약 20장의 H100**이라는 숫자가 나온다. 하지만 이 값은 오직 *서로 다른 처리량 숫자를 나눈 산술*일 뿐 실제 번역 GPU 필요 수량이 아니다.

모델 크기, 사용 가능한 메모리, 배치 크기, 입력 처리(prefill)와 출력 생성(decode)의 서로 다른 병목, 언어별 토큰 수, 지연시간 SLA, 피크 시간대, 장애·재시도, 장비 가동률에 따라 한 GPU가 감당하는 실시간 번역량은 크게 달라진다. 이전의 “수십~수백 장”, “운영 풀 100~300장” 추정은 이런 항목을 실측하지 않은 **예시적 범위**였다. **이를 X의 증설 규모로 인용해서는 안 된다.**

## 게시 비율과 노출 비율을 혼동하면 계산이 붕괴한다

한 가지 비율이 특히 위험하다. “게시물의 3%가 번역된다”와 “피드에서 발생하는 노출의 3%가 번역이 필요하다”는 전혀 다르다. 게시 기준의 번역본 생성 수는 **서로 다른 게시물·언어 조합**을 센다. 노출 기준은 동일한 게시물이 반복해서 나타나는 횟수를 센다.

`E = 하루 게시물 노출 횟수`, `r = 그중 번역 표시가 필요한 비율`, `h = 번역 결과가 이미 존재하는 비율`이라고 하면, 같은 번역을 재사용하는 간단한 읽기 시점 모형은 다음과 같다.

`추가 번역 생성 요청 ≈ E × r × (1-h)`

이 식만으로 실제 비용을 계산할 수는 없다. `E`, `r`, `h`가 공개적으로 확인되지 않았고, 캐시 적중률도 인기글·언어·시간·지역에 따라 달라지기 때문이다. 그러나 변수 하나의 중요성은 분명하다. **노출량이 매우 커도 캐시가 잘 맞으면 생성량은 작을 수 있고, 캐시 적중이 낮으면 짧은 글이라도 GPU 호출이 폭증한다.**

따라서 글이 엄청나게 많이 읽힌다는 사실만으로 추론량을 몇 배로 환산할 수 없다. 반대로 하루 게시물 수만으로 계산하면 다양한 독자 언어에 따라 같은 글의 번역본이 여러 개 생성되는 비용을 과소평가할 수 있다.

## 원래의 호스팅 비용보다 몇 배나 무거운가

추가 부담을 **기존 웹서버/API**, **저장·전송**, **AI 추론 GPU**로 나누어야 한다.

| 자원 | 새로운 번역 서비스가 추가하는 일 | '몇 배'의 의미 |
| --- | --- | --- |
| 기존 피드·API 서버 | 사용자 설정 판정, 캐시 조회, 번역본 연결 | 원래 서비스의 CPU·메모리·요청량에 따라 증분이 달라짐 |
| 저장소·네트워크 | 언어별 번역문과 메타데이터 보관·전송 | 짧은 텍스트지만 중복 언어 수와 보관기간에 따라 누적 |
| 번역 추론 서버 | 캐시 미스마다 모델 실행, 피크 대응 | 기존 단순 텍스트 전달과 비교해 비용 성격이 크게 달라짐 |
| 전력·시설 | 추가 GPU 가동과 냉각·네트워크 | 이미 보유한 설비의 유휴용량과 외부 임차 여부가 관건 |

이미지·영상이 많은 플랫폼에서 짧은 번역 텍스트의 추가 네트워크 바이트가 전체 전송량의 주된 문제는 아닐 가능성이 있다. 반면 사용자가 처음 요청한 언어의 번역본을 생성할 때에는 원래의 캐시된 텍스트 조회에 없던 추론 단계가 생긴다. **네트워크 비용이 작다는 사실은 GPU 비용도 작다는 뜻이 아니다.**

정확한 비용 증가율은 다음처럼 적어야 한다.

`플랫폼 총비용 증가율 = 추가 번역 관련 월비용 / 번역 이전 플랫폼 월비용`

분자에는 GPU 임대 또는 감가상각, 전기·냉각, 번역 캐시, 운영·배포·모니터링이 들어가고, 분모에는 기존 웹서비스와 영상 전송·추천·광고·스토리지 등의 비용이 들어간다. 어느 쪽도 공개된 숫자가 없다면 “원래 호스팅의 3~10%”, “기존 대비 몇 배”라는 비율은 계산할 수 없다. **새 기능의 원시 토큰 수와 회사 전체 호스팅 비용은 서로 다른 분모다.**

## 큰 GPU 클러스터가 있다는 사실만으로 비용이 해결되는가

[xAI의 Colossus 소개](https://x.ai/colossus)에서 앞선 분석은 **20만 GPU 규모**라는 발표치를 인용했다. 그런데 전체 GPU 보유량, 실제 설치·가동량, 모델 학습에 이미 할당된 수량, 실시간 번역에 할당할 수 있는 수량은 같지 않다. X와 xAI가 관련 사업자라는 점이 어느 순간 번역에 무료로 전용 가능한 GPU가 20만 장 있다는 뜻은 아니다.

“번역 전용 100~300 GPU면 20만 장의 극히 일부”라는 비교에는 두 번의 불확실성이 있다. 먼저 100~300장이 서비스 수요를 만족한다는 근거가 부족하다. 다음으로 20만 장 전체가 같은 기종·동일한 처리량을 내고 즉시 번역 서비스에 쓰일 수 있다는 가정도 성립하지 않는다. 대형 클러스터 숫자는 공급 능력에 관한 **맥락**으로는 유용하지만, 실제 서비스의 증설 비율을 결정하는 근거로는 부족하다.

## 가정이 맞는지 알려면 무엇을 측정해야 하나

시스템의 실물을 이해하려면 서버 설계도보다 먼저 다음 종류의 지표가 필요하다. **하루 실제 번역 결과를 새로 생성한 횟수**, 목표 언어별 서로 다른 게시물 수, 번역 요청의 캐시 적중률, 모델 및 프롬프트당 입력·출력 토큰, 번역의 중앙값과 95·99백분위 지연시간, 실시간 피크 대 평균 트래픽, 번역 전용 GPU의 가동률과 실제 비용이다.

X의 공개 문서가 이 값을 제공하지 않는다면, 사용자 화면에서 번역이 빠르게 나타난다는 관찰만으로 선번역인지 캐시 적중인지 분간하기 어렵다. 인기 게시물이 즉시 번역된다는 사실도 과거에 번역됐는지, 미리 번역됐는지, 지금 고속으로 처리됐는지를 분리하지 못한다.

보다 현실적인 결론은 정확한 서버 장수를 하나로 찍는 일이 아니다. **같은 자동번역 화면 아래에도 완전히 다른 비용 구조가 가능하며, 그것을 결정하는 것은 지원 언어의 목록보다 실제 서로 다른 번역본 생성 건수와 캐시 적중률**이라는 것이다. 게시 즉시 전언어 번역도, 노출마다 무조건 실시간 번역도 비용 측면에서 불리할 이유가 뚜렷하다. 그러나 X가 그 사이에서 어떤 지점을 택했는지는 여전히 공개 설계가 필요한 문제로 남는다.

## 근거와 한계

이 글에 포함된 X 도움말, 개발자 블로그, 2026년 4월 보도, 앱 지원 언어, xAI 클러스터, Red Hat 벤치마크는 기존 논의에서 이미 언급된 자료와 링크다. **이 원고를 만들며 해당 외부 링크를 새로 열람하거나 2026년 현재의 실가동 수치로 재검증하지 않았다.** 하루 5억 게시물은 과거 기준이고, 42개 앱 지원 언어는 번역 언어 수가 아니다. 3%·8%·15%·20%의 대상 비율, 번역 토큰 길이, 추론 GPU 수는 관측이 아니라 계산과 가정이며, X의 실제 아키텍처·캐시 적중률·호스팅비 증분은 미확인이다.

추론 계산의 일반적 구조와 가용 컴퓨트의 한계는 [AI 계산 스케일링과 데이터센터](./ai-compute-scaling-inference.md), GPU 설비의 전력·냉각·가동 조건과 규모 지표의 구별은 [세계 데이터센터의 연산 지리](./data-center-world-capacity.md)에서 더 자세히 다룬다.