Talk about Software with hani

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 전문 번역가가 되고 싶은데, 제 글을 읽고 얼마 벌지 못한다고 생각하시는 분들을 위해 한 가지 해법을 다음 번 포스트에 알려 드리겠습니다.

# 조금 오버했습니다.

부하직원들 사이에서, 별명이 ‘쫌해봐’라는 부장님이 계셨습니다. 이 부장님은 불가능해 보이는 일을 시키면서, 쉽지 않은 일이라고 항변하는 부하직원들에게

뭐, 어렵다고 그래. 쉽잖아. 좀 해봐!

라고 항상 말씀하셨기 때문에, 부하직원들은 부장님의 말버릇을 줄여서 ‘쫌해봐’라고 불렀습니다. 부하직원들은, 일이라는 게 쉬운 것도 있고 어려운 것도 있는데… 이 부장님이 ‘쫌해보면’ 모든 일이 다 된다고 생각하는것 아니냐는 불만 아닌 불만을 토로했습니다.

가끔 프로젝트는 러시안 룰렛이 아닐까?하는 생각이 들 때가 있습니다. 프로젝트를 가려 가면서 하지 못하지만, 정말로 저 프로젝트만은 맡고 싶지 않다는 심정이 들게 하는 프로젝트가 있습니다. 이런 프로젝트가 내가 몸 담은 조직에 떨어지면, PM은 서로 눈치만 봅니다. 즉, 부장님이 제발 나를 지목하면서

OO씨가 이번 프로젝트 좀 맡아주면 좋겠는데.

라고 말하지 않길 바랍니다. 하하하. 누군나 방아쇠를 당기겠지만, 제발 총알의 주인이 내가 아니길 바라는 마음이 듭니다. 인지상정인 셈이죠.

사실, 이런 프로젝트의 특징은 위험이 높거나 많다는 데 있습니다. 완전히 새로운 형태의 프로젝트이거나, 고객이 변덕스럽고 야근을 좋아하거나, 영업이 먹튀성으로 계약을 한 프로젝트거나… 등등 나열하기에 타이핑하는 손이 아플 정도로 다양한 위험이 존재하는 프로젝트입니다.

물론 위험이 많다는 것의 긍정적인 면을 보자면, 기회도 많다는 뜻입니다. 즉, 완전히 새로운 형태의 프로젝트라면 새로운 경험을 할 수 있고, 불가능해 보이기 때문에 성공시키면 인정을 받을 수 있습니다.

이처럼 야누스 같은 프로젝트이지만, 어떤 자리에 있느냐에 따라서 보는 게 달라집니다. 예를 들어 ‘쫌해봐’ 부장님처럼 조직을 이끌고 실적을 내야 하는 자리라면, 위험보다는 기회를 볼 것이며. 재수없게 총알이 장전된 권총을 든 PM이라면 금맥보다는 막장에 갇힐 위험을 봅니다.

그러나, ‘된다고 믿는 사람’과 ‘안 된다고 부정하는 사람’이 싸우면, 항상 긍정적인 신념을 가진 사람이 이깁니다. 실천은 차치하더라도, 말싸움에서 ‘긍정적인 마음 가짐으로 쫌 해봐!’라는 말이면, 상황이 종료되기 때문입니다.

물론 긍정적으로 일을 대하는 자세도 좋지만, 어쨌든 결과를 내야 하는 PM입장에서 그까짓 것 ‘쫌 해 보면 어떻게 되겠지’라는 마음가짐은 위험이라는 불이 붙은 프로젝트에 기름을 붙는 행위입니다.

자, 그렇다면 어떻게 해야 할까요? 아니 구체적으로 여러분에게 위험 부담이 높은 프로젝트가 떨어졌습니다. 그리고 건너편에 ‘쫌해봐’의 마인드로 무장한 상사가 앉아 있습니다. 어떻게 하실 건가요?

어쩔 수 없이 여러분은 농약 먹은 쥐를 잡아먹어야 하겠지만, 프로젝트를 적어도 성공쪽으로 돌려 놓기 위해서, 프로젝트를 시작하기 전에 예상되는 위험에 대해서 최대한 자세하게 나열을 하고, 각 위험에 대해서 상사와 팀원들과 이야기를 해야 합니다.

프로젝트 시작 전, 위험을 파악하고 분석하고, 대책을 마련하는 행위를 하지 않는다면, 가득이나 실패할 프로젝트를 시작과 동시에 안드로메다로 보내버리기 때문입니다.