170. 도메인 분석 (Domain Analysis)

핵심 인사이트 (3줄 요약)

1. 본질: 도메인 분석 (Domain Analysis)은 소프트웨어가 다뤄야 할 현실 업무 세계의 개념, 규칙, 용어, 경계를 정리해 문제 영역의 공통 모델을 만드는 활동이다.
2. 가치: 현업 전문가 (Domain Expert), 분석가, 개발자가 같은 단어를 같은 뜻으로 사용하게 만들어 요구사항 누락과 해석 오차를 줄이고, 이후 요구사항 명세와 설계의 기준선을 제공한다.
3. 판단 포인트: 도메인 분석은 화면이나 데이터베이스 테이블을 먼저 그리는 일이 아니라, 어떤 개념이 본질적으로 중요한지와 어디서 의미가 달라지는지를 가려내는 일이다.

Ⅰ. 개요 및 필요성

도메인 분석은 해결하려는 비즈니스 영역 자체를 이해하는 작업이다. 쇼핑, 금융, 의료, 물류처럼 소프트웨어가 다뤄야 할 세계에는 그 세계만의 개념과 규칙이 있다. "주문", "고객", "승인", "취소" 같은 단어는 일상어처럼 보이지만, 실제 업무에서는 매우 구체적인 상태 전이와 책임, 예외 규칙을 가진다. 도메인 분석은 이 의미를 먼저 고정해 두는 단계다.

이 과정이 필요한 이유는 개발이 종종 해결책에서 시작되기 때문이다. 화면 흐름, API, 테이블 구조부터 만들면 당장은 빨라 보이지만, 시간이 지나면 같은 용어를 서로 다르게 쓰는 문제가 드러난다. 예를 들어 영업팀의 "고객"은 잠재 리드까지 포함할 수 있지만, 정산팀의 "고객"은 실제 결제가 발생한 계정만 뜻할 수 있다. 이런 차이를 정리하지 않으면 요구사항도, 설계도, 테스트도 같은 단어를 서로 다른 뜻으로 사용하게 된다.

아래 그림은 도메인 분석이 없는 경우와 있는 경우의 차이를 보여준다.

┌──────────────────────────────────────────────────────────────┐
│              도메인 분석이 없을 때 vs 있을 때               │
├──────────────────────────┬───────────────────────────────────┤
│ 화면/테이블부터 설계     │ 용어·규칙·이벤트부터 합의        │
│ "회원" 의미가 부서마다 다름 │ 공통 용어 사전과 모델이 먼저 생김 │
│ 변경 영향이 뒤늦게 드러남 │ 요구사항·설계·코드가 같은 뜻 사용 │
└──────────────────────────┴───────────────────────────────────┘

즉 도메인 분석은 구현 전에 잠깐 거치는 형식 절차가 아니라, 이후 모든 산출물의 해석 기준을 만드는 단계다. 여기서 의미가 흔들리면 뒤 단계에서 아무리 깔끔한 UML (Unified Modeling Language) 다이어그램이나 코드가 나와도 실제 업무와 맞지 않을 수 있다.

• 📢 섹션 요약 비유: 도메인 분석은 집을 짓기 전에 땅의 경계와 지반 성질을 먼저 조사하는 일과 같다. 설계도가 아무리 예뻐도 땅을 잘못 이해하면 집 전체가 기울어진다.

Ⅱ. 아키텍처 및 핵심 원리

도메인 분석의 핵심은 문제 영역을 구성하는 개념과 관계를 안정적으로 식별하는 것이다. 보통은 인터뷰, 업무 절차 문서, 규정집, 기존 시스템, 실제 사례 데이터를 입력으로 삼아 개체, 값, 사건, 규칙, 예외, 경계를 추출한다. 이 과정에서 중요한 것은 명사만 모으는 것이 아니라, 어떤 규칙이 반드시 지켜져야 하는지와 어떤 시점에 상태가 바뀌는지를 함께 보는 것이다.

복잡한 시스템에서는 DDD (Domain-Driven Design)의 개념이 도메인 분석을 더 정교하게 만든다. 유비쿼터스 언어 (Ubiquitous Language)는 같은 개념을 모든 문서와 코드에서 같은 이름으로 쓰게 하고, 경계 지어진 문맥 (Bounded Context)은 같은 단어라도 문맥이 바뀌면 의미가 달라질 수 있음을 인정하게 만든다. 하지만 도메인 분석 자체는 DDD를 채택한 프로젝트에만 필요한 것이 아니라, 모든 요구공학의 기반 활동으로 볼 수 있다.

