145. 자료 사전 (DD, Data Dictionary) - =, +, { }, [ ], ( ), * *

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

본질: 소단위 명세서(Mini-Spec)는 구조적 분석의 3대 산출물(DFD, DD, Mini-Spec) 중 하나로, 하향식 분할의 끝에 다다른 가장 작은 동그라미(단말 프로세스) 속에서 실제로 어떤 수학적 연산과 조건(IF-ELSE) 판단이 일어나는지를 규명하는 설계도다.

가치: 모호한 자연어(산문) 대신 구조적 영어(Structured English), 의사결정표(Decision Table), 의사결정트리(Decision Tree)를 사용하여 작성되므로, 설계자의 의도가 프로그래머에게 100% 무결점 코드로 번역되는 오차 없는 가교 역할을 한다.

융합: 객체지향 패러다임과 애자일(Agile)이 대세가 되며 전통적 Mini-Spec의 형태는 소멸하였으나, 그 사상은 유스케이스(Use Case)의 이벤트 흐름(Flow of Events)이나 BDD의 인수 테스트 시나리오(Given-When-Then) 규격으로 진화하여 여전히 요구사항 정형화의 뼈대를 이루고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 소단위 명세서(Mini-Specification), 다른 말로 프로세스 명세서(Process Specification)는 시스템 분석 과정에서 도출된 자료 흐름도(DFD)의 가장 말단(Primitive) 프로세스 하나하나가 입력 데이터를 받아 어떤 비즈니스 룰(Rule)을 거쳐 출력 데이터를 만들어내는지 논리적 처리 절차를 기술한 문서다.
필요성: 구조적 분석 기법에서 DFD는 "데이터가 어디서 와서 어디로 가는가"라는 큰 숲의 흐름(화살표)을 기가 막히게 보여주지만, 정작 동그라미(프로세스) 안쪽 블랙박스에서 "입력값 A와 B를 더하는 건지 곱하는 건지, 아니면 A가 10보다 클 때만 C를 만드는 건지" 알 도리가 없다. 이 텅 빈 동그라미에 대해 구구절절 수필처럼 한글로 적어놓으면 개발자는 예외 조건(Edge Case)을 놓치고 버그를 쏟아낸다. 사람의 언어(자연어)가 가진 치명적 모호함을 제거하고, 기계어보다는 사람에 가까운 '반(Half) 프로그래밍 언어'로 논리를 통제할 강력한 명세 도구가 필요했다.
💡 비유: DFD가 거대한 **'공장 전체의 컨베이어 벨트 배치도'**이고, 자료 사전(DD)이 **'부품 상자 목록표'**라면, 소단위 명세서(Mini-Spec)는 컨베이어 벨트 끝에 서 있는 로봇 팔 하나하나가 "나사가 2개 들어오면 1번 구멍에 꽂아라, 3개 들어오면 2번 구멍에 꽂아라"라고 적힌 **'개별 로봇 팔의 작동 매뉴얼'**입니다. 이 매뉴얼이 없으면 로봇 팔은 컨베이어 벨트 위에서 멍하니 멈춰 섭니다.
등장 배경:
1. 자연어 요구사항의 파탄: 고객과 기획자가 적어준 "대충 적당히 할인율을 적용해라", "우수 고객에게는 혜택을 줘라" 같은 애매한 산문체 명세서가 코딩 단계에서 수많은 재작업(Rework)과 장애를 낳았다.
2. 구조적 프로그래밍의 3대 제어 구조 확립: 1960년대 에츠허르 다익스트라(Dijkstra)가 GOTO 문을 폐기하고 순차(Sequence), 선택(If-Else), 반복(Do-While)만으로 모든 로직을 짤 수 있음을 증명했다.
3. 분석-구현의 심리스 맵핑: 이 3대 제어 구조 철학을 분석 단계의 문서 포맷으로 끌어올린 것이 바로 Mini-Spec이며, 이를 통해 설계 문서가 곧바로 프로그래밍 뼈대로 자동 번역되는 공학적 틀이 완성되었다.

