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

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

본질: 요구사항 명세(Specification)는 도출과 분석이 끝난 요구사항을 '개발자와 테스터가 오해 없이 읽을 수 있는 문서 형태'로 박제하는 작업이며, 작성 언어의 수학적 엄밀성에 따라 **비정형 명세(자연어/그림)**와 **정형 명세(수학/논리식)**로 나뉜다.

가치: 비정형 명세는 의사소통이 쉽고 작성이 빨라 대다수 상업용 프로젝트(Agile, SI)를 지배하지만, 모호성의 늪에 빠질 수 있다. 반면 정형 명세는 Z-언어 같은 수학적 기호를 써서 결함을 0%로 만들지만, 작성 비용이 극악이라 우주선이나 의료 기기 같은 생명 직결 시스템(Safety-Critical)에만 제한적으로 쓰인다.

융합: 현대 소프트웨어 공학(MSA, 클라우드 환경)에서는 극단적인 자연어나 극단적인 수학 대신, UML/BPMN 다이어그램의 직관성과 Gherkin(Given-When-Then) 시나리오의 반(半)정형 텍스트 구조를 융합한 **하이브리드 명세(실행 가능한 명세)**가 업계 표준(De-facto)으로 자리 잡았다.

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

개념: 요구사항 명세(Requirements Specification)는 요구공학 프로세스의 3번째 단계(도출 ➔ 분석 ➔ 명세 ➔ 확인)다. 분석가(기획자)의 머릿속에 정리된 시스템의 동작 방식, 제약 조건, 인터페이스 규격을 일정한 포맷(주로 SRS 문서)에 기록하는 행위다. 이 기록을 남기는 도구가 '자연어(한국어, 영어)' 중심이냐, '수학적 논리 모델' 중심이냐에 따라 비정형/정형 명세로 갈린다.
필요성: "엘리베이터 문에 사람이 끼면 다시 열려야 한다." 겉보기엔 완벽한 자연어 요구사항이다. 하지만 개발자는 코딩하다 멈칫한다. "살짝 닿아도 열려야 하나? 센서가 고장 나서 안 닫히면 무한정 열어두나? 불이 났을 때는 끼여도 닫아야 하나?" 자연어가 가진 다의성, 누락, 모순이 시스템을 붕괴시킨다. 사람의 언어는 너무 느슨하기 때문에, 개발의 기준점이 될 설계도는 일말의 오차나 해석의 여지를 남기지 않는 치밀하고 깐깐한 명세(Specification) 잣대가 필요했다.
💡 비유: 비정형 명세가 요리사에게 "맛있게 약간 매콤한 김치찌개 끓여줘(자연어)"라고 말하는 것이라면, 정형 명세는 "H2O 500ml, NaCl 10g 캡사이신 농도 3.5%, 가열 온도 100도씨 5분 유지(수학적 제약식)"라고 적어주는 것입니다. 비정형은 요리하기 편하지만 맛이 바뀔 수 있고, 정형은 1만 번 끓여도 똑같은 맛이 나지만 저 문서를 쓰기 위해 화학 박사학위가 필요합니다.
등장 배경:
1. 소프트웨어 버그의 재앙: 1996년 아리안 5호 우주 발사체 폭발 사고 등, 코딩 실수가 아닌 '명세서의 모호함'으로 인한 참사가 이어졌다.
2. 정형 기법(Formal Methods)의 태동: 수학계와 학계를 중심으로, 시스템의 상태를 논리 기호와 대수학으로 증명하면 코딩 전에도 버그를 100% 잡아낼 수 있다는 Z, VDM 등의 수학적 명세 언어가 창안되었다.
3. 비즈니스의 현실적 타협: 하지만 웹 2.0 시대를 맞아 "우주선은 수학으로 만들고, 쇼핑몰은 그림(UML)과 글(Use Case)로 빨리 만들자"는 비정형/반정형 명세가 상업 시장을 완전히 통일했다.

