책노트: A Philosophy of Software Design 5장 - 경계와 오류도 설계할 수 있다

A Philosophy of Software Design 5장 - 경계와 오류도 설계할 수 있다

A Philosophy of Software Design는 설계를 거창한 아키텍처 선언보다 일상적인 복잡성 관리로 읽게 만든다. 이 5회차의 범위는 Chapter 9 Better Together Or Better Apart?, Chapter 10 Define Errors Out Of Existence이다. 원문을 길게 옮기기보다, 공개 글에서는 핵심 개념을 짧은 문구와 내 언어의 요약으로만 다룬다.

이번 글의 질문은 이것이다. 좋은 경계는 어디서 나누고 어디서 합치는가?

■ 이 노트의 사용법

이 글은 10회로 읽는 A Philosophy of Software Design 시리즈의 5회차다. 범위는 Chapter 9 Better Together Or Better Apart?, Chapter 10 Define Errors Out Of Existence이다.

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

L0 · 서지 & 진입

• 한 문장 핵심: 모듈 경계와 예외 처리는 모두 사용자가 알아야 할 경우의 수를 줄이는 방향으로 설계되어야 한다.
• 이 책을 든 이유 / 기대한 질문: AI 도구와 자동화가 코드를 더 빨리 만들수록, 어떤 코드가 오래 이해되고 수정될 수 있는지 묻고 싶다.
• 읽기 전 가설: 분리와 예외 처리는 보통 별개의 주제로 보인다. 이 범위에서는 둘 다 인터페이스가 사용자에게 노출하는 경우의 수 문제로 읽힌다.
• 저자 한 줄 컨텍스트: John Ousterhout는 운영체제와 분산 시스템 연구, Tcl/Tk 개발, Stanford 강의를 통해 소프트웨어 설계 교육을 이어온 컴퓨터 과학자다.
• 이번 회차 범위: Chapter 9 Better Together Or Better Apart?, Chapter 10 Define Errors Out Of Existence
• 관련 도서 / 계보: The Pragmatic Programmer · Refactoring · Clean Code · Software Architecture

L1 · 포착함

“ 짧은 문구 · #design

“better together”

• 왜 표시했나: 공유 정보가 많으면 함께 두는 편이 단순할 수 있다. ^q01
• 내 반응: 분리 원칙도 맥락 없이 적용하면 복잡성을 만든다.

“ 짧은 문구 · #design

“define errors out of existence”

• 왜 표시했나: 오류 처리 코드를 늘리기보다 오류 상태 자체를 설계에서 제거한다. ^q02
• 내 반응: 예외를 잡는 것보다 예외가 덜 생기게 만드는 편이 깊다.

“ 짧은 문구 · #design

“special cases”

• 왜 표시했나: 특별한 경우가 인터페이스를 넓히는 지점을 가리킨다. ^q03
• 내 반응: 특수 사례를 일반 규칙으로 흡수할 수 있는지 먼저 봐야 한다.

■ 저작권 경계

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

L2 · 챕터 지도

#	범위	한 줄 요약	핵심 주장 1개	기억할 위치
1	함께 두기	공유 지식이 많거나 인터페이스가 단순해질 때 합친다	분리는 정보 이동 비용을 만든다	^q01
2	나누기	범용 코드와 특수 코드를 분리하면 재사용성이 살아난다	모든 결합이 나쁜 것은 아니고 모든 분리가 좋은 것도 아니다	^q02
3	중복 제거	분할이 중복을 만들면 다시 합칠 신호다	중복은 경계가 잘못 그어진 증상일 수 있다	^q03
4	예외 복잡성	예외는 정상 흐름 밖의 경로를 늘린다	오류 처리는 인터페이스의 표면적이다
5	오류 제거	불가능한 상태를 만들면 처리 코드가 줄어든다	설계가 검사를 대신할 수 있다

이번 회차 논증 한 단락:

모듈 경계와 예외 처리는 모두 사용자가 알아야 할 경우의 수를 줄이는 방향으로 설계되어야 한다. 분리와 예외 처리는 보통 별개의 주제로 보인다. 이 범위에서는 둘 다 인터페이스가 사용자에게 노출하는 경우의 수 문제로 읽힌다. 이 범위를 설계 실무에 적용하면, 코드 리뷰의 질문이 “작동하는가”에서 “다음 변경자가 무엇을 알아야 하는가”로 이동한다. 설계는 별도의 의식이 아니라 매일의 이름, 경계, 예외, 주석, 계층 선택 속에 들어 있다.

L3 · 인사이트 카드 색인

• A Philosophy of Software Design - I5.1 모듈 경계는 객체 수가 아니라 공유 지식의 흐름으로 결정된다
• A Philosophy of Software Design - I5.2 예외 처리는 실패 대응 이전에 인터페이스 표면적의 문제다
• A Philosophy of Software Design - I5.3 특수 사례를 줄이는 설계는 호출자의 머릿속 분기를 줄인다

L4 · 생산 보드

■ 출력 파이프라인

• 블로그 초안: 5회차를 “경계와 오류도 설계할 수 있다” 관점으로 정리
• 코드 리뷰 질문: 좋은 경계는 어디서 나누고 어디서 합치는가?
• 인사이트 카드: 모듈 경계는 객체 수가 아니라 공유 지식의 흐름으로 결정된다
• 적용 실험: 최근 수정한 모듈 하나에 이 회차의 기준을 적용해 보기

L5 · 연결 & 복습

• 다른 책/아이디어와의 연결: 도메인 모델링과 연결된다. 불가능한 상태를 타입과 모델에서 표현하지 않는 방식은 오류를 사후 처리에서 사전 설계로 옮긴다.
• 미해결 질문:
  • 지금 내 코드베이스에서 이 회차의 레드플래그는 어디에 가장 뚜렷하게 보이는가?
  • AI 에이전트가 코드를 작성할 때 이 원칙을 검증 루프로 넣으려면 어떤 체크가 필요할까?
• 복습 일정: 1주 □ / 1개월 □ / 3개월 □
• 한 문장 최종 정리: 좋은 경계는 코드를 예쁘게 나누는 선이 아니라 사용자의 경우의 수를 줄이는 장치다.