2.1 철도 안전 소프트웨어 요구사항 명세

EN 50128은 철도 제어 및 보호 시스템용 소프트웨어 개발을 위한 국제 기능 안전 표준으로, 요구사항 명세 단계에서 완전성, 일관성, 명확성, 추적성을 의무 요건으로 규정한다 ^[1]. 특히 SIL 3~4에 해당하는 안전 핵심 소프트웨어에 대해서는 요구사항이 위험원 분석 및 위험성 평가(HARA: Hazard Analysis and Risk Assessment) 결과와 양방향으로 추적 가능해야 하며, 소프트웨어 요구사항 명세(SRS: Software Requirement Specification)가 독립 평가(Independent Assessment)의 핵심 감사 대상임을 명시한다. 2023년에는 EN 50128과 EN 50657을 통합한 EN 50716이 제정됨으로써, 철도 소프트웨어 개발 전 주기에 걸친 양방향 추적성 확보 요건이 더욱 강화되었다 ^[2].

실무 현장에서 EN 50128 요구사항 명세를 어떻게 구현할 것인가에 대한 경험 연구도 보고되고 있다. Provenzano와 Hänninen(2017)은 Bombardier Transportation의 철도 프로젝트를 대상으로, 자연어로 작성된 안전 요구사항을 EN 50128 표준에 부합하는 시나리오, 시퀀스 다이어그램, 유스케이스, 상태 기계 다이어그램으로 변환하는 방법을 도입한 경험을 보고하였다 ^[8]. 이 연구는 구조화된 요구사항 표현이 자연어 대비 명확성과 정밀성을 향상시키는 반면, 새로운 작성 방식의 도입이 조직 내 작업 절차 변경 저항 등 실질적인 도전을 수반함을 지적하였다.

형식 검증(Formal Verification) 관점에서는 Iliasov 외(2023)가 SafeCap 툴셋을 이용하여 영국 주요 철도 연동 시스템(Solid State Interlocking) 26개에 대한 산업 규모의 형식 안전 검증을 수행한 결과를 IEEE Transactions on Dependable and Secure Computing에 보고하였다 ^[9]. 이 연구는 SafeCap 툴셋이 실제 철도 신호 프로젝트에서 확장 가능하고 자동화된 형식 검증을 제공하며, 안전성 향상과 개발 효율 개선에 실질적인 산업적 가치를 가지고 있음을 실증하였다.

Chen 외(2024)는 통신기반열차제어시스템(CBTC: Communication-Based Train Control)을 대상으로 시스템 이론적 프로세스 분석(STPA: Systems-Theoretic Process Analysis)을 적용하여 계층적 안전 요구사항 도출 방법론을 제안하고, 안전 요구사항에서 서브시스템 아키텍처까지의 추적성 링크를 체계적으로 설정하는 방법을 Heliyon에 발표하였다 ^[10]. 이 연구에서 WATP, ATO, ATS 등 CBTC 주요 기능 블록의 요구사항이 전통적인 위험원 분석 기법만으로는 현대 철도 신호 시스템의 소프트웨어 관련 결함을 충분히 식별하기 어렵다는 한계를 지적하고, 요구사항의 계층적 구조화와 추적성 확보의 중요성을 강조하였다.

이들 연구는 EN 50128 준수 요구사항 명세의 중요성을 실증적으로 뒷받침하지만, 한국어 KRS 기반 철도 신호 요구사항을 표준문안 구조로 자동화하여 변환하고, 변환 결과를 결정론적으로 검증하는 엔드-투-엔드 체계를 제시한 연구는 아직 존재하지 않는다.

2.2 요구사항 자동 분석 및 구조화

