Younghoe.Info (final edition)

세대와 나이를 떠나 뜻을 같이 한다고 믿는 분이 자신이 번역한 책에 대해 실날한 비판일지라도 허심탄회한 의견을 요구하셨다. UML 쓸 일이 드문터라 시간투자가 부담스럽지만 '개체 매니페스토'를 떠들고 실천을 안한 죄로 차분히 책장을 넘겨봤다. 워낙 고전이고 철저한 번역 내용을 비난하기는 어렵다. 굳이 찾자면 '산출물도'가 눈에 띄였다. 얼핏 읽으면 '산출물'에 조사가 붙은 어구인 듯도 하고, 발음하기에도 좋지 않다. 다이어그램(diagram)을 '~도(圖)'로 번역했기 때문인데 산출물도에 있어서는 예외를 두어 '산출물 도해'로 표현했으면 어땠을까 싶은 정도로 허점을 찾으려면 긴 시간 노력이 필요할 듯하다.

사실 책에 대해 하고픈 이야기는 따로 있다. 이전에 이런 일이 있었다. 원서를 교재로 쓰는 수업인데 한 친구가 서점에도 없는 번역서를 구해서 자기 발표 시간에 한글 용어를 쓰며 발표했다. 교수님이 호되게 질책을 했다. 니가 뭔데 마음대로 용어를 정하냐는 것이었다. 교수님 논지는 용어 하나 하나 뒤에는 무수히 많은 논문이 있다는 것이다. 익숙하지 않은 한글 용어가 연달아 들릴 때는 생소하기 이를 데 없긴 했지만, 친구의 자존심이 상할 정도로 나무래는 교수님 모습도 충격이었다. 지금 생각해보면 용어 하나까지 본류를 지키는 모습은 좋아 보이지만, 사대주의 냄새도 난다. 컨설턴트 경력 초기에 현장에서 서로 합의도 되지 않은 용처를 가진 유스 케이스를 필수 도구로 사용하면 많은 사람이 소모적인 논쟁으로 시간과 예산을 낭비했던 경험을 함께 했다. 대부분의 프로젝트에서는 차라리 없는 편이 좋을 수도 있다는 생각이 들었다. 아무리 좋은 개념이나 도구라도 현장의 사람이 적절하게 써서 최종 목적 달성에 이바지할 때 의미가 있다. 다시 말해서 그래야 실용성이 있다. 내용을 떠나 이 책은 실용성으로 무장한 한글화의 정수로 극찬하고 싶다. 물론 컴퓨터 관련 서적 범위안에서 말이다.

예전에 다이어그램 대신 도(圖)는 너무 생소하다는 의견에 대해 역자가 이런 견해를 제시했다. 둘 중 무엇으로 해도 의미가 통한다면 자주 나오는 표현이니 지면을 아끼고 읽는 시간을 줄이는 '도'가 우수하다. 깜짝 놀란 논지였다.

밀린 번역이 있는데 재개할 때는 스스로 정리하던 용어 대신 이 책의 용어에서 출발해야겠다. 나를 포함한 다수 개발자가 용어에 대한 사대주의와 지나치게 원래 의미를 고수하려는 강박관념을 갖고 있다. 국내 독자의 이해를 돕기 위해서라면 원어의 이미에 약간의 손상은 감수해야 한다. 그렇다고 우리 문화를 고려하여 새로운 표현을 고안할 능력이 없으므로 먼저 고민한 선배의 토대에 한술 얻는다는 생각으로 말이다.

한편, 안드로이드 책이 프로그래밍 서적을 독점(?)한 시장에 이런 고전을 내주신 출판사가 고맙다. 그러나, UML 교과서에 해당하는 책 제목으로 'UML 실전 활용 테크닉'으로 선정한 상술은 고전을 출간하는 배포와 비견해보면 매우 아이러니하다. 또, 시장이 작으니 기술 편집자(Technical Editor)가 없는 현실은 그렇다 쳐도 블릿이 있는 글은 굵게 표기한 편집은 책을 조잡하게 보이게 만들어 아쉬웠다.