┌─────────────────────────────────────────────────────────────┐
│          비정형(Informal) 명세 vs 정형(Formal) 명세 비교 예시       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ 1. 비정형 명세 (Informal / 자연어 기반) ]                       │
│ 요구사항: "사용자가 비밀번호를 5회 이상 틀리면, 계정을 잠가야 한다."        │
│ 💥 위험성: '5회'가 누적 5회인가 연속 5회인가? '잠금'은 영구 잠금인가 30분 │
│           잠금인가? 읽는 개발자의 상상력에 따라 버그가 탄생한다.            │
│                                                             │
│ [ 2. 반정형 명세 (Semi-Formal / 도식화, 결정표) ] 🌟 실무 타협점  │
│ 요구사항: 의사결정표 (Decision Table) 또는 Use Case 텍스트 포맷       │
│ IF (연속_실패_횟수 >= 5) AND (잠금_상태 == FALSE) THEN                │
│    UPDATE 잠금_상태 = TRUE, 잠금_해제_시간 = NOW + 30MIN;             │
│                                                             │
│ [ 3. 정형 명세 (Formal / 수학적, 논리식 기반) ] 🚀 우주/의료 레벨 │
│ 요구사항: Z-Language 등 이산수학과 집합론 기호 사용                 │
│ State: Lock = { TRUE, FALSE }, failCount ∈ ℕ                  │
│ Init: failCount = 0, Lock = FALSE                             │
│ Inv: (failCount ≥ 5) ⇒ (Lock = TRUE)                           │
│ 🛡️ 강점: 수학적 증명 도구(Model Checker)에 넣으면, 상태 모순이나 데드락이│
│          발생하는지 컴퓨터가 코딩 시작 전에 100% 컴파일 에러로 잡아낸다!  │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 명세의 강도(Rigor) 스펙트럼이다. 1번 비정형 명세는 워드나 한글로 작성되어 현업(비개발자)이 읽기에는 가장 훌륭하지만, 요구사항 100페이지를 읽다 보면 10페이지의 요구사항과 80페이지의 요구사항이 앞뒤가 안 맞는 모순(Contradiction)이 무수히 발생한다. 3번 정형 명세는 이 모순을 수학의 집합 명제로 강제 치환한다. 인간의 눈으로 읽기는 지옥 같지만, 수학 검증 프로그램(Theorem Prover)에 돌리면 로직의 결함을 0.1초 만에 논리적으로 박살 내 증명해 준다. 2번 반정형 명세는 현대 IT 생태계(UML, ERD)가 안착한 가장 현실적인 스윗스팟이다.

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

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

정형 명세(Formal Spec) vs 비정형 명세(Informal Spec) 트레이드오프

정보처리기사/감리사 등 아키텍트 이론 시험의 영원한 단골 비교 테이블이다.

비교 항목	정형 명세 (Formal)	비정형 명세 (Informal)
작성 도구/언어	수학적 기호, 논리식 (Z-Language, VDM, Petri-Nets)	자연어 (한글, 영어), 자유로운 그림 (흐름도)
표현의 특징	간결하고 명확함 (Concise & Unambiguous)	서술적이고 길어짐 (장황함)
모호성 (Ambiguity)	0% (해석의 여지가 없음)	높음 (작성자와 독자의 배경지식에 따라 다르게 해석)
의사소통 (현업과)	극도로 어려움 (고객이 수학 기호를 이해 못 함)	매우 우수함 (누구나 읽고 합의 가능)
작성 난이도/시간	최고 난이도, 막대한 시간과 비용 소모	낮음, 빠르고 쉬움
결함 검증 자동화	수학적 도구를 이용해 설계 단계에서 버그 100% 증명 가능	사람이 직접 눈으로 읽고 리뷰(Walkthrough)해야 함
최고의 사용처	원자력 발전소, 항공기 제어, 인공위성 (생명/재산 직결)	모바일 앱, 쇼핑몰, 일반 B2B/B2C 시스템 전체

반정형 명세 (Semi-Formal): 현대 소프트웨어 공학의 승리자

