책노트: The Pragmatic Programmer 2회차 - 중복을 줄이고 바뀔 수 있게 만들기

The Pragmatic Programmer 2회차 - 중복을 줄이고 바뀔 수 있게 만들기

2장은 설계 기법 모음처럼 보이지만, 깊이 보면 하나의 질문으로 묶인다. 나중에 바뀔 수 있는 힘을 어디에 남겨둘 것인가.

■ 이 노트의 사용법

이 글은 The Pragmatic Programmer을 8회로 나눠 읽는 시리즈의 2회차다. 범위는 Chapter 2 · A Pragmatic Approach다.

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

L0 · 서지 & 진입

• 한 문장 핵심: 좋은 설계는 오늘의 답을 박제하지 않고, 내일의 변경권을 남겨둔다.
• 이 책을 든 이유 / 기대한 질문: AI가 코드를 빠르게 만들수록, 개발자가 지켜야 할 사고 습관과 운영 기준을 더 분명히 하고 싶었다.
• 읽기 전 가설: 이 책은 오래된 조언 모음일 것이라고 예상했다. 하지만 읽을수록 최신 도구보다 오래 가는 개발자의 운영 체계를 말하고 있었다.
• 저자 한 줄 컨텍스트: Andrew Hunt와 David Thomas는 소프트웨어 장인정신, 자동화, 실용주의 개발 문화에 큰 영향을 준 Pragmatic Bookshelf의 공동 창립자다.
• 이번 회차 범위: The Evils of Duplication, Orthogonality, Reversibility, Tracer Bullets, Prototypes and Post-it Notes, Domain Languages, Estimating
• 이번 회차 질문: 소프트웨어를 처음부터 완성하려 하지 않고, 어떻게 바뀔 수 있게 만들 것인가?

L1 · 포착함

■ 저작권 메모

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

• 이번 장은 Chapter 2 · A Pragmatic Approach를 통해 개발자의 태도와 작업 방식을 묻는다.
• 핵심은 “소프트웨어를 처음부터 완성하려 하지 않고, 어떻게 바뀔 수 있게 만들 것인가?”라는 질문으로 압축된다.
• 기억할 영어 표현: DRY · orthogonality · tracer bullets
• 내 블로그/PKM/에이전트 작업과 연결하면, 이 장은 “개인의 요령”보다 “반복 가능한 하니스”에 가깝다.

L2 · 챕터 지도

범위	내가 붙인 이름	핵심 질문
Chapter 2 · A Pragmatic Approach	중복을 줄이고 바뀔 수 있게 만들기	소프트웨어를 처음부터 완성하려 하지 않고, 어떻게 바뀔 수 있게 만들 것인가?

DRY는 복붙 금지 표어가 아니라 지식의 단일 출처를 지키는 원칙이다. 직교성은 한 부분의 변화가 다른 부분을 흔들지 않게 만드는 힘이고, 가역성은 미래 결정을 닫아버리지 않는 태도다. tracer bullets와 프로토타입은 불확실성을 말이 아니라 작동하는 피드백으로 줄인다.

L3 · 인사이트 카드 색인

• Pragmatic Programmer - I2.1 DRY는 중복 코드보다 중복 지식을 겨냥한다
• Pragmatic Programmer - I2.2 직교성은 AI 에이전트 하니스의 핵심이다
• Pragmatic Programmer - I2.3 Tracer bullet은 완성본이 아니라 방향 감각이다

1. DRY는 중복 코드보다 중복 지식을 겨냥한다

같은 코드가 두 번 있는 것보다 더 위험한 것은 같은 정책과 규칙이 여러 장소에서 서로 다르게 자라는 것이다.

2. 직교성은 AI 에이전트 하니스의 핵심이다

도구, 프롬프트, 데이터, 검증이 서로 엉켜 있으면 에이전트가 한 번 실패할 때 전체 루프가 무너진다. 나눌 수 있어야 고칠 수 있다.

3. Tracer bullet은 완성본이 아니라 방향 감각이다

끝까지 얇게 관통하는 작동 흐름은 계획서보다 빨리 현실을 드러낸다. 블로그 자동화도 작은 end-to-end 흐름부터 살아야 한다.

L4 · 생산 보드

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

• 현재 프로젝트에서 중복 지식이 숨어 있는 파일 2곳을 찾는다.
• 불확실한 기능은 프로토타입과 제품 코드를 분리한다.
• 다음 자동화는 tracer bullet처럼 입력부터 배포까지 얇게 먼저 뚫는다.

프롬프트 템플릿

다음 개발 작업을 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개월 □
• 한 문장 최종 정리: 좋은 설계는 오늘의 답을 박제하지 않고, 내일의 변경권을 남겨둔다.

다음 회차

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