Q: 실패 로그만 붙여도 Codex가 고칠 수 있나요?

A: 가능할 때도 있지만 재현 조건이 없으면 엉뚱한 파일이나 넓은 리팩터링으로 번질 수 있습니다. 먼저 입력, 기대 결과, 실제 결과, 실행 명령을 정리하는 편이 안전합니다.

Q: 테스트를 실제로 돌리지 못한 상황이면 어떻게 하나요?

A: 돌리지 못한 명령과 이유를 그대로 쓰고 수동 확인 방법을 따로 요청해야 합니다. 실행하지 않은 검증을 통과했다고 적게 하면 안 됩니다.

Q: CI에서만 실패하면 무엇을 더 붙이나요?

A: 로컬 명령, CI 작업 이름, 실패한 OS나 Node 버전, 환경 변수 유무, 최근 변경 파일을 함께 붙이면 재현 범위를 좁히기 쉽습니다.

테스트 실패 원인을 믿기 전 확인할 재현 근거

테스트가 빨갛게 깨지면 마음이 급해집니다. 터미널의 실패 로그를 복사해서 Codex에게 "고쳐줘"라고 쓰고 싶어집니다. 그런데 실패 조건이 비어 있으면 AI는 원인보다 패치를 먼저 만들 수 있습니다. 그 결과 테스트 하나를 고치려다 관련 없는 파일이 바뀌고, 리뷰할 diff가 커지고, 같은 실패가 다시 돌아옵니다.

이럴 때 첫 질문은 수정 요청이 아닙니다. 실패를 재현 가능한 사건으로 바꾸는 요청이어야 합니다. Codex가 코드를 읽고 바꾸고 명령을 실행할 수 있더라도, 무엇을 재현해야 하는지와 어디까지 고치면 안 되는지는 사용자가 먼저 좁혀 주는 편이 안전합니다.

테스트 실패 로그를 재현 조건, 수정 범위, 검증 명령으로 나누는 AI 코딩 작업 화면

developers.openai.com의 Codex CLI 문서는 Codex가 선택한 디렉터리에서 코드를 읽고 바꾸고 실행할 수 있다고 설명합니다. 같은 도메인의 AGENTS.md 문서도 저장소 구조, 실행 명령, 검증 방식, 완료 기준을 프로젝트 지침에 적어 Codex가 따르게 할 수 있다고 안내합니다. help.openai.com의 prompt engineering 문서는 지시, 맥락, 출력 형식, 제약을 구체적으로 주는 방식이 더 유용한 답을 만든다고 설명합니다. 테스트 실패 질문도 같은 원리입니다. 로그만 던지는 대신 재현 조건과 검증 기준을 먼저 고정해야 합니다.

이미 PR 리뷰 코멘트를 처리하는 중이라면 리뷰 코멘트, 바로 고칠지 더 물을지 가르는 Codex 프롬프트와 함께 쓰면 좋습니다. 실패 로그 안에 토큰이나 고객 정보가 섞였을 가능성이 있다면 에러 로그에 키가 섞였을 때, AI에게 보내기 전 가릴 범위를 먼저 확인해야 합니다.

실패 로그만 붙이면 Codex가 무엇을 모르는지 먼저 봅니다

테스트 실패 로그는 보통 결과만 보여 줍니다. expected 200, received 500이나 Cannot read properties of undefined 같은 문장은 증상입니다. Codex에게 필요한 것은 증상뿐 아니라 그 증상이 생긴 조건입니다.

빠진 정보	Codex가 헷갈리는 지점	먼저 적을 내용
입력 조건	어떤 데이터에서 실패했는지 모릅니다	샘플 입력, 사용자 역할, API 요청 값
기대 결과	무엇이 맞는 동작인지 모릅니다	원래 통과해야 하는 값이나 화면 상태
실행 명령	실제로 어떤 테스트가 깨졌는지 모릅니다	`npm test -- user-flow` 같은 명령
최근 변경	어디부터 봐야 할지 모릅니다	바뀐 파일, PR 범위, 새 의존성
금지 범위	넓은 리팩터링을 해도 되는지 모릅니다	건드리지 말 파일과 동작

이 표를 채우지 않은 채로 "테스트 고쳐줘"라고 쓰면 AI는 실패 원인을 추정해야 합니다. 추정이 많아질수록 수정 범위도 넓어집니다. 그래서 첫 단계의 목표는 정답 코드가 아닙니다. Codex가 재현할 수 있는 최소 조건을 만드는 것입니다.

바로 고치게 하지 말고 재현표부터 만들게 합니다

아래 프롬프트는 실패 로그를 붙이기 전에 먼저 사용할 수 있습니다. 핵심은 "패치하지 말고 재현 조건부터 정리하라"는 제약입니다.

아래 테스트 실패를 바로 고치지 말고, 먼저 재현 조건을 정리해 주세요.

상황:
- 작업 목적: {예: 회원가입 완료 후 대시보드로 이동해야 함}
- 최근 변경 파일: {예: app/signup/page.tsx, src/modules/auth/signup.ts}
- 실패한 명령: {예: npm test -- signup-flow}
- 로컬/CI 여부: {예: 로컬에서는 통과, GitHub Actions Ubuntu에서 실패}

실패 로그:
{여기에 민감정보를 가린 로그를 붙입니다}

원하는 출력:
| 항목 | 지금 보이는 사실 | 아직 모르는 정보 | 다음 질문 |

규칙:
1. 아직 코드를 수정하지 마세요.
2. 로그에서 확인한 사실과 추정을 분리하세요.
3. 재현에 꼭 필요한 입력, 환경, 명령을 먼저 뽑아 주세요.
4. 추가 확인 없이 고치면 위험한 범위를 따로 적어 주세요.