극단적인 수학(정형)은 너무 비싸고, 극단적인 글(비정형)은 너무 엉성하다. 이 둘을 타협한 것이 반정형(Semi-Formal) 명세다.

특징: 인간의 언어(단어)를 사용하되, 표기법을 정해진 다이어그램(그림)이나 표의 문법 안에 가두어 모호성을 통제한다.
도구:
- UML (Unified Modeling Language): 클래스, 유스케이스, 시퀀스 다이어그램. 선의 모양과 화살표의 방향에 엄격한 문법이 있다.
- 구조적 분석 도구: DFD(자료 흐름도), DD(자료 사전), Mini-Spec(의사결정표).
- BPMN: 비즈니스 프로세스 모델 및 표기법.
가치: 그림과 표의 직관성 덕분에 고객(현업)도 한눈에 이해(비정형의 장점)할 수 있으면서도, 화살표의 꼬임이나 조건 누락을 시각적으로 강제 식별(정형의 장점)해 내어 아키텍트들의 영원한 지배적 도구가 되었다.
📢 섹션 요약 비유: 수채화 물감으로 마음대로 그리는 그림이 비정형이라면, 자와 컴퍼스를 들고 오토캐드(AutoCAD)로 정해진 선과 각도에 맞춰 그리는 건축 도면이 반정형(UML) 명세입니다.

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

딜레마: 완벽한 정형 명세는 왜 상업 시장에서 실패했는가?

1990년대 학계는 "앞으로 모든 소프트웨어는 Z-Language로 완벽히 명세 증명될 것이다"라고 예언했지만 철저히 빗나갔다.

ROI (투자 대비 효과)의 파탄: 쇼핑몰 장바구니 버그가 나면 1천만 원의 손해가 난다. 하지만 장바구니 로직을 수학적으로 완벽히 명세(정형 명세)하는 데는 석박사급 인건비 5천만 원과 6개월의 시간이 필요하다. 시장은 "그냥 버그 나게 만들고 1시간 만에 핫픽스(Patch)하는 게 낫다"는 린(Lean)/애자일(Agile) 철학을 선택했다.
현업 파트너의 배제: 소프트웨어의 목적은 '고객의 비즈니스'를 돕는 것이다. 시스템이 아무리 에러 없이 수학적으로 완벽하게 돌아가도, 고객이 처음 원했던 비즈니스 로직과 다르게 짜여졌다면 100% 실패한 프로젝트다. 정형 명세는 수학 기호로 쓰여있어 고객이 리뷰(컨펌)를 할 수 없었고, 결국 엉뚱한 완벽한 깡통이 만들어지는 '요구사항 검증(Validation) 실패'의 원인이 되었다.

과목 융합 관점

시스템 구조 및 보안 (Safety Critical): KTX 고속철도 신호 제어 시스템이나 병원의 인공호흡기 펌웨어 같은 초정밀 제어 장치에서는 여전히 정형 기법이 목숨 줄이다. 최근 자율주행 자동차(자율주행 OS, AUTOSAR)의 코어 커널 로직과 블록체인 이더리움 스마트 컨트랙트(돈이 묶인 코드) 해킹 방어 검증에 있어, 다시 수학적 상태 기계 증명 모델(Model Checking)이 극도로 부상하고 있다.
클라우드 (Cloud) 및 MSA 인프라: 현대 인프라에서 인프라스트럭처 애즈 코드(IaC, Terraform/Ansible)나 쿠버네티스의 YAML 명세서는 완벽한 '선언적 반정형 명세'의 결정판이다. "서버 3대 띄워 줘"라는 한글(비정형) 대신, 정해진 스키마의 YAML 트리 규격에 맞춰 요구사항을 명세하면 쿠버네티스 엔진이 이를 읽고 시스템 상태를 100% 동일하게 빚어낸다.
📢 섹션 요약 비유: 100원짜리 지우개를 깎을 때 나노미터 단위의 레이저 정밀 커팅기(정형 명세)를 쓰면 깎는 비용이 지우개 값의 수백 배가 듭니다. 레이저 커팅기는 인공위성 엔진(생명/돈이 직결된 시스템)을 깎을 때만 아껴서 꺼내는 특수 무기입니다.

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

