Archive for July, 2006


화두, S/W Engineering의 필요성

Thursday, July 20th, 2006

화두 : 불가의 수행자가 깨달음을 얻기 위해 참구(參究)하는 문제.

from naver 백과사전

오늘 한 시간동안 S/W Engineering에 대해서 Presentation을 했습니다. 끝날 무렵 한 분이 “S/W Engineering이 왜 필요하죠?”라는 질문을 하시더군요. S/W Engineering 관련해서 Presentation을 하거나, 필요성에 대해서 이야기를 할 때면 항상 듣는 질문이기 때문에 자동으로 대답해 드렸습니다.

“좋은 품질의 S/W를 더 쉽고 더 빠르게 만들기 위해서죠.”

형이상학적이고 복잡하게 답을 할 수 있었지만, S/W Engineering을 하는 목적은 위의 한 문장으로 요약될 수 있습니다. 질문하신 분의 표정을 보니, 제 질문에 그다지 만족하신거 같지 않더군요. 역시나 제 답변이 마음에 들지 않으셨는지, 다른 질문을 하셨습니다.

“그럼 S/W Engineering을 하지 않으면 좋은 품질의 S/W를 만들 수 없나요?”

이 질문을 듣자, 갑자기 머리 속에는 어릴 때 많이 했던, 그리고 지금도 해변에 놀러 가면 한번씩 해보는 모래성 게임이 생각났습니다. 모르시는(?) 분을 위해서 이 게임에 대해서 간단히 설명 드리겠습니다. 모래성을 쌓고 가운데 나뭇가지 꺾은 것을 꽂아 두고 사람들이 돌아가면서 모래 한 줌씩 가져갑니다. 결국 가운데 꽂아 둔 나뭇가지를 쓰러뜨린 사람에게 피의 응징이 가해지는 단순하지만, 재미있는 게임이죠.

Presentation할 때는 생뚱맞게 이 게임이 왜 생각났는지 알 수가 없었습니다. 질문하신 분이 애타게 대답을 기다리셨기 때문에, 모래성 게임 생각은 잠시 접고 질문에 적당한 답을 찾았습니다.

“S/W Engineering을 하지 않아도 품질 좋은 S/W를 만들 수 있습니다. 그러나 S/W Engineering을 제대로 적용한다면, 적용하지 않았을 때보다 좋은 품질의 S/W를 얻을 수 있습니다.”

제 대답에 만족하셨는지는 모르겠지만, 그분은 더 이상 질문하지 않으셨습니다. 돌아오는 길에 Presentation을 할 때 모래성 게임이 생각난 이유를 곰곰히 생각해 봤습니다. 모래성 게임에서 보통은 다음 사람을 술래로 만들려고 나뭇가지가 쓰러지지 않을 만큼 흙을 가져 옵니다. 다음 사람도 운이 좋다면 술래가 되지 않을 수 있지만, 적어도 내 차례는 오지 않을겁니다.

나뭇가지를 지지하고 있다는 측면에서, 모래성을 구성하고 있는 모래 가운데 99%는 의미가 없습니다.(그러나 이 게임을 게임답게 만들기 위해서는 99%의 모래가 있어야 합니다.) 마찬가지로 처음 질문의 대답으로 드렸던 “좋은 품질의 S/W를 더 쉽고 더 빠르게 만들기 위해서”라는 목적에서 봤을 때, S/W Engineering의 많은 방법론, 기술은 모래성의 나머지 모래와 같지 않을까라는 생각이 들더군요.

그런데 이 생각은 제가 이 블로그에서 손가락에 힘주어서 타이핑했던 수 많은 기술과 방법론을 한 줌 재로 산화시켜 버릴만큼 위험합니다. 마치 S/W Engineering 무용론을 주장하는 것처럼 보일 수 있기 때문입니다. 그러나 인생의 나침반을 S/W Engineering으로 결정하면서 제 자신과 했던 다짐이 있었습니다.

“S/W Engineering을 위한 S/W Engineering은 하지 말자”

S/W Engineering이 극단으로 치달으면, 전형적인 관료주의가 될 수 있습니다. 이런 관료주의를 옆에서 지켜 보기도 했고, 관료주의의 희생양이 되기도 했습니다. 그렇기 때문에 인생의 목적을 S/W Engineering으로 결정했을 때는 제 자신이 관료주의로 치닫는 것을 막기 위해서, S/W Engineering이라는 범주 안에서 행해지는 활동들이 S/W Engineering의 진짜 목적에 얼마나 부합하는지에 대해서 항상 고민해야겠다는 생각 했습니다.

