Talk about Software with hani

군대에서 힘들지 않은 사람 없고, 입시공부하면서 코피 한번 흘려보지 않은 사람 없듯이, 회사생활하면서 야근에 휴일 특근으로 신물나게 일했던 경험은 누구나 있을 겁니다.저도 후배사원 앞에서 “내가 왕년에 말이지…”로 시작하는, 회사경험담이 몇 개(?) 있습니다. 이런 경험담이 있다고, 후배사원에게 쉰냄새나는 이야기를 하지는 않지만요.

입사하고 1~2년쯤 지나고 맡은 무척이나 힘든 프로젝트 이야기 하나 해보겠습니다. 제가 왕년에 말이죠… ㅋ. 아무튼 이 프로젝트는 기술적으로 난이도가 상당했는데, 이 프로젝트에는 이상한 성공기준이 있었습니다. 당시 PM이 팀원들을 모아놓고 프로젝트에 대해서 이야기하면서, 정확하지 않지만 이렇게 말했죠.

이번 프로젝트는, 우리가 얼마나 성실한지도 보여주는 게 무척 중요해.

사실, 팀원들은 성실 빼면 능력만 남는 사람들이었기 때문에, 프로젝트 성공기준에 ‘성실’이 들어간다는 게 무슨 뜻인지, 왜 필요한지 몰랐지만. PM이나 윗분들의 설명에 따르면, 성실한 모습을 보여주면 차기 프로젝트를 따는 데도 유리하다는 논리였습니다. 결국 성실한 모습을 보여주기 위해서, 프로젝트 팀원들은 월요일 아침, 첫 비행기를 타고 내려가 출근하고, 토요일 저녁 막비행기를 타고 돌와왔습니다.

당시는 프레임워크도 보편화되지 않은 시절이었기에, JSP와 Java를 사용해서 프레임워크 비슷한 것(생각해 보니, 프레임워크였네요)도 만들고, 다양한 애플리케이션도 만들어야 했기에, 무척 힘들었습니다. 일이 태산보다 많았기 때문에, 무척 성실하게도 출장지에서 주는 하루 4끼를 먹는 삶을 살았습니다(자정이 되면, 사내 식당에서 야식을 주었습니다).

일요일은 피곤에 쩔어서 좀비같은 생활을 하다, 망가지는 것은 정신과 몸이요. 느는 것은 통장에 쌓이는 쓰지 못한 월급이었습니다. 결국, 프로젝트는 끝나고… 고객이 프로젝트 팀의 성실성에 감동 받아, 차기 프로젝트를 1년이 지나고 나서 줬습니다. 하하… 아무튼 이때 깨달은 바가 있기에, 삶에서 균형을 찾자는 게 모토 비슷한 게 되었으므로, 그 프로젝트에서 큰 것을 얻은 셈이죠.

최근에 다른 프로젝트 이야기를 들었습니다. 이 프로젝트는 현재 진행중인 프로젝트인데, 팀원들이 집에 도착하면 항상 다음날이라고 하더군요. 왜 그렇게 야근이 많은지 궁금하던 차, 이 프로젝트의 고객이 PM에게 한 부탁을 듣게 됐습니다.

직원들이 퇴근하고 나서, 1시간 정도 더 근무하고 퇴근해 주세요. 지금도 열심히 하시지만, 더 열심히 하시는 모습을 보여주면…

제가 몇년 전에 경험한 프로젝트처럼, 이 프로젝트의 성공기준도 ‘근태’였기 때문에, 야근과 특근이 많았습니다. PM을 하다보면 다음 프로젝트를 생각하지 않을 수 없습니다. 즉, 영업이라는 게, 고객이 부르면 ‘백미터 앞에서도 무릎 꿇고 달려오는 것’이란 말도 있지만. 차기 프로젝트를 염두해 두고, 지금 프로젝트도 성공시켜야 하는 PM에게, ‘근태’라는 성공기준은 ‘독이 묻은 사과’인 듯합니다.

저도 가끔 이런 딜레마에 빠질 때면, 만가지 생각이 스쳐 지나가지만, 삶의 기준에 맞춰 살려고 노력합니다. 그러나 그게 쉽지 않다는 것을 느끼죠. 어쨌든 저는 근태가 성공기준인 프로젝트 이야기를 들을 때마다, 이 노래 가사가 생각납니다.

그저 버티는 건 정말 사는 걸까, 그녀를 내버려 둬 씨앗을 심듯이…

이상은의 ‘성녀’ 중에서

