Talk about Software with hani

팀장의 고백  목차

• 게으른 PL이 프로젝트 일정을 지연시킨다.
• 개발명세서? 그 귀찮은 짓을 왜 하지? (오늘의 Post)
• 개발계획은 팀장의 것? 팀원의 것?
• 팀장! 당신은 진정한 Nego를 할 수 있는가?
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지
• UnitTest! 미완의 시도
• 인수테스트, 북치고 장구치고
• Trac을 통한 품질 관리
• 진정한 프로젝트의 가치는 어디에서 오는 것일까?

오늘은 “팀장의 고백” 시리즈의 첫번째 Post로 개발 명세서에 대해서 이야기하겠다. 시리즈 순서대로면 “게으른 PL이 프로젝트 일정을 지연시킨다.” 를 post해야지만, 좀 고민해야될 이야기가 많아서 다음 기회로 미루고 오늘은 개발 명세서에 대해서 생각해 보자.

개발 명세서란 무엇인가? 사전적인 의미로 살펴 보면 개발 명세서는 “개발과 관련된 하나하나의 내용을 자세히 적은 문서”라 할 수 있다. 그렇다. 쉽게 말하면 어떤 것을 만들 때 내가 무엇을 만들지를 주저리 주저리 적어 놓은 문서를 개발 명세서라 할 수 있다. 따라서 개발 명세서는 Software의 전유물이 아니다. 개발과 관련된 모든 분야에서는 개발 명세서를 작성한다. 그러나 말은 이렇게 하지만 실제로 본 개발 명세서는 전자 제품 만들 때 작성한 개발 명세와 Software를 만들 때 작성한 개발 명세서 정도다.

전자 제품, 예를 들어 냉장고를 만들 때 개발 명세서의 내용은 다음과 같다. “냉동실의 온도는 -15도에서 -3도 사이에서 변한다.”, “사용자가 맞혀 놓은 온도는 오차 범위(+-1도)에서 유지되어야 한다.” 등등 일반적으로 생각하는 냉장고의 기능과 제품 안전을 위한 검사 항목까지 일반인들이 생각하지 못하는 내용들로 채워져 있다. 이런 냉장고의 개발 명세서를 보면, 냉장고를 어떻게 만들어야 할지는 모르지만, 개발 명세서를 토대로 냉장고가 완성되었을 때 어떤 기능과 방식으로 작동할지를 짐작해 볼 수 있다.  냉장고, TV, 홈시어터 제품군을 떠나서 전자 제품 회사에서 제품을 만들 때 중요하게 생각하는 것은 개발 명세서를 만드는 작업이다. 눈으로 보면 알 수 있는 유형의 제품을 만들면서도 개발 명세서를 무척 자세하게 적는다.

개발 명세서를 상세하게 작성하는 이유는 여러가지가 있겠지만, 가장 큰 이유를 생각해보면 개발 명세서에 적는 기능 하나 하나가 돈이기 때문이다. 여기서 말하는 돈은 기능을 개발할 때 들어가는 비용이다. 앞에서 예를 들은 냉장고의 상세 기능인 “사용자가 맞혀 놓은 온도는 오차 범위(+-1도)에서 유지되어야 한다.”를 구현하기 위해서 중요한 변수는 오차 범위다. 이 오차 범위를 +-1도에서 +-5로 변경하면, 기능을 개발하기 위한 개발 비용을 무척 줄일 수 있다. 그렇기 때문에 개발 명세서에 나열된 기능을 놓고 개발자들은 냉장고를 만들 때 어느 정도의 기간과 비용이 소요될지를 예상해 볼 수 있다.

Software 분야에서의 개발 명세서

