형태소 분석으로 test basis 점검 — 모호어·약한 표현·용어 불일치를 걸러 내고 테스트 조건 뽑기

개념

test basis 점검이 왜 "언어 문제"인가

레슨 3에서 요구사항명세서와 화면설계서를 실제 구현에 맞게 현행화했다. 그런데 현행화된 문서가 곧바로 좋은 test basis가 되는 것은 아니다. 문서가 구현과 일치 하는 것과, 문서가 테스트할 수 있게 쓰였는가 는 다른 문제다. "결제 실패 시 적절한 안내 문구를 신속히 노출한다"는 문장은 구현과 어긋나지 않을 수 있다. 그러나 무엇이 적절한지, 얼마나 빨라야 신속한지 아무도 판정할 수 없다.

모듈 2 레슨 3에서 모호함과 누락을 사람의 눈으로 찾는 법을 배웠다. 문서가 수십 쪽일 때는 그 방법이 통한다. AI가 레거시 산출물을 역분석해 수백 쪽의 기획 문서를 하룻밤에 만들어 내는 환경(레슨 2)에서는 사람이 한 줄씩 읽는 방식이 버티지 못한다. 그래서 test basis 점검의 첫 단계를 언어 처리 로 옮긴다. 문장을 기계가 다룰 수 있는 단위로 쪼개고, 쪼갠 단위에 규칙을 건다.

이 레슨의 흐름은 다음과 같다.

현행화된 test basis (요구사항명세서·화면설계서·정책 문서)
   │
   ├─ 1. 문장 분리 → 형태소 분석 (품사 태그 부착)
   ├─ 2. 규칙 점검: 약한 표현·모호 대명사·복합 요구·수치 누락
   ├─ 3. 용어 점검: 용어 사전과 대조해 동의어·금지어 표시
   ├─ 4. LLM 점검: 규칙이 못 잡는 의미 수준의 모호함·모순
   ├─ 5. 테스트 조건 추출: 동사·목적어·조건절 → 조건 후보
   └─ 6. 사람 검토 → 문서 수정 요청 또는 테스트 조건 확정

형태소란 무엇이고, 왜 띄어쓰기 단위로는 부족한가

형태소(morpheme) 는 뜻을 가진 가장 작은 말의 단위다. 영어는 단어 사이를 띄어 쓰고 단어 형태 변화가 적어서, 공백으로 자르기만 해도 꽤 쓸 만한 단위가 나온다. 한국어는 교착어 다. 하나의 어절(띄어쓰기 단위) 안에 명사·조사·어간·어미가 줄줄이 붙는다.

문장:  "잔액이 부족하지 않으면 결제를 승인한다"
 
어절 단위:    잔액이 / 부족하지 / 않으면 / 결제를 / 승인한다
형태소 단위:  잔액/NNG 이/JKS  부족/NNG 하/XSA 지/EC  않/VX 으면/EC
              결제/NNG 를/JKO  승인/NNG 하/XSV ㄴ다/EF

어절로만 자르면 "결제를"과 "결제는"과 "결제가"가 서로 다른 단어가 된다. 용어 사전에 "결제"를 등록해도 매칭이 안 된다. "않으면" 안에 숨은 조건(-으면) 과 부정(않-) 도 어절 단위로는 규칙을 걸기 어렵다. 형태소 분석을 거치면 명사는 명사대로 모으고, 조건을 나타내는 연결 어미(EC)는 연결 어미대로 찾을 수 있다. test basis 점검에서 형태소 분석이 하는 일은 결국 이것이다. 표면이 다른 말을 같은 단위로 모으고, 문법 기능을 태그로 드러낸다.

품사 태그는 대부분의 한국어 분석기가 세종 품사 태그 체계를 바탕으로 쓴다. 이 레슨에서 자주 쓰는 태그만 정리한다.

한국어 형태소 분석기 지형 — Kiwi, MeCab-ko, KoNLPy

도구를 고를 때는 정확도 숫자보다 설치 난도, 사용자 사전 지원, 라이선스, 유지보수 상태 를 먼저 본다. 사내 파이프라인에 들어가서 몇 년을 돌아야 하기 때문이다.

