Chapter 9

실용주의 프로젝트

개인에서 팀으로, 그리고 프로젝트 전체로 시야를 넓히는 마지막 장이야. 앞에서 다룬 모든 원칙을 팀 차원에서 어떻게 적용할 것인가. 그리고 책 전체를 관통하는 마지막 메시지지.

"앞 장까지의 모든 원칙을 '나'에서 '우리'로 확장하라."

실용주의 팀의 특징:

깨진 창문을 허용하지 않아 — 팀 전체가 코드 품질에 대한 기준을 공유하지. 한 사람이 엉성한 코드를 넣으면 다른 사람이 지적해. 비난이 아니라 팀 문화로서
삶은 개구리가 되지 않아 — 누군가는 큰 그림을 봐야 하거든. 모두가 자기 작업에 묻혀 있으면 프로젝트가 서서히 무너지는 걸 아무도 못 봐
소통해 — 팀 브랜딩을 하라고까지 말하지. 팀 이름, 팀의 정체성, 팀이 일하는 방식을 명확히 해
DRY를 지켜 — 팀 내 중복 작업을 방지. 누가 뭘 하고 있는지 서로 알아야 하거든

저자들이 강조하는 팀 규모: 작게 유지해. 큰 팀은 소통 오버헤드가 기하급수적으로 늘어나잖아. 기능별로 나뉜 작은 팀이 자율적으로 일하는 게 나아.

자동화도 팀 차원에서 중요하지. 빌드, 테스트, 배포를 자동화하면 반복 작업에서 벗어나서 진짜 중요한 일에 집중할 수 있어.

20주년 기념판에서 새로 추가된 절이야. 제목이 재밌지 — 카고 컬트(Cargo Cult) 이야기거든.

2차 세계대전 때 남태평양 섬 주민들이 미군 비행기가 물자를 떨어뜨리는 걸 봤어. 전쟁이 끝나고 미군이 떠나자, 주민들은 나무로 비행기 모형을 만들고 활주로를 닦고 의식을 행했지. 형식을 따라하면 물자가 올 거라고 믿은 거야.

소프트웨어 개발에서도 똑같은 일이 벌어져:

**"왜"**를 빼고 **"무엇"**만 따라하는 거지. 코코넛(형식)만 갖고는 안 돼.

저자들의 조언:

프로젝트를 시작할 때 갖춰야 할 기본 인프라를 다루지.

세 가지 핵심 도구:

수작업 절차가 들어가면 반드시 실수가 생겨. 사람은 반복 작업을 정확하게 못하거든. 기계가 더 잘하는 일을 사람에게 시키지 마.

테스트에 대해 좀 더 깊이 들어가:

"테스트를 찾아서 하지 마. 테스트가 코드를 찾아오게 해." CI/CD 파이프라인에 넣어서 커밋할 때마다 자동으로 돌아가게 하라는 뜻이야.

소프트웨어의 목적은 사용자를 기쁘게 하는 거야. 기술적 완성도가 아니라.

이 절은 개발자가 놓치기 쉬운 관점을 일깨워줘. 아무리 클린 코드고, 아무리 좋은 아키텍처고, 아무리 테스트 커버리지가 높아도 — 사용자가 원하는 문제를 해결하지 못하면 무용지물이잖아.

저자들이 제안하는 질문:

개발자는 코드를 작성하는 사람이 아니라 **"문제를 해결하는 사람"**이라는 정체성을 가져야 해. 코드는 수단이지 목적이 아니거든.

이건 1장의 "소통하라"와도 연결돼. 사용자와 대화하고, 사용자의 세계를 이해하고, 사용자의 언어로 소통해야 진짜 문제를 풀 수 있지.

책의 마지막 절이야. 제목이 제인 오스틴이지만 내용은 다르지.

자기 코드에 서명해.

옛날 장인들은 자기 작품에 서명을 새겼어. 자부심의 표현이자 책임의 표현이지. 프로그래머도 마찬가지여야 한다는 거야.

이게 "오만"이야 — 자기 이름이 붙을 만한 코드를 만들어야 한다는 자부심. "이 코드는 내가 만들었다"고 당당히 말할 수 있어야 해.

하지만 이 오만은 건강한 오만이어야 하거든:

편견은 경계해:

실용주의 프로그래머는 자부심을 갖되 교만하지 않고, 확신을 갖되 유연해. 이게 책 전체를 관통하는 메시지이기도 하지.

저자들의 마지막 한마디: "끊임없이 배우고, 비판적으로 사고하고, 책임을 져. 그리고 무엇보다 — 재미있게 해."

정리

9장, 그리고 이 책 전체에서 기억할 거 세 가지: