번역 협업 뒷이야기

* 이 글은 2017년 10월 14일 '초급 소프트웨어 개발자 생존전략 번역 협업 뒷이야기'란 제목으로 발행했으나 이후 다른 글 번역 노하우도 덧붙이면서 제목도 변경합니다.

ThoughtWorks 블로그를 최근에 발견한 것은 아니지만 요즘 부쩍 좋은 글이 눈에 띈다. (내가 하는 일과 관련하여) 도움이 절실한 분들이 주변에 있고, 또 몸이 한개인 터라 한계를 느낀 이유가 클 것이다. 그래서, 번역이라도 해서 전달하면 좋겠다 싶은데 엄두가 나지 않았다.^[1]  그러던 중에 이미 서너권을 번역하신 임춘봉님과 북경에서 함께 생활하게 되었다. 때가 왔다 싶어서 꼭 공유하고픈 글 몇 개를 부탁드렸다. 흔쾌히 승락하셔서, 옆에서 조금 거들기만 하면 좋은 글 번역을 생산할 수 있는 기반이 마련된 것이다!

그 중 첫번째 글이 바로 초급 소프트웨어 개발자 생존전략인데, 꼬박 하루 반나절을 번역에 매달리셨다.

이단 편집을 이용한 번역 방법

임춘봉님이 UML을 활용한 객체지향 분석 설계를 공역하실 2012년 즈음으로 기억한다. 당시 원고 교정 부탁을 받았을 때, 내가 일부 아이디어를 제공해 개발한 방법이 있는데 임춘봉님은 이를 이단 편집이라 부른다. 역시나 이 방법으로^[2] 번역을 시작하셨다. 참고로 이단 편집에 대해 조금 부연하면 대략 아래와 같은 식으로 두 개 컬럼을 이용해 원문과 번역결과를 병행 배열하는 방법이다.

이단 편집을 이용한 번역 진행 사례

이는 특히 장기간 번역을 진행할 때나 논문을 쓸 때 유용하다. 원문을 그대로 두고 최종 결과가 나오기까지 오른쪽 컬럼에는 참조할 링크와 아직 검증되지 않은 아이디어를 자유롭게 넣을 수 있기 때문이다. 내가 낸 아이디어는 이단 편집 자체는 아니고, 아래아 한글이 제공하는 다단편집보다는 MS워드 한 페이지에 2컬럼을 갖는 표를 넣는 것이 더 유리하고 그 보다 더 나은 방법은 단락 숫자 만큼 행을 갖는 표를 넣는 식을 제안했던 것이다^[3]. 아무튼 임춘봉님은 그 방법을 지금까지 쓰고 계셨다. 좋은 것을 보면 베끼라고 하지 않았나. 번역을 돕다가 13일 밤 나도 직접 번역을 시작했는데 워드 대신 컨플루언스 위키를 쓰기 때문에 아래와 같은 식으로 착수했다.

이단 편집에도 좋은 컨플루언스 위키 편집 기능

함께 해서 얻는 이점

검토를 요청하며 파일을 보내오셨다. 그날 일과중에 3건의 회의가 있었고, 회의 말고도 여러 다른 일처리 가운데서 피드백을 해야 하는 상황이었다. 작업 사이를 전환하는 중에 비는 틈이 생겼다. 이때를 활용해 의견을 드리려는데 맥북에 Word가 없고 Pages^[4]는 워드에서 만든 표 인식이 제대로 되지 않아 기록을 남길 수 없었다. 하는 수 없이 위챗Wechat으로 의견을 드렸다. 일반 대화와 구별이 안될까봐 번호를 달아서 개정 요구를 보냈다. 대략 아래 그림과 같은 식이다.

SNS를 통해 개선 제안을 하는 내용

