42장. 요구사항과 도메인 지식

도메인 용어·규칙·상태·사건과 경계를 모델링해 같은 단어를 서로 다르게 해석하는 문제와 시스템 간 책임 혼합을 줄인다.

이번 장에서 해결할 질문

학습 목표

• “도메인 용어·규칙·경계를 팀의 공통 요구사항 지식으로 어떻게 만드는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

요구사항의 어려움은 문장 기술보다 도메인 지식의 빈틈에서 시작되는 경우가 많다. 같은 용어를 부서마다 다르게 쓰고, 문서화되지 않은 업무 규칙과 예외가 전문가의 경험에만 남아 있으면 분석가는 익숙한 단어를 이해했다고 착각하기 쉽다.

이 장에서는 도메인 언어도메인 언어업무 전문가와 개발자가 같은 의미로 사용하기로 합의한 용어와 표현 체계다., 개념, 규칙, 사건과 경계를 전문가의 지식에서 발견하고 검증하는 방법을 다룬다. 용어집과 도메인 모델로 의미를 맞추되 현재 관행을 무조건 정답으로 복제하지 않고, 정책 근거·예외·미확정 가정을 요구사항과 연결하는 과정을 살펴본다.

1. 도메인 언어

요구사항의 문법이 완벽해도 참여자마다 단어의 뜻이 다르면 같은 시스템을 만들 수 없다. 학사 담당자가 말하는 “강좌”, 학생이 보는 “수업”, 개발자가 저장한 course, 운영자가 처리하는 “신청 건”이 서로 다른 개념을 가리킬 수 있다. 도메인 언어는 특정 업무 공동체가 사실·행동·규칙을 구분하기 위해 사용하는 일관된 어휘와 표현이다.

도메인 언어는 전문용어를 많이 쓰는 것이 아니다. 실제 업무에서 중요한 차이를 보존하고, 같은 뜻에는 같은 말을, 다른 뜻에는 다른 말을 쓰는 것이 목적이다. 화면의 쉬운 표현, 정책 원문의 법적 표현, 내부 모델의 정확한 표현은 다를 수 있지만 서로 어떻게 대응하는지 알아야 한다. 사용자에게 친숙하다는 이유로 서로 다른 상태를 “대기” 하나로 합치거나, 코드가 편하다는 이유로 업무 개념을 status=1로만 남기면 판단 근거가 사라진다.

수강신청 사례에서 먼저 다음 차이를 세운다.

• 교과목은 교육과정에 정의된 학습 단위다. 제목·학점·선수 조건을 가질 수 있다.
• 분반은 특정 학기·시간·담당·정원으로 개설된 교과목의 제공 단위다.
• 신청은 학생이 특정 분반의 수강 승인을 얻으려는 의도와 처리 기록이다.
• 수강은 승인된 등록 관계 또는 그에 따른 학습 활동을 뜻할 수 있으므로 조직의 정확한 정의가 필요하다.
• 처리 보류는 규칙 판정이 아직 안전하게 완료되지 않은 신청 상태다.
• 좌석 대기명단은 정원 부족 상태에서 향후 좌석 배정을 기다리는 별도 정책·기능이다. 이 사례에서는 승인되지 않았다.
• 정원은 분반에 허용되는 수강 규모에 관한 정책 값이고, 잔여 좌석은 특정 기준 시점의 파생 상태일 수 있다.
• 학점은 교과목의 이수 단위와 학생이 신청·취득한 합계를 모두 가리킬 수 있으므로 수식어가 필요하다.

이 구분은 문서 정리 이상의 효과가 있다. FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.의 “상태”가 신청 상태인지 수강 상태인지, RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 “정원”이 물리 좌석인지 정책상 승인 상한인지, ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?의 보류 건이 좌석을 차지하는지 같은 결정이 드러난다. 40장40장. 요구사항과 UX사용자 경험의 조사·흐름·접근성 기준을 요구사항과 어떻게 연결하는가?페이지로 이동의 사용자 흐름과 41장41장. 요구사항과 아키텍처품질 속성과 기술 제약을 아키텍처 판단 근거로 어떻게 연결하는가?페이지로 이동의 상태·일관성 구조도 같은 언어를 사용해야 한다.

