저는 국문과 출신의 개발자 입니다. 언제나 개발에 관심이 있어 대외 활동으로 해커톤 비슷한 것도 참여해보았지만 개발 지식이 없어 개발 포지션이 아닌 기획 포지션으로 참여를 했었습니다. 그러다 알고 지내던 개발자님 덕분에 운 좋게 이 일을 시작할 수 있게 되었죠.

처음부터 개발을 하진 않았어요. 처음엔 DRM 관련 문서를 번역해서 관련 개발을 하실 수 있게 돕는 역할을 주로 했습니다. 이전 회사에서는 백과사전 항목들을 조사하고 글을 작성, 교정, 윤문 하는 에디터 일을 했었기 때문에 글을 작성하는 일이 더 익숙했고 큰 거부감은 없었습니다. 그런데 그 일이 점점 제 메인 잡처럼 되어버렸고, 팀내에선 대놓고 저를 무시하는 팀원이 생기고 말았습니다. 매일 직업적 정체성을 의심하게 하고, '내가 과연 개발을 하게 될 순 있을까? 해도 되는걸까?'하는 부정적인 생각을 끊임없이 갖게 되더라구요. 그러다 조직 개편이 있어 팀을 옮기게 되었는데 바뀐 팀 리더분이 진행하고 있는 번역 작업이 있다고 제게 도움을 요청하셨습니다.

'또 비슷한 일이겠구나'

"나라님, 저희가 2년 가까이 작업한 번역서가 있어요. 함께 해주실 수 있으실까요?"
네? 제가요? 🤔

제가 책을 낸다구요?

물론 역자로서 내는 것이지만, 제 이름이 실린 책을 낼 수 있다는 것이 엄청난 흥분이었습니다. 백과사전은 아무리 제가 열심히 글을 다듬어도, 실제 그 지식을 제공하신 분의 이름이 출처가 되었었고, 당장 이전 팀에서 한 일은 아무도 알아주지 않는 일이었거든요.

'그런데, 어떻게 아무것도 모르는 내가 책을 번역하지?'

개발의 '개'자도 모르는데 제가 개발 서적을 번역한다구요? 하하. 다행히 (저와 독자분들 모두에게 다행) 초벌 번역은 다 되어있는 상태였습니다. 2년 가까운 시간동안 두 분의 개발자분께서 1000페이지가 넘는 엄청난 분량의 글들의 대략적인 번역을 다 마친 상태시더라구요. 저는 그 드래프트를 읽고 교정하는 작업을 하면 되는 것이었습니다.

🤔 교정만 하면 되는 줄 알았는데

교정만 하면 될 거라는 생각에 가볍게 시작했는데 생각보다 사태는 심각했습니다.

문제는 이렇습니다.

1. 영문이 원서였으나, 한 분은 영문을 중심으로 번역하고 한 분은 일문을 중심으로 번역했다

영문에서 일문으로 번역 되면서 틀린 번역이, 일문을 중심으로 번역하신 분의 글에 남아있게 됐습니다. 아마 각자 한권만 쭉 읽으셨을테니 이상한걸 못 느끼셨을 것 같습니다. 그러나 합쳐서 읽는 입장에선, 글의 흐름이 이상하더군요. 영문을 살펴보니 1차적으로 일문 번역이 잘못된 부분이 있는 것을 찾았습니다. 이 때 느꼈습니다. '아, 두 권을 다 봐야겠구나.'
(다행인 것은 제가 일본어를 할 줄 안다는 점이었습니다.)

"미안하다 이거 번역하려고 일본어 복수전공 했다"

또한 이런식으로 진행되면 어쩔 수 없이, 영문 번역체와 일문 번역체의 색이 문장에 그대로 남게 되어 통일성을 해칩니다. 물론 번역체를 지우고 번역하는게 베스트입니다만, 번역체가 워낙 실생활에서 많이 노출되어 이상한 것을 못 느끼고 문장을 작성하게 되는 경우가 많으니(1000페이지가 넘어가는 책의 번역을 하다보면 더 눈치채기 힘들어 집니다.) 이왕이면 통일된 문장이 좋겠죠.

기술 용어도 영문과 일문의 표현이 달랐기 때문에, 해당 표현이 한국어에서는 어떻게 표현되는지, 약속된 표현이 없다면 우리는 어떻게 새롭게 표현할 것인지와 같은 통일된 약속이 필요했습니다.

2. 번역한 사람만 이해하는 문장을 작성했다

제가 작업에 참여한 책은 Perl Cookbook 이었는데, 이미 해당 언어에 대한 이해도가 높은 상태로 책을 수차례 읽은 개발자분들이 작성하다보니 번역한 사람만 이해할 수 있는 문장을 많이 작성하셨습니다. 기술적으로 이해가 안 될 때가 있었고, 문장 자체가 이해가 안 될 때도 있었습니다.

예컨대, "It"으로 시작하는 문장은 전부 "그것/이것"이라는 지시 대명사로 문장이 시작했습니다. 한국어에서는 이런 지시 대명사의 사용이 영어만큼 흔치 않을 뿐더러, 번역체 문장의 느낌을 강하게 줍니다. 또한 문장이 길어지면 "그것"이 어떤 것인이 독자가 명확하게 판단하기 어려워집니다.

하나 더 꼽자면, 원문의 문장이 길어지고 관계대명사가 복잡하게 쓰임에 따라 번역된 문장의 서술이 매끄럽지 않은 경우가 있었습니다. 수식 대상이 모호해지고 비문이 많아졌습니다.

