148. 요구사항 명세 (Specification) - 정형 명세 vs 비정형 명세

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

본질: 요구사항 명세(Specification)는 도출된 요구사항을 개발자와 테스터가 오해 없이 구현할 수 있도록 문서화하는 작업이며, 수학적/논리적 엄밀성에 따라 **비정형 명세 (자연어 중심)**와 **정형 명세 (수학/기호 중심)**로 나뉜다.

가치: 비정형 명세는 작성이 쉽고 현업과의 의사소통이 수월해 상업용 프로젝트를 지배하지만 모호성의 위험이 있다. 반면, 정형 명세는 Z-Language 같은 수학적 기호를 써서 결함을 설계 단계에서 100% 증명해 내며 원자력/항공기 같은 생명 직결 시스템(Safety-Critical)에 사용된다.

판단 포인트: 현대 소프트웨어 공학에서는 극단적인 수학이나 자연어 대신, UML 같은 시각적 다이어그램(반정형)이나 Gherkin(Given-When-Then) 시나리오 기반의 **실행 가능한 명세 (Executable Specification)**를 융합하여 사용하는 것이 실무 아키텍처의 표준이다.

Ⅰ. 개요 및 필요성

요구사항 명세 (Requirements Specification)는 요구공학 프로세스(도출 → 분석 → 명세 → 확인)의 3번째 단계로, 기획자나 분석가의 머릿속에 있는 시스템의 동작 방식과 제약 조건을 문서(SRS, Software Requirements Specification)로 박제하는 행위다.

"비밀번호를 5회 이상 틀리면 계정을 잠가라." 겉보기엔 완벽한 한글 문장이다. 하지만 개발자는 "누적 5회인가, 연속 5회인가? 영구 잠금인가, 30분 잠금인가?"라며 멈칫한다. 인간의 자연어는 본질적으로 다의성과 모호함, 누락을 내포하고 있기 때문에, 개발의 기준이 되는 설계도는 해석의 여지를 남기지 않는 깐깐한 잣대가 필요했다. 여기서 글이나 그림으로 대략 적어내는 비정형 명세(Informal Specification)와, 수학적 집합과 논리식으로 완벽히 치환하는 정형 명세(Formal Specification)의 패러다임 충돌이 발생한다.

📢 섹션 요약 비유: 비정형 명세가 요리사에게 "맛있게 약간 매콤한 김치찌개 끓여줘(자연어)"라고 말하는 것이라면, 정형 명세는 "H2O 500ml, NaCl 10g, 100도씨 5분 가열(수학적 제약식)"이라고 적어주는 것입니다. 비정형은 편하지만 맛이 바뀔 수 있고, 정형은 1만 번 끓여도 똑같은 맛이 납니다.

Ⅱ. 아키텍처 및 핵심 원리

명세의 강도(Rigor) 스펙트럼은 자연어에서 수학으로 갈수록 모호성은 사라지지만 작성 난이도가 극악으로 치솟는다.

┌─────────────────────────────────────────────────────────────┐
│          비정형(Informal) 명세 vs 정형(Formal) 명세 비교 예시       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ 1. 비정형 명세 (Informal / 자연어 기반) ]                       │
│ 요구사항: "사용자가 비밀번호를 5회 이상 틀리면, 계정을 잠가야 한다."        │
│ 💥 위험성: 읽는 사람의 상상력에 따라 버그가 탄생하는 모호성(Ambiguity) 늪.   │
│                                                             │
│ [ 2. 반정형 명세 (Semi-Formal / UML, 도식화, 결정표) ] 🌟 실무 타협점│
│ 요구사항: 의사결정표 (Decision Table) 포맷                       │
│ IF (연속_실패 >= 5) AND (상태 == 정상) THEN 잠금=TRUE, 해제=NOW+30m;│
│                                                             │
│ [ 3. 정형 명세 (Formal / 수학적, 논리식 기반) ] 🚀 우주/의료 레벨 │
│ 요구사항: Z-Language 등 이산수학과 집합론 기호 사용                 │
│ State: Lock = { TRUE, FALSE }, failCount ∈ ℕ                  │
│ Init: failCount = 0, Lock = FALSE                             │
│ Inv: (failCount ≥ 5) ⇒ (Lock = TRUE)                           │
│ 🛡️ 강점: 컴퓨터 검증 도구(Model Checker)에 넣으면 설계 모순 0% 증명!     │
└─────────────────────────────────────────────────────────────┘