그리고 이런 맹세를 지키기 위해서, S/W Engineering 인생을 각성하게 만들어 주는 화두 하나를 정했습니다. 이 화두가 “S/W Engineering을 왜 해야 하지?”였습니다. 바로 오늘 받았던 질문입니다. 그러나 습관적으로 적용하는 S/W Engineering 기술들 속에서, 오랜 시간이 지나지 않았는데도 화두는 Presentation 때 받는 일상적인 질문에 반성없는 답변이 되어 버렸습니다.

따라서 화두를 잊어버리고 살았던 삶에 대한 무의식적인 반성으로 모래성 게임이 생각난 듯 합니다. 제가 이 블로그에 썼던 많은 S/W Engineering 이야기는 그 나름 가치가 있고 주의 깊게 사용한다면 효과를 얻을 수 있습니다. 다만 반성 없이 적용하고, 생각없이 따랐을 때는 본연의 목적을 잃어 버리고, 나무가지를 지탱하는 1%의 모래가 아닌, 의미없는 99%의 모래가 되어 버립니다. 따라서 S/W Engineering이 개발자를 위협하는 프랑켄슈타인이나, 억압하는 관료주의가 되지 않기 위해서는 끊임없는 자기 반성이 필요합니다.

그럼으로 우리가 본질이라고 믿는 것을 지키기 위해서는 본질적이지 않은 것을 희생할 수 있는 전문가다운 화두 하나를 항상 가슴에 담고 있어야 합니다.

[Book Review] 착한아이 콤플렉스

Tuesday, July 18th, 2006

장동건이 “별로 잘 생긴 얼굴이 아닌거 같아요”라는 말을 해서 세상을 뒤집어 놓은 적이 있습니다. 잘 생긴 걸로 치면 상위 0.00000001%에 속할만한 인물이 정작 본인은 못생겼다는 커밍 아웃을 하니, 장동건 뒤로 줄 서 있는 전국의 수 많은 추남들은 x 씹은 심정이 될 수 밖에 없습니다.

간혹가다 외계인이 아닐까라는 의심을 품게 만드는 옌예인들이 퍼트리는 이런 외모 콤플렉스 스캔들 덕분에, 잘난 사람들도 별거 없구나라는 카타르시스를 줍니다. 그리고 인간이라면 지위고하를 막론하고 콤플렉스 한둘은 가지고 산다는 평범한 진리를 깨닫게 해줍니다. 따라서 콤플렉스는 정량적으로 평가할 수 있는 것이 아니라, 본인만이 판단할 수 있는 내면의 문제라는 결론에 도달하게 되죠.(물론 콤플렉스가 생긴 원인은 사회적일 수 있습니다.)

잘생긴 장동건도 지니고 있는 콤플렉스를, 종류와 갯수는 다를 뿐 모든 사람이 갖고 있습니다. 따라서 콤플렉스는 사람 수만큼 다양합니다. 인터넷에서 콤플렉스로 검색을 해 보니 무척 많은 콤플렉스가 나오는군요. 외모 콤플렉스, 신데렐라 콤플렉스, 장남 콤플렉스, 맏딸 콤플렉스, 오이디푸스 콤플렉스, 엘렉트라 콤플렉스 등등. 재미삼아 만들어낸 콤플렉스도 있고, 병리 현상을 정리한 콤플렉스도 있습니다.

다양한 콤플렉스는 이것을 지니고 있는 사람의 마음 상태와 환경에 따라서 “아는게 힘이다”될 수도 있고, “모르는게 약이다”이 될 수도 있습니다. 콤플렉스를 있는 그대로 받아들이고 극복할려는 사람에게 콤플렉스는 성장의 엔진이 될 수 있습니다. 하지만 어떤 이에게 콤플렉스는 삶의 무게보다도 더 크게 다가오기 때문에 평범한 삶조차 살 수 없게 만듭니다.

