테스트 설계 에이전트 고도화 — test basis에서 조건·케이스까지, 평가셋과 단계별 자율성

개념

설계 에이전트는 무엇이고, 무엇이 아닌가

테스트 설계 에이전트 는 test basis(요구사항명세서·화면설계서·정책 문서)를 읽고 테스트 조건과 테스트 케이스를 만들어 내는 AI 구성 요소다. 단순히 "이 요구사항으로 테스트 케이스 만들어 줘"라고 채팅창에 묻는 것과 무엇이 다른가? 세 가지가 다르다.

이 레슨의 목표는 셋째 칸이다. 에이전트를 "가끔 잘 되는 도구"에서 품질이 측정되고 관리되는 설계 파이프라인 으로 끌어올리는 것. 설계 에이전트는 QA 설계자를 대체하는 것이 아니다. 설계 기법을 반복 적용하는 일은 에이전트가 하고, 무엇을 얼마나 깊게 테스트할지 정하고 결과의 품질을 판정하는 일은 사람이 한다. 이 경계를 흐리면 에이전트가 만든 대량의 케이스가 품질의 착시를 만든다.

연구 결과도 이 경계를 뒷받침한다. 다섯 개 프로젝트의 요구사항명세서로 GPT-4o 계열 모델에 시스템 테스트 케이스를 설계하게 한 2024년 연구에서, 생성된 케이스의 약 87%가 유효했고 나머지 13%는 적용 불가이거나 중복이었다. 유효 케이스 중 약 15%는 개발자가 원래 고려하지 않았던 시나리오였다. 읽는 법은 두 방향이다. 사람이 놓친 것을 꽤 찾아 준다. 동시에 열 개 중 하나 이상은 버려야 한다. 버릴 것을 고르는 능력이 없으면 그 13%가 그대로 회귀 스위트에 쌓인다.

설계 기법을 에이전트 지시로 옮기기

모듈 3에서 배운 설계 기법은 사람이 머릿속에서 수행하던 절차다. 에이전트에게는 그 절차를 단계와 산출물 로 풀어서 지시해야 한다. "경계값 분석을 해라"라고만 쓰면 에이전트는 경계값 분석처럼 보이는 표를 만든다. 실제로 경계를 정확히 찾았는지는 별개다.

표에서 페어와이즈 줄을 눈여겨본다. 조합 생성 같은 결정적 계산은 LLM에게 시키지 않는다. LLM은 파라미터와 값, 제약을 뽑는 일까지만 하고, 조합 자체는 PICT 같은 도구가 만든다(모듈 3 레슨 5). LLM이 직접 페어와이즈 표를 만들면 그럴듯하지만 실제로는 일부 쌍이 빠진 표가 나오기 쉽고, 빠졌는지 눈으로 확인하기도 어렵다.

입력 계약 — 무엇을 넣어야 하는가

설계 에이전트의 품질은 모델보다 입력에서 먼저 갈린다. 입력 계약은 "에이전트는 이것만 보고 설계한다"는 약속이다.

# design-input.yml — 설계 에이전트 1회 실행 단위
scope: REQ-PAY-030 ~ REQ-PAY-048          # 이번 실행 범위 (요구 ID)
test_basis:
  - doc: SRS-PAY v3.2 (레슨 3 현행화 승인본)
  - doc: 화면설계서 PAY-SCR v2.0
review_report: basis-check-2026-10-01.csv  # 레슨 4 점검표: 질의 상태 항목 포함
glossary: glossary.yml                     # 용어 사전
risk:                                      # 모듈 4의 리스크 평가 결과
  REQ-PAY-031: high
  REQ-PAY-044: high
  default: medium
existing_tests: tests/pay/**/*.feature     # 중복 판단용
constraints:
  techniques: [EP, BVA, decision_table, state_transition]
  depth_by_risk: {high: "3값 BVA + 무효 전이 전부", medium: "2값 BVA", low: "대표값"}
  out_of_scope: [성능, 보안]               # 별도 레슨·별도 에이전트

