도메인 지식이 왜 방어선인가

같은 화면을 보고 다른 것을 읽는 사람
도메인 지식이 왜 방어선인가
업을 아는 엔지니어가 다르게 하는 세 가지
용어가 어긋나면 코드가 어긋납니다
도메인을 익히는 여섯 단계
도메인 지식이 안 통하는 자리
시리즈를 한 문장으로
직접 해보기
이어서 읽기
참고 자료

같은 화면을 보고 다른 것을 읽는 사람

구성한 예시입니다. 주문 취소 기능에 조건이 하나 붙어 있습니다. 출고 상태에서는 취소가 안 되고 반품으로 넘어갑니다. 코드만 아는 사람은 이것을 상태 전이 규칙으로 읽습니다. 업을 아는 사람은 출고 시점에 창고로 작업 지시가 이미 나갔고, 그 지시를 되돌리려면 창고의 사람이 손으로 잡아야 하며, 잡을 수 있는 시간이 몇 분인지에 따라 이 규칙의 경계가 정해졌다는 것을 압니다.

두 사람의 차이는 이 기능을 고칠 때는 잘 안 드러납니다. 이 기능을 바꿔도 되는지 판정할 때 드러납니다.

1편에서 검증을 비싸게 만드는 첫 번째 요인으로 암묵적 맥락을 꼽았는데, 도메인 지식이 바로 그것입니다. 코드에 없고, 문서에도 대개 없고, 사람의 기억과 조직의 관행에만 있습니다.

3편에서 인용한 Brooks의 구분으로 옮기면 도메인 규칙은 우연적 복잡성이 아니라 본질적 복잡성입니다. 사용자가 서른 가지 일을 원하면 그 서른 가지는 문제 자체에서 나온 것이라 없앨 수 없다는 것이 그의 예시였습니다. 도구를 바꿔도 이쪽은 줄지 않습니다.

다만 방어선이라는 말이 남을 막는 해자로 읽히면 곤란합니다. 도메인 지식이 값어치를 갖는 이유는 희소해서가 아니라 그것 없이는 판정이 불가능하기 때문입니다. 그래서 이 지식은 나눠 준다고 줄지 않고, 오히려 나눠 줄 수 있는 형태로 만드는 일이 이 능력의 절반입니다.

업을 아는 엔지니어가 다르게 하는 세 가지

첫째, 질문의 종류가 다릅니다. 기술만 아는 쪽은 이 필드가 무슨 뜻이냐고 묻습니다. 업을 아는 쪽은 이 값이 비어 있는 주문이 실제로 있느냐고, 있다면 어떤 경우냐고 묻습니다. 두 번째 질문이 데이터의 진짜 모양을 꺼냅니다.

둘째, 예외를 대하는 태도가 다릅니다. 이상한 예외 조항을 보면 기술만 아는 쪽은 지저분하다고 느끼고 정리하고 싶어 합니다. 업을 아는 쪽은 이 조항이 어떤 사고의 흔적인지 먼저 묻습니다. 그런 조항은 대개 누군가 손해를 본 다음에 생겼고, 지우면 그 손해가 돌아옵니다.

셋째, 무엇이 진짜 요구인지 구별합니다. 6편에서 요구는 해결책의 모습으로 도착한다고 했는데, 그 번역을 되돌리려면 도메인을 알아야 합니다. 모르면 되물어도 돌아온 답을 이해하지 못합니다.

용어가 어긋나면 코드가 어긋납니다

도메인을 코드로 옮기는 지점에서 가장 자주 깨지는 것은 용어입니다.

Eric Evans가 도메인 주도 설계에서 제시한 유비쿼터스 언어가 이 문제를 다룹니다. Martin Fowler의 정리에 따르면 이것은 개발자와 사용자 사이에 공통되고 엄밀한 언어를 세우는 실천이며, 그 언어가 도메인 모델에 뿌리를 두어야 하는 이유는 소프트웨어가 모호함을 잘 다루지 못하기 때문입니다. 같은 글은 Evans를 인용해 역할을 나눕니다. 도메인 전문가는 이해를 전달하기에 어색하거나 부족한 용어에 이의를 제기하고, 개발자는 설계를 걸어 넘어뜨릴 모호함과 비일관성을 살핀다는 것입니다.

이게 안 되고 있다는 신호는 단순합니다. 회의에서 쓰는 단어와 코드에 있는 이름이 다르면 그 차이만큼 매번 번역이 일어나고, 번역은 매번 오역의 기회입니다.

예시 — 용어 대조표

사업 쪽 말   코드에 있는 이름                 같은 것인가
정산         settlement, payout, clearing     확인 필요. 셋으로 나뉜 이유가 있나
출고         shipped                          같음
반품         return, refund                   다름. 물건과 돈이 따로 움직임

위험한 것은 첫 줄 같은 자리입니다. 사업 쪽에서 한 단어로 부르는 것이 코드에서 셋으로 나뉘어 있는데 아무도 그 차이를 문장으로 갖고 있지 않다면, 거기서 틀린 값이 나옵니다.

도메인을 익히는 여섯 단계

