Encapsulation

잔액, 수량, 상태 전이 같은 값을 외부 코드가 직접 바꾸기 시작하면 객체가 어느 순간 유효한 상태인지 보장하기가 어렵습니다. 검증 로직이 호출자마다 흩어지면 어떤 곳은 체크하고 어떤 곳은 건너뛰게 되고, 결국 버그는 규칙이 빠진 가장 약한 지점에서 터집니다.

절차적 코드에서는 데이터 구조와 그 데이터를 조작하는 함수가 서로 멀리 떨어져 있는 경우가 많았습니다. 시스템이 커질수록 규칙이 여러 모듈로 복제되고 어떤 값이 어디서 바뀌는지 추적하기가 어려워졌습니다. 캡슐화는 이런 흩어진 규칙을 객체 경계 안으로 다시 모으려는 흐름 속에서 중요해졌습니다.

객체는 보통 private 상태와 public 메서드를 함께 둡니다. 외부는 값을 직접 세팅하는 대신 withdraw, reserve, changeStatus 같은 의미 있는 요청을 보냅니다. 객체는 현재 상태를 확인하고 필요한 검증을 거친 뒤 조건이 맞을 때만 내부 값을 바꿉니다. 이 과정을 통해 객체가 자기 일관성을 스스로 지키게 됩니다.

캡슐화는 누가 내부 상태에 직접 접근할 수 있는가의 문제이고, 추상화는 바깥에 어떤 표면을 보여 줄 것인가의 문제입니다. 내부를 숨긴다고 자동으로 좋은 추상화가 되는 것은 아니고, 반대로 표면이 좋아 보여도 상태 변경 규칙이 밖으로 새면 캡슐화가 잘 된 설계라고 보기 어렵습니다.

계좌 잔액, 주문 상태, 재고 수량처럼 잘못 바뀌면 바로 비즈니스 오류가 나는 데이터에는 캡슐화가 사실상 필수입니다. 반대로 외부 시스템과 값을 교환하는 단순 DTO까지 동일한 강도로 캡슐화하면 보호해야 할 규칙은 없는데 우회 메서드만 늘어나는 경우가 많습니다.