오늘 소개 드릴 조안 루빈의 “착한아이 콤플렉스”(샨티 출판)도 콤플렉스의 양면성을 지적하고 더 나은 삶을 살기 위해서 콤플렉스를 극복하라고 말합니다. 이 책의 핵심은 “착한아이 콤플렉스”를 이해하는 겁니다. 저자가 주장하길 사람은 어렸을 때 부모와 계약을 맺습니다. 즉, 아이들은 생존을 위해서 부모에게 의지하고, 부모의 칭찬을 받기 위해서 부모가 말한 아이가 되도록 계약을 맺는다고 합니다. 그런데 어렸을 적 잘못 맺은 계약은 성인이 되서도 영향을 미쳐서 자신에게 충실한 삶을 사는데 방해를 합니다.

예를 들자면 

부모의 메시지 “우리 집에서는 기분이 어떻다는 둥의 이야기는 하지 않도록 해라.”
어린 시절의 계약 “내 느낌을 숨겨야겠다. 그렇지 않으면 엄마 아빠가 나에게 화가 나실 거야. 잠자코 있으면 날 예뻐해 주시겠지.”
어른이 되어서 “나는 내 감정을 잘 표현할 수가 없다. 내가 느끼는 것을 그대로 드러낼 경우 사람들이 그런 감정을 갖는 것을 의아하게 생각하거나 나를 싫어하게 되지나 않을까 두렵다”

저자는 복잡하게 착한 아이 콤플렉스라고 정의를 했지만, 한 사람을 결정 짓는 것은 부모와의 관계입니다. “우리 아이가 달라졌어요”와 “Nanny 911″ 같은 프로그램을 보거나, 자신의 현재 모습과 부모님과의 관계를 되집어 보면 대부분이 동의할 내용입니다.

아무튼 다시 책 내용으로 돌아와서, 만일 자신이 어렸을 적 부모와 맺은 계약 때문에 현재 삶에 충실하지 못하다면, 부모와 맺은 계약이 무엇인지 분석하고 그것을 극복해서 행복해 질 수 있다고 합니다. 책 내용은 “착한아이 콤플렉스”를 이해했다면, 읽지 않아도 될 정도로 같은 이야기의 나열입니다. 그리고 주제 자체가 관념적인데, 내용도 관념적으로 흐르기 때문에 몇 십 페이지씩 건너 뛰고 읽어도 책의 흐름을 놓치지 않는다는 장점도 있습니다.

여기까지 읽으신 분들은 그렇게 권할만한 책도 아닌거 같은데 리뷰를 쓰는 이유가 궁금하실겁니다. 추천 도서도 아닌데 리뷰를 쓰는 이유는 주제가 주는 묵직함 때문입니다. 우리나라의 평범한 가정에서 자라난 사람이라면 (특히 제 나이 이상의 연배라면) “착한아이 콤플렉스”는 정도의 차이는 있지만 누구나 약간씩은 지니고 있다고 생각합니다. 왜냐면 우리 사회는 부모 말씀을 잘 듣는 것을 최고의 가치로 가르쳤기 때문입니다.

이 책을 읽기 전부터 고민했던 문제지만, 저에게는 남한테 이야기할 수 없는 콤플렉스 몇가지가 있었습니다. 가지고 있던 콤플렉스 가운데 많은 것들을 극복했기 때문에 콤플렉스를 가지고 있었다고 말할 수 있습니다. 즉, 어떤 사람이 자신이 가지고 있던 콤플렉스를 극복했냐 못했냐를 판단할 수 있는 기준은 “자신의 콤플렉스를 제 3자에게 덤덤한 심정으로 말할 수 있냐”입니다. 극복하지 못한 (진짜로 자신을 괴롭히는) 콤플렉스는 수치심과도 비슷하기 때문에, 극복의 대상일 때는 다른 사람들이 자신의 콤플렉스를 알아볼까 두려워합니다.

극복했던 콤플렉스 가운데는 “착한아이 콤플렉스”도 있었습니다. 물론 저자가 말한 것처럼 생존을 위해서 부모님과 제가 암묵적으로 맺은 계약인지는 모르겠지만, 저자가 지적한 “착한아이 콤플렉스” 범주에 속하는 컴플렉스였습니다. 한마디로 “착한 사람이 되자”였죠. 일차적으로 “못된 사림이 되자”가 “착한아이 콤플렉스”를 극복하는 방법은 아닙니다. (저자와 비슷하지만) 제가 생각하는 “착한아이 콤플렉스”의 극복 방법은 “다른 사람이 아닌 자신의 기준으로 세상을 바라보는 것입니다.”

