http://m.egloos.zum.com/aeternum/v/1232020
소프트웨어 설계 시에 고려해야 할 기본 원리 중 가장 중요한 원리가 무엇이냐고 물어 본다면 주저 없이 ‘정보 은닉(Information Hiding)’이라고 대답할 것이다. 정보 은닉(또는 정보 은폐라고도 한다)은1972년 Davis Parnas가 발표한 “On the Criteria To Be Used in Decomposing Systems Into Modules”에 소개된 이후로 오랜 세월 동안 소프트웨어 개발 분야에 지대한 영향을 끼친 원리이다. 그러나 이런 중요성에도 불구하고 정보 은닉의 개념을 정확하게 이해하고 있는 사람은 많지 않다. 소프트웨어 개발 분야에서 가장 큰 영향력을 지닌 동시에 가장 큰 오해를 받고 있는 두 가지 원리가 있다면 바로 정보 은닉과 캡슐화(Encapsulation)일 것이다.
대부분의 사람들은 외부에서 제공된 공용 메소드를 통해서만 내부 데이터에 접근할 수 있도록 하고 직접적으로 내부 데이터에 접근할 수 없도록 막는 방법을 정보 은닉이라고 알고 있다. 이것은 정보 은닉과 데이터 캡슐화라는 두 용어 간의 유사성으로 인해 빚어진 오해이다. 데이터를 공용 메소드를 통해서만 접근하도록 허용하는 방법을 데이터 캡슐화라고 하며 정보 은닉과 데이터 캡슐화는 동일한 개념이 아니다.
간단하게 말하자면 정보 은닉은 모듈을 분할하기 위한 기본 원리다.
모듈은 서브 프로그램이라기 보다는 책임의 할당이다. 모듈화는 개별적인 모듈에 대한 작업이 시작되기 전에 정해져야 하는 설계 결정들을 포함한다. … 분할된 모듈은 다른 모듈에 대해 감추어야 하는 설계 결정에 따라 특징지어 진다. 해당 모듈 내부의 작업을 가능한 적게 노출하는 인터페이스 또는 정의를 선택한다. … 어려운 설계 결정이나 변화할 것 같은 설계 결정들의 목록을 사용해서 설계를 시작할 것을 추천한다. 이러한 결정이 외부 모듈에 대해 숨겨지도록 각 모듈을 설계해야 한다.
정보 은닉은 외부에 감추어야 하는 비밀에 따라 시스템을 분할하는 모듈 분할의 원리이다. 모듈은 변경될 가능성이 있는 비밀을 내부로 감추고 잘 정의되고 쉽게 변경되지 않을 공용 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 한다.
시스템의 모듈을 분할하기 위한 설계 원리인 정보 은닉은 변경 가능한 측면을 추상화하는 인터페이스를 사용하여 변경에 대한 세부 내용을 캡슐화하거나 감추고 사용자(이 경우 다른 시스템 모듈 내의 소프트웨어)에게 일반적이고 통합된 서비스 집합을 제공한다. 이것은 각 모듈이 자신만의 작은 도메인(small domain)으로 구성되어 있음을 의미한다. 여기에서는 특별한 지식 영역 또는 전문적인 식견을 의미하기 위해 도메인(domain)이라는 용어를 사용한다.
정보 은닉은 데이터 캡슐화가 아니다. 정보 은닉은 복잡하거나 변경 가능한 설계 결정을 안정적인 인터페이스 뒤로 숨기는 기본 설계 원리이다. 정보 은닉의 목적은 변경에 대한 유연성을 제공하는 것이다. 정보 은닉의 원리에 따라 설계된 시스템은 변경에 대한 파급효과가 지역적이기 때문에 변경에 따르는 비용이 상대적으로 적다. 적절히 모듈화된 코드는 주어진 코드의 일부를 이해하기 위해 필요한 정보의 양이 적기 때문에 코드를 이해하기가 더 쉽다. 또한 상호 교환해야 하는 정보의 양을 최소화하면서 독자적으로 각 모듈에 대한 작업을 진행할 수 있으므로 개발 기간을 단축시킬 수 있다.
대규모의 소프트웨어를 만들 때 겪는 주요 어려움은 프로그래머들이 다수의 업무를 동시에 진행할 수 있게 일을 나누는 것이다. 이런 일의 모듈화는 정보 은닉의 개념에 매우 의존적이다. 정보 은닉은 객체와 알고리즘이 필요하지 않은 시스템 일부에는 가능한 한 이들을 보이지 않게 한다. 적절히 모듈화된 코드는 시스템의 주어진 일부를 이해하기 위해 필요한 정보의 양을 최소화함으로써 프로그래머가 “인지하는 부하”를 줄여준다. 잘 설계된 프로그램에서는 모듈 간의 인터페이스가 가능한 “좁으며(즉, 간단하며)” 변경될 수 있는 설계적 결정 사항은 하나의 모듈에 숨겨진다. 여기서 모듈에 숨겨져 있다는 것이 중요한데, 대부분의 상용 소프트웨어는 처음의 개발보다 유지보수(오류 수정과 개선)에 들어가는 프로그래머의 시간이 훨씬 더 많기 때문이다.
정보 은닉의 가장 큰 힘은 자기 유사성이다. 시스템을 구성하는 작은 단위의 함수부터, 이벤트 기반 아키텍처의 한 구성 요소인 시스템에 이르기까지 모든 요소를 설계하기 위한 원리로 적용이 가능하다. 자기 유사성이라는 정보 은닉의 장점은 다양한 프로그래밍 패러다임의 변화를 주도해 왔으며 현재 주도적인 패러다임의 위치를 차지하고 있는 객체 지향 프로그래밍은 정보 은닉을 효율적으로 적용할 수 있는 메커니즘인 클래스를 언어 차원에서 제공한다.
Parnas의 모듈에 대한 정보 은닉 정의는 매우 중요한 연구 프로그램에서 공개적으로 내디딘 첫 발걸음이며, 객체 지향 프로그래밍의 지적인 조상이다. 그는 모듈을 자체 데이터 모델과 자체 작동 집합을 가진 소프트웨어 실체라고 정의했다. 모듈의 데이터에는 그 모듈의 적절한 작동들 가운데 하나를 통해서만 접근할 수 있다. 두 번째 발걸음은 여러 사상가들의 헌신으로 이루어졌다. 즉, 그들이 Parnas의 모듈을 추상 데이터 타입(Abstract Data Type)으로 업그레이드하였기에, 그것으로부터 수많은 객체들이 도출될 수 있었다. 추상 데이터 타입은 모듈 인터페이스에 대한 일관된 사고와 명시 그리고 시행하기 쉬운 액세스 기율 등을 제공한다.세 번째로 내디딘 발걸음은 객체 지향 프로그래밍으로, 상속이라는 강력한 개념이 처음으로 도입되었고, 그에 따라 클래스들(데이터 타입들)은 클래스 계층 속의 조상들로부터 지정된 속성들을 기본적으로 갖게 된다. 우리가 객체 지향 프로그램에서 얻고자 하는 대부분은 사실상 Parnas가 내디딘 첫 발걸음에서, 즉 모듈의 캡슐화, 여기에 덧붙여 재사용을 목표로 설계되고 테스트된 모듈이나 클래스로 이뤄진 사전 구축된 라이브러리라는 아이디어에서 비롯된 것이다.
정보 은닉은 구조적인 설계와 객체 지향적인 설계 모두에 있어서 기본적인 구조이다. 구조적인 설계에서는, “블랙박스”라는 개념이 정보 은닉으로부터 왔다. 객체 지향적인 설계에서는 정보 은닉이 캡슐화와 모듈화를 발생케 하였으며, 추상화 개념과 연결된다.
그렇다면 정보 은닉과 캡슐화의 차이는 무엇일까? 대부분의 사람들은 캡슐화를 데이터를 공용 메소드로 감추는 방법, 또는 관련된 데이터와 함수를 하나의 단위로 묶는 방법이라고 생각한다. 전자는 캡슐화의 한 종류인 데이터 캡슐화를 의미하며, 후자는 추상 데이터 타입(ADT)-책임 할당의 개념으로 보면 INFORMATION EXPERT 패턴-의 개념이다. 그러나 이런 관점은 캡슐화의 한 단면만을 이야기할 뿐이다.
캡슐화는 ‘온갖 방법의 숨기기’라고 생각하면 쉽다. 캡슐화를 통해 데이터를 숨길 수 있다. 그리고 구현 코드, 파생 클래스 또는 여러 가지의 것들을 숨길 수 있다. … 따라서, 실제로 어떠한 종류의 파생 클래스가 나타나는지를 알고 있는 클라이언트를 가지지 않으면서 다형적으로 행위하는 추상 클래스가 존재할 때 이러한 캡슐화가 이루어질 수 있다.- 알란 섈로웨이, 제임스 트로트, “알기 쉬운 디자인 패턴”
이러한 다양한 방법의 숨기기를 통해 클래스, 클래스 그룹, 또는 패키지 전체에 가해지는 변경에 대한 파급 효과를 일정한 영역 내부로 제한시킬 수 있다.
설계에서 무엇이 변화될 수 있는지 고려하자.이 접근법은 재설계의 원인에 초점을 맞추는 것과 반대되는 것이다. 설계에 변경을 강요하는 것이 무엇인지에 대해 고려하기보다는, 재설계 없이 변경시킬 수 있는 것이 무엇인지 고려하자. 여기에서의 초점은 많은 디자인 패턴의 주제인 변화하는 개념을 캡슐화하는 것이다.
대부분의 컨텍스트에서 캡슐화와 정보 은닉은 동일한 의미를 지니다. 즉, 복잡한 설계 결정, 또는 변경이 발생할 수 있는 설계 결정을 안정적인 인터페이스 배후로 감추는 것이다. 따라서 캡슐화와 정보 은닉의 차이점에 대해 고민하기 보다는 원리를 충족시키는 방법에 초점을 맞추는 것이 올바른 접근방법이다.