번역료 측정이 잘못됐다.

번역 이야기를 하다보니 이전부터 생각해둔게 있어 글을 분리해서 적어 볼까 한다. 내가 번역을 하고 있다고 하면 사람들이 가장 먼저 물어보는게 바로 “얼마나 받는가?”라는 질문이다.

출판사와 계약서를 쓸 때 이 부분에 대해서는 항상 비밀로 한다. 외부에 공개하면 안된단다. 그런데 막상 새로운 역자를 꼬시거나 역자들과 이야기 하다보면 자연스래 어느정도 되는지 이야기하게 된다. 그렇다고해서 그게 무슨 문제가 되는지는 모르겠다.

공사장에서 노가다를 할 때 이틀에 7만원을 받았었다. 주말 토,일을 공사장에가서 벽돌을 나르고 시멘트를 나르고 청소를 하면 점심때 밥을 준다. 밥은 공짜다. 먼지가 많아 힘들지만 나름 체력도 단련되고 돈의 소중함을 느낄수 있는 일자리다.

이렇게 적는다고 해서 뭐가 달라지는가…

번역을 하면 장당 계약을 할 수도 있고 인세 계약을 할 수도 있는데 보통 장단 계약을 한다. 모바일 계열 책이 아니면 잘 팔리지 않는 요즘 한국 IT 출판 업계를 생각하면 그게 어쩜 번역자에게 더 유리할 수도 있다. 장당 얼마인지는 말하지 않겠지만 평범한 개발자가 버는 돈을 시간단위로 환산한 금액에는 턱없이 모자를 것이다. 그렇다고 적은 돈도 아니고 어찌보면 딱 적당할 수도 있다. 대신 번역이 끝나고 책이 나오는 순간에 해냈다는 성취감을 맛볼 수 있으며 끈기를 기를 수 있다. 또 해당 책을 진득하게 볼 수 있으니 아주 ‘잘’까지는 아니어도 ‘대충’이나마 해당 주제에 대한 지식을 습득할 수 있다.

어쨋든 번역은 돈만 보고 하기에는 무리가 있다. 다른 업계는 어떤지 모르겠지만 IT 서적 번역 중에 내가 경험한 번역료 측정 방법은 세가지다.

  • 1. 건당
  • 2. 원문 장당
  • 3. 번역문 장당

1. 건당

이코인을 받을 때 대충 건당으로 받은 것 같다. 물론 페이지 수가 많으면 이코인을 많이 받고 페이지 수가 적으면 조금 받았지만 그 기준이 애매했다. 원문 PDF 파일 같은게 아니라 단순 웹 페이지라 ‘장’을 계산하기 애매한 경우가 있어서 아마도 번역한 원고를 기준으로 세페이지 이내면 얼마 넘으면 얼마 또한 대여섯 페이지 넘으면 얼마.. 이런식으로 측정했던 것 같다. 어차피 받는돈이 이코인이었지마나 나름 쏠쏠했다. 몇건만 하면 책 몇권은 쉽게 살 수 있었다.(캬캬캬 도무지 얼만지 상상이 안되게 적었지만.. 괜찮단 얘기다.)

2. 원서 원고 장당

현재 출판사에서는 이 방법을 가장 많이 사용하고 있다. 원서 페이지당 얼마를 준다. 그 페이지에 글자수가 얼마나 있든 상관없다. 난 이게 불만이다. 내가 번역했던 하이버네이트 책의 1장은 글자만 있다. 그림이나 코드가 한 줄도 없다. 엄청나게 힘들다. 코드가 많이 들어있는 장에 비하면 번역랴이 두배에 달할지도 모른다. 또 글자만 있는 장은 보통 난이도가 높다. 코드는 대충 눈대중으로 보면 어떤 내용일지 상상이 되니까 쉽다. 근데 말이 많으면 어렵다. 난 그때부터 이런 측정 방법이 바꼈으면 좋겠다는 생각을 했다.

3. 번역 원고 장당

대학교때 잠시 매우 페이가 좋은 번역을 할 수 있었다. 예산이 풍부한 곳에서 진행한 번역이었는데 번역료 계산 방법이 독특했는데 지금 생각해보면 가장 이상적이었다. 내가 번역한 것을 원고지 형태로 변환해 원고지 장단 번역료를 지급해줬다. 워드에서 한페이지를 원고지 보기로 변환해보면 대충 A4 한장 꽉차게 번역한 내용이 원고지로 3~4장 정도 나온다는 걸 알 수 있다. 그런데 장단 번역료가 2번 방법의 번역료와 비슷하거나 많았다. 이정도면 번역만 해도 먹고 살만하겠구나 싶었지만 지금은 그 일이 없어졌다. ‘돈’이 되서 그런지.. 다른 업체에 일을 맡긴것인지 예산이 없어 자체 해결하는지 모르겠지만 언제든지 요청이 오면 다시 하고픈 알바다.