물론 이 극복 방법은 말은 쉽습니다. 그리고 “착한아이 콤플렉스”를 극복했다고 주장하는 지금도 가끔은 다른 사람의 기준으로 세상을 판단할 때가 있습니다. 그러나 그럴 때마다 여지없이 뒷끝이 개운치 않은 것을 보면, 역시 세상을 나만의 기준으로 살아간다는 것이 쉽지만은 않은거 같습니다. 물론 나만의 기준으로 세상을 살다 보면, 세상과 충돌이 생깁니다. 

“착한아이 콤플렉스” 극복 초기 단계에 가장 큰 딜레마는 “내 의견과 다른 사람의 의견이 충돌될 때, 그 사람의 의견은 옳은가” 였습니다. 그러나 “나만의 기준으로 세상을 바라보자는 생각”은 “착한아이 콤플렉스”를 극복하면서, 다른 사람과의 충돌을 의미하지 않는다는 것을 알게 되었습니다. 반대로 다른 사람의 의견도 나름 가치를 가지고 있다는 것을 새삼 깨닫게 되었습니다.

결론은 간단히 말하면 콤플렉스를 인식하고 극복하면 행복하다 정도겠죠. 관념적인 책을 소개하다 보니 관념적인 Review가 되는군요. 물론 post를 다시 읽어보니 오랫동안 앓고 있던 병에서 왠쾌한 환자처럼 자신만만하게 콤플렉스를 극복했다고 쓴거 같습니다. 그러나 이 세상을 자신만의 가치로 판단하고 살아간다는 것은 완료형이 아닌 진행형의 삶이겠죠? 물론 제게도 해당하는 이야기입니다.

프로젝트 완료

Thursday, July 13th, 2006

내일은(7/14) 약 10개월 동안 숨가쁘게 달려왔던 대장정의 점을 찍는 날입니다. 물론 내일을 위해 10개월이 존재했었다는 말처럼 허무한 표현은 없지만, 프로젝트 완료 보고 때문에 힘들고 고단했던 시기들이 새로운 의미로 다가오는군요.

완료 보고서를 작성하다 보면, 정량적인 가치를 산출할 수 없는 프로젝트에서 정량적인 지표를 써야 한다는 사실은 PL로써 참으로 힘든 일입니다. 하지만 경영자에게 보고하기 위해서는 정량적인 지표를 무시할 수 없는 현실이기도 합니다. 나름의 논리로 가치를 산출하는 프로젝트일 때는(이 세상에서 프로젝트에 대해서 가장 잘 아는 사람은 나이기에), 정량적인 지표를 뽑으면서 ‘0′ 하나를 덧붙이고 싶다는 욕심이 들 때도 있습니다. 그러나 이런 유혹에 쉽게 넘어가지 않는 것은 양심이라는 균형자가 유효하게 작동하고 있다는 사실이기에 안심이 됩니다.(간혹 현실의 논리에 밀릴 때도 있지만요. 엔지니어로써 슬픈 순간입니다.)

“0000 억 절감 효과”라는 경영자들의 구미에 맞는 성과 이외에도 프로젝트는 수 많은 가치를 창출합니다. 예를 들자면, 프로젝트를 통해서 얻은 개인적인 성취감, 발전, 팀웍, 동료애 등등 이런 가치들이 눈으로 쉽게 보이고 회사에도 도움이 된다면 좋겠지만, 완료 보고를 해야하는 PL 입장에서 이런 무형의 가치를 보고서로 꾸밀 수 없는 능력의 한계에 아쉬움이 남습니다.

완료 보고서를 완성했을 쯤에 이런 생각이 들었습니다. 무형의 결과들이 경영자나 상사에게 인정을 받지 못한다고 해도, 또한 프로젝트 성과가 훌륭하지 못했다 해도 프로젝트 팀에 참여해서 이런 무형의 가치를 체험하고, 나누고, 만들었다면 그나름 의미가 있지 않나라는 생각을 합니다. 박봉에, 힘들어도, 다시는 프로젝트를 하지 않을거라는 다짐 속에서도 이 때문에 (마음이 맞는 동료와) 새로운 프로젝트를 시작하는 이유겠죠.