1번 비정형 명세는 현업(고객)이 읽기 훌륭하지만, 문서 100페이지가 넘어가면 앞뒤가 안 맞는 모순(Contradiction)이 무수히 발생한다. 3번 정형 명세는 이를 수학의 명제로 치환한다. 인간이 읽기는 지옥 같지만, 모델 체커(Model Checker)에 돌리면 로직 결함을 코딩 전에 컴파일 에러처럼 완벽하게 잡아낸다. 2번 반정형 명세는 이 둘을 타협하여 그림(UML)의 문법으로 모호성을 통제하는 현실적인 중간 지대다.

📢 섹션 요약 비유: 비정형 명세가 '초상화 그리기(특징은 잘 잡지만 사람마다 그림이 다름)'라면, 정형 명세는 '3D 안면 뼈대 스캐닝 좌표값(1mm의 오차도 없는 완벽한 데이터 수치)'입니다.

Ⅲ. 비교 및 연결

정보처리기사/감리사 시험의 핵심인 두 기법의 트레이드오프를 표로 압축한다.

비교 항목	비정형 명세 (Informal Specification)	정형 명세 (Formal Specification)
작성 도구 및 언어	자연어 (한/영), 일반적인 그림 (흐름도)	수학적 기호, 논리식 (Z-Language, VDM, Petri-Net)
표현의 특징	서술적이고 장황함	간결하고 명확함 (Concise & Unambiguous)
모호성 (Ambiguity)	매우 높음 (작성자와 독자마다 다르게 해석)	0% (해석의 여지가 없음)
현업(고객) 의사소통	매우 우수함 (누구나 읽고 합의 가능)	극도로 어려움 (고객이 수학 기호를 이해 못 함)
결함 검증 방식	사람이 눈으로 읽고 리뷰 (Walkthrough)	설계 단계에서 수학적 도구로 버그 100% 증명 자동화
최고의 사용처	일반적인 웹/앱, 쇼핑몰, 상업용 프로젝트 전반	원자력 발전소 제어, 항공우주, 의료 생명 유지 장치

수학의 완벽함을 자랑하는 정형 기법은 상업 시장에서 철저히 버림받았다. 쇼핑몰 장바구니 기능을 정형 명세하는 석박사 인건비가 장바구니 버그로 인한 손해보다 수십 배 비싸기 때문이다. 시장은 빠른 개발과 패치(Agile)를 선택했다. 더 큰 문제는, 수학으로 완벽하게 시스템을 명세해도 고객(비개발자)이 이를 컨펌할 수 없으니 애초에 비즈니스 목적과 다른 시스템이 만들어지는 딜레마에 빠졌다는 점이다.

📢 섹션 요약 비유: 100원짜리 연필을 깎을 때 나노미터 단위의 레이저 커팅기(정형 명세)를 쓰면 연필값보다 깎는 비용이 더 듭니다. 레이저 커팅기는 인공위성 부품을 깎을 때만 아껴 써야 하는 특수 무기입니다.

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

최근 실무에서는 자연어의 쉬운 소통과 정형 기법의 검증 자동화를 융합한 기술이 각광받고 있다.

실무 판단 시나리오

요구사항 추적성 상실 방지: 워드 문서 2천 페이지를 줄글로 써놓는 순수 비정형 명세는 재앙이다. 아키텍트는 아무리 자연어를 쓰더라도 각 요구사항에 REQ-AUTH-001 같은 고유 식별자(ID)를 부여해 표로 만들고, 이 ID가 소스 코드 커밋 메시지와 테스트 케이스(QA)까지 거미줄처럼 이어지는 요구사항 추적성 매트릭스 (RTM, Requirements Traceability Matrix)를 반드시 구축해야 한다.
실행 가능한 명세 (Executable Specification) 도입: BDD(행동 주도 개발)의 Given-When-Then 문법(Gherkin 등)은 자연어로 쓰여 현업이 이해하기 쉽지만, 그 포맷 자체가 철저히 규격화된 반정형 명세다. 이 명세 텍스트는 CI/CD 파이프라인에서 JUnit 테스트 코드로 변환되어, 개발자가 요구사항과 다르게 코딩하면 빌드 자체가 터지도록 막아버리는 수문장 역할을 한다. 정형 기법의 '자동 증명' 철학을 현대적으로 계승한 완벽한 실무 아키텍처다.

안티패턴

