프로젝트나 팀 구성에서 '이런 문제는 이런 도구를 사용하면 쉽게 해결될텐데...'라는 생각이 든 경우가 많다. 아무래도 한번 겪어보면서 받은 충격이 커서 실제로 다시 적용해 보고 싶은 생각이 있어서 그런 것 같다. 물론 직접 해보면 구성원이나 환경의 차이로 인한 다른 결과가 나올 수도 있지만 아무튼 몇가지 의사 소통이나 업무 처리에 사용되는 도구들에 대한 생각을 적어봤다.

메일링 리스트 - 의사소통을 메일링 리스트를 통해서 공개적으로 하면 많은 장점이 있다. 공개적인 의사소통은 팀이 움직이는 모습을 공유함으로써 소속감을 높이고 프로젝트 상황에 대한 공감대를 형성할 수 있다. 새로 팀에 유입된 사람도 금방 멤버들의 성향이나 업무 분야 등을 빠르게 따라잡을 수 있다. 새로운 멤버가 생기면 가입시키는 것은 당연하지만 소속이 변경되었다고 해서 강제로 탈퇴시키지 않는다. 탈퇴와 가입을 개방해서 자신이 더이상 필요 없다고 느끼는 메일링은 알아서 탈퇴하고 관심있는 프로젝트는 스스로 가입할 수 있게 하는 선택권을 준다. 메일링 아카이브도 공개적으로 운영해서 히스토리도 공유하고 관심있는 프로젝트 메일링에 가입하지 않아도 필요할 때 확인할 수 있게 한다. 회사차원에서 가벼운 내용(오늘 벙개합니다 등)이나 트랜드, 기술관련 내용을 공유하는 메일링을 따로 운영하는 것도 좋다. 메일이 많이오는 것을 부담스러워하는 사람도 있지만 요즘은 메일 클라이언트이 워낙 좋기 때문에 중요한 메일과 중요하지 않은 메일을 잘 구분할 수 있다. 메일 클라이언트 잘 사용하는 능력도 중요한 업무 스킬이다.

위키 - 문서공유는 중요하면서도 상당한 오버헤드가 발생하는 일인데 되도록이면 파일로 문서를 공유하기 보다는 위키를 활용한다. 작성한 사람이야 문서의 언제 어디가 무슨 이유로 변경되었는지 기억하기 쉽겠지만 문서를 읽는 사람 입장에서는 변경내역을 아무리 잘 써놔도 정확한 문맥을 파악하기가 힘들다. 위키는 문서의 업데이트 현황과 변경 이력을 관리하는데 상당한 강점을 가지고 있다. 효과적인 협업이 가능하다. 위키에 있는 변경사항 알림기능(watch)을 사용하면 항상 최신의 프로젝트 상황을 파악할 수 있다. 문서간의 연결을 관리하고 문서들을 분류하는 일이 상당히 힘든데 오래된 문서나 내용이 잘못된 문서를 효과적으로 관리하는 방법에 대한 고민이 많이 필요하다. 누군가는 위키를 신경써서 관리를 해줘야 한다. 그리고 보통 팀에 한명씩은 있는 것 같다. 다행히 위키중에는 문서의 연결관계를 잘 보여주는 제품들도 있어서 유용하다. 위키 문서를 구문을 다 맞춰가면서 완벽하게 작성하려고 할 필요는 없다. 위키 문법을 잘 모르고 쓴 글이어도 내용만 있으면 서식은 누군가가 업데이트할 수 있다.

