2016.09.28. 00:45 |
읽게 된 동기
연구개발과제를 효율적으로 수행하기 위해 C++에 대한 최신 기술을 학습하고자 구매했다. 나는 C++98/03 세대로 굳이 C++11/14를 적용하지 않아도 개발에 큰 어려움은 없다. 다만, 최신 기술이 C++에 적용되었다는 사실을 알고 있고, 이미 다른 언어로 이러한 기술을 사용하고 있기 때문에, 이 책을 통해 최신 기술을 C++ 개발에 사용하고 싶었다.
워낙 유명한 책이지만, 우리나라 번역서 역사에 길이 남을 만한 큰 논란을 가진 책이기도 하다. 이 때문에 원서를 살까 고민도 했지만 한국어만큼 가독성이 좋지는 못하다고 판단하여 이 책을 구입했다.
리뷰 및 평점의 이유
명불허전(名不虛傳). 역시 훌륭한 책이다. 저자의 내공을 충분히 느낄 수 있었다. 부끄럽게도 이전 버전의 책을 읽지 않았는데 이번 기회에 그것도 읽을 계획이다.
일단 나는 15년이상 C++로 개발(다른 언어도 개발을 하지만)을 해왔고, 대부분 C++98(80%)과 C++03(20%)을 사용했다. C++14의 문법은 아직 모르는 상태이고, C++11은 간단한 문법서만 본 상태였다. 그런 상태에서 이 책을 보는데 큰 어려움은 없었다.
이 책을 보면서 C++이라는 개발언어의 생존전략이 무엇인지 파악하는 계기가 됐다. 완전하게 성능 극대화라는 목표로 개발언어가 성장하고 있었다. 손쉽고 개방적인 개발언어가 넘쳐나는 상황임에도 불구하고, 성능을 극대화 할 수 있는 차별화된 전략을 가지고 더 엄격한 문법과 라이브러리를 제시하고 있었다.
특히 우측값(오른값)은 정말 많은 개발자에게 진입장벽이 될 것 같다는 생각이 들었다. C/C++를 배울 때, 포인터로 좌절하고, 우측값에서 또 한 번 좌절할 것 같았다.
auto나 람다 함수를 포함하여 최신 트랜드 기술을 C++에 적용하고 있지만, 사실 개발 언어 특성상 매끄럽게 적용하기가 만만치 않을 것이라 생각했다. 다른 언어들은 이러한 개념을 적용하기 위해 어떻게든 편리하게 만들려고 노력했다면, C++은 정면돌파를 선택한 것 같다.
메모리를 직접 관리하는 언어 입장에서는 자칫 잘못하면 애매한 상황으로 인해 심각한 런타임 버그를 발생시킬 수 있기 때문에, 다른 편리한 언어를 사용하는 개발자가 본다면 어처구니 없을 정도의 엄격한 문법을 제시하고 있었다. 왠지 이러한 문법을 보고 있노라니 C++ 답다는 생각을 하게 된다.
책은 훌륭하지만 번역 때문에 평점이 5점짜리지만 4점밖에 줄 수 없었다. 이에 대한 논란은 yes24 리뷰를 보면 너무나 재밌으니 한 번 읽어보는 것도 좋을 것이다. 흥미롭게도 번역자의 반박글도 있다.
과거 번역서의 최고 흑역사가 있었다. 바로 UNIX Network Programming 이라는 책이다. 네트워크 프로그래밍의 최고의 책이었다. 지금 읽어도 엄청나게 도움 될 책이다. 그런 책이 말도 안되게 번역이 되었는데, 커널을 알맹이도 번역한 것을 보고 한 참 웃었던 기억이 난다.
이 밖에도 말도 안되는 번역으로 (번역기로 돌려도 이렇게 심하지는 않을 번역) 욕이란 욕은 다 먹었던 책이었다. 원서가 너무나 궁금하게 만드는 책으로 그 당시 실제로 원서도 구입해서 읽었다. 번역가가 서울대 출신으로 포항공대 교수라고 생각하면 더욱 어처구니 없다는 일이라 생각할 수 밖에 없다.
이 책의 번역자는 류광씨로 이 분의 번역서를 정말 많이 읽었었다. 양질의 번역서를 제공하시는 분인데 너무도 중요한 책에서 큰 실수를 했다는 생각을 했었다. 그런데 yes24에서의 반박글을 보니 그 분이 너무 자만해지신건 아닌가 하는 생각이 들었다.
일단 그 분이 번역한 몇가지 단어를 살펴보겠다.
- 과제 = task : 과제 기반 프로그래밍이라는 문구를 읽을 때마다 왜 자꾸 학생들 과제만 떠오르는지...
- 기상 = wakeup : 스레드가 잠에서 깨어날 때를 의미하는데, 다른데에서도 이렇게 번역했는지는 기억이 잘 나질 않는다. 자꾸 내가 잠에서 깨어나는 이미지가 떠올라서 혼났다.
- 합류가능 = joinable 뒤에는 join : 다른 독자분들은 어떨지 모르겠다. 스레드에서 join을 의미하는 것인데, 합류라고 썼다가, join으로 썼다가 그래서 더더욱 다른 의미인 줄 알았다.
- 보편참조 = universal reference : 원문이 더 이해가 되는 건 왜인지 모르겠다.
- 중복적재 = overloading : 나는 욕을 거의 안 한다. 1년에 한 두 번 정도 나도 모르게 숫자욕이 나오는데, 입 밖에 내뱉는 순간 흠칫 놀라곤 한다. 중복적재라는 단어가 나올 때마다 나는 흠칫 놀라곤 했다. 몇 년간 쓸 욕을 다 써버렸다. 이 단어는 정말 이렇게 번역하면 안 된다고 생각한다.
- 가로챌 수 있는 스레드 = interruptible thread : 한국어만 읽었을 때 한참을 생각하다 원문을 보고 바로 이해했다. 단어의 원문을 보고 몇 초 동안 충격의 도가니에 빠져있었다.
번역가의 마음은 알겠다. 수 많은 번역서를 내면서 적절치 않은 기술 관용어를 바꾸고 싶었던 모양이다. 그런데 그 선을 넘어버렸다는 생각이 들었다. 이 책에 많은 사람들이 리뷰를 남겼는데, 나도 한 마디 남기자면 이것은 잘못된 번역서가 맞다고 말하고 싶다. 그렇게 생각한 이유는 다음과 같다.
첫째, 이 책은 기본서가 아니고 부가적으로 도움을 주는 서브 책이므로, 이 책에서 새로운 용어를 정의한다는 것은 어불성설이라 생각한다. 이 책은 C++ 기본서를 읽거나 다른 방식으로 선행학습이 되어 있어야만 이해가 가능하다.
그렇다면 번역가는 C++ 기본서의 용어를 잘 살펴봤어야 한다. 많은 사람들이 그러한 책으로 용어를 익히고 사용하고 있기 때문이다.
언어의 단어는 실제 그 의미가 중요하지 않다. 이미 우리는 원래의 의미로 사용되지 않는 수많은 단어를 사용하고 있다. 심지어 처음 의도와는 반대 의미로 사용하는 단어도 있다. 세월이 흐르면서 단어의 의미가 변하기도 한다. 다수의 사람들이 익숙하게 사용하고 있으면 표준어로 채택되기도 한다.
이런 언어의 아주 기본적인 성격을 무시한 잘못된 선택이라 생각한다.
둘째, 독자에 대한 배려가 없었다. 글쓰기에서 가장 중요한 것은 독자에 대한 배려라고 생각한다. 독자가 어떻게 생각할지를 생각하면 함부로 이렇게 쓸 수는 없다.
개발자이면서 번역가로도 유명한 임백준씨도 side-effect를 부수효과로 번역한 적이 있다. 이 단어 하나에 대해서도 굉장히 조심스러워했다. 팟 캐스트 "나는 프로그래머다"에서 이렇게 번역한 단어에 대해 어떻게 생각하는지 몹시 궁금해하는 눈치였다. 이렇게 단어 하나 바꾸기가 어려운 것이다.
이미 사용하고 있는 관용적인 기술 용어를 이렇게 중요한 책에서 중복적재라는 단어로 번역한 것은 어쩌면 번역가의 횡포일 수 있다는 생각을 했다. overloading 이라는 단어는 원문부터 문제가 있다고 개인적으로 생각하는데, 이를 그대로 한국어로 번역했으니 나로서는 정말 분통이 터지는 일이다.
판권 문제가 해결되거나 개정판이 나오지 않는 이상 독자들은 잘못 번역된 책을 울며 겨자먹기로 구매해야 하는 처지에 놓여있게 되었다. 아마도 C++ 개발 경력이 높으면 높을 수록 헷갈림 정도는 기하급수적으로 늘어날 것이란 생각이 든다.
번역가 류광씨에게는 죄송스러운 일이지만 비판글을 남길 수 밖에 없는 것은 유닉스 네트워크 프로그래밍 이후에 일어나면 안 되는 일이 다시 한 번 일어났기 때문이다. 별로 영향력 없는 책이라면 이러한 논란이 발생하지는 않았을 것이라 생각한다.
출판사도 변역가님들도 그 뜻을 이해하지 못하는 건 아니지만, 특히 이렇게 영향력이 있는 도서를 번역할 때는 제발 독자들을 우선적으로 배려해 주었으면 하는 바람이다. 다시는 이런 일이 발생되지 않길 기원한다.
마지막으로 C++에 대한 저자의 공감어린 문구를 남긴다.
사실 C++ 프로그래머는 성능광일 가능성이 50% 이상이다. 성능광이 아닌 독자라도 이런 관점에 공감할 것이다. (애초에 성능에 관심이 없었다면, 지금 독자의 모니터에 떠 있는 것은 Python 코드가 아닐까?)
추천 대상
C++ 개발자라면 반드시 읽어야 할 책이라 생각한다. 어떤 분들은 그냥 원서를 읽으라고 하시는데, 분량이 상당히 많아서 원서로 읽기에는 너무 많은 시간이 소요될 것이란 생각이 든다. 아무리 짜증이 난다고 할지라도, 내 생각에는 원서를 읽는 것보다 한국어판이 더 좋은 선택이라 생각한다.
이 책은 초급이 읽기에는 조금 힘들지 않을까 생각이 들지만, 그래도 추천하고 싶다. 모르면 모르는대로 자신이 현재 아는 지식 내에서 이해가 가는 범위내에서 스키밍하며 읽어도 좋을 것 같다.
어차피 레퍼런스 용이라 생각하고, 개발하면서 참고해야 할 것이다.
http://blog.naver.com/yo2dh/220822566110
ㄹㅇ
번역가 우러욧8ㅅ8
ㄴ맞아요 ㅠㅠ 근데 표준화를 위한 노력이 아예 없다시피해서 마냥 좋아할수도 없음
허구한날 신기술이 생겨대니 그럴수바꼐
번역서를 읽는 이유는 빠르게 읽기 위함인데 저런 식으로 번역해 놓으면 번역서를 읽는 이유가 없어짐. 번역서를 위한 쓸데없는 단어공부 시간이 추가되니까