Kiwi 저장소는 웹 텍스트에서 약 87%, 정제된 문어체에서 약 94% 수준의 정확도를 밝히고 있다. 요구사항 문서는 문어체에 가깝지만, 사내 용어·화면명·약어 가 많아 실제 정확도는 이보다 낮게 나오기 쉽다. "출금한도조회API", "간편결제(PAY)" 같은 말은 분석기가 제멋대로 쪼갠다. 그래서 어떤 도구를 쓰든 사용자 사전 이 실무의 핵심이 된다. 벤더나 저장소가 밝힌 숫자는 일반 말뭉치 기준이니, 도입 전에 우리 문서 100문장으로 직접 정확도를 재 보는 것이 맞다.

# pip install kiwipiepy  (버전은 requirements.txt에 고정한다)
from kiwipiepy import Kiwi
 
kiwi = Kiwi()
# 사내 용어를 고유 명사로 등록해 엉뚱하게 쪼개지지 않게 한다
for term in ["간편결제", "출금한도", "본인인증", "선불충전금"]:
    kiwi.add_user_word(term, "NNP")
 
for tok in kiwi.tokenize("간편결제 실패 시 적절히 안내 문구를 노출한다"):
    print(tok.form, tok.tag, tok.start, tok.len)

tokenize() 가 돌려주는 토큰에는 형태(form)·태그(tag)와 함께 원문에서의 시작 위치(start)와 길이(len) 가 들어 있다. 이 위치 정보가 중요하다. 점검 결과를 "3장 2절 REQ-PAY-031, 14번째 글자부터 '적절히'"처럼 원문에 정확히 되짚어 표시할 수 있기 때문이다. 위치 없는 지적은 문서 작성자가 고치지 않는다.

좋은 요구사항의 특성 — ISO/IEC/IEEE 29148

무엇을 "나쁜 문장"으로 볼지 기준이 있어야 규칙을 만들 수 있다. 요구사항 공학 표준 ISO/IEC/IEEE 29148은 개별 요구사항이 갖춰야 할 특성을 다음과 같이 정리한다(표준 판에 따라 표현이 조금 다르다). QA 관점에서 기계로 점검하기 쉬운 정도를 함께 적었다.

표의 핵심은 오른쪽 두 칸이다. 명확성·단일성·준수성은 형태소 규칙만으로 상당 부분 잡히고, 필요성·정확성은 기계가 거의 못 잡는다. 그래서 규칙 기반 점검과 LLM 점검과 사람 검토가 각각 다른 특성을 맡는다.

요구사항 스멜과 약한 표현 사전

코드에 "코드 스멜"이 있듯 요구사항에도 요구사항 스멜(requirements smell) 이 있다. Femmer 등의 연구는 이 개념을 요구사항 공학으로 옮기고, 품사 태깅·사전·표제어 추출(lemmatization)로 스멜을 자동 탐지하는 프로토타입 Smella를 만들었다. 실제 산업 문서에 적용했을 때 평균 정밀도(precision) 약 59%, 재현율(recall) 약 82% 수준이었다. 숫자를 읽는 법이 중요하다. 놓치는 것은 적지만 잘못 지적하는 것도 많다. 자동 탐지는 "여기 한번 보세요"라는 표시이지 판정이 아니다. 연구진도 정확한 판정보다 품질 결함에 대한 인식이 높아지는 효과 를 더 큰 이득으로 꼽았다.

한국어 문서용 약한 표현 사전은 팀이 직접 만들어야 한다. 출발점으로 쓸 수 있는 분류는 다음과 같다.

"등"은 특히 위험하다. "카드·계좌이체 등의 결제 수단을 지원한다"는 문장에서 QA는 몇 개의 결제 수단을 테스트해야 하는가? 개발자는 카드와 계좌이체 두 가지를 만들고, 기획자는 간편결제까지 생각했고, QA는 휴대폰 결제까지 테스트 범위에 넣는 일이 실제로 생긴다. 열린 나열은 범위의 합의가 없다는 증거 다.

형태소 규칙으로 스멜 잡기 — 최소 구현

아래는 약한 표현과 복합 요구를 잡는 최소 예시다. 실무용이라기보다 구조를 보여 주기 위한 코드다.

from kiwipiepy import Kiwi
 
