객체의 상태와 엔티티
실전 시스템 수준 리팩토링 사례 5회
3회에서 다뤘던 화이트보드 메모를 다시 보겠습니다. 화이트보드에 그렸던 그림을 사진으로 찍어서 협업시스템(두레이)에 올리면서 기부 프로세스 설명을 시도하는 표를 만들어봤습니다. 당시 회의에 참여했던 분들이 다수라 전달이 안된 내용이 있을 것이고, 그때 생각이 났어도 하지 못한 이야기들을 나눌 목적이죠.
누군가에게 설명해보기
많이 경험해보셨겠지만, 누군가에게 설명을 해보는 것이나 이를 위해 기록을 시도하는 일은 매우 유용합니다. 아주 간단해 보이는 내용도 실제로 해보면 명확한 설명이 예상보다 쉽지 않습니다. 아무튼 시도해보니 아래와 같이 모호하거나 역할 정의가 불분명해 보이는 부분을 포착했습니다. 훌륭한 의사소통 꺼리을 잡아낸 듯합니다.
피드백의 실제 효과
한편, 이렇게 협업 시스템에 글을 올리면서 3편에 아래 코멘트로 등장한 프론트 개발자에게 3편 (브런치) 글을 보여줬더니 그가 아래와 같은 댓글을 올렸습니다. 또 다른 대화가 이어지는 것이죠.
다음으로 이해했는데 내용이 맞을까요?
1. 물품이 접수, 분류, 생산의 상태를 거친다.
2. 그 상태들을 결정하는 것이 촉발자의 역할이다.
3. 촉발자의 역할인 상태 결정을 돕는 행위가 User interface이다.
이해한 내용이 맞다면 다음과 같은 답답함으로 질문과 생각이 정리가 되지 않습니다. 저는 현재 user 페이지만 작업을 해왔기에 `접수` 상태만 이해도가 있습니다. `분류`와 `생산` 상태의 작업은 admin 화면에서 이루어지는 일이라 생각하고 있습니다. 두 가지의 상태를 각각 책임지는 촉발자들의 역할(매장 매니저, 되살림터 간사 등)에 대한 정확한 이해(촉발자의 역할에 따라 보이는 화면, 사용 가능한 기능 등)가 없습니다. User interface에 대한 생각 또한 쉽게 떠오르지가 않습니다. ...
글을 읽어 보고 협업 시스템에 아래와 같이 답을 올렸습니다.
협업시스템과 두레이를 오가며 피드백이 의사소통과 교감을 촉진하는 모습입니다. 제가 즉흥적으로 그렸던 화이트보드 그림을 나중에 글을 쓰며 다시 보니 상태도라고 하기에는 맥락이나 대상이 모호하다는 생각을 했는데 피드백 과정에서 프론트 개발자가 무엇의 상태인지에 대해 혼선을 겪는 모습이 보이니 이거다 싶은 느낌이 들었습니다. 무엇의 상태인지를 명확하게 하여 상태도를 정제할 필요가 있구나 확인하는 순간입니다. 게다가 소통할 대상이 분명해졌으니 말과 글이 힘을 얻을 상황입니다.
기부 행위와 기부 물품 상태 관리 구분하기
지금까지 의사소통과 비대면 협업 과정에 초점을 맞춰 설명을 했습니다. 이제는 다시 상태 표현으로 돌아가 보겠습니다. 먼저 원활한 설명을 위해 업무 도메인에 대한 설명이 필요해 보입니다. 아름다운가게는 물품기부를 통해 소외 이웃을 돕고 환경을 보호하는 대표적인 NGO입니다.
보통 기부자들이 박스에 기부할 물건을 담아 매장이나 편의점에서 기부할 수 있습니다. 이때는 자연스럽게 여러 개의 물품을 한 번에 보낼 수 있겠죠. 반면에 소외 계층에 전달하거나 아름다운가게 매장에서 판매할 때는 개별 물품 단위로 취급해야 합니다.
화이트보드에 그린 그림은 기부 물품이 생산이라고 불리는 매장 판매가 가능한 형태로 바뀌는 절차를 그린 것이지만, 엄밀히 말해 상태도라고 하기에는 무엇의 상태인지가 불분명합니다. 그래서, 위 도식에서 보듯이 기부라는 단위와 물품의 단위는 구분되어야 합니다.
기부 객체 상태도로 변경
일단, 위 그림에서 기부 수령 이후에 물품을 취급하는 단계의 내용은 생략하기로 합니다. 결과적으로 상태도의 맥락을 기부로 한정합니다. 여기서 맥락이란 상태도가 무엇의 상태 변화를 그린 것이냐를 뜻합니다. UML은 객체라는 개념을 기반으로 하기 때문에 상태도라고 하면 보통은 객체의 상태를 말합니다. 앞서 단위나 맥락 같은 말을 했는데, 그걸 객체라고 부르는 식이죠. 엄밀한 개념 정의는 당장 필요하지 않기 때문에 단위, 맥락, 객체가 다 비슷한 말이라고 해두죠.
새로 그린 기부 (객체) 상태도를 보여드립니다. plant UML 상태도 설명을 보고 객체 경계를 표현하는 방법으로 상태 안에 상태를 넣었습니다. 엄밀한 UML 표기법은 아니지만, 의사소통에는 문제가 없습니다. 바깥에 그린 기부가 바로 객체를 나타냅니다. 즉, 기부라는 행위의 상태를 표현하겠다고 단위(혹은 맥락)를 설정한 것이죠.
기부를 행위라고 했습니다만, 시스템으로 구현해야 하기에 그냥 행위로 둘 수는 없습니다. 왜냐하면 상태도에서 보이듯이 행위에 대한 기록과 기부한 물품의 가액을 판정하는 등의 후속 행위가 이어져야 하고, 증빙을 위한 서류나 영수증 발급도 필요하기 때문이죠.
이런 행위들이 제때 벌어지게 하기 위해 현재 어디까지 진행이 되었는가 하는 정보를 상태로 표현할 수 있습니다. 이때 행위와 상태를 모두 담기 위해 기부를 객체로 정의할 수 있습니다. 이렇게 객체라는 개념을 설계 단위나 프로그래밍 단위로 사용하는 방법을 객체 지향(object-orientation)이라고 합니다.
DDD 빌딩블록 엔티티
한편, 식별이 가능한 레코드를 저장하는 단위를 흔히 엔티티(entity)라고 부릅니다. 데이터 모델링할 때 쓰는 표현이기도 하지만, 객체 지향 진영에서도 똑같은 개념이 있습니다. Domain Driven Design 책은 객체의 한 형태로 엔티티를 다음과 같이 정의를 합니다.
Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.
속성들로 정의하지 않고, 지속성과 정체성으로 정의되는 객체라고 짤막하지만 핵심을 간파한 정의입니다. 물론, 책에는 상세한 설명이 있지만, 여기서는 상태와 엔티티의 특성만을 살펴봅니다. 다양한 속성으로 정의되지 않는다(not defined by their attributes)는 표현이 먼저 봅시다. 다양한 속성의 현재 조합이 바로 객체의 상태를 나타내는 보편적인 방법입니다.
여러분의 이해를 돕기 위해 비유적 설명을 덧붙입니다. 우리는 일상에서 이런 표현을 자주 씁니다.
너 요즘 어때? 지금 날씨가 어때?
객체지향은 프로그램 구성단위를 위와 같이 우리가 사물을 인지하는 방식에 걸맞게 매핑하는 방식이라고 할 수 있습니다. 나의 상태와 날씨는 나와 날씨를 구성하는 다양한 속성들의 현재 값의 조합입니다. 그리고 매번 바뀌죠. 그래서 정체성이란 개념이 필요합니다. 인간사회에서는 많은 것들에 번호를 붙이죠. 우리에게도 주민번호가 있고, 스스로는 자기 정체성을 알지만 다수의 객체가 있을 때 그 정체성을 구분하기 위해서는 식별번호가 필요한 것입니다.
자, 여기까지 설명으로 여러분의 엔티티의 개념과 함께 변하지 않는 식별번호(혹은 식별자)와 끊임없이 바뀌는 상태의 관계에 대해 어느 정도 감이 잡히셨기를 바라겠습니다.
