Younghoe.Info v3

질문에서 산출물과 Trac의 상충 관계를 의미하는 듯한 뉘앙스가 있어 오해했다. 다시 받은 질문인데, 산출물이라고 표현하셨으나 요체는 산출물을 활용하는 절차 즉, 프로젝트에서 이미 익숙한 개발 프로세스 하에서 Trac을 활용하는 방안을 묻는 듯하다. Trac를 처음 활용할 때 빠지기 쉬운 함정은 모든 작업을 넣어서 관리하려는 시도이다. 만일 시스템/솔루션 유지보수 조직이라면 Trac 활용이 원활할 수 있다. 그러나 개발 프로젝트에서는 대개 WBS나 PMS의 일정을 기준으로 진척을 확인한다. WBS의 하위 항목을 Trac에 넣으면 유용할까? 내가 Trac으로 작업관리를 해본 결과 Trac의 작업이 1일 이내의 작은 단위일 때 팀에 유연성을 제공했다. 과거에 우리 팀은 1, 2개월 간격으로 배포(release)를 했으나 지금은 매주 배포를 한다. 따라서, 매주 월요일에 고객이 기대할 기능이 빠져 실망하지 않게 하려고 목요일 이후쯤 조정을 해야 한다. 작은 단위의 일은 남은 이틀 안에서 조정할 수 있지만, 이틀을 넘어서는 일은 조정 자체가 힘들다. 테스트 주도 개발에서 켄트 벡이 보여준 것처럼 자신/팀의 리듬을 모르면 일단 작게 쪼개서 해라.

WBS와 Trac의 항목 일치는 힘들다는 사실을 알았다. 그렇다면, 서로 용도를 구분해서 사용해야 할까? 구분하는 방법과 연결 관계를 짓는 방법 모두가 있다. JCO 발표에서도 언급했지만 처음 Trac을 적용하는 경우라면 최대한 용도를 좁혀서 쓰는 방법을 권하고 싶다.

우리 팀은 처음에는 공식적인 작업은 백로그라는 엑셀 파일을 만들어 관리했다. Trac은 사전에 계획한 작업 이외에 반드시 추적할 필요는 없는 작업에 실험적으로 썼다. 대개는 코드 검사(Code Inspection) 이후에 테스트 누락이나 주석, 리팩토링 지시 등에 썼다. 용도에 대해 이름을 짓자면 개발팀 내 품질보증 활동을 위한 의사소통 도구 정도라고 할 수 있을까? 두 번째 쓰임새는 검수 과정에서 고객과의 의사소통 촉진용이다. 이미 개발자 테스트도 어느 정도 수행했고, 데모를 통해 정상 작동을 확인한 이후인지라 소소한 문제에 대한 보고이기 때문에 구체적인 설명이 필요했고, 경우에 따라서는 화면 캡처가 유용했다. 따라서, 시간을 정해서 회의하는 방식보다는 Trac에 관련 내용을 보고하고, 관계자가 해당 내용을 확인해서 바로 조치하는 방식은 시간을 절대적으로 절약해주었다.

후자는 고객의 적극적인 참여가 필수 전제 조건이다. 하지만, 웹이나 이클립스 화면(Mylyn 활용)을 써서 요구사항을 기록할 만큼 적극적인 고객을 만나기는 쉽지 않다. 적극성을 발휘하게 하려면 고객이 진심으로 관심을 가질만한 결과를 내놓아야 한다. 대개 요구 사항이나 화면 설계 등은 진정한 관심을 끌지 못한다. 요구 사항 검증이나 화면 설계서/정의서 검증에 고객을 참여시키려고 하면, 고객이 얼마나 관심이 없는지(?)는 확인할 수 있다. 하지만, 이는 고객의 문제로 보긴 어렵다. 동작하는 시스템을 써서 본인의 업무가 어떻게 바뀌고, 프로그램이 사용하는데 얼마나 편리한지/불편한지 느낄 때만 비로소 관심이 생긴다. 반복하지 않는 경우 프로젝트 막판에 가서야 구체적인 요구 사항을 들을 수 있다. 결국, 조기에 배포할수록 개발팀이 구체적인 피드백을 받는데 유리하단 이야기다. 조기 배포를 하려면 모든 기능을 한 번에 다룰 수는 없다. 애자일과 Trac의 시너지는 바로 이 부분에서 포착할 수 있다.

세 번째 활용 방식은 다른 질문 사항에 대한 답변이기도 해서 별도의 글로 나누어서 쓰겠다.

감기 때문에 모처럼 초딩으로 돌아가 10시 반쯤인가 잠이 들었다. 덕분에 아침부터 눈을 떠 메일과 RSS 구독 목록을 읽는다. 구독 목록을 훑어 보다 어떤 논쟁 끝에 달린 댓글을 봤다.


한창 4GL 언어가 주종을 이루고 SI 전문 업체가 태동할 시점에 입사했던 선배가 후배에게 훈화한답시고 프로그래밍 지식은 중요하지 않다고 말했다. 댓글을 보는 순간 얼굴도, 이름도 기억나지 않지만, 그때 선배의 말이 생각났다.

지금 생각해보면 당시 선배는 큰 조직에 입사해 보니 절실히 깨닫는 부분이 있어 지나치게 강조해서 이야기했을 뿐이다. 하지만, 경험이 없던 당시의 나는 울컥해서 후배를 모으고, 스스로 모임을 만들어서 학교에서 가르치지 않는 내용을 배우고 가르쳤다. 일을 하며 학교에 다녀서 시간도 없고, 동문에 대한 애착도 없고, 더구나 모임을 조직하는 일은 문외한인 나^[각주:1]의 변화는 놀라운 일이었다. 결국, 선배의 조언(?)은 의도와 달리 내가 SE 컨설턴트로 성장하는 데 혁혁하게 이바지했다.

다시 댓글에 대해 이야기하면 포기할 때 'SI는 안된다.' 식의 표현을 거두자. 남아있는 동료를 위해 좋은 말은 아니지 않은가? 무언가 포기할 때는 반성을 통해 배움을 얻어야 한다. 그것이 역사가 존재하는 이유^[각주:2]라 배웠는데, 개인에게도 예외는 아니라 생각한다.

나는 한동안 SI에 종사할 계획이다. 솔직히 떠나지 못한다고 확신하고 있을 뿐 구체적인 계획을 하고 있다는 말은 아니다. 최근 SI 분야에서 애자일 바람이 대단하다. 이러한 열풍을 만들어낸 이들과 댓글을 쓴 이는 같은 어려움을 근거로 하고 있다. 너무 동떨어진 사건을 관계짓는다고 생각하는가? 그렇다면, 구체적인 예를 들어보겠다.

현재 나는 팀장으로 ^[각주:3] 팀원 각자에게 동기를 부여하려고 노력한다. 팀원이 작업에 흥미를 잃어 눈치 보며 진도만 맞추려고 한다면 관리가 힘들어지기 때문이다. 프로젝트를 6개월 이상 진행하고 나니 확실히 숙련도가 늘었다. 팀원 스스로 언제까지 하겠다던 추정을 정확히 맞추기 시작했다. 그리고 나니 이번에는 뜻하지 않던 부작용이 찾아왔다. 슬슬 긴장감이 떨어졌다. 그래서, 고객과 회사에 보고한 공식 행사로 매주 프로젝트 내부 세미나를 진행한다. 이 자리에서 팀원 모두는 각자 고민한 내용을 나누고, 노력한 만큼 자부심을 얻는다. 세미나가 궤도에 오르자 다시 외부 발표를 준비하고 있다. 확정 단계는 아니지만, 우리 팀이 배운 내용을 월간 마소에 기고하거나 JCO에서 발표할 예정이다.

너는 팀장이니까 그렇지 않으냐? 나는 팀장이 되기 훨씬 이전부터 이런 방식을 익혀왔다. 위키를 처음 배운 2000년 즈음부터 내가 배운 바를 체계적으로 개인 위키에 정리했다. 2003년부터 써온 블로그는 위키 관리할 시간이 없어 선택한 대안이기도 하다. 주변을 돌아보라. 내가 닮고 싶어했던 모든 사람은 비슷한 방식으로 하루하루 노력하고 있다.

만일, '그래서'가 지칭하는 바가 자신에 대한 반성은 빠진 채로 암울한 특정 환경에 대한 원망만 담고 있다면, 자신을 소외하는 격이 아닌가? SI를 떠나는 이유가 '다시 음악이 하고 싶어서'와 같은 낭만적인 이유까지는 아니더라도 '가족 때문에 돈을 더 주는 유사 분야로 직장을 옮기려고' 정도의 소박한 내용이었다면 아마 나는 이런 긴 글을 쓰지 않았을 것이다.

* 혹시 댓글을 쓴 분이 보신다면 '상황이 마음에 들지 않을 때, 개선하는 노력을 충분히 했는지 돌아보자!'라며 스스로 다짐해왔던 내용을 남겼음을 알려 드립니다. 댓글 쓴 분의 상황을 모르기 때문에 비난할 목적은 아니었습니다. 혹시나 모를 부작용을 막으려고 댓글로 가는 링크는 삭제했습니다.

낮에는 프로젝트 중반에 고객과 개발자 사이에 갈등이 표출되는 광경을 보다가, 밤에는 제안 작업을 하느라 고객 설득을 위한 문서를 작성한다. 그러는 중에 사랑하지 않으면 떠나라에서 개발자와 고객에 대해 언급하는 이야기들을 화두로 해서 생각을 옮겨둔다.

이 책 전체에서 가장 인상적인 부분은 35, 36쪽에 걸쳐서 나온 내용이다.


무릎을 칠만한 절묘한 예시다. Hz와 RPM은 보통의 14살 아이에게 흥미롭지 않고, 사업가에게도 그렇다. 발췌한 글이 나오는 부분의 제목은 '적절한 표현으로 말하기'이다. 종종 ISP에 참여를 권하는 선배들도 같은 맥락이다. 엔지니어 시각으로는 고객이 정말 원하는 것을 설계하고 만들기가 어렵다. 96쪽에서 여기에 대해 말하고 있다.


위 표현에 대한 예시로 본인 경험을 들었다. 하던 작업을 마무리 하고 싶은데, 쌩뚱맞은 차트를 계속보여주는 리더를 보며 시간 낭비라고 투덜거리는 모습. 아타깝게도 이 글을 쓰기 직전 산출물 교육을 하고 왔는데, 자신과 관계 없는 내용이라고 여기는 1/3 정도 개발자는 발표자료 대신에 아무것도 놓여있지 않은 책상표면을 보는 것을 택했다. 이런 상태이거나 막 벗어나려는 상태라면 누구를 위해 일하는지 기억하라(146쪽)를 읽어보시라. 관리자의 성공과 여러분의 성공을 분리하지 말라. (148쪽) 한발 더 나아간 상황이라면 다음 말에 귀를 기울일 필요가 있다.


내 수준에 어울리는 실천지침이라서 가까운 시일내에 실천하기로 마음 먹었다.

202쪽을 보면 개발자 관점이 아니라 고객 관점에서 비슷한 현상을 되짚어 볼 수 있다. 고객은 개발자를 두려워하고, 자기가 하는 프로젝트에 대해 편하게 말해줄 사람을 찾으려 한다는 것!

예전에 어떤 프로젝트에서 PM이 개발자의 말을 통역(?)해주는 일을 무척 고마워했다. 책 내용을 조금 더 보자.


민망한 내용이지만 사실 자주 목격한다. 자주 범하고 있는지도 모르지만, 사실 자신의 실수는 잘 보이지 않는다.

사랑하지 않으면 떠나라! - 차드 파울러 지음, 송우일 옮김/인사이트