AI 에이전트가 주도하는 소스 코드 자동 QA 루프 설계하기

QA 자동화를 이야기할 때 자주 놓치는 부분은 테스트 실행보다 기능 목록이다. 코드가 이미 많이 쌓인 앱에서는 “무엇을 테스트할 것인가"가 먼저 막힌다. Greg Brockman이 공유한 Codex Loop 캡처가 흥미로운 이유도 여기에 있다. 버그 찾기만 시키는 프롬프트가 아니다. 기능 인벤토리와 사용자 스토리, 기대 동작, 결함 기록표를 한 루프로 묶는다.

원문 Loop 프롬프트

아래는 캡처에 나온 원문이다. 줄바꿈만 정리했다.

/goal go over every single feature in this app create a user story with expected behaviour based on the code keep a single canonical spreadsheet tracking the features status - when done switch loop to testing every user story and documenting all errors - when done fix every logistical error or ux error - test every user behaviour again post fix

공유본에는 logistical error라고 적혀 있지만 흐름상 로직 오류와 UX 오류를 함께 고치라는 지시로 읽는 편이 자연스럽다. 이 한 줄의 실제 구조는 아래에 가깝다.

1. 앱의 모든 기능을 훑는다.
2. 코드 기준으로 사용자 스토리와 기대 동작을 만든다.
3. 기능 상태를 추적하는 단일 스프레드시트를 유지한다.
4. 각 사용자 스토리를 테스트하고 오류를 기록한다.
5. 로직 오류와 UX 오류를 수정한다.
6. 수정 뒤 같은 사용자 행동을 다시 테스트한다.

한국어로 풀어 쓰면 아래 프롬프트처럼 사용할 수 있다. 원문의 한 줄짜리 지시를 실무에서 바로 쓰기 쉽도록 단계와 완료 조건을 분리한 형태다.

/goal
이 애플리케이션의 모든 기능을 하나도 빠짐없이 분석하라.
각 기능에 대해 다음을 수행하라.
1. 코드와 현재 구현 상태를 기반으로 사용자 스토리(User Story)를 작성한다.
2. 해당 기능의 예상 동작(Expected Behavior)을 정의한다.
3. 모든 기능의 상태를 관리하는 단일 마스터 스프레드시트(또는 추적 문서)를 생성하고 유지한다.
모든 기능 분석이 완료되면 다음 단계로 진행한다.
4. 각 사용자 스토리를 기준으로 가능한 모든 사용 시나리오를 테스트한다.
5. 발견된 오류, 예외 상황, UX 문제, 논리적 결함을 상세히 기록한다.
모든 테스트가 완료되면 다음 단계로 진행한다.
6. 발견된 모든 논리 오류(Logical Error)를 수정한다.
7. 발견된 모든 버그(Bug)를 수정한다.
8. 발견된 모든 UX 문제를 개선한다.
수정이 완료되면 다음 단계로 진행한다.
9. 전체 사용자 시나리오를 처음부터 다시 테스트한다.
10. 신규 오류나 회귀(Regression)가 발생하지 않았는지 검증한다.
11. 문제가 남아 있다면 수정 후 재검증을 반복한다.
최종적으로 모든 핵심 기능이 안정적으로 동작하고, 사용자 경험이 최적화될 때까지 분석 → 테스트 → 수정 → 재테스트 과정을 반복하라.

/goal은 완료 조건을 잡고 루프를 돌리는 명령이다. 여기서는 “모든 기능을 문서화하고 테스트하고 고치고 다시 테스트할 때까지"가 종료 조건이다.

기능 목록부터 만드는 이유

이 프롬프트가 바로 테스트 코드부터 쓰라고 하지 않는 점이 중요하다. 먼저 기능을 세고 사용자 스토리로 바꾼다.

코드베이스가 커지면 테스트 누락은 대부분 의도 부족이 아니라 목록 부재에서 나온다. 로그인 화면은 테스트했는데 비밀번호 재설정의 만료 링크는 빠진다. 결제 성공은 확인했는데 결제 실패 뒤 재시도 흐름은 빠진다. 관리 화면은 열리는데 권한이 낮은 계정에서 버튼이 어떻게 숨는지는 기록이 없다. “모든 기능"을 말로만 외치면 금방 흐려진다. 스프레드시트가 필요한 이유다.