┌──────────────────────────────────────────────────────────────┐
│                 도메인 분석의 기본 흐름                      │
├──────────────────────────────────────────────────────────────┤
│ 현업 인터뷰 · 규정 · 업무 흐름 · 기존 시스템                 │
│                     │                                        │
│                     ▼                                        │
│ 용어 정리 -> 핵심 개념 식별 -> 규칙/예외 추출 -> 경계 설정   │
│                     │                                        │
│                     ▼                                        │
│ 용어 사전 · 도메인 모델 · 핵심 이벤트 · 컨텍스트 맵          │
└──────────────────────────────────────────────────────────────┘

이 흐름에서 가장 중요한 산출물은 단순 목록이 아니라 관계가 드러나는 모델이다. 예를 들어 주문(Order)과 결제(Payment)가 독립 개체인지, 승인(Approval)이 상태인지 이벤트인지, 한도 초과가 비즈니스 규칙인지 예외 처리인지 분리돼야 한다. 그래야 이후 요구사항 명세, 유스케이스, 데이터 설계가 같은 의미 위에 쌓인다.

• 📢 섹션 요약 비유: 도메인 분석은 동네 지도를 그리면서 건물 이름만 적는 일이 아니라, 학교는 어디에 있고 도로는 어떻게 이어지며 어떤 길은 일방통행인지까지 함께 표시하는 일과 같다. 그래야 실제로 길을 잃지 않는다.

Ⅲ. 비교 및 연결

도메인 분석은 요구사항 분석과 닮아 보이지만 초점이 다르다. 도메인 분석이 "이 세계에는 어떤 개념과 규칙이 존재하는가"를 묻는다면, 요구사항 분석은 "우리 시스템이 무엇을 해야 하는가"를 묻는다. 설계는 다시 "그 일을 어떻게 구현할 것인가"를 다룬다. 이 차이를 구분해야 모델이 문제 공간과 해결 공간을 혼동하지 않는다.

또 다른 중요한 비교는 스키마 중심 접근과 도메인 중심 접근이다. 스키마 중심 접근은 테이블과 CRUD (Create, Read, Update, Delete) 화면을 먼저 만들기 쉽지만, 업무 규칙이 서비스 코드 곳곳에 흩어질 위험이 크다. 도메인 중심 접근은 초기 합의 비용이 더 들지만, 비즈니스 규칙과 변경 영향을 더 명확하게 추적할 수 있다.

도메인 분석은 BPMN (Business Process Model and Notation), 유스케이스, 이벤트 스토밍과도 연결된다. BPMN이 업무 흐름을 시간 순서로 보여 준다면, 도메인 분석은 그 흐름 안에서 어떤 개념이 중심 역할을 하는지 드러낸다. 유스케이스가 사용자 목표를 설명한다면, 도메인 모델은 그 목표를 실현하는 개념적 토대를 제공한다. 즉 도메인 분석은 다양한 요구공학 기법을 묶는 의미의 축이다.

• 📢 섹션 요약 비유: 도메인 분석이 등장인물과 세계관을 정리하는 일이라면, 요구사항 분석은 그 인물들이 어떤 이야기를 겪는지 정하는 일이고, 설계는 그 이야기를 영화 세트로 어떻게 만들지 정하는 일과 같다. 순서가 뒤바뀌면 이야기와 무대가 따로 논다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 도메인 분석이 특히 용어 충돌과 규칙 누락을 줄이는 데 큰 효과를 낸다. 예를 들어 은행 시스템에서 "출금"이라는 단어는 일반 예금 계좌, 마이너스 통장, 한도 대출 계좌에서 서로 다른 규칙을 가질 수 있다. 이런 규칙이 도메인 모델에서 먼저 정리되지 않으면, 개발자는 화면 입력과 테이블 컬럼만 보고 잘못된 제약을 넣기 쉽다.

┌──────────────────────────────────────────────────────────────┐
│               도메인 경계를 가를 때 보는 질문               │
├──────────────────────────────────────────────────────────────┤
│ 같은 용어가 부서마다 같은 뜻인가?                           │
│   ├─ 예  -> 하나의 컨텍스트 후보                            │
│   └─ 아니오 -> 컨텍스트 분리 후 매핑 규칙 정의              │
│                                                             │
│ 핵심 규칙이 UI/DB 세부사항보다 안정적인가?                  │
│   ├─ 예  -> 도메인 모델 중심 설계 유지                      │
│   └─ 아니오 -> 구현 세부와 본질 규칙을 재분리               │
└──────────────────────────────────────────────────────────────┘

