왜 개발자들은 질 좋은 번역서를 읽지 못할까?
우연한 기회에 올 연말쯤 출시될 책의 베타 리뷰를 맡게 되었다. 인턴부터 지금까지도 팀 내에서 글을 검토하거나 번역하는 일이 많았었다. 업무 틈틈이 해오던 일이라 '얼마 안 걸리겠지'라고 생각하며 흔쾌히 책의 리뷰를 하겠다고 했다. 막상 받아보니 책에서 다루는 내용이 어려워 글이 잘 읽히지 않았다. 복문이나 번역투가 그대로 남아있어 몇 번씩 다시 읽느라 시간이 오래 걸렸다.
최근 빅데이터와 관련된 개발 도서들을 읽으면서도 이런 느낌을 받았었다. 책에 나온 내용이 어렵기 때문에 쉬운 말로 설명해주길 바랬지만 영어와 한국어의 문법 차이로 인한 만들어진 문장들이 굉장히 많았었다. 그리고 문장의 주어와 서술어의 호응이 맞지 않을 때도 있고, 문장의 성분 요소가 빠진 경우도 더러 있었다.
그동안 많은 개발 도서들을 읽으면서 내가 느꼈던 번역 문장의 특징들을 한번 정리해보았다.
한자를 많이 쓴다.
번역 문장이 길어지다 보니 어떻게 해서라도 문장을 줄이기 위해 한자를 쓰는 느낌이 들었다. 나는 차라리 문장을 짧게 끊어내고 한자를 우리말로 대체할 수 있는 표현으로 쓰는 게 훨씬 좋다고 생각한다. 한자보다는 우리말 표현이 새로운 기술에 대해 배울 때 더 이해하기 쉽다고 느껴졌다. 실제 대화할 때 '-적', '-의', '~로 인한', '사용', '~할 시' 등의 표현은 잘 안 쓰는 것처럼. (이건 개인적인 취향일 수 있음)
문장의 주체가 없다.
번역된 문장을 보면 문장의 주어가 없는 경우가 있다. 영어 문법에서 꾸며주는 말들을 '~하는', '~되는'이라는 표현으로 계속 이어서 가져온다. 그래서 문장의 주인이 없는 경우도 있고, 이상한 번역투가 생기거나 주어가 한참 뒤에 있는 형태의 복문이 많다.
this, that 등으로 인해 '이', '그', '저', '이런' 등의 표현이 많다.
직역을 하면서 시키다/되다 등 주어와 어울리지 않는 어색한 표현들이 많다.
위와 같은 특징을 가진 문장들을 개발 도서를 읽으면서 많이 봤을 것이다. 그렇기 때문에 나는 이 일을 대충하고 싶지 않았다. (누군가에게는 그저 직무와 관련 없는 잔업으로 보였을지 모르지만) 그래서 베타 리뷰 제안이 왔을 때, 괜찮은 번역 기술서를 만들겠다는 생각으로 수락하였다.
왜 이런 문장이 나올까?
보통 컴퓨터공학을 전공한다면 대학에서 전공을 원서로 배웠을 것이다. 원서로 공부하는 사람도 있었겠지만 번역본을 구해서 공부를 한 사람들도 있었다. 내가 알기로는 대부분의 번역본은 대학원 조교들이 작성하는 부분이 많다고 한다. 대학원생들의 일상을 보면 직장인 못지않게 해야 할 일들이 많다. 연구도 해야 하고, 조교 활동, 본인 학사관리 등. 그러므로 퀄리티가 좋은 번역서가 나우기 힘든 환경이다. 그러나 그렇게 만들어진 책은 출판이 되었고, 그 책으로 공부를 하다 보니 자연스럽게 그 말투에 익숙해지는 건 아닐까라는 생각이 들었다.
한국어와 영어의 차이라고 구글에 검색하면 이와 관련된 내용이 많이 나올 것이다. 영어는 말의 뼈대를 먼저 말하는 방식이다. 주어와 서술어를 먼저 말하고 나머지는 다 꾸며주는 즉, 보충해주는 방식으로 문장이 이루어진다. 그렇기 때문에 문장을 보충해주는 말들이 굉장히 많고, 이를 직역하게 되면 문장이 복문이 되는 경우가 많다. 또한 우리는 서술어가 보통 맨 뒤에 나오는 방식이므로 이와 같이 번역하게 되면 '~하는 무엇은 ~되는 ~을 ~한다.'와 같은 문장이 만들어진다. 그러므로 이러한 차이를 알고 번역하는 사람이 문장을 짧게 끊어서 매끄럽게 만들어야 읽는 사람이 편한 번역 도서가 된다고 생각한다.
보통 IT 도서는 회사를 다니는 개발자들이 직접 쓰거나 외국 도서를 번역하는 경우가 많다. 실제로 번역도서를 출간하는 것은 직장인들에겐 어려운 일이다. 시간이 꽤 많이 걸리기 때문이다. 평일에는 회사의 업무를 해야 할 것이고, 때때로 야근을 하는 일이 생길 것이다. 회사에서 눈치 안 보고 번역하는 것도 쉽진 않을 테고. 그렇다면 보통 주말에 해야 할 텐데 직장을 다녀본 사람들은 알 것이다. 직장인이 주말에 무언가 한다는 게 체력이 뒷받침되지 않는 이상 하기 어렵다는 것을. 그리고 가정이 있는 사람들은 보통 주말에 가족들과 시간을 보낸다. 주말에 번역 작업을 몰두할 수 있도록 가족들의 이해와 배려가 없다면 현실적으로 하기 힘들 것이다.
'개발자는 코드로 말한다.'라는 표현이 있다. 나는 이 문장에 반만 동의한다. '코드'로 나를 말하는 일도 있지만, '글'로써 표현하는 일도 제법 있기 때문이다. 취업과 이직을 하기 위한 자기소개서는 말할 것도 없고 메일을 통한 업무, 회의록, 개발 명세서 그리고 매뉴얼 등 회사 생활에 글쓰기 능력이 필요한 일들이 꽤나 많다. 개발자는 코드로 말한다고 하지만 내가 짠 코드 아니면 다른 사람들은 이해하기가 힘들다. 그렇기 때문에 '글'과 '말'로 설명을 해야 하는 게 사실이다.
1년 전 취업 준비를 하는 과정 중에 '내 문장이 그렇게 이상한가요?'라는 책을 알게 되었다. 이 책을 통해 내가 쓴 자기소개서의 문장들을 다시 한번 돌아볼 수 있게 되었고, 불필요한 것들을 줄일 수 있게 되었다. 그때 보았던 내용들은 누군가의 글을 검토하거나 내가 글을 쓸 때, 더 나은 글로 만들어 주었다. 또한 이번에 맡은 번역 도서의 교정 및 베타 리뷰에도 많은 도움이 되었다. 책 하나를 통해 내 문장이 더 좋아진 것처럼 책을 쓰는 사람이 본인의 문장에 조금만 더 관심을 기울여서 좋은 문장을 만든다면 훨씬 잘 읽히는 기술서가 될 것이라고 생각한다.
어쨌든 이번 베타 리뷰를 하면서 두꺼운 양의 기술서를 번역해 출판까지 하는 직장인들이 새삼 대단하다고 느껴졌다. 회사 일과 출판 작업으로 바쁜 와중에 나의 리뷰로 인해 고생했을 팀원들에게 죄송한 생각이 들었다. 그래도 팀원들이 내가 생각해왔던 번역서의 문제점에 공감해주셨고, 나의 교정본을 본인들의 책에 많이 반영을 해주셨다. 지금까지 한 작업은 베타 리뷰보다는 거의 교정, 교열 작업에 가까웠지만 출간 전에는 독자의 마음으로 돌아가 리뷰를 할 예정이다.
책이 출간된 이후에는 이전의 번역 기술서에 비해 어떤지 의견을 듣고 싶다. 잘 읽히는 기술서라는 평을 듣는다면 더없이 좋을 것 같다. 더 나은 기술 번역서가 나오길 바라면서 그동안 내가 리뷰를 하면서 느꼈던 점을 마무리한다.
위의 내용은 전적으로 저의 생각입니다.
글을 읽는 모든 분들의 라이킷과 댓글을 환영합니다. ;-)