AI 번역의 진짜 난제는 문장이 아니라 레이아웃이다

문장을 다른 언어로 바꾸는 일은 쉬워졌다. 하지만 표와 수식, 제목 계층, 페이지 구조를 유지한 채 다시 내보내는 일은 여전히 제품 문제다.

TL;DR

PDF 번역의 실패는 오역보다 문서 구조가 무너질 때 먼저 드러난다.
문서 도구는 텍스트 추출기가 아니라 구조를 보존하는 변환기여야 한다.
첫 MVP는 모든 문서를 지원하기보다 표·수식·2단 레이아웃 등 검증 가능한 범위를 약속해야 한다.

왜 지금 중요한가

생성 AI는 문장 번역의 진입장벽을 낮췄다. 이제 사용자는 “번역할 수 있나?”보다 “번역된 파일을 바로 업무에 쓸 수 있나?”를 묻는다. 업무 문서에서는 번역문이 자연스러운 것만으로 부족하다. 제목과 본문의 관계, 표의 행과 열, 수식과 특수문자의 위치가 결과물의 사용성을 결정한다.

핵심 흐름

문서를 번역하는 파이프라인은 다음처럼 나뉜다.

페이지에서 텍스트·표·도형·수식의 위치와 관계를 추출한다.
구조를 잃지 않는 중간 표현으로 변환한다.
의미 단위로 번역하되 표 셀과 제목 계층의 경계를 보존한다.
원래 페이지의 흐름에 맞춰 다시 렌더링한다.
원본과 결과를 비교해 겹침·누락·잘림을 검사한다.

여기서 언어 모델은 3번의 일부일 뿐이다. 나머지는 문서 파싱, 레이아웃 엔진, 렌더링, 검증의 문제다.

실제 사례에서 본 신호

GeekNews에 소개된 문서 단위 번역 도구는 텍스트만 번역하면 표가 뒤섞이고 제목 관계가 사라지는 문제를 개발 동기로 제시한다. 이 사례는 “번역 품질”을 문장 평가로만 보면 실제 사용 실패를 놓친다는 점을 보여준다.

비슷하게 브라우저에서 동작하는 3D 슬라이서는 복잡한 파일 처리를 서버 없이 실행하는 방향을 보여준다. 문서 처리에서도 입력 파일을 업로드하지 않고 로컬 또는 브라우저에서 처리할 수 있다면 개인정보와 신뢰 문제를 동시에 줄일 수 있다.

실전 활용 팁: 결과 파일을 먼저 정의하라

도구를 만들 때 “PDF를 번역한다”고 쓰면 범위가 끝없이 커진다. 대신 다음처럼 출력 계약을 정한다.

입력: 텍스트 기반 PDF, 최대 20페이지
보존: 제목 계층, 표, 페이지 수, 각주 위치
제외: 스캔 OCR, 복잡한 수식, 손글씨
결과: 번역 PDF와 페이지별 검증 리포트

이렇게 하면 모델 품질과 렌더링 품질을 분리해 측정할 수 있다.

바로 해볼 실험

표·2단 레이아웃·수식·각주가 섞인 PDF 10개를 준비한다. 번역 결과를 문장 정확도와 구조 보존으로 나눠 평가한다. 구조 보존 평가는 표 누락, 텍스트 겹침, 잘림, 제목 계층 유지 여부를 체크리스트로 기록한다.

첫 버전은 웹 업로드 없이 브라우저에서 처리하는 흐름을 우선하고, 지원하지 않는 문서는 명확히 거절한다. 지원 범위를 좁히는 것이 “무엇이든 번역”보다 신뢰를 만든다.

리스크와 반론

레이아웃 보존은 문서 형식마다 난도가 크게 다르다. PDF가 원래부터 이미지 기반이면 OCR 오류가 구조 오류로 이어질 수 있다. 또한 자동 비교가 통과해도 사람이 읽기에 어색한 번역은 남을 수 있다. 따라서 자동 검증은 사람 검토를 없애는 장치가 아니라 검토 대상을 줄이는 장치로 설명해야 한다.

결론

AI 문서 도구의 다음 경쟁은 더 유창한 문장을 만드는 데만 있지 않다. 사용자가 원본 파일을 다시 열었을 때 구조가 살아 있고, 무엇이 보존됐는지 확인할 수 있게 만드는 데 있다. 번역의 단위를 문장이 아니라 사용 가능한 문서로 바꾸는 순간, 작은 유틸도 분명한 제품이 된다.

이번 주에 번역해 볼 문서에서 가장 먼저 보존해야 할 구조는 무엇인가?