┌─────────────────────────────────────────────────────────────┐
│          모호한 자연어 명세 vs 소단위 명세서(Mini-Spec) 비교       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ ❌ 최악의 안티패턴: 산문형(자연어) 요구사항 정의 ]                     │
│ "고객이 대출을 신청하면, 신용등급이 좋은 사람(1~3등급)은 그냥 통과시켜 주고, │
│  근데 만약에 대출액이 한도를 넘으면 한 번 더 보류 상태로 돌려서 심사팀에     │
│  넘겨라. 아! 신용 안 좋은 사람은 무조건 탈락이다."                      │
│ 💥 문제점: 개발자가 "신용 안 좋은 사람이 한도를 안 넘으면 어떻게 하죠?"      │
│           라고 물어볼 수밖에 없는 논리의 구멍(Hole) 투성이 쓰레기 문서다.  │
│                                                             │
│ [ ✅ 모범 아키텍처: 의사결정표 (Decision Table) 기반 Mini-Spec ]     │
│                                                             │
│ 프로세스 번호: 3.1.2 / 프로세스명: 대출 승인 판정                      │
│ 입력: 신용등급, 요청금액, 한도금액 / 출력: 승인결과(Approve, Reject, Hold)│
│                                                             │
│ [ 조건부 (Conditions) ]                                       │
│ C1: 신용등급이 1~3등급인가?                 Y    Y    N    N      │
│ C2: 대출 요청금액이 한도금액을 초과하는가?       Y    N    Y    N      │
│                                                             │
│ [ 행위부 (Actions) ]                                          │
│ A1: 자동 승인 (Approve) 결과 반환           X    O    X    X      │
│ A2: 보류 (Hold) 결과 반환 후 심사팀 이관      O    X    X    O      │
│ A3: 자동 거절 (Reject) 결과 반환            X    X    O    X      │
│                                                             │
│ 🌟 결과: 코더(Programmer)가 뇌를 쓰지 않고 표의 Y/N 칼럼 4개만 보고      │
│    그대로 4가지 `if-else` 분기 코드로 직역하면 100% 버그 프리(Bug-free) 달성!│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 소단위 명세서가 요구공학(Requirements Engineering)에서 차지하는 절대적 가치를 보여준다. 상단의 자연어는 읽기는 편하지만 경우의 수를 100% 덮지 못하는 누락(Incompleteness)을 낳는다. 하단의 Mini-Spec 의사결정표(Decision Table)는 입력 조건 2개로 나올 수 있는 모든 조합의 수($2^2 = 4$가지 칼럼)를 수학적 매트릭스로 억지로 강제 전개시킨다. 이를 통해 기획자조차 미처 생각지 못했던 4번째 칼럼("신용 안 좋은 사람(N)이 한도를 안 넘을 때(N) ➔ 무조건 탈락이 아니라 보류(Hold)로 태우자")의 예외 케이스(Edge Case)를 분석 단계에서 미리 끄집어내어 런타임 오류(Bug)를 0으로 수렴시키는 공학적 기적을 만든다.

📢 섹션 요약 비유: 자연어 명세서가 요리사에게 "오늘 저녁은 대충 알아서 맛있는 간장 불고기 볶아줘"라고 말하는 것이라면, 소단위 명세서는 "1) 간장 3스푼, 설탕 1스푼을 섞는다 (순차) 2) 고기가 소고기면 3분, 돼지고기면 5분 볶는다 (선택 조건표)"라고 적어둔 0.1%의 오차도 허용치 않는 깐깐한 백종원 레시피와 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

소단위 명세서를 작성하는 3가지 무기 (표현 기법)

로직의 성격에 따라 가장 직관적이고 효율적인 툴(Tool)을 선택하여 작성한다.