단일 추적 문서는 에이전트가 다음에 무엇을 해야 하는지 기억하게 만든다. Feature ID와 사용자 스토리, 기대 동작을 먼저 둔다. 현재 상태와 발견 결함, 마지막 테스트 시점까지 한곳에 모으면 루프가 끊기지 않는다. 사람이 QA 리스트를 들고 있는 것과 비슷하다.

자동 수정보다 기록 루프가 먼저다

에이전트가 버그를 바로 고치는 장면만 보면 멋있다. 실제로 더 중요한 건 기록이다. 어떤 기능을 왜 실패로 판단했는지 남지 않으면 수정 뒤 검증도 흔들린다.

좋은 루프는 보통 이런 순서로 돈다.

이 표가 없으면 에이전트는 “대충 좋아 보이는 코드"를 만들기 쉽다. 반대로 표가 있으면 사람이 중간에 끊어 들어가 검토하기도 편하다. Codex가 QA/PM/개발자 역할을 한 번에 흉내 내더라도 최종 판단은 추적 문서를 보고 해야 한다.

그대로 돌리면 위험한 지점

이 프롬프트를 그대로 큰 서비스에 던지는 건 위험하다. “every single feature"는 작은 앱에서는 괜찮지만 운영 중인 제품에서는 범위가 터진다. 테스트 환경과 계정 권한부터 준비돼야 한다. 외부 API, 결제 샌드박스, 시드 데이터도 마찬가지다. 준비가 없으면 에이전트는 화면만 훑고 끝내거나 잘못된 가정을 만든다.

수정 범위도 문제다. “모든 오류를 고쳐라"는 말은 강하지만 실제 개발에서는 우선순위가 필요하다. 논리 오류와 UX 오류를 한 번에 고치면 변경 파일이 커지고 회귀 원인을 찾기 어려워진다. 특히 UX 문제는 제품 판단이 섞인다. 버튼 위치와 문구, 플로우 단축 같은 작업은 에이전트가 마음대로 고치게 두면 안 된다.

내가 쓴다면 처음부터 전체 수정을 맡기지 않는다. 먼저 1차 루프는 기능 목록과 테스트 시나리오 생성까지만 시킨다. 사람이 표를 검토한 뒤 우선순위를 붙인다. 그다음 기능 묶음별로 수정 루프를 돌린다.

실무용으로 나누면 더 안전하다

원문 프롬프트는 짧아서 공유하기 좋다. 실무에서는 아래처럼 쪼개는 편이 낫다.

/goal audit the app feature by feature.
Create a canonical QA table with:
Feature ID, route/screen/API, user story, expected behavior, test scenarios, current status, defects, severity, last checked.

Do not modify code in the first pass.
Stop after the inventory and test scenarios are complete.

1차 루프를 문서화 전용으로 제한하면 에이전트가 코드를 건드리기 전에 범위를 볼 수 있다. 그 뒤 수정 루프에서는 조건을 좁힌다. “P0/P1 결함만”, “인증 플로우만”, “모바일 레이아웃은 제외” 정도로 잡는 식이다. 루프가 길어질수록 제약 조건이 품질을 만든다.

Codex Loop의 가치는 “AI가 알아서 전부 고친다"가 아니다. 반복 QA에서 사람이 매번 다시 만들던 체크리스트와 재검증 루틴을 에이전트에게 넘기는 데 있다. 관리 표와 종료 조건, 수정 범위가 같이 있어야 쓸 만해진다.

요약

• 원문 Loop 프롬프트는 모든 기능을 사용자 스토리와 기대 동작으로 바꾸고 단일 QA 표로 추적한다.
• 자동 수정 자체보다 기능 목록과 결함 기록, 수정 후 재테스트가 루프로 묶이는 점이 중요하다.
• 큰 코드베이스에서는 전체 수정부터 맡기지 말고 기능 인벤토리와 테스트 시나리오 생성 루프를 먼저 돌리는 편이 안전하다.