kiwi = Kiwi()
WEAK_ADVERBS = {"적절히", "신속히", "원활히", "최대한", "충분히", "가급적"}
OPEN_LIST = {"등", "기타", "외"}
DISCRETION = {"필요시", "가능하면", "원칙적으로"}
VAGUE_REF = {"해당", "상기", "이것"}
 
def check(req_id, sentence):
    toks = kiwi.tokenize(sentence)
    findings = []
    for t in toks:
        if t.form in WEAK_ADVERBS and t.tag.startswith("MA"):
            findings.append(("모호한 부사", t.form, t.start))
        elif t.form in OPEN_LIST and t.tag.startswith("NN"):
            findings.append(("열린 나열", t.form, t.start))
        elif t.form in DISCRETION:
            findings.append(("재량 표현", t.form, t.start))
        elif t.form in VAGUE_REF:
            findings.append(("모호 지시어", t.form, t.start))
    verbs = [t for t in toks if t.tag in ("VV", "XSV")]
    if len(verbs) >= 3:
        findings.append(("복합 요구 의심", f"행위 {len(verbs)}개", 0))
    return [(req_id, *f) for f in findings]
 
print(check("REQ-PAY-031", "결제 실패 시 해당 사유를 적절히 안내하고 재시도 등을 제공한다"))

두 가지를 눈여겨본다. 첫째, 단어만 보지 않고 태그를 함께 본다. "등"이 일반 명사로 쓰인 "등(背)"이나 "등급"의 일부일 때 잘못 잡지 않으려는 것이다. 형태소 분석이 단순 문자열 검색보다 나은 지점이 여기다. 둘째, 결과에 요구사항 ID와 원문 위치 를 붙인다. 레슨 3의 추적성 매트릭스와 이어지려면 모든 지적이 ID로 돌아가야 한다.

용어 불일치 — 기획·개발·QA 용어 사전 정렬

같은 조직 안에서도 부서마다 말이 다르다. 모듈 30 레슨 6에서 본 것처럼 기획은 "버그", 개발은 "이슈"나 "defect", QA는 "결함", 운영은 "장애"라고 부른다. 엄밀히 하면 오류(error)·결함(defect)·실패(failure)·장애(incident)는 다른 개념인데, 문서마다 섞여 쓰이면 테스트 결과 보고와 결함 통계가 엉킨다. 도메인 용어에서도 같은 일이 생긴다.

"결제 취소"와 "환불"은 특히 흔한 함정이다. 카드 승인 당일 취소는 매입 전 승인 취소이고, 매입 후에는 환불(매입 취소)이 되어 처리 경로와 반영 시점이 다르다. 문서가 두 말을 섞으면 QA는 한쪽 경로만 테스트하게 된다.

용어 사전은 세 칸이면 시작할 수 있다. 표준어, 허용 동의어, 금지어. 형태소 분석으로 문서의 명사를 모두 모아 사전과 대조하면, 표준어 대신 동의어가 쓰인 곳과 금지어가 쓰인 곳이 자동으로 표시된다.

# glossary.yml — 기획·개발·QA 합의본, 변경은 PR로만
- term: 회원 탈퇴
  synonyms: [탈퇴, 해지, 회원 해지]   # 문서에 나오면 '표준어로 바꾸기' 제안
  forbidden: [계정 삭제]              # 의미가 다름: 데이터 즉시 삭제로 오해
  code_names: [withdraw, delete_yn]
  definition: 회원이 이용 계약을 끝내는 것. 개인정보는 정책에 따른 보존 기간 후 파기
- term: 결함
  synonyms: [버그, defect, 이슈]
  forbidden: [장애]                   # 장애는 운영 중 서비스 영향이 발생한 사건

사전에 code_names 를 두는 이유는 레슨 2·3과의 연결 때문이다. AI가 코드에서 복원한 문서는 withdraw 같은 코드 이름을 그대로 가져오기 쉽다. 코드 이름과 표준어의 대응표가 있어야 복원 문서와 기존 문서를 같은 말로 비교할 수 있다.

동사와 조건절에서 테스트 조건 뽑기

