Value Object 이전에 Object란 사실
지식 덕후의 탄생
좋아하는 조영호 님의 포스트를 보고 그냥 넘어가지 못하고 일종의 글로 쓰는 수다입니다.
문장 이해를 이해서는 맥락부터 분명히 해야 한다
제 눈길을 사로잡은 글은 다음 포기말(=문장)입니다.
설계 관점에서 우리가 다루는 모든 것은 의미(semantic) 수준과 구현(implementation) 수준을 함께 고민해야 하고 값 객체 역시 예외는 아닙니다.
멋진 이분법입니다. 다른 내용에 앞서 이 문장에 특별히 끌리는 이유는 제가 설계 덕후이기 때문이죠. 여기에 한 가지 이유를 덧붙일 수 있습니다. 직전에 읽었던 페벗님의 글에 포함된 표현이 영향을 끼쳤습니다.
Gemini 1.5 Pro의 Context Caching(CC) vs. Claude Sonnet 3.5의 Prompt Caching(PC)
페벗님의 글을 읽자 자연스럽게 전날 지인이 ChatGPT와 대화를 이용해 시놉시스를 쓰는 장면이 떠올랐습니다. 그래서, Context Caching 혹은 Prompt Caching의 쓰임새를 상상해 본 잠깐의 시간이 있었습니다. 그 후에 조영호 님의 글의 보니 문장의 뜻을 이해할 때, 맥락부터 살펴야 한다는 점을 꼬집은 듯해 무릎을 치는 심정이 되었던 것이죠.
글에 맥락이란 단어는 없지만, 의미 수준과 구현 수준이라는 이분법은 분명 맥락을 명확하게 하는 훌륭한 설명이라 생각합니다.
더불어 오래된 기억을 자극하기도 했습니다. UML 모델링을 열심히 하던 시절, 데이터 모델은 명확하게 세 가지 타입으로 나누는 방식이 꽤 마음에 든다고 생각했습니다. 그렇게 셋으로 나누는 행위의 기원이 어딘가 찾아보았습니다.[1] 위키피디아를 보니 다음 책인 듯합니다.
Simison, Graeme. C. & Witt, Graham. C. (2005). Data Modeling Essentials. 3rd Edition. Morgan Kaufmann Publishers. ISBN 0-12-644551-6
아무튼 관점(viewpoint)나 추상화 수준을 둘 중 하나로 나누면 맥락이 분명해집니다. 마치 이런 질문을 하는 효과가 생기죠.
어떤 상황을 말하는 거야?
코드 작성할 때를 말하는 거야? 아니면 단순히 의미 수준에서 그렇다는 거야?
Value Object 이전에 Object란 사실
이 글을 쓰기 위해 조영호 님의 글을 다시 보는데 이번에는 아래 포기말이 눈에 띄었습니다.
값 객체는 데이터와 달리 행동 중심이며(따라서 추상화를 위한 도구) 흔히 말하는 Rich Domain Model을 더 명확하게 표현하면서도 복잡성을 낮추기 위한 용도로 사용됩니다.
멋진 내용인데, 배경 지식 충전(?)을 위해서 DDD 책을 펼치게 되었습니다. Value Objects 설명 첫 줄에 나오는 두 포기말은 아름답다는 생각을 하게 합니다. ;)
Many objects have no conceptual identity. These objects describe some characteristic of a thing.
멋진 개념 정의이지만, 제가 책을 펼친 이유는 '값 객체는 데이터와 달리 행동 중심이며'라는 매듭말[2]의 기원을 찾기 위함이었습니다. 그래서 훑어보니 다음 내용이다 싶었습니다.
When you care only about the attributes of an element of the model, classifiy it as a VALUE OBJECT. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the VALUE OBJECT as immutable. Don't give it any identity and avoid the design complexities necessary to maintain ENTITIES.
'그렇구나' 하면서 (프로그래밍 맥락에서) 객체라는 기본 개념의 정의가 떠올랐습니다. 객체 개념을 쓰지 않는다면, 변수에 보관하는 값일 뿐인 내용에 지나지 않는 문제가 복잡하게 Value Object 같은 파생 개념으로 다뤄지는 것이니까요. 그래서 위키피디아 객체 정의를 다시 찾아보았습니다.
In computer science, an object is a programming element that has state, has associated operations and is accessed via an identifier.
'associated operations'을 갖는 것이 바로 객체라는 아주 기본적인 사실을 재확인합니다.
DDD의 Value Object 말고 마틴 파울러가 정의한 Value Object
한편, 이 글을 쓰기 전에는 주목하지 않았던 내용이 눈에 띕니다.
쓰레드에서는 아래 글을 인용하고 있는데 위에 적은 내용을 감안해서 글을 읽으시면 이해하기가 쉬울 거예요.
https://martinfowler.com/bliki/ValueObject.html...
이번에는 조영호 님의 글에서 힌트를 얻어 'beh'(영어로 쓰인 '행동 중심' 관련 내용 찾기 위해)로 문서를 검색했습니다. 빙고! 찾았습니다.
마틴 파울러가 예로 든 Range class를 보니 다 읽을 것도 없이 바로 이해가 되었습니다. 범위로 묶이는 값을 한 번에 다룰 때라면 클래스를 만드는 것이 객체 지향 프로그래밍을 하는 혜택을 보는 방법이죠.
가령 위와 같이 만들면 특정 값이 범위(Range) 안에 드는지 쉽게 확인할 수 있는 기능 혹은 행위를 객체로 묶어서 쓸 수 있습니다.
주석
[1] 찾는 과정에서 위키피디아에서 View model 페이지를 살펴보는 계기가 되었습니다. <자기중심에서 팀 중심으로 확대하기>에 썼던 '번역'이란 관점에서 뜻하지 않은 영감을 받을 수 있었는데, 이에 대해서는 <
설계: 생각을 ‘차려’ 물질로 만드는 힘> 연재 글로 나중에 쓰겠습니다.
[2] <한국말 말차림법>에서 제안한 어구에 대한 토박이 말입니다. 왜 매듭말인지는 <언어에 대한 일반이론>에서 일부 답을 얻을 수 있습니다.
지난 지식 덕후의 탄생 연재
8. 늘어나는 AI 고용주(?)와 생각의 자동화라는 부작용
