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

mind.com의 기존 /product/overview/how-it-works 페이지는 몇 차례의 주요 릴리스가 지날 만큼 구버전입니다. 이 페이지는 대부분의 공급업체 페이지가 그렇듯 "당신이 말하면"에서 "그들이 듣는다"로 이어지는 하나의 커다란 화살표로 단일 "번역 엔진"을 설명합니다. 그러한 그림은 2년 전에만 해도 단순화된 형태였지만, 오늘날에는 틀린 설명입니다.

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

이것이 "어떻게 작동하는가"에 대한 업데이트된 답변입니다.

관련 글: "몇 개의 언어를 지원하나요?"는 각 파이프라인이 다루는 범위(24 / 24 / 30 / 17)를 다룹니다. 이 글은 각 파이프라인이 수행하는 작업과 그것이 왜 독자적인 구성을 갖추고 있는지를 설명합니다.

"모든 것을 위한 단일 엔진"이 거짓인 이유

실시간 회의 플랫폼은 한 번에 최소 네 가지 작업을 동시에 수행해야 하며, 이들은 양립할 수 없는 방향으로 서로를 끌어당깁니다:

1. 실시간 음성 — 1초 미만의 시간 안에 오디오를 입력받아 번역된 오디오를 출력하며, 모든 참여자는 각자의 언어를 듣습니다. 가장 엄격한 제약 조건은 지연 시간입니다.
2. 실시간 채팅 텍스트 — 짧은 메시지, 빠른 속도, 편집 및 인용, HTML 구조 유지.
3. 실시간 공유 노트 — 글자 단위의 협업 타이핑, 번역 후에도 유지되어야 하는 구조적 계층(목록, 제목, 체크박스).
4. 비동기 문서 파일 — 채팅에 드롭된 40페이지 분량의 PDF. 지연 시간 예산이 없습니다. 가장 엄격한 제약 조건은 서식, 표, 페이지 번호, 글꼴이 정확히 유지되는 *일치도(fidelity)*입니다.

이 네 가지를 모두 처리하려는 거대한 LLM 호출 하나를 구축할 수도 있습니다. 저희도 시도했습니다. 그 결과 네 가지 모두에서 성능이 좋지 않았습니다. 음성의 지연 시간 예산은 모델이 '생각'할 수 없게 만들지만, 문서의 일치도 예산은 모델이 '생각'해야 함을 의미합니다. 채팅 편집은 시청자 언어로 표시된 diff를 필요로 하며, 40페이지짜리 PDF는 토큰 스트리밍 모델이 제공하지 않는 서식 보존을 필요로 합니다.

그래서 저희는 네 가지를 실행합니다. 각각에 대한 설명은 다음과 같습니다.

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

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

예산: 종단 간 1초 미만. 약 1.2초가 넘어가면 대화가 끊기고, 사람들이 번역이 끝나기 전에 말을 시작하며, 회의는 "그냥 영어로 바꾸죠"라는 방향으로 흘러갑니다.

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

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

• ASR은 연설자의 브라우저에서 실행되며, 중앙 서버에서 실행되지 않습니다. 저희는 Mind SDK를 로컬에서 사용합니다. 이는 왕복 시간을 절약하고 번역이 시작되기 전에 가능한 가장 낮은 지연 시간으로 원본 언어 전사본을 제공합니다.
• 번역은 단일 팬아웃(fan-out)이 아닙니다. 저희는 번역 엔진에 대한 WebSocket 연결 풀을 유지하며, 회의실에 있는 각 대상 언어당 하나씩 연결됩니다. 세 명의 참가자가 독일어를 선택했다면 독일어는 하나의 연결을 공유합니다. 아무도 아랍어를 선택하지 않았다면 아랍어 연결은 열리지 않습니다. 연결 풀은 5분 후 유휴 연결을 삭제합니다. 따라서 4개 언어 회의와 40개 언어 회의는 실제로 참가한 사람을 기준으로 동일한 비용이 듭니다. 어떤 참가자도 듣지 않는 언어로는 번역을 수행하지 않기 때문입니다.
• 합성 음성은 시청자별로 제공됩니다. 각 참가자는 원래 연설자의 비디오와 믹싱된 자신만의 번역된 오디오 트랙을 수신합니다. 그들은 마스터 "번역된 회의"를 보는 것이 아니라, 자신의 오디오 채널이 선택한 언어로 번역된 동일한 회의를 보는 것입니다. 같은 물리적 공간에 있는 두 사람이 각각 헤드폰을 꽂고 다른 언어를 들을 수 있는 이유이기도 합니다.

회의에 문제가 생겼을 때 이것이 중요한 이유

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

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

음성 품질에 대해 저희가 공개하는 내용: /benchmark는 매월 게시된 모든 언어 쌍에 대해 프로덕션 음성 파이프라인을 FLORES-200 문장과 대조하여 실행합니다. 평가자는 명시되어 있습니다(주 평가자: Gemini 2.5 Flash, 보조 평가자: Claude Sonnet 4). 전체 분포(중앙값, p10, p90, 최소값, 최대값, 샘플 크기)가 페이지에 표시됩니다. 해당 수치가 측정하는 것과 측정하지 않는 것에 대해서는 방법론을 참조하세요.

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

