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)

Tweet

This entry was posted on Sunday, May 14th, 2006 at 2:45 am and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.