최근 HTMX 문서 번역을 완료하였고(https://htmx.pinstella.com), 지금은 문서 번역 과정에서 어느 정도의 자동화를 도입하고 싶어 연구를 하고 있습니다. 개발 문서 번역이 가지는 의미가 무엇일지, 현재 개발 문서 번역의 한계는 무엇인지 정리하고 싶어 이 글을 작성하게 되었습니다.
이 글이 블로그의 첫 글인 이유는;; 원래 쓰고 있던 글들이 마무리가 안 됐습니다ㅜ
개발 문서 번역의 종류
개발 문서라 하면 프로그래밍 언어의 reference, 라이브러리와 프레임워크의 quick start가 기본적으로 포함될 것입니다. 그러나 저는 이 글에서 의미하는 개발 문서는 개발에 도움을 주는 코드가 포함된 책들도 포괄한다고 정의하겠습니다.
확장된 정의를 바탕으로 개발 문서를 분류해보겠습니다.
- 정적인 문서(책, 관리자가 사망?한 프로젝트의 문서, 공식적인 지원이 중단된 프로젝트의 문서)
- 동적인 문서(현재 관리가 이루어지고 있는 프로젝트의 문서)
이렇게 분류를 한 이유는 당연히 번역 때문입니다. 정적인 문서는 더 이상 업데이트가 이루어지지 않습니다. ISBN이 같은 책은 (오탈자를 제외하고) 모두 언제나 같다고 할 수 있습니다. 책의 경우 개정판이 출판된다고 해도, 그 개정판은 개정 이전 책과 다른 독립적인 책입니다. 그렇기에 정적인 문서는 한 번 번역하면 그걸로 끝이라고 할 수 있습니다. 여기서 의미하는 번역은, 번역의 수요자가 충분히 만족할 수 있는 번역이라고 가정하겠습니다. 의미와 맥락이 명확하게 전달되며, 오류나 누락된 항목이 없는 번역을 의미합니다. 정적인 문서에 이런 번역이 가능하기만 하다면 번역물도 정적인 문서가 될 것입니다. 이미 번역이 완벽하기에 번역에 수정을 가할 필요가 없는 것이죠.
하지만 동적인 문서는 다릅니다. 동적인 문서는 꾸준히 변화하는 프로젝트에 기반을 두고 있습니다. 프로젝트의 기여자들이 대체로 적극적이라면 새로운 기능이 계속 추가됩니다. 설령 프로젝트의 기여자들이 소극적으로 프로젝트에 수정을 가해도 보안 이슈나 안정성 이슈가 계속 튀어나오는 동안 프로젝트의 코드는 변화할 수 밖에 없습니다. 프로젝트가 변화하면 문서 또한 변경될 가능성이 높아집니다. 새로운 항목을 추가하거나, 기존 항목에 예시를 추가하거나, 혹은 기존 항목이 삭제될 수 있습니다. 동적인 문서를 완벽하게 번역해도, 그 번역은 번역을 할 당시의 문서를 번역했다는 의의 밖에 가질 것이 없습니다.
동적인 문서가 번역되고 난 후 원본 문서가 변경된다면
 |
| 번역 희망편 |
 |
| 번역 절망편 |
일단 어떤 프로젝트의 문서를 완전히 번역했다고 할 수 있으려면 문서의 변화를 계속 따라잡아야(follow up) 합니다. 만약 그렇지 않다면, 그 번역은 그냥 번역할 당시의 버전을 번역한 것에 불과합니다. 그래서 동적인 문서를 완전히 번역하는 것은 현실적으로 힘든 편입니다. 프로젝트 기여자들이 전업으로 프로젝트 작업을 하는 경우라면 프로젝트에 변경 사항이 생길 때마다 문서에 바로바로 반영할 수 있을 것입니다. 큰 규모의 프로젝트라면 전업 개발자가 보통 존재하기 때문에, 찾기 어렵지 않습니다. 그러나 번역가는 큰 규모의 프로젝트라도 전업으로 활동하기 힘듭니다. 이미 쓰여진 문서를 번역 하는 것에서 오는 수입은 문서를 새로 쓸 때 오는 수입보다 확실히 적을 것이기 때문이죠. 다양한 문서를 생성하는 빅테크 기업의 전업 번역가나, 번역 전문 업체의 번역가들이 존재하지만, 이들이 작업하는 문서는 소수에 불과합니다.
만약 특정 버전일 때 번역을 해둔 뒤 그대로 방치하다가 원래 문서가 변경된다면, 위에 보이는 사진처럼 오히려 보기 안 좋게 됩니다. (제가 프로젝트를 번역할 때 저장소를 통째로 클론하여 번역하는 이유이죠.) 한국어 번역이 있다고 해서 보았는데 중요한 변경 사항이 번역되지 않아서 중요한 사항을 놓치는 경우가 비현실적이지 않습니다.
번역을 할 때 중요한 것
- 자신이 무엇을 번역하는지 잘 알아야 합니다. 파이썬을 써본 적이 없으면서 FastAPI 문서를 번역하는 것은 불가능합니다.
- 영어를 잘 알아야 합니다. 글을 해석하지 못한 상태에서 글을 번역하는 것은 불가능합니다. 물론 문서에 사용된 모든 단어를 100% 알아야 하는 것은 아닙니다. 하지만 문장을 이해하는데 필요한 영어 전치사나 문장 구조는 확실히 알아야 할 필요가 있습니다.
- 한국어를 잘 알아야 합니다. 영어를 잘 한다고 바로 직독직해한 걸로 번역하는 것은, 최선의 번역을 얻는 방법과 거리가 있습니다. 때로는 한국어 상황에 맞추어 초월번역도 할 수 있어야 합니다. 오랜 기간 기술 분야만 집중하다보면, 기초적인 한국어 문법 실수도 발생하기 쉽습니다. 이 또한 번역 과정에서 염두에 두어야 합니다. 또 용어 선정에는 신중하게 접근해야 합니다.
단어 번역
특정 단어를 어떻게 번역할 것인가로 논쟁이 벌어지는 것을 자주 목격할 수 있습니다. 특히
철학에서 매우 심한데, 개발 분야라고 크게 안 심한 게 아닙니다. 그렇기에 단어 번역에 대한 개인적인 입장을 밝히는 것이 조심스럽지만, 현재 개발 문서 번역에서는 외래어가 지나치게 많이 사용된다고 보고 있습니다. 엘리먼트일지 요소일지, 오버라이드일지 재정의일지는 충분한 합의가 필요할 것입니다. 다만 저는 완전한 고유명사가 아니라면 음역을 지양해야 한다고 생각합니다.
추천 자료:
https://easyword.kr/why https://terms.tta.or.kr/main.do
번역은 양인가 질인가
번역을 대량 생산하는 곳이 있는가 하면, 신중을 다해서 번역을 하는 곳도 있습니다. 좋은 번역을 양산하는 것이 가장 좋겠지만, 일단
틀리게 번역하지만 않았다면 두 경우 모두 지적하기 어렵습니다. 이 질문은 접근성을 높이느냐 오류를 최소화하느냐라는 질문으로 환원될 수 있습니다. 다만 전문성이 매우 중요하고 고난도 기술이 포함되는 문서의 경우 오류를 최소화해야 잘못된 해석이 생기는 것을 방지할 수 있을 것입니다(이는 원본 문서를 작성할 때도 해당됩니다. 복잡한 기술일 수록 신중하게 기술되어야 합니다).
개인적으로 생각하는 번역에 최적화된 웹 페이지와 부속 시스템
남의 프로젝트를 번역하는 것에 대해 계속 이야기했는데, 이번에는 자신의, 자신이 소속된 프로젝트가 잘 번역되려면 어떻게 해야 할지 생각해보겠습니다. 개발 문서는 일반적으로 웹 페이지에서 접근할 수 있으며 웹 페이지는 다양한 텍스트를 포함하기 때문에, 더 넓은 범위에서의 번역을 생각하기 위해 웹 페이지를 번역하는 것으로 생각해보겠습니다. 웹 페이지 번역은 문서를 작성할 때 자주 쓰이는 마크다운보다 번역하기 더 어렵습니다. 번역되면 안 되는 태그 속성과 번역이 되어야 하는 태그 속성이 공존하기 때문이죠. 반대로 웹 페이지를 잘 번역할 수 있는 시스템이 갖추어진다는 것은 마크다운 기반 시스템은 더 쉽게 구축할 수 있다는 의미가 됩니다.
본인의 웹 페이지가 번역에 최적화되기 위해서는 번역을 하기 좋은 텍스트와 번역을 하기 좋은 환경이 필요하다고 생각합니다. 이 중에서 환경적인 면에서 웹 페이지를 번역되기 좋게 만들기 위해서는 2가지 시스템을 고려할 수 있을 듯 합니다. (순전히 블로그 주인의 제안임)
GIT스러운 템플릿 기반 방법
- 개발자 웹 페이지를 번역 도우미 프로그램에 등록합니다. 번역 도우미 프로그램은 웹 서비스를 호스팅하는 서버에서 작동하는 것이 가장 좋습니다.
- 번역 도우미 프로그램은 웹 페이지에서 텍스트만 추출하여 데이터베이스에 저장합니다.
- 번역자는 데이터베이스에 접근하여 새 번역을 추가합니다.
- 클라이언트에게는 템플릿 엔진을 통해 (번역)페이지를 만들어 전달합니다.
- 웹 페이지가 업데이트되면 번역 도우미 프로그램은 변경 사항을 기존 데이터베이스 데이터와 병합합니다.
- 번역자는 병합 내역을 바탕으로 번역을 수정합니다.
이때 중요한 것은 HTML 태그입니다. 태그 중 웹 접근성과 관련된 항목은 번역되어야 합니다. 하지만 그러다가 자칫 class나 id를 번역해버린다면?
직접 수정 방법
- 개발자는 웹 페이지를 만듭니다.
- 번역자는 웹 페이지를 보면서 웹 페이지를 수정할 수 있는 WYSIWYG 기반 에디터를 사용하여 번역을 수행합니다.
- 번역을 완료한 페이지는 저장소에 등록하거나 개발자에게 전달합니다. 그 후 번역 페이지 호스팅을 시작합니다.
일반적이고 가볍지만, 자주 번경되는 웹 페이지에는 적합하지 않습니다. 또 WYSIWYG 기반 에디터는 번역되어야 하는 태그 속성도 같이 보여주고 편집할 수 있게 해야 합니다.
번역하기 좋은 텍스트를 작성하는 방법은 너무 원론적입니다. 책을 열심히 읽고, 글을 많이 써보고, 좋은 글을 분석해보는 것. 그래도 글 쓰는 것에 익숙해지기 시작하면, 좋은 텍스트를 많이 써낼 수 있기에 날먹할 수 있다고 생각합니다.
번역을 왜 하는데?
그럼 기술 번역을 왜 하는 가에 대한 근본적인 질문을 생각해보며 글을 마무리하겠습니다. 대형 프로젝트의 경우 대다수의 개발 문서는 영어로 작성됩니다. 회사 내에서 돌려보는 정도에 그치지 않고, 전 세계에 공개적으로 배포하고 유지보수하는 프로그램은 영어로 작성되는 것이 타당합니다. 그럼 영어를 잘 배우면 정답인가? 정답입니다..
위 대답은 지금까지 논의한 번역을 다 의미 없게 만들어버린다고 보일 수도 있습니다. 그러나 위 대답과 문서 번역은 상충되지 않습니다.
훌륭한 개발자가 되기 위해서는 영어 문서를 읽을 수 있어야 합니다. 그러나 개발자가 되기 위해서는 토익, 토플, 탭스, 플렉스, 듀오링고 점수가 필요한 것이 아닙니다. 컴퓨터 시스템에 대한 흥미를 바탕으로 소프트웨어를 구현할 수 있는 역량을 갖추고 있다면 누구나 소프트웨어 개발자가 될 수 있다고 생각합니다. 이들에게는 진입의 좌절을 안겨주지 않으려면 번역이 꼭 필요하다고 생각합니다. 더 넓은 관점에서 보면, 영어 소양을 갖추기 어려운 배경의 사람들에게 도움을 주는 기여라고 생각할 수 있습니다. 실제로 천병희 번역가님 작품을 보면 좋은 번역은 공리 증진에 도움이 된다는 것을 느낄 수 있습니다.
필수적으로 사용되고, 기반이 되는 기술의 문서는 많이 번역할 수록 좋은 것이라고 생각합니다. 하지만 번역가에게 주어진 시간은 제한적입니다. 광범위하고 꾸준한 번역을 이루기 위해서는 결국 새로운 방법이 필요하다고 생각합니다.
댓글
댓글 쓰기