Information Hiding — 14 원칙 산소의 마지막 한 조각
Parnas 1972 논문 On the Criteria to Be Used in Decomposing Systems into Modules. 54년 후에도 모든 SE 원칙의 root. paradigm-agnostic 명제라서 OOP·FP·microservices 모두 자기 방식으로 추구한다. overview의 철학적 root 3개 중 마지막. deep-modules의 더 깊은 root이자, simple-not-easy의 얽힘 제거가 module 단위에서 어떻게 작동하는지의 답.
한 줄
시스템을 module로 나눌 때 기준은 "어떤 design decision을 감출 수 있는가". 변할 가능성이 있는 결정마다 module로 격리하면, 그 결정이 변해도 외부에 영향이 없다. 1972년 Parnas가 step별 decomposition(당시 통념)을 거부하고 secret별 decomposition을 제안한 게 시작. 모든 후속 SE 원칙(encapsulation, ADT, deep modules, microservices, anti-corruption layer)이 이 명제의 paradigm별 응용.
⚛️ 철학
원칙의 왜. 더 깊은 root와의 연결.
1972 — Parnas의 발견
David Parnas의 1972년 논문 On the Criteria to Be Used in Decomposing Systems into Modules는 module 경계를 어떻게 그어야 하는가에 대한 질문에 답을 줬다. 1960s까지의 통념:
Flowchart의 step별로 module을 나눠라. input → process A → process B → output.
Parnas의 반박은 단순하지만 폭발적이었음:
Module 경계는 step이 아니라 "감춰야 할 secret" 별로 그어야 한다. 각 module은 변할 가능성이 있는 design decision 하나를 감춘다.
논문의 KWIC 인덱스 시스템 비교가 결정적 사례:
Input format이 바뀌면:
- A: 4개 module 모두 수정 — input을 모든 step이 직접 처리하기 때문
- B: Input format 1개 module만 수정 — 나머지 module은 변화를 모름
이 한 사례로 변화에 강한 시스템의 mechanism이 정의됨. 시스템의 진화 비용을 결정하는 것은 module의 수가 아니라 module의 secret.
핵심 명제
Information hiding의 한 줄 정의:
Module은 자기가 감추는 secret으로 정의된다. module의 가치는 얼마나 많은 functionality를 제공하는가가 아니라 얼마나 많은 변화를 흡수할 수 있는가.
이게 deep-modules의 더 깊은 root. Ousterhout의 deep module은 Parnas의 information hiding을 measurable하게 만든 것:
- Parnas 1972: secret을 감춰라 (질적 명제)
- Ousterhout 2018: interface는 좁게, implementation은 깊게 (양적 명제)
같은 정신, 다른 시대의 표현.
Paradigm-agnostic 본질
이 명제가 강력한 이유는 paradigm을 가리지 않음. 모든 후속 SE 사상이 information hiding을 자기 방식으로 구현:
| Paradigm | Information hiding의 표현 |
|---|---|
| Modular programming (Parnas 자체) | module + interface |
| Abstract Data Types (Liskov 1974) | type + operations, representation 감춤 |
| OOP (Smalltalk → Java) | class + private fields + public methods |
| Functional (ML, Haskell, Clojure) | module + closure + opaque type |
| Microservices | service boundary + API |
| Deep Modules (Ousterhout) | small interface + deep implementation |
| Anti-Corruption Layer (DDD) | 외부 시스템의 변화를 감춤 |
→ Information hiding은 14 원칙의 산소이자 paradigm 다양성의 root. OOP가 encapsulation을 약속했지만, simple-not-easy#대안 흐름에서 본 것처럼 OOP만이 답은 아님. Parnas의 명제는 paradigm을 가리지 않는다.
다른 root와의 연결
- simple-not-easy — Hickey의 complect 제거가 secret 격리와 동형. 얽힘이 없는 module = secret이 깔끔히 격리된 module
- strategic-vs-tactical-programming — 어떤 secret을 감출지 결정이 strategic 활동의 가장 직접적 형태. tactical은 secret을 무시하고 step별 decomposition으로 빠짐
- anti-corruption-layer — 외부 시스템의 변화라는 secret을 감추는 module-system-단위 표현
- deep-modules — Information hiding의 measurable 표현
🧱 추상적 작동 구조
Module의 내부와 외부:
핵심: 변화의 blast radius가 module 안에 갇힘. 외부는 변화를 느끼지 못함. 이게 deep-modules 노트의 추상화의 가치 공식과 직접 만남:
Module의 가치 = (감춘 complexity) - (노출한 complexity) = (감춘 secret) - (interface로 노출한 가정)
Secret의 종류 (Parnas 분류)
Parnas가 후속 논문에서 정리한 어떤 것이 secret이 될 수 있는가:
| Secret 종류 | 예시 |
|---|---|
| Data representation | linked list vs array vs tree |
| Algorithm | quicksort vs mergesort vs heapsort |
| External system format | JSON vs XML vs Protobuf |
| Hardware specifics | x86 vs ARM, 32bit vs 64bit |
| Vendor choice | OpenAI vs Anthropic vs local model |
| Concurrency model | thread vs async vs actor |
| Persistence | filesystem vs DB vs S3 |
| Time | UTC vs local, monotonic vs wall clock |
→ 변할 수 있는 모든 결정이 secret 후보. 어떤 결정을 secret으로 만들지가 architect의 strategic 판단.
변화의 격리 — 시간 그래프
→ Interface가 안정하면 secret은 자유롭게 진화. 이게 reversibility의 module-단위 표현. 결정을 되돌리는 비용을 0에 가깝게 만드는 mechanism.
⚠️ 약점/한계
원칙의 적용 한계. 잘못 적용 시 함정.
1. 어떤 decision이 변할지 예측 어려움
Parnas 명제의 가장 큰 약점. 변할 가능성이 있는 결정을 알아야 secret으로 만들 수 있는데, 미래 예측은 항상 일부 틀린다. 잘못 예측하면:
- 변할 줄 알았는데 안 변함 → over-engineering (낭비된 indirection)
- 안 변할 줄 알았는데 변함 → under-engineering (전체 수정)
해결: Strategic 사고로 "변화 압력"을 측정. 외부 시스템과 만나는 자리는 항상 변할 가능성. 도메인 핵심은 덜 변함. 외부 ↔ 내부 경계가 우선 격리.
2. Over-encapsulation → 추상화 비용 폭발
모든 결정을 secret으로 만들면 interface 학습 곡선 + indirection layer가 비대해짐. 시스템이 원리적으로는 simple하지만 실제 사용은 hard. AbstractFactoryFactoryBuilder 함정.
해결: Deep module과 함께 적용 (작은 interface + 풍부한 내부). 작은 module 100개로 secret을 흩뿌리지 말고 cohesive한 module 5개로 모음.
3. 추상화 Leak (Spolsky's Law)
Joel Spolsky의 Law of Leaky Abstractions: 모든 non-trivial 추상화는 어느 정도 leak한다. Secret을 감췄어도, 성능·에러·timing 같은 측면에서 외부가 secret을 느끼게 됨.
예시:
- TCP가 reliable byte stream이라는 추상화를 제공하지만, latency·packet loss는 leak
- ORM이 DB를 감춤이라 약속하지만, 쿼리 성능 문제는 leak (N+1 등)
- LLM Provider trait가 vendor 차이 감춤이라 해도, rate limit·latency 차이는 leak
해결: Leak을 인정하고 interface에 명시적으로 노출. Result type (성공/실패) + retry policy + timeout 같은 게 leak을 명시적 contract로. 감추지 않고 예측 가능한 leak으로.
4. 디버깅 어려움
Secret이 깊으면 trace가 어려움. 왜 이 결과가 나왔는가를 추적하려면 internal을 봐야 하는데, internal은 hidden. observability·logging이 information hiding의 동반 도구가 되어야 함.
해결: Internal seam 정의. unit test로 internal 행동을 검증할 수 있는 내부 경계. 사용자 외부에는 hidden, 디버거·테스트에게는 visible.
5. 조직 차원의 지식 손실
Secret이 사람의 머릿속에만 있으면 그 사람 떠날 때 손실. Tribal knowledge. 이게 Ian Bull의 Memento metaphor의 root — AI agent에게는 모든 사람이 어제 떠난 사람.
해결: Secret을 ADR로 박기. 왜 이 secret을 감췄는가, 어떻게 결정했는가를 기록. AI 시대에 ADR은 secret을 AI가 읽을 수 있게 하는 도구.
6. Open Source / Build in the Open 흐름과 충돌
일부 모던 회사 (Plain, Linear, Cloudflare 등)는 design decision을 공개. Information hiding의 secret과 정반대. 이유: trust 구축, 커뮤니티 참여.
이건 진정한 충돌이 아님. Information hiding의 secret은 interface 사용자에게 감춤이지 source code 비공개가 아님. Open source여도 module 사용자는 interface만 보고 사용. 단, 시각적 노출이 늘면 내부 결정에 사용자가 의존하기 시작 → leak 가능성 증가.
🔄 대안 흐름
이 원칙이 적용 안 되는 시나리오와 다른 답.
대안 1 — Open Design (Saltzer & Schroeder 1975, 보안)
"The design should not be secret. The mechanisms should not depend on the ignorance of potential attackers."
보안 측면에서는 감추는 것보다 open으로 검증이 강하다. Kerckhoffs's principle: 암호 알고리즘은 공개되어도 안전해야. 보안에서 security through obscurity는 anti-pattern.
→ Parnas와 영역이 다름. Parnas의 secret은 변화 흡수용. Saltzer-Schroeder의 open은 공격 방어용. 둘 다 같이 적용 가능 (코드는 open, design decision은 module로 격리).
대안 2 — YAGNI — 미리 격리하지 말기
XP 명제. 변할지 모르는 것을 미리 module로 격리하지 말고, 변할 때 격리. Parnas 명제의 예측 의존성 약점에 대한 답.
→ 합쳐서 적용 가능. 명백히 변할 자리(외부 시스템 경계, vendor)는 격리. 모호한 자리는 YAGNI로 두고 증거가 쌓이면 격리.
대안 3 — Naked Objects / Anemic Domain Model
데이터를 그대로 노출. behavior를 분리해서 service에 둠. Information hiding 반대 방향.
→ DDD 진영에서 anti-pattern으로 비판 (Vernon, Fowler). 단, 작은 시스템 / 도메인 행동이 단순할 때는 정당. CRUD UI에서는 합리.
대안 4 — Microservices — 시스템 단위 hiding
Module 단위가 아닌 service 단위로 information hiding. 각 service가 internal model을 감추고 API로 통신. Parnas의 명제가 아키텍처 단위로 확장.
→ Parnas 명제와 직접 정렬. Microservices는 information hiding의 시스템 단위 표현. 단, 추가 비용 (network, eventual consistency 등) 발생.
대안 5 — Event Sourcing / CQRS
State를 event log로 저장. Read model과 Write model 분리. Information hiding 대신 데이터 흐름의 명시화.
→ Parnas 명제와 직교적. Event sourcing 안에서도 각 event handler가 secret을 감출 수 있음.
💡 인사이트
AI 시대 왜 지금 부활하는가 + 학내 segment 의미.
1. AI agent에게 interface는 진실, secret은 거짓
sources/key-articles-summary#5. Ian Bull — *Sinks, Not Pipes*|Ian Bull의 핵심 명제:
If your architecture is lying — if the interfaces don't tell the truth about what the modules do, if there are hidden couplings and undocumented side effects — then the AI will produce code that looks correct locally but breaks things.
AI agent는 interface를 face value로 받음. 사람은 tribal knowledge로 secret을 알아내지만 AI는 interface가 contract의 전부. 따라서:
- Information hiding이 잘 되어 있으면 AI에게 친화적 — interface만 보고 작동
- Hidden coupling이 있으면 AI fail — interface가 거짓말하기 때문
→ Parnas 1972 명제가 AI 시대에 더 강하게 작동. Architecture is the prompt (Bull)는 information hiding의 AI 시대 표현.
2. Architecture as documentation — AI 친화적 설계
전통적으로 design decision은 사람의 머릿속에 있었음. AI 시대에는 그 secret이 명시적이어야 AI가 사용 가능:
- ADR (Architecture Decision Records) — 왜 이 secret을 감췄는가를 기록
- AGENTS.md — AI에게 secret 사용법 안내
- SKILL.md frontmatter — skill의 secret과 contract 명시
→ Information hiding의 secret을 "사람 머릿속"에서 "machine readable spec"으로 옮김. 이게 research/stateless-llm-sdk/design-principles|7 원칙의 도구화 mechanism.
3. v1.0 design 직접 적용
| Layer | Interface | Secret (감춘 것) |
|---|---|---|
Provider trait | stream, complete, name, model_config | vendor별 quirk, retry, cache, rate limit, auth method |
SKILL.md frontmatter | name, description, owner, success_criteria | skill body의 동작, tool 호출, prompt 구성 |
| Agent loop | run(prompt) -> Result | turn 수, tool dispatch, context compaction, failure mode |
| 학내 통합 모듈 | "수강신청 가능 과목 조회" | 학사 시스템 API, 인증, 시간표 충돌, 졸업요건 lookup |
→ 모든 layer가 information hiding의 직접 응용. v1.0의 정체성이 정확히 Parnas 1972 명제의 도구화.
4. 학내 segment에서 학내 시스템 변화 흡수
학내 시스템은 학기마다 개편되는 게 정상:
- 학사 시스템 UI/API 변경
- 인증 시스템 (SSO 변경, 다중 인증 도입 등)
- 학칙 변경 (수강 제한, 시간표 규칙)
- 정책 변경 (등록금, 장학)
학내 통합 모듈을 information hiding으로 격리하면:
- 학사 시스템 변경 → 통합 module 1개만 수정. 학생 도구 100개는 그대로
- 인증 변경 → 인증 module만 수정
- 학칙 변경 → 정책 module만 수정
→ 학내 segment에서 information hiding은 가장 실용적인 가치. 격리 안 하면 학기마다 모든 도구를 수정해야 함.
5. 54년의 시간 검증 — Parnas 명제가 변하지 않는 이유
1972년 논문이 2026년에도 그대로 적용 가능한 이유:
- 명제 자체가 변화 흡수에 관한 것. 시대가 변해도 변화는 보편
- Paradigm-agnostic 본질 — 새 paradigm이 등장해도 그 paradigm에 맞는 응용으로 살아남음
- AI 시대에는 오히려 더 강하게 작동 (인사이트 1, 2)
→ overview에서 정리한 왜 지금 부활하는가의 가장 강력한 사례. 부활이 아니라 한 번도 멈춘 적이 없는 명제. 단, 그 명제의 적용 비용이 AI 시대에 급감 → 채택 가속.
6. OOP의 진정한 약속 — Parnas 명제의 OOP 응용
곁가지 대화에서 발견한 흐름의 정확한 이론적 명제:
OOP가 약속한 것은 information hiding의 OOP 표현 (private fields + public methods) 그러나 OOP가 추가한 상속·mutable state·class hierarchy는 information hiding과 충돌
OOP의 진짜 가치는 information hiding 부분만. Hickey가 OOP를 비판한 자리도 상속·mutable state. Encapsulation 자체는 Hickey도 옹호.
따라서 modern multi-paradigm 언어들의 흐름:
- 상속 X (Go, Rust, Zig, Clojure, Elixir)
- mutable state 통제 (Rust ownership, Clojure immutable default)
- Encapsulation/information hiding 유지 (struct + module + visibility modifier)
→ Information hiding은 paradigm 다양성을 가로지르는 universal value. 이게 곁가지 대화에서 사용자가 직관적으로 짚은 encapsulation은 좋은 부분의 정확한 이론적 표현.
7. 학내 segment에 가르칠 핵심 한 줄
학생에게 module을 가르칠 때 한 줄 명제:
Module은 자기가 감추는 것으로 정의된다. 무엇을 노출하느냐가 아니라 무엇을 감추느냐가 중요하다.
이 한 줄이 OOP·FP·microservices·DDD 모두를 통합 framework로 본다는 뜻. 학생이 Java 상속을 외우는 대신 내가 무슨 secret을 감추고 있는가를 묻기 시작하면 paradigm-free 사고로 진입. AI 시대에 가장 가치 있는 멘탈 모델.
다음에 가야 할 자리
이 노트가 호출한 다른 원칙들 — 자연스러운 다음 노트:
- information-leak-vs-abstraction — Spolsky의 leak이 information hiding의 자기 점검 도구
- anti-corruption-layer — Information hiding의 시스템 단위 응용
- ubiquitous-language — vocabulary 수준의 information hiding (외부 vocabulary 감추기)
- orthogonality — Information hiding이 잘 되면 layer가 orthogonal해진다
→ 이로써 overview의 ⚛️ 철학적 root 3개 모두 완성. Module 축의 information-leak-vs-abstraction이 다음으로 자연스럽거나, Domain 축의 ubiquitous-language로 이동도 자연스러움.
관련
- overview
- deep-modules — Information hiding의 measurable 표현. Parnas 1972의 Ousterhout 2018 진화
- simple-not-easy — complect 제거가 secret 격리와 동형
- strategic-vs-tactical-programming — 어떤 secret을 감출지 결정이 strategic 활동의 가장 직접적 형태
- research/stateless-llm-sdk/design-principles|design-principles — 7 원칙 모두가 이 명제의 응용
- sources/key-articles-summary|key-articles-summary — Ian Bull Sinks Not Pipes가 정확히 information hiding의 AI 시대 표현
Sources
직접 source
- Parnas, D.L. (1972). On the Criteria to Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12). — 무료 PDF: https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf
- Parnas의 후속 논문들 (1976 Family of Programs, 1985 Software Aging) — 같은 정신의 확장
Information Hiding의 후속 응용
- Liskov, B. (1974). Programming with Abstract Data Types. — ADT가 정보 hiding의 type-theoretic 표현
- Spolsky, J. (2002). The Law of Leaky Abstractions. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ — 약점 3 (leak)의 가장 명료한 글
- Saltzer, J.H. & Schroeder, M.D. (1975). The Protection of Information in Computer Systems. — Open Design (대안 1)의 root
같은 정신의 modern 표현
- A Philosophy of Software Design — John Ousterhout (2018). Deep modules가 information hiding의 measurable 표현
- Domain-Driven Design — Eric Evans (2003). Anti-Corruption Layer가 시스템 단위 표현
- Sinks, Not Pipes — Ian Bull https://ianbull.com/posts/software-architecture/ — AI 시대 표현 (Architecture is the prompt)
Hickey의 functional 측 표현
- Simple Made Easy — Rich Hickey (2011, InfoQ). complect 제거 = secret 격리
- Clojure 자체가 information hiding의 functional 응용 (protocols + immutable data + namespace)