CMM을 처음으로 접하는 것은, 02월드컵의 열기가 잦아들고 02대선의 열기가 후끈달아오른 시점이었습니다. 그 당시에는, CMM을 회사에 적용하는 게 일종의 유행이었죠. 제가 몸담고 있던 회사에서도, CMM을 이런 저런 사업부에서 적용하기 시작했죠. 제가 근무했던 연구소에서는 ISO9001을 적용하고 있었지만, IS9001기반으로 정리된 SW개발 프로세스가 그다지 상세하지 않았기에, 개발하는 데 큰 도움을 주지 못했습니다.

인원은 모자르고, 일은 많고, 납기가 늦어지는 경우가 왕왕 있었기에, 제가 있던 연구소에서도 CMM을 적용하자는 분위기가 있었습니다(물론 CMM을 적용하다고 이런 문제가 해결된다는 것은 물음표입니다). 그리하여, CMM을 배워 오기 위해, 비행기를 타고 동료들과 CMM5레벨을 취득한 인도연구소로 향했습니다. 그곳에서 2주 동안, 친숙하지 않은 주제인데, 익숙하지 않은 인도 영어로 배움을 얻으려고 하니 참 고단했습니다. 짧은 기간이었기에, “CMM이라는 게 그런 거구나”하는 느낌 정도를 받아 왔습니다.

그러고 나서, 인도연구소에서 온 엔지니어들과 CMM을 적용한 파일롯 프로젝트를 약 2달간 진행했습니다. 저는 당시에 여러 가지 일이 있었는데, 가욋일 비슷하게 저도 파일롯 프로젝트에 참석했죠. 대충 그 프로젝트를 통해서, 윗분들이 CMM을 연구소에 적용하는 게 의미있는지 살펴보려는 의도였습니다. 인도에서 공부도 쉽지 않았는데, 그 짧은 기간에 파일롯 프로젝트를 수행한다는 게 만만하지 않았죠. 우여곡절 끝에, 파일롯 프로젝트는 끝나고 다행스럽게 CMM을 조직에 적용하는 것은 시기상조다, 그리고 별 이득이 없다는 결론이 내려졌습니다. 하하…

어찌 어찌하여 이직하고 몇 년이 흘렀습니다. 그리고 지금 있는 곳에서도 CMMI 인증을 얻으려고 준비했고, 3레벨을 취득했습니다. CMMI나 기타 인증시스템을 취득해 보거나, 취득한 회사에서 근무하신 분들은 아시겠지만, 이런 인증모델을 조직차원에서 적용한다는 것은, 자신이 맡은 혹은 참여한 프로젝트에서도 인증을 유지하기 위한 프로세스를 따라야 한다는 의미입니다.

조직 차원에서, 프로젝트가 CMMI 영역을 준수하는지 파악하기 위해, 보통은 QA팀에서 품질보증활동을 합니다. 즉, 품질보증을 위한 체크리스트를 활용해서 QA담당자들이, 프로젝트 산출물을 검토하고, 의심이? 생기는 부분은 프로젝트 관리자나 팀원들과 인터뷰로 확인합니다. 이런 이유로, CMMI를 준수하는 회사에서 운영되는 프로젝트는 문서 작성을 소홀히 할 수 없습니다. 물론, CMMI에서 문서 작성을 반드시 하라고 말하지는 않지만, 심사관이나 QA담당자가 프로세스를 준수하는지 파악할 수 있는 유일한 방법 그리고 객관적인? 방법은, 산출물이기 때문입니다.

SI회사에서, 대개 CMMI 레벨을 취득하기 때문에, PM에게 산출물을 잘 작성하고 관리하는 게 중요한 능력으로 평가받기도 합니다.

CMMI는 프로세스 개선, 평가 모델이기 때문에, 어떤 개발방법론을 따르라고 명시하지 않습니다. 그렇기 때문에, 프로젝트에서 폭포수 방법을 써도, 반복적인 방법(iterative methodology), 점진적인 방법(incremental methodology), 애자일 방법론(agile methodology)를 사용할 수 있고, 사용해도 괜찮습니다. 그런데, 애자일 방법론을 CMMI인증을 받은 조직에서 사용하다 보면, 일종의 형용모순을 겪습니다. 왜냐하면… 애자일 선언과 CMMI의 접근방식이 모순을 일으키기 때문이죠.

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

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

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

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

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

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

애자일 선언문에서 알 수 있듯이, 애자일 방법론은 ‘프로세스와 도구’보다는 ‘개인과 상호작용’을 중시하기 때문입니다. 애자일 방법론은 경량 프로세스(light weight process)라고도 불립니다. 즉, 전통적인 프로세스(heavy weight process)에 반발해서, 애자일은 경량 프로세스를 외치면서 만들어졌기 때문입니다.