용어를 수집합니다. 회의록, 화면, 고객이 보낸 메일에서 나온 명사를 판단 없이 모읍니다.
같은 말과 다른 말을 가릅니다. 다른 단어가 같은 것을 가리키면 합치고, 같은 단어를 두 부서가 다르게 쓰면 나눕니다. 두 번째가 가장 값어치 있는 발견입니다.
사물과 사건을 나눕니다. 지속되는 대상인지 특정 시점에 일어난 일인지 가릅니다. 이 구분이 데이터 모델의 뼈대입니다.
관계에 개수를 붙입니다. 하나에 하나인지, 하나에 여럿인지, 여럿에 여럿인지. 여기서 오해가 가장 많이 나옵니다.
검증 질문을 만듭니다. 모델이 맞다면 답할 수 있어야 하는 질문 다섯 개를 도메인 전문가에게 물어봅니다. 답이 막히면 모델이 틀린 것입니다.
예외를 사냥합니다. 이 규칙이 안 맞는 경우가 있느냐고 반복해 묻습니다. 예외가 안 나오는 도메인은 아직 덜 파인 것입니다.

가장 자주 건너뛰는 것이 다섯 번째입니다. 모델을 그리는 데까지는 다들 가고, 그 모델로 답할 수 없는 질문을 찾는 데까지는 잘 안 갑니다. 4편의 표현으로는 모델을 그리는 것이 생성이고, 검증 질문을 만드는 것이 판정의 설계입니다.

도메인 지식이 안 통하는 자리

정직하게 적어야 할 한계가 세 가지 있습니다.

첫째, 이월이 잘 안 됩니다. 10년 쌓은 물류 도메인은 다른 업으로 옮기면 상당 부분 버려집니다. 그래서 도메인에만 투자하는 것은 위험하고, 앞의 아홉 편에서 다룬 이월되는 능력들과 함께 가야 합니다.

둘째, 업 자체가 줄어드는 경우가 있습니다. 깊이가 깊을수록 이 위험은 커지므로, 도메인을 고를 때 그 업이 어디로 가는지는 기술 선택만큼 중요한 질문입니다.

셋째, 과적합이 있습니다. 한 업에 오래 있으면 그 업의 관행을 물리 법칙으로 착각하기 쉽습니다. 원래 이렇게 한다는 말이 자기 입에서 나오면 점검할 때입니다. 이유를 문장으로 댈 수 없다면 그건 이유가 아니라 습관입니다.

시리즈를 한 문장으로

열 편을 한 문장으로 줄이면 이렇습니다. 값이 남는 기술은 검증 비용이 비싼 기술이고, 엔지니어의 일은 그 비싼 판정을 싼 판정으로 바꾸는 장치를 설계하는 것입니다. 디버깅, 읽기, 테스트, 쓰기, 문제 정의, 운영, 위임, 학습, 도메인은 전부 이 문장의 다른 얼굴이었습니다.

도구 목록으로 답하지 않은 이유도 여기 있습니다. 목록은 낡고 판별식은 덜 낡습니다. 다음에 새 도구가 나올 때 물어야 할 질문은 두 개입니다. 이것이 무엇을 싸게 만드는가. 그래서 무엇의 판정이 비싸게 남는가.

직접 해보기

이번 주에 자기 팀의 도메인 용어 열 개를 적고, 사업 쪽 사람이 쓰는 말과 코드에 있는 이름을 나란히 적어 보세요. 30분이면 됩니다. 다른 칸이 하나라도 나오면 그 자리가 번역이 일어나는 지점이고, 거기서 조용히 틀린 값이 나옵니다.

FDE 엔지니어 키우기 RPG — 도메인 분석과 온톨로지 작성 코스가 위 여섯 단계를 그대로 훈련합니다. 제조 MES, 물류, 금융 여신 세 개 가상 업계에서 이해관계자 인터뷰를 읽고 용어를 정규화한 뒤, 객체 타입과 속성과 링크 타입을 카디널리티까지 붙여 조립하고 검증 질문으로 모델을 시험합니다.
협업 RPG — 도메인은 결국 사람에게서 옵니다. 묻는 선택과 미룬 대화가 몇 주 뒤에 어떤 값으로 돌아오는지를 시간차로 보여 줍니다.

안 통하는 경우도 적어 둡니다. 몇 주짜리 작업으로 들어간 자리에서 도메인을 깊게 파는 것은 회수가 안 됩니다. 그때는 3편의 결론과 같습니다. 이해가 아니라 경계만 파악하면 됩니다.

이어서 읽기

이 블로그의 관련 글: 고객의 도메인을 모델로 — 유비쿼터스 언어에서 온톨로지까지

비싸게 남는 기술 시리즈

참고 자료

Ubiquitous Language — Martin Fowler — 공통되고 엄밀한 언어를 세우는 실천이라는 정의, 소프트웨어가 모호함을 잘 다루지 못한다는 논거, 도메인 전문가와 개발자의 역할에 대한 Evans 인용이 여기서 나옵니다. 2026-08-15 확인.
No Silver Bullet — Wikipedia 요약 — 본질적 복잡성은 문제 자체에서 나오므로 제거할 수 없다는 정리와, 사용자가 서른 가지를 원하면 그 서른 가지가 본질이라는 예시가 여기서 나옵니다. 2026-08-15 확인.
여섯 단계 절차와 용어 대조표는 위 자료에 나오는 것이 아니라 이 글에서 정리한 것입니다.