실무 시나리오

시나리오 — 자연어 요구사항 추적의 단절 (Traceability Loss): 차세대 공공기관 SI 프로젝트에서 요구사항 정의서를 워드 문서로 2,000페이지 넘게 줄글로 썼다. 개발 중반에 "관리자 승인 절차를 간소화하라"는 법령이 바뀌었다. 2,000페이지 문서 중 이 로직과 관련된 문장이 어디어디 박혀있는지 검색조차 안 되어, 코드를 다 고친 뒤에도 시스템 곳곳에서 구형 승인 로직이 튀어나오며 마비가 왔다.
- 판단: 비정형 산문형 명세서의 재앙이다. 실무 아키텍트는 아무리 자연어를 쓰더라도 반드시 요구사항마다 고유 식별자 ID(REQ-AUTH-001)를 부여하고 엑셀표나 Jira 같은 이슈 트래커 시스템으로 반정형화하여 나열해야 한다. 이 요구사항 ID가 소스 코드의 커밋 메시지(Git)와 테스트 케이스(QA)까지 거미줄처럼 이어지는 **요구사항 추적성 매트릭스(RTM, Requirements Traceability Matrix)**를 구축하지 않으면 거대 프로젝트는 반드시 길을 잃고 침몰한다.
시나리오 — Gherkin 문법을 이용한 실행 가능한 명세(Executable Specification): 애자일 팀에서 기획자가 백로그(Jira)에 기능을 적어주면 개발자가 항상 딴소리를 하고 다르게 구현했다. 커뮤니케이션 오해를 뿌리 뽑기 위해 팀장은 기획자의 요구사항 작성 양식을 BDD(행동 주도 개발)의 Given-When-Then 포맷으로 강제했다.
- 판단: 자연어(비정형)의 가독성을 살리되, 제약 구조(반정형)를 입히고, 나아가 테스팅 자동화(정형 증명)까지 융합한 현대 요구공학의 마스터피스 설계다.

  ┌─────────────────────────────────────────────────────────────┐
  │        실무 아키텍처: BDD (Given-When-Then) 하이브리드 명세의 위력    │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [기획자(PO)가 지라에 적는 요구사항 명세 텍스트 (Gherkin 문법)]         │
  │                                                             │
  │ Feature: 결제 취소 시 포인트 환불 로직                            │
  │                                                             │
  │   Scenario: 부분 취소 시 비율에 맞게 포인트 환불                    │
  │     Given (사전 상태) 10만원 물건을 사고 1만 포인트를 사용했다.        │
  │     When  (행위 발생) 고객이 5만원어치 상품만 '부분 취소'를 요청한다.    │
  │     Then  (기대 결과) 포인트는 5천 포인트가 고객에게 환불되어야 한다.    │
  │     And   (추가 결과) 결제 금액은 4만5천원이 청구되어야 한다.          │
  │                                                             │
  │        ======= [ 마법의 변환 파이프라인 (CI/CD) ] ========        │
  │                                                             │
  │ ✅ 실무 효과: 이 텍스트 명세서는 기획자(현업)가 한글로 썼지만, Cucumber나│
  │ Spring Test 프레임워크에 던져지면 정규표현식으로 파싱되어 진짜 Java 단위 │
  │ 테스트 코드(JUnit)와 1:1로 결합된다! 만약 개발자가 5천 포인트가 아니라 │
  │ 1만 포인트를 다 돌려주도록 버그를 짜면, 서버 배포(Build) 자체가 빨간불을 │
  │ 내뿜으며 터져서 운영 서버 반입을 원천 차단한다 (Executable Specification).│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 명세서(문서)와 소스코드(구현체)가 서로 다르게 굴러가는 "문서의 데드락(Deadlock)과 진부화" 문제를 어떻게 현대 아키텍처가 해결했는지 보여준다. BDD 구조는 인간의 자연어 문장이지만 3가지 키워드(Given, When, Then)에 철저히 가둬진 반정형 명세다. 이 명세서 텍스트 쪼가리는 살아 움직이며 런타임에 소스코드를 감시하는 수문장(Test Code)으로 둔갑한다. "명세서가 곧 테스트 코드고, 테스트 코드가 곧 명세서"가 되는 이 융합은 1970년대 학자들이 정형 명세로 꿈꿨던 "설계 결함의 수학적 100% 자동차단"이라는 꿈을 우회적인 실용주의로 달성한 쾌거다.