자! 그렇다면, CMMI, 즉 전통적인 프로세스를 적용하는 SI회사에서, 애자일 방법론을 적용한다는 것은 일종의 형용 모순처럼 느껴지지 않으신가요? 맞습니다. SI회사에서 애자일은 확실히 가능하지만, 한편으로 CMMI 프로세스를 준수해야 하기 때문에 이러 저러한 어려움이 있었습니다.

즉, 우선순위라는 것은 결국 순서를 세워야 한다는 의미인데, 모든 것이 우선순위 1번이라는 것은 이미 모순적인 말입니다. 다시 애자일 방법론으로 돌아와서, ‘프로세스’보다는 ‘개인과 상호작용’에 비중을 두는 것이기에, 프로세스가 이러 저러 하기 때문에, “고객님의 요구사항”을 받아들일 수 없다는 논리를 편다는 게… 썩 개운치 않습니다.

그렇다면, CMMI속에서 애자일을 적용한다는 것은 모순투성이 일일까요? 지금까지 제가 내린 결론은, 절반의 긍정과 절반의 부정입니다. 즉, CMMI를 적용한다면 변경요청서를 작성하는 작업이 고객의 요구사항을 애자일하게 반영하는 것보다 더 중요할 수 있습니다. 반대로 애자일을 적용한다는 것은 그깟 ‘문서 작업’은 이슈 추적 시스템에 기록한 티켓 정도로 충분할 수도 있습니다. 아무튼 이런 모순이 존재하기에, CMMI도 준수해야 하고 애자일 방법을 프로젝트에 적용해야 하는 PM은 무척이나 분주해질 수 있습니다.

프로젝트에서 중요하지 않은 팀원은 없습니다. 팀원이 모두 자신이 맡은 일을 제대로 할 때 좋은 결과가 생기기 때문이죠. 하지만, 행정적인 업무를 처리하고, 조직차원의 규칙도 준수하면서, 팀원들이 신나게 일하는 환경을 만들기 위해서, 즉 CMMI도 지키고 애자일 실천방법도 프로젝트에 적용하려면, 전체적인 관점에서 CMMI와 애자일을 잘 엮을 수 있는 PM의 역할이 중요한 셈이죠.

그래서 한줄 요약은, “CMMI와 애자일을 동시에 따른다는 게 쉽지  않다”정도 입니다.

금요일, 조금 한가한 점심시간을 틈 타 올려보는, 번역 팁입니다. 두 문장은 각각 어떻게 번역하면 좋을까요?

To program is not easy.

Programming is not easy.

언뜻 보면, 두 문장이 비슷한 것을 이야기하는 듯합니다. 그리고 수십 만개의 문장으로 구성되는 원서를 옮기다 보면, 이런 작은 차이까지 옮길 정도의 집중력을 지닌 번역가도 흔하지 않을 겁니다.

두 문장의 차이는 앞문장에서 to부정사를 쓴 것이고, 뒷문장에서 동명사를 쓴 데 있습니다. 굳이 차이를 또 찾자고 하면 앞문장은 to가 있기 때문에 5단어로 구성되어 있고, 뒷문장은 4단어로 구성되어 있습니다. 그렇습니다, 4단어로 말할 수 있는 것을, 5단어로 말한 이유에서 번역의 힌트를 찾을 수 있습니다.

즉, 앞문장은 프로그래밍을 강조하기 위해, 말이 길어짐에도 불구하고 to를 사용한 것이죠. 이것이 바로 ‘to부정사의 강조용법’에 해당합니다. 뒷문장은 그냥 프로그램이 쉽지 않다는 사실을 담담하게 이야기하는 것이구요. 그렇다면 이런 뉘앙스를 우리말로 어떻게 옮길까요?

프로그래밍은 쉽지 않다.

프로그래밍이 쉽지 않다.

이렇게 옮긴 문장에서 우리말 조사 ‘은’의 강력함이 다시 한번 빛을 발합니다. ‘은/는’과 ‘이/가’를 그다지 구분하지 않는 경향이 있습니다만, 두 조사는 분명 쓰임새가 다른 조사입니다. 앞문장은 ‘프로그래밍’을 강조하는 뜻이지만, 뒷문장은 사실을 평이하게 전달하죠. 즉, 앞문장에서 다른 인간의 활동이 더 쉬운지, 더 어려운지 판단을 유보하게 하는 뉘앙스가 숨겨져 있습니다.