일반적인 제품의 개발 명세서 이야기는 여기에서 마치고 오늘의 주제인 Software 개발 명세서에 대해서 생각해 보자. 유형의 제품을 만들면서도 많은 시간과 노력을 들여서 개발 명세서를 작성하는데, 무형의 제품인 Software를 만드는 팀에서는 개발 명세서 작성에 큰 노력을 들이지 않을까? 여러가지 이유가 있겠지만, 가장 큰 이유는 Software 산업 내에 직업 분화가 다양하게 이루어지지 않았기 때문이다. Software 개발이라는 작업은 다양한 업무로 구성되어 있다. 간단하게 보더라도 고객 요구 분석, 시스템 설계, 개발, 테스트 업무, 배포 업무로 나뉘지만, 일반적인 Software 개발 회사에서는 이 모든 업무를 단 하나의 단어 “개발 업무”로 표현한다. 즉, Software개발자가 고객요구 분석부터 배포의 업무까지를 모두 도맡아서 하는 것이 현실이다.

그러나 Software를 개발해 본 사람은 고객 요구 분석에서 배포의 업무 하나하나가 전문성을 요구하는 작업이라는 것을 알것이다. 그러나 개발 회사 내에서도 이런 업무를 각각의 담당자를 지정해서 하기 위해서는 많은 비용이 발생하기 때문에, 개발자들이 모두 처리하기를 바라고, 실제 업무에 있어서도 그렇게 한다. 그런데 개발자 입장에서 가장 핵심적인 업무는 개발이다. 그렇기 때문에 아무리 고객 요구 분석이 중요하고, 테스트가 중요하더라도 결과를 내놓아야 하는 입장에서 본다면 개발 업무를 제외한 모든 업무는 사소한것으로 생각된다. 따라서 개발명세서 작성과 같은 업무는 물 건너 배부른 나라에서 한가할 때 하는 유흥정도로 느낀다.

스티브 맥코넬의 소프트웨어 개발(Professional, 인사이트)에서는 소프트웨어 산업도 전문직에 속한다고 주장한다.(지난 30년여의 세월을 뒤돌아 볼 때보다 소프트웨어 산업도 의사, 변호사, 각종 기술직처럼 전문직으로 성숙되고 있다고 주장한다.) 물론 이 이야기는 바다 건너 미국에 해당한 이야기지만, 우리나라도 서서히 개발자 중심의 개발문화에서 프로세스 중심의 개발 문화로 바뀌어 가야 한다. 그러기 위해서는 소프트웨어 개발 전단계에서 업무 분화가 이루어지고, 그렇게 된다면 개발 명세서와 같은 작성 업무가 개발자에서 프로그램 관리자와 같은 별도의 직군에서 의해서 수행될 것이다.

이상으로 간단하게나마 업계에서 당연히 작성해야 하는 개발명세서를 당연히 작성 안하는 이유를 살펴 보았다. 지금부터는 마무리 단계인 이번 프로젝트에서 어떤 식으로 개발명세서를 작성했으며 얻은 이점과 개선 사항은 무엇인지에 대해서 이야기해 보겠다. 개발명세서를 한번도 작성해 보지 않은 사람에게 개발명세서를 작성하라고 한다면, 좀 난감해 할 것이다. 개발명세서를 작성해 보고 싶은 사람에게 도움이 될만한 자료 하나를 소개하겠다. 조엘 스폴스키의 조엘 온 소프트웨어(Joel On Software, 에이콘)에 제 5장 손쉬운 기능 명세 작성법 : 1강 명세서 작업이 귀찮습니까? 다.(동일한 자료를 조엘의 블로그의 Painless Functional Specifications - Part 1 : Why Border?에서도 볼 수 있다.) 간단하지만 실무에서 적용하기에 충분한 참고 자료다.

의사 소통을 위한 개발 명세서 작성

