여기까지 다시 말해 2004년까지 나의 프로젝트 수행방법은 언제나 "요구사항 분석, 설계(?), 구현, 테스트"였다.
요구사항을 받거나 혹은 고객에게 요구사항을 그리라고 하고나서 그것을 검토하고 담당자를 배치하고 담당자에게 물어본다.
"언제면 끝나겠니?"
담당자는 나이 어린 PL을 바라보면 "3주~4주 걸린거 같은데요~"라고 하면 "안돼. 오픈일이 언제고 테스트 기간이 얼마 잡혀 있으니까 요때까지 끝내야돼"라고 이야기 했다.

즉, 모든 계획의 개발 일정=오픈일-테스트일정-Plus Alpha였다.
오픈일은 어차피 정해져 있는것이고 오픈일을 어기면 다 뒤졌으~ 이런 마인드였던 것이다.
20대 후반 30대 초반의 개발 3~4년 하다가 갑작이 리딩을 맡게된 PL이 할줄 아는게 이게 다였다.
그리고 개발자가 원하는 개발 기간을 빼고나면 설계 소요 기간이 되고 설계소요 기간을 빼고나면 오늘로 부터 설계착수일까지가 바로 요구사항분석 기간이 되는 것이다.

따라서, 고객에게 이렇게 이야기한다.
"님~! 이거 언제까지 그려주세요" 혹은 "님이 원하는게 뭐죠?"

당시 알고있는 설계지식이라봤자 고작 "Flow chart"와 "ERD", "UI 설계"가 전부인줄 알던 풋내기 PL은 그렇게 일을 했었다.

그런데 여기서 부터 문제가 발생한다.

지금까지 겪었던 수많은 고객들은 스스로 무엇을 원하는 지, 무엇을 하고싶어 하는지 몰랐다.
이것은 지난 10여년동안 변한적이 없던 진실이다.

예를 들면 이런식이다.
글뻥 : "음.. 과장님께서 하시는 일이 뭐죠?"
과장 : "제가하는 일이 뭐 있나요... 그냥 이것저것 하지요"
글뻥 : "그래도 프로젝트 개발하러 왔는데 뭐가 필요하신지 말씀을 해주셔야..."
과장 : "그건 그쪽 사정이지요. 그냥 저는 이대로가 좋은데... 전산팀에서 뭐라하나요?"
글뻥 : "전산쪽에서 발주내서 어쩌구 저쩌구 그래서 저희가 왔는데... 그럼 지금까지 불편하셨던거는 없으셨나요?"
과장 : "뭐 불편한게 한두갠가요? 이런것도 불편하고 저런것도 불편하고..."
글뻥 : (마구마구 적는다..) "아~ 그럼 이런것을 고치면 되겠네요."

이렇게 받은게 나의 요구사항들 이었다.
이정도는 양반이다.
어떤 고객은 "그냥 엑셀처럼 만들어 주세요!"라던가 "아 XX 바빠 죽겠는데... 담에 와요~"라던가...
그렇다고 해서 업무 매뉴얼이 있는가?
업무 매뉴얼이라도 보면서 관계도를 그려보면 금방이라도 알 수 있을 업무 관계를 전적으로 탐정이 된 것처럼 탐문 수사(?)를 해야 하니 어찌 제대로 된 요구사항이 나오겠는가?

이런상황에서 2004년 11월 프로젝트 종료후에 서산으로 옮겨 가게된다.
대학교라는 곳이 병원, 종교기관, 학원과 함께 SI회사의 무덤이라불리는 그곳으로 끌려가서는 처음 들은 이야기는 이것이었다.
"SKC&C는 가만히 H/W나 납품하시오. 나머지는 저기 당신들 협력사랑 같이 하겠소."
그래서 진짜 H/W나(?) 납품하고 설치하고 운영하는 일을 맡았다.
HP RX 8640 장비라는 대형 클러스터링 서버를 MSCS 설치하여 Database Active-Standby 로 운영하는게 내 업무였다. 분명 프로젝트 관리를 위해 내려간 현장 책임자였지만 당시 내일은 이런 것이었다.

종합대학교의 학사행정 시스템이 그리 간단한 것이 절대 아니다. 1만명이나 되는 학생들이 수강신청을 할때는 상상을 초월하는 트래픽이 발생하는 시스템이며 사소한 전산 오류 하나가 학생의 미래를 바꾸기도 한다.
거기다 시시탐탐 성적표를 노리는 해커들이 있는 곳이 바로 학교 전산 시스템이다.
그야 말로 사회의 모든 시스템을 모아놓은 곳이 바로 학교이다.
이런 시스템을 몇개월간 수천장에 달하는 인터뷰 목록이 만들어 졌고 협력사 직원들이 매달려 수개월간 CRUD라고 하는 챠트를 그려 나갔다.
CRUD를 그리는 수개월이 지나자 한학기가 끝났고 그 CRUD를 다시 Entity와 Relation으로 표현하는데 다시 수개월이 흘렀다. 분석이 끝난 시스템부터 개발되기 시작했으며 그 과정을 일정 계획표하나 가지고 TASK하나가 끝날때 마다 하나씩 지워가며 "진척도가 몇 %입니다"라고 보고서에 올렸다.