공통 언어는 워크숍 한 번으로 완성되지 않는다. 인터뷰·정책·화면·API·데이터·민원에서 후보 용어를 모으고, 실제 예문과 반례로 경계를 확인한다. 정의가 충돌하면 권한 있는 도메인 책임자, 사용자, 운영·데이터·개발 담당자가 출처와 영향을 놓고 결정한다. 새 규칙과 사건이 생기면 용어와 연결 산출물을 함께 갱신한다.

2. 용어사전

용어사전은 한영 번역표나 약어 목록이 아니다. 한 개념의 정의, 동의어·금지어, 예와 반례, 관련 규칙, 출처·소유자, 상태와 버전을 관리하는 도메인 산출물이다. 정의 안에서 아직 정의하지 않은 모호한 말을 반복하지 않고, 가능하면 상위 개념과 구별 조건으로 설명한다.

용어 항목 후보는 다음 형식을 쓴다.

수강신청 용어사전 일부를 교육용 후보로 작성해 보자.

정의에는 함부로 구현을 넣지 않는다. “신청은 application 테이블의 한 행”이라고 쓰면 임시 저장, 재시도 의도, 이력과 수강 관계가 데이터 설계에 종속된다. 반대로 데이터 필드가 업무 용어와 연결되지 않으면 pending이 처리 보류인지 좌석 대기인지 알 수 없다. 용어사전과 데이터 사전은 구분하되 매핑한다.

용어 변경은 단순 편집이 아닐 수 있다. “승인”을 “접수 완료”로 바꾸는 것이 화면 문구 수정인지 상태 의미 변경인지 확인한다. 용어 ID는 유지하면서 정의 버전과 유효 시점을 관리하고, 영향받는 FR, RULE, SCR, API, DATA, TC, 운영 문서를 찾는다. 오래된 민원·로그를 해석할 때 당시 버전도 필요하다.

3. 개념 모델

개념 모델은 도메인의 주요 개념, 그리고 속성보다 먼저 알아야 할 관계와 제약을 표현한다. 요구를 이해하고 질문을 찾기 위한 모델이지 데이터베이스 물리 모델이 아니다. 식별자·카디널리티·시간·상태를 논의할 수 있지만 테이블, 외래키, 서비스 경계를 곧바로 확정하지 않는다.

수강신청 개념 모델 후보 CM-ENR-01CM-ENR-01 · 프로젝트 항목학생·교과목·분반·신청·판정·수강 등록의 관계와 경계를 질문하기 위한 수강신청 개념 모델 후보다.은 다음처럼 읽는다.

이 그림은 질문을 만든다. 한 학생이 같은 분반에 여러 요청 ID를 보낼 수 있는가, 같은 의도를 재전송하면 신청 객체는 하나인가 여러 사건인가? 취소는 신청 상태를 바꾸는가, 수강 등록을 종료하는 별도 결정인가? 분반 정원이 중간에 바뀌면 과거 승인과 새 판정에 어느 버전을 적용하는가? DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.의 결정 기록은 이런 질문에 답할 입력·규칙 버전과 상태 변화를 보존해야 한다.

개념 모델에는 시간도 포함한다. “학생이 선수과목을 이수했다”는 현재 조회값만으로 충분하지 않을 수 있다. 신청 시점, 판정 시점, 학적 반영 시점과 재평가 시점이 다르면 결과가 달라진다. DR-003DR-003 · 데이터 요구학생·강좌·규칙 입력의 원천과 기준 시점을 판정에 연결한다의 일관성과 DR-002DR-002 · 데이터 요구신청과 요청·판정·상태 변경을 고유 식별자로 연결한다의 신원 연결을 이용해 어떤 기준선으로 판정했는지 설명할 수 있어야 한다.

