오브젝트와 함께 한 객체 지향 스터디 마무리 회고

지난 6월 중순에 시작한 객체 지향 스터디가 종료되어 회고를 작성해보려 합니다. 사실 스터디가 종료된 것은 지난 11월 중순이나 그동안 프로젝트를 진행하고 배운 내용을 정리하면서 조금씩 미루다 보니 무려 한 달이 지나서야 작성을 하게 되었습니다.

지난 1차 스터디에서 이어지는 이번 스터디의 방식과 짧은 내용 정리, 생각보다 길어진 스터디 기간동안 느낀점에 정리하며 마무리하겠습니다.

스터디 방식

• 기간: 7월 18일 ~ 11월 14일
• 사용한 자료: 오브젝트
  

초기에는 스터디원이 돌아가면서 그 주 챕터에서 대해서 요약하여 발표하고 각자 어려웠던 점에 대해서 공유하는 시간을 가졌습니다. 그러나 어느정도 진행했을쯤 어차피 모두 읽고 오는 내용인데 정리는 각자 진행하고 어려웠던 부분, 각자 프로젝트를 진행하면서 고민했던 부분에 대해서 공유하는 시간을 가지는 것이 어떻느냐? 라는 의견이 나왔습니다.

따라서 중, 후기부터는 이해하기 어려운 내용, 실제로 고민했던 부분에 대해 경험을 공유하는 시간의 비중을 늘렸습니다.

학습 내용 정리

아직까지 경험이 부족해서인지 온전히 이해하기에는 쉽지 않은 내용들이 있었습니다. 때문에 책에서 설명한 바와 달리 제가 잘못 이해한 부분이 있을 수 있습니다. 잘못된 부분, 모호한 부분이 있다면 너른 마음으로 지적 부탁드립니다.

객체는 협력을 통해서 하나의 기능을 구성합니다. 각각의 객체는 상태와 행위를 가지는 복합적인 존재이고 스스로의 판단하에 어떤 행위를 할지 결정하는 자율적인 존재입니다.

객체는 서로 메시지를 통해서 의사소통합니다. 티켓 박스와 고객이라는 객체가 있다고 하겠습니다. 고객이 티켓 박스에게 티켓을 구매한다라는 메시지를 보냅니다. 고객은 메시지에 대한 응답으로 티켓을 받을 것입니다.

이 과정에서 고객은 티켓 박스가 티켓이라는 응답을 보내기 위해 어떤 과정을 거치는지, 어떤 객체와 협력하는지 전혀 알 필요가 없습니다. 고객이 알고 있는 것은 티켓을 구매한다는 메시지를 티켓 박스가 이해할 수 있다는 사실 하나 뿐입니다.

티켓 박스는 티켓을 구매한다라는 메시지를 처리하기 위해 스스로의 판단하에 최적의 방법을 선택합니다. 이 과정에서 좌석 관리 시스템이라는 객체에 새로운 메시지를 보내거나, 티켓 서비스라는 인공적인 객체에 메시지를 보낼지도 모릅니다. 만일 티켓의 수량이 부족하다면 티켓 발행기에게 티켓을 추가로 발행하라라는 메시지를 보낼 겁니다. 어쩌면 다른 객체와 협력하지 않고 이 모든 사항을 티켓 박스 내에서 처리할지도 모릅니다.

그러나 이는 오직 티켓 박스가 알아서 처리할 내용입니다. 티켓팅 시스템으로부터 티켓을 구매한다 따위의 내용은 세부적인 사항입니다. 외부에 공개하는 것은 그보다는 좀 더 추상적이고 고수준의 정책인 티켓을 구매한다 정도의 메시지뿐입니다.

티켓을 구매한다라는 메시지만 이해할 수 있다면 그 대상이 사람이 관리하는 티켓 박스든, 키오스크로 관리하는 티켓 박스든 상관 없습니다. 로봇이 관리하는 티켓 박스가 새롭게 추가된다 하더라도 동일한 메시지를 이해하고 고객이 원하는 응답을 할 수만 있다면 어떤 티켓 박스와도 협력할 수 있습니다.

캡슐화

객체의 로직을 내부로 숨겨서 클라이언트가 알지 못하도록 하는 것을 캡슐화라 합니다. 고객은 티켓 박스가 티켓 구매를 어떻게 처리하는지 모르고, 티켓 박스는 티켓 발행기가 티켓 발행을 어떻게 처리하는지 모릅니다. 연관된 로직을 객체 내부에서 처리하여 응집도를 높이고 클라이언트와의 결합도는 낮춥니다. 어떤 객체와 협력해야 하는지, 어떤 로직으로 처리되는지는 클라이언트는 전혀 알지 못합니다.

추상화

