InterMIND를 구동하는 4개의 번역 파이프라인 내부

mind.com의 이전 /product/overview/how-it-works 페이지는 여러 주요 릴리스가 뒤처져 있습니다. 이 페이지는 대부분의 벤더 페이지가 그렇듯 단일 "번역 엔진"을 설명하며, "당신이 말하면"에서 "그들이 듣는다"로 향하는 하나의 큰 화살표로 표현합니다. 그 그림은 2년 전에 이미 단순화된 것이었습니다. 오늘날에는 틀린 그림입니다.

실제로 InterMIND는 4개의 개별 번역 파이프라인을 실행하며, 각 파이프라인은 각기 다른 엔진, 다른 지연 시간 예산, 다른 품질 한계로 다른 문제를 해결합니다. 이들은 언어 선택기를 공유하지만, 엔진은 공유하지 않습니다.

이것이 "어떻게 작동하나요?"라는 질문에 대한 업데이트된 답변입니다.

관련 글: "지원하는 언어는 몇 개인가요?"는 각 파이프라인이 지원하는 범위(23 / 23 / 30 / 17)를 다룹니다. 이 글은 각 파이프라인이 수행하는 작업과 각 파이프라인이 독립적인 이유를 다룹니다.

"모든 것을 위한 하나의 엔진"이 거짓인 이유

실시간 미팅 플랫폼은 한 번에 적어도 4가지 작업을 수행해야 하며, 이들은 서로 양립할 수 없는 방향으로 당깁니다:

1. 실시간 음성 — 1초 미만으로 오디오를 입력받아 번역된 오디오를 출력하며, 모든 시청자는 자신의 언어로 듣습니다. 가장 엄격한 제약은 지연 시간입니다.
2. 실시간 채팅 텍스트 — 빠르고 짧은 메시지, 편집 및 인용, HTML 구조가 유지됩니다.
3. 실시간 공유 노트 — 문자 단위의 협업 타이핑, 번역 후에도 유지되어야 하는 구조적 계층(목록, 제목, 체크박스)을 포함합니다.
4. 비동기 문서 파일 — 채팅에 드롭된 40페이지짜리 PDF. 지연 시간 예산이 없습니다. 가장 엄격한 제약은 충실도(fidelity) — 서식, 표, 페이지 번호, 글꼴입니다.

이 네 가지를 모두 처리하려는 거대한 LLM 호출 하나를 만들 수 있습니다. 우리는 시도해봤습니다. 네 가지 모두에 대해 서툴렀습니다. 음성의 지연 시간 예산은 모델이 '생각'할 수 없음을 의미하고, 문서의 충실도 예산은 모델이 생각해야 함을 의미합니다. 채팅 편집은 시청자 언어로 diff가 필요하지만, 40페이지 PDF는 어떤 토큰 스트리밍 모델도 제공하지 않는 서식 보존이 필요합니다.

그래서 우리는 4개를 실행합니다. 각각에 대한 설명은 다음과 같습니다.

파이프라인 1: 실시간 음성 번역

문제: 한 참가자는 프랑스어로 말합니다. 다른 참가자는 독일어로 참여했고, 세 번째는 브라질 포르투갈어, 네 번째는 일본어로 참여했습니다. 각 참가자는 시선을 맞출 수 있을 만큼 짧은 지연 시간으로 자신의 언어로 발화자의 말을 자신의 귀로 들어야 합니다.

예산: 종단 간 1초 미만. ~1.2초가 넘으면 대화가 끊어집니다 — 사람들이 번역을 덮어 말하기 시작하고, 미팅은 "그냥 영어로 바꾸자" 쪽으로 흘러갑니다.

오디오가 실제로 이동하는 방식

명시적으로 짚고 넘어갈 몇 가지 사항:

• ASR은 미디어 서버에서 실행됩니다. 발화자의 오디오는 WebRTC를 통해 자체 엔진인 프랑스 OVH의 Mind API로 전달되어 통화를 처리하는 것과 동일한 서버에서 인식됩니다. 브라우저는 오디오를 보내고 단어를 되돌려 받기만 합니다. 번역이 시작되기 전에 별도의 음성 벤더나 추가적인 홉이 없습니다. (채팅 음성 메모는 예외입니다. 이들의 음성-투-텍스트는 기본 AI 게이트웨이의 음성 서비스인 Azure AI Speech에서 실행됩니다.)
• 번역은 단일 팬아웃(fan-out)이 아닙니다. 엔진은 시청자별이 아닌 방에 있는 대상 언어별로 번역합니다. 특정 언어로의 번역은 해당 언어를 선택한 첫 번째 청취자가 번역 스트림을 요청할 때 시작됩니다. 독일어를 선택한 세 명의 참가자는 하나의 독일어 번역을 공유하며, 아랍어로 듣는 사람이 없으면 아랍어로 번역되지 않습니다. 이것이 4개 언어 미팅이 40개 언어 미팅과 실제로 참여한 사람을 기준으로는 비용이 같은 이유입니다. 참가자가 듣지 않는 언어로는 절대 번역하지 않습니다.
• 합성 음성은 시청자별로 제공됩니다. 각 참가자는 원래 발화자의 비디오와 믹싱된 자신만의 번역된 오디오 트랙을 받습니다. 그들은 마스터 "번역된 미팅"을 보는 것이 아니라, 동일한 미팅을 보면서 자신의 개인 오디오 채널을 선택한 언어로 번역하여 듣는 것입니다. 이것이 같은 물리적 방에 있는 두 사람이 각각 헤드폰을 끼고 다른 언어를 들을 수 있는 이유입니다.

미팅에 문제가 생겼을 때 이것이 중요한 이유

8개 언어가 사용되는 60분 통화에서 문제는 흥미로운 방식으로 발생합니다: WebSocket이 끊기거나, ASR이 고유명사를 일시적으로 잘못 전사하거나, 한 참가자의 네트워크가 불안정해집니다. 위의 아키텍처는 우리가 장애를 격리할 수 있게 해줍니다. 번역 엔진은 처음부터 단일 "번역"을 생성한 것이 아니라 8개를 병렬로 생성했으며, 문제가 발생한 하나만 복구하면 되므로 한 시청자의 오디오 글리치가 다른 7명에게 영향을 주지 않습니다.

엔진 자체는 우리의 것이며, 자체 인프라에 호스팅됩니다. 실시간 음성을 제3자의 범용 LLM을 통해 라우팅하지 않습니다. 지연 시간 예산이 그것을 배제하고, 데이터 상주(data residency) 요구사항이 이를 실제로 중요하게 여기는 규제 대상 고객을 위해 그것을 배제합니다.

음성 품질에 대해 우리가 공개하는 것: /benchmark는 게시된 모든 언어 쌍에 대해 매월 FLORES-200 문장을 대상으로 프로덕션 음성 파이프라인을 실행합니다. 평가자는 명시됩니다(Gemini 3.7 Flash 주, Claude Sonnet 5 대체). 전체 분포(중앙값, p10, p90, 최소, 최대, 샘플 크기)가 페이지에 표시됩니다. 이러한 숫자가 측정하는 것과 측정하지 않는 것에 대해서는 방법론을 참조하십시오.

파이프라인 2: 실시간 채팅 번역

문제: 미팅의 모든 채팅 메시지가 전송되는 즉시 각 참가자의 언어로 번역됩니다. 여기에 편집이 더해지며, 편집은 재번역이 아닌 편집된 것처럼 보여야 합니다.

예산: 빠르지만 1초 미만은 아닙니다. 채팅 메시지가 다른 언어로 나타나는 데 0.5초가 걸려도 아무도 신경 쓰지 않습니다. 사람들이 신경 쓰는 것은 번역이 올바른지, 그리고 편집 내용이 말이 되는지입니다.

채팅 파이프라인이 실제로 수행하는 작업

각 메시지는 음성 파이프라인이 사용하는 것과 동일한 번역 엔진을 거치지만, 사전 및 사후 처리는 다르게 이루어집니다:

• HTML 구조가 유지됩니다. 채팅은 서식 있는 텍스트(단락, 목록, 인용, 볼드, 이탤릭)를 지원합니다. 모델을 위해 일반 텍스트로 변환하고, 번역한 다음, 결과를 원래 태그로 다시 감쌉니다. 모델은 HTML을 결코 보지 못하며, 깨끗한 산문만 봅니다.
• 인용은 독립적으로 번역됩니다. 메시지에 답장하며 인용할 경우, [QUOTE]…[/QUOTE] 블록과 새 내용은 별도의 단위로 번역되어 모델이 두 가지를 혼동하지 않도록 합니다.
• 긴 메시지는 청킹됩니다. 청크당 1,000자 단위로 단락 경계에서 분할합니다. 각 청크는 독립적인 번역 호출입니다. 4,000자짜리 소설을 한 번에 모델에 제공하지 않습니다. 실패 모드(잘림, 누락된 단락, 문장 중간 잘림)가 너무 지저분하기 때문입니다.
• 번역은 지연(lazy) 방식입니다. IntersectionObserver를 사용하여 메시지가 시청자의 뷰포트로 스크롤될 때만 번역됩니다. 장시간 실행되는 채널에서 언어를 전환하면 과거의 모든 번역 API 호출이 다시 실행되었습니다. 이제는 그렇지 않습니다.

흥미로운 부분: diff로서의 편집

v1.2에서 다른 언어를 사용하는 시청자에게 채팅 편집이 표시되는 방식을 변경했습니다. 이전 동작은 누군가 메시지를 편집하면 전체를 다시 번역하여 새 단락을 보여주고, 변경된 부분을 직접 찾아야 했습니다.

새로운 동작:

1. 원본 메시지는 이미 귀하의 언어로 번역되어 있었습니다.
2. 발신자가 편집하면 새 버전을 다시 번역합니다.
3. 귀하의 언어로 이전 번역과 새 번역 사이의 diff를 계산합니다.
4. Git이 변경된 사항을 보여주는 것과 동일한 방식으로 그 diff를 인라인으로 표시합니다.

따라서 영어로 "review by Tuesday"가 "review by Thursday"로 바뀌면, 스페인어를 읽는 동료는 다시 읽어야 하는 재번역된 단락 대신, martes → jueves가 강조 표시된 것을 보게 됩니다.

이를 위해서는 채팅 파이프라인을 요청 시 번역하는 무상태(stateless) 엔드포인트가 아닌, 시청자별 상태 저장(stateful) 캐시로 취급해야 했습니다. 문서와 음성에는 이것이 필요하지 않습니다. 채팅에는 필요합니다.

파이프라인 3: 실시간 공유 노트 번역

문제: 호스트가 공유 노트 창을 열고 타이핑을 시작합니다. 모든 참가자는 문서의 구조(제목, 중첩 목록, 체크리스트, 코드 블록)가 그대로 유지된 채 자신의 언어로 노트를 문자 단위로 보게 됩니다.

예산: 채팅과 동일(약 0.5초)하지만, 두 가지 추가 제약이 있습니다:

• 번역 대상이 번역 도중에 변경됩니다. 호스트가 여전히 타이핑을 하고 있습니다. 키 입력마다 "문서 전체"를 번역하는 단순한 시스템은 깜빡임을 유발하고 API 예산을 소진합니다. 우리는 문서 전체가 아닌 변경된 단위의 세분성으로 번역합니다.
• 구조가 살아남아야 합니다. 세 개의 중첩 목록이 있는 마크다운 덩어리를 번역 모델에 번역하도록 요청하면, 원본처럼 보이지만 계층이 미묘하게 평면화되거나, 항목 번호가 다시 매겨지거나, 들여쓰기가 이동된 결과를 받게 됩니다. 우리는 모델이 전체 덩어리를 보지 못하게 합니다.

노트 파이프라인이 채팅과 다른 점

구조 보존이 주요한 점입니다. 우리는 하나의 문서가 아닌 각 목록 항목을 독립적으로 번역합니다. 모델은 다음을 봅니다:

"컴플라이언스 리뷰 — Q2 산출물"

— 가 아닙니다:

"# 프로젝트 계획\n## 분기\n- 컴플라이언스 리뷰 — Q2 산출물\n- 벤더 평가\n - Tier 1 벤더..."