ISTQB는 테스트 조건(test condition) 을 테스트 근거에서 식별한, 테스트할 수 있는 측면으로 본다. 문장 구조로 말하면 테스트 조건은 대개 "어떤 조건에서 + 무엇이 + 어떻게 된다" 의 꼴이다. 형태소 분석 결과에서 이 세 칸을 기계적으로 뽑을 수 있다.

예를 들어 "잔액이 결제 금액보다 적으면 결제를 승인하지 않고 충전 화면으로 이동한다"는 문장에서 다음 조건 후보가 나온다.

TC-COND-01  [조건] 잔액 < 결제 금액         [행위] 결제 승인 안 됨
TC-COND-02  [조건] 잔액 < 결제 금액         [행위] 충전 화면으로 이동
TC-COND-03  [조건] 잔액 = 결제 금액 (경계)   [행위] ? ← 문서에 없음, 질의 필요
TC-COND-04  [조건] 잔액 > 결제 금액         [행위] ? ← 문서에 없음 (승인으로 추정)

3번과 4번이 이 방법의 진짜 가치다. 조건절을 뽑아 반대 조건과 경계 조건을 기계적으로 생성 하면 문서가 말하지 않은 부분이 드러난다. 동등 분할과 경계값 분석(모듈 3 레슨 1)을 문장 구조에 적용한 셈이다. 문서에 없는 칸은 추정으로 채우지 않고 질의 목록 으로 보낸다. 추정으로 채우는 순간 test basis 점검이 아니라 test basis 창작이 된다.

LLM과 규칙 기반을 병행하는 이유

요즘은 "LLM에게 요구사항을 주고 문제를 찾아 달라고 하면 되지 않나"라는 질문이 먼저 나온다. 실제로 Lubos 등의 연구(RE 2024)는 LLM이 ISO 29148 기준으로 요구사항 품질을 평가하고, 이유를 설명하고, 개선안을 제시할 수 있음을 보였다. 그러나 둘을 대체 관계로 보면 안 된다. 성질이 다르다.

실무 분업은 이렇다. 규칙 기반이 전수 점검을 하고, LLM은 규칙이 표시한 문장과 규칙이 못 보는 문장 간 관계를 본다. LLM에게는 형태소 분석 결과와 용어 사전을 함께 넘겨서, 사내 용어를 일반 단어로 오해하지 않게 한다. LLM의 지적에는 반드시 원문 인용 을 요구하고, 인용이 원문에 실제로 있는지는 다시 코드로 확인한다(모듈 38 레슨 1의 "결정적으로 판정할 수 있는 것은 결정적으로"). 인용 없는 지적, 원문에 없는 인용은 버린다.

[LLM 점검 지시 예]
너는 test basis 검토자다. 아래 요구사항 묶음에서
(1) 서로 모순되는 문장 쌍, (2) 정의되지 않은 상태나 화면 이동, (3) 문서 간 수치 불일치를 찾아라.
- 각 지적에는 반드시 요구사항 ID와 원문을 그대로 인용한다.
- 용어는 첨부한 glossary.yml의 정의를 따른다. 사전에 없는 말을 새로 정의하지 마라.
- 규칙 점검기가 이미 표시한 약한 표현은 다시 보고하지 마라.
- 확신이 낮으면 '질의'로 분류하고, 문서를 고친 문장을 제안하지 마라.

마지막 줄이 중요하다. LLM이 문장을 고쳐 쓰게 두면, 모호한 요구가 LLM이 상상한 구체적인 요구로 바뀐다. 그 구체성은 기획 의도가 아니라 모델의 추측 이다. 고쳐 쓰기는 문서 소유자의 일이고, QA와 AI는 질의와 근거를 만든다.

점검 결과를 어떤 형태로 내보내는가

점검 결과는 문서 작성자가 바로 고칠 수 있는 형태여야 한다. 지적 목록을 메일로 던지면 아무도 고치지 않는다. 다음 형식이 실무에서 쓰기 좋다.

"상태" 칸에서 자동 수정 가능 은 용어 표준화처럼 의미가 바뀌지 않는 것에만 붙인다. 수치·범위·조건이 바뀌는 지적은 언제나 질의다. 이 점검표가 레슨 3의 갱신 승인 절차로 그대로 들어가고, 확정된 테스트 조건은 레슨 5의 설계 에이전트 입력이 된다.