Special thanks to…

고객이지만, 프로젝트 팀보다 기술적인 탁월함과 이해심을 발휘한 조주임님,
끝까지 함께하지 못했지만 많은 조언을 준 이선임님,
좋은 출발을 하고 계신 fastsearch.com의 이팀장님, 윤부장님,
팀원인 영창씨… 이 모든 분들에게 수고하셨다는 말을 전합니다.

인수테스트, 북치고 장구치고 2/2

Tuesday, July 11th, 2006

팀장의 고백 목차

지난 post에서 테스트를 해야 하는 이유를 간단히 살펴 봤습니다. 그럼 이번 post에서는 다양한 테스트 중에서 인수테스트의 의미와 효용성을 살펴 보겠습니다. 인수 테스트를 처음 들어 보신 분들을 위해서 인수 테스트의 정의를 간단히 알아보고 넘어 가겠습니다. 인수테스트란 “개발된 시스템이 고객의 요구사항과 일치하는지 확인하기 위해서 고객 주관으로 수행하는 테스트”를 뜻합니다. 간단히 정의한다고 했는데, 다소 복잡한거 같습니다. 조금 더 쉽게 정의하면… 고객이 말한대로 시스템을 만들었는지, 고객이 직접 테스트하는 것을 인수 테스트라고 합니다.

XP에서는 인수테스트를 다음과 같이 보고 있습니다.

고객 소유의 인수 테스트를 마련하지 못하는 것은 XP에서 가장 흔한 실수 중 하나입니다. 매 반복(iteration)마다 고객에게 인수 테스트 정의를 받도록 하세요. 고객이 그 테스트들을 정의하도록 도와주세요 - 조언을 해주세요. 그 테스트들을 구현하고, 바라는대로 시스템이 작동한다는 것을 고객에게 보여주세요. 고객은 더 나은 테스트와 더 나은 기능을 만드는 법을 배우게 될 것이고, 프로젝트에 참가하는 모두가 당신이 어디쯤 있는지 알게 될 겁니다. 인수 테스트를 작성할 도구를 기다리지 마세요. 다른 여타의 프로그램이나 테스트들처럼 그냥 프로그램하세요. 그 도구들이 시간이 지남에 따라 진화하도록 하세요. 중요한 것은 바로 테스트를 갖는 것입니다. 서문 from XP Installed 론 제프리 외 2명 공저(인사이트)

XP에서 iteration을 끌고 나가는 것이 Story Card라면 인수테스트는 주기의 끝을 알리는 결승점의 깃발과 비슷합니다. 따라서 귀찮은(?) 인수테스트를 매 주기마다 적용하기 위해서 자동화된 툴을 도입할 것을 주장합니다. XP다운 사상이죠.

물론 여러분들은 현업에서 XP를 적용할 수도 있고 안할 수도 있습니다. 마찬가지로 CMM을 적용할 수도 있고 적용 안할 수도 있습니다. 심지어 프로세스 규정집이라고 부를 수 있는 A4용지 한 장조차도 없을 수 있습니다. 그러나 어떤 개발환경이나 어떤 프로세스를 사용하더라도 실천해야 하는 몇가지 practice가 있습니다. 제가 post하고 있는 팀장의 고백 시리즈의 소주제들이 이런 practice가 될 수 있습니다. 마찬가지로 인수테스트도 이 practice에 포함됩니다.

인수테스트와 관련된 업계의 현실을 설명드리겠습니다.

(특히 SI 프로젝트인 경우) 모든 프로젝트는 고객의 요구에서 시작합니다. 빅뱅이 우주의 시작이었던 것처럼요. 그러나 SI 프로젝트가 처해 있는 상황을 보면 “내 시작은 미약했으나 그 끝은 창대하리라!”가 아니고 “내 시작은 창대하였으나 그 끝은 미약하리라!”라는 생각이 듭니다. 고객의 요구 사항은 너무나 화려합니다. 요구 사항의 구현 가능성을 의심하는 것은 민족을 반역하는 행위처럼 프로젝트에서 받아 들여집니다. 그렇기 때문에 고객이 말한 요구 사항은 시나리오로 작성되고, 개발 명세서라는 예쁜 문서로 꾸며지고, 솔거도 울고 갈만큼 진짜 GUI와 비슷한 화면 설계서로도 그려집니다.

