Talk with Hani

팀장의 고백  목차

• 게으른 PL이 프로젝트 일정을 지연시킨다.
• 개발명세서? 그 귀찮은 짓을 왜 하지?
• 개발계획은 팀장의 것? 팀원의 것?
• 팀장! 당신은 진정한 Nego를 할 수 있는가?
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지 1부
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지 2부 (오늘의 Post)
• Trac을 통한 품질 관리 (오늘의 Post)
• UnitTest! 미완의 시도
• 인수테스트, 북치고 장구치고
• 진정한 프로젝트의 가치는 어디에서 오는 것일까?

변화는 삶의 본질

내용의 흐름 상 오늘은 형상 관리와 Trac의 이야기를 같이 풀어 보겠다. 우선 지난 post에서 변화의 어려움과 변화를 이끌어 내기 위해서 어떻게 해야하는지 간단한 각론 수준의 이야기를 했다. 사실 변화란 쉽지도 않고, 변화의 끝에 성공이 있으리라는 보장은 없다. 물론 성공의 보장이 있다 하더라도 변화라는 것은 실천하기가 어렵다. 그러나 어찌 보면 우리 인생의 본질은 변화가 아닐까한다.

위편삼절(韋編三絶)이라는 말은 공자님이 죽(竹)을 묶은 가죽끈이 세번 끊어질 정도로 주역을 읽으셨다는 의미의 사자성어다. 주역이 도대체 무엇이길래 공자님은 가죽끈이 세번 끊어질 정도 읽은걸까? 신영복님의 강의(돌베게 출판)에서는 “주역은 변화에 관한 사상이고 변화에 대한 법칙적 인신…”이라고 한다. 물론 주역에는 방대한 주제가 녹아 있지만 핵심적인 키워드 중에서도 중요한 위치를 차지하는 것은 변화다.(이와 관련된 이야기는 다른 post에서 이야기해 보겠다.) 

유교와 더불어 동양 사상의 한축인 불교의 핵심사상 중 하나는 연기(緣起)다. 도올 김용옥은 달라이라마와 도올의 만남(통나무 출판)에서 연기를 다음과 같이 평가하고 있다. “연기의 방식으로 사물을 볼 줄 알아야만 곧 깨달음에  도달케 된다.”… 그럼 도대체 연기라 무엇인가? 문자 그대로 풀어 보면, 원인(緣, 원인으로 한다.)과 결과(起, 생겨난다.)라는 뜻이다. 여기서 불교 철학에 대하 깊이 논할 수도 없고, 그럴 정도로 불교에 대한 지식이 많지 않다. 그러나 아는 범위에서 이야기하자면 풀 한포기에서 우주의 형통을 이해할 수 있고, 젊은 여자의 아름다움 속에서 해골의 쓸쓸함을 볼 수 있는 혜안을 가지라는 뜻이다. 결국 연기는 사물은 고정되어 있는 것이 아니고 끊임 없이 변화의 굴레 속에 움직인다는 것을 뜻한다. 물론 변화의 의미성은 불교와 유교에서 다르게 해석되지만, 불교도 인생의 본질을 변화(연기)로 인식한 것이다.

변화와 자유의지

결론적으로 내가 하고 싶은 이야기는 변화다. 물론 동양 철학씩이나 갖다 붙이면서 설명하지 않아도, 우리 인생의 본질은 ‘변화’라는 것은 본능적으로 알고 있다. 문제는 변화에 대한 우리의 자세다. 변화를 어둠을 몰고 오는 먹구름의 징조로 볼 것인지, 긴 겨울의 끝을 알리는 산뜻한 봄바람으로 받아들일지는 개인의 문제다. 미쉘 파이퍼가 주연으로 나오는 영화 위험한 아이들(dangerous mind)에서는 다음과 같은 일화가 나온다. 시를 가지고 토론하는 수업 중간에 자유의지에 대해서 이야기가 진행되었다. 화두는 “만일 갱이 너의 머리를 10초 후에 총으로 날려 버린다면, 너에게는 자유가 있는 것일까?” 였다.(기억에 의존하기 때문에 정확하지는 않지만, 이런 뉘앙스다.) 대체적인 의견은 그런 경우에는 자유가 없다였지만, 똑똑한 여학생이 말했다.