이 글을 읽다보면 혼란스러울 수 있다. 돈 때문에 번역하는게 아니라면서 왜이렇게 번역료에 집착하냐고?

난 돈 때문에 번역하는게 아니라고는 했지만 그렇다고 그릇된 가치평가를 받으면서 일을 하고 싶지는 않다. 번역료가 짜도 상관없다. 어차피 대동소이한 번역료이고 내가 번역하는 목적은 뿌듯함, 끈기, 성취함, 학습이 주요 목적이다. 그렇다고 원치않는 일(용어 고민, 감수, 일정압박, 번역이 개판이라고 욕먹기)이 따르는 번역을 하면서 페이를 안받을 순 없지 않은가. 페이는 적든 많든 받아야된다. 그런데 되도록이면 올바른 측정 방법이면 좋겠다.

내가 원하는 측정 방법은 3번이다. 2번의 문제점은 너무 분명하다. 그림과 코드가 많은 책은 번역하기 쉽다. 말이 많은 책은 번역하기 어렵다. 그런데 장당 받는 돈은 똑같다. 비합리적이지 않은가. 공동번역으로 가면 문제는 더 복잡하다. 누군 그림과 코드가 많은 곳을 번역하고 누군 말이 많은 곳을 번역한다. 번역량을 조절하면 되지만 페이가 달라진다. 거의 절반의 돈을 받고 일하는 거나 마찬가지다.

그러니 번역료는 번역한 원고를 기준으로 책정하는게 맞다고 생각한다. 그래야 역자가 번역하기 쉬운 책을 골라 번역하는 현상도 줄일 수 있고 말이 많은 책이어도 좋은 책이라면 번역할 용기를 낼 수 있지 않을까 싶다.

그밖에도 원고료 측정에 고려해야 할 요소들이 몇가지 더 있는것 같다. 번역자의 실력, 경험에 대한 가치를 고려해야 한다. 누군 감수하는데 한시간이면 충분할 정도로 번역하고 누구는 대여섯시간의 감수가 필요한 수준으로 번역을 해도 같은 페이를 받는다면 어찌될까. 지금은 어떻게 되고 있는걸까? 다른 역자들이 얼마나 받는지 몰라서 난 모르겠다. 내가 허접하고 발전이 없으니 게속 같은 돈이겠거니 생각하는게 속 편할지도..?

역자가 얼마나 마감일을 잘 지키느냐 역시 중요한 포인트다. 하지만 고려하는지 어쩌는지 모르겠다. 역자의 편의를 많이 봐주고 있는 것 같긴한데… 뭐.. 기일이 별로 중요하지 않을 수도 있으니.. 흠.

역자의 역할도 중요하다. 역자에게 감수까지 맡길 계획이라면 페이를 더 줘야 하는것 아닐까? 근데, 과연 감수까지 할 수 있는 역자가 얼마나 될까. 그정도는 출판사에서 외주를 주던, 자체 감수자를 키워서 해결해야 하지 않을까.

어쨋든 생각해보면 올바른 가치평가를 위해 고민해야 할 것들이 제법인데 한국 IT 출판 업계와 역자들은 참 착하다. “원고 장당 얼마”라는 단순한 원칙을 계속해서 유지하고 있다니…

맘에 안들지만 그렇다고 안할 순 없다. 소일거리로 번역만큼 재밌고 유익한 일을 아직 못찾았기 때문이다. 그래서 난 그냥 이 시스템을 최대한 활용할까 한다.  IT 출판 업계가 2번을 고집하는한 나는 앞으로 번역하기 쉬운책만 골라서 번역할 생각이다. 근데;; IT 서적은 대게 번역하기 쉬운책들이 많다. ㅋㅋㅋ 비겁하다고 비난해도 좋지만 책 한 권이라도 번역한 다음에 비난해 달라!!

ps: 참.. 혹시 번역하고 싶으신 분들은 각 IT 서적 출판사에 직접 연락하셔도 되는데,, 그게 좀 왠지 어렵다고 느껴지시는 분들은 저한테 간단하게 번역한 문서를 첨부해서 메일로 보내주시면 제가 아는 출판사(위키북스, 에이콘, 한빛) 쪽으로 소개시켜 드릴께요. 언제든지 도전하세요.ㅋㅋ 특히 대딩들.. 괜히 신입생때부터 면접준비 같은거 하지마시고.. 그 시간에 번역하면서 수양이나 하세요.

