잦은 요구사항 변경 속에서 제품의 일관성을 유지하기 위해 왜 형상관리 시스템이 필요한지, 그리고 왜 단순한 가이드라인 문서만으로는 무결성을 강제할 수 없는지 그 정론을 살펴보았다. 아무리 훌륭한 변경 관리 프로세스가 수립되어 있어도, 사람이 눈으로 일일이 사양서의 오류를 검토하는 방식은 결국 시간과 주의력의 한계에 부딪혀 구멍이 뚫리기 마련이다.
결국 필요한 것은 기획서와 사양서가 코드 저장소에 반영되는 즉시 사람이 설계해 둔 규칙을 어겼는지 기계적으로 판정해 주는 자동화 도구이다.
이번 2편에서는 실무에서 널리 쓰이는 마크다운(Markdown) 포맷의 소프트웨어 사양서를 대상으로, 파이썬(Python)을 이용해 사양서 내부의 표준 용어 준수 여부와 요구사항 ID의 연결 상태를 자동으로 파싱하고 검증하는 실무 검증 엔진을 직접 설계하고 구현하는 과정을 알아보고자 한다.
1. 정적 텍스트 분석 기반의 사양 검증기 설계 구조
우리가 만들 자동화 검증 도구의 본질은 컴파일러의 빌드 타임 정적 분석(Static Analysis)과 매우 유사하다. 사양서 텍스트를 읽어 들여 토큰화하고, 이를 표준 데이터베이스(지식 베이스)와 대조하여 일관성을 판정하는 구조이다.
개발에 착수하기 전, 검증 엔진이 다루어야 할 형상 항목과 파이프라인 구조를 다음과 같이 추상화하여 정의할 수 있다.
ㄱ. 검증 도구의 3대 핵심 목표
시나리오에서 파이썬 정적 분석기가 검증해야 할 대상은 크게 세 가지 영역이다.
용어 준수 여부 검증: 사양서 본문에 사용된 단어가 표준 용어 사전(terminology.md)에 정의된 올바른 비즈니스 단어인지 확인하고, “임시 계정”, “모바일 웹” 등 시스템적으로 금지된 단어가 명세에 포함되었는지 검사한다.
요구사항 식별자(ID) 무결성 검증: 요구사항 사양서 본문에서 선언된 개별 요구사항 식별자(예: REQ-CON-001)가 중복되어 정의되지 않았는지, 그리고 매핑 참조 문서에 빠짐없이 기재되어 정렬 상태를 유지하고 있는지 분석한다.
에러 코드 도메인 정합성 검증: 사양서 내부에서 참조하고 있는 시스템 에러 코드가 공식 정책 문서(error-code-policy.md)에 명문화된 규격 및 도메인 범위(예: ERR-AUTH-001 계열)에 정확히 들어맞는지 교차 판정한다.
2. 1단계: 마크다운 파서 및 추상 구문 트리의 원리
마크다운은 사람이 읽고 쓰기에는 대단히 편리한 포맷이지만, 컴퓨터가 세부 구조를 엄격하게 검증하기 위해서는 텍스트 원문을 파싱(Parsing)하여 의미 있는 구조적 단위로 쪼개는 작업이 선행되어야 한다.
파이썬에서는 단순 문자열 검색(예: find()나 in 연산자)만으로 정합성을 검증하려 하면 수많은 예외 상황과 오탐(False Positive)에 직면하게 된다. 예를 들어, 코드 블록 내부의 주석문이나 예시 문장에 들어 있는 단어까지 시스템 에러로 잡아내는 식이다.
따라서 마크다운 텍스트를 파싱할 때는 정규 표현식(Regular Expression)을 고도화하거나, 마크다운의 AST(Abstract Syntax Tree, 추상 구문 트리)를 생성해 주는 외부 라이브러리(예: mistletoe 또는 markdown-it-py)를 활용하여 사양서의 계층 구조를 완전히 분해하는 방식을 취해야 한다.
ㄱ. 정규식 기반의 가벼운 파싱 전략
본 실무 예제에서는 파이썬 표준 라이브러리만을 활용하여 시스템 의존성을 줄이고 가볍게 구동할 수 있도록, 정규 표현식을 고도화하여 사양서 내에서 특정 패턴을 추출하는 파서 로직을 정형화한다.
에러 코드 패턴 정규식: (?:^|\s)(ERR-[A-Z]{3}-\d{3})(?:\s|$|:|\.)
이 정규식들은 문장의 시작이나 공백 뒤에 위치하며 대문자 알파벳 3글자로 이루어진 도메인 영역과 3자리의 숫자로 규격화된 식별 패턴을 명확히 추적해 낸다.
3. 2단계: 핵심 검증 엔진의 소스 코드 구현
이제 실제로 구동 가능한 파이썬 검증 스크립트의 핵심 코드를 완성해 보자. 본 코드는 외부 패키지 설치 없이 파이썬 3 기본 내장 라이브러리만으로 동작하여 빌드 머신이나 Git 훅 환경에 즉시 이식할 수 있도록 설계하였다.
4. 3단계: 구문 위반 사항의 처리 및 에러 리포트 표준화
형상관리 검증 도구가 실무에서 사용자 친화적으로 기능하려면 단순히 빌드를 깨뜨리는 것(Exit 1)만으로는 충분하지 않다. 분석 결과 출력창(Console Output)에 정확한 가이드라인을 반환하여, 작업자가 어떤 맥락에서 어떤 오류를 범했는지 단번에 알아차릴 수 있도록 보고서 포맷을 표준화해야 한다.
ㄱ. 로그 정보의 명확성 확보
본 검증 스크립트의 출력 설계 방식은 위반 상황이 포착된 ‘파일의 상대 경로’, 오류가 존재하는 ‘행(Line) 번호’, 그리고 ‘위반 사항의 범주’를 일목요연한 텍스트 구조로 리포팅한다. 이를 통해 작업자는 사양서 전체를 훑지 않고도 해당 파일의 해당 행으로 즉시 찾아가 사양 정합성 불일치 문제를 신속하게 교정할 수 있게 된다.
[실패] 사양서 정합성 검증 실패! 아래 위반 사항을 수정해야 합니다.
▶ 파일 경로: docs/prd/authentication_v2.md [45행] 정의되지 않은 불법 에러 코드 참조 감지: ERR-AUTH-999 [120행] 중복된 요구사항 ID 선언 감지: REQ-CON-003
[안내] 이 오류가 해결되지 않으면 품질 게이트 규칙에 따라 버전 머지가 제한됩니다.
5. 텍스트를 시스템으로 승화시키는 정밀 검증 엔진
제작한 파이썬 스크립트는 단순한 일회성 코드 조각이 아니다. 지식 베이스 성격의 정책 문서들과 실제 요구사항 명세서를 하나의 정교한 의존 매트릭스로 엮어주는 형상관리의 중추적인 두뇌 역할을 담당한다.
이 검증 로직이 소스 제어 시스템 내부에서 지속적으로 실행될 때 비로소 우리는 “말뿐인 가이드”가 아닌 시스템적 신뢰를 확보할 수 있다. 변경이 일어날 때마다 연결된 수많은 문서 간의 정합성을 수 밀리초 만에 검증하여 오류를 짚어내는 도구의 존재 여부는 개발 생산성과 사양의 품질 수준을 가르는 분수령이 된다.
다음 이어지는 3편에서는 이 검증 스크립트를 한 단계 더 고도화하여, 실제 로컬 커밋 환경과 지속적 통합(CI) 서버의 파이프라인에 이식하고, 규칙 위반 시 물리적으로 병합 프로세스를 강제 차단하는 자동화 파이프라인 배포 및 품질 게이트 통제 기술에 대해 심층적으로 다룰 예정이다.