자연어 처리(NLP: Natural Language Processing) 기반 요구사항 자동 분석 연구의 현황을 파악하기 위해 Zhao 외(2021)는 404편의 관련 연구를 분석한 체계적 매핑 연구를 ACM Computing Surveys에 발표하였다 ^[11]. 이 연구는 NLP를 요구사항 공학에 적용하는 연구(NLP4RE) 분야가 결함 탐지, 요구사항 분류, 추적성 링크 생성, 모호성 탐지의 네 가지 주요 과제를 중심으로 발전해 왔음을 확인하였다. 그러나 동시에 실험 재현 가능성과 산업 현장 적용성이 여전히 미흡하며, 대부분의 연구가 소규모 데이터셋에 의존하고 도메인 특화 지식을 충분히 반영하지 못한다는 한계를 지적하였다.

안전이 필수적인 철도 분야에서의 요구사항 결함 자동 탐지 연구도 진전을 보이고 있다. Ferrari 외(2018)는 이탈리아 철도 신호 제조업체의 자연어 요구사항 문서 1,866건을 대상으로, GATE 텍스트 처리 프레임워크 기반의 NLP 패턴 규칙 집합을 개발하여 모호성, 불완전성, 중복 등 복수의 결함 유형을 자동으로 탐지하는 산업 사례 연구를 Empirical Software Engineering에 보고하였다 ^[12]. 더 최근의 연구로 Veizaga 외(2024)는 제어된 자연어(CNL: Controlled Natural Language) 문법 기반의 Paska 도구를 개발하여, 수동태, 불특정 수량어, 복합 조건 등 요구사항 스멜(Requirement Smell)을 자동으로 탐지하고 수정 권고를 생성하는 방법을 IEEE Transactions on Software Engineering에 발표하였다 ^[13]. 금융 도메인의 13개 시스템, 2,725개 요구사항을 대상으로 한 산업 사례 연구에서 Paska는 요구사항 품질 문제를 높은 정밀도로 탐지하였으며, 도메인 독립적으로 적용 가능함을 입증하였다.

표준문안 기반 요구사항 구조화 연구로는 Mavin 외(2009)의 EARS(Easy Approach to Requirements Syntax)가 대표적이다 ^[14]. EARS는 Rolls-Royce의 항공기 엔진 제어 시스템 요구사항 명세 경험을 바탕으로, 5가지 요구사항 유형 패턴과 WHILE–WHEN–SHALL의 표준 절 구조를 정의하여, 모호성·복잡성·불완전성 등 8가지 공통 요구사항 문제를 구조적으로 해소한다. 임혜선·이석원(2017)은 안전 필수 시스템에 특화된 표준문안(6개 요소)을 설계하고, GSN 모델과 결합함으로써 요구사항 명세 단계에서부터 결함을 식별하고 안전 증거와의 연결을 통해 안전 적합성을 증명하는 방법을 제안하였으나, 자동화를 위한 후속 연구의 필요성을 제시하였다 ^[4].

이상의 연구들은 NLP와 구조화 문법을 결합하면 자연어 요구사항의 품질을 자동으로 높일 수 있음을 보여 주지만, 한국어로 작성된 KRS 기반 철도 신호 요구사항처럼 도메인 특화 의무 표현과 복합 조건이 혼재하는 환경에 직접 적용하기 위한 체계적인 방법론은 아직 부재한 실정이다.

2.3 LLM의 소프트웨어 공학 적용

GPT-5, Claude Opus, Claude Sonnet, Gemini 등 대규모 언어 모델(LLM)의 소프트웨어 공학 분야 적용 연구가 급증하고 있다. Hou 외(2024)는 2017년부터 2024년 1월까지 발표된 395편의 연구를 대상으로 LLM의 소프트웨어 공학 적용에 관한 체계적 문헌 고찰을 수행하여, LLM이 요구사항 공학, 소프트웨어 설계, 코드 생성, 테스트, 유지보수의 전 생명주기에 걸쳐 활용되고 있음을 확인하였다 ^[15]. White 외(2023)는 소프트웨어 공학 작업에서 ChatGPT와의 효과적인 상호작용을 위한 프롬프트 패턴 카탈로그를 체계화하였다 ^[16].