실무에서 왜 필요한가

AI가 테스트를 설계하는 조직에서 test basis의 모호함은 증폭된다. 사람 설계자는 "적절히"를 보면 기획자에게 물어봤다. 설계 에이전트는 묻지 않고 그럴듯한 값으로 채워 케이스를 만들고, 그 케이스로 통과를 판정한다. 모호한 문장 하나가 수십 개의 근거 없는 케이스로 번진다. test basis를 테스트 설계 전에 기계적으로 걸러 내는 단계는 그래서 비용이 아니라 보험이다.

용어 정렬도 같은 이유로 중요하다. 기획·개발·QA가 서로 다른 말을 쓰면 추적성 매트릭스가 끊기고, 결함 통계가 부서마다 다르게 집계되고, AI는 동의어를 서로 다른 개념으로 처리한다. 용어 사전은 사람 간 소통 도구였던 것이 AI에게 주는 입력 사양 이 된다.

또 하나, 이 작업은 QA가 개발 이전 단계에 개입하는 가장 구체적인 방법이다. "요구사항이 모호하다"는 의견은 무시되기 쉽지만, "REQ-PAY 영역 120문장 중 약한 표현 34건, 열린 나열 11건, 용어 불일치 19건, 경계 조건 미정의 8건"이라는 점검표는 회의 안건이 된다.

채용시장에서의 위치

AI 품질·QA 리드 직무의 공고에 "요구사항 정적 분석", "테스트 근거 자동 검토", "도메인 용어 체계 관리" 같은 표현이 늘고 있다. 형태소 분석기를 직접 개발할 필요는 없지만, 파이썬으로 분석기를 불러 규칙을 걸고 결과를 요구사항 ID에 연결하는 정도의 스크립트 능력, 그리고 LLM 점검 결과를 그대로 믿지 않고 근거를 검증하는 설계 감각을 함께 보여 주면 차별점이 된다. 면접에서는 "어떤 규칙으로 무엇을 몇 건 잡았고, 그중 실제 문서 수정으로 이어진 비율이 얼마였는가"처럼 정밀도까지 말할 수 있으면 설득력이 크다.

실습 과제

과제 1 — 형태소 분석기 체험과 사용자 사전 (20분)

kiwipiepy를 설치하고, 본인이 아는 서비스의 요구사항 문장 10개(공개 문서나 직접 쓴 가상 문장)를 분석한다. 사내 용어·화면명이 잘못 쪼개지는 사례를 3개 이상 찾고, add_user_word 로 등록한 뒤 결과가 어떻게 바뀌는지 전후를 표로 비교한다. 분석기 버전을 기록하고, 버전을 고정해야 하는 이유를 한 문단으로 쓴다.

과제 2 — 약한 표현 사전과 점검기 만들기 (30분)

이 레슨의 스멜 표를 바탕으로 약한 표현 사전을 최소 30개 항목으로 만든다. 각 항목에 규칙 ID, 유형, 기대 품사 태그를 붙인다. 본문의 최소 구현을 확장해 아래 문장들을 점검하고, 잘못 잡은 것(오탐)과 놓친 것(미탐)을 각각 세어 정밀도와 재현율을 대략 계산한다.

1. 로그인 실패가 반복되면 적절한 조치를 취한다.
2. 관리자는 회원 정보를 조회하고 수정하며 삭제할 수 있다.
3. 등급별 혜택은 기타 정책에 따른다.
4. 상기 화면에서 확인 버튼을 누르면 해당 내역이 표시된다.
5. 등 쪽 통증 문의는 상담 메뉴로 안내한다.
6. 주문 완료 후 30분 이내에는 고객이 직접 취소할 수 있어야 한다.

5번(오탐 유도)과 6번(문제없어 보이지만 "고객"이 용어 사전과 충돌)을 어떻게 다뤘는지 반드시 설명한다.

과제 3 — 용어 사전과 조건 추출 (25분)

결제·회원 영역에서 기획·개발·QA가 다르게 부르는 개념 5개를 골라 표준어·동의어·금지어·코드명·정의를 갖춘 용어 사전을 쓴다. 그리고 다음 문장에서 조건절·대상·행위·부정·수치를 뽑아 테스트 조건 후보를 만들고, 문서에 없는 반대·경계 조건을 질의 목록으로 따로 적는다.

