컴퓨터공학을 전공하면 꼭 듣게 되는 과목 중 하나가 객체 지향 프로그래밍 (Object Oriented Programming)이다.
OOP 수업을 들으며 클래스와 객체, 객체의 상태와 행동, 그리고 객체지향의 4가지 특성 등을 배웠다. 과제, 퀴즈, 시험을 보며 그다지 복잡하다고 느낀적은 별로 없었던것 같다.
하지만, 현재 인턴쉽을 하면서 “좋은 객체 지향 설계”를 하기 위해서는 많은 경험과 지식이 필요하다는것을 크게 느끼고 있다.
인턴쉽에서 맡게되었던 업무 중 하나는 LLM Chatbot 애플리케이션으로 부터 대화 세션을 수집하는 server-side Python SDK 개발이였다. 실제 SDK 사용자들이랑 인터랙션하는 SDKClient, batch processing을 위해 데이터를 임시로 저장하는 BufferStorage, 데이터를 실제 ingestion 서버에 쏴주는 APIclient, 버퍼로부터 적절한 타이밍에 데이터를 빼내서 APIClient에 넘겨주는 Worker 등 다양한 객체들이 정의되었다.
처음 PR을 올렸을때 사수로부터 많은 코드 리뷰를 받았었다. 리뷰들중에 가장 깊게 고민을 했던 리뷰는 “객체들의 적절한 역할분담”과 관련된것이었다.
예를들어, APIClient가 서버에게 요청을 보냈을때 에러가 발생하면, APIClient 단에서 로깅을 하고 error smoothing을 하였다. 하지만 사수로부터 “APIClient는 인풋 데이터를 받아서 API 요청을 보내는 역할”을 하는 객체이고, 그 결과값을 보고 error 처리를 하는것은 Worker객체(혹은 SDKClient)단에서 해야한다 라는 코드리뷰를 받았다. 곰곰히 생각해보니 API 요청을 보내는 라이브러리를 쓰는데, 요청 중에 에러가 발생한걸 그 라이브러리가 마음대로 묵살해버리면 굉장히 당황스러운 일일것이다.
이러한 경험들로부터 다음과 같은 질문들이 생겨났다.
- 상황에 맞게 “어떠한 객체”들을 정의하는게 좋은가?
- 각 객체에게 어느 역할/어느 정도까지의 역할을 부여해야하는 것인가?
- 어떻게 다양한 객체들이 유기적으로 연합하여 큰 시스템을 만드는가?
- etc…
자연스럽게 객체 지향 설계에 대해 깊게 탐구해보고 싶다는 갈증이 많이 생겨났다.
코드와 함께 배울 수 있는 객체지향 서적들이 많지만, 주위 사람들로부터 객체지향의 본질에 대해서 이해하기 위해 “객체지향의 사실과 오해”를 읽어보라는 조언을 들어서 한번 정독해보려 한다.
물론 갈길은 멀었지만, 차근차근 성장하고 싶다.
이 책의 목차는 크게 다음과 같다.
- 협력하는 객체들의 공동체
- OOP의 핵심은 자율적인 객체의 협력
- 이상한 나라의 객체
- 객체란 무엇인가
- 타입과 추상화
- 추상화는 단순화다
- 역할, 책임, 협력
- OOP 설계의 가장 중요한 재료인 역할, 책임, 협력
- 책임과 메시지
- 훌륭한 메시지가 훌륭한 객체지향 설계의 기반
- 객체 지도
- 구조와 기능의 조화
- 함께 모으기
- 구현 코드