프로그램의 결함(버그) 중에는 찾기 쉬운 것이 있고, 찾기 어려운 것이 있습니다. 찾기 쉬운 것은 문법적인(syntactic) 오류입니다. 소위 컴퓨터가 이해할 수 없는 말이 포함된 경우이죠. 이런 것은 찾기가 쉽습니다. 코드의 이런 문제를 찾아주는 프로그램(컴파일러)도 있고요. 하지만 정말 찾기 어려운 버그는 의미론적(semantic)인 버그입니다. 코드를 읽어보면 일단 말은 되는데 문제가 숨겨져 있는 코드가 그렇습니다. 그런데 이런 구분은 글의 번역에도 존재합니다.

다치바나 다카시의 책, "나는 이런 책을 읽어왔다"에 다음과 같은 글귀가 있습니다.
 

번역서는 오역이나 나쁜 번역이 생각 이상으로 많다. 번역서를 읽다가 이해가 잘 되지 않는 부분이 있으면 머리가 나쁘다고 자책하지 말고 우선 오역이 아닌지 의심해 보라.

이해가 잘 안되는 번역이 있다면 다음 둘 중 하나 이상일 가능성이 높습니다. 1) 오역이다. 2) 번역자도 제대로 이해 못했다. 하지만 읽어서 이해 안되는 번역이 최악의 번역은 아닙니다. 이해가 안되면 오히려 고마운 경우입니다.

저는 번역 중에서 가장 못된 번역은 독자를 속이는 번역이라고 생각합니다. 어설프게 번역을 해서 말이 잘 와닿지 않는 경우, 이해가 안되는 경우는 그나마 낫습니다. 독자가 스스로 이해를 못했다는 사실을 인지할 수 있으니까요 -- 그 후에 필요하다면 원서를 찾아 비교해 보거나 하겠죠. 하지만, 원래 메세지와 다른, 또는 정반대의 메세지로 바꾸어서, 독자가 의식하지 못한 채 원저자의 의도를 다르게 받아들이게 만드는 번역은 정말 위험합니다. 독자에게는 원래 글에 대한 정보가 없기 때문에 완전히 속을 수 밖에 없습니다.

왜 이런 일이 벌어질까요? 저는 대부분 다음 두가지 요소의 복합으로 일어난다고 봅니다.

  1. 번역자가 원래 글의 의미를 제대로 이해 못했다.
  2. 번역자가 꼼꼼한 번역 훈련이 안되었다.

여기에 한가지 요소를 더하자면, 정직하지 못한 번역자를 꼽을 수 있습니다. 원문이 무슨 뜻인지 이해하지 못하고 그 사실을 감추기 위해 그냥 그럴싸한 문장을 만들어 넣습니다. 정직한 번역자는 우선 자기가 할 수 있는 최선을 다하고(각종 자료를 찾고, 자문을 구하고, 원저자에게 물어보는 등) 그러고도 확신이 안서는 경우 원문을 주석으로 넣어야 합니다.

이번 글에서는 2번, 꼼꼼한 번역에 대해 좀 더 이야기를 하고, 마지막으로는 꼼꼼한 번역을 할 수 있는 훈련법을 소개하도록 하겠습니다.

누군가가 정말 웃긴 이야기를 듣고는 다른 사람들에게 그 얘기를 해주면 아무도 웃지 않는 상황이 벌어지는 경우가 종종 있습니다. 우스개의 전체 줄거리가 틀리거나 한 것도 아닌데 왜 그럴까요. 작은 차이들에 있습니다. 어떤 단어 하나를 빼먹거나 어조를 놓치거나 등등. 어찌보면 작은 차이인데 결과는 차이가 큽니다. 웃거나 몰매 맞거나.

꼼꼼하지 못한 번역의 예를 몇가지 보도록 하겠습니다. 우선 제 방에서 굴러다니는 책 중 원서와 번역서가 모두 있는 책 두어권을 뽑고 거기서 임의의 페이지를 펼쳐서 비교해 보도록 하겠습니다. (책 선정과 페이지 선정은 순전히 우연이었기 때문에 번역자들께서 원망을 하지 않으셨으면 하며, 이 글에서 해당 책들의 전반적 번역 수준을 이야기하는 것은 절대 아니라는 점을 고려해 주시기 바랍니다)

조엘 온 소프트웨어

제가 가진 번역서 발행일은 2005년 4월 15일입니다.
번역원문
다중 표준 시간대 (p.72)multiple time zones for one member (p.56)

이번 소프트웨어에 포함되지 말아야 할 기능을 이야기하고 있는 대목입니다.

뭐가 문제일까요? 다중 표준 시간대를 다시 영어로 옮긴다면 multiple time zones라고 옮기겠습니다. 그런데 "for one member"라는 정보는 어디로 가버렸나요?

