파이썬 공식 문서 한국어 번역의 과제는 크게 세 가지로 압축할 수 있다.
- 100% 완역에 도달하기
- 끊임없는 변경에 지속적으로 대응하기
- 번역의 품질 향상하기
앞선 두 가지는 양적인 문제고, 마지막은 질적인 문제다. 하지만 양적이든 질적이든 막대한 리소스가 필요하다는 사실은 다르지 않으며, 현재 기여 리소스가 부족하다는 점을 인정할 수밖에 없다. 파이썬 공식 문서의 번역 대상 분량은 공백을 포함해 1,000만 자가 살짝 넘는다. 1,000만 자라고 하면 감이 잘 오지 않을 것이다. 박경리 작가의 소설 《토지》(전 20권)와 조정래 작가의 소설 《태백산맥》(전 10권)의 분량을 모두 합친 것에 달한다. 게다가 이것이 끝이 아니다. 파이썬 공식 문서는 지금 이 순간에도 끊임없이 업데이트되고 있다.
과거에 오래된 ‘What’s New’ 문서 일부만 제외하고 전체 번역률을 80%까지 끌어올린 적이 있었다. 하지만 번역 작업에 다소 지쳐 몇 년 동안 손을 놓았더니, 그사이 누적된 원문 업데이트로 인해 번역률이 40%대까지 떨어지고 말았다. 원문의 글자 하나만 달라져도 기존 번역문 전체가 무효화되어 변경 사항이 누적·증폭되는 gettext/po 포맷 특유의 영향도 있지만, 어쨌든 그만큼 원문이 부지런히 수정되고 있다는 의미다. 과거 파이썬 커뮤니티의 힘을 모아 번역 리소스를 다각도로 조달해 보자는 움직임도 있었으나, 안타깝게도 지속적이고 가시적인 성과로 이어지지는 못했다. 당시 내심 기대했던 ’인해전술’은 실현되지 않았고 소식도 뜸해졌다. 이제는 다른 패러다임으로 접근해야 할 때다.
라이브 번역
기여자들이 마주하는 진입 장벽을 근본적으로 제거할 수 없을까?
현재 방식대로 파이썬 문서 번역에 기여하려면 다음과 같은 준비가 필요하다.
- GitHub 저장소를 포크(fork)하고 PR(Pull Request)을 보낼 수 있어야 한다.
- 로컬 환경에서 전문 편집기로
.po파일을 다룰 수 있어야 한다. - Sphinx 문서 표준인 reStructuredText(RST)의 기초 지식이 있어야 한다.
- 직접 빌드 테스트를 수행하여 수정본이 웹 화면에 올바르게 렌더링되는지 검사할 수 있어야 한다.
기여를 돕기 위해 PDK(CLI 도구)나 Dev Container 환경을 지원하며 장벽을 낮추려고 노력해 보았지만, 개발 도구에 익숙하지 않은 일반 기여자에게는 여전히 번거롭고 높은 벽이다. GitHub 이슈를 통한 관리를 위해 파일 단위의 기여를 요구하는 구조 역시 기여를 어렵게 만드는 요소다. 단지 한두 문장을 고치고 싶을 뿐인데도, 컴퓨터 앞에 각을 잡고 개발 도구를 켜서 달려들어야 하기 때문이다.
만약 문서 웹 페이지에 곧바로 편집기를 붙인다면 어떨까? 이때 다음과 같은 매끄러운 기여 시나리오가 가능해진다.
- 웹 브라우저로 렌더링된 문서를 읽다 보니 다소 어색한 문장이 눈에 띈다.
- 해당 문단에 마우스를 올리니(Hover) 문단 끝에 작은 편집 버튼이 표시된다.
- 버튼을 클릭하자 화면 우측에서 슬라이드 패널 편집창이 나타나며 원문과 번역문을 나란히 대조해 보여준다.
- RST 문법은 잘 모르지만, 대조해서 읽어보니 어디를 고치면 번역이 자연스러워질지 눈에 보인다.
- 편집 창에서 번역문을 가볍게 다듬어 ‘등록’ 버튼을 누른다.
- 잠시 후 서버 빌드 자동 테스트를 거쳐 웹 문서가 새 번역으로 업데이트된다.
이 기여 흐름은 기여자가 웹 브라우저 창을 전혀 떠나지 않고 번역을 제안할 수 있도록 설계되었다. GitHub 계정, git 사용법, VS Code 설치, .po 파일 포맷 정리, 빌드 테스트, 화면 렌더링 테스트… 복잡한 모든 과정이 기여자 입장에서 완전히 생략된다.
이 아이디어를 토대로 구축한 파이썬 한국어 번역 플랫폼의 이름이 바로 ‘에디토리얼(Editorial)’이다. 현재 python.flowdas.com에서 에디토리얼 테마가 적용된 파이썬 공식 설명서 웹 서비스를 체험할 수 있다. 첫 페이지는 기술적인 문제로 (아직은) 편집할 수 없다. 본문 페이지로 이동해야 각 문단에 편집 버튼이 표시된다. 화면 우측에 마련된 ’번역 편집’ 탭을 직접 열어 전체 번역 진행률과 기여 현황을 둘러볼 수도 있다.
그렇다면, 이 라이브 편집 기능만으로 번역 과제가 완벽하게 해결될까? 당연히 그렇지 않다. 진입 장벽이 획기적으로 낮아진 만큼 더 많은 참여를 유도할 수는 있을 것이다. 하지만 이 플랫폼은 근본적으로 ‘작고 소소한 기여’를 기반으로 한다. 참여자들이 평균적으로 각자 200자 원고지 한 장 분량만 기여한다고 가정해 보자. 그렇다면 문서 전체를 한 차례 번역하기 위해서만 5만 명의 인원이 참여해야 한다. 게다가 매년 발생하는 공식 문서의 수정 사항을 지속해서 반영하려면 매년 추가로 1만 명이 유지되어야 한다. 현실적으로 파이썬 한글화 커뮤니티에서 감당하기 어려운 규모의 숫자다. 평균 기여의 절대량이 얼마나 될지 예단하기는 어렵지만, 이 ’라이브 번역’ 단독 기여 모델만으로 100% 완역을 달성할 수 있다고 낙관할 수는 없다. 스팀팩이 필요하다.
사람이 지도하는 AI 번역
단조롭고 거대한 번역 작업의 대부분은 AI에 위임하고, 사람은 오직 핵심적인 작업에만 집중하자.1 여기서 사람이 수행할 가장 중요한 역할은 세 번째 과제인 ‘품질 향상’이다.
물론 AI의 번역 품질은 기술의 발전과 함께 계속 올라갈 것이다. 하지만 당장의 현실적인 비용 제약 속에서 선택 가능한 AI 모델의 번역 수준은 기술 용어 해석이나 Sphinx 문법 결합 등에서 아직 완벽과는 거리가 멀다. 그래서 사람은 번역의 교정을 통해 품질 향상에 기여해야 한다. 모두 교정하겠다는 각오로 임하겠지만, 앞서 언급했듯이 문서의 막대한 규모는 교정 작업에서도 여전히 거대한 장벽이다. 따라서 번역의 품질 평가를 수행하여 교정 작업의 우선 순위를 결정할 수 있어야 하고, 이 평가 작업도 AI가 수행해야 한다.
결국 한정된 인간의 리소스는 일부 중요하고 결함이 높은 문서에 집중될 수밖에 없다. 주로 다음 두 가지 카테고리를 중점적으로 검토하게 된다.
- 많이 읽히는 페이지
- 품질 평가에서 낮은 점수를 받은 문제의 문장들
우선 순위가 있어도 전부 교정해야만 한다면 결국 들어가는 리소스의 총량은 같다. 대신 AI는 사람이 남겨준 고품질 교정 데이터를 적극적으로 학습해야 한다. 학습의 결과 필요하다고 판단되면 재번역해야 한다.2 인간 기여자가 가장 형편없는 10%를 다듬어 주면, AI가 이를 학습하여 나머지 90% 영역에 이를 자동으로 확대 적용해 주기를 기대하는 모델이다. 10%를 교정할 리소스도 없다면, 1%를 교정하고, AI가 99%를 재번역 하라고 하자. 최소 교정비율은 AI가 개선됨에 따라, 학습 데이터가 누적됨에 따라 점점 개선될 것이다.
이 ‘사람이 지도하는 AI 번역’ 전략은 세가지 과제를 모두 완수할 잠재력을 갖고 있다. 이 시스템은 크게 세 가지 축으로 회전한다.
- AI 초안 번역 & 사람의 웹 라이브 교정
- AI 자동 품질 검증 & 우선순위 큐잉
- 인간 피드백 연동 자가 학습 및 재번역
에디토리얼(Editorial)의 백엔드는 이 전략의 구현체다.
아직은 첫걸음 단계이지만, 한걸음씩 나아가다보면 어딘가 도착하지 않겠나.