클라이언트에게 객체의 세부적인 처리 내용을 알리지 않는 것을 추상화라 합니다. 티켓 박스가 외부에 공개하는 메시지는 세부적인 사항에 결합되어서는 안 됩니다. 어떤 객체와 협력하는지, 외부와의 통신이 필요한지 따위는 세부적인 사항일 뿐입니다. 클라이언트에게 공개하는 퍼블릭 인터페이스는 객체가 어떤 역할을 하는지를 알리는 추상적인 메시지뿐입니다.

다형성

객체가 메시지를 이해할 수만 있다면 클라이언트가 어떤 객체와도 협력할 수 있는 것을 다형성이라 합니다. 사람이든, 키오스크든, 로봇이든 고객이 티켓을 구매한다는 메시지를 보내면 티켓 박스는 적절한 방식으로 요청을 처리하고 응답을 반환합니다. 객체가 어떤 방식으로든 클라이언트의 메시지를 이해하고 원하는 응답을 반환할 수 있다면 실제 클라이언트의 요청 시점에 어떤 객체든 협력 대상이 될 수 있습니다.

상속

이러한 다형적인 협력을 위해 메시지를 이해할 수 있는 계층을 구성하는 것을 상속이라 합니다. 로봇이 티켓 박스를 담당한다는 새로운 요구사항이 추가되면 티켓을 구매한다라는 메시지를 이해할 수 있는 새로운 객체를 추가합니다. 단, 상속을 통해서 새롭게 타입 계층만 형성한다고 끝나지는 않습니다. 모든 구체적인 객체는 동일한 계층 안에 있는 다른 객체들이 그러하듯이 일관적인 협력을 통해 이해하기 쉬운 일관성을 갖추어야 합니다.

느낀 점

오브젝트에 대해서

객체 지향에 대한 상세한 해설서라고 느껴졌습니다. 그래서 객체 지향이 뭔데? 라는 생각이 들면 꼭 읽어봐야하는 책이라고 생각합니다.

데브코스에서 과제를 수행할 때 이 정도까지 객체 지향을 챙기는 것이 맞나? 라는 의문을 품은 적이 있었습니다. 대표적인 코드 스멜이라고 불리는 instance of를 제거하기 위해 비지터 패턴을 적용해본 적이 있었습니다. 막상 사용해보니 저도 이해하기 쉽지 않고 남한테 설명해주는 것도 복잡한 로직이 탄생하였습니다. 멘토님께 이에 대해 질문을 드렸을 때 이해하기 어려운 코드 보다는 적절한 트레이드 오프를 통해 이해하기 쉬운 설계를 챙기는 것도 방법이라는 답변을 받은 적이 있었습니다.

오브젝트는 객체 지향에 대한 찐한 설명 뿐만 아니라 최대한 객체 지향을 챙긴 설계에서 오는 문제점과 트레이드 오프의 중요성, 잘못 설계한 코드에서 발생하는 문제점까지도 상세하게 설명하고 있습니다. 때문에 객체 지향에 대해서 조금이라도 더 이해하고 싶다면 오브젝트를 통해서 부족한 부분을 보충할 수 있을 것이라 생각합니다.

이와 별개로 경험이 부족한 탓인지 명확하게 이해하지 못한 내용도 종종 있었습니다. 한 번으로 끝내는 책이 아닌 가끔 꺼내 읽으면서 돌아보는 시간을 가지면 더 도움이 되리라 느낍니다.

스터디에 대해서

가장 아쉬운 점이 하나 있다면 스터디 기간입니다. 조금 더 빡세게 진행해서 최소 한 주에 2챕터 씩은 쭉쭉 치고 나갔어야 한다는 생각을 합니다. 스터디 병행의 어려움으로 스터디원이 한 사람씩 빠져나가고, 어떤 주차는 예비군, 코로나 등의 개인 이슈가 겹쳐 참여 인원이 너무 적어 스터디를 쉬게 되는 경우가 생겨났습니다. 그래도 어떻게든 스터디를 진행한다고 했을 때는 2명이서 진행하기도 했습니다.

좋았던 점은 제가 이해하고 정리한 바를 팀원과 공유하면서 다시 한 번 확인하는 시간을 가질 수 있었다는 점입니다. 다른 사람의 어려웠던 부분에 대해서 각자 어떻게 이해했는지 생각을 나누고 자신의 경험에 비추어보면서 좀 더 나은 설계에 대해서 고민하는 시간은 책의 내용을 이해하는데 좀 더 도움이 되었습니다. 개인의 경험과 프로젝트에서 담당한 역할들이 다양하다보니 프로젝트와 병행하는 것이 도움이 되는 부분들도 있었습니다.

최종적으로 전반기 스터디를 포함해서 시작할 때 7명이었던 인원은 마지막 스터디 때는 참여 인원이 3명까지 줄어들었습니다. 그래도 제 첫번째 스터디를 시작부터 끝까지 마무리지었다는 것은 다행입니다. 다시 스터디에 참여하거나 직접 꾸리게 된다면 좀 더 빡빡한 일정을 잡아봐야겠습니다.