Talk with Hani

저술은 인간이, 편집은 신이 한다.

-스티븐 킹

번역을 끝내고 나서, 초벌번역을 넘기면 편집자분께서 교정, 교열이라는 작업을 하십니다. 쉽게 말해, 교정은 맞춤법이 틀린 것을 고치는 작업이죠. 예를 들어, ‘자진거’를 ‘자전거’로 고치는 작업이 교정입니다.

교열은 맞춤법도 맞고 주술 구조도 맞지만, 문장이 꼬여 이해하기 어렵거나 문장에 오류가 있는 경우 바로잡는 것을 말합니다. 즉, “빌게이츠는 애플의 CEO다.”하는 문장은 주술구조도 맞고, 맞춤법에 오류도 없지만. 문장에 오류가 존재하죠. 이 문장을 “스티브 잡스는 애플의 CEO다.”하는 문장으로 고치는 것이 바로 교열이죠.

교정, 교열을 프로그래밍에 비유하자면, 무엇과 비슷할까요? 논란의 여지가 있지만, 저는 디버깅, 리팩터링과 비슷하다고 생각합니다. 즉, 교정은 디버깅으로… 교열은 리팩터링으로 볼 수 있습니다. 물론 오류를 고친다는 측면에서 보면, 교열도 디버깅이라는 게 더 정확하지만. 교열의 주된 목적이 더 나은 문장으로 만드는 것이기 때문에, 리팩터링이라고 볼 수 있습니다.

교정/교열과 디버깅/리팩터링 사이에서 유사한 점을 발견할 수 있지만, 출판과 번역에서 뚜렷한 차이점이 존재합니다. 작업자가 다르다는 점입니다. 교정/교열은 편집자의 몫인 반면, 디버깅/리팩터링은 개발자의 몫입니다. 즉, 원고를 만드는 작가와 더 좋은 원고로 수정하는 편집자가 분리되어 있지만, 프로그래밍에서는 개발자가 두 작업을 모두 합니다.

세상에 중요하지 않은 역할이란 존재하지 않습니다. 하지만, 전문가의 세계에서 그 세계를 체험하기 전에, 그 중요성을 느낄 수 없는 역할이 존재합니다. 바로 편집자가 그런 역할 가운데 하나라고 생각합니다. 번역을 하거나 책을 써보기 전에, 번역가나 작가의 역할이 절대적이라고 생각했습니다. 하지만 몇 번의 번역과, 한 번의 출판 경험을 통해서… 스티븐 킹이 한 말을 머리가 아닌 몸으로 경험할 수 있었습니다

프로그래밍 세계에서, 편집 개발자라는 직업이 있다고 가정해 보겠습니다. 개발자가 코딩을 끝낸 소스를 편집 개발자에게 넘겨주면, 이 편집 개발자가 버그도 잡고 더 나은 코드로 만들기 위해 리팩터링도 한다고 상상해 보죠. 그 직업이 바로 여러분의 일이라고 상상해 보면 어떨까요? 눈을 감고 상상을 하자마자 식은 땀을 흘리실지도 모르겠네요.

물론, 편집자가 단순히 교정, 교열의 작업만을 하는 것은 아닙니다. 요즘에는 에디터십(editorship)이라고 해서, 책의 방향을 잡는 기획이 더 중요한 업무라고도 하십니다. 하지만, 그래도 편집의 꽃은 교정, 교열에 있습니다. 그래서… 신의 영역에 도전하는 편집자와 함께 일하는 번역가나 작가는 무척이나 축복받은 영혼이라고 할 수 있습니다.

* 덧 : 요즘 교정/교열 작업 비슷한 것(?)을 하는 데 휴~ 힘듭니다.

등산을 하다보면 숨이 턱까지 차서 포기하고(?) 싶은 생각이 드는 순간이 있습니다. 흔히 깔딱고개라고 말합니다. 깔딱고개와 힘겨루기에 져서, 가끔 쉬었다 가는 경우도 있지만. 속도를 줄여서라도 이 깔닥고개를 지나고 나면, 등산이 그다지 어렵지 않게 되죠. 아울러 그 힘든 깔딱고개를 쉬지 않고 넘었다는, 작은 자부심도 부수적으로 얻습니다. 어차피 올라가는 산인데, 깔딱고개에서 쉬었다가도 결과적으로 똑같지만, 극기를 통해 얻는 1그램 정도의 성취감! 그게 바로 깔딱고개가 주는 선물인 듯합니다.