기법 명칭	특징 및 구조	최고의 사용처 (Best Practice)	비유
구조적 영어 (Structured English)	if, then, else, do, while 등 제한된 문법 제어어와 DFD 상의 명사만 써서 엄격하게 쓴 영어(또는 한글) 글.	순차적인 계산 로직이나 루프(반복) 연산이 주를 이루는 계산 알고리즘.	요리 레시피 텍스트
의사결정표 (Decision Table)	조건(상단)과 행위(하단)를 매트릭스 표 모양으로 구성. 가능한 모든 Y/N 조합을 세로 열(Column)로 뽑아냄.	복잡한 논리적 조건 분기가 여러 개 얽혀서 예외 케이스가 많이 발생할 위험이 큰 로직.	진단 척도 체크리스트
의사결정도 (Decision Tree)	의사결정표를 보기 편하게 나뭇가지 모양의 트리(Tree)로 그려낸 도식. (루트 노드 ➔ 조건 분기 ➔ 리프 단말)	표(Table)보다 시각적으로 조건 분기를 쫓아가기 편하여 현업 사용자(비개발자)에게 컨펌받을 때 씀.	스무고개 / 심리테스트 길찾기

Mini-Spec 작성의 3대 원칙 (제약 사항)

소단위 명세서를 소설처럼 쓰면 멸망한다. 엄격한 코딩 룰이 분석 문서에도 적용된다.

최하위 프로세스 전용 (Primitive Only): DFD Level 0이나 Level 1 같은 덩치가 큰 동그라미에는 절대 Mini-Spec을 쓰지 않는다. 그것들은 쪼개어 내려가야 할 대상이다. "더 이상 쪼갤 수 없는 맨 밑바닥 동그라미"에 대해서만 1:1로 작성한다.
"How"가 아닌 "What"의 원칙: "오라클 DB 연결 객체를 가져와서 SELECT를 날리고 Hash Map에 담아라"라는 구현 종속적(How)인 코딩을 적으면 안 된다. "들어온 할인 쿠폰 배열을 순회하며 가장 할인액이 큰 1개를 찾는다(What)"라는 논리적 본질만 남겨야 나중에 C로 짜든 Java로 짜든 독립성이 유지된다.
입출력 데이터의 무결성 묶음 (Balancing): Mini-Spec 내부의 IF-ELSE 로직에 쓰이는 모든 명사(변수)는 반드시 그 부모 프로세스 동그라미로 꽂히는 DFD 화살표와, **자료 사전(DD)**에 명시된 단어들로만 작성되어야 한다. 뜬금없이 DD에 없는 '보너스점수'라는 단어가 튀어나오면 문서 아키텍처가 붕괴한 것이다.

📢 섹션 요약 비유: 미니 스펙은 레고 블록 중에서도 가장 작아서 더는 쪼갤 수 없는 '1칸짜리 단일 브릭(최하위 프로세스)'의 색깔과 투명도(로직)를 적어두는 꼬리표입니다. 그리고 이 꼬리표에는 "플라스틱을 녹여서 부어라(How)"가 아니라 "이건 빨간색 투명 브릭이다(What)"라는 사실만 우직하게 적어야 합니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: 의사결정표(Decision Table) vs 의사결정도(Decision Tree)

논리적 분기가 복잡할 때 둘 다 쓸 수 있지만, 아키텍처 설계 시 수용자의 관점에 따라 툴을 고른다.

속성	의사결정표 (Decision Table)	의사결정도 (Decision Tree)
시각적 형태	2차원 매트릭스 엑셀 표	나뭇가지(Tree) 노드 연결 그래프
최대 장점	$2^n$ 개의 콤비네이션 조합 열(Column)을 강제 전개하므로 누락된 예외 케이스(Missing Rule) 검출력 100% (빈칸 추적)	루트부터 리프노드까지 선을 따라 내려가므로 논리적 분기 맥락의 흐름 이해도가 매우 높음
최대 단점	조건이 5~6개를 넘어가면 칼럼이 64개 이상으로 폭증하여 사람이 눈으로 읽어내기 불가능해짐.	불가능한 조합이나 중복된 분기 룰을 압축하거나 검증하는 수학적 무결성 체크가 어려움.
주요 독자층	개발자, 테스터 (QA 단위 테스트 케이스용)	현업 담당자(PO), 비즈니스 부서 리뷰용