그리고 멀고도 먼 구현의 대장정을 떠납니다. A4 용지로 출력된 개발 명세서는 몇번이나 읽었는지 기억이 나질 않습니다. 그리고 어느새 개발 명세서는 입시 공부할 때 사용했던 참고서보다 더 많은 밑줄과 동그라미가 긋어집니다. 물론 열심히 공부 했다고 시험 점수가 잘 나오지 않는 것처럼, 수많은 야근과 특근으로 채워진 일정표가 프로젝트의 성공을 보장해 주지 않습니다. 또한 화려한 설계서와 개발 명세서도 프로그램이 성공적으로 만들어졌는지를 보장해 주지 않습니다. 아니 어느 누구도(고객을 포함해서) 완성된 프로그램이 고객의 요구사항을 만족시키는 것이라고 말해주지 않습니다.

다만 몇 번의 사용자 설명회에서 핵심 고객에게 프로그램(시스템)을 완성했고, 사용해 보라고 설명합니다. 그리고 몇 번의 이벤트만 잘 넘어가면 프로젝트는 끌날거라고 생각합니다. 그러나, 가끔은 순진하고 순수한 고객은 완성된 프로그램(시스템)을 보고 본인이 얘기한 게 아니라고 말합니다. 고객의 갑작스런 변덕에 벼랑 끝에 내몰린 개발자는 개발 명세서, 화면 설계서, 시나리오를 보여주면서 “고객님이 O월 O일에 이렇게 만들어 달라고 하셨습니다.”라고 반박합니다. 그러나 순진하지만 한편으로 꾀가 많은 고객은 “그 버튼을 눌렀을 때 이렇게 이렇게 되야한다고 말했는데, 고객 요구 명세서에는 이렇게 이렇게 만들어야 한다고 적지 않으신거 같은데요.”라고 말합니다.

해맑게 웃고 있는 고객의 얼굴을 보고 있자니, 거짓은 아닌거 같습니다. 자! 이제부터 프로젝트 2막의 시작입니다. 다시 고객의 요구 사항을 정리해서 이번에는 완벽히 만들어야겠네요… 재미 있게 하려고 약간의 과장을 섞었지만, 현실과 큰 괴리가 있는 이야기는 아닙니다. 우리는 고객의 요구사항을 받아 적는데는 어느 정도 수준에 올라와 있습니다. 하지만 요구 사항이 구현되었을 때, 이것을 어떻게 검증할까에 대해서는 아직 초보 수준인거 같습니다. 물론 어떤 분들은 “고객의 요구사항=인수 테스트”라고 주장하실 수 있지만, 이 둘은 남극과 북극이 둘 다 지구에 있는 곳이지만 지리적으로 멀리 떨어져 있는 것처럼 명백히 다릅니다.

둘 사이의 차이점에 대해서 조금 더 설명을 하자면… 고객의 요구 사항과 인수 테스트는 자유 여신상을 바라본 다른 두 화가가 그린 그림처럼 다른 그림입니다.(물론 오브제가 같지만요.) 즉, 고객 요구 사항은 자유의 여신상의 특징적인 인상을 묘사한 인상파 그림이라면, 인수 테스트는 자유의 여신상에 묻은 때까지 정밀하게 묘사해 놓은 초정밀화라고 볼 수 있습니다. 그렇기 때문에 그림이라는 범위에서 고객 요구 사항과 인수 테스트를 보시는 분들은 그냥 그림이라고 하실 수 있지만, 조금 더 관심을 기울이시는 분들에게는 고객 요구 사항과 인수 테스트는 다르며 그 나름 존재 의미가 있습니다.

이 정도로 인수 테스트의 의미에 대해서 이야기를 마치고, 인수 테스트의 효용성에 대해서 알아보겠습니다. 테스트의 효용성이 품질 향상이듯이, 인수 테스트의 일차적인 효용성도 품질 향상입니다. 인수 테스트를 작성하고 작성된 인수 테스트에 맞추어서 테스트를 진행한 후, 발생한 문제점을 수정하면 당연히 프로그램의 품질은 높아집니다. 이건 너무나도 당연한 이야기겠죠. 이것만으로도 인수 테스트를 해야 하는 목적이 분명합니다. 하지만 저는 인수 테스트를 하는 목적이 품질향상 외에 한가지 목적이 더 있다고 생각합니다. 인수 테스트는 프로젝트의 끝을 알리는 (정치적) 깃발 역할을 합니다.