지금 마무리 중인 프로젝트의 아주 개략적인 Scope을 설명하면(프로젝트의 내용에 대해서 상세히 설명하고 싶으나, 기업 비밀에 해당하는 내용이기 때문에 이야기할 수 없어 아쉽다.) 총 3개의 모듈을 개발해야 했으며, 이 중 한개의 모듈은 개발을 Outsourcing 하였다. Outsourcing한 모듈은 건축 설계에 대표적으로 사용되는 툴인 AutoCAD와 같은 2D GUI툴을 제공하며, 공학적인 Simulation을 수행한 후 Excel을 이용해서 다양한 형태의 Report를 출력해야 했다. 고객의 요구 사항은 매우 복잡했고, 프로젝트 초반에 고객 요구 사항을 명확히 하지 못한다면 일정관리에 치명적인 영향을 줄 수 있었다.

기존까지 수행한 프로젝트는 대부분이 고객과 같이 작업할 수 있었기 때문에, 상세한 개발명세서 작성을 간단한 사용자 시나리오나 GUI 설계로 대체하였다(사실 고객과 원할한 의사소통이 이루어진다 하더라다도 개발명세서는 꼭 작성해야 한다. 개발명세서의 필요성은 뒷부분에서 자세히 이야기하겠다.) 그러나 이번 프로젝트에서는 고객과 개발팀 그리고 Outsourcing 업체가 지리적으로 떨어져 있었기 때문에, 의사소통에 큰 문제가 있었다. 프로젝트의 참여 당사자들이 모두 같은 자리에 모여서 의견을 교환할 수 없는 상황이었기 때문에, 고객의 요구가 개발을 담당하는 Outsourcing업체에 명확히 전달되기 어려웠다.

이런 이유로 프로젝트 일정을 전체 관리하는 입장에서 고객의 요구사항을 명확히 해서 Outsourcing업체에 전달하기 위해서는 필연적으로 매우 상세한 개발명세서를 작성해야 했다. 우선 간단한 사용자 시나리오를 작성해서 S/W의 전체적인 GUI 윤곽을 잡은 후 이를 토대로 개발명세서 작성에 돌입하였다. 사용자 시나리오에서 최종 개발명세서 작성에 약 한달의 기간이 소요되었으며, 이 기간동안 5번정도의 Revision이 발생하였다. 최종 개발명세서는 A4용지 기준으로 55Page 분량 정도였다.(백마디 말보다 직접 작성한 개발 명세서를 몇 페이지 공유하는게 도움이 되겠지만 그러지 못하는 현실이 아쉽다.)

한 달간의 짧지 않은 시간동안 작성한 개발명세서에는 어떤 것들이 담겨져 있을까? 아래는 내가 작성한 개발 명세서를 읽고 담겨 있는 내용을 정리한 것이다.

• 전체적인 GUI
• 사용자 대화상자
• 전체적인 사용자 시나리오
• 상세 기능별 사용 방법
• 각 기능별 Input/Output
• 에러 발생 시 처리 방법

위의 개발 명세서는 사용자가 Software를 사용하면서 마주칠 모든 상황에 대해서 기술해 놓은 것이라 할 수 있다. Software를 사용할 잠재 고객들이 개발 명세서를 읽어봄으로써 Software를 어떻게 사용할 수 있는지 그리고 어떤 방식으로 작동하는지를 짐작할 수 있도록 작성해야 한다. 따라서 개발명세서는 개발자의 입장에서 작성하는 것이 아니라, 사용자의 입장에서 작성해야 한다. 명세서는 Software를 만드는데 있어서 출발점이다. 그렇기 때문에 명세서가 명확하지 않으면 Software또한 제대로 만들 수 없다. 따라서 명세서에 기술되는 내용은 초등학생들이 읽어도 무슨 내용인지 알 수 있는 수준으로 작성해야 한다.

“… Function-12A를 사용하기 위해서는 Functioin-11B가 먼저 활성되어야 한다. 따라서 Function-11B를 활성화하기 위해서는 Function-11B에 해당하는 메뉴를 누른 후 대화상자에서 “Yes” 혹은 “No”를 선택해야 한다. …” 간혹 개발 명세서는 기술적인 냄새가 물신 풍겨야 한다고 생각해서, 컴퓨터도 못 알아 들을 내용으로 명세서를 꾸미기도 한다. 그러나 이런식의 명세서는 차라지 작성하지 않는 편이 낫다. 명세서 작성 시 가장 강조하고 싶은 것은 간략하면서도 누구나 쉽게 이해할 수 있도록 작성해야 한다.