과목 융합 관점

소프트웨어 공학 (소프트웨어 테스팅): Mini-Spec의 의사결정표는 설계 산출물로 끝나지 않는다. 품질 보증(QA) 단계로 넘어가면 이 테이블이 곧바로 '원인-결과 그래프(Cause-Effect Graphing)' 나 **'결정표 기반 블랙박스 테스트(Decision Table Testing)'**의 테스트 케이스(TC) 시트로 1:1 자동 변환된다. Y/N 컬럼 하나하나가 "QA 엔지니어가 반드시 입력해보고 검증해야 할 TC 번호 1번, 2번..."으로 연결되는 완벽한 테스트 주도 설계(Test-Driven)의 뼈대다.
알고리즘 (컴파일러 최적화): Mini-Spec의 구조적 영어(IF-THEN)는 훗날 프로그래머가 짤 코드의 추상 구문 트리(AST, Abstract Syntax Tree)의 기초 뼈대다. 모호한 GOTO문을 타파한 다익스트라의 제어 구조가 없었다면, 이 명세서가 고품질의 어셈블리어나 바이너리로 번역되는 컴파일러 최적화 단계가 성립할 수 없었다.
📢 섹션 요약 비유: 의사결정표(표)가 의사 선생님이 보는 모든 성분과 수치가 빽빽하게 적힌 **'혈액 검사 결과지 엑셀 표'**라면, 의사결정도(트리)는 환자에게 결과를 설명해 줄 때 "A수치가 높으시니 이쪽(Y) 가지를 타서, B결과로 나왔네요"라고 색연필로 줄을 그어가며 설명해 주는 **'환자용 진단 플로우 차트'**입니다.

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

실무 시나리오

