객체지향은 왜 클래스 많이 만드는 기술이 아닐까라는 질문은 생각보다 중요합니다. 객체지향을 클래스 수나 상속 문법으로만 이해하면 설계가 왜 어려운지 설명하기가 잘 안 되기 때문입니다. 이 글에서는 객체지향을 책임, 협력, 캡슐화 관점으로 다시 풀어보겠습니다.
왜 많은 사람이 객체지향을 오해할까
이유는 단순합니다. 눈에 보이는 것부터 배우기 때문입니다. 클래스, 상속, 접근 제어자 같은 것은 문법으로 바로 보이지만 책임과 협력은 눈에 잘 보이지 않습니다. 그래서 초급 단계에서는 설계보다 문법이 더 중요해 보이기 쉽습니다.
문제는 여기서 시작됩니다. 클래스를 10개로 나눴다고 해서 좋은 객체지향이 되는 것은 아닙니다. 오히려 역할이 애매한 클래스가 늘어나면 어디를 고쳐야 할지 더 헷갈릴 수 있습니다. 객체지향은 변경을 덜 아프게 만드는 설계 방식에 더 가깝습니다.
객체지향에서 먼저 봐야 하는 것은 책임이다
좋은 객체지향 설계를 이야기할 때 가장 먼저 봐야 하는 것은 책임입니다. 여기서 책임은 이 객체가 무슨 데이터를 들고 있느냐보다 이 객체가 어떤 일을 맡아야 하느냐에 가깝습니다.
초보자는 보통 데이터를 기준으로 클래스를 나눕니다. 그런데 실제 행동은 다른 서비스 클래스에 몰아넣고 엔티티는 getter만 잔뜩 가진 데이터 통처럼 남는 경우가 많습니다. 이 구조는 객체지향처럼 보이지만 실제로는 책임이 잘게 흩어진 상태에 가깝습니다.
협력을 봐야 설계가 보인다
객체는 혼자 존재하지 않습니다. 실제 프로그램은 객체들이 서로 메시지를 주고받으며 동작합니다. 그래서 객체지향을 이해할 때는 개별 클래스만 보는 습관보다 어떤 객체가 누구와 어떻게 협력하는가를 먼저 보는 편이 좋습니다.
나쁜 설계에서는 하나의 거대한 서비스가 회원 상태를 읽고, 상품 재고를 읽고, 할인 규칙을 계산하고, 결제를 처리하고, 주문 상태를 바꿉니다. 반대로 협력 중심으로 보면 각 객체가 자신이 책임질 판단을 맡고 필요한 요청만 서로 주고받습니다.
캡슐화는 왜 중요한가
캡슐화는 종종 private 붙이는 것 정도로 오해됩니다. 하지만 실무에서 더 중요한 것은 객체 내부의 판단과 상태 변경 방식을 밖으로 너무 많이 드러내지 않는 것입니다.
내부 구현이 밖으로 다 새어나가면 다른 객체들이 그 구현에 의존하기 시작합니다. 그러면 나중에 내부 로직을 바꾸고 싶어도 바깥 코드가 다 같이 깨집니다. 캡슐화는 예쁘게 숨기는 기술이 아니라 변경 범위를 줄이는 기술입니다.
데이터 중심 설계가 왜 자주 무너질까
초보자가 가장 자주 만드는 구조는 데이터 중심 설계입니다. 객체는 필드만 들고 있고, 비즈니스 로직은 서비스에 몰려 있고, 판단은 대부분 외부에서 하는 구조입니다. 처음에는 단순해 보이지만 요구사항이 늘어나기 시작하면 데이터를 읽는 곳이 많아지고, 판단 로직이 여러 서비스에 퍼지고, 변경이 생기면 여러 군데를 같이 수정해야 합니다.
반대로 책임 중심 설계는 가능한 한 객체가 자기 상태와 행동을 함께 다루게 만듭니다. 물론 현실에서는 모든 책임을 객체 내부에만 둘 수는 없지만, 적어도 이 판단은 누가 가져야 자연스러운가를 계속 묻는 습관이 설계를 크게 바꿉니다.
나쁜 클래스 구조는 보통 이런 식으로 생긴다
- getter만 많은 클래스
- 모든 것을 아는 서비스 클래스
- 상속으로 구조를 억지로 묶는 경우
- 역할보다 데이터 모양으로만 클래스를 나누는 경우
이 패턴들은 결국 공통점이 있습니다. 객체가 자기 책임을 충분히 갖지 못한다는 점입니다.
그럼 좋은 객체지향 설계는 어떻게 시작할까
- 이 기능에서 핵심 역할은 누구인가
- 어떤 객체가 이 판단을 가져가는 것이 자연스러운가
- 이 정보는 정말 밖에서 알아야 하는가
- 이 변경이 생기면 어디까지 수정이 퍼질까
이 질문을 기준으로 설계를 보면 클래스 수보다 역할이 보이기 시작합니다. 그리고 역할이 보이면 그다음에야 상속, 인터페이스, 조합 같은 도구를 더 제대로 쓸 수 있습니다.
마무리
객체지향은 클래스를 많이 만드는 기술이 아닙니다. 상속을 멋지게 쓰는 기술도 아닙니다. 더 정확히 말하면 변경이 생겨도 덜 아프게 만들기 위해 책임과 협력, 캡슐화를 조정하는 설계 방식에 가깝습니다.
그래서 객체지향을 다시 배우고 싶다면 문법보다 먼저 누가 이 일을 맡아야 하는가, 누구와 어떻게 협력해야 하는가, 무엇을 안으로 숨겨야 하는가를 붙잡는 편이 좋습니다.
코드를 읽기 쉬운 기준을 함께 보고 싶다면 컬렉션과 람다를 읽기 쉽게 쓰는 기준 글도 같이 참고할 수 있습니다.