여기서 두 줄이 특히 중요하다. 첫째, review_report 다. 레슨 4에서 "질의" 상태로 남은 항목을 에이전트가 알아야 한다. 모르면 에이전트는 "적절히 안내한다"를 보고 자기 생각대로 기대 결과를 채운다. 알면 해당 요구의 케이스를 "보류(질의 대기)"로 표시할 수 있다. 둘째, depth_by_risk 다. 리스크별로 설계 깊이를 정하지 않으면 에이전트는 모든 요구를 같은 밀도로 설계한다. 위험한 곳은 얕고 안전한 곳은 과하게 두꺼운 스위트가 나온다.

출력 계약 — 조건과 케이스의 스키마

출력은 사람이 읽기 좋은 표보다 기계가 검사할 수 있는 구조 가 먼저다. 스키마가 있어야 평가셋으로 자동 채점할 수 있다.

{
  "condition_id": "COND-PAY-031-03",
  "basis": [{"req": "REQ-PAY-031", "quote": "잔액이 결제 금액보다 적으면 결제를 승인하지 않고"}],
  "technique": "BVA",
  "variable": "잔액 - 결제 금액",
  "partition": "경계: 0원 (같을 때)",
  "status": "질의",
  "question": "잔액이 결제 금액과 같을 때 승인 여부가 문서에 없음",
  "cases": [
    {
      "case_id": "TC-PAY-031-03-a",
      "preconditions": ["회원 잔액 10,000원"],
      "steps": ["10,000원 상품 결제 요청"],
      "oracle": {
        "type": "deterministic",
        "checks": ["응답 status == APPROVED", "잔액 == 0", "결제 내역 1건 추가"]
      },
      "priority": "high",
      "confidence": "low"
    }
  ]
}

필드마다 이유가 있다. basis.quote 는 근거 문장의 원문 인용 이다. 인용이 원문에 실제로 있는지 코드로 확인할 수 있어서, 근거를 지어내는 행동을 걸러 낸다. status 와 question 은 문서가 답하지 않는 칸을 추정으로 채우지 않고 질의로 보내는 통로다. oracle 은 기대 결과를 "정상 처리된다" 같은 문장이 아니라 판정 가능한 검사 목록 으로 쓰게 한다(모듈 38 레슨 1의 결정적 판정). confidence 는 사람이 검토 순서를 정하는 데 쓴다.

한 번에 케이스까지 vs 단계로 쪼개기

"요구사항 → 케이스"를 한 번의 호출로 하면 빠르지만 중간을 검사할 수 없다. 설계 에이전트를 고도화할 때 가장 효과가 큰 변화는 단계 분할 이다.

[1단계] 요구 분석     : 요구 문장 → 변수·조건·행동 목록      (사람 검토 지점 A)
[2단계] 커버리지 항목 : 기법 적용 → 분할·경계·전이·조합 목록  (사람 검토 지점 B)
[3단계] 케이스 구체화 : 항목 → 전제·절차·오라클               (자동 검사)
[4단계] 정리         : 기존 케이스와 중복 제거, 우선순위 부여  (자동 검사 + 표본 검토)

사람의 검토는 1·2단계에 집중한다. 커버리지 항목이 맞으면 케이스 구체화는 크게 틀리지 않는다. 반대로 커버리지 항목이 틀리면 케이스를 아무리 잘 써도 소용없다. 학계에서도 비슷한 방향의 시도가 있다. 유즈케이스 설명을 LLM이 먼저 제어 흐름 그래프로 바꾸고, 그래프의 경로를 열거해 케이스를 만드는 방식(LLMCFG-TGen, 2025)이 그 예다. LLM은 자연어를 구조로 바꾸는 일을 하고, 경로 열거 같은 완전성이 필요한 일은 알고리즘이 한다. 앞에서 본 페어와이즈 원칙과 같다.