카디널리티를 기계적으로 채우지 않는다. 교과목에 분반이 반드시 하나 이상인지, 폐강·예정 개설을 포함하는지에 따라 달라진다. 실제 정책과 데이터 표본, 예외를 확인하고 후보 상태를 붙인다. 개념 모델은 현실을 단순화하므로 모델 밖에 둔 개념과 이유도 기록한다.

4. 도메인 모델

도메인 모델은 개념과 관계에 행위, 상태, 불변조건과 책임을 더해 문제 영역을 설명한다. 개념 모델보다 풍부할 수 있지만 구현 클래스 다이어그램과 동일하지 않다. 업무가 무엇을 허용·금지하고 상태가 왜 변하는지를 표현한 뒤, 아키텍처가 책임을 어디에 할당할지 판단하게 한다.

신청 생명주기 후보 DM-APPLICATION-01DM-APPLICATION-01 · 프로젝트 항목접수·판정 중·보류·승인·거절·취소 상태와 재평가 및 늦은 응답의 전이 규칙을 표현하는 신청 생명주기 도메인 모델 후보다.을 보자.

“접수됨”과 “승인됨”을 분리해야 응답 유실 뒤 FR-004FR-004 · 기능 요구같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다.의 중복 안전성을 설명할 수 있다. “처리 보류”는 실패를 숨기는 성공 상태가 아니며 자동 승인으로 넘어가지 않는다. 취소 가능 시점과 효과, 재평가 중 취소, 늦은 판정이 새 상태를 덮는지 여부는 아직 확인할 규칙이다. 도메인 모델은 이 미결정을 상태 전이의 빈칸과 쟁점으로 드러낸다.

불변조건 후보는 다음과 같다.

• 같은 신청 의도의 재전송은 복수의 수강 등록 효과를 만들지 않는다.
• 권한 있는 승인 결정 없이 수강 등록이 성립하지 않는다.
• 규칙 실패·무효·시간 초과는 승인으로 해석하지 않는다.
• 학생은 자신의 신청과 공개 가능한 판정 사유만 조회한다.
• 승인·취소·운영 정정은 주체·근거·규칙 버전과 전후 상태를 설명할 수 있다.
• 정원 초과 승인 금지는 RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 실제 정책·예외가 확인된 범위에서 적용한다.

도메인 책임과 소프트웨어 책임도 구분한다. 학사 정책 책임자는 선수·학점·우선권 규칙을 승인하고, 시스템은 승인된 규칙 버전을 일관되게 실행·기록한다. 데이터 원천이 졸업예정 여부를 제공하지 않는데 애플리케이션이 임의 추정해서는 안 된다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.과 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.는 모델이 해결할 기술 문제가 아니라 권한과 데이터 계약이 필요한 미결정이다.

도메인 모델과 아키텍처는 왕복한다. 41장41장. 요구사항과 아키텍처품질 속성과 기술 제약을 아키텍처 판단 근거로 어떻게 연결하는가?페이지로 이동의 ASR-ENR-01ASR-ENR-01 · 프로젝트 항목신청 효과와 좌석의 일관성. 동시성 경계, 멱등 처리, 상태 전이·대사.은 신청·결정·수강 등록의 일관성 경계를 묻고, 도메인 모델은 함께 지켜야 할 불변조건을 제공한다. 아키텍처 실험에서 분산 경합이나 외부 지연이 발견되면 상태·규칙의 의미가 충분한지 다시 확인한다. 모델은 설계 전에 한 번 그리고 끝내는 그림이 아니다.

5. 업무 규칙

업무 규칙은 조직의 운영과 의사결정을 제한하거나 정의하는 명시적 문장이다. 정책, 법규, 계약, 계산·판정 기준, 권한과 예외에서 나온다. 시스템이 현재 그렇게 동작한다는 사실은 규칙의 증거 후보일 뿐 공식 규칙과 같지 않다. 오래된 코드의 분기문이 학칙을 대신하게 두지 않는다.

