꼼꼼한 번역

프로그램의 결함(버그) 중에는 찾기 쉬운 것이 있고, 찾기 어려운 것이 있습니다. 찾기 쉬운 것은 문법적인(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.


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

--김창준

by 애자일컨설팅 | 2008/06/07 01:10 | 트랙백(3) | 핑백(4) | 덧글(10)
트랙백 주소 : http://agile.egloos.com/tb/4407296
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from june's me2DAY at 2008/06/07 01:55

제목 : 김창준의 생각
꼼꼼한 번역...more

Tracked from Eclipse for .. at 2008/06/22 04:02

제목 : 기술서적 번역에 대한 짧은 생각
사실 우리나라 여건에서는 현재의 시스템이 그나마 번역서가 지속적으로 나올 수 있도록 출판사 분들이 고육지책으로 만들어놓은 시스템이 아닌가 합니다. 출판 시스템을 좀 더 자동화했으면 좋겠다는 생각은 많이 합니다만, 국내 독자들 눈높이가 원서보다 오히려 높아서 편집에 손이 많이 가는 바람에 그것도 힘들다고 하네요. ...more

Tracked from Younghoe.Info at 2008/07/03 13:03

제목 : 점심시간 서핑을 하다가... 영문 이해에 관한 좋은 글
물개형 블로그에서 오래된 글... 좋지 않은 번역에 대해서 왈가불가 댓글이 달리는 와중에, 당시에는 못봤던 좋은 글이 있었다. First-Class Value 나 First-Class Object란 말은 적어도 수십년 전부터 써오던 말입니다. 더구나, Object란 말은 한 언어에서 어떤 값을 나타내기 위해서, 그 언어가 정해놓은 모형에 따라 만들어 쓰는, Memory Image를 뭉텅거려 나타내는 말로 써왔기 때문에, 스스로를 이른 바 물체 ......more

Linked at 天劍之道 : [펌] 꼼꼼한 번역 at 2008/06/08 16:09

... 링크 : http://agile.egloos.com/4407296저도 기술 문서 및 전산학 원서의 허접한 번역일을 몇번 해봤지만 애자일님의 이번 글을 참으로 깨우치는 바가 크네요.정리 : (피터 노박이 제안하 ... more

Linked at Eclipse for Ever.. at 2008/06/22 04:23

... rything - javanese Let’s write eclipse RCP apps { 2008 06 22 } 기술서적 번역에 대한 짧은 생각 애자일 이야기 블로그에 번역에 대한 글이 올라왔습니다. 본문,댓글 모두 깊이 공감이 가고 찔리는 점도 많습니다. ^^ 컴퓨터 기술서적 번역에 관심 있으신 분은 읽어보시기 바랍니다. 일단 컴퓨터서적 번역은 일반적 ... more

Linked at 애자일 이야기 : <아웃라이어.. at 2009/03/26 14:56

... 지난번 글(1만 시간 법칙에 대한 오해)에서도 언급을 했던 아웃라이어라는 말콤 글래드웰이 쓴 책의 오역에 대한 이야기입니다(예전에도 오역에 대해 글을 쓴 적이 있죠).저는 책 나온다는 소문이 돌 때부터 아마존에 주문을 걸어놓고 있다가 출간되지 마자 원서를 받아서 갖고 있었는데 그 책을 다 읽기도 전에 번역이 나와서 놀 ... more

Linked at 잠보니스틱스 : 오늘의 오역계.. at 2009/10/23 00:10

... 정리 (수정 1.3) (PHugsy님) ★그래도 우리 딸이 무슨 잘못이겠어요........ (청룡하안사녀님) ★다른 게임의 오역이야기도 해 볼까요.. (청룡하안사녀님) ★꼼꼼한 번역 (애자일컨설팅님) ★의 오역 몇가지 (애자일컨설팅님) ★오역 논란의 한 가지 사례 (로쟈님) ★마르크스주의 이후의 마르크스주의 - 자크 데리다 (정윤수님) ★오역 ... more

Commented at 2008/06/07 10:21
비공개 덧글입니다.
Commented by spatialguy at 2008/06/07 22:48
번역을 하는데 에 어려움을 느끼는 것 중 다른 하나로는, (현재 Ruby 서적 번역 중에 있습니다.)
컴퓨터 관련 언어들 중 '한글 표준화'되어있지 않은 것이 너무도 많다는 점도 있습니다.


'함수 A는 B를 리턴 한다.'가 맞는지 '반환 한다.'가 맞는지와 같은 작은 내용부터,

string을 문자열이라고 해야 할지, 스트링이라고 해야 할지 와 같은 단어의 선택문제.
in-place method의 경우엔 '인 플레이스 메서드'라고 써 놓으면, 왠지 죄짓는 것 같고,(번역을 안 한 것이 되므로.)
'HTTP is a stateless protocol'은 'HTTP는 상태를 저장하지 않는 프로토콜이다.'라는 말도 안 되는 한글을 쓰는 것도 안 좋고.
object persistence는 '객체 영속성'이라는 다소 친숙하지 않은 한자어를 쓰는 게 맞는지.

번역을 하다가 문제에 부딪혀서, 전공 번역서를 찾아보면, 너무도 불편한 한자말 ( ex: blocking -> 봉쇄형 ) 도 넘쳐나고.
syntactic 에러를 잡기 위해선, 표준화된 문장이 약속 되어 있어야 하는데..

따라서 개인의 언어적인 능력문제도 따라가 줘야 하겠지만,
컴퓨터공학 언어들을 한글 표준화도 필요한 것 같습니다.
Commented by 영록 at 2008/06/07 23:30
전반적으로 공감하지만 저 정도로 열심히 번역하면 번역 단가가 안 맞을 것 같다는 생각이 드는군요. 저도 이번에 책 번역을 두번째로 해봤는데 아무리 생각해도 수지가 안 맞는다는 생각이 들더군요. 물론 번역이 돈 버는 일만은 아니겠지만 국내 기술서적들의 번역이 만족스럽지 않은 결정적인 이유는 번역비가 싸다는 것, 그리고 번역비를 많이 줄 수 없을 만큼 책이 적게 팔린다는 것이 아닐까요.
Commented by 애자일컨설팅 at 2008/06/08 00:32
맞습니다. 우리나라에서 기술서적을 번역하면서 그것만으로 먹고 살 생각하는 것은 아직은 시기상조인 것 같습니다. 저도 번역할 때 돈 벌 생각보다는, 저 훌륭한 책을 직접 번역해보고 싶다는 개인적 바람이나, 좋은 음악은 주변사람들에게도 들려주고 싶은 마음 등의 이유로 번역하게 됩니다. 그러면서 책 한 권 나올 때마다 다짐하죠. 이제는 번역 그만해야지. 그러면서도 또 번역 청탁에 오케이하기도 합니다.

번역을 프로그래밍에 비견해 보면, 말씀하신 경우를 단가가 안 맞을 것 같아서 늘 결함 적당히 섞인 프로그램을 만드는 프로그래머에 대입해 생각해 볼 수 있습니다. 그 사람은 자존감이나 자부심, 전문가 정신, 업무 만족도 등이 대체로 낮을 것 같습니다. 피터 드러커가 흔히 말하는 피디아스의 "하지만 신은 뒷면도 봅니다"는 대사에서 비춰지는 장인 정신 같은 뭔가가 결여된 것이죠. 번역자도 비슷할 것 같습니다.

그에 합당한 금전적 가치는 손에 쥐어지지는 않지만, 그래도 자기애나 자부심, 뿌듯함 같은 것에서 오는 비물질적 가치는 행복감이라는 면에서 무시 못하지 않나 생각이 듭니다.

하지만 번역이라는 작업(더 크게는 지식 노동)에 대한 독자적 가치 인정이 충분히 되고 있지 못하기 때문에 아직까지는 전업 번역가로 활동하기가 쉽지 않다고 생각합니다. 임시 방편은, 높은 품질이 필요한 고객을 주요 타겟으로 삼는 것, 출판/유통 비용을 낮추어서(예컨대 lulu.com) 번역자에게 돌아오는 이윤을 높이는 것 등이 있겠습니다.
Commented by Q at 2008/06/08 09:06
그냥 용돈벌이나 할까 하고 번역하는 사람들이 많아서 일어나는 폐해가 아닐까 싶네요.
Commented by 꼼꼼함만으로 at 2008/06/08 10:27
저도 쓰신 글에 전체적으로 공감합니다.

저도 번역해 본 경험이 있습니다. 이 번역이란 작업이 단순히 꼼꼼함이 있다고
잘 할 수 있는 일이 아닙니다. 우선 IT서적 번역의 경우, 해당 분야의 높은 IT 지식,
독해 능력, 가장 중요한 것은 이해한 것을 읽기 쉽고 이해하기 쉬운 한글로 풀어 쓸 수 있느냐...
이런 능력과 꼼꼼함, 성실성이 합쳐졌을 때 좋은 번역이 나옵니다.

문제는 번역이 상당한 전문분야임에도 불구하고, 받는 돈은 편의점 알바비보다
작다는 점입니다. 물론 지적해 주신 것처럼 소양이 안 되는 번역가 자질도 문제지만...
이게 단순히 번역가의 문제로 치부해 버리면 영원히 답이 없는 문제입니다.

옳은 말씀이지만... 번역시장의 답답함을 경험해 봤기에 답이 없는 것 같아서요.
Commented by daybreaker at 2008/06/08 22:31
번역도 번역이지만 뒤에 설명하신, 말로 쓰여진 알고리즘을 실제 코드로 만드는 과정... 이거 상당히 어렵더군요.
저는 특히나 설명하는 사람이 '이건 당연히 알겠지'라고 자기의 기준에 따라 임의로 생략해버린 부분이 있으면 잘 받아들이지 못하는 편입니다.
그런데 알고리즘 설명하는 내용들을 보면 그런 부분들이 종종 나타나 괴롭더군요.
경험이 많은 친구들은 이게 이런 걸 말하는 것이다-라고 바로 알아보지만 그렇지 않은 사람이 따라가기엔 좀 문제가 있지 않나 싶습니다.
그래서 저는 뭔가 설명할 때 굉장히 세세한 디테일도 놓치지 않고 하는 편인데 그러면 또 오히려 너무 말이 많다는 소리를 들을 때도 있고...-_-;;
Commented by 배고픈바보 at 2008/06/09 20:58
오늘 서점가서 저도 비슷하게 따라해봤습니다. '리팩토링 데이터베이스'란 책의 한 챕터를 한글판, 영문판으로 봤습니다. 요즘 원서를 많이 봐야하는 상황이라서 그런지 영문판이 오히려 더 눈에 잘 들어오더군요. 물론 한글판을 먼저 봐서 그럴 수 있겠습니다만, 우리말로 된 컴퓨터 용어에 생소해 그런 것 같아요. spatialguy의 의견에 동감합니다.^^
Commented by 담벼락 at 2008/06/13 22:43
가끔은 저도 번역서를 읽으면서 원문에는 어떻게 나왔을까 비교해보고 싶은 구문이 있기도 하더군요.
반대로, 한글로된 클라이언트 프로그램을 영어로 번역하는데, 전문번역가가 했다는데 사용성과는 떨어진 번역(따지면 뜻은 맞는거 같으나 전달의 의미는 약한)이 많더라구요.

이야기를 약간 틀어서,
재밌는게 있는데, 외국에 나가서 관광 안내서 같은거...한글/영어 동시에 놓고 보면 가관이죠..일본은 특히 죽입니다..

마지막으로~
원저자는 번역판이 다른나라 언어로 출판되어 나갈때 번역수준이 어떨지 많이 궁금해 하겠죠?
저는 책 보고 리뷰도 잘 안쓰는 사람이었는데, 감동받은 번역서가 있어 원저자에게 안되는 한글로 쓴 리뷰내용을 영어로 번역하여 메일을 보낸적이 있는데,
번역이 잘 되었냐고 물어보더라구요.

번역의 훈련법 너무 공감합니다.
프로그래밍과의 비교도 재밌네요.
Commented at 2009/02/14 19:33
비공개 덧글입니다.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >