책노트: A Philosophy of Software Design 1장 - 복잡성은 설계의 부채다

A Philosophy of Software Design 1장 - 복잡성은 설계의 부채다

A Philosophy of Software Design는 설계를 거창한 아키텍처 선언보다 일상적인 복잡성 관리로 읽게 만든다. 이 1회차의 범위는 Preface, Chapter 1 Introduction, Chapter 2 The Nature of Complexity이다. 원문을 길게 옮기기보다, 공개 글에서는 핵심 개념을 짧은 문구와 내 언어의 요약으로만 다룬다.

이번 글의 질문은 이것이다. 좋은 설계는 무엇을 더 많이 추가하는 기술이 아니라 무엇을 줄이는 기술인가?

■ 이 노트의 사용법

이 글은 10회로 읽는 A Philosophy of Software Design 시리즈의 1회차다. 범위는 Preface, Chapter 1 Introduction, Chapter 2 The Nature of Complexity이다.

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

L0 · 서지 & 진입

• 한 문장 핵심: 좋은 설계의 첫 기준은 멋진 구조가 아니라 복잡성을 줄이는 힘이다.
• 이 책을 든 이유 / 기대한 질문: AI 도구와 자동화가 코드를 더 빨리 만들수록, 어떤 코드가 오래 이해되고 수정될 수 있는지 묻고 싶다.
• 읽기 전 가설: 설계는 아키텍처 다이어그램이나 패턴 선택의 문제라고 생각하기 쉽다. 이 범위는 그보다 먼저, 개발자의 머릿속 부담을 줄이는 문제로 설계를 다시 정의한다.
• 저자 한 줄 컨텍스트: John Ousterhout는 운영체제와 분산 시스템 연구, Tcl/Tk 개발, Stanford 강의를 통해 소프트웨어 설계 교육을 이어온 컴퓨터 과학자다.
• 이번 회차 범위: Preface, Chapter 1 Introduction, Chapter 2 The Nature of Complexity
• 관련 도서 / 계보: The Pragmatic Programmer · Refactoring · Clean Code · Software Architecture

L1 · 포착함

“ 짧은 문구 · #design

“complexity”

• 왜 표시했나: 이 책이 계속 싸우는 상대의 이름이다. ^q01
• 내 반응: 복잡성을 비용이 아니라 감각의 문제로만 다루면 개선 방향을 놓친다.

“ 짧은 문구 · #design

“change amplification”

• 왜 표시했나: 작은 변경이 많은 수정으로 번지는 증상을 붙잡는다. ^q02
• 내 반응: 내 코드에서도 변경이 어디까지 번지는지 먼저 봐야 한다.

“ 짧은 문구 · #design

“cognitive load”

• 왜 표시했나: 설계 품질을 읽는 사람의 머릿속 부담으로 측정하게 한다. ^q03
• 내 반응: 좋은 코드는 실행만 되는 코드가 아니라 이해 비용이 낮은 코드다.

■ 저작권 경계

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

L2 · 챕터 지도

#	범위	한 줄 요약	핵심 주장 1개	기억할 위치
1	도입	소프트웨어 설계의 핵심 문제를 복잡성으로 놓는다	설계는 개발자의 장기 생산성을 다룬다	^q01
2	복잡성 정의	복잡성은 이해와 수정이 어려워지는 상태다	복잡성은 코드량보다 인지 부담에 가깝다	^q02
3	증상	변경 증폭, 인지 부하, 알 수 없는 미지수가 나타난다	증상을 이름 붙이면 리팩터링 방향이 생긴다	^q03
4	원인	의존성과 모호함이 복잡성을 키운다	의존성은 연결 자체보다 숨겨진 연결이 위험하다

이번 회차 논증 한 단락:

좋은 설계의 첫 기준은 멋진 구조가 아니라 복잡성을 줄이는 힘이다. 설계는 아키텍처 다이어그램이나 패턴 선택의 문제라고 생각하기 쉽다. 이 범위는 그보다 먼저, 개발자의 머릿속 부담을 줄이는 문제로 설계를 다시 정의한다. 이 범위를 설계 실무에 적용하면, 코드 리뷰의 질문이 “작동하는가”에서 “다음 변경자가 무엇을 알아야 하는가”로 이동한다. 설계는 별도의 의식이 아니라 매일의 이름, 경계, 예외, 주석, 계층 선택 속에 들어 있다.

L3 · 인사이트 카드 색인

• A Philosophy of Software Design - I1.1 설계의 첫 언어는 아름다움이 아니라 복잡성의 증상이다
• A Philosophy of Software Design - I1.2 변경 증폭은 코드베이스가 보내는 조기 경보 신호다
• A Philosophy of Software Design - I1.3 인지 부하는 개인 능력 문제가 아니라 시스템 설계 문제다

L4 · 생산 보드

■ 출력 파이프라인

• 블로그 초안: 1회차를 “복잡성은 설계의 부채다” 관점으로 정리
• 코드 리뷰 질문: 좋은 설계는 무엇을 더 많이 추가하는 기술이 아니라 무엇을 줄이는 기술인가?
• 인사이트 카드: 설계의 첫 언어는 아름다움이 아니라 복잡성의 증상이다
• 적용 실험: 최근 수정한 모듈 하나에 이 회차의 기준을 적용해 보기

L5 · 연결 & 복습

• 다른 책/아이디어와의 연결: 이 범위는 프래그매틱 프로그래머의 책임 윤리와 이어진다. 다만 초점은 태도보다 구조다.
• 미해결 질문:
  • 지금 내 코드베이스에서 이 회차의 레드플래그는 어디에 가장 뚜렷하게 보이는가?
  • AI 에이전트가 코드를 작성할 때 이 원칙을 검증 루프로 넣으려면 어떤 체크가 필요할까?
• 복습 일정: 1주 □ / 1개월 □ / 3개월 □
• 한 문장 최종 정리: 설계는 코드를 멋지게 꾸미는 일이 아니라 다음 사람이 덜 헤매게 만드는 일이다.