안전 필수 시스템에서의 LLM 활용 연구도 진전을 보이고 있다. Nouri 외(2024)는 자율주행 시스템을 대상으로 LLM 기반 HARA 자동화 파이프라인 프로토타입을 개발하고, LLM이 안전 요구사항 도출을 수일에서 1일 이내로 단축할 수 있음을 보고하였으나, LLM 출력의 환각과 비결정론적 특성으로 인해 전문가 검증이 필수적임을 명시하였다 ^[17]. Greshake, Abdelnabi 외(2023)는 외부 데이터 소스와 연동된 LLM 통합 애플리케이션이 간접 프롬프트 인젝션 공격에 취약함을 실증하였다 ^[18]. 이러한 연구들은 공통적으로 LLM 출력의 비결정성과 신뢰성 한계를 지적하며, 안전 필수 도메인에서는 LLM을 최종 판정자가 아닌 보조 도구로 제한해야 할 필요성을 보여준다.

2.4 상태 전이 모델 기반 테스트 케이스 생성

상태 전이 모델(STM: State Transition Model) 기반 테스트 케이스 자동 생성은 철도 제어 소프트웨어 검증에서 오랫동안 활용되어 온 핵심 방법론이다. Kurian 외(2023)는 SCADE로 개발된 철도 임베디드 소프트웨어에 대해 기호 실행(Symbolic Execution)을 적용하여 테스트 케이스를 자동 생성하는 TECS(Test Engine for Critical Software) 도구를 개발하고, 기호 실행이 무작위 탐색 기반 방법 대비 높은 모델 커버리지를 달성함을 실증하였다 ^[19]. Bucaioni 외(2022)는 Bombardier Transportation의 Aventra 전동차 소프트웨어 제품 라인을 대상으로 메타 모델링과 모델 변환을 결합하여 제품 변형별 테스트 스크립트를 자동으로 생성하는 접근법을 보고하였다 ^[20].

Ferrari 외(2022)는 철도 신호 시스템 설계에 활용되는 형식 검증 도구들을 대상으로 체계적인 평가 및 사용성 분석을 수행하고, 요구사항 명세에서 검증 가능한 상태 모델을 도출하는 엔드-투-엔드 접근법의 필요성을 강조하였다 ^[21]. 그러나 이들 연구는 자연어 요구사항의 구조화 단계와 상태 전이 모델 생성 단계를 연결하는 파이프라인을 제시하지 않는다.

2.5 기존 연구와의 차별성

2절에서 고찰한 관련 연구들을 종합하면, 각 연구 흐름은 본 논문이 다루는 문제의 일부를 해결하고 있으나 이를 통합하는 접근은 이루어지지 않고 있다. 2.3절에서 검토한 LLM의 비결정성·환각 관련 연구들^[17][18]은 LLM을 요구사항 구조화 보조 도구로 한정하고 최종 안전 판정을 결정론적 규칙 엔진에 위임하는 본 논문의 하이브리드 아키텍처 설계 원칙을 뒷받침한다. 또한 2.4절에서 검토한 상태 전이 모델 기반 검증 연구들 ^[19][20][21]이 제시하지 못한 자연어 요구사항 구조화-상태 모델 생성 간 연결 고리는, 본 논문이 LLM으로 구조화한 표준문안 요구사항에서 상태 전이 모델을 추출하고 결정론적 엔진으로 검증하는 파이프라인을 제안함으로써 보완한다.

요구사항 자동 분석 측면에서 Zhao 외(2021) ^[11]와 Ferrari 외 (2018) ^[12]는 자연어 요구사항의 자동 품질 분석 가능성을 실증하였으나, 분석 결과를 표준문안 구조로 변환하는 자동화 체계를 제시하지 않는다.

Veizaga 외(2024)의 Paska 도구 ^[13]는 영어 자연어를 대상으로 하며, 한국어 KRS 표준과 같이 의무 표현 구조가 상이한 비영어권 도메인 특화 요구사항에 대한 적용 방법은 제시되지 않는다. Zadenoori 외(2025)의 체계적 문헌고찰 ^[22]도 대부분의 연구가 GPT 기반 모델에 의존하고 통제된 실험 환경에서만 평가되며 실무 도메인 통합이 제한적임을 지적하였다.