이런 경험은 짜릿했다. 나는 나대로 일정을 소화하며 즉, 자리에 앉아 노트북으로 일을 하다가 회의실에 갔다가 하는 와중에도 짬이 생기면 가능한만큼 원고를 보고 수정하면 좋겠다 싶은 내용을 위챗으로 던진다. 대화창에 앞서 썼던 번호가 있으니까 이를 참조해서 순번만 달아둔다. 항상 내용을 머리에 담아 둘 필요도 없고, 5분이라도 짬이 나면 그만큼 진도를 나갈 수 있었다.

번역자인 임춘봉님 역시 편안해하셨다. 한번 번역을 마치고 파일을 던져 놓고 커피 한 잔 여유를 즐기고 있다가 대화창에 쌓인 요구를 보고 다시 원고를 펼치면 된다. 거기서 지정한 내용을 찾아 그 부분만 몰두해서 개선하면 된다. 이슈 트래커나 Slack 같은 도구를 일상에 써온 사람은 아는 바로 그런 방식...

우리 말로 하면 '따로 또 같이' 정도 되려나? 수정 작업은 금요일 오후부터 시작해서 내가 메긴 순번으로는49번^[5], 개정 파일 개수는 11번째로 popit에 올라갔다.

번역 협업 도구로 쓰인 wechat

쓰다보니 도구나 그 사용법이 강조된 듯 하다. 사실 더 중요한 부분은 바로 서로가 가진 강점을 잘 활용할 수 있고, 협업 과정에서도 자기 스타일이나 업무 방식 희생을 최소화 했다는 점이다. 그것이 생산의 요체가 아니었을까 싶다. 단순히 효율을 높이거나 분업이 주는 생산성 향상이 아니라^[6] 그런 편안함이 없으면 만들어지지 않았을 내용이 나온 것이다. 돈 받고 번역하는 것도 아니니까. 불편하고 번거로우면 안 한다. ^^

앞서 말한대로 나 혼자는 번역할 엄두가 안난다. 임춘봉님은 가치있는 글이라면 번역이 즐겁다고 수락했다. 허나 문제는 함수형 언어, 빌드 모니터링 도구가 필요한 현대 개발 방식 등에 생소하다. 그 부분은 내가 도우면 된다. 내겐 (상대적으로) 간단한 문제니까.

의지를 내는 사람이 둘이라 나타나는 상승작용

함께 해서 얻는 이점이 한 가지 더 있었다. 항상 그렇지는 않겠지만, 한 사람이 '이 정도면 되지 않을까' 할 때 다른 사람이 끌어주는 경우다. 금요일 10시가 넘어서 슬슬 졸릴 때 대강 고쳐서 올리면 되겠다는 공감이 있었다. 그런데, 하필(?) hilariously different라는 난해한 문구가 눈에 띄었다. 사전과 검색 엔진을 한참 찾아봤더니 겉모양이 비슷해보이지만 성격이 상당히 달라 나중에 알고 나면 바닥을 구르며 웃을 만한 일들을 설명할 때 이런 표현을 쓴다는 사실을 알았다. 바로 아래 문장 번역이 현재처럼 나오느냐 아니면 검색을 거치고 토의를 하기 직전의 모양대로 뭉뚱그려 모호한 표현으로 나오느냐는 두 사람의 실랑이 속에서 결정되었다.^[7]

모니터링 코드는 Clojure로 작성 되었고, 내가 익숙했던 객체 지향 패러다임과는 유사해 보이지만 놀랄 만한 차이가 있었다. 그래서 한달 동안 밤낮으로 클로저와는 어울리지 않는 끔찍한 코드를 만들며, Rich Hickey의 설명도 열심히 경청해야 했다.

출처: 초급 소프트웨어 개발자 생존전략

맺음말

이 글은 애초에 함께 번역을 개선했던 어젯밤의 추억을 기억하기 위해 썼다. 다만, 마치 영화의 디렉터스컷처럼 뒷이야기를 공유하고 싶은 의도가 있기는 했다. 그리고 쓰다 보니 번역에 활용하면 좋을 기법도 공유하게 되었다. 하지만, 글을 쓰게 만든 가장 큰 동기는 아마도 바로 각자의 인간성(혹은 정체성)을 발전시키면서 공동의 목표를 위해 노력하는 협업 과정의 즐거움을 홍보하려는 마음이 아니었을까 싶다.