이 프롬프트의 목적은 속도를 늦추는 것이 아닙니다. 수정 전에 실패를 작게 만드는 것입니다. 테스트 이름, 입력 값, 기대 결과가 모이면 다음 패치 요청이 훨씬 짧아집니다.

Codex에게 붙이기 전 확인할 실패 조건, 기대 결과, 금지 범위 체크리스트

재현 조건이 모이면 수정 범위를 작게 묶습니다

재현표가 나오면 그때 수정 요청을 보냅니다. 이때도 "알아서 고쳐줘"보다 파일, 함수, 금지 범위, 검증 명령을 붙이는 편이 좋습니다. Codex가 넓게 고치면 빨라 보일 수 있지만, 테스트 실패 하나가 스타일 변경이나 구조 변경으로 번지면 리뷰 비용이 커집니다.

위 재현 조건을 기준으로 최소 수정안을 제안해 주세요.

수정 대상:
- 우선 볼 파일: {예: src/modules/auth/signup.ts}
- 가능하면 유지할 파일: {예: app/signup/page.tsx}
- 바꾸지 말 것: 라우팅 구조, UI 문구, 인증 정책

수정 목표:
- {예: 가입 성공 응답이 201일 때 대시보드 이동 테스트가 통과해야 함}

검증:
- 실행할 명령: {예: npm test -- signup-flow}
- 추가 확인: {예: npm run typecheck}

출력 형식:
1. 실패 원인 가설
2. 바꿀 파일과 이유
3. 최소 수정안
4. 실행한 검증 명령과 결과
5. 아직 남은 위험

여기서 가장 중요한 줄은 검증입니다. Codex가 명령을 실행할 수 있는 환경이라면 실제 명령과 결과를 요구해야 합니다. 실행하지 못했다면 "실행하지 못함"과 이유를 적게 해야 합니다. 실행하지 않은 테스트를 통과한 것처럼 쓰게 두면 안 됩니다.

CI에서만 깨지면 환경 차이를 질문에 넣습니다

로컬에서는 통과하고 CI에서만 실패하는 경우가 더 까다롭습니다. 이때 로그만 붙이면 Codex는 코드 문제와 환경 문제를 구분하기 어렵습니다. CI 작업 이름, OS, Node 버전, 캐시 여부, 환경 변수 유무를 함께 적어야 합니다.

CI 전용 실패 단서	붙이면 좋은 정보
OS 차이	Ubuntu, Windows, macOS 중 어디서 깨졌는지
런타임 차이	Node, Python, 브라우저, 패키지 매니저 버전
시간 의존	timezone, 날짜 고정 여부, fake timer 사용 여부
비밀값 의존	실제 값이 아니라 존재 여부와 이름만
캐시 의존	lockfile 변경, install cache, build cache 사용 여부

CI 로그에는 민감정보가 섞일 수 있습니다. 토큰, 쿠키, 실제 고객 식별자, 내부 URL은 그대로 붙이지 말고 가려야 합니다. 다만 모두 지우면 재현이 어려워집니다. 예를 들어 API_KEY=[REDACTED], DATABASE_URL=[REDACTED_POSTGRES_URL]처럼 값은 숨기고 종류는 남기는 방식이 좋습니다.

고쳤다는 답을 받으면 검증 결과부터 다시 묻습니다

Codex가 수정안을 냈다면 마지막으로 확인해야 할 것은 설명의 자연스러움이 아닙니다. 실제로 어떤 명령을 실행했고 어떤 결과가 나왔는지입니다. 아래 질문을 한 번 더 붙이면 됩니다.

방금 수정 결과를 검증 관점으로만 다시 정리해 주세요.

확인할 내용:
1. 실행한 명령
2. 명령별 성공 또는 실패 결과
3. 실패했다면 실패 줄과 다음 원인 후보
4. 실행하지 못한 명령과 이유
5. 사람이 직접 확인해야 할 화면이나 입력
6. 이번 수정 범위 밖으로 남긴 일

규칙:
- 실행하지 않은 검증은 통과로 쓰지 마세요.
- 추정은 추정이라고 표시하세요.
- 다음 수정이 필요하면 가장 작은 단위로만 제안하세요.

이 질문은 AI를 의심하기 위한 절차가 아닙니다. 작업을 리뷰 가능한 상태로 만들기 위한 절차입니다. 테스트 실패를 해결한 뒤에도 어떤 명령이 통과했는지, 무엇을 확인하지 못했는지, 다음 위험이 무엇인지가 남아야 사람이 이어받을 수 있습니다.

다음 테스트 실패에서는 패치보다 재현을 먼저 붙입니다

다음에 테스트가 깨지면 로그부터 붙이지 말고 이 순서로 정리합니다.

실패한 명령을 적습니다.
기대 결과와 실제 결과를 한 문장씩 적습니다.
최근 변경 파일을 두세 개로 좁힙니다.
로컬과 CI 중 어디서 실패했는지 적습니다.
건드리면 안 되는 파일과 동작을 적습니다.
Codex에게 먼저 재현표를 만들라고 요청합니다.
재현표가 맞으면 그때 최소 수정과 검증 명령을 요청합니다.

테스트 실패를 잘 맡기는 요령은 더 강한 말로 재촉하는 것이 아닙니다. 실패를 작은 사건으로 바꾸고, 그 사건을 고칠 수 있는 범위만 열어 주는 것입니다. 오늘 저장해 둘 문장은 하나입니다. "바로 고치지 말고, 먼저 재현 조건을 정리해 주세요." 이 한 줄이 AI 코딩 결과의 diff를 작게 만들고, 사람이 검토할 수 있는 검증 기록을 남깁니다.