책노트: The Pragmatic Programmer 7회차 - 프로젝트 전에 질문을 다듬기

The Pragmatic Programmer 7회차 - 프로젝트 전에 질문을 다듬기

프로젝트는 첫 커밋보다 훨씬 전에 성공하거나 실패하기 시작한다. 요구사항을 읽는 법, 질문을 바꾸는 법, 준비되지 않았다는 감각을 존중하는 법이 필요하다.

■ 이 노트의 사용법

이 글은 The Pragmatic Programmer을 8회로 나눠 읽는 시리즈의 7회차다. 범위는 Chapter 7 · Before the Project다.

포착 -> 증류 -> 연결 -> 표현 4단계 깔때기로 읽는다. 핵심 원칙은 그대로 둔다. 책 노트는 창고, 인사이트 카드는 화폐.

L0 · 서지 & 진입

• 한 문장 핵심: 프로젝트 전의 좋은 질문은 프로젝트 중의 수많은 회의를 줄인다.
• 이 책을 든 이유 / 기대한 질문: AI가 코드를 빠르게 만들수록, 개발자가 지켜야 할 사고 습관과 운영 기준을 더 분명히 하고 싶었다.
• 읽기 전 가설: 이 책은 오래된 조언 모음일 것이라고 예상했다. 하지만 읽을수록 최신 도구보다 오래 가는 개발자의 운영 체계를 말하고 있었다.
• 저자 한 줄 컨텍스트: Andrew Hunt와 David Thomas는 소프트웨어 장인정신, 자동화, 실용주의 개발 문화에 큰 영향을 준 Pragmatic Bookshelf의 공동 창립자다.
• 이번 회차 범위: The Requirements Pit, Solving Impossible Puzzles, Not Until You’re Ready, The Specification Trap, Circles and Arrows
• 이번 회차 질문: 프로젝트 시작 전에 무엇을 명확히 해야 실패 비용을 줄일 수 있는가?

L1 · 포착함

■ 저작권 메모

원문 전체를 재현하지 않고, 각 장의 주장과 예시를 내 언어로 압축한다. 필요한 표현은 짧은 문구 수준으로만 사용한다.

• 이번 장은 Chapter 7 · Before the Project를 통해 개발자의 태도와 작업 방식을 묻는다.
• 핵심은 “프로젝트 시작 전에 무엇을 명확히 해야 실패 비용을 줄일 수 있는가?”라는 질문으로 압축된다.
• 기억할 영어 표현: requirements · specification trap · readiness
• 내 블로그/PKM/에이전트 작업과 연결하면, 이 장은 “개인의 요령”보다 “반복 가능한 하니스”에 가깝다.

L2 · 챕터 지도

범위	내가 붙인 이름	핵심 질문
Chapter 7 · Before the Project	프로젝트 전에 질문을 다듬기	프로젝트 시작 전에 무엇을 명확히 해야 실패 비용을 줄일 수 있는가?

요구사항은 땅속에서 캐내는 것이지 누가 완성품으로 건네주는 것이 아니다. 불가능해 보이는 퍼즐은 제약을 다시 보면 풀릴 수 있다. 준비되지 않았다는 감각은 게으름이 아니라 정보 부족의 신호일 수 있다. 명세와 다이어그램은 소통 도구이지 현실의 대체물이 아니다.

L3 · 인사이트 카드 색인

• Pragmatic Programmer - I7.1 요구사항은 문장이 아니라 대화의 흔적이다
• Pragmatic Programmer - I7.2 불가능한 퍼즐은 질문을 바꾸라는 신호다
• Pragmatic Programmer - I7.3 명세는 하네스가 되어야 한다

1. 요구사항은 문장이 아니라 대화의 흔적이다

문서에 적힌 요구사항만 믿으면 사용자의 진짜 제약을 놓친다. 좋은 개발자는 요구사항을 번역하고 되묻는다.

2. 불가능한 퍼즐은 질문을 바꾸라는 신호다

막힌 문제는 종종 기술이 부족해서가 아니라, 제약을 잘못 고정했기 때문에 막힌다.

3. 명세는 하네스가 되어야 한다

명세가 코드와 검증으로 이어지지 않으면 문서 창고가 된다. 좋은 명세는 에이전트와 사람이 같은 기준으로 움직이는 작업판이 된다.

L4 · 생산 보드

■ 이번 회차를 작업으로 바꾸기

• 새 기능을 시작하기 전에 사용자의 실제 행동 3가지를 적는다.
• 불가능해 보이는 제약 하나를 질문 형태로 바꾼다.
• 명세 문서에 검증 방법을 한 줄씩 붙인다.

프롬프트 템플릿

다음 개발 작업을 The Pragmatic Programmer의 관점으로 점검하라.
1. 이 작업에서 중복 지식, 숨은 결합, 불명확한 책임을 찾아라.
2. 사람이 기억해야 하는 절차와 자동화할 수 있는 절차를 나눠라.
3. 오늘 바로 적용할 작은 개선 3개를 제안하라.
4. AI 에이전트에게 맡기기 전에 필요한 검증 하니스를 정의하라.

L5 · 연결 & 복습

이 회차는 Clean Code의 가독성, Refactoring의 구조 개선, 그리고 지금 내 블로그의 LLM Wiki 실험과 연결된다. 차이는 분명하다. 이 책은 특정 기법보다 개발자가 어떤 기준으로 선택하고, 고치고, 설명할 것인가를 묻는다.

• 다른 책/아이디어와의 연결: Refactoring, Clean Code, LLM Wiki, Harness Engineering
• 미해결 질문: AI가 코드 대부분을 생성할 때, 실용주의 개발자의 책임은 어디로 이동하는가?
• 복습 일정: 1주 □ / 1개월 □ / 3개월 □
• 한 문장 최종 정리: 프로젝트 전의 좋은 질문은 프로젝트 중의 수많은 회의를 줄인다.

다음 회차

• 이전: 6회차
• 다음: 8회차
• 책장으로 돌아가기: /book