이슈/버그 관리 시스템(Issue/Bug Tracking System) - 이슈관리와 버그관리는 다른일이지만 생성 소멸 과정(issue life span)이 비슷하기 때문에 도구는 하나로 통합해서 사용할 수 있다. 개인적으로는 모든 업무를 ITS에 등록하고 진행하는 방법을 선호한다. 주간 보고를 아예 생략하거나 주간 보고를 금요일에 ITS를 보고 요약 작성하는 정도를 말한다. 이렇게 하면 ITS에 오고가는 내용만 추적하고 있어도 일이 진행되는 전체 모습을 파악할 수 있고 업무 처리도 ITS에서 자신에게 할당된 목록을 보고 진행할 수 있다. 가장 큰 강점은 가장 활발하거나 놓치고 있는 이슈를 파악해서 위험 요소를 미리 예측할 수 있다는 점이다. 자원을 어떻게 배분해야할지 결정하는데 많은 참고가 될 수 있다. ITS/BTS 항목은 생성, 확인, 할당, 처리, 완료, 검토 6과정(처리를 빼면 5과정)을 거치게되고 이 과정을 잘 이해해야 효과적으로 사용할 수 있다. 이 단계에서 할당(assign)을 상당히 두려워하는 사람들이 있는데 다른사람에게 일을 시킨다는 느낌이 많이 들기 때문이다. 또한 할당을 이리저리 잘못해서 이슈 처리가 제대로 되지 않는 상황이 발생하기도 하는데 어느정도 훈련이 필요한 일이다. 이건 나중에 따로 한번 더 다뤄봐야겠다. 중요한 점은 이슈 관리 시스템은 일을 시키거나 버그를 해결해주는 도구가 아니라 이슈 해결을 위한 커뮤니케이션 도구라는 점이다. 열려있는 이슈가 엄청나게 많고 해결이 잘 안되고 있는 상황도 문제지만 열려있는 이슈가 하나도 없는 상황도 문제다. 닫는데만 급급해서 건강하게 이슈가 관리되고 있지 않은 상황이라고 할 수 있다. 열린 이슈를 없애는데만 집중하게되면 정보가 은닉되고 누락된다. 버그는 항상 존재하고 실수도 항상 존재한다는 점을 인정하고 버그와 실수를 완전히 공개 할 때 건강하게 프로젝트와 팀이 관리된다. 우선순위를 잘 지정하는 일도 매우 중요하다. 이슈와 버그 항목이 많이 쌓이면 돈주고 절대 살 수 없는 실무 경험 기반의 자산이 된다.

코드 형상 관리 시스템(Version Control System) - Git, Mercurial, 또는 SVN. 보기 좋은 코드 비교(diff)와 커밋 로그를 유지하고 싶은데 쉽지 않다. 커밋 로그의 중요성은 많은 사람들이 강조하지만 잘 관리되지 않는 경우도 많이 보게 된다. 오픈소스 프로젝트에서 이슈가 관리되는 과정을 살펴보면 도움이 많이 된다. ITS가 먼저 활성화되면 어느정도 같이 해결되는 부분도 있는 것 같다. 최소한 커밋로그를 공백이나 쩜만 넣는 경우는 피할 수 있고 커밋 로그가 잘 이해가 안가도 ITS에서 내용을 확인할 수 있다. 동료끼리 코드 리뷰하는 문화를 만들고 코드를 서로 섞는 일이 자연스러워야 VCS를 잘 활용할 수 있게 되지 않을까 싶다. 나의 업무내역을 다른사람에게 설명해준다는 생각으로 코드를 관리해야 한다. VCS나 DVCS 관련 내용은 방대하기도 하고 좋은 글들도 많이 있다. 전략도 그만큼 다양하다. 우수 사례를 잘 살펴보고 현재 상황이나 제품에 맞는 방법을 만들어야 한다.

지속적인 통합(Continuous Integration), 잦은 배포 - 잘 모르는 분야이기는 한데 QA 프로세스가 제대로 받쳐주는 환경을 만드는 것이 중요할 것 같다. QA가 사전에 정립되어 있는 테스트 시나리오에 많이 의존하거나 릴리즈할때만 참여하는 모양새라면 테스트 부족으로 CI를 통한 잦은 배포 프로세스가 자칫 위험요소(오번가?)가 될 수도 있다. 리그레션 범위 관리와 코드 리뷰, TDD가 활성화 되고 강력한 QA 조직이 있어야 원활하게 안착 할 수 있을 것 같다. 이 역시 프로젝트나 제품의 특성에 따라서 다양한 전략이 가능하지 않을까 싶다.

적고보니 주관적인 부분이 많고 잘 모르는 부분도 있다. 특히 피어 리뷰...제대로 해본적이 없다. 더 많은 경험이 필요하다.