톰 디마르코의 소설 데드라인(A The Deadline, 인사이트) 위와 같은 명세서가 종종 작성되는 이유는 작성자가 멍청해서가 아니라, 해당 프로젝트의 이해 관계가 충돌하기 때문이라고 한다. 개발 명세서라고 하는 것은 Software의 모든 행위를 기술한 것이다. 그렇기 때문에 이해 당사자들이 정치적으로 충돌하는 프로젝트의 요구 사항이 합의되지 않고, 따라서 해당 개발 명세서도 명확하게 작성할 수 없다. 이런 프로젝트의 개발 명세서는 모호한 표현들로 가득차지고, 이 개발명세서를 읽는 사람들은 해당 명세서를 이해할 수 없게된다. 따라서 자신이 속해 있는 프로젝트의 개발명세서를 읽고도 무엇을 개발해야할지 모르다면, 프로젝트가 잘못되고 있음을 직감해야 한다.

개발명세서를 작성함으로써 얻을 수 있는 이점

1. 고객의 요구를 명확하게 정할 수 있다 : 사람 사는 세상에 상대방의 말을 100% 신뢰할 수 있다면 천국이 따로 없을 것이다. 그러나 현실은 상대방의 말만 믿고 일을 진행할 수 없다. 따라서 말에 신뢰를 부여하기 위해서 할 수 없이 글에 의존할 수 밖에 없다. 말보다는 글로 써 놓는 것이 구속력이 강함을 부인할 사람은 없을 것이다. 솔직히 개발명세서를 작성하기는 하지만, 내가 작성한 개발 명세서를 모든 사람들이 다 읽어보리라는 기대를 하지 않는다. 그러나 이해 관계자가 많고, 의사 소통에 문제가 발생할 가능성이 많다면 개발 명세서는 프로젝트를 일정 방향으로 이끌어 갈 수 있는 방향타 역할을 한다.

물론 고객 만족을 위해서 고객의 요구를 100% 반영하는 것이 가장 이상적인 프로젝트일 수 있다. 그러나, 성공적인 프로젝트는 냉정한 현실과 이상 사이의 중간 지점에서 적절한 타협을 이루어내야 한다. 그렇기 때문에 변화하는 고객의 요구를 어느정도 통제할 필요가 있다.(고객의 요구를 100% 반영하는 것이 필요한지에 대해서는 “팀장! 당신은 진정한 Nego를 할 수 있는가?”에서 다루겠다.) 표현의 차이기는 하나 고객의 요구를 명확히 한다는 것은 고객의 요구를 통제한다는 다른 표현이다. 시간이 흐른 후 고객이 다른 이야기를 할 때 “개발 명세서 몇 페이지에 이런 식으로 개발하기로 하였습니다” 라고 간단히 언급해 주는 것으로 변화 무쌍한 고객을 진정시키는데 도움이 되기도 한다.(현실에서는 이런 합의도 간단히 무시해 버리는 고객도 많다.)