문서화 지상주의 (진부화된 문서 양산): 시스템 개발이 다 끝나가는데 감리나 납품 산출물을 맞추기 위해 이미 돌아가는 코드를 보고 뒤늦게 요구사항 명세서를 소설 쓰듯 끼워 맞추는 행위. 명세서는 길을 떠나기 전 0점을 맞추는 나침반인데, 도착한 뒤에 나침반을 그리는 완벽한 공수 낭비다.
📢 섹션 요약 비유: 요구사항 명세서는 집을 짓기 전의 건축 도면입니다. 벽돌(코드)을 다 쌓고 나서 구청에 내려고 가짜 도면을 뒤늦게 그리는 건 코미디입니다. 벽돌 한 장 올리기 전에 기획자와 집주인이 며칠을 싸워서라도 합의한 도면을 뽑아내는 게 아키텍트의 의무입니다.

Ⅴ. 기대효과 및 결론

모호성 없는 탄탄한 요구사항 명세는 뒷단에서의 결함 수정 비용을 10배~100배 줄여준다(Boehm 곡선). 첫 단추인 명세가 비정형의 늪에 빠져 1도라도 비틀어지면, 화려한 마이크로서비스(MSA)와 클라우드 아키텍처로 지은 시스템은 결국 '고객이 원하지 않는 완벽한 쓰레기'로 전락할 뿐이다.

미래의 명세 환경은 AI(LLM)와 결합하고 있다. 기획자가 개떡같이 쓴 산문형 비정형 텍스트를 AI가 분석하여, 모순을 짚어내고 10초 만에 완벽한 반정형 UML 코드(PlantUML)나 Gherkin 시나리오로 정제해 내는 시대다. 이제 소프트웨어 엔지니어는 완벽함(정형)과 생산성/소통(비정형) 사이에서, 반정형과 자동화 툴을 영리하게 엮어내어 비즈니스의 합의를 끌어내는 진정한 지휘자가 되어야 한다.

📢 섹션 요약 비유: 목적지 없이 무작정 뛰기만 하면 엉뚱한 바다에 빠집니다. 명세란 출발하기 전 나침반을 세밀하게 돌려 0점을 깎아 맞추는 귀찮은 작업이지만, 결국 이 귀찮음이 가장 먼 길을 가장 빨리, 정확하게 가는 유일한 방법입니다.

📌 관련 개념 맵

개념	연결 포인트
UML (Unified Modeling Language)	비정형의 모호함과 정형의 어려움을 타협하여 IT 업계를 천하통일한 객체지향 반정형(그림) 명세 도구.
SRS (Software Requirements Spec)	도출/분석된 모든 요구사항 명세를 묶어 베이스라인(Baseline)으로 확정하고 고객의 서명을 받는 최종 계약 문서 패키지.
BDD (Behavior-Driven Development)	`Given-When-Then` 구조로 작성된 비즈니스 요구사항 문장이 곧바로 테스트 코드의 뼈대가 되는 현대적 융합 명세 기법.
요구사항 추적성 (Traceability)	명세서에 적힌 요구사항이 설계 도면, 소스 코드, 테스트 케이스까지 빠짐없이 1:1 매핑되었는지 감시하는 품질 통제망.

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

비정형 명세 (Informal) / 100% 자연어 의존, 모호성 폭발 및 해석의 충돌
    │
    ▼
구조적 명세 도구 / DFD (자료흐름도), DD (자료사전), Mini-Spec (의사결정표) 도입
    │
    ▼
정형 기법 (Formal Methods) 태동 / Z-Language, VDM 등 수학적 증명 (상업 시장 실패)
    │
    ▼
객체지향 UML (Unified Modeling Language) / 반정형 시각화 모델링으로 실무 평정
    │
    ▼
BDD 기반 실행 가능한 명세 (Executable Specification) / 명세서가 곧 자동화 테스트 코드!

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

공장 아저씨에게 "싸고 멋진 로봇 하나 만들어줘!"라고 대충 말하는 건 비정형(자연어) 명세예요. 쉽지만 아저씨가 엉뚱한 로봇을 만들 수 있어요.
반대로 "무게 2.5kg, 키 50cm, 관절 각도 30도"라고 아주 정확한 수학 수치로 빡빡하게 적어주는 게 정형(수학적) 명세예요. 완벽하지만 적기가 너무너무 힘들죠.
그래서 요즘은 레고 조립 설명서처럼 **반정형(그림과 표)**으로 그려서, 사장님도 알아보기 쉽고 공장 아저씨도 실수 없이 로봇을 조립하게 만드는 방법을 쓴답니다!