평가셋 — 설계 에이전트의 시험지

에이전트 품질을 "써 보니 괜찮더라"로 판단하면 모델이나 프롬프트를 바꿀 때마다 느낌으로 결정하게 된다. 평가셋(evaluation set) 은 에이전트의 시험지다. 구성은 다음과 같다.

정답 작성에 숙련 설계자 두 명을 쓰는 이유는 정답 자체도 흔들리기 때문이다. 두 사람의 커버리지 항목이 얼마나 일치하는지 먼저 보면, 에이전트에게 기대할 수 있는 상한도 알 수 있다. 사람끼리 70%만 일치하는 영역에서 에이전트에게 95% 일치를 요구하는 것은 의미가 없다.

평가셋은 에이전트가 학습이나 프롬프트 예시로 본 적이 없는 문서 여야 한다. 프롬프트에 예시로 넣은 요구사항으로 평가하면 점수가 부풀려진다. 평가셋은 별도 저장소에 두고, 프롬프트 작성자가 쉽게 들여다볼 수 없게 관리하는 팀도 있다.

무엇을 잴 것인가 — 여섯 가지 지표

지표마다 함께 봐야 할 짝이 있다. 커버리지 재현율만 올리려 하면 에이전트는 비슷한 케이스를 잔뜩 만들어 정밀도와 중복률이 나빠진다. 질의 적중률만 올리려 하면 모든 문장을 질의로 보내 설계 자체를 하지 않는다. 그래서 하나의 지표를 목표로 삼지 않고, 재현율과 정밀도, 질의 적중률과 질의 비율 을 쌍으로 기록한다. 함정이 아닌 문장까지 질의로 보내는 비율(과잉 질의율)이 높다면 에이전트가 책임을 회피하고 있는 것이다.

중복은 어떻게 판정하는가

중복률은 계산이 생각보다 까다롭다. 제목이 다른 두 케이스가 같은 것을 시험할 수도 있고, 제목이 비슷한 두 케이스가 다른 경계를 시험할 수도 있다. 문장 유사도만으로 판정하면 둘 다 틀린다. 실무에서는 세 층으로 본다.

커버리지 항목과 입력 분할이 같고 오라클도 같으면 중복이다. 커버리지 항목은 같은데 오라클이 다르면 중복이 아니라 오라클이 약한 쪽을 강한 쪽에 합칠 후보 다. 문장 임베딩 유사도는 이 세 층 판정 전에 후보를 좁히는 용도로만 쓴다. 유사도가 높다고 바로 지우면 경계값 0원과 1원처럼 표현은 거의 같지만 의미가 다른 케이스가 사라진다.

기존 스위트와의 중복도 같은 방식으로 본다. 설계 에이전트가 새로 만든 케이스의 상당수가 이미 있는 케이스와 겹친다면, 입력 계약의 existing_tests 가 제대로 전달되지 않았거나 기존 케이스가 출력 스키마와 다른 형식이라 비교가 안 되는 것이다. 기존 스위트를 같은 스키마로 한 번 정리해 두는 작업이 에이전트 도입의 숨은 선행 과제다.

사람 검토를 효율화하는 법 — 신뢰도와 표본

2단계(검토 후 반영)에서 사람이 모든 케이스를 읽으면 도입 효과가 사라진다. 검토의 밀도를 어디에 집중할지 정하는 규칙이 필요하다.

표본 검토 결과는 버리지 않는다. 표본에서 사람이 반려한 비율이 곧 정밀도의 운영 중 추정값 이 되고, 평가셋 점수와 크게 다르면 평가셋이 실제 문서를 대표하지 못한다는 신호다. 다만 confidence 값 자체는 모델이 스스로 매긴 것이라 그대로 믿을 수 없다. 평가셋에서 신뢰도 높음으로 표시된 항목의 실제 정답률을 따로 재서, 자기 평가가 얼마나 맞는지(보정 상태)를 확인한 뒤에 검토 우선순위에 쓴다.