도입 체크리스트

기술적: 요구사항 명세서(SRS) 내에 성능에 관한 비기능 요구사항을 "응답이 매우 빠를 것"(비정형 안티패턴) 대신, "동시 접속 1만 명 시점 99%의 요청이 200ms 이내에 응답할 것"(정형화된 검증 가능 문장)처럼, 테스트 툴(JMeter)로 O/X 채점이 가능하게 계량화(Quantified)하여 명세했는가?
운영·보안적: 설계 도면(UML)을 그릴 때 사내 위키(Confluence)에 무거운 이미지 파일 덤프로 올리지 않고, PlantUML이나 Mermaid 같은 텍스트 코드 기반 도구(Text-as-Diagram)를 써서 Git으로 버전 관리가 되도록 명세 인프라를 구축했는가?

안티패턴

문서화 지상주의 (문서를 위한 문서): 애자일 도입을 핑계로 명세를 아예 안 쓰는 것도 죄악이지만, 반대로 공공 프로젝트에서 시스템 오픈 직전에 "산출물을 맞춰야 한다"며 이미 돌아가는 소스 코드를 보고 역으로 요구사항 명세서 1만 장을 두꺼운 워드로 영혼 없이 쳐서 찍어내는 행위. 이는 소프트웨어 공학의 생명 주기를 완전히 역행하는 쓰레기 양산 작업이며, 이런 프로젝트의 시스템 유지보수성은 1년도 못 가 쓰레기통에 처박힌다.
📢 섹션 요약 비유: 요구사항 명세서는 설계도를 그리는 일입니다. 집을 다 짓고 나서 구청에 제출하려고 가짜 도면을 뒤늦게 그리는 건 아무 의미가 없습니다. 벽돌(코드)을 하나 올리기 전에, 기획자와 집주인이 며칠을 싸워서라도 합의한 도면(명세) 한 장을 책상에 붙여놔야만 기둥이 무너지지 않습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	모호한 비정형 자연어 위주	반정형(UML, 표) 및 BDD 시나리오	개선 효과
정량	운영 단계(Post-Release)에서 결함 발견	설계(Design)/테스트 단계에서 결함 99% 차단	결함 수정(Bug Fix) 비용 10배~100배 감소 (Boehm 곡선)
정량	요구사항 회의 및 재질의 시간 수십 시간	명확한 IF-THEN 매트릭스로 핑퐁 제거	커뮤니케이션 낭비 및 분석/설계 공수 30% 절감
정성	개발자의 독단적 상상력에 의한 기능 왜곡	현업과 개발팀 간의 '단일 진실 원천' 계약서 확보	인도 시점의 현업 인수 거부(Rejection) 리스크 0% 완화

미래 전망

거대 언어 모델(LLM)에 의한 명세 패러다임 붕괴: ChatGPT, Claude 3와 같은 AI의 등장으로 '자연어의 모호함'이라는 약점이 극복되고 있다. 기획자가 대충 개떡같이 적어놓은 산문 회의록을 AI에게 주면, 수만 건의 베스트 프랙티스를 학습한 AI가 찰떡같이 엣지 케이스(Edge Case)를 찾아내어 완벽하게 구조화된 UML 코드(PlantUML)나 Gherkin BDD 시나리오로 10초 만에 번역해 준다. '비정형 ➔ 반정형'으로의 고통스러운 번역 노동을 이제 AI가 전담하게 되었다.
Low-Code / No-Code (명세가 곧 코드): 앞으로의 명세는 개발자에게 넘겨주기 위한 중간 다리가 아니다. 비즈니스 룰을 박스-화살표 도식이나 반정형 텍스트로 똑바로 그리기만 하면(Flowcharting), 그 명세서 자체가 즉시 클라우드 엔진에서 실행되는 백엔드 로직(Serverless Workflow)으로 구동되는 명세=코드 일체화 시대가 다가오고 있다.