제가 요즘 맡은 프로젝트가 마지막 단계로 접어들고 있습니다. 개발은 거의 끝났고, 시스템 오픈을 위한 작업 몇 가지가 남았죠. 등산에 비유하자면 깔딱고개를 넘어가는 시점입니다. 리스크가 상대적으로 적은 프로젝트에 속하기 때문에, 오픈할 때까지 별 문제는 없지만요. 깔딱고개를 넘어가는 심정으로 지내고 있습니다.

그런데

큰 문제는 아니지만, 프로젝트 외부 조직에서 주기로 한 결과물이 조금 늦어지고, 데이터마이그레이션(DM) 방법이 아직 정해지지 않았다는 불확실성이 존재합니다. 두 가지 작업은 다른 작업과 선후행관계가 있기 때문에, 다른 조직에서 결과를 언제 줄지, DM방법이 결정될지에 영향을 받습니다. 두 가지 작업은 2주 안에 어떻게 할지가 결정되겠지만, 문제는 두 가지 작업이 불확실해지면서 프로젝트 나머지 기간 동안 계획이 조금 틀어졌다는 것입니다.

깔딱고개를 넘어갈 때는 무리하거나, 그 자리에 주저 앉으면 제 페이스에 산에 오를 수 없습니다. 마지막을 향해 가는 프로젝트에서도, 불확실한 것이 결정될 때까지 놀고 있거나 선행작업이 끝나지 않은 상태에서 뒷작업을 하면 재작업의 위험이 존재합니다. 이처럼 불확실한 것이 존재할 때… 그래도 앞으로 나아가야하는 상황에서 유용한 계획하기 방법이 바로 연동 계획하기(Rolling wave planning)입니다.

연동 계획하기의 핵심은 확실한 것을 먼저 하게 계획하고, 불확실한 것은 뒤로 미루어두는 데 있습니다. 즉, 불확실한 것이 확실해질 때까지 다른 작업을 먼저 수행해서 시간을 버는 것이죠.

연동 계획하기를 사용해서 팀원들과 불확실한 작업에 영향을 받지 않고 할 수 있는 작업을 도출했죠. 그리고 각 작업에 대한 상세 계획을 세웠습니다. 물론 계획을 세우지 않은 작업들은 작업 버퍼(화이트보드 한 구석)에 잘 저장해두었습니다. 이런 연동 계획하기는 작업 목록만 나왔을 뿐, 작업 사이에 관계가 명확하지 않은 프로젝트 초반에도 효과적입니다.

그나저나… 연동 계획하기 신공으로 프로젝트에서 만난 깔딱고개를 잘 넘어야 할텐데 말이죠.

from http://www.okmountain.com

유명한 요리사에게 요리를 배우는 문하생이 있었습니다. 문하생은 스승에게 더 이상 배울 것이 없다고 생각하고 떠나겠다고 말했습니다. 며칠 후 스승이 이 문하생을 불렀죠.

자, 이 장맛을 보거라.

스승이 문하생에게 장이 담긴 단지를 건냈습니다. 문하생은 스승의 지시에 망설임 없이 단지에 손을 담궈 장을 조금 찍어냈습니다. 그리고 장을 단숨에 입 안에 넣었습니다. 입안에서 퍼지는 맛은 말로 형용할 수 없는, 바로 변맛이었습니다. 문하생은 입에 있던 똥을 뱉어냈습니다. 위에서 넘어오는 토역질을 간신히 참아냈죠.

스승님! 이건 똥이지 않습니까?

그래, 아직 똥인지 된장인지 맛을 봐야 하는 놈이 어딜 가겠다고 하느냐! 설거지부터 다시 배워라, 고얀 놈.

훌륭한 요리사가 되기 위해서 손으로 신선한 재료를 고르고 코로 간을 맞추며 눈으로 맛을 볼 줄 알아야 합니다. 물론 절대 미각도 필요하지만, 미각은 훌륭한 요리사가 갖추어야할 기본 능력이지, 그것이 전부는 아니죠.

문하생이 요리를 배우려고 처음에는 미각에 의존하지만, 평범함을 뛰어넘으려는 사람은 오감을 사용하는 훌륭한 요리사가 됩니다. 전문가로 향하는 다른 분야도 훌륭한 요리사가 되는 것과 비슷합니다. 즉, 프로그래머든, 작가든, 번역가든, 관리자든. 선배가 알려준 하나의 방법이나 어깨 넘어로 배운 기술에 의존해서 실력을 쌓죠. 하지만 대성하는 사람과 평범한 직업인과 차이는, 요리사가 미각을 벗어나 훌륭한 요리사로 거듭나기 위해 오감을 사용하는 것처럼, 남들이 알려주지 않은 영역의 것을 발견하고 자신의 것으로 만드는 데 있지 않을까요?

