프로젝트 전에
- 8.1 요구 사항의 구렁텅이
- 8.2 불가능한 퍼즐 풀기
- 8.3 함께 일하기
- 8.4 애자일의 핵심
코드를 한 줄이라도 치기 전에 해야 할 것들을 다루는 장이야. 요구사항 파악, 문제 해결 사고법, 협업, 그리고 애자일이 정말 의미하는 것. 코딩 능력만큼 중요하지만 종종 간과되는 영역이지.
아무도 자기가 정확히 뭘 원하는지 몰라.
요구사항 수집의 가장 큰 함정: 고객이 말하는 것과 실제로 원하는 것이 다르거든. 고객은 자기 문제를 기술 용어로 번역해서 전달하려고 하는데, 그 과정에서 왜곡이 생기지.
저자들의 핵심 조언:
- 요구사항을 수집하지 마라. 발굴(dig for)하라. 표면에 있는 게 아니라 파내야 해
- **"사용자가 이것을 왜 필요로 하는가?"**를 물어. what이 아니라 why를 파악해야 하거든
- 요구사항 문서는 시작점이지 완성품이 아니야. 피드백 루프가 필수지
요구사항 과잉 명세도 경고하거든. 모든 걸 미리 문서에 적으려는 시도는 실패해. 정책(policy)과 구현(implementation)을 분리해야 해. "사직원은 연차를 20일 받는다"는 정책이고, "DB 테이블에 leaveBalance 필드가 있다"는 구현이야. 정책은 요구사항이지만, 구현은 개발자의 영역이지.
피드백 루프를 짧게 유지해가 이 절의 결론이야. 프로토타입, MVP, 짧은 이터레이션으로 고객과 자주 확인해.
"상자 바깥에서 생각하라"는 진부한 말 대신, 저자들은 **"상자를 찾아라"**고 하지.
문제가 풀리지 않을 때 진짜 이유:
- 제약 조건을 잘못 이해하고 있어
- 실제로는 없는 제약을 있다고 가정하고 있지
- 문제 자체를 잘못 정의하고 있어
저자들이 제시하는 사고법:
- 모든 가능한 길을 나열해
- **"정말 반드시 이래야 하는가?"**를 각 제약에 물어봐
- 제약을 하나씩 제거해봐 — 그러면 풀리는가?
- 더 쉬운 관련 문제를 풀어봐
- 문제를 다른 관점에서 재정의해
트로이 목마 얘기도 나오거든. 트로이 성벽은 난공불락이었지만, "성벽을 넘어야 한다"는 제약을 "성문으로 들여보내면 안 될까?"로 바꾸니 해결됐잖아. 진짜 제약과 가짜 제약을 구분하는 게 핵심이야.
20주년 기념판에서 새로 추가된 절이야. 이전 판에서는 개인 기술에 집중했는데, 이번에는 협업을 명시적으로 다루지.
핵심 개념: **짝 프로그래밍(Pair Programming)**과 몹 프로그래밍(Mob Programming).
짝 프로그래밍:
- 한 사람이 코드를 치고(드라이버), 한 사람이 방향을 잡아(네비게이터)
- 실시간 코드 리뷰 효과가 있지
- 지식 공유가 자연스럽게 이루어져
몹 프로그래밍:
- 팀 전체가 하나의 화면 앞에서 함께 작업
- 극단적이지만, 복잡한 문제나 팀 빌딩에 효과적이야
저자들은 항상 이렇게 하라는 게 아니라, **"적절한 시점에 함께 일하는 것의 가치를 과소평가하지 마라"**는 입장이야.
그리고 코드 리뷰에 대해서도 언급하지. 코드 리뷰는 결함을 찾는 것뿐 아니라 학습의 기회야. 다른 사람의 코드를 읽고, 다른 접근 방식을 배우고, 팀의 코딩 표준을 맞추거든.
콘웨이 법칙도 나와: "시스템의 구조는 그것을 만든 조직의 구조를 반영한다." 좋은 소프트웨어를 만들려면 좋은 팀 구조가 먼저야.
애자일은 명사가 아니야. 형용사지.
이 절은 20주년 기념판에서 가장 날카로운 비판이 담긴 부분이야. 저자들은 현재의 "애자일 산업" — 인증, 프레임워크, 컨설턴트 — 에 대해 쓴소리를 하거든.
애자일 선언문(2001)의 원래 정신은 단순했어:
- 프로세스와 도구보다 개인과 상호작용
- 포괄적인 문서보다 작동하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획을 따르기보다 변화에 대응
그런데 이게 **"애자일 프레임워크를 도입하면 애자일해진다"**로 변질됐다고. 스크럼 마스터 자격증이 있으면 애자일이고, 스프린트를 운영하면 애자일이라는 착각이지.
저자들이 말하는 진짜 애자일:
- **"피드백 루프를 통해 지속적으로 방향을 조정하는 것"**이 핵심이야
- 특정 프레임워크를 따르는 게 아니라, 값(values)과 원칙(principles)을 실천하는 거지
- 작은 단위로 만들고, 피드백 받고, 수정하고, 반복
실용적 조언: "우리 팀이 애자일한지" 확인하는 방법 — 작업 방식을 바꿀 필요가 있을 때, 얼마나 빠르게 바꿀 수 있는가? 프로세스가 경직되어 있다면, 아무리 스크럼 보드를 쓰고 데일리 스탠드업을 해도 애자일이 아니야.
정리
8장 읽고 기억할 거 세 가지:
- 요구사항은 발굴하는 거야. 고객의 말 뒤에 숨은 진짜 필요를 파악해
- 제약 조건을 의심해. 풀리지 않는 문제는 대개 가짜 제약 때문이거든
- 애자일은 프레임워크가 아니라 태도야. 피드백 루프를 짧게, 변화에 유연하게