“나는 그 때에도 자유의지가 있다고 봐. 결과적으로 죽을 목숨이지만, 죽음 앞에서 당당할 것이냐? 비굴해질 것이냐?를 선택할 수 있기 때문에, 결국 자신의 자유 의지는 항상 존재하지..”

그렇다. 변화에 대한 자세는 당신 몫이다. 그렇다면 난 왜 이렇게, 변화의, 본질에, 대해서, 길게, 이야기, 하는, 것일까? 이유는 간단하다. 형상 관리와 품질 관리 툴은 프로젝트 규모를 떠나서 반드시 써야 한다는 것을 말하고 싶어서다. 폴더에서 데이터를 관리하는 방법은 cvs나 subversion같은 형상 관리툴로 대체해야 하고, 액셀로 관리되는 bug list는 trac같은 품질 관리툴로 바꾸어야 한다. 그러나 이런 변화는 삶에 작은 변화를 가져 오기 때문에 쉽지도 않고 필요성에 대해서 인식하지 못한다.(써보지 않았기 때문에 얼마나 좋은지 모르고, 그렇기 때문에 필요성을 인식 못한다.) 그러나… 변화는 필요하다.

subversion을 활용한 형상관리

subversion의 활용방법을 다룬 책도 많고, google에게 subversion이라고 물어 보면 수 많은 사이트가 나온다. 물론 subversion이라는 산에 내가 돌 하나를 더 올린다고 해서 태산이 에베레스트산이 되지는 않겠지만, 용기를 내서 이 글을 쓰는 이유는 아직까지 subversion을 사용해 보지 않았거나, 약간의 사용 경험이 있는 사람들과 내 경험을 공유함으로써 조금 더 나은 형상관리가 전파되는데 일조하고 싶은 내 욕심 때문이다. 따라서 앞으로의 내용은 이번 프로젝트에서 경험 위주로 기술하겠다.

형상 관리의 필요성

이번 프로젝트는 vc++ 6.0으로 개발했으며, 도움말은 매크로미디어의 RoboHelp로 작성했다. 우선 형상관리 문서의 범위를 정하는 것이 문제였다. 본좌가 몸 담고 있는 회사는 한 때 cmm 3레벨을 취득할려고 했으나, 여러가지 여건 상 cmm 레벨을 취득하지 않았다. 단지 ISO 9001에 기초한 개발 process를 가지고 있다. 개발 업무에서 발생하는 여러가지 산축물을(고객 요구 분석서, GUI설계서, 기능 명세서…) file 서버에서 최종본을 올리는 수준에서 관리하고 있다. 물론 프로젝트 산출물도 매우 중요하기 때문에 형상관리를 할 필요가 있으나, 기존 다른 프로젝트와 회사 정책을 바꾸어야 하는 문제가 있기 때문에 산출물은 기존의 방식대로 최종본만 file 서버에 올리기로 하였다. 하지만 program 소스와 각종 resource(program 관련 이미지 및 data), help 파일은 형상관리가 절실하게 필요했다. 프로젝트는 2차로 진행되었고 1차에 3개 모듈, 2차도 3개의 모듈을 개발하였다. 문제는 프로젝트 멤버(고객 담당자, pl, 팀원)들이 종종 바뀌기 때문에 1차 프로젝트에서 사용한 디렉토리 기반의 파일 관리로는 제대로된 프로젝트 관리를 할 수 없었다. 2차 프로젝트의 pl을 맡았을 때는 어떤 source가 최신본인지 알 수 없었다.(개발자마다 로컬에서 소스를 관리하다가, 서버로 올리기 때문에 팀원 pc의 소스가 최신본인지, 서버 소스가 최신본인지 알 수가 없었다.) 또한 개발은 지리적으로 떨어진 고객사, 회사, 협력업체에서 진행되었기 때문에 source및 도움말의 공유를 위해서 형상 관리툴의 도입이 절실하였다.

trunk, branch 그리고 export

1차 프로젝트 때 개발이 완료된 module에 AutoCAD와 2차원 Drawing 기능 추가가 요구가 있었다. 일반적으로 개발이 완료된 상태에서 programe에 신규 기능을 추가할 때는 trunk에서 branch를 생성해서 branch에서 작업을 한다. 그러나 기존 module에 AutoCAD 기능을 추가하는 것은 절반 이상을 신규로 개발해야 했다. 따라서 AutoCAD 작업은 trunk에서 하고 유지보수 부분은 branch로 진행하다 AutoCAD 기능을 release할 때 branch와 trunk를 merge하는 것이 정석적인 작업 방법이다. 해당 모듈에 대해서 이 방법을 사용하는 것이 최상이었으나, 문제는 AutoCAD 기능을 개발하는 협력 업체가 Firewall 밖에 위치하고 있었다. 물론 Firewall을 열면 문제는 해결이 되지만, 회사 정책 상 Mission imposible하였다.(MI4가 나와도 안된다…) 따라서 차선의 방법을 선택한 것으로 trunk의 소스를 export해서 협력업체는 subversion 밖에서 개발을 진행하였다. 유지 보수는 별도 branch로 빼서 작업을 하였다. 협력업체가 개발한 소스를 update하는 것이 문제였으나, 이것은 하루에 한번 개발된 소소를 협력 업체에 받아서 check-out한 로컬 trunk 소스에 copy & paste해서 commit하였다. 물론 신규로 add되는 파일은 별 문제가 없었으나, 협력업체에서 개발 중 삭제한 파일은 subversion에 삭제 작업이 반영이 안되었다. 있어야할 파일이 없는게 문제지, 없어야할 파일이 있는 것은 큰 문제가 아니었다. 삭제 작업은 귀찮지만 한달에 한번 수 작업으로 하였다.

temporary file은 별도로, library file은 같이

build 작업을 하거나, 도움말 output을 생성할 때는 임시 파일이 생긴다. vc++ 6.0이나 RoboHelp는 default로 이런 임시 파일을 project 폴더 아래에서 생성을 하기 때문에 아무 생각 없이 source를 import하거나 add하면 임시 파일까지 subversion에 올라가는 실수를 범한다. 따라서 source build나 help build 시에 사용되는 임시 파일은 반드시 subversion에서 관리되는 폴더 밖에 두도록 한다. 이에 반해서 library 파일같이 build 시에 꼭 필요한 파일은 subversion에서 관리하는 폴더 안에 두자. 이렇게 하면 신규 개발자가 오거나 개발 환경을 다시 구축할 때 subversion 파일만 로컬에 checkout하면 된다. vc++ 6.0 프로젝트 설정에서 디렉토리 경로는 반드시 상대 경로로 입력하자. 절대 경로로 입력하면 개발자 pc의 환경이 다르기 때문에 build 시 오류가 발생한다.

subversion과 통계

subversion에서 얻을 수 있는 이점은 version 관리 외에 개발 이력 정보를 얻을 수 있다는 것이다. tortoise svn을 사용하면 날짜별 revision현황과 사용자별 revision 횟수등의 간단한 통계를 알려 준다. 그러나 이런 정보는 실무에 큰 도움이 되지 않는다. 물론 subversion에서 직접 통계 정보를 주지는 않지만, subversion을 이용하면 실무에 도움이 될만한 통계 정보(이력 정보)를 뽑아낼 수 있다. 아래 그림은 협력업체에서 개발한 모듈의 KLOC(Kilo lines of code)의 추이를 나타낸 것이다. KLOC의 추이를 보면 모듈의 개발 상태를 알 수 있다. 개발 초기에는 개발 자체보다는 설계와 개발 작업을 병행하기 때문에 작업 효율이 높지 않다. 그러나 설계 불투명성이 제거된 후 개발 효율은 비약적으로 향상되는 것을 확인할 수 있다. 1월 이후로는 KLOC가 늘어나지 않는 것을 알 수 있다. 개발이 막바지로 접어들면 KLOC는 (더 이상 요청 사항이 추가되지 않는다면) 제자리 걸음을 한다. 재미있는 사항은 1월부터는 실제적인 사용성 테스트를 실시하면서 동시에 refactoring작업을 하였다. 따라서 세부적으로 추가되는 기능을 있었으나, 프로그램이 안정화되면서 refactoring에 의해 KLOC가 줄어들었다. 단순히 KLOC만을 예로 들었지만, subversion의 데이터를 개발 시 생성되는 다른 데이터와 합친다면, 다른 프로젝트에서 참조할만한 의미있는 정보를 얻을 수 있을 것이다.

