엉터리 IT 번역「타협은 없다」

[ː번역inː]

http://www.zdnet.co.kr/news/column/mylee/0,39024739,10067273,00.htm

"[이만용의 Open Mind] 엉터리 IT 번역「타협은 없다」

이만용 (리눅스코리아) (리눅스코리아)
2004/02/20

모든 문화와 기술은 영어, 한국어 등 특정 언어를 기반으로 만들어진다. 따라서 이를 다른 언어권 사람들에게 전파하기 위해서는 항상 ‘번역(translation)’이라는 작업을 거친다. ‘번역은 제2의 창조 과정이다’라는 말은 이와 같은 번역 작업의 중요성과 번역자의 책임을 강조하는 말이다.

IT 분야의 번역은 타 분야와는 차이가 있다. 무엇보다 IT 분야는 다른 분야와 비교할 수 없을 만큼 빠른 속도로 기술이 생산되기 때문에 신속한 번역을 필요로 한다. 문학의 경우 번역에 충분한 시간을 가져도 무방하지만, 제 시간 안에 번역돼 IT 종사자들에게 전달되지 못한 기술은 그 가치가 반감되기 마련이다.

문제는 이와 같은 신속성과 경박한 출판 자본이 만나 최악의 결과로 빚어지는 경우다. 특히 오역이라는 말조차 사치스러운 악역(惡譯)에 대해서는 일말의 동정심도 가지 않는다.

보통 새로운 출판사가 설립되면 외국 출판사의 시리즈물을 단기간에 출시하곤 한다. 이때 가장 눈에 띄는 것은 기획서가 아닌 번역서임에도 불구하고 번역자의 이름이 특정인이 아니라 ‘***연구회’나 ‘***팀’ 등 집단 번역체제라는 점이다.

이같은 유령 번역 시스템에서는 책임질 주체가 존재하지 않는다. 십중팔구 값싼 대학생 노동력을 착취한 결과로, 번역에 대한 충분한 금전적 보상도 긍지도 없기 때문에 번역 ‘납기일’이 가까워지면 주위 친구들에게 긴급 구조 요청을 보내 누비 이불 같은 공동 번역 작품을 만들어낸다. 출판사를 욕해 봤자 계란으로 바위치기다. 독자들의 시선을 의식하는 출판사라면 애초부터 이런 파렴치한 짓 자체를 하지 않았을 것이기 때문이다.

‘유령 번역 시스템’은 부패한 음식을 파는 것과 같다
새로운 기술을 익히기 위해 이와 같은 번역서 구입에 지갑을 턴 독자는 신기술은 커녕 오히려 치유하기 힘든 혼란만 얻는다. 어떤 의미에서는 오히려 후퇴한다. 여기에는 IT 분야에서 사용되지 않는 엉뚱한 번역어들이 가득 차 있으며, 심지어 우리말로도 앞뒤가 맞지 않기 때문이다. 프로그래밍 서적이라면 그 안에 들어있는 소스 코드가 제대로 실행될리 없다.

이와 같은 출판 관행은 ‘출판사가 비록 영리를 추구하는 조직이지만 지식을 다루며 사회적 사명감을 가진 뜻있는 영리 활동’이라는 순진한 믿음을 묵살하는 것을 물론 독자를 금전적으로나 정신적으로 (요즘 유행하는 썰렁한 말로) ‘두 번 죽이는’ 일이다. 결과가 뻔한 이같은 불성실한 번역 행위는 죄악이며 소비자의 적극적인 홍보 활동을 통해 단죄해야 한다.

이런 취지에서 필자는 좋은 책을 소개하는 것은 물론이요 동시에 나쁜 책도 소개(!)하곤 한다. 악역은 절대 타협의 대상이 아니며 퇴치의 대상일 뿐이다. 그런 출판사와 번역자는 정신적으로 부패한 음식을 파는 것과 다르지 않다.

번역자들(특히 대학생 번역자)에게 꼭 이야기하고 싶은 것은 번역에 앞서 원서를 읽는 것이 아니라 이를 소화(digest)해 자기 것으로 만들 수 있을 만큼 지식을 갖추고 있는지 자문해 보라는 것이다. 공부하는 자세로 번역하겠다는 자기 위안만큼 유치한 것도 없다. 위대한 학자들은 모국어 창작은 물론 다른 언어를 사용했던 조상이나 타민족의 원전을 끊임없이 발굴해 고통스러운 번역 작업을 병행했다. 위대한 학자는 위대한 번역자이기도 했다. 그들에게 번역은 학문 활동의 부수적 활동이 아니었으며 번역하는 동안 오히려 더 투철하게 공부했다.

책 위에 활자화된 자신의 이름을 올리고 한 번에 목돈을 만질 수 있다는 사실은 분명 멋진 일이지만 그것은 죄없는 사람들 또는 동년배 친구들의 돈을 빼앗고 훌륭한 책 하나가 널리 퍼질 수 있는 기회를 박탈한 댓가임을 알아야 한다.

잘못 탄생한 번역서의 가장 큰 문제는 훌륭한 원서 하나를 영영 또는 몇 년 간 방치 상태로 놔두고 다른 좋은 번역이 나올 수 없도록 막는다는 점이다. 출판사의 계약 관계에 의해 해당 번역서의 원서는 다음 개정판이 나오기 전까지 계속해서 악역된 상태로 남아 있어야 한다. 이 앵커데스크에는 토크백을 통해 독자들이 자유롭게 의견개진을 할 수 있지만 단행본 책은 그런 수단도 없지 않은가?

의도적인 악역은 아니지만 불성실에 의한 악역 역시 비난을 면할 수 없다. 불성실한 악역의 대표적인 사례는, 원저자는 한 명인데 역자가 2명 심지어는 3, 4명인 경우다. 아마도 한 명으로 시작했다가 납기가 다가오면서 점점 늘어났을 것이다. 두번째 유형으로는 대학 교수가 명목상 대표로 번역을 하는 형태로, 타이핑, 정정 등에 도움을 주었다는 이유로 역자 서문 말미에 자신을 도와 준 대학원생들 칭찬을 필요 이상으로 하는 경우다. 심지어 역자 서문이 없는 경우도 있다!

독자들이여, IT 서적을 구입하기전 반드시 역자 서문을 읽고 사시길. 역자 서문에서 그가 해당 분야의 지식에 대한 확신과 열정을 보여 주지 않고 쓸데 없이 번역 당시의 날씨 얘기나 하고 여자 친구, 애인에게 감사의 말만 적고 있다면 그 책은 다시 서가에 꽂힌 그대로 내려 놓아야 한다.

‘쉘(shell)’을 ‘껍데기’라고 말하는 사람과 함께 일할 수 있는가?
이제서야 겨우 오역(誤譯)이라 부를 수 있는, 아주 조금은 용서 가능한 번역 오류에 대해 얘기할 수 있을 것 같다. 타 분야도 마찬가지지만 IT 분야의 번역에서는 이 단어를 한글로 번역할 것인가 아니면 원어를 그대로 놔두고 발음대로 적을 것인가의 기로에 서게 된다.

object를 '객체'라고 적을 것인가 '오브젝트'라고 적을 것인가 고민하는 경우, 객체라는 번역어가 원어의 의미를 충분히 나타내므로 객체라는 번역을 선택한다. 그러나 객체의 method에 대해서는 어떻게 번역할까? '방법' 또는 '수단'이라고 번역하는 사람은 거의 없으나 '메쏘드'와 '메써드'라는 표기가 공존한다. 후자가 현지인(정확히 말해 미국인)의 발음에 가깝지만, 근본적으로 상대 언어의 발음을 완전히 표기할 수 없다면 로마자 표기 규칙을 따라야 하는 것 아닐까? 하지만 이 정도는 혼란의 축에도 끼지 못한다.

거창하게 분석철학까지는 아니더라도, 어떤 단어가 갖는 의미는 그 단어를 사용한 사람이나 문화가 가리키고 싶은 것을 가리킬 뿐, 문자 그 자체는 껍질이다. 어떤 단어가 IT 분야에서 사용될 때 원래의 일상적 의미와 전혀 관계없는 것은 아닐지라도, 실제로는 그 의미로 환원할 수 없는 경우가 대부분이다. 이런 취지에서 필자는 선택의 기로에 서면 항상 원어 발음을 선택하곤 한다.

IT 단어는 번역의 대상이라기 보다 사람의 이름처럼 대명사처럼 취급하는 것이 편하다. 그것을 굳이 한자어로 번역해도 괄호 속에 영어를 적는 것과 한자를 적는 것의 차이일 뿐이다. 무엇보다 필자는 IT 현장에서 쓰이지 않는 번역어를 써서 학습용 용어와 현장 업무용 용어를 별도로 구분하는 것은 잘못됐다고 생각한다.



