들어가며
테스트는 모두 통과되었습니다.
그런데 나중에서야 알았습니다. 테스트한 건 ‘현재’가 아니라 기획서 속의 ‘과거’였다는 사실을요.
QA의 테스트 설계는 보통 추측에서 시작합니다. 기획서와 경험을 바탕으로 "지금은 이렇게 동작하겠지"라며 테스트 케이스(TC)를 작성합니다. 하지만 기획서에 적힌 현재 동작이 틀렸다면, 그 기획서로 만든 TC 역시 잘못된 기준을 검증하게 됩니다. 테스트가 통과해도 무엇이 틀렸는지 알아차리기는 쉽지 않습니다.
원래는 과제를 하나씩 순서대로 진행했습니다. 그러다 혼자서 8개 팀의 과제를 한꺼번에 맡게 되면서 감당하기 어려워졌습니다. "이거 지금도 진짜 이렇게 동작하나?" 싶어도 확인할 시간이 없었습니다. QA라면 다들 비슷한 경험을 해보셨을 거예요.
AI를 도입해 봤습니다. 하지만 AI 역시 똑같은 문서를 보고 똑같이 추측할 뿐이었습니다. 오래된 문서를 근거로, 사람보다 더 빠르고 더 그럴듯하게 틀렸습니다. 결국 AI의 판단이 맞는지 검증할 방법이 필요했습니다.
이 글은 3월부터 10월까지 추측을 확신으로 바꾸기 위해 시도한 과정입니다. 잘된 부분과 생각보다 효과가 없었던 시행착오도 함께 적었습니다.
1. 문제의 정의
기존 방식에서 테스트 설계의 출발점은 기획서와 API 명세였습니다. 기획서가 확정되고 리뷰가 끝나야 테스트를 설계할 수 있었고, 문서에 적힌 현재 동작을 의심할 근거도 부족했습니다.
하지만 코드에서 직접 현재 동작을 확인할 수 있다면, 기획서가 바꾸려는 내용과 실제 코드를 비교해, 기획 리뷰 전에 확인할 항목을 추려 낼 수 있습니다.
구분
문서 기반 분석
코드 기반 분석
현재 동작을 확인하는 기준
기획서의 설명과 과거 경험
운영 기준 코드의 특정 커밋과 라인
주요 참조 문서
기획서, API 명세
기획서, API 명세 + 코드
불일치 발견
경험 문서 명세
코드 기획서 명세
근거가 불분명한 경우
경험 기반 추정
미확인으로 남기고 추가 확인 대상으로 분리
기대하는 프로세스 변화
문서 분석 이후 설계 시작
분석과 질문 정리를 기획 리뷰보다 앞당김
병목은 주로 테스트 설계 기간에서 생겼는데, 2025년 상반기에는 과제의 절반 이상(52%)이 테스트 설계에만 4일 넘게 걸렸습니다. 문서만 보고 분석해서는 설계 기간을 줄이기 어려웠습니다.
그래서 두 가지 가설을 세웠습니다. 아래는 그 가설을 검증하며 방법을 발전시켜 온 과정입니다.
가설 1. 현재 동작의 기준을 코드로 고정하고 판정마다 근거를 남기면, 추측이 확신으로 바뀌고 판단이 빨라질 것이다.
가설 2. 분석 결과와 확인할 질문을 기획 리뷰 전에 정리하면 테스트 설계 기간을 줄일 수 있을 것이다.
2. 시행착오 과정
위 가설을 검증하기 위해 한 번에 완성하지 않고, 각 단계에서 드러난 한계를 다음 단계에서 순차적으로 고쳐 나갔습니다.
2.1 1단계 단순 문서 기반 분석(AI 도입 초기)
초기에는 기획서와 API 명세서만 AI에 붙여 넣어 리포트와 TC를 빠르게 얻어내는 방식을 썼습니다. 하지만 실제 코드를 대조하는 기준선이 없다 보니, 질문 방식에 따라 결과물의 형식과 내용이 매번 달라졌습니다.
처음에는 기획서와 API 명세를 AI에 입력하고, 불일치 항목과 테스트 시나리오를 추출했습니다. 사람이 문서를 읽고 TC를 작성하던 작업 일부를 AI가 대신하도록 한 것입니다.
초기 결과는 나쁘지 않았습니다. 시나리오를 빠르게 정리하고 문서 사이의 차이를 찾을 수 있었습니다. 하지만 이 방식에는 명확한 한계가 있었습니다.
기획서의 현재 동작이 틀렸는지 확인할 기준이 없었습니다.
작업 조건이 세션마다 달라 매번 프롬프트로 분석 순서와 결과 형식을 설명해야 했습니다. 같은 과제의 리포트를 여러 번 다시 요청하는 일도 잦았습니다.
산출물 형식이 통일되지 않아 사람이 다시 대조하고 손보는 시간이 매번 들었습니다.
테