LLM 기반 안전 요구사항 명세 측면에서 Nouri 외(2024)의 ^[17]는 자율주행 ISO 26262 도메인을 대상으로 하였으나 전문가 검증이 필수적임을 강조하였다. 가장 직접적으로 관련된 선행 연구인 Oțelea 외(2025)는 GPT-4, Claude, Gemini를 대상으로 철도 신호 요구사항을 구조화된 제품 요구사항과 테스트 케이스로 변환하는 LLM 능력을 평가하였으나, 단일 LLM 직접 생성에 의존하고 결정론적 검증 단계를 포함하지 않아 EN 50128이 요구하는 재현성과 추적성 확보에 한계가 있다 ^[23]. 상태 전이 모델 기반 테스트 케이스 생성 측면에서 Kurian 외(2023) ^[19]와 Bucaioni 외(2022) ^[20]는 철도 도메인에서의 모델 기반 테스트 자동화 가능성을 입증하였으나, 자연어 요구사항 구조화 단계와 연결된 엔드-투-엔드 파이프라인을 제시하지는 않는다.

이러한 맥락에서 본 논문의 차별점은 세 가지로 요약된다. 첫째, 한국어 KRS 표준 요구사항을 대상으로 도메인 특화 표준문안 구조로 자동 변환하는 LLM 기반 체계를 제안한 최초의 연구로, 비영어권 안전 필수 표준 환경에서의 LLM4RE 적용 공백을 채운다. 둘째, LLM을 요구사항 구조화 초안 생성에만 활용하고 최종 안전 판정은 결정론적 규칙 엔진과 형식 모델 검증기에 위임하는 하이브리드 아키텍처를 통해, 기존 LLM 단독 적용 연구가 해결하지 못한 재현성과 추적성 요건을 충족한다. 셋째, 요구사항 구조화부터 상태 전이 모델 생성, 테스트 케이스 도출, 추적성 매트릭스 생성까지의 엔드-투-엔드 파이프라인 아키텍처를 제안한다.

3.1 KRS 표준 체계 개요

한국철도표준은 국토교통부 산하 철도기술심의위원회가 제정하고 관리하는 기술 표준 체계이다. 철도 노선·차량·신호·통신·전기·토목을 아우르며 수백 종의 문서로 구성되어 있는데, 신호 분야에서는 KRS-SG 시리즈가 중심축을 이룬다. 그 가운데 KRS-SG-0069는 도시철도 무선 통신 기반 열차제어 시스템의 기능 요구사항을 정의한 문서로, 본 연구가 분석 대상으로 삼은 핵심 표준이다.

KRS-SG-0069는 WATP, OATP, OATO, ATS, EIS, PSD라는 여섯 개의 기능 블록으로 짜여 있다. 각 기능 블록은 수십에서 수백 개에 이르는 한국어 자연어 요구사항으로 기술되며, 안전 무결성 수준은 블록에 따라 0단계에서 4단계까지 분포한다. 표 1은 본 연구에서 분석한 기능 블록별 요구사항 현황을 정리한 것이다. 개별 요구사항 식별자(WATP-F-01 등) 전체 목록은 부록 A.1에 수록하였다.

3.2 KRS 표준 요구사항의 자연어 특성 분석

본 절은 제안 프레임워크의 설계 근거를 마련하기 위한 문제 진단으로, 프레임워크의 성능을 실험적으로 측정하는 것이 아니라 KRS-SG-0069 요구사항이 가진 자연어 결함의 유형과 분포를 체계적으로 파악하는 것을 목적으로 한다. 분석 대상은 KRS-SG-0069에 수록된 기능 요구사항 전체 94건으로, 임의 표본 추출이나 부분 선정이 아닌 표준 문서 전체 대상 분석이다. 각 요구사항을 원문 KRS 텍스트와 대조하면서 임혜선·이석원(2017)이 제안한 표준문안 6요소로의 구조적 변환을 저해하는 자연어 특성을 분류한 결과, 일곱 가지 결함 유형이 반복적으로 확인되었다.

