프로그래밍에서는 몰라도 설계에서 작명은 엄청 중요하다
설계: 생각을 ‘차려’ 물질로 만드는 힘
프로그래밍에서 이름은 굉장히 중요한 역할을 합니다. 그러나 많은 개발자들이 과소평가하고 있다고 생각합니다.
하지만, 달리 생각해 보면 설계에 진심이어야 맥락이 보이고, 그래야 디자이너가 디자인하듯이 주변과 조화로운 작명에 힘을 쓸 동기가 생기겠구나 싶었습니다. 그러니 좋은 작명은 어쩌면 설계의 영역일 수도 있겠습니다.
이 글은 최근에 작명에 대해 생각하게 만든 세 개의 사건을 다룹니다. 이를 통해 받은 영감이 독자 여러분께도 전달되길 빌면서...
아... 인감 수정이요?
최근 법인 관련 업무를 하면서 인감도장과 인감 증명서가 필요한 일이 생겼습니다. 수년간 인감도장을 챙기지 않았더니 온 방을 뒤지는 일이 발생했습니다. 가까스로 비슷한 도장을 챙기고 인감 증명서를 발급했는데, 아뿔싸! 비슷하게 생겼을 뿐 인감도장이 아니었습니다.
서류에 찍고 난 후에야 발견했기 때문에 가장 간편한 방법은 그 도장이 인감이 되게 만들고, 인감 증명서를 새로 발급하는 일이었습니다.
주민 센터에 갔는데, 창구에서 제 차례가 되었습니다. '인감'까지만 말하고 뭐라고 해야 하나 생각하는데, 민원 담당자가 인감 증명서 발급받으러 왔냐고 물었습니다. 그게 아니고, 이 도장을 인감으로 바꾸고 다시 증명서를 발급받고 싶다고 말했더니, 창구에서 '아... 인감 수정이요?'라고 대답했습니다.
저는 설계 덕후답게 머릿속으로 이렇게 속말을 했습니다.
아, 이게 바로 도메인 용어(Domain Specific Language)의 효용성이구나!
주민센터에서 DSL 효용성을 깨닫다
잠시 위키피디아에서 DSL의 정의를 살펴보겠습니다.
A domain-specific language (DSL) is a computer language specialized to a particular application domain.
물론, 주민센터에서 DSL을 쓸 리는 없습니다. '인감 수정'이라는 말이 컴퓨터 언어(computer language)는 더더욱 아니고요. 하지만, 제가 DSL 효용성을 깨달았다는 말은 언어에 담는 '간명한 전달력'에 대한 느낌을 설계 덕후답게 익숙한 용어와 함께 머릿속에 떠올렸다는 의미입니다.
다만, 'domain-specific'을 상황에 맞춰(for instance) '주민센터에서'라고 바꿔본다고 상상해 보겠습니다. 다른 곳에서는 통용되지 않거나 맥락에 닿지 않을 수 있는데, 주민센터라는 영역(domain)에서는 특별히(specific) 바로 소통이 되는 말(language)이라고 새길 수 있다면 제가 무엇을 느꼈는지 아실 수 있습니다.
Bounded Context의 기능과 효용성 이해하기
독자 님들의 이해를 위해 DSL로 설명했지만, 사실 링크드인에서 본(두 번째 사건) 글 때문에 머릿속에 떠올린 단어는 다른 것이었습니다. 링크드인에서 주로 보는 Vaughn Vernon의 글의 잔상이죠.
그는 DDD를 알고 있다고 주장하는 사람들조차 Ubiquitous Language(이하 UL)에 대해 오해한다고 말합니다. 오해의 내용은 UL을 하나의 Bounded Context에 국한된 것으로 사용해야 하는데
A Ubiquitous Language is 100% within a single Bounded Context.
그게 아니라 마치 조직 전체 혹은 시스템의 표준 용어처럼 쓴다는 점을 지적했습니다. 전에 썼던 <입장에 맞춰 맥락을 나눈 BoundedContext>를 보니 이를 도식화한 그림이 있습니다.
출처: https://thedomaindrivendesign.io/developing-the-ubiquitous-language/수문장과 단일 트랜잭션으로 하지 않기
작명에 얽힌 나머지 하나의 사건이 더 있습니다. 동료와 개발 대상을 두고 의견을 나누는데 제가 상상하는 바를 말로 표현하려고 애를 쓰다가 이를 담은 이름이 필요해 ProudctInfoGuardian이란 말을 지어냈습니다.
첫 제안이니 개선의 여지가 있을 이름이지만, 왜 ProudctInfoGuardian이라고 했는지 스스로에게 물었습니다. 상품 정보를 어떻게 다루고 사용자의 정보 가공과 편집 절차에 대해 포괄적으로 논의하는 과정이었습니다. 그러니 ProudctInfo- 라는 접두어 혹은 낱말 조합이 들어가는 일은 자연스럽습니다. 대화의 맥락이기도 하니까요. 그런데 마지막에 고심 끝에 내놓은 Guardian이라는 씨말[1]은 왜 넣었을까요?
대화 중에 머릿속에 먼저 떠오른 이미지는 수문장(혹은 문지기)이었습니다. 거기서 관행에 따라 영어 단어 조합으로 축약하려는 가운데에 즉흥적으로 선택한 단어가 Guardian이죠.
그런데 같은 대화를 두고 동료가 남긴 기록을 보니 ProudctInfoGuardian이 등장하는 배경을 두고 '단일 트랜젝션으로 하지 않기'라고 표현했습니다. 흥미로왔습니다. 저는 트랜젝션이란 말을 쓴 기억이 없고, 트랜젝션을 떠올린 일도 없습니다. 그런데 제가 말한 내용들을 동료가 받아들일 때에는 '트랜젝션'이란 개념을 두고 수용했다는 사실이니까요.
다시 생각해 보니 상품 정보 엔터티로 DBMS에 단번에 반영하지 말라는 프로그래밍 맥락에서 이해했다고 유추할 수 있었습니다. 느슨하게 연결되는 기분이었습니다. 저라면 그렇게 표현하지 않겠지만, 제가 의도한 바를 구현하는 입장에서 자신이 구현할 때 바로 떠올릴 수 있는 말로 나타낸 것이니 서로 똑같은 것을 인식하지 않더라도 문제는 없었습니다.
이쯤에서 세 가지 사건을 하나의 메시지로 꿰어 보겠습니다. 구슬이 서 말이라도 꿰어야 한다고 하니. 먼저 주민센터 체험에서 '인감 수정'이라는 한 마디로 복잡하고 장황한 설명을 간소화할 수 있는 장면을 경험했습니다. 거기서 연상 작용으로 DSL을 떠올렸으나 DSL은 특정 영역(Domain)을 국한해 소통하기 때문에 오히려 그 범위를 명확하게 좁힐수록 위력을 발휘합니다. 그래서 DDD에서 말하는 UL은 명확하게 구획을 만든 Bounded Context 하에서 효과를 발휘합니다.
Bounded Context가 개발자와 비즈니스를 담당하는 사람이 함께 쓰이는 지식의 영역일 때 DDD와 같은 복잡한 지식 체계를 쓰는 효용성이 커집니다. 이를 위해서는 Bounded Context 안에 비즈니스 정의, 규칙, 정책 따위가 담긴 개념들이 언어로서 자리하고 코드에도 그대로 대응시킬 수 있다면 소통 능력이 높아집니다.
설계란 결국 번역인가?
여기서 지난 글 말미에 떠올렸던 질문을 반복해 보겠습니다.
설계란 결국 번역인가?
그렇다면, 번역이 필요 없는 서로 이해하는 단어를 만들수록 소통은 고도화됩니다. 왜냐하면 양자가 이해하는 단어는 번역이 필요 없고, 그 단어를 둘러싼 소통을 하는 영역으로 설계 업무가 발전할 테니까요.
성공적 대화를 돕는 그림을 소환해서 수정해 보겠습니다.
키노트 파일 재사용을 하려고 찾다가 못 찾고 대신 비슷한 시도를 했던 다른 글을 발견했습니다. <관리 요소 식별을 위한 조기 시각화의 필요성>에서 이미 눈에 보이는 데이터를 대상으로 관심사에 따른 서로 다른 관점을 표현한 바 있습니다.
물론, 이번에는 그와 조금은 다른 맥락이긴 합니다. 서로 다른 녀김에 대한 문제이니 <같은 현상도 서로 다른 일로 인식할 수 있으니 차리기>에 썼던 그런 내용이겠네요.
다만, 중요한 내용은 언어를 같이 하는 사람 혹은 집단을 기준으로 1에서 N으로 커지는 관점으로 번역을 하는 일이라 할 수 있겠습니다. 굳이 숫자를 넣은 이유는 4+1이라는 소프트웨어 모델링 분야의 일종의 레토릭 때문입니다.
주석
[1] 낱말의 최소 구성 요소로 제안된 말로써 <말과 마디말에 대하여>에서 그 기원과 의미를 알 수 있습니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법