그러다가 이슈가 업무관계가 안맞는 이슈가 터지기 시작하고 이슈가 무려 200여개나 되는 미친 시스템이 되어 가고 있었다.

즉, 학사과에서 어떤 일을 하면 그것이 각 학과로 연결되고 학과에서 업무는 다시 학생과, 행정처, 학생 예비군, 학적과, 수납과, 회계팀 등으로 퍼져나간다. 그런데 각과의 업무중 하나라도 문제가 발생하면 모든 업무는 스톱이 되는 것이다.
그런데 이런 밀접한 관계를 가진 시스템을 고작 20명이 들어가서 6개월이 넘도록 인터뷰만으로 요구사항을 도출했다는 것이 가당키나 한 것일까? 그것도 고작 개발 경력이 길어봐야 5~6년 많이 길면 10년 넘으신 분들 1, 2명으로 비전문 분석가가 수천장에 달하는 문서를 만들고 그것을 정리해서 설계한다는 것이 가능한 일일까?

결국 프로젝트는 망했다.

요구사항을 제대로 구현하기는 커녕 잦은 요구 변경과 고객의 원성에 형상관리조차 하지 못하는 상황에서 그제서야 "C&C가 책임져!"라는 고객의 요구는 어찌보면 황당하기 그지 없는 일이기도 했지만 그제서야 문제를 잡아가기 시작했다.

제일 먼저 한일이 형상관리 부터 때려 잡는 일이었다. 그래서 생각해낸 것이 보험사 SM요원이었을 때 도입된 "하베스트"라는 형상관리 툴을 기억해냈고 오픈소스로 뒤져보니 CVS와 비슷하지만 사용하기 쉬운 "SVN"이 눈에 띈다. 부랴 부랴 개발 시스템에 "SVN"을 설치하고 형상관리를 하기 시작했다.
프로젝트가 1년하고 2개월정도 진척되고 있을 무렵 늦었지만 형상관리가 들어가자 버그가 눈에 띄게 줄어든다.
그렇지만 몇개월간의 강행군으로 개발자 하나 둘씩 나가 떨어지고 고객은 고객대로 불만만 쌓여 결국 그해 여름 전면 감사라는 표현으로 감리를 수검하게 된다.
본사에 올라와서 몇개월에 걸친 방대한 문서를 감리 수검을 위해 재정리하고 본사의 감리 전문가들도 손을 들고 말았다. 결국 그들이 선택한것은 현장 책임자인 나와의 인터뷰였고 결론은 "감리 부적합"이었다. 보완사항을 지적받고 다시 재정리한 끝에 감리수검용 문서만 바인더로 4~5m 정도 쌓아 놓고 감리를 수검하였다.
10일간의 수검기간동안 감리인들은 그 방대한 문서를 다 보지도 못했고 그들이 남긴 한마디는 "그래서 프로젝트 잘된다고 생각하시오?"였다.
아무튼 관리 측면에서만 "부적합"이었고 나머지는 "적정" 또는 "보통" 판정으로 고객의 중도금 미지급 문제와 공문과 내용증명에 대한 미응답을 사유로 고객 책임이 되고 말았다.
대신 감리 지적사항에 대해서는 시정 명령을 받아 이수하였고 그것으로 그 프로젝트는 종료되었다.

햇수로 3년 만으로 2년의 전쟁이 남긴것은 나에게 몇 가지 질문을 주었다.

첫째, "요구사항 도출 방법은 적정한가? 더 확실한 방법이 없을까?"
둘째, "현재 설계 방식이 적정한가? 더 빠르게 설계할 방법이 없을까?"
셋째, "SVN은 합리적 선택이었을까?"
넷째, "TASK의 완료가 실재적인 완료일까?"
다섯째, "테스트를 자동화 할 수 있을까?"

첫번째에 대한 질문은 이전 프로젝트에서 우리가 고민했던 그 문제 바로 Mockup툴의 필요성으로 귀결되었다.
고객이 스스로 만든 어플을 돌려 보면서 빠르게 고쳐 나가면 요구사항은 확실하게 Fix될 것이라는 생각이다.
두번째에 대한 질문은 ERD와 UI설계, Work Flow의 과감한 통합 내지 포기였다.
그래서 선택한것이 바로 UML이었다.
셋째는 SVN만한것이 없었다.
넷째는 TASK의 완료는 완료일뿐 실재적인 고객이 원하는 어플을 만들지 못한다는 결론에 이르렀고 TASK가 중요한것이 아니라 최종 산출물이 중요하다는 것을 깨달았다.
다섯째는 그 당시 JUNIT과 xUNIT을 보면서 자동 유닛 테스트 만이 해답이라는 생각을 했다.