번역 맡은 게 있어서, 몇 주전에 여름 휴가지만 휴가를 개인적으로 반납한 채, 번역 작업에 5일 정도 매진했습니다. 우연찮게 전업 번역가의 삶을 주 5일 정도 체험한 셈이죠. 제가 틈틈이 번역한다는 것을 아시는 분들은, 제게 번역하면 돈 많이 버냐고 농담삼아 물어보십니다. 예전 포스트에서도 언급을 했지만, 다른 분야는 모르지만 제가 경험한 IT 서적 번역은 그다지 많은 돈을 벌지 못합니다.

아무튼 5일 동안 번역 작업에 매진하면서, 리플레시하는 의미로, 상반기 최고 베스트셀러인 시크릿 번역가인 김우열씨가 지은, ‘나도 번역 한번 해볼까?’를 읽었습니다. 이 책은 번역의 세계에 발을 들여놓고 싶은 예비번역가를 위해, 번역가의 삶이란 어떤 것인지 생활면, 소득면, 비전 측면에서 친절하게 설명해줍니다. 예비 번역가도 읽어보면 좋고, 저처럼 번역 몇 번 해본 사람도 읽어도 얻는 게 있는 책인 듯합니다.

사실, 번역 수입을 물어보는 지인들에게 IT서적의 수입은 쉽게 알려줄 수 있었지만, 다른 분야… 예를 들면, 소설, 경제, 사회 서적의 번역수입은 알려드리지 못했고, 궁금하기도 했는데, 김우열씨의 책을 통해서 대충 가늠해 볼 수 있었습니다.

보통 영어 원서 200쪽 내외 책을 우리말로 번역하면 원고지 1,000매 내외가 나옵니다. 번역 단가는 실력과 경력과 지명도 등에 따라 달라지지만 영어를 기준으로 2,500원에서 6,000원 사이입니다. 이것은 200자 원고지 1장 가격입니다. 원고지 100매 나오는 책을 번역해서 넘겼는데, 처음에 계약한 번역 단가가 2,500원이라면 250만원을 받게 될 테고 단가가 6,000원이라면 600만원을 받겠지요.

번역가의 실력에 따라서 다르겠지만, IT이외 분야에서 200쪽짜리 원서를 번역한다면 대략 250만원에서 600만원을 받는다는 이야기입니다. 통계적으로 의미가 있는 데이터는 아니지만, 저쪽 동네 번역가들은 그 정도 받는다는 것을 알 수 있습니다. 그럼 IT쪽은 어떨까요? IT전문지식이 풍부하시겠만 번역 경험이 없는 분들은 IT서적을 번역하실 때, 제가 들은 바로는 원서 1장 기준으로 7천원에서 만원 사이를 받는 걸로 압니다. 즉, 200쪽 기준으로 대략 140만원에서 200만원 사이를 왔다갔다 하겠네요.

김우열씨가 제시한 데이터와 제가 들은 데이터만을 두고 보면, IT동네의 번역료가 상대적으로 낮다는 생각이 들지만, 1쇄 팔기도 부자가 천국에 가기만큼 어려운 IT동네에서 이런 번역료도 적지 않은 금액입니다.#

여기까지 읽으시면, IT서적을 번역하시는 분들이 돈만 보고 하시지는 않는다는 생각이 드실 겁니다. 제가 아는 분이나 제 경우도, 좋은 원서고 묘한 재미도 있으니까 노동량보다는 적은 돈이지만 번역이라는 미로(?)에 빠지는 듯합니다.

소명의식 약간으로 번역하시는 분들을 제외하고, IT전문 번역가는 전문직업으로써 매력이 없는 직업일까요? 우물 속에 갇혀서 세상을 보면, 우물 위로 보이는 세상이 전부고. 셀리그만의 실험실에 갇힌 견공처럼, 세상을 바꾸는 일이란 불가능하다는 무력감에 빠져 있다면, 자물쇠가 풀린 감옥도 철옹성입니다.

직업이라는 건, 밥벌이를 무시할 수 없지만 끊임없이 자신을 불태울 동인을 줘야 합니다. 누군가는 열정이라고 표현하고, 혹자는 내적 동기라고 부르기고 하는데. 아무튼 이런 불덩어리 하나씩을 가슴 속에 지피게 하는 게 바로 직업이어야 합니다. 이런 이유로 돈  때문이 아니라, 번역이라면 미칠 정도로 빠져 들고 싶은 분들이라면, IT번역 시장도 노력하시는만큼은 보상받을 수 있는 분야라고 생각합니다.

그래도 IT 전문 번역가가 되고 싶은데, 제 글을 읽고 얼마 벌지 못한다고 생각하시는 분들을 위해 한 가지 해법을 다음 번 포스트에 알려 드리겠습니다.

# 조금 오버했습니다.