시나리오 — 배송료 산정 로직의 예외 케이스(Edge Case) 버그 폭발: E-커머스 쇼핑몰을 런칭했는데, "기본 배송료는 3천 원, VIP 회원은 무료, 단 도서 산간 지역은 추가 5천 원, 5만 원 이상 구매 시 VIP 아니어도 무료배송"이라는 산문 형태의 기획서만 보고 개발자가 코딩을 했다. 오픈 직후, "도서 산간에 사는 일반 회원이 5만 원 이상 구매했을 때, 배송료가 무료인지 5천 원인지"에 대한 충돌 로직이 꼬여 배송비가 거꾸로 마이너스가 되는 파멸적 결제 오류가 발생했다.
- 판단: 전형적인 자연어 기반 요구사항 분석의 실패다. 설계 단계에서 해당 '배송료 산정(P4.3)' 최하위 프로세스에 대해 의사결정표 기반 Mini-Spec을 그렸어야 했다. (VIP 여부 Y/N) * (도서산간 여부 Y/N) * (5만원 이상 여부 Y/N) = 총 8가지의 칼럼을 표로 전개해 놓고, 기획자에게 "저기, 도서산간(Y)이고 5만원 이상(Y)이고 일반(N)일 때는 배송비 0원인가요 5천원인가요?"라고 빈칸 1개에 대한 확답(Rule 컨펌)을 찌르고 빈칸을 메꿨다면 런타임 결제 오류는 절대 일어나지 않았다.
시나리오 — 객체지향 맹신으로 인한 복잡한 계산식 명세 실종: 차세대 금융 배치 시스템을 객체지향 방법론(UML)으로 화려하게 설계했다. Class 다이어그램 수십 장이 벽에 붙어 있었지만, 막상 월말 이자 정산 이율을 구하는 복잡한 수식과 세금 공제 로직을 적어둔 문서가 단 하나도 없었다. "클래스 안의 calculateInterest() 메서드가 알아서 잘하겠지" 하고 구렁이 담 넘어가듯 넘긴 것이다. 결국 20년 차 낡은 코볼(COBOL) 로직을 신규 Java로 마이그레이션하던 주니어 개발자는 수학 계산식 로직에서 헤매다 수백억 원의 오차를 냈다.
- 판단: UML 클래스 다이어그램(구조)은 훌륭하지만, 수학적 계산이 극한에 달한 알고리즘 중심의 모듈(예: 세금 계산, 연말 정산)에서는 객체지향의 추상화가 오히려 독이 된다. 복잡한 계산식은 껍데기를 그리는 객체 다이어그램이 아니라, 구조적 분석의 고전 유물인 구조적 영어(Structured English) 기반의 Mini-Spec으로 산술 연산 공식을 한 줄 한 줄 하드코딩하듯 명세해 박아주어야만 금융계의 1원 단위 데이터 마이그레이션 정합성을 보장할 수 있다.

  ┌─────────────────────────────────────────────────────────────┐
  │        실무 아키텍처: Mini-Spec 기반의 BDD(행동 주도 개발) 시나리오 변환    │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [과거의 고전적 의사결정표 (Mini-Spec)]                           │
  │ C1: 장바구니 합계 > 5만원 (Y/N)                                 │
  │ A1: 배송비 0원 반환                                           │
  │                                                             │
  │ 🌟 과거의 이 낡은 유물은 클라우드/애자일 시대에 어떻게 진화했는가?        │
  │                                                             │
  │        ======= [ 애자일 BDD(Behavior-Driven)로의 진화 ] ======= │
  │                                                             │
  │ [현대의 Cucumber / Gherkin 기반 BDD 인수 테스트 시나리오]           │
  │                                                             │
  │ Feature: 무료 배송 판정 로직 (P4.3 대체)                         │
  │                                                             │
  │   Scenario: 5만 원 초과 구매 시 배송비 무료 혜택 적용                │
  │     Given (주어진 조건) 고객의 장바구니 상품 합계가 60,000원이다.      │
  │     And   (추가 조건) 고객은 일반 회원이다.                         │
  │                                                             │
  │     When  (행위/트리거) 결제 단계로 넘어가서 배송비를 계산할 때,        │
  │                                                             │
  │     Then  (기대 결과) 청구되는 배송비는 0원이어야 한다.               │
  │                                                             │
  │ ✅ 판단: Mini-Spec의 '조건(Condition)-행위(Action)' 철학은 죽지 않았다.│
  │    현대 MSA 환경에서 Given-When-Then 이라는 텍스트 구조로 간판만 바꾼 채,│
  │    자동화된 단위 테스트(JUnit) 코드로 즉각 변환되는 위대한 유산으로 살아있다.│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 소단위 명세서(Mini-Spec)라는 단어는 폭포수(Waterfall) 시대의 산물로 취급받아 현대 SI 업계에서는 거의 쓰지 않는다. 하지만 "쪼갤 수 없는 최하위 요구사항 로직을 모호하지 않게 구조화된 텍스트로 고정시킨다"는 그 위대한 철학은, 현대 애자일(Agile) 조직에서 기획자, QA, 개발자가 공통으로 작성하는 BDD(행동 주도 개발)의 Given-When-Then 시나리오로 완벽하게 영혼이 전이되었다. 기획자가 엑셀로 짜주던 결정표는, 이제 Cucumber라는 자동화 프레임워크에 태워져 기획자가 Gherkin 문법으로 영어(한국어)를 치면 개발자의 테스트 코드가 자동으로 휙휙 돌아가는 '실행 가능한 명세(Executable Specification)'라는 꿈의 아키텍처로 진화했다.

도입 체크리스트

