199. 정보 은닉 (Information Hiding) - 내부 구현 상세를 숨김 캡슐화 캡슐화 객체 지향 접근 제어자 사이드 이펙트 차단 독립성
핵심 인사이트: (198번 추상화 연계) ATM 기계가 있다. 내가 만질 수 있는 건 '입금, 출금 버튼'과 '돈구멍'뿐이다. 왜 현금이 들어있는 진짜 '쇠금고' 문은 꽁꽁 잠가 놨을까? 열어놓으면 손님이 자기 돈 출금하려다 실수로 다른 사람 돈통을 건드려서 찢어먹거나, 해커가 돈을 다 훔쳐가서 은행 전산망 전체가 무너지기 때문이다. "야! 프로그램 짤 때도 똑같이 해! 객체(클래스)가 가진 '비밀번호 변수'나 '핵심 잔액 변수'를 다른 놈이 밖에서 직접
계좌.잔액 = 0으로 건드리지 못하게 무조건 자물쇠(private)를 채워버려! 밖의 놈들은 오직 내가 허락한 '출금() 메서드'라는 대문(public)을 통해서만 노크하고 잔액을 바꿔가게 해라!" 객체의 속살을 외부의 더러운 손길로부터 완벽히 차단하는 철갑옷, 정보 은닉이다.
Ⅰ. 정보 은닉 (Information Hiding)의 개념 🌟
- 데이비드 파나스(David Parnas)가 1972년에 주창한 소프트웨어 설계의 절대 진리입니다.
- 개념: 모듈(클래스/함수)의 내부 데이터 구조나 구체적인 알고리즘 로직을 외부 모듈이 직접 접근하거나 들여다보지 못하게 자물쇠로 꽁꽁 감추고, 오직 사전에 약속된 공식적인 통로(인터페이스, Public Method)를 통해서만 데이터를 주고받도록 통제하는 기법입니다.
Ⅱ. 왜 꽁꽁 숨겨야 하는가? (정보 은닉의 효과) 🌟 핵심 기출 🌟
1. 사이드 이펙트(부작용) 차단과 안정성
- 은행 계좌 클래스의
잔액변수가 만약Public(공개)상태라고 칩시다. - 신입 개발자가 주문 시스템 코드를 짜다가 실수로
내계좌.잔액 = 100억이라고 쳐버리면 에러 없이 그대로 적용되어 회사가 파산합니다. - 잔액 변수를 **
Private(은닉)**으로 숨겨버리고입금(금액)메서드만 열어두면? 외부에서 잔액을 직접 조작할 방법이 원천 차단되고, 입금() 함수 안에서 "마이너스 금액은 안 돼!"라고 검증 로직을 거치게 할 수 있어 데이터가 100% 오염되지 않습니다.
2. 유지보수와 독립성의 극대화 (파급 효과 최소화)
- 내부 구현을 싹 다 숨겨놨기 때문에, 내가 내부 알고리즘(예: 배열을 쓰던 걸 트리 구조로 바꿈)을 완전히 갈아엎어도 밖에서 나를 호출해 쓰던 다른 모듈들의 코드는 단 1줄도 수정할 필요가 없습니다. (왜? 걔들은 내 겉모습 껍데기 인터페이스만 보고 있었으니까!)
Ⅲ. 객체 지향(OOP)의 캡슐화(Encapsulation)와의 관계
- 캡슐화: 관련된 데이터(변수)와 그걸 처리하는 함수(메서드)를 하나의 알약(클래스) 껍데기로 이쁘게 묶어버리는 '행위(포장)' 자체를 말합니다.
- 정보 은닉: 그 묶어놓은 알약 껍데기 안에서 밖에서 보이면 안 되는 위험한 속살(변수)을 안 보이게 **'접근 제어자(Access Modifier)'를 통해 차단하는 '원리'이자 '목적'**입니다. (캡슐화라는 포장지를 쓰면 자연스럽게 정보 은닉이 달성됩니다.)
Ⅳ. 구현 도구: 접근 제어자 (Access Modifier)
자바, C++ 등에서 정보를 숨기는 바리케이드입니다.
private(철벽): 내 클래스 안에서만 나만 볼 수 있음! 외부 접근 100% 차단. (정보 은닉의 핵심)protected(가족 허용): 외부인은 못 보지만, 나를 상속받은 자식 클래스에게는 물려줌.public(공공재): 세상 누구나 다 뜯어보고 호출할 수 있는 열린 문(인터페이스).
📢 섹션 요약 비유: 정보 은닉이 안 된 코드는 손님이 **'주방 안까지 막 들어와서 직접 요리하는 식당'**입니다. 손님이 스테이크를 굽는다고 주방의 소금통, 간장통(내부 변수)을 자기 맘대로 막 써대다가 냉장고 온도를 실수로 꺼버리면(부작용 발생) 그 식당의 요리 생태계 전체가 썩어버립니다(의존성 폭발 및 유지보수 지옥). 반면 **정보 은닉(Information Hiding)**이 완벽한 코드는 **'주방에 쇠창살 문이 굳게 닫힌 고급 레스토랑'**입니다. 주방 안(모듈 내부)에 칼, 도마, 비법 소스(Private 변수와 로직)가 널브러져 있지만 밖의 손님은 절대 만지거나 볼 수 없습니다. 손님은 오직 홀에 서 있는 웨이터(Public Interface 인터페이스)에게 **"스테이크 하나 줘(메서드 호출)"**라는 정해진 대화만 할 수 있습니다. 셰프가 내일 도마를 나무에서 플라스틱으로 바꾸든 칼을 바꾸든(내부 알고리즘 수정), 손님은 아무것도 알 필요가 없고 맛있는 스테이크만 받아먹으면 끝나는, 완벽한 역할 분리와 모듈의 자립을 보장하는 궁극의 바리케이드입니다.