OMG SBVR 1.5은 업무 어휘의 의미와 업무 규칙을 정밀하게 표현하기 위한 현행 공식 사양이다. 모든 프로젝트가 SBVR 메타모델을 도입해야 한다는 뜻은 아니다. 어휘와 사실 유형을 먼저 정의하고, 규칙을 구현과 분리하며, 의무·금지·가능을 명확히 표현하는 원리가 실용적이다.

규칙 카탈로그에는 다음을 둔다.

기존 규칙 후보를 도메인 언어로 정제하면 다음과 같다.

다섯 문장은 아직 출처·예외·승인자가 확인되지 않은 후보다. 자연어가 간결하다고 완전한 것은 아니다. 결정표와 예시를 사용해 경계 조합을 찾고 정책 책임자에게 결정 가능한 질문으로 올린다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.의 졸업예정자 우선권은 대상·증명 시점·동률·공개 사유·이의·좌석 정책이 정해지기 전에는 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.의 현행 내용으로 취급하지 않으며, RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 정원 한도 영향도 따로 검토한다.

규칙 변경은 과거 판정을 재해석할 수 있으므로 버전과 유효 시점을 보존한다. 어떤 신청이 어떤 학적 입력과 규칙 버전으로 판정됐는지 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.에 연결한다. 규칙 엔진의 배포 버전만으로는 업무 승인 버전을 설명하지 못할 수 있다. 정책 원문, 해석 결정, 실행 규칙과 시험을 이어야 한다.

6. 온톨로지

온톨로지는 공유하는 개념과 관계, 제약을 명시적으로 형식화해 사람과 기계가 같은 의미 구조를 참조하게 하는 수단이다. 용어사전보다 엄밀한 식별·관계와 추론 가능성을 제공할 수 있다. 여러 학사 시스템·기관의 데이터를 연결하거나 대규모 지식 자산을 재사용할 때 가치가 커지지만, 작은 프로젝트의 모든 용어집을 온톨로지로 만들 필요는 없다.

W3C의 OWL 2 개요는 온톨로지를 특정 영역을 다루며 사용자 공동체가 공유하는 형식화된 용어 어휘로 설명하고, 용어 사이의 관계로 정의를 표현한다. OWL 2는 표현력과 추론 특성이 다른 프로파일도 제공한다. 형식 언어를 쓴다는 사실이 도메인 정의의 진실성이나 완전성을 보장하지는 않는다.

수강신청에서 다음 요구가 있을 때 온톨로지를 검토할 수 있다.

• 대학·학과마다 다른 교과목·이수·선수 개념을 공통 의미로 연결해야 한다.
• 정책·문서·데이터셋 사이에서 같은 개념을 안정적으로 식별해야 한다.
• 정의된 관계에 따라 분류·일관성 검사를 반복해야 한다.
• 외부 표준 어휘와 상호운용하고 변경 이력을 관리해야 한다.

반면 하나의 시스템에서 제한된 팀이 관리하는 규칙이고 관계형 모델·결정표로 충분하다면 온톨로지 도입 비용이 이익보다 클 수 있다. 모델링 전문성, 추론 성능, 설명 가능성, 버전·권한, 도구 운영과 잘못된 추론의 영향을 평가한다. “AI를 쓰려면 온톨로지가 필수”도, “LLM이 문서를 읽으니 모델이 불필요”도 일반화할 수 없다.

개방 세계를 전제로 하는 온톨로지 추론과 업무 시스템의 폐쇄적 판정도 구분한다. 어떤 선수 이수 사실이 지식베이스에 없다는 이유만으로 미이수를 확정할 수 없는 표현 체계가 있고, 수강신청은 공식 기준 시점 데이터로 승인·거절을 결정해야 한다. 추론 의미와 업무 판정 의미를 정하지 않으면 누락 데이터를 잘못된 승인·거절로 바꿀 수 있다.

7. 지식 그래프