2. 기간 산정 시 기본 자료로 사용된다. : “잘 만들어 주세요!”라는 말처럼 무서운 말이 없다. 프로젝트 관리자로써 대충 이런 식으로 만들어 달라고 Outsourcing 업체에 던져 주고 “잘 만들어 주세요!”라는 말 한마디로 일을 끝내는 이들도 있지만… 결국 이런식의 Outsourcing 업체 관리는 제 발에 족쇄를 채우는 형국이다. 잘 만들고 싶지 않은 Outsourcing 업체가 어디에 있을까? 모든 Outsourcing 업체들이 좋은 결과를 내고, 차기 프로젝트로 연결되서 일을 하고 싶어한다. 그렇기 때문에 Outsourcing 업체들이 좋은 결과를 낼 수 있도록 조금만 도와준다면 프로젝트를 성공적으로 마무리할 수 있다. 도움의 시작은 정확한 개발 일정을 산정할 수 있게 하는 것이다. 그러기 위해서 개발 명세서를 명확히 작성해서 넘겨 준다면 Outsourcing업체가 개발 일정을 산출하는데 많은 도움을 줄 수 있다. 따라서 일정을 관리하는 PL입장에서도 초기에 개발 명세서를 완벽히 작성해서 넘겨주는 수고를 조그만 들인다면, 프로젝트 후반부에서는 그렇게 신경 쓸 일이 많지 않다.(물론 현실적으로 개발업체 내부에서 발생하는 문제가 일정 지연에 큰 영향을 미치기는 하나, 이 부분은 부처님도 도와줄 수 없다. 이런 문제는 Risk Management가 해결 방안일 수 있다.)

개발 명세서 작성 시 개선 사항

이번 프로젝트로 제대로 된 개발 명세서를 작성할 수 있어, 개인적으로 한단계 실력을 높이는데 많은 도움이 되었다. 그러나 개발명세서를 작성하면서 가장 하기 싫은 작업이 있었다. 바로 완성된 명세서를 개정 작업하는 것이다. 개발명세서를 완성한 후 핵심 고객에게 전달하면 반드시 변경사항이 발생하였다. 이는 무척이나 자연스러운 일이며 바람직한 현상이다. 그러나 개발명세서를 수정해야 하는 입장에서는 반복적으로 일어나는 개정작업이 그다지 달갑지 않은 것도 사실이다. 원칙적으로 요구 사항이 변경될 때마다 명세서가 변경되어야 하나, 현실적으로 개발에 들어가게 된 후부터 다른 업무 때문에 개발명세서 변경 작업은 중단되었다. 개발명세서 개정 작업이 중단된 이유는 초기 Software의 Spec 명확화와 기간 산정의 역할을 다했기 때문이다. 그러나 애써 작성한 개발 명세서가 단순히 Spec을 잡는데에만 사용되기에는 아깝다는 생각이 들었다.

개발명세서의 활용방안에 대해서 고민하다가 스티브 맥코넬의 소프트웨어 프로젝트 생존전략(Software Project Survival Guide, 인사이트)에서 얻은 팁을 소개한다. 개발명세서가 단순한 명세서 수준에서 멈추는 것이 아니라, 사용자 도움말의 형태로 작성하는 것이다. 즉, 소프트웨어 개발 초기부터 도움말(개발명세서)을 만들어 나간다면, 개발 명세서 역할도 하면서 이 문서가 최종적으로 도움말이 되기 때문에, 지속적인 개정 작업을 할 수 있다는 것이다. 이 방법은 개발명세서의 작성이 과도한 업무 때문에 망설여지는 회사에서 적극적으로 고려해볼 필요가 있다.

이것으로 Post를 끝내고, 다음 Post에서는 개발 일정 수립 방법에 대해서 이야기하겠다.

모정(母情)과 부정(父情)은 근본적으로 다를까? 물론 자식을 향한 부모의 마음은 본질적으로 다르지 않겠지만, 정이 형성되는 형태는 다르다. 부정은 사회적 관계의 산물이다. 물론 갓 태어난 자식을 품에 앉은 아버지는 북받쳐 오르는 기쁨은 누구에게나 똑같겠지만, 자식을 품에 앉는 그 순간부터가 자식과 아버지로써의 정서적 공감의 시작이다. 이에 반해 10달을 뱃속에서 품었다가, 세상 무엇보다도 심한 진통 끝에 자식을 품에 앉은 어머니의 감정은 어떨까? 물론 남자이고 미혼인 관계로 그 정서적 상태는 드라마, 소설 그리고 약간의 감수성이 묻은 상상력을 동원해서 판단할 수 밖에 없지만, 말로 형언할 수 없는 복합적인 심정이 들것이다. 즉, 어머니에게 있어서 자식은 자신의 일부분인, 혈육의 관계이기 때문이다.

