책노트: A Philosophy of Software Design 2장 - 작동하는 코드만으로는 부족하다

A Philosophy of Software Design 2장 - 작동하는 코드만으로는 부족하다

A Philosophy of Software Design는 설계를 거창한 아키텍처 선언보다 일상적인 복잡성 관리로 읽게 만든다. 이 2회차의 범위는 Chapter 3 Working Code Isn’t Enough, Chapter 4 Modules Should Be Deep이다. 원문을 길게 옮기기보다, 공개 글에서는 핵심 개념을 짧은 문구와 내 언어의 요약으로만 다룬다.

이번 글의 질문은 이것이다. 오늘 빨리 끝내는 코드와 내일도 계속 이해되는 코드는 어디서 갈라지는가?

■ 이 노트의 사용법

이 글은 10회로 읽는 A Philosophy of Software Design 시리즈의 2회차다. 범위는 Chapter 3 Working Code Isn’t Enough, Chapter 4 Modules Should Be Deep이다.

포착 -> 증류 -> 연결 -> 표현 4단계 깔때기로 기술서를 흘려보낸다. 핵심 원칙은 같다. 책 노트는 창고, 인사이트 카드는 화폐.

L0 · 서지 & 진입

• 한 문장 핵심: 전략적 프로그래밍은 당장의 완료가 아니라 미래 변경 비용까지 설계 대상으로 삼는다.
• 이 책을 든 이유 / 기대한 질문: AI 도구와 자동화가 코드를 더 빨리 만들수록, 어떤 코드가 오래 이해되고 수정될 수 있는지 묻고 싶다.
• 읽기 전 가설: 실무에서는 작동 여부가 설계 판단을 압도하기 쉽다. 이 범위는 작동을 최소 조건으로 낮추고, 깊은 모듈을 장기 투자 단위로 본다.
• 저자 한 줄 컨텍스트: John Ousterhout는 운영체제와 분산 시스템 연구, Tcl/Tk 개발, Stanford 강의를 통해 소프트웨어 설계 교육을 이어온 컴퓨터 과학자다.
• 이번 회차 범위: Chapter 3 Working Code Isn’t Enough, Chapter 4 Modules Should Be Deep
• 관련 도서 / 계보: The Pragmatic Programmer · Refactoring · Clean Code · Software Architecture

L1 · 포착함

“ 짧은 문구 · #design

“tactical programming”

• 왜 표시했나: 눈앞의 문제 해결만 보는 습관을 가리킨다. ^q01
• 내 반응: 빠른 해결이 반복되면 구조가 느려진다.

“ 짧은 문구 · #design

“strategic programming”

• 왜 표시했나: 미래 변경 가능성을 비용으로 계산하는 태도다. ^q02
• 내 반응: 작은 설계 투자를 매번 넣는 습관이 필요하다.

“ 짧은 문구 · #design

“deep modules”

• 왜 표시했나: 단순한 인터페이스 뒤에 큰 기능을 숨기는 모듈이다. ^q03
• 내 반응: 클래스 수보다 인터페이스 대비 기능 밀도를 봐야 한다.

■ 저작권 경계

이 공개 노트는 책의 장문 문장을 재현하지 않는다. 장 제목과 짧은 핵심어만 단서로 삼고, 내용은 요약·해석·적용 중심으로 재구성한다.

L2 · 챕터 지도

#	범위	한 줄 요약	핵심 주장 1개	기억할 위치
1	전술적 프로그래밍	작동을 우선하지만 구조 비용을 뒤로 미룬다	완료 속도는 빨라도 변경 속도는 느려질 수 있다	^q01
2	전략적 프로그래밍	작은 설계 투자를 꾸준히 넣는다	설계는 큰 리라이트가 아니라 매일의 선택이다	^q02
3	모듈 인터페이스	사용자가 알아야 하는 표면을 줄인다	인터페이스가 단순할수록 사용자는 덜 기억한다	^q03
4	깊은 모듈	작은 인터페이스가 큰 기능을 제공한다	좋은 추상화는 내부 복잡성을 흡수한다
5	얕은 모듈	분리했지만 사용자의 부담은 줄이지 못한다	분할 자체가 설계 품질을 보장하지 않는다

이번 회차 논증 한 단락:

전략적 프로그래밍은 당장의 완료가 아니라 미래 변경 비용까지 설계 대상으로 삼는다. 실무에서는 작동 여부가 설계 판단을 압도하기 쉽다. 이 범위는 작동을 최소 조건으로 낮추고, 깊은 모듈을 장기 투자 단위로 본다. 이 범위를 설계 실무에 적용하면, 코드 리뷰의 질문이 “작동하는가”에서 “다음 변경자가 무엇을 알아야 하는가”로 이동한다. 설계는 별도의 의식이 아니라 매일의 이름, 경계, 예외, 주석, 계층 선택 속에 들어 있다.

L3 · 인사이트 카드 색인

• A Philosophy of Software Design - I2.1 작동은 설계의 끝이 아니라 검증 가능한 시작점이다
• A Philosophy of Software Design - I2.2 깊은 모듈은 구현량이 아니라 사용자의 기억 부담으로 평가된다
• A Philosophy of Software Design - I2.3 전략적 프로그래밍은 큰 결심보다 작은 반복 투자다

L4 · 생산 보드

■ 출력 파이프라인

• 블로그 초안: 2회차를 “작동하는 코드만으로는 부족하다” 관점으로 정리
• 코드 리뷰 질문: 오늘 빨리 끝내는 코드와 내일도 계속 이해되는 코드는 어디서 갈라지는가?
• 인사이트 카드: 작동은 설계의 끝이 아니라 검증 가능한 시작점이다
• 적용 실험: 최근 수정한 모듈 하나에 이 회차의 기준을 적용해 보기

L5 · 연결 & 복습

• 다른 책/아이디어와의 연결: YAGNI와 긴장 관계가 있다. 불필요한 일반화는 피하되, 미래 변경을 전혀 보지 않는 전술성도 피해야 한다.
• 미해결 질문:
  • 지금 내 코드베이스에서 이 회차의 레드플래그는 어디에 가장 뚜렷하게 보이는가?
  • AI 에이전트가 코드를 작성할 때 이 원칙을 검증 루프로 넣으려면 어떤 체크가 필요할까?
• 복습 일정: 1주 □ / 1개월 □ / 3개월 □
• 한 문장 최종 정리: 깊은 모듈은 많이 감춘 모듈이 아니라 적게 알게 해도 많이 해주는 모듈이다.