이와 같은 논쟁의 대표적인 예가 유닉스용 명령 해석 프로그램인 shell을 '껍데기'라고 해석한 경우다. 굳이 도식화하자면 shell은 운영체제 커널(kernel, 이건 도대체 뭐라고 번역해야 하나? 옹이?)이 한 가운데 있고 사용자와 커널 사이의 얇은 층에 위치한다. 따라서 껍데기라고 번역하겠다고 우기면 할 말이 없다.

문제는 난데없이 껍데기라고 하면 아무도 알아들을 수 없으므로 이 ‘껍데기’가 어떤 의미라는 것을 다시 설명해야 한다는 사실이다. 적어도 커널 껍데기라고 해야 그나마 본래 뜻에 근접해 진다. 한편 쉘(shell, 셸이라고 적기도 한다!)의 종류 중 C 언어와 비슷한 문법을 쓰는 C shell이 있는데 이를 C 껍데기라고 한다면 부연 설명을 하지 않는 한, C에 대한 껍데기가 되고 만다.

대학생이 번역했으면 그냥 무시하고 넘어가도 좋겠지만, 인지도가 있는 대학의 교수라는 역자(이제는 필자가 제일 싫어하는 상태인 공동 번역 체계 즉 '역자들'로 바뀌었다)의 경우는 그 사회적 지위가 오히려 문제를 복잡하게 만든다. 무엇보다 이들이 번역한 책은 전세계적 권위를 가진 리차드 스티븐스의 명작이기에 유닉스 프로그래머로서는 피해 갈 수 없다는데 문제가 있다. 더구나 리차드 스티븐스는 이미 작고했기 때문에 새 판본을 기대할 수 없고 한국에서 그의 책은 영원히 현재 상태로 번역된 채 남아 있게 될 것이라는 생각에 우울한 마음까지 든다.

컴퓨터(computer)나 프로그래밍(programming), 소스 코드(source code) 같은 번역은 이미 논쟁거리도 아니다. 국어 사랑의 대의를 가진 비 IT 전문가 아닌 한, 셈틀이라고 번역하는 것을 본 적 없다. 이는 언어의 사회적 성격을 분명하게 보여주고 사례다. 단도직입적으로 말해 누군가 개발팀에 들어와서 쉘을 껍데기라고 우기고 패킷(packet)을 보쌈이라고 우긴다면 그와는 함께 일할 수 없다.

IT 종사자가 대화할 사람들은 IT 분야의 세계인이다
며칠 전에 병원에 가서 의사가 간호사에게 주사를 말할 때 인젝션(injection)이라고 표현하는 것을 들었다. 주사라는 말을 놔두고 굳이 인젝션이라고 해야만 했을까? 마찬가지로 IT 분야의 사람들이 찻집에서 서로 이야기하는 모습을 IT 문외한이 보면 어떨까? 분명한 것은 IT 분야 사람들이 대화하고 협동해야 하는 대상은 일반인이 아니라 오히려 같은 IT 분야의 세계인이라는 사실이다. 즉 번역서를 가지고 시작한다 하더라도 결국 전문가가 되기 위해서는 영어 원문과 대면해야만 한다.

고대 사람들은 그리스 문명을 이해하기 위해 그리스어를 공부했고, 우리나라 선비들은 한자를 알아야 했으며, 혜초 스님은 직접 인도에 갔다. 일정 수준에 이른 IT 전문가들에게 친절한 번역 문서는 존재치 않는다. 그럴 시간도 없고 이유도 없다. 영어와 IT 전문 용어는 IT 직업인들에게 있어서는 생계의 수단이지 의사나 법조인의 배타성과 비교할 수 없다.

따라서 IT 번역서는 IT에 입문하는 신입생들이 세계인으로 커갈 수 있도록 하는 연결 다리가 되어야 한다는 대전제를 세우고 싶다. 번역는 번역자의 개인적 이익이나 고집이 아니라 사회적 책임의식 아래 이루어져야 한다. 그렇다면 최종 소비자인 우리들은 악역과 오역에 대해 분노하고 자기 자리에서 할 수 있는 최소한의 행동(험담에서부터 시작해서)을 해야 하지 않을까?"