개념
Test basis — 테스트가 기대는 지식의 몸통
ISTQB 용어집은 test basis를 테스트 분석과 설계의 근거로 쓰이는 지식의 총체 로 정의한다. 덧붙인 설명이 중요하다. test basis는 요구사항명세서·설계명세서 같은 문서일 수도 있지만, 문서화되지 않은 요구 동작에 대한 이해 일 수도 있다.
이 정의를 현장에 대 보면 불편한 사실이 드러난다. 많은 조직에서 실제 test basis는 문서가 아니라 사람의 머릿속이다. 명세서에는 "비밀번호 8자 이상"이라고 되어 있지만 3년 전 보안 점검 이후 "10자 이상, 특수문자 포함"으로 바뀌었고, 그 사실은 개발자와 오래된 QA 담당자만 안다. 신입 QA나 AI 테스트 에이전트가 명세서를 test basis로 삼으면 틀린 기준으로 정확하게 테스트한다.
| 낡은 test basis가 만드는 오판 | 예 |
|---|---|
| 정상을 결함으로 | 명세서 "8자 이상" 기준으로 9자 비밀번호 거부를 결함 보고 |
| 결함을 정상으로 | 명세서에 없는 새 할인 정책의 계산 오류를 아무도 검증하지 않음 |
| 커버리지 착시 | 명세서 요구사항 100% 커버, 그러나 실제 기능의 30%는 명세서에 없음 |
AI 에이전트가 테스트를 설계하는 조직(레슨 1)에서는 문제가 더 커진다. 사람 QA는 이상하면 개발자에게 물어보지만, 에이전트는 문서를 믿고 수백 개 케이스를 펼친다. AI의 판정은 기준보다 정확할 수 없고, 기준은 test basis보다 정확할 수 없다.
왜 문서만 낡는가
개발 산출물은 현행화 압력을 받는다. 코드는 틀리면 돌아가지 않고, DB 스키마는 맞지 않으면 오류가 난다. 반면 명세서와 화면설계서는 틀려도 아무것도 멈추지 않는다. 그래서 변경은 이렇게 흘러간다.
요청(티켓) → 개발(코드 변경) → 배포 ← 여기까지는 반드시 일어난다
↘ 명세서 갱신 ✗ ← 일정에 밀려 생략
↘ 화면설계서 갱신 ✗ ← 디자인 도구 원본만 갱신, 문서는 그대로
↘ 테스트 케이스 갱신 △ ← 실패한 케이스만 고침결과적으로 변경의 진짜 기록은 티켓·커밋·PR·배포 노트 에 흩어지고, 문서는 오픈 시점의 사진으로 남는다. 개발에 비해 test basis의 현행화가 뒤처지는 구조적 이유다. 현행화는 흩어진 변경 기록을 다시 문서로 모으는 일이고, 이 수집과 대조가 AI가 잘하는 일이다.
드리프트 유형 — 어긋남에도 종류가 있다
문서와 구현의 어긋남을 드리프트(drift) 라고 부르자. 종류에 따라 찾는 방법과 처리가 다르다.
| 유형 | 정의 | 예 | 주로 찾는 근거 |
|---|---|---|---|
| 누락 | 구현에는 있고 문서에 없음 | 간편 로그인 추가, 문서는 아이디 로그인만 | 화면 캡처, 라우트 목록, 티켓 |
| 잔존 | 문서에는 있고 구현에서 사라짐 | 팩스 번호 입력 필드 삭제 | 화면 캡처, 코드 검색 |
| 값 불일치 | 같은 항목의 수치·조건이 다름 | 비밀번호 8자 vs 10자 | 검증 코드, API 명세 |
| 흐름 불일치 | 단계 순서·분기가 다름 | 본인인증이 가입 마지막에서 처음으로 이동 | E2E 녹화, 화면 전이 로그 |
| 문구 불일치 | 메시지·라벨이 다름 | "주문 완료" vs "주문 접수" | 화면 캡처, 다국어 리소스 파일 |
| 용어 불일치 | 같은 대상을 다른 이름으로 | 문서 "회원", 화면 "고객", DB "user" | 용어 사전, 스키마 |
| 정책 불일치 | 업무 규칙이 다름 | 반품 기한 7일 vs 14일 | 약관, 정책 문서, 설정 값 |
용어 불일치를 먼저 정리하지 않으면 차이표가 거짓 드리프트로 가득 찬다(레슨 4).
근거의 위계 — 무엇을 믿고 비교하는가
드리프트를 찾으려면 문서와 비교할 현재 상태의 근거 가 필요하다. 근거마다 신뢰도가 다르다.
| 순위 | 근거 | 장점 | 한계 |
|---|---|---|---|
| 1 | 운영 환경 화면 캡처·E2E 녹화 | 사용자가 실제로 보는 것 | 권한·데이터에 따라 다르게 보임 |
| 2 | 코드·설정·API 명세(OpenAPI) | 정확한 값과 조건 | 업무 의미는 없음 |
| 3 | 승인된 티켓·PR 설명 | 변경의 이유가 있음 | 반려·롤백 여부 확인 필요 |
| 4 | 배포 노트·운영 공지 | 사용자에게 공개된 변경 | 세부 조건 생략 |
| 5 | 회의록·메신저 | 맥락이 풍부 | 결정이 번복됐을 수 있음 |
규칙은 이렇다. "구현이 지금 어떤가"는 1·2순위로, "왜 바뀌었나"는 3·4순위로 확인한다. 5순위만으로 드리프트를 확정하지 않는다. 티켓은 특히 주의한다. "비밀번호 정책 강화" 티켓이 있어도 반려되었거나 배포 후 롤백됐을 수 있다. 티켓 상태와 해당 커밋의 배포 여부를 함께 확인해야 근거가 된다.
AI로 차이표 만들기 — 입력과 출력의 계약
AI에게 "명세서와 실제 화면 비교해 줘"라고 하면 그럴듯한 목록이 나오지만 검증할 수 없다. 입력과 출력을 계약으로 정한다.
[입력]
1. 대상 문서 단위: 요구사항 ID 목록 (예: REQ-MEM-001 ~ 045), 화면 ID (SCR-MEM-01 ~ 08)
2. 현재 상태 근거: 화면 캡처(운영, 기준일 명시), 검증 코드 경로, OpenAPI 파일
3. 변경 이력: 문서 최종 갱신일 이후의 티켓·PR 목록(상태 포함)
4. 용어 사전: 문서 용어 ↔ 화면 용어 ↔ 코드 식별자 대응표
[출력 — 차이 한 건마다]
- 차이 ID, 요구사항/화면 ID, 드리프트 유형
- 문서 내용 (원문 인용)
- 현재 구현 (근거 위치와 함께 인용)
- 변경 근거 후보 (티켓/PR 번호, 없으면 "없음")
- 판정 제안: 문서 갱신 / 결함 후보 / 확인 필요
- 신뢰도와 그 이유
[금지]
- 근거 인용 없이 차이를 주장하지 않는다
- 변경 근거 티켓이 없는 차이를 "문서 갱신"으로 제안하지 않는다마지막 금지 조항이 핵심이다. 티켓 없이 구현만 바뀐 경우는 누군가 승인 없이 바꿨거나 결함일 수 있다. AI가 이를 "문서를 현재에 맞춰 고치자"로 제안하면 결함이 문서로 세탁된다(레슨 2와 같은 구조).
출력된 차이표는 이런 모양이다.
| 차이 ID | 대상 | 유형 | 문서 | 구현(근거) | 변경 근거 | 제안 |
|---|---|---|---|---|---|---|
| D-012 | REQ-MEM-007 | 값 불일치 | 비밀번호 8자 이상 | 10자 이상·특수문자 (PasswordPolicy.kt:14) | SEC-2231 완료·배포 | 문서 갱신 |
| D-013 | SCR-MEM-03 | 누락 | (없음) | 간편 로그인 버튼 3종 (운영 캡처 09-30) | MEM-880 완료 | 문서 갱신 |
| D-014 | REQ-MEM-019 | 정책 불일치 | 탈퇴 후 30일 재가입 제한 | 제한 없음 (MemberService.kt:203 분기 없음) | 없음 | 결함 후보 |
| D-015 | SCR-MEM-05 | 문구 불일치 | "가입을 축하합니다" | "환영합니다" (ko.json:88) | 없음 | 확인 필요 |
D-014가 이 작업의 진짜 수확이다. 재가입 제한은 부정 가입 방지 정책일 가능성이 높은데, 구현에서 빠져 있고 변경 근거가 없다. 현행화 작업이 결함 발견 작업 이 되는 순간이다.
문서를 고칠 것인가, 구현을 고칠 것인가
차이 한 건에는 두 가지 해결 방향이 있다. 이것을 정하는 것은 AI가 아니라 사람이다. 판정 기준을 미리 합의해 둔다.
변경 근거 티켓이 있고, 배포되었고, 기획 승인이 있다 → 문서 갱신
변경 근거가 없고, 정책·약관·법규와 어긋난다 → 결함 등록 (구현 수정)
변경 근거가 없고, 정책 근거도 없다 → 기획에 확인 요청 (보류)
문구·용어만 다르고 의미가 같다 → 용어 사전 갱신 후 일괄 문서 갱신갱신 승인 절차 — 상태를 가진 차이
차이표는 한 번 만들고 끝나는 보고서가 아니라 상태를 가진 작업 목록 이다. 이슈 트래커에 차이 하나를 하나의 항목으로 올리고 상태를 옮긴다.
발견(AI 제안) → 검토 중(QA) → 판정 대기(기획) → 문서 갱신 완료 / 결함 등록 / 보류
↓
근거 부족 → 반려 (AI 오탐으로 기록)QA는 근거와 드리프트의 진위를 검토하고, 기획은 문서 갱신인지 결함인지 판정하며, 문서 담당은 갱신 후 문서 버전을 차이 항목에 남긴다. 반려된 차이는 지우지 않고 AI 오탐 으로 기록한다. 오탐 유형이 쌓이면 입력 계약이나 용어 사전을 고칠 근거가 된다(예: 권한별 화면 차이를 드리프트로 잘못 잡는 경우).
추적성 매트릭스 — 갱신해도 끊기지 않게
모듈 2 레슨 5에서 배운 추적성 매트릭스는 요구사항 ↔ 테스트 조건 ↔ 테스트 케이스 ↔ 결함을 잇는다. 현행화의 가장 큰 부작용은 이 연결이 끊어지는 것이다. 문서를 새로 쓰면서 요구사항 ID를 다시 매기면 기존 테스트와 결함이 모두 고아가 된다.
| 원칙 | 방법 |
|---|---|
| ID는 바꾸지 않는다 | 내용이 바뀌어도 REQ-MEM-007은 REQ-MEM-007. 버전만 올린다 |
| 삭제는 표시로 | 잔존 드리프트로 삭제된 요구사항은 "폐기" 상태로 두고 연결된 테스트를 폐기 검토로 넘긴다 |
| 신규는 새 ID | 누락 드리프트로 추가된 요구사항은 새 ID, 출처 차이 ID를 기록 |
| 영향 전파 | 값이 바뀐 요구사항에 연결된 테스트 케이스는 자동으로 "재검토 필요" 표시 |
REQ-MEM-007 v1 → v2 (D-012, SEC-2231)
├─ TC-MEM-021 비밀번호 8자 허용 → 재검토 필요 → 기대값 수정 (10자)
├─ TC-MEM-022 비밀번호 7자 거부 → 재검토 필요 → 경계 수정 (9자 거부)
└─ BUG-5520 (종결) 8자 비밀번호 거부 → "명세 낡음으로 인한 오보고" 태그마지막 줄을 보라. 과거에 "결함"으로 보고됐다가 종결된 항목 중 일부는 사실 낡은 test basis가 만든 오보고였다. 현행화하면서 이런 항목을 태그해 두면 "명세 낡음으로 낭비된 비용"을 숫자로 보여 줄 수 있고, 현행화에 예산을 받는 근거가 된다. 연구 쪽에서도 요구사항 변경이 제대로 전파되지 않아 생기는 잘못되거나 빠진 추적 링크를 LLM과 검색 증강 생성(RAG)으로 검증·복구하는 접근이 산업 데이터로 평가되고 있다. 다만 연구의 높은 정확도 수치는 특정 도메인·데이터에서 나온 것이므로, 우리 조직에서는 샘플을 사람이 검수해 오탐률을 직접 재야 한다.
한 번이 아니라 계속 — PR 단위 드리프트 검사
현행화를 분기에 한 번 하는 큰 작업으로 두면 다시 낡는다. 목표는 드리프트가 생기는 순간 잡는 것이다.
- PR 단위 검사: 화면·검증 로직·API 명세가 바뀌는 PR에 연결된 요구사항 ID가 있는지, 그 요구사항 문서가 같이 바뀌었는지 확인한다. 문서 변경이 없으면 "test basis 갱신 필요" 라벨을 단다.
- 스펙 주도 개발과의 연결: GitHub Spec Kit처럼 명세를 먼저 쓰고 에이전트가 명세에서 계획·작업·코드를 만드는 방식은 명세를 "살아 있는 산출물"로 다루려 한다. 이런 조직에서는 명세가 코드보다 먼저 바뀌므로 드리프트 방향이 반대(명세는 바뀌었는데 구현이 안 따라옴) 가 되고, QA는 그 반대 방향 드리프트를 검사한다.
- 정기 전수 대조: PR을 거치지 않는 변경(설정 값, 외부 시스템)이 있으므로 월 단위로 화면 캡처 기반 대조를 돌린다.
실무에서 왜 필요한가
AI 테스트 설계 에이전트를 도입한 조직이 가장 먼저 겪는 실망은 "AI가 만든 케이스가 엉뚱하다"는 것이다. 원인을 파면 대개 에이전트가 아니라 입력이다. 3년 묵은 명세서를 넣었으니 3년 전 시스템의 테스트가 나온다. test basis 현행화는 AI 도입의 전제 작업 이다.
또한 현행화 작업은 그 자체로 결함을 찾는다. 근거 없이 바뀐 구현, 빠진 정책, 문서에만 남은 기능은 대부분 누군가 놓친 것이다. QA가 차이표를 들고 기획·개발과 마주 앉는 회의는, 테스트 실행보다 앞 단계에서 결함을 막는 가장 싼 품질 활동 중 하나다.