협력업체 개발 모듈의 일자별 KLOC 변화 추이

Trac을 활용한 버그 관리

subversion만 도입해서 사용하는 것보다는 subversion의 활용도를 한 단계 더 높이기 위해서는 trac을 도입하는 것이 좋다. 일반적으로 버그 관리 툴을 사용하지 않을 때, 버그 관리를 위해서 excel을 이용하곤 한다. 물론 file 서버에 excel을 올려 두고 잘 공유해도 어느 정도의 버그 관리를 할 수는 있지만, 효율성 측면에서 본다면 on-line상에 두고 issue 트랙을 하는 것에 비해서 떨어진다. Trac의 일반적인 사용방법은 web 상에서 많은 자료를 구해 볼 수 있기 때문에 상세하게 설명하지 않겠다. 따라서 Trac 사용 방법보다는 Trac 적용 방법에 대해서 알아보자. Trac은 언제 사용하는게 좋을까? 물론 개발 초기부터 trac을 사용할 수도 있었지만, 개발에서 발생하는 이슈는 subversion의 로그를 이용하고 실제적인 버그 문제가 발생하는 closed beta 테스트부터 트랙을 사용하였다.

Trac과 subversion을 어떻게 사용하는 것이 좋은지를 알아보고 긴 글을 끝마칠까 한다.(글이 길어진다…졸립다. -..- 보통 끊고서 다음 post를 기약하지만 오늘은 끝까지 써보겠다.) Trac에서 버그 관리를 위해서 가장 기본적으로 하는 일은 티켓을 발행하는 것이다. 그럼 티켓 하나당 몇개의 버그를 기록하는 것이 좋을까? 경험 상 티켓 하나당 하나의 버그나 개선 사항을 적는게 좋다. 여러개의 버그가 한꺼번에 보고될 때 하나의 티켓에다 다 올리는 경우가 있다. 여러 개의 버그를 하나의 티켓으로 관리하면 각 버그를 개발자에게 할당할 수도 없으며, 개별적인 버그에 대해서 수정이 발생했을 때 어떤 식으로 버그가 처리되었는지 알기가 힘들다. 또한 subversion에서 언급할 것이지만, 버그 수정을 위한 revision 발생 시 해당 revision이 어떤 버그와 연결되어 있는지 찾아내기도 쉽지가 않다. 또한 차후에 버그 개수를 추정할 때 티켓수=버그수가 되기 위해서도 왠만하면(?) 티켓 하나에는 한 개의 버그만 할당하도록 하자.

티켓의 담당자가 지정된 경우, 수정 작업을 해야 한다. 개발 기간에는 일일 한번 정도 subversion을 commit하였다. 그러나 closed beta 테스트 때부터는 일일 commit과 더불어서 티켓 하나가 완료될 때마다(버그 하나가 수정될 때마다) commit하도록 권고하였다. 즉 버그와 수정 내역을 일치시키기 위함이었다. 물론 버그 수정 내용을 trac에 반영해도 되지만, subversion commit 시 로그 내용에 수정 내용과 더불어서 관련 티켓 번호를 적어 두면 버그와 수정 내용이 연결되기 때문에 차후 문제 발생 시 대처가 용이하다.

이상으로 간단하지만 subversion과 trac의 사용법을 설명하였다. 아래 링크는 trac 설치 시 정리한 자료이다. 혹시 window 버전의 trac 설치 시 어려움을 겪는 사람은 참고하도록 한다.(이런 형태의 자료는 없는거 같아서 공유한다.) 그럼 내 경험이 형상관리와 품질관리를 하려는 여러분에게 도움이 되었길 바라며 오늘 post를 마감한다.

trac 설치 방법, windows(pdf file)

“오리지널의 부재가 오리지널의 카피를 만든다.” -스마일 맨- from 공각기동대 SAC

공각 기동대를 관통하는 핵심 주제는 stand alone complex다. stand alone complex의 예로는 프리랜서와 회사원이 있겠다. 자유로운 생활을 즐기기 위해서 회사를 떠난 프리랜서와 홀로 서는 “초초함”을 이기지 못하고 회사(network)에 취직함으로써 프리랜서의 독립성을 버리고 회사 정책에 맞춰서 일하는 것… 전형적인 stand alone complex라 할 수 있다.

