정보은닉(Information Hiding)
1. 개요
가. 정의
모듈 내부의 구현 세부사항·데이터를 외부로부터 감추고, 잘 정의된 인터페이스만 공개하여 모듈 간 결합도를 낮추는 소프트웨어 설계 원리. D.L. Parnas가 1972년 논문에서 제안했다.
정보은닉의 출발점은 "무엇을 모듈 경계로 삼을 것인가"라는 질문이다. Parnas는 시스템을 처리 순서(플로차트)가 아니라 변경 가능성이 높은 결정(설계 비밀) 을 기준으로 나누라고 했다. 자주 바뀔 만한 부분(자료구조 표현, 알고리즘, 외부 규격 등)을 하나의 모듈 안에 가두고 그 결정을 "비밀"로 감추면, 그 비밀이 바뀌어도 다른 모듈이 영향을 받지 않는다. 즉 정보은닉은 단순한 접근 제한 기법이 아니라 변경의 파급을 국소화하기 위한 모듈 분해 전략이다.
나. 필요성
소프트웨어의 총비용은 개발보다 변경·유지보수에서 더 크게 발생하는데, 모듈들이 서로의 내부를 알고 의존하면 한 곳의 수정이 연쇄적으로 다른 곳을 깨뜨리는 파급 효과(Ripple Effect) 가 생긴다. 정보은닉은 각 모듈이 오직 공개된 인터페이스로만 상호작용하게 하여, 내부 구현이 바뀌어도 인터페이스만 유지되면 다른 모듈은 손대지 않아도 되게 만든다. 이로써 모듈의 독립성과 유지보수성이 오르고, 복잡한 내부를 감춤으로써 추상화가 실현된다.
2. 개념 구조
flowchart LR
C[호출 모듈] -->|공개 인터페이스| I[인터페이스<br/>공개]
I --> M[모듈 내부<br/>자료구조·알고리즘·상태<br/>은닉]
핵심은 인터페이스와 구현을 계약과 실행으로 분리하는 것이다. 호출하는 쪽은 그 모듈이 무엇(What) 을 보장하는지(인터페이스의 약속)만 알면 되고, 그것을 어떻게(How) 이루는지(내부 자료구조·알고리즘)는 알 필요도, 알아서도 안 된다. 예컨대 "정렬된 목록을 반환한다"는 계약만 공개하면, 내부에서 퀵정렬을 쓰든 병합정렬을 쓰든 호출자는 무관하다. 호출자가 내부 구현을 몰라야만 그 구현을 자유롭게 바꿀 수 있으므로, "모른다"는 것이 오히려 유연성의 원천이 된다.
3. 정보은닉과 캡슐화의 관계
두 개념은 자주 혼동되지만 층위가 다르다. 정보은닉은 "무엇을 왜 감출 것인가"를 정하는 설계 원리(목적) 이고, 캡슐화는 데이터와 그 데이터를 다루는 메서드를 하나로 묶는 구현 기법(수단) 이다. 캡슐화로 데이터를 객체 안에 묶고 private으로 접근을 제한함으로써 정보은닉이라는 목적이 실제로 실현된다. 즉 캡슐화 없이도 은닉을 논할 수 있지만(모듈 인터페이스 규약 등), 객체지향에서는 캡슐화가 은닉을 이루는 대표 수단이다. 목적과 수단의 관계로 이해하면 둘의 차이가 분명해진다.
| 구분 | 정보은닉 | 캡슐화 |
|---|---|---|
| 개념 | 구현 세부를 감추는 설계 원리(목적) | 데이터+메서드를 묶는 기법(수단) |
| 초점 | 접근 제한·비밀 은폐 | 결합(묶음) |
| 관계 | 캡슐화를 통해 실현됨 | 정보은닉을 지원하는 수단 |
| 구현 예 | private, 모듈 인터페이스 규약 |
클래스, 객체 |
4. 구현 기법과 관련 원칙
정보은닉은 여러 층위의 기법·원칙으로 구체화된다. 언어 차원에서는 접근제어자(private·protected)로 내부를 가리고, 인터페이스/추상클래스로 계약만 노출하고 구현을 분리한다. 설계 원칙으로는 객체가 낯선 객체의 내부까지 파고들지 않도록 하는 디미터 법칙, 확장에는 열려 있고 변경에는 닫히도록 하는 개방-폐쇄 원칙(OCP), 구체 구현이 아닌 추상에 의존하게 하는 의존성 역전(DIP) 이 모두 은닉과 맞닿아 있다. 이들은 결국 "변경 가능한 세부를 추상 뒤에 감춘다"는 하나의 지향을 공유한다.
| 구분 | 내용 |
|---|---|
| 접근제어자 | private·protected로 내부 은닉 |
| 인터페이스/추상클래스 | 계약만 노출, 구현 분리 |
| 관련 원칙 | 캡슐화·추상화, 디미터 법칙, OCP, DIP |
5. 장점 및 효과
정보은닉이 주는 효과들은 서로 연결되어 있다. 모듈이 인터페이스로만 소통하니 결합도가 낮아지고, 관련 기능·데이터가 한 모듈에 모이니 응집도가 높아진다. 결합도가 낮고 응집도가 높으면 한 모듈을 독립적으로 수정·교체할 수 있어 유지보수성이 오르고, 검증된 인터페이스를 여러 곳에서 재사용할 수 있다. 또 내부 데이터를 외부가 직접 건드리지 못하게 막으므로 잘못된 상태 변경을 방지하는 무결성·보안 효과까지 얻는다. 즉 하나의 원리가 품질 지표 여러 개를 동시에 개선한다.
| 효과 | 설명 |
|---|---|
| 낮은 결합도 | 모듈 간 의존 감소 → 독립 수정 |
| 높은 응집도 | 관련 기능이 모듈 내부에 집중 |
| 유지보수성 | 인터페이스 유지 시 내부 변경 무영향 |
| 재사용성·보안 | 검증된 인터페이스 재사용, 내부 데이터 보호 |
6. 고려사항 및 시사점
- 규모를 관통하는 원리: 클래스의
private부터 MSA의 서비스 경계, 개방형 API 설계까지 "구현을 감추고 계약만 노출"한다는 같은 원리가 관통한다. MSA에서 각 서비스가 DB를 직접 공유하지 않고 API로만 통신하는 것도 정보은닉의 확장이다. - 인터페이스 안정성이 곧 유연성: 인터페이스가 자주 바뀌면 은닉의 이점이 사라지므로, 인터페이스 우선 설계(API-first) 로 계약을 먼저 안정화하는 것이 중요하다.
- 과도한 은닉의 비용: 지나친 추상화 계층은 성능 오버헤드와 디버깅·추적의 어려움을 낳는다. 감출 가치가 있는 "변경 가능한 비밀"과 그렇지 않은 것을 구분해 적정 추상화 수준을 잡아야 한다.
한 줄 요약: 정보은닉은 변경 가능한 구현 세부를 감추고 인터페이스만 공개 하여 변경의 파급을 국소화하는 설계 원리로, 목적인 은닉을 수단인 캡슐화가 실현하며 결합도 저하·유지보수성 향상을 통해 MSA·API 설계의 기초가 된다.