책노트: A Philosophy of Software Design 3장 - 정보 은닉은 결정을 숨기는 기술이다

A Philosophy of Software Design 3장 - 정보 은닉은 결정을 숨기는 기술이다

A Philosophy of Software Design는 설계를 거창한 아키텍처 선언보다 일상적인 복잡성 관리로 읽게 만든다. 이 3회차의 범위는 Chapter 5 Information Hiding (and Leakage), Chapter 6 General-Purpose Modules are Deeper이다. 원문을 길게 옮기기보다, 공개 글에서는 핵심 개념을 짧은 문구와 내 언어의 요약으로만 다룬다.

이번 글의 질문은 이것이다. 모듈은 무엇을 감춰야 깊어지는가?

■ 이 노트의 사용법

이 글은 10회로 읽는 A Philosophy of Software Design 시리즈의 3회차다. 범위는 Chapter 5 Information Hiding (and Leakage), Chapter 6 General-Purpose Modules are Deeper이다.

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

L0 · 서지 & 진입

• 한 문장 핵심: 정보 은닉은 코드를 숨기는 기술이 아니라 변경될 가능성이 높은 설계 결정을 감추는 기술이다.
• 이 책을 든 이유 / 기대한 질문: AI 도구와 자동화가 코드를 더 빨리 만들수록, 어떤 코드가 오래 이해되고 수정될 수 있는지 묻고 싶다.
• 읽기 전 가설: 캡슐화를 필드 접근 제한 정도로만 이해하면 모듈 경계를 잘못 그린다. 이 범위는 숨겨야 할 대상이 데이터가 아니라 결정이라는 점을 보여준다.
• 저자 한 줄 컨텍스트: John Ousterhout는 운영체제와 분산 시스템 연구, Tcl/Tk 개발, Stanford 강의를 통해 소프트웨어 설계 교육을 이어온 컴퓨터 과학자다.
• 이번 회차 범위: Chapter 5 Information Hiding (and Leakage), Chapter 6 General-Purpose Modules are Deeper
• 관련 도서 / 계보: The Pragmatic Programmer · Refactoring · Clean Code · Software Architecture

L1 · 포착함

“ 짧은 문구 · #design

“information hiding”

• 왜 표시했나: 변경될 결정을 모듈 내부로 밀어 넣는 원칙이다. ^q01
• 내 반응: 무엇이 바뀔지 묻지 않으면 무엇을 숨길지도 알 수 없다.

“ 짧은 문구 · #design

“information leakage”

• 왜 표시했나: 한 결정이 여러 모듈로 새어 나간 상태다. ^q02
• 내 반응: 누출은 수정 범위를 넓히고 테스트 범위를 흐린다.

“ 짧은 문구 · #design

“general-purpose”

• 왜 표시했나: 특정 호출자에 묶이지 않는 깊은 API를 지향한다. ^q03
• 내 반응: 범용성은 과한 추상화가 아니라 정보 은닉을 돕는 범위에서 유효하다.

■ 저작권 경계

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

L2 · 챕터 지도

#	범위	한 줄 요약	핵심 주장 1개	기억할 위치
1	정보 은닉	중요한 결정과 세부사항을 모듈 안으로 둔다	사용자는 덜 알아야 오래 쓸 수 있다	^q01
2	정보 누출	같은 지식이 여러 위치에 퍼진다	변경은 퍼진 지식의 수만큼 비싸진다	^q02
3	시간 순서 분해	작업 순서대로 클래스를 나누면 정보가 새기 쉽다	프로세스 단계는 좋은 모듈 경계가 아닐 수 있다	^q03
4	범용 API	조금 더 일반적인 인터페이스가 더 깊은 모듈을 만든다	호출자 특화 코드는 표면을 넓힌다
5	과한 일반화	상상 속 미래까지 미리 설계하면 복잡해진다	범용성도 현재 문제에서 검증되어야 한다

이번 회차 논증 한 단락:

정보 은닉은 코드를 숨기는 기술이 아니라 변경될 가능성이 높은 설계 결정을 감추는 기술이다. 캡슐화를 필드 접근 제한 정도로만 이해하면 모듈 경계를 잘못 그린다. 이 범위는 숨겨야 할 대상이 데이터가 아니라 결정이라는 점을 보여준다. 이 범위를 설계 실무에 적용하면, 코드 리뷰의 질문이 “작동하는가”에서 “다음 변경자가 무엇을 알아야 하는가”로 이동한다. 설계는 별도의 의식이 아니라 매일의 이름, 경계, 예외, 주석, 계층 선택 속에 들어 있다.

L3 · 인사이트 카드 색인

• A Philosophy of Software Design - I3.1 정보 은닉의 질문은 ‘무엇이 private인가’가 아니라 ‘무엇이 변할 결정인가’다
• A Philosophy of Software Design - I3.2 정보 누출은 중복 코드보다 더 조용한 중복 지식이다
• A Philosophy of Software Design - I3.3 좋은 범용성은 미래 예측이 아니라 현재 인터페이스 단순화에서 나온다

L4 · 생산 보드

■ 출력 파이프라인

• 블로그 초안: 3회차를 “정보 은닉은 결정을 숨기는 기술이다” 관점으로 정리
• 코드 리뷰 질문: 모듈은 무엇을 감춰야 깊어지는가?
• 인사이트 카드: 정보 은닉의 질문은 ‘무엇이 private인가’가 아니라 ‘무엇이 변할 결정인가’다
• 적용 실험: 최근 수정한 모듈 하나에 이 회차의 기준을 적용해 보기

L5 · 연결 & 복습

• 다른 책/아이디어와의 연결: Parnas의 모듈 분해 원칙과 직접 연결된다. 변할 수 있는 결정이 곧 모듈 경계의 후보가 된다.
• 미해결 질문:
  • 지금 내 코드베이스에서 이 회차의 레드플래그는 어디에 가장 뚜렷하게 보이는가?
  • AI 에이전트가 코드를 작성할 때 이 원칙을 검증 루프로 넣으려면 어떤 체크가 필요할까?
• 복습 일정: 1주 □ / 1개월 □ / 3개월 □
• 한 문장 최종 정리: 좋은 모듈은 코드를 감추는 벽이 아니라 변경 결정을 한곳에 모으는 작업대다.