그럼 부정이 깊냐? 모정이 깊냐?는 의문이 든다. 정확한 답은 부모들마다 천차만별일 것이다. 간혹 패륜아와 무정한 부모들이 뉴스거리가 되긴 하지만, 대부분의 부모들은 자식을 사랑으로 키우는 것만은 틀림없다. 다만 부정은 아버지가 얼마큼 노력하느냐에 따라서 깊이가 차이 날 수 있지만, 모정은 혈육의 정이기 때문에 그 출발선부터가 다르다는 점을 말하고 싶다.

무엇을 말하고 싶어서 부정과 모정의 차이점에 대해서 주저리 주저리 설명하냐는 생각이 들 것이다.가끔 모정이 어떤 것일까라는 막연한 느낌이 실제적인 체험으로 다가올 때가 있다. 1년 내외의 프로젝트가 마무리될 때다. 입사한 후 지금이 14번째 프로젝트다. 자식으로 따지자면 지금 품 안에 앉고 있는 자식이 14번째 자식이다. 지금까지 수행한 프로젝트의 결과를 보면 꼭 자식같다는 생각이 든다. 결과는 좋지 않았지만 이상하게 애정이 많이 가는 프로젝트가 있는 반면, 생각도 하기 싫을 정도로 정이 안가는 프로젝트가(힘든 것을 떠나서…) 좋게 평가받는 경우도 있었다. 자식이 부모 마음처럼 안되는 것처럼 프로젝트도 팀장 마음대로 안되나 보다.

어머니와 자식의 관계처럼 프로그래머와 Software는 혈육의 정이다. 내가 짠 알고리즘이 보드 위의 전류를 따라 흐르고, 내가 만든 GUI는 얼굴로써 사용자와 대화를 한다. 어머니가 출산의 고통을 겪는다면, 프로그래머는 모니터를 쳐다 보느라고 굽은 등 때문에 고통을 겪는다. 이래 저래 생각해 보면 무에서 유를 창출하는 프로그래머는 꼭 필요한 존재임에 틀림 없다.

아무튼 출산을 며칠 앞둔 이번 프로젝트는 노산에 해당한다. 어느 순간을 지나면서 코딩이라는 작업이 체력전이 되었다. 7년전까지만 해도 며칠 철야에 밤새 코딩을 해도 다음날 가뿐히 일어났는데, 이제는 8시간만 IDE를 붙잡고 시름하면 온 몸이 쑤시는게 안 아픈 곳이 없다. 이 때쯤 되면 뜨거운 욕탕이 그리워진다. 팀장이지만, 불가결하게 코딩까지 해야 하는 현실에 심신이 서서히 지쳐가고 있다. 그러나 곧 출산할 자식을 생각하면서 조금 더 노력하자는 생각도 드는 것은 이 직업이 천직임은 틀림없다.

아래의 내용은 언제 발표된 것일까?

• 컴퓨터 마우스
• 2차원 화면 편집
• 파일 트리뷰
• 하이퍼미디어 검색 및 퍼블리싱
• 다중 윈도우
• 통합된 하이퍼미디어 방식의 인트라넷 이메일 시스템
• 문서 버전 컨트롤
• 원격 화상 회의
• 포매팅 지시어를 사용한 간단한 워드 프로세싱
• 문맥 기반 도움말
• 분산 클라이언트 서버 아키텍처
• 일관성 있는 명령어 문법
• 범용 사용자 인터페이스
• 문법 주도형 명령어 해석기
• 가상 터미널의 프로토콜
• RPC 프로토콜
• 게시판
• 지식관리 시스템

source from 누가 소프트웨어의 심장을 만들었는가? 박지훈 저
link from http://www.bootstrap.org/chronicle/chronicle.html#2U