여섯 번째 지표인 오라클 강도는 별도로 설명한다.

오라클 품질 — 케이스가 실제로 결함을 잡는가

커버리지가 높아도 오라클이 약하면 케이스는 결함을 잡지 못한다. "결제 요청 후 화면이 표시된다"만 확인하는 케이스는 잔액 차감이 틀려도 통과한다. 오라클 품질은 심은 결함(변이) 으로 잰다.

원래 구현:  if balance >= amount: approve()
변이 1:     if balance >  amount: approve()     # 경계 변이 — 같을 때 거절
변이 2:     approve(); deduct(amount - 1)        # 부수 효과 변이 — 1원 덜 차감
변이 3:     if balance >= amount: approve()      # 내역 기록 누락 변이
            # history.add(...) 삭제

에이전트가 만든 케이스를 각 변이에 돌려서 실패하는 케이스가 하나라도 있으면 그 변이는 잡힌 것이다. 변이 1은 경계 케이스가 있어야 잡힌다. 변이 2는 오라클이 잔액을 확인해야 잡힌다. 변이 3은 오라클이 내역 건수를 확인해야 잡힌다. 셋을 다 잡는 스위트는 커버리지와 오라클이 모두 강한 스위트다. 모듈 18c 레슨 3의 "항상 통과하는 가짜 테스트"를 정량적으로 걸러 내는 방법이 이것이다.

자율성 단계 — 제안에서 자동 반영까지

에이전트에게 얼마나 맡길지는 능력과 별개로 설계 결정 이다. 워싱턴대 연구진의 2025년 논문은 에이전트 자율성을 사용자의 역할에 따라 다섯 단계(조작자·협업자·자문자·승인자·관찰자)로 나누고, 자율성 수준을 능력과 분리된 의도적 설계 선택으로 다뤄야 한다고 주장한다. 테스트 설계 에이전트에 맞게 줄이면 세 단계가 실용적이다.

단계는 영역별로 다르게 둔다. 결제·인증처럼 리스크가 높은 영역은 2단계에 오래 머물고, 공지 게시판 같은 낮은 리스크 영역은 3단계로 먼저 올라간다. 단계를 올리는 조건은 미리 숫자로 정해 둔다.

[2단계 → 3단계 승격 조건 예: 회원 영역]
- 최근 4회 평가셋 실행에서 커버리지 재현율 ≥ 90%, 근거 정확도 ≥ 98%
- 질의 적중률 ≥ 80% (함정 문장을 추정으로 채운 비율 ≤ 20%)
- 오라클 강도: 심은 결함 포착률 ≥ 85%
- 최근 2개월 동안 사람이 반려한 PR 비율 ≤ 10%
[강등 조건]
- 운영 결함 중 "에이전트 케이스가 있었으나 오라클이 약해 놓친" 사례 1건 발생 시 즉시 2단계

3단계에서도 자동 반영해서는 안 되는 변경 을 정해 둔다. 기존 케이스 삭제, 기대 결과 변경, 리스크 높음 요구의 케이스 변경이 대표적이다. 특히 기대 결과 변경은 레슨 1에서 본 셀프힐링이 결함을 덮는 위험과 같은 구조다. 테스트가 실패했을 때 에이전트가 기대 결과를 바꿔서 통과시키면, 결함이 테스트 수정으로 둔갑한다.

설계 에이전트의 전형적인 오류 다섯 가지

평가셋을 돌리다 보면 에이전트의 틀림이 몇 가지 유형으로 반복된다는 것을 알게 된다. 유형을 알면 지시문과 검사 규칙을 정확히 고칠 수 있다.

다섯 유형 중 기대 결과 창작 이 가장 위험하다. 나머지는 누락이라 평가셋의 재현율로 드러나지만, 창작은 그럴듯한 케이스로 섞여 들어와 정밀도 검사에서도 놓치기 쉽다. 근거 인용을 의무로 하는 출력 계약이 이 유형을 막는 거의 유일한 기계적 수단이다.