200번 정도의 번역 수정과 편집을 하면서 _{2017년 11월 15일}

앞서 설명한 바대로 핑퐁이나 랠리를 하듯 수정 의견을 역자에게 넘기고, 역자가 다시 고쳐서 나에게 주는 식의 협업이 우리 작업방식의 골격이다. 그런데, 웹이 아닌 PDF 배포도 해보려고 A4 사이즈 문서로 편집하다 보니 또 다른 상황이 벌어졌다. 마침 역자도 출타중이어서 즉각적인 반응도 받기 어려운 상황에 촉매제 역할을 하기도 했다.

그래서, 아래와 같은 식으로 대화를 남기고 단독 편집을 시작했다. 무슨 말인고 하니, 어느 시점부터는 스스로 문장을 다듬으면서 톤을 결정하고 레이아웃도 즉시 정하여 작업했다. 출판사 번역과정과 점점 유사해지는 듯한 기분도 들었다. 확실하게 분업이 되면서 주석도 저자주와 역자주외에 편집자주까지 달았다.

여기서 대단한 배움이 있던 것은 아니지만, 오너십이 보장되는 상황(일종의 Collective Ownership이겠다.)이라면 확실하게 위임을 하고(혹은 받아) 전문성을 발휘하는 방식이 부가 가치 사슬을 만든다. 다만, 그 사슬은 전통적인 경영학의 구현처럼 프로세스 중심이 아니라 인간(혹은 인간과 기계의 협업)적 협업의 흐름을 통해서 구현해야 한다는 점이 중요한 시사점이다.

웹 출판이 아닌 전자문서 형태 출판을 하면서 _{2017년 11월 17일}

역시 협업이 아니었다면 배포 후에 발견했을만한 일을 막았다. 웹으로 글을 구독하지 않는 분들을 위해 PDF 배포를 시도했다. 맥용 워드 프로세서인 Pages를 이용해 문서를 편집해서 PDF로 만들었다. 그런데, 파트너인 임춘봉님이 그림이 너무 흐리다며 사이즈를 키우는 노력을 하고 있었다. '단순히 사이즈를 키운다고 해결되지 않는다'며 방법을 가지고 왈가왈부하던 나는 곧이어 깨달았다.

PDF 변환^[8] 이후 상황에 대한 고려가 적었다. 그냥 쓱 훑어 보는 식이었고, 그림이 나오는 후반부 페이지를 제대로 보지 않았다. 개발할 때 흔히 최종 사용자 환경을 무시한채 내 개발환경 혹은 내가 접근하기 쉬운 기기만 고려하는 습관이 떠올랐다. 번역에도 이런 일이 존재하다니...

역시 현장에 가깝게 작업하라. 그게 어려우면 무조건 페어로 하거나 빠른 피드백을 받을 수 있는 협업 구도를 만들어라!

주석

[1] 소트웍스 앤솔러지란 책의 한 챕터를 번역하면서 겪은 경험탓이다.

[2] 좋은 것은 항상 쓰면서 개선을 하신다. 나에게 리팩토링의 중요성을 삶으로 보여주신 분이 임춘봉님이다.

[3] 두 개선안 모두 전자보다 후자가 편집 단위를 작게 가져갈 수 있기 때문이다.

[4] Mac이 제공하는 워드 프로세서로 MS-Word와 일부 기능이 호환된다.

[5] 이슈트래커의 이슈 갯수에 해당

[6] 지식산업에서의 생산성은 제조업의 생산성과는 다른 시각으로 봐야 한다.

[7] 중국에서 구글이 막혀있으나 야후는 된다는 사실도 이때 알아낸 부수 효과다.

[8] Pages에서 PDF 보내기를 하며 이미지 품질이 훼손되었고, PDF로 인쇄하기로 출력하면 이미지 품질이 보전되었다.