stand alone complex의 상세한 내용은 “stand alone complex란 무엇인가” post를 참조하자.

할인점의 무차별 융단 폭격에 동네 슈퍼는 아사상태다. 물론 동네 슈퍼만이 아니라 재래 시장도 상황은 좋지 않다. 보통 재래 시장은 현대화라는 방법으로 제 2의 전성기를 꿈꾸지만, remodeling 비용대비 효과는 크지 않다. 그래도 재래 시장이 remodeling 사업이라는 돌파구가 있어서 다행이었지만(?), 동네 슈퍼는 그동안 마땅한 정세 전환용 카드도 없었다.

한국체인사업협동조합에서 동네 슈퍼의 경쟁력을 높이기 위해서 ‘햇빛촌‘이라는 이름으로 동네 슈퍼 브랜드를 통일하는 사업을 본격적으로 추진한다고 한다. 해당 뉴스를 보면 알지만 할인점이나 편의점에서 사용하는 자체 브랜드처럼 ‘햇빛촌’이라는 브랜드로 중소기업의 제품을 싸게 구입해서 중소기업과 동네 슈퍼의 상생을 도모한다고 한다. 구지 이런 현상을 파악하는데 animation의 주제를 갖다 붙이지 않아도 되지만…

동네 슈퍼는 stand alone complex를 탈출하는 방법으로 개별성을 버리고 ‘햇빛촌’이라는 network의 세상에 들어간다. 개별 사업자로써 독립성은 포기하지만 network의 일부로 편입되는 이유는 전체와 운명을 같이하는 안정성을 추구하기 위해서다. 그동안 개별 node로써 힘겹게 대형 network과 경쟁하던 동네 슈퍼들에게는 경쟁력을 높일 수 있는 좋은 전략이기는 하지만 잊어서는 안되는 사실 한가지가 있다.

소비자들은 network에 부여된 brand를 개별 node에서도 체험하길 바란다. 즉, 이마트라는 network에 대한 소비자들의 기대 수준은 전국 어디의 할인 매장, 개별 node를 찾았을 때 동일한 수준에서 만족한다. 그러나 ‘햇빛촌’이라는 bottom-up형식의 네트웍에 대한 brand 만족도는 개별 node에 따라서 다를 수 있다는 사실이다. 강남에 있는 ‘햇빛촌’을 방문했을 때 얻는 만족도와 서울 주변 도시의 ‘햇빛촌’을 방문했을 때 만족도는 다를 수 있다. 개별 node의 이질성이 소비자의 brand 만족도를 떨어트릴 수 있다. 따라서 내가 생각하는 ‘햇빛촌’의 성공 point는 network 브랜드 만족도와 개별 node의 브랜드 만족도를 일치시키는 것이다.

쌓이는 책. 서점을 가면 안된다.

내가 좋은 책, 나쁜 책을 나누는 기준은 무척 간단하다. 바로 ‘재미’다. 간단함을 넘어서 편협하고, 자의적이고, 비합리적이다. 그러나 ‘재미’ 없는 책은 읽기가 싫다. 재미없는 책을 읽을 때면 페이지 페이지 넘기는 순간이 나와의 싸움이다.

“덮어? 계속 읽어? 반이나 읽었는데 아깝다. 계속 읽자”

도서관에서 보는 책이나 빌려 읽은 책은 덮어 버리면 그만이지만, 피같은 돈을 주고 산 책일수록 순간의 선택이 나를 괴롭힌다. 차라리 흥미로 읽는 책이라면 내 돈 주고 산 책이라도 덮어 버리면 그만이다. 그런데 먹고 살 목적으로 읽어야 하는 책이 ‘재미’까지 없으면 독서라는 행위는 ‘정신적 고문’이다.(그래서 직업은 흥미를 유발해야 한다.)

Read or Die의 주인공 요미코 리드먼, 코드명 The Paper

