객체지향의 사실과 오해: 개발자의 시야를 넓혀줄 필독서 핵심 리뷰

안녕하세요, 현대 소프트웨어 개발에서 객체지향 프로그래밍(OOP)은 빼놓을 수 없는 핵심 패러다임입니다. 자바, C#, 파이썬 등 대부분의 주류 언어가 객체지향을 지원하며, 우리는 매일 객체와 클래스를 사용해 코드를 작성합니다. 하지만 과연 우리는 객체지향을 '제대로' 이해하고 있을까요?

많은 개발자들이 객체지향을 "클래스를 만들고 상속을 활용하며 다형성을 사용하는 것" 정도로만 이해하고 넘어가는 경우가 많습니다. 저 역시 그랬습니다. 그러다 우연히 접하게 된 책이 바로 『객체지향의 사실과 오해』(원제: Object Thinking)입니다. 이 책은 객체지향에 대한 저의 기존 관념을 뿌리째 흔들어 놓았고, 코드와 설계를 바라보는 시야를 근본적으로 변화시켰습니다. 오늘은 이 책의 핵심 내용을 리뷰하며, 여러분의 객체지향 사고를 한 단계 업그레이드할 기회를 제공하고자 합니다.

1. 우리가 알던 객체지향은 '오해'였을지도? - 책의 핵심 메시지

이 책의 가장 강력한 메시지는 바로 객체지향의 본질이 클래스나 상속, 다형성에 있지 않다는 것입니다. 저자는 우리가 흔히 객체지향의 '기법'이라고 배우는 것들이 사실은 객체지향 패러다임을 구현하기 위한 '도구'일 뿐이며, 진정한 객체지향은 현실 세계를 바라보는 관점과 사고방식에 뿌리를 두고 있다고 주장합니다.

객체지향은 세상을 자율적인 객체들의 협력 공동체로 바라보는 것이다. 이 객체들은 각자의 책임을 다하며 메시지를 주고받으며 전체 시스템을 구성한다.

우리는 보통 클래스를 먼저 만들고 그 안에 데이터와 메서드를 채워 넣는 방식으로 개발을 시작합니다. 하지만 이 책은 객체의 '상태'보다는 '행동'에, 그리고 '클래스'보다는 '객체' 자체에 집중하라고 조언합니다. 클래스는 단지 객체의 청사진일 뿐, 실제 행위자는 객체라는 점을 끊임없이 강조하며, 이는 많은 개발자에게 신선한 충격으로 다가올 것입니다.

2. 객체지향의 세 가지 핵심 기둥: 객체, 책임, 협력

『객체지향의 사실과 오해』가 제시하는 객체지향의 핵심 개념은 다음 세 가지입니다.

• 객체(Object): 스스로 판단하고 행동하는 자율적인 존재. 데이터와 행동을 함께 가지며, 외부에서는 객체의 상태를 직접 제어하기보다 메시지를 통해 행동을 요청해야 합니다. 객체는 단순히 데이터 덩어리가 아니라, 능동적인 주체여야 합니다.
• 책임(Responsibility): 객체가 마땅히 해야 하는 일, 또는 객체가 알고 있어야 하는 정보입니다. 책임은 외부에서 객체에게 기대하는 '행동'의 명세입니다. 예를 들어, '영화' 객체는 자신의 '제목'과 '가격'을 아는 책임이 있고, '할인 정책' 객체는 '할인 금액을 계산하는' 책임이 있습니다.
• 협력(Collaboration): 객체들이 공동의 목표를 달성하기 위해 메시지를 주고받으며 상호작용하는 과정입니다. 시스템은 하나의 거대한 객체가 모든 것을 처리하는 것이 아니라, 작은 책임을 가진 객체들이 서로 협력하여 복잡한 기능을 구현합니다. 이 과정에서 객체는 자신이 직접 처리할 수 없는 요청에 대해 다른 객체에게 책임을 위임하기도 합니다.

이 세 가지 개념은 마치 현실 세계의 사회 구성원들이 각자의 역할을 수행하고 협력하여 사회를 유지하는 모습과 닮아 있습니다. 이 책을 통해 우리는 코드를 작성하기 전에 "어떤 객체들이 존재해야 할까?", "각 객체는 어떤 책임을 가져야 할까?", "이 객체들은 어떻게 협력해서 문제를 해결할까?"와 같은 질문을 먼저 던지는 훈련을 하게 됩니다.

3. 실용적 관점에서의 객체지향 설계 원칙

책에서 제시하는 객체, 책임, 협력에 대한 깊은 이해는 실제 코드 설계에도 큰 영향을 미칩니다. 특히 캡슐화와 추상화에 대한 새로운 관점을 제공합니다.

• 캡슐화: 단순히 private 접근 제어자를 사용하는 것을 넘어, 객체의 책임을 외부에 명확히 노출하고, 그 책임을 수행하는 구현 세부사항을 내부로 철저히 숨기는 것입니다. 객체는 메시지를 통해서만 상호작용해야 하며, 외부에서 객체의 내부 상태를 직접 조작하려는 시도를 막아야 합니다.
• 추상화: 복잡성을 숨기고 핵심적인 책임을 드러내는 과정입니다. 인터페이스나 추상 클래스는 이러한 추상화를 위한 도구이며, 중요한 것은 '무엇을 할 것인가(책임)'를 '어떻게 할 것인가(구현)'보다 우선시하는 사고방식입니다.

이러한 관점은 응집도(Cohesion)를 높이고 결합도(Coupling)를 낮추는 설계 원칙과도 자연스럽게 연결됩니다. 객체가 하나의 분명한 책임을 가지고 있다면 응집도가 높아지고, 다른 객체와 메시지를 통해서만 느슨하게 협력한다면 결합도가 낮아지기 때문입니다. 결과적으로 유연하고 확장 가능한 시스템을 구축하는 데 기여합니다.

4. 클래스 중심 사고와 객체 중심 사고의 차이

이 책을 읽고 나면, 우리가 무의식적으로 해왔던 '클래스 중심' 사고방식이 얼마나 많은 설계 문제를 야기했는지 깨닫게 됩니다. 아래 표를 통해 두 사고방식의 차이를 명확히 비교해 보겠습니다.

항목	클래스 중심 사고	객체 중심 사고 (객체지향의 사실과 오해)
시작점	클래스 구조, 상속 계층도, 데이터 모델링	객체의 책임과 협력 정의
주요 관심사	데이터와 메서드를 묶는 것, 클래스 간의 관계	객체가 수신하는 메시지, 객체의 행동, 역할
설계 결과	데이터 위주의 수동적인 객체, 경직된 구조, 높은 결합도	자율적이고 능동적인 객체, 유연하고 확장 가능한 구조, 낮은 결합도
예시 (할인 정책)	Movie 클래스 안에 할인 로직을 직접 구현하거나, DiscountType 열거형으로 분기	DiscountPolicy 인터페이스를 정의하고, AmountDiscountPolicy, PercentDiscountPolicy 등 다양한 객체들이 책임을 위임받아 협력

이러한 사고의 전환은 단순히 코드를 더 예쁘게 만드는 것을 넘어, 시스템의 유지보수성, 확장성, 재사용성을 근본적으로 향상시킵니다. "객