이 문제를 맞춘 사람은 첫번째 힌트 “컴퓨터 마우스”에서 답을 알았을 것이다. 답은 1968년 12월 9일이다. 위의 개념들 중에서 일부는 최근에야 사용이 보편화 된것들도 있다. 그런데 40여년전에 이미 개념들이 나왔다는 사실이 놀랍지 않은가? 이런 개념을 소개하고 실제로 구현한 사람은 SRI(Stanford Research Institue)의 더글러스 엥겔바트다. 엥겔바트는 NLS(oN Line System)를 소개하는 데모에서 위의 개념들을 소개하였다. 그런데 엥겔바트의 데모는 모든 데모의 어머니(The Mother of All Demos)로 불릴 정도로 뛰어나다. 아래의 링크에서 당시의 데모를 직접 확인할 수 있다.

http://video.google.com/videoplay?docid=-8734787622017763097&q=engelbart

가끔 이런 대가들의 모습을 보면, 내가 현업에서 고민하는 문제가 너무나 하잖게 보일 때가 있다. 그래~ 나는 난쟁이다. 그러나 거인의 어깨 위에 서 있는 난쟁이라는 사실을 잊어서는 안된다.

Framework을 사용해야 하는 이유
 

번역서를 읽으면서 분통을 터트린 경험은 누구가 갖고 있을 것이다. 특히 IT관련 서적의 경우, IT붐이 불면서 번역되는 외서가 급증했지만, 양과 질의 괴리 때문에 한동안 번역서를 읽는 것보다는 차라리 원서를 읽는 편이 이해에 도움이 많이 된다는 이야기도 있었다.

질 낮은 번역서의 일차적인 책임은 번역가에 있음을 부정할 수 없다. 장미의 이름 등을 번역한 우리나라의 대표적인 번역가 이윤기氏의 어른의 학교를 보면 번역과 관련된 재미있는 일화가 있다.

번역가에게 오명은 숙명입니다. 내 눈에 들보가 들어 있는 판에 남의 손톱 밑 가시 걱정이라니 당치 않지요. 그러나 번역하는 사람이 사전 안 찾고 얼렁뚱땅 넘어가는 버릇은 반드시 고쳐야 한다는 뜻에서 하나만 소개합니다. 나는 십수 년 전 어떤 소설 한국어 번역판에서 “그는 자기의 루거를 불태웠다.”는 문장을 읽고 웃었습니다. 원문을 확인할 것도 없이 ‘He fired his Luger’일 것이라고 짐작했기 때문입니다. ‘루거’는 독일제 9밀리 권총 상표명입니다. 따라서 그 문장의 정확한 번역은 ‘그는 권총을 쏘았다.’가 맞습니다.

이윤기氏와 같은 경험을 다들 한번 씩 갖고 있을 것이다. 훌륭한 번역서의 1차적인 책임은 전적으로 번역가에 달려 있다고 생각했다. 그러나 박상익氏의 ‘번역은 반역인가’를 읽고 이 생각이 조금은 바뀌었다. 저자는 이 책에서 우리나라 번역 문화에 대한 전반적인 문제점을 지적하고, 저질의 번역서들이 출판될 수 밖에 없는 현실에 대해서 설명했다. 시장 진입을 법적으로 통제하는 전문직(의사, 변호사 등)을 제외하고, 우리나라 지식 노동자가 제대로 대우 받는 시장이 있을까라는 의문이 들기는 하지만…

전문번역가의 1년 소득은 어느정도 될까? 책에서는 김용옥 교수의 일화를 소개하고 있다.