꼼꼼하고 정확한 번역은 다음과 같습니다. "한 회원이 여러 시간대를 사용하기". 느낌이 확 다르죠? 그냥 다중 표준 시간대라고 번역해 버리면 오해의 여지가 있습니다.

피플웨어


이번에는 피플웨어라는 책에서 찾아보도록 합시다. 번역서는 2003년 1월 16일에 인쇄한 책입니다.

우선 번역의 일부를 그대로 인용해 보겠습니다. 제 생각에 문제가 있는 부분은 강조 표시를 했습니다. 특히 그 부분에 주의해서 원문과 비교해 보시면 좋을 것 같습니다.

프로그래밍 언어 : 코볼이나 포트란 같은 구식 프로그래밍 언어로 코딩한 사람들은 파스칼(Pascal)이나 C언어를 사용한 사람들과 동일한 능력을 보여 주었다. 각 언어를 사용한 사람들 간의 능력 차는 전반적인 업무 능력차와 거의 똑같았다. 이에 대한 유일한 예외는 어셈블리(assembly)어를 사용하는 참가자들이었는데, 그들은 다른 언어를 사용하는 그룹들에 비해 뒤처졌다(그러나 어셈블리어를 사용하는 사람들은 계속 뒤처져 있었다). (p.81)

글을 읽으면 이해하는 데에 별 문제가 없는 번역이라고 느껴집니다(맨 마지막 문장의 괄호속 글을 빼고는). 하지만 원문을 비교해 봅시다.

Language : Those who coded in old languages like COBOL and Fortran did essentially as well as those who coded in Pascal and C. The spread within each language group was much like the overall spread of performance. The only exception to this observation about language was assembly language: The assembly language participants got badly left behind by all the other language groups. (But, then, people who use assembly language are used to being left behind.) (p.47)


문제가 몇 가지 있습니다.

1) 동일한 능력

우선, essentially가 우리말 번역글에 전혀 의미 참여를 하고 있지 못합니다. 여기서 essentially는 "거의"나, "근본적으로" 정도의 말로 번역할 수 있습니다. "...구식 프로그래밍 언어로 코딩한 사람들은 파스칼(Pascal)이나 C언어를 사용한 사람들과 동일한 능력을 보여 주었다."라고 번역했는데, 그 번역의 구조를 되도록 유지하면서 좀 더 꼼꼼하게 번역한다면 다음과 같습니다. "... C언어를 사용한 사람들과 근본적으로 대등한 능력을 보여 주었다." 원저자는 절대 동일한 능력을 보여 주었다고 말하지 않았습니다. 만약 저 번역을 영어로 다시 옮긴다면 "showed identical performance"어쩌구 하는 말이 나오겠죠.

2) 각 언어를 사용한 사람들 간의 능력 차

오해의 소지가 다분한 번역입니다(예컨대, 코볼 사용자와 포트란 사용자, C 사용자들 사이의 능력 차를 말하는 것 같습니다). 원번역의 구조를 되도록 유지하면서 좀 더 꼼꼼한 번역은 다음과 같습니다. "각 언어 사용자 집단 내에서 그 사람들 간의 능력 차는 전체 집단 내의 능력 차와 매우 유사했다". 그리고 능력 차라고 하는 것보다는 "능력 분포"라고 하는 것이 더 꼼꼼하고 정확한 번역입니다.

3) 그들은 다른 언어를 사용하는 그룹들에 비해 뒤처졌다

badly가 우리말 번역에서 완전히 배제되어 있습니다. 그냥 뒤처졌다는 이야기를 하는 것이 아닙니다. 매우 뒤처졌습니다. 매우 하나 빠트린다고 큰일 날까요? 납니다. 두 사람의 대화를 통역하다가 정도 표현 부사 하나 빠트리면 살인도 날 수 있습니다.

꼼꼼하게 번역하면 다음과 같습니다: 그들은 다른 언어를 사용하는 어떤 그룹보다도 심각하게 뒤처졌다

4) 그러나 어셈블리어를 사용하는 사람들은 계속 뒤처져 있었다

무슨 뜻인지 잘 이해가 되지 않는 문장입니다. 번역자가 제대로 이해를 못한 문장이라고 봅니다. be used to를 과거를 나타내는 표현으로 이해했나 봅니다. 그러면 도무지 이해가 안되죠. 여기서 be used to는 익숙하다는 뜻입니다.

정확한 번역은 다음과 같습니다: 그렇긴 하지만 어셈블리어를 사용하는 사람들은 뒤처지는 데에 원래 익숙하다.





대부분 한 두 단어 빠트린 예인데, 이번에는 엉뚱한 단어와 의미가 번역자에 의해 첨가된 경우를 보겠습니다. 역시 같은 페이지에서 찾았습니다. (강조는 제가 했습니다)

