협력하는 객체들의 공동체 | 협력 속에 사는 객체

728x90

이 장을 읽으면서 가장 먼저 떠오른 생각은, 객체지향이라는 것이 단순히 코드 구조를 깔끔하게 만들기 위한 도구가 아니라, 소프트웨어를 구성하는 '존재들'이 어떻게 살아가야 하는지에 대한 철학이라는 점이었다. '협력 속에 사는 객체'라는 표현은 단순히 은유로 들리지 않았다. 객체들이 각자의 책임을 지니고 서로 메시지를 주고받으며 협력하는 구조는, 마치 서로 다른 사람이 함께 살아가는 사회의 모습과도 닮아 있었다. 객체지향의 아름다움이 '협력의 조화'에서 나온다고 한 말은 그래서 설득력 있게 다가왔다. 그리고 그 조화를 만들기 위해서 각 객체가 반드시 품고 있어야 할 두 가지, 바로 협력성과 자율성 사이의 균형이 무엇보다 중요하다는 말에 깊이 공감하게 되었다.

객체가 협력적이라는 것은 타인의 요청에 적절하게 응답할 수 있어야 한다는 의미지만, 그것이 곧 수동적으로 명령에 복종하는 상태를 의미하는 것은 아니라는 설명이 인상 깊었다. 객체는 요청을 수신하고, 그에 대한 응답을 선택하며, 자신의 방식대로 일을 수행할 수 있어야 한다. 이런 의미에서 객체는 자신의 내부 원칙과 상태를 기준으로 판단하고 행동하는 자율적인 존재여야 하며, 동시에 외부와의 상호작용을 위해 열려 있어야 한다. 이 균형이 무너지면 협력도 무너지게 되고, 그로 인해 전체 시스템의 품질 역시 흔들리게 된다. 결국 객체의 자율성과 협력성은 개별 객체의 품질뿐 아니라 전체 애플리케이션의 품질을 좌우하는 기준이 된다.

객체가 상태와 행동을 함께 지니고 있어야 한다는 설명은 매우 기본적인 원칙 같지만, 그 안에 자율성의 본질이 담겨 있다는 점을 다시 생각하게 되었다. 객체가 단순히 데이터의 집합이 아니라, 상태를 바탕으로 스스로 판단하고 행동할 수 있어야 한다면, 우리는 객체를 설계할 때 그 내부에 들어갈 상태와 그에 적합한 행동을 신중하게 구성해야 한다. 그리고 객체 간의 협력은 그 상태와 행동이 바탕이 된 메시지 교환으로 이뤄지기 때문에, 메시지를 설계하는 일은 곧 협력 방식을 정의하는 일이기도 하다. 객체는 다른 객체에게 '무엇을 해달라'는 메시지를 보낼 수 있지만, 그 요청을 '어떻게' 수행할지는 메시지를 수신한 객체의 몫이라는 점이 중요하다. 이런 방식은 협력의 구조는 명확하되, 구현은 유연하게 유지될 수 있는 장점을 갖는다.

메시지와 메서드를 구분해서 생각하는 개념은 자율성의 실현을 돕는다. 메시지는 외부로부터의 요청이며, 메서드는 그 요청을 어떻게 처리할지를 결정하는 내부의 구체적인 방법이다. 이 둘이 명확히 분리되어 있다는 것은 객체가 외부의 요청에 휘둘리지 않고, 자신의 내부 로직에 따라 자율적으로 응답할 수 있다는 가능성을 열어준다. 그래서 이 구분은 단순한 개념 정리를 넘어서, 객체 간의 건강한 관계를 유지하기 위한 핵심 원칙으로 느껴졌다.

전체적으로 이 장은 객체지향이 왜 단순한 구조적 접근을 넘어 철학처럼 느껴지는지를 다시 확인하게 해주었다. 객체는 단순히 기능을 나누는 단위가 아니라, 역할을 지닌 존재로서 서로를 인정하고 존중하며 협력하는 주체들이다. 이들의 상호작용이 매끄럽고 자연스러워질 때, 비로소 시스템은 유연하고 품격 있게 동작할 수 있다. 그래서 객체를 설계한다는 일은 곧 사람처럼 생각하고, 사람처럼 관계 맺는 방식을 소프트웨어에 심는 일이라는 생각이 들었다. 이 책이 기술서가 아닌 철학서처럼 느껴지는 이유가 바로 여기에 있다고 생각한다.

 

 

 

 

728x90