결함 유형은 다음과 같이 정의된다. Entity 누락(D1)은 기능을 수행하는 주체 또는 수신 대상 시스템이 문장에 명시되지 않은 경우이다. ATS는 복수의 주체가 병립하는 구조여서 원문이 주체를 생략하는 경향이 두드러진다. Precondition 불명확(D2)은 기능 발동의 선행 조건이 정량적으로 특정되지 않은 경우로, 일곱 유형 중 발생 건수가 가장 많다(88.3%). Condition 트리거 불명확(D3)은 기능 발동을 촉발하는 이벤트가 정성적으로만 기술된 경우로, 상태 전이 모델 생성 단계에서 Guard Condition을 특정할 수 없게 만든다. Exception 미정의(D4)는 비정상 상황 대응이 기술되지 않은 경우로, 두 번째로 높은 발생 건수(79.8%)를 보인다. Transition 모호성(D5)은 상태 전이의 완료 조건이 수치 기준 없이 기술된 경우로, OATO에서 가장 높은 비율(53.8%)을 보인다. Emergency 미분류(D6)는 비상 기능이 일반 기능과 구분 없이 기술된 경우로, 발생 빈도는 가장 낮으나(7.4%) SIL 배정 근거를 흐리는 파급 효과가 크다. 복합 요구사항 비분리(D7)는 독립적으로 검증되어야 할 기능이 하나의 문장에 결합된 경우로, EIS는 전체 요구사항이 해당된다(100%).

분석 결과를 종합하면 네 가지가 두드러진다. 첫째, Precondition 불명확(88.3%)과 Exception 미정의(79.8%)가 나란히 높은 비율을 차지하며, 두 결함 모두 서브시스템 간 연동 흐름에서 비롯되는 경우가 많아 단순한 문장 교정으로는 해소하기 어렵다. 둘째, Condition 트리거 불명확(27.7%)은 OATP에 집중되며 상태 전이 모델 생성 단계의 파싱 오류로 직결된다. 셋째, 복합 요구사항 미분리(48.9%)도 절반에 근접하는 결함률을 보인다. 넷째, 결함 유형의 서브시스템별 분포가 고르지 않다. OATO는 Transition 모호성 비율이 가장 높고, OATP는 총 결함 건수와 D3 발생 건수가 모든 서브시스템 중 가장 높아 요구사항 재작성 우선순위를 높여야 할 서브시스템으로 식별된다.

3.3 EN 50128 소프트웨어 요구사항 명세 요건

EN 50128 표준의 7.2.4절은 소프트웨어 요구사항 명세 단계에서 준수해야 할 요건을 7.2.4.1부터 7.2.4.15까지 15개 조항으로 규정한다. 이 절에서는 3.2절에서 식별한 일곱 가지 결함 유형 각각이 7.2.4절의 어느 조항을 위반하는지를 규정하고, 그 구조적 함의를 M3 규칙 엔진 설계(5.3절)와 연결한다.

4.1 전체 아키텍처 개요

제안 프레임워크는 KRS 표준 자연어 요구사항을 EN 50128 준수 표준문안 구조로 변환하고, 규칙 기반 검증과 형식 모델 검증을 거쳐 테스트 케이스와 추적성 매트릭스를 자동 생성하는 4단계 반자동 파이프라인이다. M1에서 M4까지 네 개의 처리 모듈이 단방향으로 연결되며, 각 모듈의 출력이 다음 모듈의 입력으로 흘러 들어가는 데이터 파이프라인 형태를 취한다.

그림 1 제안 프레임워크 전체 아키텍처

Fig. 1 Overall Architecture of the Proposed Framework

