대체로 그렇기는 하지만 꼭 잘생기거나 예쁜 사람이 이성 친구가 많은 것은 아닙니다.
성실하고 일을 열심히 하는 사람이 꼭 성공하게 되는 것도 아니지요.
이처럼 세상의 이치는 참으로 오묘해서 정답이란 걸 찾기가 여간 어렵지 않습니다.
이번 글은 월간 마이크로소프트웨어에 실린 글인데요.
맹목적인 방법론의 적용이나 배타 대신 보다 제대로 개발 방법론을 활용하는데 도움이 될 듯하여 옮겨봅니다.
좋은 제품과 잘 팔리는 제품은 다르듯, 잘 만들어진 개발방법론과 널리 쓰이는 개발방법론은 반드시 같지 않을 수 있다. 개발방법론이 널리 쓰이지 않는다면, 그리고 상황에 맞게 변화하지 않는다면 과연 가치 있는 것이라 할 수 있을까? 이런 고민은 방법론 무용론으로도 이어질 수 있다. 그러므로 방법론이 쓸모가 없다고 생각된다면 그 방법론을 의심하기 전에 제대로 활용하고 있는 건지를 먼저 의심할 필요가 있다. 이 컬럼은 이런 전제에서 시작한다.
안영회 ahnyounghoe@gmail.com｜(주)아이티와이즈 컨설팅 SE 그룹에서 컨설턴트로 일하고 있으며, 국내 대규모 프로젝트에서 다년간 방법론, 모델링, 아키텍처 수립, 프로젝트 관리 등의 다양한 역할을 수행하고 있다. 현재는 보험사 시스템 구축 프로젝트에서 소프트웨어 아키텍트로 일하고 있으며 한국스프링사용자모임(KSUG)의 대표를 맡고 있기도 하다. 본인의 블로그인 Younghoe.info를 통해 현장 경험 나누기를 즐기고 있으니 교류를 원하는 분은 언제라도 환영한다.
여러분이 어떤 조직의 IT 운영팀장이라고 가정해보자. 우리 회사는 이미 오래 전에 선진 사례라고 알려진 RU P(Rational Unified Process)를 받아들였다(http://en.wiki pedia.org/wiki/RUP). 예산을 편성해서 프로젝트를 발주했고, 유명 컨설팅 회사가 우리 회사에 맞도록 RUP를 테일러링(tailoring)했다. 결과물은 우리 회사 표준 개발방법론으로 지정했다. 표준 개발방법론은 시스템 개발 과정에서 필요한 역할, 작업 진행을 위한 프로세스를 설명하고 있다. 또한, 각 작업마다 참조할 수 있는 지침과 표준 양식 그리고 점검표 등을 포함하고 있다. 표준 방법론을 만든 이후에 시행하는 모든 시스템 개발 프로젝트에 적용해 보았지만 반응은 기대 이하다. 성과가 없다 보니 자조적인 평가도 나왔다. UML 표기법을 썼다는 점이나 유스케이스(use case) 단위로 산출물을 다룬 형식적인 측면을 빼면 예전보다 나아진 점이 없다고 불평하는 직원도 있었다. 더구나 UML 표기법이나 유스케이스 개념은 조직 내에서 널리 쓰이고 있지도 않다.
방법론은 표준 산출물 양식집?
필자가 최근 3년에 걸쳐 진행한 프로젝트 중에서 두 번은 방법론 담당자로 일했다. 두 차례 모두 표준 방법론을 갖고 있는 회사였다. 하지만, 흥미롭게도 가능하면 그대로 지키는 일은 피해달라고 했다. 현실과 맞지 않기 때문에 자사 표준이지만 가능하면 유연하게 해석해 달라고 했다. 시간과 노력을 들여 만든 방법론을 지키지 말라니 아이러니한 주문 아닌가? 하지만, 프로젝트 경험이 많은 베테랑이라면 입가에 미소를 머금으며 충분히 수긍할 수 있는 부분이다. 모든 상황에는 원인이 있는 법이다. 방법론을 거추장스러운 절차나 복잡한 문서양식 따위로 취급하는 경우는 왜 발생할까? 우선 방법론을 만든 후에 문자 그대로 고지식하게 적용하려고 했던 아픈 기억(?)탓일 수 있다. 개발방법론 도입 초창기에는 사용자가 방법론을 충분히 이해하지 못한 상태에서 곧이곧대로 따르던 시절이 있었다(필자 경력상 주로 객체지향 분석설계에 바탕을 둔 개발방법론 도입 시기에 국한한다). 시스템 개발과 동시에 팀원 다수가 방법론 훈련을 병행해 상당한 스트레스를 받았다고 할 수 있다.
개발방법론이 숨 쉬게 하기
개발방법론을 답답한 문서 안에서 숨도 못 쉬게 놓아두지 말고 현실과 만나게 하라. 현실과 만나야만 방법론이 숨을 쉰다. 현실은 방법론에 변화를 요구하는 다양한 변수를 갖고 있다. 어떤 변수가 있을까? 참여하는 사람만 놓고 봐도 일하는 방식을 바꿀 소지는 쉽게 찾을 수 있다. 일단 사람이 많아지면 모든 의사 소통을 구두로 할 수는 없다. 더구나 참여 기간이 달라지거나, 물리적으로 떨어진 공간에서 일하는 경우에 똑같이 일할 수 있을까? 또한, 숙련된 개발자와 그렇지 않은 개발자 모두에게 같은 방법을 고수하면 결과는 어떨까? 사람을 기준으로 얼핏 살펴보았지만, 개발하는 기능 개수, 사용하는 기술 플랫폼 종류, 계약이나 납품 절차 등을 하나하나 꺼내보면 변수는 매우 다양하다. 방법론을 프로젝트에 효과적으로 사용하기 위한 방법은 매우 간단하게도 정리할 수 있다. 방법론이 현실을 만나게 하라. 다시 말해, 널리 써라. 그리고 불편한 부분을 그냥 지나치지 말고 지속적으로 개선하라. 번거로운 부분은 과감하게 제거하거나 단순하게 하고, 모호한 부분은 분명하게 해둬라. 이 글의 이후 분량은 두 줄 남짓 정리한 비법을 실천할 수 있도록 경험을 담은 부연이다.
첫 단추는 개발 케이스 만들기
필자가 가장 익숙한 RUP에는 세 개의 케이스(Case)가 있다. 비즈니스 케이스(Business Case), 유스케이스(Use Case) 그리고 개발 케이스(Development Case)다. 비즈니스 케이스는 사업 수행을 다루고, 유스케이스는 시스템 사용 시나리오를 다루지만 모두 “어떻게 하겠다”는 내용을 정형화한다. 개발 케이스도 마찬가지로 어떻게 개발하겠다는 시나리오를 정의한다. 개발에 관한 모든 사항을 처음부터 모두 세세하게 정의하기는 힘들다. 기존에 정의한 방법론 내용이 있다면 큰 노력이 들지 않는 부분만 초기에 수정하고, 문제에 봉착했을 때 해당 부분을 수정한다. 개발 케이스를 어떤 형식으로 얼마나 상세하게 하느냐는 프로젝트마다 달리해야 한다. 하지만 개발 케이스를 집약해서 모두에게 누가 무슨 일을 하는지 알려야 한다. 그래야만 역할이 분명해지고, 필요한 사람을 찾을 수 있다. <그림1>에서 빈칸에 담당자를 명기하면 각 단계별로 산출물 작업 기준이 드러나고, 특정 업무에 따라 산출물 작성자를 한 눈에 볼 수 있다. 이러한 표를 만들어 공유하면 모호했던 역할과 서로 다르게 생각하고 있는 부분이 드러난다. 자연스레 이어지는 협의 과정에서 점차 역할과 책임이 명확해진다. 한 가지 팁이라면 프로젝트 규모가 커서 여러 장의 표를 작성해야 할 정도라면, 프로젝트 관리자는 대표자를 명기한 표만 활용하고, 상세 내용은 각 업무 단위로 관리를 위임한다.
예전에 어떤 개발자가 R&R이란 표현이 폼나게 여겨졌는지, 문맥에 관계없이 R&R이란 표현을 남발했다. 옆에서 보면서 드는 생각이 R&R이 폼나는 표현이 아니란 사실을 알기 전까지는 그 의미를 전혀 모르겠구나 싶었다. 그리고 어떤 관리자는 틈만 나면 R&R 따지지 말고 서로 도와가며 일하라고 말했다. 우습게도 그 말에 반박했던 필자 역시 얼마 후 다른 이에게 비슷한 말을 했다. 올해로 8년째 방법론과 직간접적으로 인연을 맺어왔다. 누군가에겐 우습게 들릴 수 있지만, 방법론에 대한 애증이 쌓였다. 요즘 누가 필자에게 방법론이 무어냐고 물으면, ‘방법론은 R&R이다.’라고 말해주고 싶다. R&R은 ‘Role and Responsibility’의 약자다. 우리말로 역할과 책임이다. 역할과 책임을 규정하지 않고 일하는 조직이 어디 있을까? 하지만, 방법론이 효과를 발휘하려면 R&R이 더 명확해야 한다. 마치 오랫동안 잘 돌아가는 프로그램을 만들려면, 함수 시그니처가 명확해야 하고, 컴포넌트 인터페이스 규약이 명확해야 하고, 계층(layer)간 주고받는 항목과 제약사항이 명확해야 하는 것과 같은 이치다. 산출물(deliverable)이라는 명확한 ‘부가가치’의 연쇄구조(chain)를 통해 최종 제품을 만든다. 마치 컨베이어 벨트처럼 방법론을 기계화 수준의 시스템으로 만들면 효율성은 극대화한다. 하지만 아쉽게도 아직 소프트웨어 개발에 있어서는 제조업의 노하우를 그대로 쓸 수는 없다. 개념적으로는 이미 오래 전에 소프트웨어 공장을 논했다. 하지만 산업 경계를 넘어가면 재해석을 해서 새로운 행동 계획(action plan)이 필요하다. 물리적으로는 하나의 산출물이라도 여기에 부여한 부가가치의 생산자는 다르다. 이를 명확하게 해야 효과를 내는 R&R 정립이다. 소프트웨어 설계를 고민하면서 동시에 혹은 번갈아 방법론을 고민하다 보면 무척 닮았음을 알 수 있다. R&R 정립이 가져오는 팀 협업 구도는 loosely-coupled로 불리는 시스템 연동 방식과 원리가 같다.
모호한 부분 구석구석 밝혀내기
규모를 막론하고 개발 프로젝트 초기에는 단계별 산출물을 기준으로 책임자를 명기해두고 합의를 이끄는 과정을 반드시 수행해야 한다. <그림1>의 표는 만들고 나면 매우 명확하지만, 앉은 자리에서 그냥 작성할 수 있는 내용이 아니다. 필자는 주로 외주 계약 기반인 SI 프로젝트에 컨설턴트로 참여하는데, 복잡한 하도급 계약을 고려하면 어떤 역할을 수행하는지 세부 사항은 매번 새로 정의해야한다. 대부분 기존에 해오던 방식을 선호하는 경향이 있어 필연적으로 갈등이 빚어지고, 노련한 개발자가 많으면 서로 자신에게 유리하게 협상하려 해서 설득과 조정 과정이 필요하다. 한편, 여러 업무나 여러 단위 시스템으로 구성된 프로젝트의 경우 역할이 상충하게 마련이다. 주고 받는 데이터가 발생하면 누가 전송을 책임지느냐 여부가 관건이다. 함께 쓰는 기능이 있다면 공통 기능 개발 주체가 초미의 관심사다. 항상 분명한 사실은 오래 끌어봐야 갈등만 커진다는 점이다. 가능한 빨리 문제를 이슈화해서 초반에 정리해야 한다.
내포된 위험을 전혀 혹은 거의 모르고 있는 프로젝트 시작 초기에 노련한 프로젝트 관리자라면 마치 상처의 고름을 짜내듯 문제를 미연에 파헤치는 시도가 필요하다. RUP를 보면 프로젝트 관리자는 위험요소 목록(Risk List)을 도입단계(Inception Phase)부터 생성하고 관리한다. 보다 구체적으로는 비전문(Vision)으로부터 바로 위험을 식별하고 확인하라고 한다. 즉, 사업 계획서(Business Case) 작성 과정에서 이미 만들어져야 하는 것이다. 어찌 보면 당연한 이야기다. 프로젝트를 실패로 끌고 갈 수 있는 위험을 조기에 파악해 위험 관리 계획(Risk Management Plan)을 세우라는 것은 문자 그대로 너무나 당연한 말이다. 그러나 문제는 생각처럼 쉽게 그 모습을 드러내지 않는다. 명확해 보이는 문제는 누구나 이를 알고 있기 때문에 설사 프로젝트에 미치는 영향력이 지대하다고 하더라도 덜 위험하다. 오히려 진짜 큰 위험요소들은 쉽게 눈에 띄지 않는 것들이다. 삼국지류의 책에서 대패하는 경우는 뜻하지 않던 습격에 당하는 경우가 많다. 너무나 당연하게 수행되리라고 믿었던 일들이 되지 않을 때, 이를 고칠 수 있을 시점이 훨씬 지나서 문제를 알게 된다면 경우에 따라서는 그간의 산출물이 모두 쓸모 없어진다.
예를 들어 요구사항의 원천인 고객과 분석가가 서로 다르게 인식하고 있다고 해보자. 또한, 고객 입장에서 아직 결정되지 않은 요소가 너무 많아서 분석가에게 충분한 흐름을 제시할 수 없다. 언제 결정될지 모르는 사항을 무작정 기다리는 대신에 분석가가 나름의 시나리오를 기술해 고객에게 의견을 제시했다. 이때, 고객이 요구사항 기술 방식이 생소해 가령, 기본 흐름과 대안 흐름으로 시나리오를 기술하는 유스케이스 명세가 익숙지 않아서 내용 파악을 어려워한다거나 검토를 꺼린다. 고객은 요구사항 정의 내역을 검토해야 하는 것을 알지만 위와 같은 문제로 검토를 차일피일 미루고 또한 본연의 업무가 있기 때문에 요구사항에 대한 검증이 이뤄지지 않은 채 시간은 계속 흘러간다. 이보다 더 심한 문제는 고객이 마치 검토를 충분히 한 것처럼 인지될 때이다. 사실 이런 문제는 모든 프로젝트가 갖고 있는 가장 큰 위험요소 중에 하나이다. 다만, 이렇게 명백해 보이는 문제마저 실제 프로젝트에서는 다양한 양상으로 벌어지기 때문에 이를 잡아내서 의사소통 경로나 방식의 문제를 해결하기 쉽지는 않다. 적어도 필자가 경험한 모든 프로젝트에서 가장 큰 문제는 의사소통 경로나 방식에서 나왔다. 프로젝트 초기에 의사소통을 원활히 할 수 있는 환경을 만들어내는 일은 무척 중요하다. 그렇게 하기 위해서 프로젝트에 영향력이 큰 인물을 찾아내고 그 힘을 적절히 활용하라. 주요 실무자를 확실한 우군(?)으로 만드는 일과 정보가 물 흐르듯 소통할 수 있게 하는 일은 너무나 중요하다. 예전에 PM만 8년 하셨다는 분이 프로젝트 관리는 한 마디로 ‘정치’라고 단언했던 말이 떠오른다.
실행 능력 키우기
단조로움을 피하기 위해 잠시 다른 이야기를 해보겠다. 한일월드컵 4강 신화를 이뤄낸 거스 히딩크 등장 이전에 국가대표는 4(four)백을 잘 쓰지 않았다. 4백이란 수비수 네 명이 일렬로 서서 수비 라인을 구축하는 전형을 말한다. 4백 대신 중앙 수비수 세 명을 두는 3(three)백 시스템을 썼다. 당시 선진 축구 흐름은 전원공격과 전원수비를 함께 하는 이른바 ‘토탈사커’였다. 토탈사커를 구사할 때 4백을 구성하는 측면 수비수 2명은 특히 중요한 역할을 했다. 기본적인 위치는 좌우 측면 수비이지만, 공격할 때는 공을 갖고 상대편 깊숙이 침투해 크로스를 올리는 역할을 맡았다. 따라서, 공수 양면에서 탁월한 능력과 함께 기동력, 그리고 강한 체력을 요구했다. 동시에 중앙 수비수는 역습 상황에서 둘이서 최후방을 책임져야 하기 때문에 강력한 대인 마크 능력을 요구했다. 당시 우리나라는 홍명보와 짝을 이룰 중앙 수비수 재목이 약했고, 측면 침투와 수비를 책임질 측면 수비수 재목이 없었다. 히딩크는 어떻게 4백을 도입할 수 있었을까? 히딩크 역시 처음부터 4백을 고집하지 않았다. 월드컵 본선 직전까지 3백과 4백을 함께 사용하다가 끝내 본선에서 주요 경기에 4백을 사용했다. 이를 가능하게 한 힘은 극한에 이르는 체력훈련이다. 히딩크가 수행한 체력훈련을 빼고 4백(4-3-3) 도입을 논하는 일은 무의미하다.
필자가 히딩크의 접근방식을 꺼내놓은 이유는 방법론 적용에 대해서도 마찬가지의 노력이 필요하기 때문이다.
실행 능력을 키우는 코치
지난 해 바쁜 시간을 쪼개서 ‘소트웍스 앤솔러지: 소프트웨어 기술과 혁신에 관한 에세이’ 번역에 참여했다. 번역 작업은 처음이었지만, 7장 ‘반복 관리자’ 내용이 무척 실무적인 터라 번역 요청에 응했다. 때마침 프로젝트 관리를 하고 있었고, 소수의 팀원에 비해 개발 물량이 무척 많아 애자일 방법론을 채택한 상황이기도 했다. 책 내용 일부를 소개하면, 반복 관리자가 팀이 일정을 지키게 하기 위해 다음과 같은 질문을 하라고 한다.
- 개발자가 자신이 맡은 스토리 범위를 이해하고 있는가?
- 애초 예측 이후 스토리 작업에 변경이 있었는가? 그렇다면, 어떻게 변했는가?
- 개발자가 해당 스토리가 목표로 하는 상태에 대해 더 잘 이해하기 위해 업무 분석가나 고객 도움이 필요한가?
- 개발자에게 선임 개발자 도움이 필요한가?
- 개발자의 스토리 완수에 장애가 있는가? 가령 하드웨어, 소프트웨어 또는 기반구조 문제가 있는가?
- 개발자가 다른 프로젝트에도 참여하고 있거나 스토리 완수를 위해 지나치게 많은 잡다한 회의까지 참석하고 있지 않는가?
필자는 번역을 수행할 당시, 스스로 뽑은 최고의 팀원으로 프로젝트 관리를 수행하고 있었다. 하지만, 기대만큼 좋은 결과를 내지 못했다. 얼마간의 시행착오를 겪은 이후에 필자는 팀원의 작업 내용에 직접 개입하기보다는 위 질문과 같은 내용으로 도움을 주려고 노력했다. 스스로 해결할 수 없는 문제는 빨리 도움을 요청하도록 유도했고, 회의는 주로 관리자인 내가 전담하면서 검토를 수행할 경우에 한해서 개발 담당자를 참여시켰다. 또 가장 중요한 점은 스스로 자신의 작업 계획을 수립하게 한 것이다. 약 4개월 동안은 주마다 계획을 하고, 매일 아침 진척을 보고하게 했다. 주단위로 보면 늘 조금은 지연(기능을 완료한 경우에도 주석이나 도움말이 빠졌거나 단위 테스트가 없었다)이 있었고, 매일 아침 물어봐야 며칠 동안 같은 작업을 진행 중이라고 답했다. 속으로 답답했지만, 인내심을 가지고 기다렸다. 매번 반복해서 가능한 일을 잘게 나누어 보고하라고만 요청했다. 놀랍게도 4개월 이후부터는 하루 단위 작업 추정이 가능했다. 주 단위로는 거의 모든 팀원이 자신의 말을 지켰다. 처음에는 상상도 못할 작업 측정과 관리가 가능했다.
거스 히딩크가 했던 일도 이와 비슷한 일종의 코치가 아니었을까? 반복 관리자는 애자일 코치(agile coach)라고 부르기도 한다. 갑자기 방법론 이야기하다 말고 왜 애자일 코치 이야기를 꺼냈을까? 앞서 이야기했지만, 기초체력훈련 없이 4백은 불가능하다. 최소한의 체력이나 개인기가 없는데 마법 같은 부분전술이나 훌륭한 전략을 소화할 수는 없다. 마찬가지로 효과적인 방법론 적용을 위해 팀원의 기본 역량 강화는 필수다(아쉽게도 프로젝트 동안만 만나는 팀원이라면 ROI는 장담할 수 없겠다).
팀워크 빌딩
축구팀이나 개발팀이나 팀워크는 중요하다. 축구는 11명이 하지만, 개발팀 구성원 숫자는 이보다 많을 수 있다. 특히, 방법론을 도입하는 프로젝트는 수 십, 수 백명인 경우가 많다. 숫자가 늘면 팀워크를 갖추기는 더욱 어렵다. 더구나 서로 다른 회사에 속한 팀원을 모아놓았을 때 이들을 진정한 팀으로 만드는 일은 과연 가능할까 싶을 정도로 힘들다. 대규모 프로젝트에서는 팀워크를 위해 워크샵을 가기도 하고 몇 차례 회식을 한다. 얼마나 효과가 있을지는 의문이다. 함께 일하는 빈도가 높은 팀원 사이에서라면 필자가 했던 다음과 같은 시도를 한번쯤 권해보고 싶다. 필자는 함께 일하는 팀원을 불러다 놓고 자신과 관계된 담당자와 산출물을 표기한 후 관계를 그려보라고 했다. 훈련된 팀이어서 산출물을 빠뜨리는 경우는 없었지만, 다른 사람과의 관계는 팀원 대부분이 빠뜨리고 그렸다. 놀라운 점은 서로가 그린 그림을 공유하는 정도만으로도 팀워크 개선이 있었다는 점이다. 보지 못하던 부분이 드러난 이후에는 굳이 계속해서 지적하지 않아도 새로 인지한 부분을 고려해서 작업했다.
획일화의 함정에 빠지지 말라
지금까지는 사람에 초점을 맞췄는데 세부적으로 들어가면 방법론은 각종 산출물 작성법을 포함한다. 종종 방법론과 표준 양식을 대등하게 생각하는 사람도 있다. 올바른 판단은 아니지만, 그만큼 표준 양식은 모두가 명확히 인지하고 필요로 한다. 문서 작성 방식이 명확하다면 작성도 편하지만, 읽기에도 좋다. 그러나, 프로젝트가 커지면 지나치게 관리 편의성을 내세우기도 한다. 지나치게 일관성을 강조하면 획일화의 함정에 빠질 수 있다. 대규모 프로젝트에서 프로그램 식별자(ID)는 여러 가지 용도로 쓰인다. 사업 관리 측면에서 진척 관리 기준으로 쓰이기도 하고, 설계자, 개발자 및 테스트 담당자가 작업 항목을 식별하고 서로 추적할 용도로 쓰기도 한다. 수많은 프로그램 가운데서 일관성을 부여하기 위해 대개는 다양한 약어와 일련번호를 조합한 이름을 지정한다. 그러나, 프로그램 내부의 변수에까지 모두 동일한 체계를 부여해 프로그램을 암호처럼 만드는 경우를 종종 목격할 수 있다. 산출물 특성을 무시하고 모두 똑같이 처리하려고 시도한 탓이다. 엑셀 문서에서 특정 프로그램을 지칭하기 위해 ‘IF-CMD-001’과 같은 식별자를 쓰는 일은 긴 이름에 비해 효율적일 수 있다. 하지만 프로그램 이름을 ‘IF-CMD-001.java’ 혹은 ‘IF-CMD-001.jsp’ 라고 만드는 일은 과연 적절할까(물론, 암호와 같은 작명 체계를 고객의 기존 시스템에서 오랫동안 사용했다면, 이미 의미 있는 관행이기 때문에 준수해야 할 수도 있다)? 비슷한 획일화 함정의 예로 ‘유스케이스 크기 기준’을 들 수 있다.
유스케이스 크기에 대한 이슈(http://cavin.egloos.com/4869054)는 억지로 유스케이스를 콘트롤(control)이나 설계요소와 일정규칙으로 연관 지으려는 경향에서 발생한다. 이는 유스케이스를 소프트웨어 설계원리로 오인하면서 발생하는 대표적인 오해이다. 유스케이스 모델링 책에서 동일한 크기를 강조한 데에서 비롯된 잘못된 양상이라 할 수 있다. 실제로 일정한 크기를 갖고 한 사람이 모델링하는 것을 베스트로 추천하곤 한다. 유스케이스는 전달자와 수집자간에 요구사항에 대한 본인들의 관심사를 담아 다른 사람과 소통하기 위한 ‘스케치’다. 비즈니스 특성이 다르고 각각의 관심사가 다르기 때문에 일정 크기로 수렴하는 것은 전혀 의미가 없다. 일정한 크기로 강제하다 보니 유스케이스가 1,000개 단위로 나오는 어이없는 사태가 발생하기도 한다. 요구사항이 조밀한 수준에서 높은 가치를 갖는 비즈니스가 있고 반대로 큰 수준에서 가치를 갖는 비즈니스도 있다. 전자와 같은 비즈니스에 대해 유스케이스 크기 기준을 들이미는 것은 입도가 조밀한 수준의 관심사를 더 큰 크기로 나타내고 소통하라는 얘기가 된다. 원자에 대한 커뮤니케이션이 필요한데 분자크기로 요건을 작성하라는 얘기이다. 말도 안 된다. 비즈니스 특성도, 개개인의 관심사도 다르니 크기에 대한 ‘정답’도 없는 것이 당연하다. <중략> 유스케이스는 커뮤니케이션 도구다. 고객과 협업하는 사람들, 그리고 자신을 포함한 모두의 커뮤니케이션이 가장 큰 목적이다.
프로세스 최적화와 도구의 적용
산출물 형식뿐 아니라 용도와 상황에 부합하게 산출물 작성 프로세스를 최적화한다. 산출물 작성 프로세스의 경우에도 <그림 4와> 같이 시각화해 공유해야 한다. 누가 무엇을 하고, 이어지는 작업은 무엇인지, 관련자나 관련 시스템은 무엇인지 명확하게 해서 혼선을 없애야 한다.
프로세스가 복잡해지면, 단순화를 위해 시스템 도입을 고려해야 한다. 최근에 다양한 협업 도구가 오픈소스로 개발하고 쓰여지고 있다. 필자가 수행하는 최근 프로젝트에서는 사용하는 형상관리 도구(Subversion, Subversive), 작업관리 도구(Redmine, Eclipse Mylyn), 결함관리 도구(Redmine), 빌드 및 테스트 자동화 도구(Ant, Hudson) 등은 모두 무료로 사용할 수 있는 오픈소스 도구이다.
의사소통을 문서로만 관리할 때보다 도구를 도입하면 효율적이지만, 소수 관리자의 관리 편의성이나 도구에 대한 거부감으로 문서를 고집하는 경우도 있다. 명심하라. 개발 프로젝트에서 최종 산출물은 소스 코드다. 그 이전에 만들어지는 수많은 문서는 결국 중간 결과를 담는 그릇이다. 의사결정 사항을 알려 오류를 찾아내고, 누락시킨 요구사항을 다시 수렴하고, 다음 단계로 진화하고, 필요하다면 변경을 수행하기 위한 정보 전달에 사용한다. 목적에 부합하는 수단과 방법을 쓰고 있는지 항상 고민해야 한다.
생생하게 유지하기
얼마 전 모회사에서 꽤 잘 만든 조직 표준 체계를 열람했다. 2년 전에 만든 것인데, 내용이 그대로였다. 만들기는 잘했지만, 널리 쓰이지는 않았구나 짐작했다. 널리 쓰이지 않는다면, 그리고 상황에 맞게 옷을 갈아입지 않는다면 가치가 있을까? 방법론 무용론도 같은 맥락이 아닐까? 아무리 욕을 해도 마구잡이 개발보다 나쁜 방법론은 없다. 방법론이 쓸모가 없다고 생각한다면 자신이 제대로 활용하고 있는가 돌아보자.
'마이크로소프트웨어' 카테고리의 다른 글
| 소프트웨어 개발 방법론의 함정 (0) | 2009.11.27 |
|---|---|
| InsideMASO(3) | 간식의 유혹 (1) | 2009.11.23 |
| 나는 대한민국 개발자다-1 | 4년차 개발자의 고민 (3) | 2009.11.19 |
| 윈도우7 세미나 후기 당첨자 안내 (2) | 2009.11.17 |
| Inside MASO(2) | 마감은 괴로워 (1) | 2009.11.16 |