문제: 회의의 모든 채팅 메시지는 전송되는 즉시 모든 참가자의 언어로 번역됩니다. 편집 역시 마찬가지이며, 편집은 재번역이 아닌 편집으로 보여야 합니다.

예산: 빠르지만 1초 미만이 필요하지는 않습니다. 채팅 메시지가 다른 언어로 표시되는 데 0.5초가 걸려도 아무도 신경 쓰지 않습니다. 사람들이 신경 쓰는 것은 번역이 정확한지, 그리고 편집 내용이 제대로 반영되는지입니다.

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

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

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

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

v1.2에서 저희는 다른 언어를 사용하는 시청자에게 채팅 편집이 표시되는 방식을 변경했습니다. 이전에는 누군가 메시지를 편집하면 전체를 다시 번역하여 새 단락이 표시되었고, 사용자는 무엇이 변경되었는지 찾아내야 했습니다.

새로운 방식은 다음과 같습니다:

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

따라서 영어로 "review by Tuesday"가 "review by Thursday"로 변경되면, 스페인어를 읽는 동료는 다시 읽어야 하는 재번역된 단락이 아니라 강조 표시된 martes → jueves를 보게 됩니다.

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

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

문제: 호스트가 공유 노트 창을 열고 입력을 시작합니다. 모든 참가자는 글자 단위로 문서의 구조(제목, 중첩 목록, 체크리스트, 코드 블록)가 손상되지 않은 채 자신의 언어로 노트를 봅니다.

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

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

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

구조 유지가 가장 중요합니다. 저희는 하나의 문서로 묶어서 번역하는 대신 각 목록 항목을 독립적으로 번역합니다. 모델이 보는 것은 다음과 같습니다:

"컴플라이언스 검토 — Q2 산출물"

— 다음이 아닙니다:

"# 프로젝트 계획\n## 분기\n- 컴플라이언스 검토 — Q2 산출물\n- 공급업체 평가\n - 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이 구축된 목적이기 때문입니다. 더 나은 것을 직접 구축하려 하지 않았습니다. 반대의 경우는 성립하지 않습니다. DeepL은 저희가 회의를 위해 구축한 것과 같은 실시간 음성 파이프라인을 실행하지 않습니다. 다른 문제에는 다른 도구가 필요합니다. "InterMIND 번역을 구동하는 것"에 대한 정직한 답변은 "어디서나 우리의 엔진"이 아니라 "파이프라인마다 적합한 엔진"입니다.

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

문서 파이프라인은 30개 언어를 지원하며, 음성은 24개 언어를 지원합니다. 추가로 지원되는 언어에는 불가리아어, 그리스어, 에스토니아어, 인도네시아어, 리투아니아어, 라트비아어, 슬로바키아어, 슬로베니아어가 포함됩니다. (과거에는 아랍어 음성 품질이 저희 기준에 미치지 못해 이 목록에 포함되어 있었습니다. 현재는 다른 모든 언어와 마찬가지로 실시간 선택기에서 지원되며 언어 쌍별 점수가 /benchmark에 공개되어 있습니다. 이제 힌디어의 경우 비대칭성이 반대 방향으로 나타납니다. 음성에서는 실시간 지원되지만 파일에서는 아직 지원되지 않습니다.)

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

파이프라인이 만나는 지점

네 개의 파이프라인은 독립적으로 실행되지 않습니다. 회의실은 이들이 서로 맞닿는 곳이며, 그 연결점이 중요합니다:

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

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

의도적으로 시도하지 않는 것

• "통합 번역 모델"은 없습니다. 저희는 음성, 채팅, 노트 및 문서를 모두 처리하는 단일 모델을 구축하지 않습니다. 지연 시간과 일치도 간의 트레이드오프에는 승자가 없습니다. 저희는 각 영역에 적합한 엔진을 사용합니다.
• 조용한 재라우팅은 없습니다. 오늘 파일 파이프라인이 힌디어로 번역할 수 없는 경우, 조용히 음성 엔진으로 대체하고 작동하는 척하지 않습니다. 파일 선택기는 격차를 숨기는 대신 명확히 표시합니다.
• "200개 언어로 번역합니다"라는 말은 없습니다. 저희 엔진은 24개 언어를 출력합니다. 실시간 표면은 24개, 문서는 30개 언어를 제공하며, 마케팅 친화적인 단일 숫자 대신 감사자 앞에 내놓아야 하는 언어 쌍별 품질(약한 쌍 포함)이 /benchmark에 공개되어 있습니다.

직접 사용해 보기

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

네 개의 파이프라인, 네 개의 엔진, 하나의 회의실. 이것이 기존 how-it-works 페이지를 대체하는 정직한 답변입니다.

— Mind.com 팀

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