모델·프롬프트가 바뀌면 평가셋부터 돌린다

설계 에이전트는 모델 업데이트, 프롬프트 수정, 입력 계약 변경으로 성능이 바뀐다. 더 좋은 모델로 바꿨는데 질의 적중률이 떨어지는 일도 생긴다. 더 "적극적인" 모델은 모호한 문장을 더 그럴듯하게 채우기 때문이다. 그래서 설계 에이전트 자체를 하나의 테스트 대상으로 다룬다.

같은 평가셋을 여러 번 돌려 실행 간 편차 도 기록한다. 같은 입력에서 커버리지 재현율이 80%와 92% 사이를 오간다면, 한 번의 92%는 승격 근거가 될 수 없다.

실무에서 왜 필요한가

설계 에이전트를 도입한 팀이 처음 겪는 문제는 케이스 양 이 아니라 신뢰 다. 하루에 수백 개의 케이스가 나오는데 이것이 좋은지 판단할 방법이 없으면, 결국 사람이 전부 읽거나(도입 효과 없음) 아무도 안 읽는다(품질 착시). 평가셋과 지표는 이 둘 사이에서 "이 영역은 어디까지 맡겨도 된다"를 숫자로 말하게 해 준다.

자율성 단계는 조직 간 갈등도 줄인다. "AI가 만든 케이스를 왜 검토 없이 반영하느냐"와 "왜 아직도 사람이 다 보느냐"는 논쟁은 승격·강등 조건을 미리 합의하면 사라진다. 감사나 인증 대응에서도 "이 영역은 평가셋 기준 어떤 지표를 넘어서 자동 반영 단계로 운영 중이며, 변경마다 재평가 기록이 있다"는 설명이 가능해진다.

채용시장에서의 위치

AI 기반 QA 직무 공고에서 "테스트 설계 자동화", "LLM 기반 테스트 생성 파이프라인 구축", "AI 산출물 품질 평가 체계 설계"가 자주 보인다. 면접에서 차별점이 되는 것은 생성 도구 이름이 아니라 평가 체계 다. "평가셋을 어떻게 만들었고, 어떤 지표가 어떤 값을 넘으면 자동 반영으로 올렸으며, 강등된 적이 있다면 무엇 때문이었는가"를 말할 수 있는 사람은 많지 않다. 모듈 3의 설계 기법을 확실히 아는 사람이 이 평가 체계를 가장 잘 만든다. 기법을 모르면 정답 커버리지 항목을 쓸 수 없기 때문이다.

실습 과제

과제 1 — 기법을 지시로 풀기 (20분)

결정 테이블과 상태 전이 두 기법에 대해, 에이전트에게 줄 단계별 지시문을 쓴다. 각 지시문에는 중간 산출물 형식, 문서에 없는 조합·전이의 처리 방법(질의로 보내기), 사람이 확인할 항목을 포함한다. "~를 적용하라"로 끝나는 지시문은 실패로 본다.

과제 2 — 입력·출력 계약 쓰기 (25분)

본인이 아는 서비스의 한 기능(예: 쿠폰 적용, 비밀번호 재설정)을 골라 입력 계약 YAML과 출력 스키마 JSON 예시를 쓴다. 출력에는 근거 인용, 질의 상태, 결정적 오라클 검사 목록, 신뢰도가 반드시 들어가야 한다. 그리고 출력 스키마를 검사하는 규칙 다섯 개(예: basis가 비어 있으면 거부)를 적는다.

과제 3 — 미니 평가셋과 채점 (30분)