[번역] 띄어쓰기

  • 여러가지 -> 여러 가지
  • 받아들일테지만 -> 받아들일 테지만
  • 불러 일으킬 -> 블러일으킬
  • 한가지 -> 한 가지
  • 것들 보다 -> 것들보다 (조사는 붙여 쓴다.)
  • 갱신하는데 -> 갱신하는 데 (~하는 데는 띄어 쓴다.)
  • 새로고침 -> 새로 고침
  • 일반화 되어가고 -> 일반화되어가고 (~되다는 붙여 쓴다.)
  • 들어있는 -> 들어 있는 (합성어 아님)
  • 상호 작용 -> 상호작용 (~작용은 합성어)
  • 치우쳐있다 -> 치우쳐 있다.
  • 패이지 라는 -> 페이지라는
  • 할당 받은 -> 할당받은
  • 사용자 마다 -> 사용자마다
  • 수백만명 -> 수백만 명 (단위는 띄어 쓴다.)
난 번역으로 먹고 살 수 없다. 한 시간에 한 장을 할까말까한 실력, 그나마도 교정이 많이 필요한 수준이다.
번역은 대학교 3학년 일때부터 꾸준히 해왔으니 개발 경력보다 오래됐고 스터디 경력과 비슷한 5년 정도인 것 같다. 물론 처음부터 책 번역을 할 생각은 없었고 취미 삼아 관심가는 주제의 글을 찾아 번역해서 이코인을 모아서 책을 샀다. 그때 모아둔 이코인으로 최근에도 공짜로 책을 산적이 있다. 한빛출판사에 오라일리 기사를 번역해주면 되는건데 요즘도 진행중인것 같다. 나같이 별로 돈이 없는 대딩들에겐 책을 살 수 있는 좋은 방법이니 시도해보면 좋겠다. 공부도하고 책도 생기니 얼마나 좋은가..
어쿠.. 광고하려던게 아닌데.. 어쨋든 핵심은 5년이나 번역을 하고 있는데 실력이 안는다는 것이다. 최근데 ‘번역의 탄생’을 읽었는데 정말 많은 도움을 받을 수 있는 책이다. 이 책을 읽고나서 번역한 문장들은 아주 조금 나아졌다는 생각이 들지만 그래도 이 책의 내용이 하두 많아서 그새 잊어버린게 많다. 언젠가 날 잡고 위키에 정리하거나 출력해서 심심할 때 보고 다니면 좋겠다.
게다가 제대로 된 교정을 받아 본적이 없다. 그나마 하이버네이트 책을 번역할 땐 대엽님이 검수 역할을 맡아 이것저것 손을 봐주셔서 조금 더 나은 번역 방법과 번역의 기초를 연마할 수 있었지만 대엽님이 전문 검수자도 아니고 공동 역자 중 한 명일 뿐이었는데 너무 많은 짐을 드리는 것 같았다.
그래서 이번에 번역할 땐 내가 받는 피드백을 하나 하나 잘 정리해 둘까한다. 분명히 또 잊어버리고 해매겠지만 내가 자주 고민하고 틀리는 어법이나 표현방법 중심으로 정리해두면 조금은 나아지지 않을까.


FUD는 Fear, Uncertainty, Doubt

참조: http://www.catb.org/jargon/html/F/FUD.html

Defined by Gene Amdahl after he left IBM to found his own company: “FUD is the fear, uncertainty, and doubt that IBM sales people instill in the minds of potential customers who might be considering [Amdahl] products.” The idea, of course, was to persuade them to go with safe IBM gear rather than with competitors’ equipment. This implicit coercion was traditionally accomplished by promising that Good Things would happen to people who stuck with IBM, but Dark Shadows loomed over the future of competitors’ equipment or software. See IBM. After 1990 the term FUD was associated increasingly frequently with Microsoft, and has become generalized to refer to any kind of disinformation used as a competitive weapon.

번역하다가 등장해서 난항을 겪다가 대엽님 도움으로 알게 됐습니다. 캬오~ 저런 단어가 있었군요. 흠.. 저런 단어는 한글로 옮기기가 좀;; 그냥 FUD라고 쓰고 주석을 달거나, 풀어서 써야겠습니다.

Pros and Cons of language oriented programming