파이프라인의 입구인 M1(전처리 및 요구사항 분류)은 KRS-SG-0069 원문 문서에서 기능 요구사항을 추출하고 서브시스템별로 분류한다. 의무적 표현("~하여야 한다" 등)을 기준으로 요구사항 문장을 식별하고, 절 번호 접두사와 키워드 매칭을 결합하여 각 요구사항을 5개 기능 블록에 귀속시키며, 언어적 복잡도 점수를 산출해 후속 처리의 우선순위를 결정한다(구현 세부는 5.2절 및 부록 A.1 참조).

M2(LLM 기반 표준문안 구조화)는 자연어 요구사항을 6요소 표준문안으로 변환하는 파이프라인의 핵심 단계다. Chain-of-Thought(CoT) 방식의 프롬프트 템플릿으로 LLM API를 호출하고, 복수의 Temperature 설정으로 반복 실행한 뒤 다수결로 결과를 통합하는 앙상블 전략을 적용한다. 각 표준문안 요소에는 신뢰도 점수가 부여되며, 이 점수에 따라 정상 경로·전문가 검토 플래그 유지·수동 처리 요청의 세 가지 처리 경로가 결정된다. 이 단계의 산출물은 검증을 거치지 않은 초안으로 명시적으로 표시되며, M3의 점검 없이 후속 단계로 넘어가는 일은 없다(5.2절).

M3(규칙 기반 검증 및 형식화)는 M2가 생성한 초안을 결정론적 규칙 엔진이 점검하는 단계다. 완전성 검사(L1)·형식 일관성 검사(L2)·도메인 의미 검사(L3)·상호 요구사항 일관성 검사(L4)의 네 계층이 순차적으로 작동하며, 상위 계층을 통과하지 못한 요소는 하위 계층으로 넘기지 않아 오류 중첩을 방지한다. 검증이 완료된 명세에는 EN 50128 7.2.4절 15개 조항별 준수 여부를 기록한 준수 매트릭스를 함께 산출한다. 이 단계의 판정은 어떠한 경우에도 규칙 엔진이 수행하며 LLM이 개입할 여지는 없다(5.3절).

파이프라인의 출구인 M4(자동 검증 아티팩트 생성)는 M3가 승인한 표준문안 명세를 재료로 세 가지 검증 아티팩트를 자동으로 생성한다. Precondition을 초기 상태, Condition을 전이 트리거, Transition을 행동 및 후속 상태로 매핑하여 상태 전이 모델을 생성하고, NuSMV 모델 검증기를 통해 네 가지 CTL(Computation Tree Logic) 속성을 검증한다. 이어서 STM의 전이 그래프에서 All-Transition 커버리지 기준의 테스트 케이스를 도출하고, 요구사항-시험 추적 매트릭스(RTM)를 생성한다(5.4절).

4.2 설계 원칙: LLM의 역할 제한과 결정론적 검증 위임

이 프레임워크를 설계하면서 가장 먼저 확정한 원칙은 역할 분리다. LLM은 자연어 요구사항을 표준문안 구조로 변환하는 초안 생성에만 관여하고, 안전 판정은 전적으로 결정론적 규칙 엔진과 형식 모델 검증기가 담당한다. Nouri 외(2024)^[17]와 Greshake 외(2023)^[18]가 지적한 것처럼 LLM의 환각과 비결정론적 출력 특성은 재현성이 의무화된 안전 시스템에서 수용할 수 없는 위험이기 때문이다.

이 원칙을 아키텍처 수준에서 강제하기 위해 세 가지 메커니즘을 구현한다. 첫째, M2에서 각 표준문안 요소가 생성될 때마다 신뢰도 점수를 산출하고, 임계값 이하 요소에는 전문가 검토 플래그를 자동 부착한다. 둘째, 검증 게이트(Verification Gate)로서, M2 출력물은 반드시 M3 규칙 엔진의 4개 계층 점검을 통과해야만 Verified 상태를 얻으며, 이를 우회하는 경로는 구조적으로 존재하지 않는다. 셋째, 감사 추적(Audit Trail)으로서, LLM 프롬프트 입력·원시 출력·규칙 엔진 판정 결과를 모두 타임스탬프와 함께 로그 데이터베이스에 저장하여 사후 재현성과 설명 가능성을 확보한다. 이 세 메커니즘이 완화할 수 있는 범위와 그렇지 못한 한계는 5.2.3절에서 별도로 논의한다.