지식 그래프는 식별 가능한 개체와 그 관계, 출처·맥락을 그래프 형태로 연결한 지식 자산이다. 온톨로지가 의미 체계와 제약을 제공할 수 있다면 지식 그래프는 실제 교과목·분반·정책·규칙·요구·결정 같은 인스턴스와 근거를 연결한다. 둘은 함께 쓸 수 있지만 같은 말은 아니다.

RDF 1.1은 웹에서 정보를 그래프로 표현하기 위한 W3C 권고다. 주어-술어-목적어 형태의 트리플과 국제화된 식별자를 사용해 서로 다른 출처의 관계를 연결할 수 있다. RDF를 저장했다고 자동으로 믿을 수 있는 지식이 되는 것은 아니다. 출처, 공식성, 기준 시점, 접근 통제와 검증 규칙이 필요하다.

수강신청 지식 그래프 후보 KG-ENR-01KG-ENR-01 · 프로젝트 항목교과목·분반·정책·규칙·요구·결정과 각 출처를 관계로 연결해 변경 영향과 근거 누락을 탐색하는 수강신청 지식 그래프 후보다.은 다음 관계를 다룰 수 있다.

마지막 세 줄은 교육용 구조 예시이며 실제 학생·신청 데이터가 아니다. 실제 그래프에 개인정보와 판정 근거를 넣는다면 목적·최소화·분리·권한·보존·파기와 추론을 통한 민감정보 노출을 검토한다. 접근 권한이 다른 데이터를 링크하면 각각 안전해 보이던 조각이 개인을 식별하거나 민감한 상태를 드러낼 수 있다.

지식 그래프가 요구사항에 주는 가치는 관계 탐색이다. RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.가 바뀔 때 관련 FR, ASR, API, 결정 기록, 시험과 운영 절차를 찾거나, 출처 없는 요구와 검증 없는 규칙을 질의할 수 있다. 그러나 링크를 자동 생성한 결과는 후보 관계다. 같은 단어가 등장했다는 이유만으로 implements나 verifies가 성립하지 않는다. 관계 유형별 승인 기준과 검토 책임자를 둔다.

도입 여부는 질문과 규모로 판단한다. 문서 수가 적고 안정된 추적표로 충분한데 그래프 플랫폼부터 만들면 유지비만 늘 수 있다. 반대로 여러 정책 버전·기관·시스템·규칙이 얽혀 관계 질의와 출처 추적이 반복된다면 그래프가 효과적일 수 있다. 정확도·완전성·신선도·출처·중복 식별과 권한을 측정하고, 원문 요구 저장소와 동기화 방법을 정한다.

이 장에서 정리한 결과는 도메인 용어사전, 개념·도메인 모델, 업무 규칙 카탈로그, 필요할 때의 온톨로지·지식 그래프 도입 판단표다. 완료 여부는 다이어그램의 복잡도가 아니라 다음으로 판단한다.

• 같은 용어가 화면·정책·API·데이터·시험에서 같은 개념을 가리키는가?
• 신청·수강 등록, 처리 보류·좌석 대기명단처럼 중요한 경계가 보존되는가?
• 규칙마다 출처·권한·예외·버전·실행·검증이 연결되는가?
• 도메인 모델과 DB·구현 모델이 구분되면서도 매핑되는가?
• 형식 추론의 전제와 한계, 개인정보·권한 위험이 기록되는가?
• 변경된 정의에서 영향받는 요구와 결정을 양방향으로 찾을 수 있는가?

이 구조화된 지식은 43장43장. AI 시대의 요구사항AI가 만든 요구 후보를 어떤 증거·책임·검토 절차로 안전하게 사용하는가?페이지로 이동의 AI 보조 작업에서 입력 문맥과 검증 기준이 된다. 다만 좋은 용어사전과 그래프도 AI 출력의 정확성을 보증하지 않는다. 출처 원문, 권한 있는 사람의 판단과 승인 이력은 계속 별도로 보존해야 한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로