래핑 문서(<ul>, 제목, 들여쓰기)는 원본 문서와 동일한 구조를 사용하여 클라이언트 측에서 다시 작성되며, 각 리프 노드는 번역본으로 교체됩니다. 모델은 계층을 "개선"할 수 없습니다.

노트는 채팅 편집과 동일한 시청자별 diff 모델을 사용합니다. 호스트가 한 줄을 변경하면 다른 언어를 사용하는 시청자는 새로운 단락이 아닌 변경된 단어가 강조 표시된 것을 보게 됩니다.

파이프라인 4: 비동기 문서 번역

문제: 누군가 채팅에 40페이지짜리 PDF, Word 문서, PowerPoint 슬라이드 또는 Excel 시트를 드롭합니다. 각 참가자는 자신의 언어로 된 사본을 요청할 수 있습니다. 번역된 파일은 원본과 동일하게 보여야 합니다 — 동일한 글꼴, 동일한 표, 동일한 페이지 번호, 동일한 머리글, 동일한 자리의 동일한 차트.

예산: 실시간 제약이 없습니다. 1분이면 됩니다. 2분이어도 됩니다. 제약은 **충실도(fidelity)**입니다. 번역된 PDF가 원본처럼 보이지 않으면 수신자는 신뢰하지 않을 것입니다.

이 파이프라인이 음성과 엔진을 공유하지 않는 이유

범용 LLM은 아주 좋은 모델이라 할지라도 문서의 번역된 텍스트를 돌려줄 뿐입니다. 동일한 레이아웃으로 번역된 PDF를 돌려주지는 않습니다. 모델에게는 "원본과 일치해야 하는 페이지 나누기"나 "열 너비를 유지해야 하는 표 셀"이라는 개념이 없습니다.

이 영역에서는 DeepL Document API를 직접 사용합니다. 이는 파일에서 추출한 산문이 아닌 파일 자체로 번역하도록 특별히 구축되었습니다. DeepL은 다음을 처리합니다:

• PDF(레이아웃 보존 포함)
• DOCX, DOC
• PPTX
• XLSX

문서는 DeepL 파이프라인에 업로드되어 서식이 그대로 유지된 채 서버 측에서 번역되고, 동일한 형식으로 반환됩니다. 그런 다음 우리는 결과를 자체 오브젝트 스토리지에 업로드하고 다운로드 가능한 첨부 파일로 채팅에 다시 표시합니다.

이것의 비용과 숨기지 않는 이유

DeepL은 문서당 최소 50,000자를 청구합니다. 문서가 1페이지든 30페이지든 상관없이 Pro 등급에서 파일당 약 1달러입니다. 우리는 파일당 비용을 청구하는 대신 이 비용을 흡수합니다. 이는 미팅의 번역 사용량에 **청구된 문자(billed characters)**로 표시되며, 제품의 나머지 부분이 번역 활동을 보고하는 방식과 일치하는 워드 단위로 변환됩니다.

우리가 이 영역에 DeepL을 선택한 이유는 파일을 파일로 번역하는 것이 바로 이를 위해 구축된 작업이기 때문입니다. 더 나은 것을 만들려고 시도하지 않았습니다. 반대의 경우는 같지 않습니다. DeepL은 미팅을 위해 우리가 구축한 것과 같은 실시간 음성 파이프라인을 실행하지 않습니다. 다른 문제, 다른 도구입니다. "InterMIND 번역을 구동하는 것"에 대한 정직한 대답은 "어디서나 우리 엔진"이 아니라 "파이프라인마다 올바른 엔진"입니다.

음성 파이프라인이 지원하지 않지만 이 파이프라인이 지원하는 언어

문서 파이프라인은 30개 언어에 도달하며, 음성은 23개 언어입니다. 추가 언어에는 불가리아어, 그리스어, 에스토니아어, 인도네시아어, 리투아니아어, 라트비아어, 슬로바키아어, 슬로베니아어가 포함됩니다. (아랍어도 이 목록에 있으며 추가 언어 중 하나입니다. 음성 품질이 우리의 기준에 미달하는 동안 실시간 선택기에서 철회되었으며, 언어 쌍별 점수는 /benchmark에 공개로 유지됩니다. 이 숫자가 아랍어를 다시 가져오는 것입니다. 이러한 비대칭성은 힌디어에서 반대로 실행됩니다. 음성에서는 라이브이지만 파일에서는 아직 불가능합니다.)