기술적: 하위 로직 명세를 텍스트로 작성할 때, 비밀번호 암호화 로직 같은 시스템 내부 구현 지향적인(How) 단어가 아닌 비밀번호 일치 여부 검증 같은 도메인 본질 지향적인(What) 어휘로 통제되어 작성되고 있는가?
운영·보안적: 보안 결제, 인증 인가, 권한 부여 등 단 하나의 IF문 실수로 해킹의 고속도로가 뚫릴 수 있는 치명적 코어 모듈(Critical Module)에 한해서는, 강제적으로 의사결정표(Decision Table) 리뷰를 통과해야만 개발 착수를 허가하는 식의 설계 품질 게이트(Quality Gate)가 사내 프로세스에 세워져 있는가?

안티패턴

프로그래밍 언어의 직접 삽입 (Code Embedding): 개발자 출신의 설계자가 소단위 명세서를 쓰랍시고 문서 안에 진짜 Java나 C# 코드를 50줄짜리 for문 괄호 { }까지 정확하게 지켜가며 통째로 복사-붙여넣기 해놓는 행위. 명세서가 특정 기술 스택에 강력하게 결합(Coupled)되어 버리며, 1년 뒤 시스템을 Python으로 재구축하려 할 때 낡은 명세서를 전혀 읽고 재활용할 수 없게 만드는 쓰레기 문서화의 전형이다. 명세는 반드시 범용 의사코드(Pseudo-code)를 유지해야 한다.
📢 섹션 요약 비유: 악보를 그릴 때 기타(특정 언어)로만 칠 수 있게 코드로 적어놓으면(안티패턴) 나중에 피아노나 바이올린을 치는 사람은 그 악보를 보고 연주할 수 없습니다. 소단위 명세서는 도레미파솔(구조적 영어)이라는 만국 공통의 음표로만 적어두어, 어떤 악기를 가져와도 똑같은 노래(로직)가 흘러나오게 만들어야 하는 위대한 마스터 악보입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	주먹구구식 자연어 산문 요구사항	의사결정표 기반 Mini-Spec 강제화	개선 효과
정량	코딩 시 예외 조건 누락률 30% 발생	논리 전개 매트릭스로 예외 100% 식별	로직 결함(Logical Bug)으로 인한 재작업 비용 90% 극감
정량	테스트 케이스(TC) 수동 도출 공수 과다	테이블의 칼럼 수만큼 1:1 TC 자동 산출	품질 보증(QA) 커버리지 100% 보장 및 공수 절반 단축
정성	기획-개발자 간 끊임없는 질문 핑퐁 지연	명확한 IF-THEN 명세로 핑퐁 차단	부서 간 커뮤니케이션 모호성 제거 및 무결점(Defect-free) 구현 달성

미래 전망

AI 주도 설계 (AI-Driven Design): 요구사항이 담긴 방대한 텍스트나 산만하게 흩어진 회의록을 ChatGPT 같은 대형 언어 모델(LLM)에 던져주면, AI가 사람의 언어에 숨어있는 논리의 구멍(모순점)을 스스로 찾아내고 10초 만에 완벽한 무결점 의사결정표(Decision Table)와 의사코드(Pseudo-code)로 뱉어내는 시대가 도래했다. 구조적 명세의 지루한 작성 노동은 AI가 전담하게 될 것이다.
실행 가능한 명세(Executable Specification) 생태계 통합: 더 이상 문서는 '죽어있는 종이 쪼가리'에 머물지 않는다. 작성된 Mini-Spec 룰 엔진 명세서(Gherkin 문법 등) 파일 자체가 빌드 파이프라인(CI/CD)에 던져지면, 테스트 코드 프레임워크가 이를 읽고 런타임에 코드가 룰을 위반하지 않았는지 실시간으로 검증하며 배포를 막아버리는 '살아 숨 쉬는 설계도' 아키텍처로 진화가 완료되었다.

참고 표준

