Ubiquitous Language의 효용성
실전 시스템 수준 리팩토링 사례 12회
제 관심사에 치우쳐서 전문용어의 늪으로 빠지는 것을 우려하여 하지 않았던 이야기가 있습니다. 하지만, 기부상태 UL로 만들어보기 등의 글에서 Ubiquitous Language라는 표현을 명확한 정의없이 써왔습니다. 이 글에서는 Ubiquitous Language 개념을 다루기로 하겠습니다.
Ubiquitous Language 란 무엇인가?
인터넷에서 좋은 그림을 발견했습니다. DDD 책을 읽은지 오래 되어서 책에서도 이렇게 묘사했나 기억이 나지 않습니다. 제가 쓰는 연재 글에서 기부 혹은 기부상태 등이 점선으로 표기한 부분에 해당합니다. 기부 혹은 기부 상태를 다루는 많은 말들이 Ubiquitous Language이고, 이를 묶는 개념인 기부가 다시 Bouned Context 입니다.
일단, 원문의 Ubiquitous Language 정의를 다시 보겠습니다.
Ubiquitous Language is modeled within a Limited context, where the terms and concepts of the business domain are identified, and there should be no ambiguity.
within a Limited context를 영문 그대로 해석하지 말고, 우리 상황에 맞춰서로 이해하세요. 하지만, 이미 의사소통 수단으로 자연어(한글)와 프로그래밍 언어 등을 쓰는 상황에서 별도로 규정한 언어를 도입하려면 분명한 가치가 있어야 합니다. 사람들은 가치를 느끼지 못하면 따르지 않습니다.
게다가 각자 자신의 가치가 있습니다. 주관적이죠. 자연스러운 일입니다. 그렇기 때문에 위 정의에서 두 가지 표현을 강조하고 싶습니다. 하나는, Limited와 identified를 묶어서 두 번째는 should be no ambiguity 입니다.
맥락 제한의 필요성
먼저 용어나 개념을 식별(identified)했다고 하더라 그 말이 특정짓는 특수한 맥락(Limited context)이 없다면 굳이 그 말을 쓸 이유가 사라집니다. 딱 그 단어를 썼을 때, 맥락이 공유된다면 소통이 쉬워집니다. 사실, 어떤 현장에서도 그런 개념이나 용어 몇 개 정도는 존재하기 마련입니다. 굳이 Ubiquitous Language라는 표현 따위를 쓰지 않아도 말이죠.
하지만, 누군가 모호하게 그 말을 오염시키기 시작하면 Ubiquitous Language로써의 효과는 뚝 떨어질 수 있습니다. 우리가 일하는 현장의 영역에는 굉장히 포괄적인 정보들이 맥락을 구성합니다. 대충 생각해도 아래와 같은 내용들이 암묵적으로 우리의 대화 속에 들어 있습니다.
현재의 비즈니스
그리고, 숨겨진 레거시(일부만 아는 형태로 남아있는) 규칙
가까운 미래의 비즈니스
우리 팀의 작명 습관
개발자들의 코딩 스타일
우리의 업무량
연동하는 시스템에 따른 제약
언제 Ubiquitous Language를 쓸까?
언어가 의사소통 수단이란 점을 다시 상기하세요. 그렇다면, 적어도 그냥 한글을 쓰는 일보다는 이점이 있어야 합니다. 짧은 단어 한마디가 무언가를 내포하게 해야 합니다. 그래야 쓰죠. 제가 Ubiquitous Language라는 개념 소개를 전혀 하지 않고, 실제 개발조직에 보급하는 일을 떠올려보면 복잡한 상태를 갖는 개념에 이를 도입하면 매우 효과적입니다.
그때, 기준은 간단합니다. 명쾌하게 하는 방법으로 씁니다. 장황한 설명이 필요한 일에 대해 사용합니다. 이를 테면, 기부 상태가 불분명할 때는 해당 프로그램의 if 문을 작성했거나 복잡한 조건절의 SQL을 작성한 개발자만이 해당 부분을 알았습니다. 운영자가 화면을 보면서 파악한 규칙과 다른데 이를 설명할 방법을 찾지 못했고, 개발자도 명쾌하게 말로 설명하지 못하는 상황이었습니다.
이때, 함께 대화를 통해서 (여러 차례, 게시판 대화와 대면 회의 등으로) 아래 두 개의 상태를 명확하게 정의했습니다.
물품 등록 완료
(기부금액) 평가 완료
이렇게 했더니 대화가 간편해집니다. 물품 등록 완료된 후에야 사용자는 기부 확인서를 발급할 수 있습니다. 평가 완료가 된 후에야 비로소 기부 영수증 신청이 가능해집니다. 화면의 상태 변화, 사용자 이벤트 가능 여부 등의 프로그램 로직 논의가 해당 코드를 작성하지 않는 사람들과 가능해집니다. 바로 이러한 의사소통의 명료함이 Ubiquitous Language가 지향하는 목표죠.