4.3 데이터 흐름 및 인터페이스

파이프라인 전체의 데이터 흐름은 단방향이다. KRS 표준 문서가 입력으로 들어오면 M1→M2→M3→M4를 순차적으로 통과하며 최종적으로 요구사항-시험 추적 매트릭스가 산출된다. 각 모듈 간 경계에서 주고받는 데이터는 JSON 형식으로 직렬화하여 저장하므로, 특정 단계만 독립적으로 재실행하거나 중간 결과를 직접 검토하는 것이 가능하다.

M1→M2 경계에서는 요구사항 기본 속성과 언어적 복잡도 점수가 전달된다. M2→M3 경계에서는 6요소 표준문안 초안이 요소별 값·신뢰도 점수와 함께 전달되며, 신뢰도가 0.4 미만인 요소는 자동 처리가 중단되고 0.4~0.7 구간은 규칙 엔진 통과 후에도 전문가 검토 플래그가 유지된다. M3→M4 경계에는 4개 계층을 모두 통과한 표준문안 명세와 EN 50128 조항별 준수 매트릭스만 포함되며, 검증을 마치지 못한 항목은 이 경계를 넘지 못한다. M4의 최종 산출물은 NuSMV 모델 파일, 테스트 케이스 집합, 요구사항-시험 추적 매트릭스 세 가지로, 모든 중간 산출물에는 타임스탬프와 처리 모듈 ID가 포함되어 사후 감사 추적이 가능하다(세부 스키마는 부록 A 참조).

4.4 확장성 및 유지보수성

프레임워크는 모듈 간 느슨한 결합 원칙에 따라 설계되었다. 각 모듈이 JSON 인터페이스만을 통해 연결되므로 모듈 내부 변경이 다른 모듈에 파급되지 않는다. KRS 표준이 개정될 경우 M3의 규칙 엔진과 KRS 용어 사전만 갱신하면 나머지 모듈은 그대로 재사용할 수 있다. LLM 모델을 교체할 경우 M2의 프롬프트 템플릿과 출력 파서를 수정하는 것으로 충분하며, M3·M4의 결정론적 엔진은 변경 없이 유지된다. 변경의 파급 범위가 항상 단일 모듈 안에서 멈춘다는 것이 이 설계의 유지보수성 핵심이다.

5.1 M1: 전처리 및 요구사항 분류

KRS-SG-0069는 HWP와 PDF 두 형식으로 배포된다. 파서는 두 형식을 구분한 뒤 각각 별도 경로로 텍스트를 추출하고(HWP: pyhwp, PDF: Apache Tika/PyMuPDF), 절 번호·의무 표현을 기준으로 요구사항 문장을 식별하며, 절 번호 접두사와 키워드 매칭을 결합해 5개 기능 블록에 귀속시킨다. 이어 절 수·의존성 깊이·모호성 지시자·조건 중첩도·수치 속성 수의 다섯 지표를 가중 합산하여 언어적 복잡도 점수를 산출하고, 임계값(0.7)을 초과하는 요구사항은 전문가 검토 대상으로 자동 분류한다. M1 자체는 표준 NLP 전처리 기법의 조합으로, 본 논문의 신규 기여는 아니며 M2~M4의 입력을 준비하는 역할에 한정된다. 라이브러리 버전, 6단계 파이프라인, 복잡도 점수 산출 공식 등 정규표현식 전문은 부록 A.1에 수록하였다.

5.2 M2: LLM 기반 표준문안 구조화

5.3 M3: 규칙 기반 검증 및 형식화

5.4 M4: 자동 검증 아티팩트 생성