참고 표준

IEEE Std 830-1998: 소프트웨어 요구사항 명세서(SRS) 작성의 글로벌 바이블 가이드. (좋은 명세서의 특징: 명확성, 완전성, 일관성, 검증 가능성 등을 정의)
ISO/IEC 29148: 최신 시스템 및 소프트웨어 공학 수명주기 프로세스의 요구공학 국제 표준

"설계에서 1시간 고민하면 구현에서 10시간을 아끼고, 운영에서 100시간의 장애를 막는다." 요구사항 명세는 개발 생태계에서 가장 앞단(Upstream)에 위치한 수문장이다. 첫 단추인 명세가 비정형의 늪에 빠져 삐뚤어지면, 뒷단의 아키텍처 설계와 화려한 마이크로서비스 코딩은 모두 아무 쓸모 없는 거대한 쓰레기를 튼튼하게 짓는 삽질로 전락한다. 수학 기호(정형)로 칠할 것인가, 그림과 표(반정형)로 엮을 것인가. 완벽함과 생산성 사이에서 줄타기하며 비즈니스의 합의를 끌어내는 자가 진정한 소프트웨어 아키텍트다.

📢 섹션 요약 비유: 요구사항 명세는 길을 떠나는 나침반의 0점을 맞추는 작업입니다. 부산을 가려다 나침반이 1도만 비틀어진 상태(모호한 명세)로 열심히 달리다 보면, 도착할 때쯤엔 완전히 다른 엉뚱한 바다 한가운데에 떨어지게 됩니다. 0점을 세밀한 수학과 자로 깎아 맞추는 이 귀찮은 작업이 가장 먼 길을 가장 빨리 가는 유일한 방법입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
SRS (Software Requirements Spec)	요구사항 도출의 모든 결과물(정형/비정형)을 차곡차곡 담아서 고객에게 도장을 받아내는(Baseline) 최종 계약 문서 패키지다.
UML (Unified Modeling Language)	글로는 한계가 있고 수학은 너무 어려운 중간 지대에서, IT 생태계를 천하통일한 가장 위대한 반정형(그림) 명세 도구다.
BDD (Behavior-Driven Development)	구식 기획 문서의 한글 텍스트를 `Given-When-Then` 룰에 맞춰 쓰면 곧바로 개발자의 테스트 코드로 부활시켜 주는 현대 명세의 마법이다.
Mini-Spec (소단위 명세서)	구조적 분석 시대에 가장 쪼갤 수 없는 하위 로직을 모호성 없는 의사결정표나 구조적 영어로 정밀 타격하여 기록한 분석 도구다.
요구사항 추적성 (Traceability)	100페이지에 적힌 요구사항 하나하나가 도면, 소스코드, QA 테스트 시트까지 유령처럼 이어져 있는지 꼬리표(ID)를 매달아 감시하는 품질 통제망이다.

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

로봇을 만들어달라고 할 때 "싸고 멋지게 만들어줘!"라고 말하는 건 비정형(자연어) 명세예요. 쉽지만 공장 아저씨는 얼마나 싸게, 얼마나 멋지게 만들어야 할지 몰라 엉뚱한 로봇을 만들죠.
반면에 "무게는 2.5kg, 키는 50cm로 만들어줘"라고 정확한 수치로 적는 건 정형(수학적) 명세예요. 오해할 일이 0%지만 적기가 너무 힘들고 어려워요.
그래서 요즘은 레고 설명서처럼 **반정형(그림과 표)**으로 그려서, 사장님도 보기 쉽고 공장 아저씨도 실수 없이 조립할 수 있게 타협하는 방법을 가장 많이 쓴답니다!