이러한 비대칭성은 실재합니다. 이는 미팅의 프랑스어 참가자가 에스토니아어로 미팅을 들을 수는 없지만, 계약서 PDF를 에스토니아어로 요청할 수 있음을 의미합니다. 우리는 이를 단일 숫자로 덮지 않고 선택기에 명확히 표시합니다. 그 이유는 언어 수 게시물에 나와 있습니다.

파이프라인이 만나는 지점

4개의 파이프라인은 독립적으로 실행되지 않습니다. 미팅룸은 이들이 서로 맞닿는 곳이며, 이어지는 부분이 중요합니다:

• 문서 첨부 파일이 있는 채팅 메시지는 텍스트에 대해 채팅 파이프라인을, 파일에 대해 문서 파이프라인을 트리거합니다. 다른 언어를 사용하는 참가자는 메시지가 즉시 번역되는 것을 보고, 첨부 파일 번역은 비동기적으로 다운로드 가능한 형태로 도착하는 것을 봅니다.
• 전사 줄을 인용하는 공유 노트는 노트 ↔ 음성을 가로지릅니다. 전사본은 음성 파이프라인이 발신자 언어로 생성한 것이며, 노트 번역은 출처 표기를 유지하면서 다른 모든 사람의 언어로 해당 인용문의 시청자별 사본을 생성합니다.
• 미팅 후 내보낸 전사본은 전체 대화에 대해 채팅 방식의 텍스트 파이프라인을 실행하여 참가자가 다운로드할 수 있는 언어별 파일을 생성합니다. 이는 채팅 번역과 동일한 코드 경로이며 단지 배치 처리일 뿐입니다.

언어 선택기는 하나의 UI 조각입니다. 그 아래 인프라는 서로 대화하는 4개의 파이프라인입니다.

우리가 의도적으로 시도하지 않는 것

• "통합 번역 모델"은 없습니다. 우리는 음성, 채팅, 노트, 문서를 모두 처리하는 단일 모델을 구축하지 않습니다. 지연 시간과 충실도 사이의 트레이드오프에는 승자가 없습니다. 우리는 각 영역마다 올바른 엔진을 사용합니다.
• 조용한 재라우팅은 없습니다. 오늘 파일 파이프라인이 힌디어로 번역할 수 없다면, 음성 엔진으로 조용히 대체하여 작동된 척하지 않습니다. 파일 선택기는 이 간극을 숨기는 대신 표시합니다.
• "우리는 200개 언어로 번역합니다"라고 말하지 않습니다. 우리의 엔진은 24개를 내보냅니다. 라이브 서비스는 23개, 문서는 30개를 제공하며 — 마케팅에 친화적인 단일 숫자 대신, 감사관 앞에 서야 하는 언어 쌍별 품질이 /benchmark에 약한 쌍을 포함하여 게시됩니다.

직접 사용해 보기

• 라이브 데모 체험하기 — 23개 제품 언어 중 하나로 귀하의 오디오에 대해 라이브 음성 파이프라인을 실행합니다. /benchmark 점수를 기록한 것과 동일한 파이프라인입니다.
• 벤치마크 확인하기 — 실제 트래픽에 대한 언어 쌍별, 월별 품질. 선택기의 모든 쌍이 강하든 약하든 딥 링크가 가능합니다.
• 방법론 읽기 — 숫자가 무엇인지, 무엇이 아닌지, 평가자가 누구인지 확인하세요.

4개의 파이프라인, 4개의 엔진, 하나의 미팅룸. 이것이 이전 how-it-works 페이지를 대체하는 정직한 답변입니다.

— Mind.com 팀

출처: DeepL — 지원 언어, DeepL — 사용량 및 청구(파일당 50,000자 최소 요금), FLORES-200; 내부 파이프라인 사실은 배포된 코드를 기준으로 확인되었으며, 2026년 8월에 검증되었습니다.