Whiteship's Note

[Agile 번역] 어떻게 하면 번역을 기민하게 할 수 있을까?

모하니?/Thinking : 2010.03.12 11:09


번역은 쉽지 않다. 하지만 나름 재미는 있다. 돈은 되지 않지만, 하고 나면 뿌듯하다. 책으로 치면 지금하고 있는 책까지 두 권째다. 난 번역을 잘하지 못한다. 한글 실력이 엉망이고 책읽기를 별로 좋아하지 않아서 인지 문학 도서에 비하면 비교적 쉬운 영어를 사용하는 서적들 임에도 불구하고 한글 문장으로 옮기는 일이 쉽지 않다. 그래도 최소한 내가 다시 읽었을 때 이해할 수 있을 정도의 수준 만큼은 달성하고자 노력한다.

그렇게 어렵사리 번역을 하고나면 사실 다른 사람의 시각에서 읽었을 때 어떠한지 궁금하다. 그래서 베타리딩을 한다. 베타리딩을 하면서 내가 미처 감지하지 못했던 어색한 부분과 이해 못할 만한 부분이 드러난다. 그 부분을 개선하는 작업은 중요하다. 내가 읽었을 때 이해할 수 있었던 건 난 원문의 내용을 읽었기 때문이다. 그래서 원문을 보지 않고도 이해할 수 있는지 알려면 반드시 베타리딩이 필요하다. 코딩으로 치면 일종의 테스트다. 그런데 베타리딩도 쉽지 않다. 하이버네이트 같은 경우 한 챕터당 워드로 100페이지 정도가 된다. 넘는 것도 있고 덜 되는 것도 있지만 대충 그렇다. 그걸 바쁜 개발자들에게 읽어달라고 부탁하기가 참 뭐하다. 그 분들이 받는 댓가라고는 책을 미리 읽어볼 수 있다는 것 정도?

그래서 이런 저런 이유로 고민 중에 번역에도 Agile 기법을 도입하면 어떨까 하는 생각이 들었다. 그래서 상상을 해봤다.

페어 번역 

두 명이 앉아서 번역을 한다. 한명은 부르고 한명은 타이핑 하거나 그 반대로 한명이 읊으면서 동시에 타이핑도 하고 옆 사람은 보고 있다가 이상한 문장이나 틀린걸 봐주면 될 것 같다. 하지만 이건 번역으로 먹고 사는 사람이 아닌 이상 힘들어 보인다. 그렇게 30분 정도 번역을 한 다음 교대한다.

이런식으로 하루에 2시간을 번역한다고 쳤을 때 두 사람은 각각 1시간 번역 1시간 리뷰를 하게 된다. 한 사람이 2시간을 번역할 때와 2사람이 각각 1시간 번역/1시간 리뷰를 했을 때의 생산량과 품질을 확인해보고 싶다.

리뷰 퍼스트 번역

타이핑을 하기 전에 먼저 말로 리뷰를 한다. 아 이 문장은 대충 요러 요러한 이야기 같네요. 이렇게 옮기겠습니다. 라고 말을 한 뒤에 타이핑을 한다. 그리고 타이핑이 끝나면 옆 사람과 리팩토링을 진행한다. 어설프거나 한글 어법에 어긋나면 교정한다. 나중에 QA 팀 겪인 출판사의 검수자가 봐주겠지만 최소한의 품질을 보장하기 위한 수단이라고 보면 되겠다. 

페어 번역을 진행할 때 타이핑만 하지 않고 리뷰를 함으로써 대화를 유도할 수 있다. 하지만 대화가 목적은 아니기에 잡담으로 새는 일이 없게 주의해야겠다. 리뷰를 최소화하고 바로 타이핑을 한다. 그 다음 리팩토링에 해당하는 작업도 반드시 단락 단위나 문자 단위로 하는게 좋겠다. 이런 과정이 없다면 페어 번역을 하는 의미가 없으니 이렇게 하지 않을꺼면 페어 번역을 하지 않는게 좋겠다.

점진적인 베타리딩

베타리더에게 전달하는 과정을 일종의 배포로 간주하고 Agile 기법인 여러번 그리고 점진적으로 배포하는 수단을 번역에도 도입하면 어떨까. 예를 들어 베타리딩 주기를 1주일로 잡고 1주일치 번역한 내용을 베타리더에게 공개한다. 그리고 피드백을 받은 다음 그 주 초에 지난 배포의 개선 작업을 한 다음에 주 중~말까지 새로운 번역 작업을 진행하는 식이다.

베타리더에게 한번에 100 페이지씩 읽어야 하는 부담을 줄일 수 있고 피드백을 초기에 받음으로써 나중에 뭉탱이로 중복적인 피드백을 받는 것을 개선할 수 있을 것 같다. 하지만 베타리더도 번역자 못지않게 기민해야 할 것이다.

다음 번역은 봄싹에서 진행할 계획인데 이 세가지를 시도해 봐야겠다. 
과연.. 어떨까.. 후훗.. 재밌을 것 같다.
저작자 표시
신고
top

TAG ,



: 1 : ··· : 160 : 161 : 162 : 163 : 164 : 165 : 166 : 167 : 168 : ··· : 2639 :





티스토리 툴바