[개발관련도서] 조엘 온 소프트웨어(3/3)

3부 조엘 따라하기: 두서 없는 생각, 하지만 놓쳐서는 안 될 이야기

30장 - 이 나라에서는 개가 무슨 일을 하죠?

자기 개밥을 먹는다

• '자기 개밥을 먹는다'는 말은 컴퓨터 분야에서 쓰는 표현으로, 자기회사 제품을 실제로 사용해 보는 과정을 말한다. 저자는 출시 전회사의 제품을 직접 사용해봤는데, 버그 몇 개 때문에 작업 진행이 불가했다. 꼼꼼하게 테스트 과정을 거쳤지만, 제품 기능을 수행하지 못하게 하는 치명적인 버그는 다 고치지 못한 것이다. 고객 입장에서 제품을 실행해보니 버그가 바로 보였다. 이후 팀을 소집해서 모두 자사의 제품을 써서 사이트를 구축해 보자고 제안했다. 이게 바로 '자기 개밥 먹기'이다.
• 다들 자기 개밥 먹기를 해봐야 한다. 투자자금을 모으려고 전국을 누비는 대신, 고객 의견에 귀를 기울이고 개밥을 먹으면서 비즈니스에 집중해야 한다.

---

31장 - 말단이면서도 해내기

말단 프로그래머의 팀 개선 전략

1. 혼자라도 해라
   • 일일빌드 서버가 없는가? 직접 만들어라. 자신의 컴퓨터에 예약 작업을 설정하라. 밤마다 일일빌드를 돌리고, 그 결과를 다른 팀원들에게 이메일로 알려라.
   • 빌드 단계가 너무 복잡한가? makefile을 써라.
   • 사용편의성 테스트를 아무도 하지 않는가? 종이에 프로토타입을 그려 동료에게 보여주면서 직접 사용편의성 테스트를 해라.
2. 입소문의 힘을 이용해라
   • 예를 들어, 팀원 모두가 버그 DB(데이터베이스)를 꺼린다고 하자. 혼자라도 만들라. 다른 팀원 코드에서 버그를 발견하면, 버그 DB를 이용해 팀원에게 버그를 할당하라.
   • 아무도 소스관리를 하지 않는가? 자신의 컴퓨터에라도 CVS 저장소를 만들어라. 팀이 협조하지 않더라도, 코드를 독립적으로 체크인하라.
3. 우수한 인재를 모아라
   • 팀이 일정을 세우지 않는가? 명세서를 작성하지 않는가? 혼자라도 해라. 본인이 맡은 일에 대해 하루 이틀 시간을 들여 최소 명세서나 일정을 세운다고 해서, 아무도 불평하지 않을 것이다.
   • 채용과 인터뷰 업무에 참여하라. 우수한 인재가 여러분 팀에 합류하도록 홍보해라.
   • 개선할 의지와 능력이 있는 사람을 찾아 같은 편으로 만들어라. 아무리 엉망인 팀이라도, 똑똑하지만 경험이 좀 부족해서 뒤처진 팀원이 있기 마련이다. 이런 팀원에게 배울 기회를 줘라.
4. 고문관은 봉쇄하라
   • 최고 팀이라도 고문관은 있다. 실력 없는 프로그래머는 질 낮은 코드로 다른 질 좋은 코드까지 깨버린다. 뒤치다꺼리 하느라 우수한 프로그래머가 시간을 낭비하게 된다.
   • 말단 프로그래머 입장에서는 피해 최소화, 즉 원천봉쇄를 목표로 삼아야 한다. 고문관이 지저분한 코드를 짜오면 일단 참고 기다려라. 이후 코드에서 버그가 생기면 계속 그에게 보고하라. 그러면 보고할 버그가 없을때까지, 몇 달 동안은 버그 수정 작업에 매달릴 것이다. 즉, 몇 달 동안은 다른 개발자에게 더 이상 아무런 피해도 입힐 수 없게 된다.
5. 방해 받지 않는 곳으로
   • 혼자 조용히 업무를 할 수 있는 공간을 마련해라.
   • 늦게 출근해서 늦게 퇴근하라. 전 직원이 퇴근하고 난 몇 시간이 가장 생산적일 수 있다. 혹은 팀 전체가 늦게 출근한다면, 9시에 출근해라. 다른 사람이 출근해 방해를 받기 전 2시간 동안에 훨씬 더 많은 일을 할 수 있다.
   • 아웃룩이나 메신저 클라이언트를 띄워놓지 마라. 필요하다면 매 시간 확인해라. 계속 띄워놓지 마라.
6. 꼭 필요한 인물이 되어라
   • 조직에 긍정적으로 공헌하는 사람이 아니라면, 이제껏 제안한 전략은 먹혀 들지 않는다. 코드를 잘 짜지 못한다면, 코드를 짜고 있어야 할 시간에 버그 DB에 신경 쓴다고 욕먹기 십상이다. 프로세스에 집착하느라 업무를 달성하지 못한다는 낙인은 개발자 경력 관리에 치명적이다.
   • 저자는 말단 프로그래머일 당시 매일 7시간은 무조건 코딩을 했다. 그럼으로써 다른 팀원에게 좋은 인상을 주었다. 그러나 매일 오후 퇴근 전 한 시간은 프로세스 개선에 쏟았다.

• 책임자가 아니라 할지라도 변화를 일으킬 수 있다.

---

35장 - NIH 신드롬을 옹호하며

핵심 비즈니스 기능은 직접 수행하라

• 핵심 비즈니스 기능과 목표를 파악한 후 직접 수행하라. 소프트웨어 회사에서는 우수한 코드가 성공하는 길이다. 사내식당 관리 등의 작업은 아웃소싱해도 괜찮다. 고객이 있다면, 고객 지원 팀은 절대로 아웃소싱하지 마라.

---

마무리

책을 다 읽었다. 3장과 4장은 꽤나 많은 부분을 생략했다. 아직 나에게 와닿지 않는 내용들이 많아서 정리하지 않고 읽기만 했다. 기본적으로 이 책은 소프트웨어 회사 운영자가 읽으면 좋을 것 같다. 아직 대학원에 있는 나에게는 조금은 동떨어진 이야기지만 언젠가는 마주칠 문제들이라 허투루 보지 않고 전부 읽었다. 그리 책이 두껍진 않았는데 무엇을 블로그에 넣을지 고민하고 작성하느라 꽤나 많은 시간을 보냈다. 그래도 올해 가기전에 끝내리라고 목표를 잡았는데 끝낼 수 있어 감사하다.