... 대회에서 사용한 프로그래밍 언어를 경험한 지 6개월 미만인 사람들이 나머지 사람들보다 잘하지 못했다는 사실을 제외하고는 경력과 업무 수행 능력은 깊은 상관성이 없었다.

원문입니다.

There was no correlation between experience and performance except that those with less than six months' experience with the language used in the exercise did not do as well as the rest of the sample.

문제는 "깊은 상관성이 없었다"에서 '깊은'이 도대체 어디에서 끼어들어온 단어냐 이겁니다. 그냥 경제적으로 간결하게 "상관성이 없었다"라고 하면 될 것을 왜 굳이 역자가 불필요한 의미를 첨가했는지 모르겠습니다. 일단 문장의 의미를 이해하고 그걸 머리 속에서 국어로 대충 재생산해내면서 번역해서라고 봅니다. 그런 번역도 하나의 스타일로 치는 사람들이 있습니다만 저는 그걸 스타일로 보지 않습니다. 좋지 못한 번역이고, 꼼꼼하지 못한 것이죠.





같은 페이지에 문제가 되는 문장이 더 남아 있습니다. 하나만 더 보죠. 이 문장은 그야말로 꼼꼼하지 못한 번역의 대표로 꼽을만 합니다. (역시 강조는 제가 했습니다)
번역원문
사실 무결함 집단은 평균 한두 개의 결함도를 보여 준 집단보다 더 빠른 시간 내에 과제를 끝냈다.
In fact, they took slightly less time, on the average, to complete the exercise than those who had one or more defects.


세가지 문제가 있습니다.
  1. 평균 : 이 평균은 아마 on the average의 번역 같은데, on the average는 slightly less time을 꾸며줍니다. one or more defects가 아니고요. 그런데 위 번역에서는 "평균적으로"도 아니고 "평균"이라고 했기 때문에 당연히 "평균 한두 개"로 오해하게 됩니다.
  2. 한두 개의 : 한두 개가 아닙니다. 하나 이상입니다. 의미가 완전히 바뀌죠.
  3. 더 빠른 시간 내에 : 그냥 더 빠른 시간이 아닙니다. 약간 더 빠른 시간입니다.

제가 생각하는 꼼꼼한 번역은 다음과 같습니다.

사실 무결함 집단은 하나 이상의 결함도를 보여 준 집단보다 평균적으로 약간 더 빠른 시간 내에 과제를 끝냈다.


훈련법


좀 과격하게 말하자면, 꼼꼼하지 못한 사람은 번역하면 안된다고 봅니다. 그런 사람은 우선 꼼꼼한 언어 사용 훈련을 받아야 합니다. 말을 예리한 수술용 칼처럼 정밀하게 쓰고, 또 조심스럽게 다루는 훈련을 해야 합니다.

간단한 훈련법이 있습니다. 원문을 번역합니다. 그 다음(하루 정도가 지난 후라면 더 좋음) 자신이 번역한 글을 보고 다시 영어로 옮겨 봅니다. 둘의 차이가 적으면 적을수록 좋습니다. 이 훈련이 된 다음에야 비로소 의역이니 맛깔스러운 번역이니 뭐니를 이야기할 수 있습니다. 번역 실력이 부족한 사람일수록 정직하고 소박하게, 꼼꼼하게 번역해야 합니다. 그래야 실력이 늡니다.

참고로 위 훈련은 프로그래머에게도 효과적입니다.

피터 노빅(Peter Norvig)은 "영어 번역 법칙"(Rule of English Translation, 출처는 Tutorial on Good Lisp Programming Style)을 이야기 합니다. 그 단계는 다음과 같습니다.
  1. 알고리즘을 영어로 설명한 것에서 출발한다.
  2. 그 설명으로부터 코드를 작성한다.
  3. 코드를 다시 영어로 번역한다.
  4. 3과 1을 비교한다.

폴리야는 수식화 과정의 어려움은 결국 번역의 어려움이라고 말한 바 있습니다.
 

To set up equations means to express in mathematical symbols a condition that is stated in words; it is translation from ordinary language into the language of mathematical formulas. The difficulties which we may have in setting up equations are difficulties of translation.


꼭 영어 번역 법칙에 따른 훈련을 하지 않더라도, 프로그래밍에는 번역 과정이 필연적으로 들어갑니다. 우리 뇌 속에서 말이죠. 내가 생각하는 것을 어떻게 이 프로그래밍 언어로 표현하느냐, 이것은 번역의 문제입니다. 저는 번역 능력과 프로그래밍 능력에 어느 정도 상관성이 있을 것이라 생각합니다. 그래서 같은 맥락에서 프로그래머도 기본적으로 꼼꼼해야 한다고 봅니다.

--김창준