전자상거래 시스템도 좋은 예다. 카탈로그 서비스의 상품(Product)은 설명과 가격, 노출 속성이 중요하지만, 물류 서비스의 상품은 무게, 재고 위치, 박스 단위가 더 중요할 수 있다. 이때 하나의 거대한 Product 모델로 통합하려 들면 각 팀의 규칙이 섞여 복잡해진다. 도메인 분석은 이런 의미 차이를 발견하고, 필요하면 서로 다른 컨텍스트로 분리하게 만든다. 이는 나중에 마이크로서비스 경계나 데이터 소유권을 정할 때도 직접적인 기준이 된다.

체크리스트

• 핵심 용어에 대해 현업 전문가와 개발팀이 같은 정의를 공유하는가?
• 규칙과 예외가 화면 흐름이 아니라 도메인 개념 단위로 정리돼 있는가?
• 같은 용어가 다른 문맥에서 다른 의미를 가질 때 경계를 명확히 나눴는가?
• 도메인 모델이 테이블 구조나 프레임워크 용어에 끌려가지 않는가?

안티패턴

• 화면 설계나 데이터베이스 스키마를 먼저 만들고 의미를 나중에 맞추려는 접근

• 개념 이름만 수집하고 규칙·예외·상태 변화를 분석하지 않는 접근

• 부서별 의미 차이를 무시하고 하나의 보편 모델로 억지 통합하는 접근

• 현업 전문가 참여 없이 개발자 추측만으로 도메인을 정의하는 접근

• 📢 섹션 요약 비유: 도메인 분석을 건너뛰는 것은 지도 없이 낯선 도시에서 택시 노선부터 짜는 일과 같다. 길 이름과 규칙을 모르면 차선 변경 하나도 사고로 이어질 수 있다.

Ⅴ. 기대효과 및 결론

도메인 분석이 잘 되어 있으면 요구사항 일관성이 높아지고, 변경 영향 분석이 쉬워지며, 설계와 구현이 같은 문제 인식을 공유하게 된다. 특히 조직이 커질수록 이런 효과는 더 커진다. 공통 용어와 경계가 정리돼 있으면 팀 간 의사소통 비용이 줄고, 테스트 케이스도 실제 업무 규칙을 더 잘 반영할 수 있다.

물론 도메인 분석은 비용이 없는 작업이 아니다. 이해관계자를 모아 용어를 합의하고, 규칙 충돌을 조정하며, 모델을 계속 다듬는 데 시간이 든다. 또한 도메인은 고정물이 아니라 비즈니스 변화에 따라 진화하므로, 도메인 분석 결과도 살아 있는 산출물로 관리해야 한다.

그럼에도 이 작업은 소프트웨어 공학에서 매우 본질적이다. 도메인 분석은 "무엇을 만들 것인가" 이전에 "무엇을 이해해야 하는가"를 묻는 단계이기 때문이다. 결국 좋은 설계는 좋은 문제 이해에서 시작하고, 도메인 분석은 그 문제 이해의 뼈대를 세우는 작업으로 기억하는 것이 맞다.

• 📢 섹션 요약 비유: 도메인 분석은 오케스트라 연주 전에 악보와 조율을 먼저 맞추는 일과 같다. 악기 연주 실력이 아무리 좋아도 악보 해석이 제각각이면 합주는 곧바로 어긋난다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

현실 업무 영역
    │
    ▼
용어 · 규칙 · 이벤트 정리
    │
    ▼
도메인 모델 · 컨텍스트 정의
    │
    ├──────────────▶ 요구사항 명세
    ├──────────────▶ 아키텍처 경계 설정
    ├──────────────▶ 데이터 / API / 이벤트 설계
    ▼
구현 · 테스트 · 변경 영향 분석

이 흐름도는 도메인 분석이 단독 문서 작성으로 끝나는 것이 아니라, 요구사항 명세부터 아키텍처와 구현까지 이어지는 기준선 역할을 함을 보여준다.

👶 어린이를 위한 3줄 비유 설명

1. 새 게임을 만들기 전에 그 게임 속 세상에 누가 살고 어떤 규칙이 있는지 먼저 정해야 해요.
2. 그래야 친구들이 같은 이름을 같은 뜻으로 쓰고, 규칙도 헷갈리지 않아요.
3. 도메인 분석은 바로 그 게임 세상의 약속을 먼저 정리하는 일이에요.