예전 동료 가운데 공무원이 되신 분이 있습니다. 공무원이 된 옛동료를 포함해 서너 명이 모여 맛있는 저녁을 먹으면서 이 이야기 저 이야기했죠. 한 분이 ‘공무원스럽다’라는 표현을 쓰면서, 공무원이 흔히 저지르는 복지부동식의 삶을 살지 말라고 농담삼아 조언(?)을 했습니다.

공무원이 되신 분 하시는 말씀이,

그런 공무원도 있지만, 동료 가운데 국가 발전에 이바지하는 좋은 정책을 개발하려고 노력하는 사람도 많아요! 저도 그런 사람이 될게요. 하하하.

사실, 저는 공무원에게 당한(?) 적도 없으면서, 사무적이고 자기는 잘 모르겠다고 배째는 사람들을 향해 ‘공무원스럽다’는 말을 많이 했습니다. 사실, ‘공무원스러워지는’ 것은 공무원만의 특징이 아닐 겁니다. 대규모 조직, 즉 관료조직에 속한 사람이라면, 다양한 규율과 조직의 이해 관계에 얽히기 때문에, 어쩔 수 없이 공무원스러워집니다.

***

애자일 프랙티스를 프로젝트에 도입할 때, 자연스럽게 다양한 도구와 기법도 도입합니다. 예를 들어, 고객이나 팀에서 찾은 버그를 관리하고 해결하기 위해, trac과 같은 이슈(버그) 추적도구를 쓰기도 하고. 정보 방열기에 일정을 관리하기 위해, burn-down chart나 할일 목록을 포스트잇에 붙여 관리합니다.

저는, 팀이 제대로 달려가고 있는지 알려주는 이런 도구/기법/차트를 통상 ‘프로젝트 잣대’라고 부릅니다. 팀원들은 자신이 적절한 속도로 올바른 목표를 달리지는 살피려고, ‘프로젝트 잣대’에 신경을 많이 씁니다. 즉, 자신에게 배포된 티겟의 갯수가 줄고는 있는지. burn-down chart에 나타나는 진행 속도가 빠른지 날마다 살펴보죠.

‘프로젝트 잣대’는 자동차 대시보드에 붙어 있는 ‘속도계’와 같은 역할을 합니다. 안전운행을 하려면 운전자의 감에 의존하기 보다는 ‘속도계’에 나타난 속도가 제한속도를 지키고 있는지 살펴야 하기 때문이죠. 속도계를 통해서 정상적인 속도를 알 수 있지만, ‘속도계’가 자동차의 속도는 아닙니다. 예를 들어, 속도계는 정작 시속 100킬로미터를 가리키지만, 실제 자동차 속도가 시속 150킬로미터라면 어쩌죠? 고속도로를 신나게 질주하는 멋진 승용차 사진을 받게 될지도 모르죠.

프로젝트에 애자일 프랙티스를 적용하는 이유는, 고객에게 더 나은 것을 제공하기 위해서죠(다른 이유도 있지만, 여기서는 간단히 이 정도로). 하지만 가끔, 이런 애자일 프랙티스를 적용려고 도입한 도구에 집착하는 경향이 있습니다. trac을 도입한 어떤 팀에서, 티켓을 발행하지 않으면 개발자가 버그에 대해 이야기를 하려고 하지 않았다고 합니다. 다른 프로젝트 팀에서는 burn-down chart에 속도를 높이는 데만 치중했지 고객이 개발한 기능에 만족하는지는 살피지 않았다고 하네요.

법과 원칙을 지키는 공무원을 향해 비난을 하는 것은 옳지 않습니다. 다만, 관료조직에 있다는 이유로, 자신의 게으름이나 실수를 조직이라는 방패로 막으려는 행위를 비판해야죠. 마찬가지로, 우리가 애자일 프랙티스를 도입하면서 자신도 모르게 도구에 대해서 맹신해 버리는, 즉 복지부동의 ‘공무원스러워져서’는 안 됩니다. 이런 생각을 할 때마다, 애자일 선언은 참 잘 만들었다는 탄복을 합니다.

애자일 소프트웨어 개발 선언문

‘프로세스와 도구’보다는 ‘개인과 상호작용’을

‘포괄적인 문서화’보다는 ‘동작하는 소프트웨어’를

‘계약 협상’보다는 ‘고객과의 협력’을

‘계획 준수’보다는 ‘변화에 대응’을

‘애자일 프랙티스’에서(밑줄은 개인적으로 침)