저는 올해(1990년) 일곱 권의 책을 출간했습니다. 이렇게 무리를 한 것은 제가 현재 살고 있는 공간이 너무 비좁아 80평짜리 집을 하나 봉원동에 짓고 있기 때문입니다. 도스토예프스키는 도박벽 때문에 도박판에 돈을 대느라고 그렇게 많은 소설을 썼습니다. 저는 올해 건축비 대느라고 죽으라고 썼습니다. 그런데 제 주변의 아무것도 모르는 교수 자식들이 절 만나면 뭐라 하시는지 아십니까? ‘야, 넌 교수 때려치우더니 돈 벌었더구나. 책 내기만 하면 얼마나 돈이 쏟아지겠니?’ (그러나) 제가 내는 책들은 인문과학 서적이며 이문열씨 소설과는 그 자릿수가 다릅니다. 인문과학 서적의 베스트셀러라는 것은 히트쳐야 만 부면 주저앉습니다. 참 실망스럽지요. 사천 원짜리 책 만부면 그 10퍼센트 인세가 사백만원입니다. 이렇게 따지면 일년에 다섯 권의 베스트셀러를 내도 제 수익은 이천만 원, 팽팽 놀아 처먹는 교수새끼들 일 년 월급도 되질 않습니다. 제 어깨는 떨어져나갑니다. 이 주길노므새끼들이 날 보고 베스트셀러 작가 부자라는 겁니다. 야 이 개새끼들아, 너희들이 받아 처먹고 있는 월급이 얼마나 엄청난 액수인가를 좀 알아라 하고 외치고 싶고, 정말 이 시대의 지성의 역할이 무엇인가를 반성하게 됩니다.

번역서가 아닌 저자가 직접 쓴 책인 경우에도 김용옥 교수가 지적하였듯이 인세가 매우 적다. 우리나라 번역작가의 소득 수준을 짐작할 수 있는 대목이 있어서 소개한다.

(본문 요약)보통 정가의 6%가 번역로로 지불된다고 한다. 정가 2만 원짜리 책을 한권 번역했는데, 초판을 2천 부 찍고 인세가 6%라면 번역자에게는 240만원이 돌아가게 된다. 그런데 2001년 민주노총이 제시한 표준 생계비를 4인 가족 기준 월 305만 7,972원이라고 제시했다고 하니, 매달 한권씩 번역 작업을 해도 4인 가족 표준 생계비에 턱없이 모자르는 형편이다.

앞서 이야기하였듯이, 지식 노동자의 대우가 좋은 시장이 어디 있게냐만은, 번역 시장이 이렇다 보니 능력 있는 인재들이 번역 시장에 끌어 들일만한 유인책이 없다. 투철한 사명의식과 학자 정신이 있는 번역가들이 적은 수입이지만 열심히 번역 문화에 참여하고 있는 실정이란다.

일본 사람들이 영어를 못한다고 우리나라 사람들은 생각한다. 사실 일본의 경우 메이지 유신 때부터 번역국을 두어서 국가적으로 번역 사업을 주도하였기 때문에 왠만한 서양 서적은 일찍이 번역이 완료되었다. 따라서 구지 영어를 잘하지 못하더라도, 대부분의 서적을 모국어로 읽을 수 있는 인프라가 갖추어졌기 때문에 일본인들이 영어의 필요성을 못 느끼는거 같다. 이에 반해 조금이라도 심도 있는 공부를 해보려고 했던 사람들은 우리나라말로 번역된 참고 서적을 찾기란 하늘의 별 따기라는 사실을 알 것이다.

양질의 텍스트를 공급하는 것은 일차적으로 교수들의 몫이라는 것을 지적하고 있다. 그러나 교수들의 이름으로 출판되는 번역서의 대부분은 대학원생들에게 나누어 주고 번역된 것을 모아서 출판하는 형태이기 때문에 번역의 수준도 낮다. 이런 교수들의 번역에 대한 수준 낮은 인식이 오늘날의 번역 문화를 생산해 내었다고 지적한다.

‘번역은 반역인가’는 우리나라의 번역문화에 대한 통찰을 제공해 주는 책이다. 음지에서도 최선을 다하는 번역가들이 있기에, 그 어려운 외서를 읽지 않아도 우리나라말로 쉽게 수 많은 텍스트를 접할 수 있음에 고마움을 느낀다.