2006년 12월 프로젝트가 종료되고 복귀한후 마침 팀으로 이동해온 모 과장님을 붙잡고 공공에서 경험하셨던 UML을 하나씩 하나씩 알려달라고 조르고 물어보면서 하나 하나씩 배워나갔다.
그리고 사내 UML강의도 들으면서 UML에 대해서 하나씩 하나씩 내것으로 흡수하기 시작했다.

그런데 이게 웃기다.
배움을 얻으려 했던 거의 모든 전문가가 USE CASE Diagram을 그리고 바로 Class Diagram을 그리고 이것을 다시 Sequence Diagram으로 전개하는 것이 아닌가?
그렇다면 Class Diagram은 전혀 근거없이 상상의 나래를 펴서 만드는 것 아닌가?
즉, CRUD없는 ERD였던 것이다.

몇권의 책을 사서 보기 시작했다. 과연 이게 맞는 것인지.
그리고 해답을 찾았다. Workflow Diagram인 Activity Diagram이 바로 그것이다.
이제 하나씩 연결고리가 보이기 시작했다.

1개의 USE CASE는 1개의 Activity Diagram을 가진다.
1개의 Activity Diagram은 n개의 Action과 Entity를 포함한다.
즉, Activity Diagram으로 도출된 Action이 바로 Method 였던 것이고 그 Action 을 작동하기위해 들어가는 인자값인 Entity가 Entity 였던 것이다.
다시말해 Method를 따로 모아두면 Controller Class가 되고 Entity만 모아 두면 Entity Class가 된다.
이게 바로 Class Diagram의 정체였던 것이다.
또한 그 Class Diagram의 연관관계가 Sequence Diagram이다.

즉, 적정한 UML은 요구사항 분석과 함께 설계 및 설계를 통해 예측되는 작동까지 알수 있는 툴이 되는 것이었다.
그러나 여전히 UI 설계와 사용자 체험에 대한 갈증은 풀수 없었다.

그리고 한참뒤 쉬고 있는 동안 T의 Store 컨설팅 프로젝트에서 아키텍쳐의 역할을 맡으면서 지금까지 고민해왔던 그동안 딱아 왔던 나만의 무기를 꺼내 들고 유수의 컨설던트들과 협업하기 시작했다.
수많은 업무범위를 적정하게 쪼게야 하는데 어떤 데이터 기준으로 쪼게는지가 문제였고 내가 사용한 방법은 바로 포스트 잇이었다.
파워포인트로 한장씩 그려서 혹은 화이트 보드에 그려서 커뮤니케이션하는데는 많은 시간과 가시성이 떨어지는 문제가 생겼고 파견된 1주동안 나는 사업팀의 대표로 그 문제를 풀어야만 했던 것이다.
결국 마지막날 하루전에 아키텍쳐들과 컨설던트, 그리고 다른 참여자들이 모두 모인 그 자리에서 포스트 잇을 꺼내서 발생할 수 있는 데이터의 종류를 모두 가리지 말고 불러 보라고 하였다.
"고객기본 정보", "배송정보", "환불정보" 등등등등 수많은 포스잇 위에 나오는 이름마다 하나씩 모두 포스잇에 적어 나갔다. 그리고는 비슷한 것끼리 모아서 붙여 나가자 하나의 거대한 나무가 만들어 진다.
이것으로 모든 업무 수행조직이 결정되었고 어떤 데이터를 어떻게 흘려야 하며 누가 컨트롤할지가 결정되었다.

이작업을 통해 느낀 바는 "가시성이다."
말과 글은 은유의 종합예술 일뿐이었다.
따라서, 사람들이 무엇인가를 보기전에는 결정하기 매우 어렵다는 사실을 다시 확인했고 그것을 꺼꾸로 이용한다면 쉽게 결정을 도출할 수 있다는 것도 배웠다.

이로써 나는 차기 SI프로젝트에서 사용할 무기들을 어느 정도 완성할 수 있었다.

심플한 요구사항을 결정하기 위한 포스트 잇의 새로운 사용처를 발견했고 요구분석도구인 UML USE CASE와 Activity Diagram을 자유자재로 사용할 수 있게 되었으며 이를 통해 설계할 수 있는 Class Diagram과 연관관계를 통해 실재 어플이 작동되는 것을 예측할 수 있는 Sequence Diagram을 보유하게 된것이다.

긴 문장보다 그림으로 표현되는 심플한 방식은 그 뒤의 T-Store (현재의 11번가) 하드웨어 설치 프로젝트 PM을 맡으면서 더 크게 적용되었다.

130여대의 서버와 네트워크 장비, 그리고 그 인프라를 1달안에 설치하는 프로젝트에서 S/W개발 툴들과 기법을 적용할 기회를 얻은 것이다.

=== 다음회 계속~ ===