인수 테스트 작성 주체는 고객입니다. 물론 인수 테스트를 작성할 때 프로젝트 팀에서 도와주기는 하지만, 인수 테스트는 고객이 생각하는 요구 사항 만족 기준입니다. 그렇기 때문에 인수 테스트는 고객의 것입니다. 따라서 고객이 작성한 인수테스트를 이용해서 테스트를 끝마쳤다는 뜻은 프로젝트가 완료되었다는 의미입니다. 따라서 이후의 고객의 요구는 완료된 프로젝트 밖의 요구 사항입니다. 반대로 인수 테스트를 하지 않은 경우에는, 모든 요구 사항을 개발했다고 말해도 완료되었다고 주장할 수 있는 자료가 없기 때문에 추가되는 고객의 요구 사항은 프로젝트 범위에 포함됩니다.

제가 이야기 드리는 인수테스트의 효용성은 다소 정치적인 면이 있습니다. 살아 있는 생물체처럼 항상 변하는 고객의 요구를 통제하고 한정된 자원으로 프로젝트 결과를 이끌어야 하는 팀장 입장에서 정치를 외면할 수도 없습니다. 그래서 인수테스트를 작성하는 것이 그나마 프로젝트를 옳은 방향으로 이끌어 갈 수 있는 합리적인 정치 수단이리고 생각합니다. 물론 인수테스트를 작성했다고 해서, 고객의 요구사항은 한마디로 거절할 수도 없습니다. 그러나, 인수테스트와 같은 자료는 정치 판단의 근거를 감정인 아닌 이성의 영역으로 옮겨 놓기 때문에, 고객과 요구사항을 두고 줄다리기를 할 때 기분 좋은 협상을 할 수 있습니다.

반대로 이런 인수테스트를 작성하지 않는다면 명확한 근거가 없기 때문에, 요구사항의 반영 여부는 자칫 잘못하면 감정의 문제로 흐를 수 있습니다. 즉, 프로젝트 팀에서는 “우리는 할 도리를 다 했습니다. 너무 하시는거 아닙니까?” 고객의 입장에서는 “아! Hani 팀장 쫀쫀하게 굴지 말고 이거 하나만 더 해죠.” 이런 식의 협상은 쫀쫀함과 뻔뻔함의 대결이 되기 때문에 요구하는 입장이나 요구받는 입장이나 감정적으로 상하게 됩니다. 이런 이유때문에 인수 테스트는 작성해야 합니다.

지금부터는 이번 프로젝트에서 인수 테스트를 어떻게 작성했고 어떤 결과를 얻었는지 살펴 보면서, 오늘의 post를 마치겠습니다. 일단 제목에서 암시하듯이 이번 프로젝트의 인수 테스트는 제가 작성했습니다. 고객이 다른 업무로 너무나 바쁜 상황이여서… 할 수 없이 제가 작성했습니다. 물론 작성은 제가 했지만, 최종적인 검토는 고객에게 맡겼습니다. 고객이 새로운 내용을 첨가하거나 빼서 인수 테스트를 완성했습니다. 이번 프로젝트에서 인수 테스트를 작성한 이유는 outsourcing 때문입니다. resource를 회사안에서 활용하는 상황이라면 고객의 요구 사항을 한 두가지 더 들어 주는 것은 문제가 아니었으나, outsourcing을 하도 보니 반드시 모듈의 개발 완료를 확정지어야 했습니다.

 

인수 테스트 케이스, 약 220여 항목의 테스트 케이스를 작성했음

작성된 인수 테스트는 프로젝트 시작 시에 협력업체에 전달되었고, 업체는 인수 테스트와 개발 명세서를 활용해서 개발을 진행했습니다. 모듈 개발 후에 몇가지 추가적인 개발이 있었지만, 인수 테스트를 작성해서 고객의 요구가 명확히 반영되었기 때문에 고객과 업체 사이에는 큰 이슈가 없었습니다.(다행이죠! :) )

이상으로 오늘의 post를 마치고, 다음은! 드디어! 팀장의 고백 시리즈의 마지막 편입니다. 기대해 주세요!