Language Workbenches 번역 중에 일부분입니다. 현재 제대로 된 번역은 영회 형 블러그에 연재 중입니다. 🙂

먼저 해석 및 번역이 어려웠던 문장들 부터 정리해 봅니다.

However you’ll probably come acrossthe embedded term if you look around at more writing on DSLs.

기선 : ???
영회 :
하지만, DSL에 관련된 많은 글에서 포함된 DSL가 같은 표현을 자주 보게 될 것이다.

Parser generator and compiler compiler tools existthat can help you manipulate quite complex languages, andof course the whole point of DSLs is that they are usually quite simple.

기선 : 파서 생성기와 컴파일러 도구는 매우 복잡한 언어에서 작업할 때 도움이 된다. 그리고 물론 DSL의 주요한 점은 매우 간단하다는 것이다.
영회 :
파서 생성기와 컴파일러 저작 도구는 매우 복잡한 언어를 DSL다룰 때 도움을 준다. 게다가 DSL은 대개매우 간단하다.

This lack of integration hitsus in lots of ways with tooling.

기선 : 통합의 결여는 툴을 사용하도록 한다.
영회 :
통합의 결여로 인해 도구가 필요해진다.

We also have the full power of our base languageavailable to us at all times, together with all thetooling that exists in our base language.

기선 : 또한 항상 기반 언어에서 사용가능 한 특성들을 모두 사용할 수 있어야 한다.
영회 :
해당 언어에서 사용 가능한 모든 특성들을 활용할 수 있다.

While much of this machinery is missing from Cbased languages, we’re seeing features that can supportsome of this thinking.

기선 :  C 기반의 언어들은 이러한 기능이 빠져있는 반면, 이러한기능을 지원할 수 있는 특성을 찾는다.
영회 :
C에 기반하고 있는 언어들은 내부 DSL 작성에 적합한기능이 많이 빠져 있지만, 존재하지 않는 것은 아니다.

Ideally you want only the actual tools you need foryour job – certainly no less, but only a few more.

기선 : 이상적으로 사용자가 실제로 작업에 필요로 하는 툴만을 원할 것이다.
영회 :
이상적인 것은 어떤 작업을 수행하는데 꼭 필요한 기능만 제공하는 즉, 부족하지 않으면서 너무 많은 것을 제공하지는 않는 개발도구이다.


아직 끝까지 차이를 정리한 것이 아니라 다음에 추가로 수정을 해야겠습니다.

그리고 아래는 영회형이 지적 해 주신 수정사항입니다.

1. one of ~ 를 ~ 중에 하나로 번역하면.. 매우 어색하다.
2. COBOL inference – that mosttechnologies that are supposed to eliminate professional programmersdo nothing of the sort.
이 부분은 완전히 반대로 해석했다.

mosttechnologies that are supposed to eliminate professional programmers/ do nothing of the sort.
앞 부분 전체가 주어부인.. 상당히 복잡한 구문이지.

This reminds us of what I call the COBOLinference – that most technologies that are supposed to eliminateprofessional programmers do nothing of the sort.

기선 : COBOL inference란 대부분의 기술들이 전문적인 프로그래머들이아무것도 할 일이 없도록 발전한다는 것이다.
영회 :
이는 내가 코볼 추론(COBOL inference)이라고말하는 것을 떠올리게 한다. 대부분의 기술의 등장으로 전문적인 프로그래머가 사라질 것이라는 소문이 나돌지만그런 일은 벌어지지 않는다.

3. gettingdirect user input into programs
사용자를 참여시키는 것이 아니라 사용자의 입력을 프로그램에 넣는 것이지.



ps …

기선 :
영회 형:

이렇게 하다보니 어색해서..

기선 :
영회 :

이렇게 했습니다. ^^;;

Traditions of language oriented programming

  • You, We.

굳이 당신, 여러분, 우리, 나… 이런 말을 넣지 않아도 된다. 어색하다.

  • class와 같이 다양한 의미로 사용가능한 단어.

명확한 의미로 번역하자.

  • These files are essentially DSLs.

이 파일들 역시 본질적으로 DSL이다.

  • they allow people familiar with the adaptive model to be extremely productive once the model is developed and shaken down.

이러한 모델은 한번 개발되어서 자리잡게 되면 개발자들이 모델에 익숙해져서 고도로 생산성 향상을 가져온다.

http://martinfowler.com/articles/languageWorkbench.html#AdaptiveObjectModels
위 글 번역 중 얻은 조언.

제대로된 번역은 언어지향 프로그래밍의 전통 🙂