작년 가을이었습니다.
UCC를 활용한 랭킹시스템이 탑재된 작은 커뮤니티 웹사이트를 하나 만들어야 하는 상황이었습니다.
한분의 프로그래머, 얼마전에 새로 오신 프로그래머분, 그리고 저 이렇게 셋이 있었고, ppt로 제작된 화면UI와 데이터베이스 스키마가 막 나온 상태였습니다, 그리고 개발 완료로 지정된 마감일까지 남은 시간은 workday로 무려(!) 11일 정도 였습니다.
내부 개발 이슈 외에 외부적으로 이 프로젝트에 연결된 회사가 두개 더 있다보니 의사소통에 애를 먹고 아웃룩만 부여잡다 시간이 꽤 지체된 것이지요.

솔직히 답이 안섰습니다. 시간이 고작 열흘정도라니요. 게다가 이 프로젝트의 구성원 중 웹프로그래머 한분은 이제 우리쪽 코드 컨벤션이나 개발 프로세스에 적응을 시작하셔야 할 판이었고, 나머지 한분과는 반년남짓 일을 같이 해 보아서 어느정도 서로에 대한 파악이 잘 되었지만, 우리 셋이 함께 팀웍을 발휘한 경험은 한번도 없었기에.. 솔직히 (개발적으로) 우리 팀을 제대로 신뢰하지도 못하는 상황이었기 때문이었습니다.
더군다나 웹디자이너는 한분이라 우리가 html 퍼블리싱이나 심지어 그림 자르기까지 도와야할 판이었습니다.

너무 막막했습니다.
그런데, 답답해하며 하루 종일 퍼즐맞추기처럼 스토리를 나누고 조합하며 스케쥴링을 해 보았더니 '모든 예외사항이 없다면 열흘 안에 가능하기도 하다'라는 미심쩍은 결론이 났습니다. -.-
그리고 이 빡빡한 스케쥴을 유연하고 효과적으로(그리고 정해놓은 순서대로) 수행하기 위해서는 서로 대화의 시간이 많아야 할 것 같다는 생각을 했고, 그 방법으로 여기저기 글들을 통해 느꼈던 회고라는것의 장점을 활용하기로 했습니다.
그래서 우리는 없는 시간을 쪼개 '최소 매일 2번 회고'라는 내부 규칙을 만들었습니다.

각자 전달받은 타임 테이블에서 자신에게 할당된 (1)오늘의 목표량을 확인 한 후, (2)출근 후에 30분, 그리고 각자 업무를 가진(목표를 수행한) 후 (3)퇴근 전에 30분동안 회고를 하기로 한 것입니다.

그런데 저는 개발방법론에서 말하는 회고retrospective에 대한 개념도 지식도 약했고 이런 방법론들에 관련된 책들이 있을거란 생각도 못해봤기에 그냥 여기저기서 얻은 잡지식(?)과 글들을 답습하는 식으로 진행을 하기로 했습니다.

일단 퇴근 30분전에는 각자 자신이 오늘 만든 프로그램을 프로세스레벨로 나머지 팀원에게 설명하면서, 이 부분을 만드는데 이런 삽질을 했다, 이 부분들은 이렇게 하니 쉽게 되었다 하는 이야기를 담았습니다.

출근해서는 오늘 자신이 개발할 프로그램에 대해서 서로 공유하면서 만들 프로그램에 대한 비슷한 경험이 있는 사람들이 서로 과거 개발시에 겪었던 (기술적이든 비기술적이든)경험을 공유하고 분석하고, 모두 경험해보지 못한 모듈이나 프로그램이라면 함께 머리로 프로세스를 만들어보는 시간을 가졌습니다.

"이건 이렇게 이렇게 하면 되겠죠?"
"근데 이런이런 예외사항 있을 수 있잖아요"
"그건 이렇게 이렇게 해보면?"
"그렇게 되면 처음에 빨강씨가 설명한 이 부분이 이렇게 되어버려요"
"음, 그러면 여기부터 여기까지 부분을 빼면 어때요?"
"그 부분을 빼면 확장성이 떨어지고, 제 생각엔 이걸 추가하면 될 것 같은데요."
"아, 그렇네요!"
"네, 정말 그러면 되겠네요."

대충 이런식으로 말이죠.


경험 공유는 되도록 긍정적이고 좋았던, 그리고 잘 되었던 느낌과 사실부분들을 많이 공유하도록 분위기를 이끌었지만, 마음이 아팠던 삽질을 무조건 덮거나 하진 않았습니다.



이런식으로 매일 두번, 많게는 서너번씩 회고를 하며 얻은 직접적 효과는 :

1. 회고를 통해 논리적 오류와 코드레벨의 오류까지 잡히는 때가 많아, 후에 디버깅시간을 매우 단축할 수 있었음
2. 만들 프로그램에 대한 경험 공유로, 각 모듈의 초기 개발시간이 매우 단축 되었음.
3. 매일 프로세스에 대한 정의를 같이 하다보니 프로젝트 스케쥴 작성시에 빼먹은 스토리나 빈약하게 정의한 스토리를 미리미리 캐치할 수 있어짐.
4. 팀의 대화시간을 넓힘으로 처음모인 우리들이 빠르게 가까워지는 계기를 마련 했음.

그리고 간접적 효과는 :

1. 많은 대화속에 매일 프로세스를 같이 만들다보니 서로에 대한 신뢰가 강해지고, 자존심?이 약해졌다랄까. 사소한 부분까지 서로에 대한 의견을 자주 묻고 그것을 통해 해결하는 일이 잦아짐.
2. 논의가 필요한 경우 그때그때 간의 회의가 열리게 되었고, 토의를 통해 프로세스를 완성하게 되었기 때문에 혼자 오랫동안 삽질하거나 머리싸매는 경우가 많이 줄어듬.
3. 오늘의 목표량을 조기 달성한 경우, 간의 회의를 열어 목표량이 많이 남은 사람것의 스토리를 세부적으로 나눠서 같이 처리하거나 (내것이나 다른 팀원의)다음날 목표를 미리 끌어다가 처리하도록 함.

회고 첫날은 남자 세명이 좁게 모여있는 모습이 서로에게 조금은 부담스러웠지만, 서로 조금 더 먼저 웃고 마음에 있는 얘기들을 꺼내게 되면서 매일매일 회고와 대화의 시간을 가지다보니 맨 처음 생각했던 '한사람이 하는 것 처럼' 세명이 유기적으로 즐겁게 일을 하기 시작했습니다.
게다가 목표 조기달성으로 인해 나날이 단축되는 작업시간으로 거의 매일 타임테이블을 새로 작성해서 프린트할 정도였습니다.
결국 우리는 8일동안 (본인 빼고는)야근도 하루 없이 웹사이트를 완성했고, 나머지 2일동안엔 서로 각자 만든 프로세스/코드리뷰를 하며 페어/트리플 프로그래밍으로 버그들을 수정했습니다.


매일 정기적이고 또 비정기적으로 가진 회고를 통해, 우린 마감일이라는 압박의 불안감을 서로를 의지함으로 해소할 수 있었고, 내가 부족한 부분을 남이 가진 부분으로 채우며, 본인조차 인지하지 못했던 부분을 억지로 또는 자연스레 꺼냄으로써 좀 더 기민하게 프로젝트를 진행한 즐거운 시간들이 되었던 것 같습니다.