비밀번호를 5회 연속 잘못 입력하면 계정을 잠그고, 본인인증을 완료하지 않으면 잠금을 해제하지 않는다.

과제 4 (선택) — 규칙 점검과 LLM 점검 비교 (25분)

같은 요구사항 묶음(20문장 이상)을 규칙 점검기와 LLM에 각각 넣는다. LLM에는 원문 인용을 요구하는 지시를 쓴다. 두 결과를 겹치는 지적, 규칙만 잡은 지적, LLM만 잡은 지적으로 나누고, LLM 지적 중 인용이 원문과 다른 것이 몇 건인지 센다. 같은 지시로 LLM을 세 번 돌려 결과가 얼마나 흔들리는지도 기록한다.

자가 체크리스트

• 교착어인 한국어에서 어절 단위 대신 형태소 단위로 점검해야 하는 이유를 예로 설명할 수 있다
• NNG·VV·VA·MAG·EC·EF 태그가 test basis 점검에서 각각 무엇을 찾는 데 쓰이는지 말할 수 있다
• Kiwi·MeCab-ko·KoNLPy의 차이를 설치·사용자 사전·라이선스 관점에서 비교할 수 있다
• ISO/IEC/IEEE 29148의 좋은 요구사항 특성 중 기계 점검이 쉬운 것과 어려운 것을 구분할 수 있다
• 요구사항 스멜 자동 탐지가 판정이 아니라 표시라는 점을 정밀도·재현율로 설명할 수 있다
• 표준어·동의어·금지어·코드명을 갖춘 용어 사전을 만들고 문서와 자동 대조할 수 있다
• 조건절에서 반대 조건과 경계 조건을 생성하고, 문서에 없는 칸을 질의로 보낼 수 있다
• 규칙 기반 점검과 LLM 점검의 분업을 정하고, LLM 지적의 인용을 코드로 검증할 수 있다

흔한 실수

문자열 검색으로 끝낸다. "등"을 문자열로 찾으면 "등급", "등록", "등 통증"까지 걸린다. 오탐이 많으면 문서 작성자가 점검표 전체를 무시한다. 품사 태그를 함께 봐야 한다.

사용자 사전 없이 돌린다. 사내 용어가 잘게 쪼개지면 용어 대조와 조건 추출이 모두 틀어진다. 사전 구축이 도입 작업의 절반이다.

분석기 버전을 고정하지 않는다. 분석기가 업데이트되면 같은 문서의 점검 결과가 바뀌어, 지난달 대비 개선 추이를 비교할 수 없다.

LLM에게 문장을 고쳐 쓰게 한다. 모호한 요구가 모델의 추측으로 구체화되어 test basis에 들어간다. LLM은 질의와 근거까지만 만든다.

자동 지적을 그대로 결함으로 등록한다. 정밀도가 60% 안팎인 도구의 지적은 검토 대상이지 결함이 아니다. 사람이 걸러서 문서 소유자에게 보낸다.

용어 사전을 QA 혼자 만든다. 기획·개발이 합의하지 않은 사전은 QA 문서에서만 쓰이고 끝난다. 변경은 세 부서가 함께 보는 PR로 관리한다.

참고 자료

• Kiwi — 지능형 한국어 형태소 분석기 (GitHub)
• kiwipiepy — Kiwi 파이썬 패키지 (GitHub)
• KoNLPy 공식 문서
• Femmer et al., Rapid quality assurance with Requirements Smells (arXiv:1611.08847)
• Lubos et al., Leveraging LLMs for the Quality Assurance of Software Requirements (arXiv:2408.10886, RE 2024)
• ISO/IEC/IEEE 29148:2011 미리보기 (ANSI Webstore)
• 이 커리큘럼 안: 모듈 2 레슨 3 「모호함과 누락 찾아내기」, 모듈 3 레슨 1 「동등분할과 경계값 분석」, 모듈 30 레슨 6 「버그라고 부르는 것의 정체」, 모듈 38 레슨 1 「AI가 판정할 수 있는 검증 기준 쓰기」