Ship It

Ship It by Jared Richardson, William Gwaltney

Ship It은 소프트웨어 개발에 관한 가이드라인을 담은 책이다. ‘도구와 인프라스트럭처’, ‘실용주의적 프로젝트 기술’, ‘예광탄 개발’, ‘일반적인 문제와 해결방법’의 네 부분으로 나뉜다.

‘도구와 인프라스트럭처’는 CVS 또는 Subversion과 같은 코드 저장소, 빌드의 자동화, 이슈 및 기능 추적, 테스트 자동화와 같은 이슈를 다루고 있다. 사실 이러한 도구들을 사용하라는 가이드라인은 흔히 들을 수 있는 이야기지만, 이 장의 마지막 가이드라인인 ‘실험하지 말아야 할 때’에서는 ‘핵심적인 기술을 기술 실험 대상으로 삼아선 안 됩니다’라는 중요한 교훈을 얘기하고 있다. 의욕에 찬 하지만, 경험은 부족한 개발자들이 흔히 하는 실수다.

‘실용주의적 프로젝트 기술’에서 소개하는 목록 사용은 오래 전부터 나나 내가 일하던 팀, 내 주변의 사람들이 실제로 활용하면서 훌륭한 습관임이 증명된 프랙티스다.

일일 회의나 모든 코드의 검토, 코드 변경 통지 등은 내겐 약간 적용하기 힘들어보이는 프랙티스들인데, 각각의 프랙티스는 나름의 장점들을 갖고 있다는 것에 동의하기 때문에 조금씩 적용해 볼 생각이다.

내가 맡고 있는 조직에 주간 회의를 적용하기 시작한지가 수개월 지났고, 현재는 어느 정도 정착이 되어가고 있다. 하지만, 어차피 작업이나 문제 관리를 위한 의사 소통이 매일 일어나는 것을 생각하면, 일일 회의는 의사소통이 예측 가능하게 일어나게 해주고, 때문에 효율적인 의사소통이 가능하게 해주리라 생각한다. (이는 주간 회의를 포함한 ‘정기적인 회의’의 장점일 것이다.) 하지만, 일일 회의를 시행하기 위해서는 주간 회의라는 익숙한 프랙티스를 포기해야 한다. 이와 같이, 어떤 프랙티스가 좋고, 현재의 프랙티스를 대체하자는 얘기는 너무나 쉽지만, 이것을 적용하기 위한 사람들의 지지를 얻고, 대체 과정의 비용을 줄이고, 실제로 잘 적용하는 것은 여러 고민과 많은 노력이 필요한 일이다.

코드 검토의 경우, 이 책에서는 변경을 포함한 모든 코드를 검토해야 한다고 나와있지만, 그보다 온화한 (덜 진보적인) 단계로, 새로운 모듈이나 프로그램, 시스템이 완성되었을 때, 코드 검토를 하는 프랙티스가 경험적으로는 상당히 좋았던 것 같다. 아마도 이를 코드 검토를 시작하는 팀의 마지노선으로 잡으면 될 것 같다. 코드 검토는, 이 책에서 얘기하는대로, 작은 단위로 할 수록 효율과 정확성이 높아지는데, 작은 단위로 리뷰하는 문화를 정착시키는 것은 또 다른 과제다.

현재 팀에는 기술 리더라고 할만한 사람들이 몇 명 있는데, 팀의 한 파트를 책임지고 있는 나도 그 중의 한명이라고 볼 수 있다. 간단하게 말해서, 기술 리더는 기술 업무와 관리 업무를 수행해야 하는데, 둘 다를 수행하는 것은, 한가지만을 수행하는 것에 비해 절대 쉬운 일은 아니다. 가장 중요한 책임 중 하나는 역시 우선 순위의 조정이다. 업무의 목록은 팀원들 각자가 결정할 수 있지만, 우선 순위의 문제는 항상 기술 리더의 책임이다. 요즘 내가 생각하고 있는 것은, 우선 순위 결정을 주간 보고나 주간 회의와 같은 과정에 자연스럽게 연결해 프로세스화 하는 것이다.

‘예광탄 개발’은 일반적인 애자일 개발과 얼마나 크게 차이가 있는지 모르겠고, 굳이 ‘예광탄 개발’이라는 이름표를 달아주어야 하는지 의문인데, 이 글에서는 설명을 생략하도록 한다.

‘일반적인 문제와 해결 방법’은 분류하기 힘든 가이드라인을 모아놓은 부분이라고 볼 수 있는데, 그 중 ‘불한당 개발자’에 대한 대처 방법을 다룬 항목이 흥미로웠다. 고삐를 채울 수 없는 불한당의 경우, ‘불한당의 행동을 문서화하고, 반항적 행동을 문제 삼아 해고해야 한다’는 것이다. 그리고, ‘대부분의 경우엔, 문서화 과정을 시작하는 것만으로도 충격받아 제자리로 돌아온다’라고 한다. 실제로도, 문제를 일으키는 팀원의 경우, 문제점을 지적당하면, 그 근거를 제시하라는 답이 돌아오기도 한다. 이에 대한 정당한 답변은 다른 사람에게 어떻게 얘기했는가, 어떤 예절 바르지 못한 행동을 했는가 등이 아니라, 잘 문서화된 작업 목록 뿐이다. 이런 수단이 악의적으로 사용되어서는 물론 안되겠지만 말이다. 한편, Jeff Atwood의 ‘Dealing With Bad Apple‘이란 글에서는 불한당 또는 Bad Apple은 팀 전체에 악영향을 미치며, 어떤 사람의 능력은 발전할 수 있어도 태도는 변하기 어렵다는 이유로, 빨리 제거하는 방법밖에 없다고 얘기하고 있다.

이 책 전체에서 드러나는 실용주의적 태도 – 어떤 프랙티스가 절대적으로 옳다고 주장하기 보다는 적합한 것을 적용해나가자는 태도 – 는 상당히 마음에 드는 편이다.

내용이나 태도 뿐만 아니라, 구성 면에서도, 하나의 가이드라인마다 마지막에 ‘어떻게 시작하면 될까요?’, ‘제대로 사용하고 있는 걸까요?’, ‘경고 신호’와 같은 섹션을 두어, 이 책에 나온 가이드라인을 실제로 행동에 옮길 수 있는 지침으로 활용하기 좋게 만들어져 있다.

번역은 따로 언급할 필요가 없을 정도로 잘 되어 있는 편이다. 최근에 출판되는 해외에서 유명한 기술 서적들은 평균적인 번역 품질이 예전보다는 많이 좋아진 것 같다.