Read or Die의 주인공 요미코 리드먼(요미코=讀子, 리드먼=Readman)처럼 독서에 미친 캐릭터가 아니라면, 독서라는 지루한 행위로 돌려 받을 수 있는 것은 지식(혹은 지혜)과 ‘재미’다. 그렇기 때문에 지식의 바퀴가 아무리 커도 ‘재미’의 바퀴가 작으면 독서라는 수레는 제자리 걸음 밖에 할 수 없다.

독서와 음식을 비교하는 것은 그렇지만… 영영과 맛이 균형잡힌 음식을 먹다 TV 속의 junk food 광고를 보면, 느끼하고 자극적인 인스턴스 음식을 맛보고 싶은 욕망이 꿈틀댄다. 트랜스 지방산에 단백질은 코딱지보다도 적게 들어 있고, 지방 & 탄수화물 덩어리라는 것을 알지만, 윤기가 자르르르 흐르는 빅맥을 한 입 베어 물었을 때 그 향과 맛을 상상하면 패스트 푸드의 유혹을 뿌리치기도 힘들다.

오늘 소개할 오쿠다 히데오의 장편 소설 ‘라라 피포’도 junk food의 윤기가 흐르는 책이다. ‘라라 피포’에 나오는 주인공은 소위 말해 ‘인생의 실패자’다. 6명의 주인공이 등장하는 옴니버스 형태의 소설로써 각각의 이야기는 다른 이야기와 연결되어 6명의 주인공이 어떤 식으로던지 관계를 맺게 된다. 프란제시 카린스의 소설 “연쇄”에서 처음 제기되었던 지구 상의 15억 인구 중 아무나 뽑았을 때 다섯 명 이하의 사람들의 친분관계를 통하여 자신과 연결될 수 있다는 “여섯 단계의 분리(six degrees of seperation)”의 아이디어에 기초한 것임을 알 수 있다. 그런 아이디어가 차용되었을 뿐 “여섯 단계의 분리”가 이 책을 읽는 핵심 키워드가 아니다.

6명의 주인공의 면면을 살펴보면 다음과 같다.

• 스기야마 히로시 : 명문대 출신 대인 공포증 환자 32살, 남자, 프리랜서 기자
• 구리노 겐지 : 여자를 등쳐먹고 하루하루 살아가는 건달 23살, 남자, 카바레 클럽 스카우트맨
• 사토 요시에 : 권태로운 일상에서 탈출해 에로 배우로 거듭난 아줌마 43살, 여자, 주부
• 아오야나기 고이치 : 남의 말을 절대로 거절 못하는 소심남 26살, 남자, 노래방 아르바이트생
• 사이고지 게이지로 : 한때는 순수한 문학청년이었던 대머리 아저씨 52살, 남자, 관능소설가
• 다마키 사유리 : ‘폭탄’이라 불리는 못생긴 뚱땡이 28살, 여자, 테이프 리라이터

책을 덮었을 때는 마치 김기덕 감독의 영화 한편을 본 느낌이 든다. 김기덕 감독을 비평하는 평은 많지만, 그래도 김기덕 감독이 상을 받고 해외에서 주목을 받는 것은 인간이 지닌 못된 습성을 예술적 경지(?)로 끌어 올린 실력 덕택이다. 마찬가지로 오쿠다의 ‘라라피포’도 읽고 나면 머리에 남는 것은 불편함이다. 불편함… 그것은 사물 자체가 주는 혐오감에서 생길 수 있지만, 사물이 잊고 싶은 기억을 상기시켜 주거나 자신의 약점을 투사할 때 들기도 한다. 그 불편함이 잠자고 있던 내 본성을 깨워서 있지, 책에서 표현한 묘사가 생생해서 그런것인지 알 수 없지만, 소설이 가지는 서사구조를 떠나서 글을 참 재미있게 잘 썼다는 생각이 든다.(물론 서사가 약한다는 뜻은 아니다.) 어찌나 불편했던지 책을 다 읽은 날 불면증에 시달렸다. 뒷 목이 뻐근한 느낌.. 내 감수성이 그렇게 sensitive하지도 않은데 말이다.

‘라리피포’가 무슨 뜻일까? 책의 뒷부분에 그 뜻이 나오기 때문에 책을 끝까지 읽도록 배려해준 작가에게 감사하다. 궁금한 사람은 책을 읽거나 google에게 물어보자.

Read Or Google