DeMarco Structured Analysis Method: 구조적 분석(DFD, DD, Mini-Spec 3대 산출물)의 바이블이자 근간 스펙
IEEE 830: 소프트웨어 요구사항 명세서(SRS) 작성의 글로벌 표준 체계 (Mini-Spec 사상 포함)

소단위 명세서(Mini-Spec)는 모호함이라는 가장 거대한 적과 싸워 이기기 위해 선배 엔지니어들이 고안해 낸 가장 차가운 공학적 방패다. "인간의 언어는 믿을 수 없으니, 모든 조건과 행동을 표(Table)라는 감옥 속에 가두어 강제로 논리의 빈칸을 채우게 만들어라." 비록 객체지향의 화려한 등장에 가려져 낡은 기법이라는 오명을 쓰기도 했으나, 알고리즘과 비즈니스 룰의 최전선에서 단 한 치의 오차(Bug)도 허용치 않으려는 그 집요한 분할 정복(Divide & Conquer)의 공학적 결벽증은, 클라우드와 애자일 시대에도 여전히 완벽한 코드 구현을 위한 심장 박동으로 맥박 치고 있다.

📢 섹션 요약 비유: 미니 스펙은 건물을 다 짓고 나서 문짝을 다는 순간에 쓰이는 '경첩 설치 매뉴얼'입니다. 화려한 3D 조감도(객체지향 다이어그램)만 보고 집을 지어도 멋있어 보일진 몰라도, 결국 "나사 3개를 45도 각도로 2바퀴 조인다(Mini-Spec)"라는 밑바닥의 정밀한 규칙이 지켜지지 않으면 결국 비바람에 문짝이 뜯겨나가고 맙니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Data Flow Diagram (DFD)	소단위 명세서가 기생하는 뼈대. DFD가 분할 정복을 거쳐 최하단 단말 프로세스(동그라미)까지 쪼개져야 비로소 Mini-Spec이 탄생할 무대가 열린다.
Data Dictionary (DD)	Mini-Spec의 `IF (금액 > 500)` 같은 문장에서 '금액'이라는 단어의 타입(숫자)과 범위를 사전에 완벽히 정의해 두어 모호성을 이중으로 차단하는 짝꿍이다.
Decision Table (의사결정표)	복잡하게 꼬인 IF-THEN-ELSE 미로를 2차원 엑셀 표로 강제 전개시켜, 기획자가 놓친 예외(Bug) 틈새를 100% 잡아내는 Mini-Spec 최고의 작성 무기다.
Use Case Description (유스케이스 명세서)	OOA(객체지향 분석) 패러다임으로 넘어오면서, 시스템 동작 시나리오를 기본 흐름(Basic Flow)과 대안 흐름(Alternative Flow)으로 대체하여 작성하는 현대의 Mini-Spec 후계자다.
Behavior-Driven Development (BDD)	Mini-Spec의 엄격한 텍스트 룰을 `Given-When-Then`이라는 테스트 자동화 언어로 껍데기만 갈아 끼워 애자일(Agile) 시대를 지배한 위대한 아키텍처 진화의 결과물이다.

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

거대한 로봇 공장(시스템) 지도를 볼 때, 로봇 팔 하나가 서 있는 곳은 그냥 동그라미(DFD)로만 그려져 있어서 얘가 정확히 무슨 일을 하는지 아무도 몰라요.
**소단위 명세서(Mini-Spec)**는 그 동그라미 안에 몰래 적혀있는 **'작동 비밀 매뉴얼'**이에요! "파란색 나사가 오면 오른쪽으로 2번 돌려라!"라고 빈틈없이 꼼꼼하게 적혀있죠.
이 설명서를 대충 일기로 쓰면 기계가 헷갈려하니까, 모든 경우의 수를 꽉 채운 엑셀 표(의사결정표) 모양으로 깔끔하게 정리해 줘서 고장(버그)이 0%가 되게 도와주는 천재적인 작전 지시서랍니다!