요구사항 문장 8개로 미니 평가셋을 만든다. 2개는 레슨 4의 함정 문장(약한 표현·열린 나열)으로 넣는다. 정답 커버리지 항목을 직접 쓰고, LLM에게 같은 문장으로 커버리지 항목을 만들게 한 뒤 커버리지 재현율·정밀도·질의 적중률·근거 정확도를 계산한다. 같은 지시로 세 번 실행해 지표의 편차를 기록한다.

과제 4 (선택) — 변이로 오라클 강도 재기 (25분)

간단한 함수(예: 할인 금액 계산, 잔액 차감)를 파이썬이나 자바스크립트로 쓰고, 변이 세 개(경계 연산자 변경, 부수 효과 누락, 반올림 변경)를 만든다. LLM이 만든 테스트를 각 변이에 돌려 몇 개가 잡히는지 세고, 놓친 변이에 대해 오라클을 어떻게 고쳐야 하는지 적는다.

자가 체크리스트

• 채팅으로 케이스를 받는 것과 설계 에이전트를 운영하는 것의 차이를 입력·출력·품질 관리로 설명할 수 있다
• 설계 기법을 단계와 중간 산출물로 풀어 지시할 수 있고, 결정적 계산은 도구에 맡긴다
• 입력 계약에 점검표(질의 항목)와 리스크별 설계 깊이를 넣어야 하는 이유를 말할 수 있다
• 출력 스키마에 근거 인용·질의 상태·결정적 오라클을 넣고, 이를 코드로 검사할 수 있다
• 평가셋의 구성 요소와, 정답을 두 사람이 독립 작성해야 하는 이유를 설명할 수 있다
• 커버리지 재현율·정밀도·중복률·근거 정확도·질의 적중률·오라클 강도를 정의할 수 있다
• 영역별 자율성 단계와 숫자로 된 승격·강등 조건을 설계할 수 있다
• 자동 반영 단계에서도 막아야 할 변경(삭제·기대 결과 변경)을 말할 수 있다

흔한 실수

케이스 개수로 성과를 말한다. 케이스가 많다는 것은 중복과 유지 비용이 많다는 뜻일 수 있다. 커버리지 재현율과 오라클 강도로 말한다.

프롬프트 예시로 쓴 문서로 평가한다. 점수가 부풀려지고, 새 문서에서는 성능이 떨어진다. 평가셋은 분리해서 관리한다.

한 번의 좋은 결과로 단계를 올린다. LLM 출력은 실행마다 흔들린다. 여러 번 실행한 지표의 하한으로 판단한다.

모든 영역을 같은 자율성으로 운영한다. 리스크가 다른 영역을 한 단계로 묶으면 위험한 곳이 덜 검토되거나 안전한 곳이 과하게 검토된다.

기대 결과 변경을 자동 반영에 포함한다. 실패한 테스트의 기대 결과를 바꿔 통과시키는 것은 결함을 테스트 수정으로 숨기는 일이다.

설계 기법을 모르는 채로 에이전트를 운영한다. 정답 커버리지 항목을 쓸 수 없으면 평가셋도 만들 수 없다. 에이전트 시대일수록 기법 지식이 평가 능력의 바탕이 된다.

참고 자료

• System Test Case Design from Requirements Specifications: Insights and Challenges of Using ChatGPT (arXiv:2412.03693)
• LLMCFG-TGen: Using LLM-Generated Control Flow Graphs to Automatically Create Test Cases from Use Cases (arXiv:2512.06401)
• Feng, McDonald, Zhang — Levels of Autonomy for AI Agents (arXiv:2506.12469)
• Lubos et al., Leveraging LLMs for the Quality Assurance of Software Requirements (arXiv:2408.10886)
• 이 커리큘럼 안: 모듈 3 레슨 1~5 「명세 기반 기법」·레슨 9 「TC 설계 종합」, 모듈 4 「테스트 계획과 리스크 기반 테스트」, 모듈 18c 레슨 3 「항상 통과하는 가짜 테스트」, 모듈 38 레슨 1 「AI가 판정할 수 있는 검증 기준 쓰기」