오브젝트를 읽게 된 이유와 감상에 대한 글입니다. 책의 각 장을 요약해 둔 블로그가 많을 것 같기에, 내용보다는 제가 얻은 점을 중점으로 작성하였습니다.
왜 객체지향을 공부하게 되었나?
코드 작성과 설계를 검색하다 보면 객체지향, 함수형과 같은 단어들을 마주친다. 모두 확장과 변경이 쉬운 코드를 작성하고 설계하라는 이야기를 하며 이는 너무 당연해 보인다. 마치 착하게 살자라는 표어 같다. 쓰레기를 줍는 것, 남을 배려하는 것 등 착하게 사는 방법을 배우는 것처럼, 확장과 변경이 쉬운 코드를 위해 SOLID 원칙, 추상화, 다형성 등을 배운다. 나 혼자만 사용하는 코드를 설계하거나, 작성된 코드에 기능을 추가하거나 수정하는 등의 업무만 할 때까지 나는 괜찮은 코드를 작성하는 줄 알았다.
현 회사는 설립이 3년이 안 되었다. 입사 초기 나에게 할당된 요구 사항이 인턴을 하던 회사에 비해 상당히 추상적이었다. 확고한 요구 사항이 없다는 것이 신입 입장에서는 꽤 어려웠고 정확히 어떤 기능을 개발해야 하는지 갈피를 못 잡았다. 진행 상황을 발표하던 자리에서 팀장님이 요구가 명확하지 않을 때 개발자는 어떠한 코드를 작성해야 하는지를 약간 설명해 주셨다. 조금은 정석으로 객체지향을 공부하고 싶어 여러 책을 구매했고, 유명한 오브젝트로 첫 시작을 하였다.
크게 이 책은 객체지향에서의 설계 원칙, 상속과 합성, 역할과 책임, 협력에 대한 개념과 접근 방식을 다룬다.
책에서 적절한 사례와 코드로 위 내용을 설명한다. 사례도 좋았고 읽으며 내 경험 두 가지가 떠올랐다.
-
책 초반
요구 사항은 항상 변하며 개발을 시작하는 시점에 구현에 필요한 모든 요구사항을 수집하는 것은 불가능에 가깝다라는 내용이 나온다. 이를 읽으며 입사 초기 나에게 할당된 일이 왜 추상적으로 느껴지고 나를 힘들게 했는지 깨달았다. 나는 변하지 않는 요구 사항을 원하고 있었다! 수정과 확장성이 필요 없는 코드만 작성해 왔기 때문에 유연한 코드를 작성해야 하는 것이 어렵게 느껴졌다고 생각한다. (당시에는 유연한 코드를 작성해야 하는 것 자체도 사실 생각을 못 했다) -
'책임'에 대한 이야기는 반복해서 나온다. 읽으며 문득 LLM Ouput이 Json schema에 일치하지 않으면 schema에 맞게 output을 수정하거나 LLM이 고치는 로직을 개발한 것이 떠올랐다. 처음 개발하였을 때는 prompt, model call, parsing, retry를 하나의 클래스에서 담당하고 있었다. 지금 생각하면 어이가 없지만 당시 재시작을 담당하는 책임만 지고 있다고 생각했다. 당연히 사용성과 확장성이 좋지 않았고 Langchain의 LCEL 문법과도 맞지 않아서 다시 개발했다. 두 번째로 개발할 때는 Langchain의 코드를 조금 더 자세히 살펴보며 클래스를 어떻게, 왜 나누었는지 생각해 보았다. 그들이 생각한 책임의 범위를 최대한 따르며 개발하려고 했다. 방법으로는 적절한 상속과 합성을 둘 다 사용했다. 완벽하다고 할 수는 없지만, 책임도 나름 분리되었고 LCEL 문법과도 호환이 되어 훨씬 사용성이 높아졌다.
느낀 점
현실 세상은 상당히 복잡하다. 코드 세상도 마찬가지이다. 거짓말이 항상 악이 아닌 것처럼, 의존성도 항상 악이 아니다. 오브젝트를 통해 언제 거짓말이 악이 될 수 있는지, 어떻게 하면 거짓말하는 상황을 피할 수 있는지 혹은 언제 거짓말을 해도 되는지와 같은 것을 배울 수 있다. 당연히 모든 것을 관통하는 법칙이나 방법은 없다. 객체지향에 입문하기 좋은 책이고 다른 책과 다양한 관점도 꾸준히 공부 해야겠다.