보통 본인이 쓴 글은 스스로 빨간펜 선생님이 되기가 무척 어렵기 때문에, 이제 막 작업에 참여하게 된 제3자였던 제가 문장을 더 객관적으로 볼 수 있는 입장이었을 것 같습니다. (그리고 사실 이 부분은 출판사 에디터분이 함께 봐주시기 때문에, 여러번 크로스 체킹 됩니다. 담당자님도 고생이 엄청 많으셨어요.)

🧐 번역만 하면 되는 줄 알았는데

3. 결국은 Perl을 공부해야 한다

마무리 작업으로 간단하게 교정만 보면 될 줄 알았던 일이, 위와 같은 이유로 처음부터 두 권의 외국어 서적을 번갈아가며 체크하여 번역을 다시 해야하는 경우가 발생하고 말았습니다.

문제는 제가 Perl을 모른다는 것이었습니다.

어쩔 수 없이 해당 도서의 매끄러운 번역을 위해서 예제 코드를 돌려보고 Perl을 조금씩 공부했습니다. 책의 이해를 위해 필수적으로 거쳐야 하는 과정이었습니다.
아쉽게도 출판사에서 요구한 마감날짜가 있었기 때문에 정말 공부하듯이 진득하게 집중 할 순 없었습니다. 그렇지만 코드를 써보기 위해 개발환경을 구성해보고 필요한 라이브러리를 깔아보고 코드를 써보고 개발에 필요한 기본 개념들을 학습하는 등, 개발 초년생이 해봐야 하는 기본적인 일들을 접하고 배울 수 있었습니다. 여러명이 번역을 하다보니 git을 통해 문서관리를 했습니다. 덕분에 git도 배울 수 있었네요🥰.

4. 색인(Index) 페이지 찾기 노가다는 덤

최종_번역본.docx
최종의_최종.docx
진짜_최최최종.docx
진진막_최최최최종.docx
찐찐막_최최최최종_final.docx

마지막까지 재번역 및 교정 작업이 다 끝나면 가장 최악의 부분이 남습니다. 바로 책 마지막 부분에 나오는 인덱스 부분입니다. 어떤 용어가 어느 페이지에 등장하는지 알려주는 좌표 페이지죠. 번역 작업을 처음 하다보니 이런 작업도 역자가 하는지 몰랐습니다. (독자의 입장에서 있을 때 해당 페이지는 출판사가 자체적으로 정리해서 넣는 페이지라고 생각했었거든요.)

Perl Cookbook은 총 1096쪽(역서 기준)의 방대한 페이지를 자랑하며, 예상하셨겠지만 엄청난 수의 용어들이 등장합니다.

🔼 위와 같이 엑셀로 3명의 공역자가 인덱싱 작업을 했습니다. 작업은 아래와 같습니다.

• 원문에는 용어들이 ABC 알파벳 순으로 정렬되어 있으므로 인덱스라 ㄱㄴㄷ 순으로 변경합니다. (Depth가 최대 3단계!)
• 역서를 기준으로 용어가 나온 페이지를 찾아 맵핑 합니다.
• 그걸 2932번 반복합니다.
  * 무려 3명이 진행합니다. (...)
  

번역서 상의 복수처리 된 명사를 정말 복수형으로 기록할 것인지, 단수형으로 기록할 것인지, 외래어 표기를 어떻게 통일할 것인지 합의 하는 과정도 상당히 오래 걸리지만 이를 적용시키는 과정도 엄청난 시간이 소요됐습니다.

이런 시간을 단축시키기 위해 공역자이신 박근영 박사님께서 아래 툴을 만들어 공유해주셨습니다.

gypark/indexing-web

일관성 있게 인덱스를 처리할 수 있게 만든 툴입니다. 이 툴 덕분에 작업속도가 올라갈뿐만 아니라, 휴먼에러를 많이 줄일 수 있어서 상당히 유용했습니다.

당시 비개발자에 더 가까웠던 저는 개발이라고 하면, 웹이나 모바일 애플리케이션만 생각했는데 '이렇게 내가 피곤한 작업을 단순화 하고 자동화 할 수 있는거구나' 를 처음 깨닫게 된 순간이었어요. 덕분에 번역작업에 개발이 어떻게 활용될 수 있는지 엿볼 수 있어 즐거운 작업이 되었습니다.

🤟 국문과 출신 개발자라는 수식어는 나의 강점

🔼 공역에 제 이름을 올렸습니다.

꽤 오랜 시간이 걸렸지만 무사히 책을 낼 수 있었습니다. 처음엔 국문과 출신의 개발자라 한계가 있다고 생각했지만, 이것이 되려 제겐 무기가 될 수 있다는 생각을 갖게 해준 프로젝트였습니다. '나는 국문과 출신이라 안되나봐.'가 아니라 '나는 글도 잘 쓰는 개발자야.'라는 자신감이 생겼습니다.

이후에 제게 공역을 권해주신 이종진 님 덕분에 구글 클라우드 플랫폼 입문 이라는 서적도 번역과 교정을 담당했습니다. 공역에 이름을 올리진 못했지만, 현 직장에서 AWS SA로 일하며 멀티 클라우드를 접하고 공부하며 번역도 할 수 있는 소중한 기회였습니다.

2019년에는 손에 잡히는 10분 정규 표현식을 번역하였습니다.

번역을 하면서 개발에 대한 관심과 애정이 점점 더 짙어집니다. 책을 여러번 강독하게 되니 새롭게 배우는 것도 많고, 협업을 위해 커뮤니케이션을 자주하다보니 커뮤니케이션의 방법, 표현력에도 자신이 많이 생겼습니다. 그렇다면 제 전공은 이제 저의 강점이 된게 아닐까요?

부족한 저와 함께 작업해주셨던 모든 분들에게 감사드립니다. 이제는 코드를도 더 잘 쓰는 개발자가 되기 위해 더 노력해야겠습니다.