Codex로 테스트 실패 해결하기: 오류 로그와 요청 예시

요약: 테스트 실패 해결 요청에는 실행 명령, 실패 로그, 기대 동작, 변경 경계를 함께 넣으세요. 테스트를 통과시키는 것과 기능이 맞게 동작하는 것은 구분해야 합니다.

1. 테스트 실패를 한 종류로 생각하지 않기

실패 화면에는 서로 다른 문제가 섞일 수 있습니다. 검증한 값이 예상과 다른 경우, 모듈을 불러오지 못한 경우, 테스트 명령 자체가 실행되지 않은 경우는 출발점이 다릅니다. “빨간 글씨가 나왔으니 함수가 틀렸다”라고 단정하면 코드를 불필요하게 수정할 수 있습니다.

먼저 실행이 어디까지 진행되었는지 확인하세요. 테스트 사례가 실행되어 값 비교에서 실패했는지, 그 전에 도구나 설정을 찾지 못했는지 구분합니다. 현재 로컬에서만 실패하는지, CI에서도 같은지 알면 맥락을 함께 적습니다. 아직 확인하지 못했다면 “CI에서는 정상”이라고 추정하지 말고 미확인이라고 표시하면 됩니다.

2. Codex에 전달할 최소 정보

OpenAI 공식 버그 수정 안내는 재현 단계와 제약, 수정 후 확인을 포함하는 요청을 설명합니다. 테스트 문제에도 실행한 명령과 재현할 조건을 전달하는 방식이 유용합니다. 아래 목록은 그 원칙을 테스트 실패 조사에 적용한 자체 체크리스트입니다.

• 프로젝트에서 실행한 정확한 명령과 작업 폴더
• 실패한 테스트의 이름과 핵심 오류 메시지
• 어떤 동작이 올바른지에 대한 요구사항
• 최근 바꾼 내용과 보존해야 할 기능
• 로컬과 CI 차이를 실제로 확인했는지 여부

로그는 첫 오류와 관련된 부분을 우선 공유하세요. 토큰, 비밀번호, 개인정보가 섞였는지 점검하고, 필요 없는 비밀값은 제거합니다. 단순히 마지막의 “실패” 문장만 보여 주면 원인을 가리키는 앞부분이 빠질 수 있습니다. 반대로 수천 줄의 로그를 설명 없이 붙이면 관련 정보를 찾는 부담이 커집니다.

3. 가상의 실패를 위한 요청 템플릿

가격 합계 계산 테스트가 실패합니다.
실행 명령: [실제로 사용한 명령]
실패 테스트: [실제 테스트 이름]
핵심 로그: [민감정보를 제거한 오류 내용]
기대 동작: 수량이 0인 항목은 합계에 포함하지 않습니다.
최근 변경: 수량 입력 검증을 수정했습니다.

원인부터 조사하고 코드 오류와 환경 오류를 구분해 주세요.
공개 함수의 입력·반환 형식은 유지해 주세요.
통과만을 위해 기대값을 바꾸거나 테스트를 삭제하지 마세요.
수정 후 같은 명령과 관련 검증을 실행하고 결과를 보고해 주세요.
실행하지 못한 검증은 이유와 함께 표시해 주세요.

대괄호 부분에는 실제 정보를 넣어야 합니다. 가격 계산의 정상 규칙을 모르겠다면 요구사항 문서나 기존 호출부를 확인하도록 요청하세요. 테스트의 기대값이 항상 옳은 것도 아니고, 구현이 항상 옳은 것도 아닙니다. 둘 중 무엇을 수정해야 하는지 판단할 기준이 필요합니다.

4. 수정 후에는 같은 실패를 다시 확인하기

첫 검증은 원래 실패한 명령으로 돌아오는 것입니다. 다른 테스트가 통과했다는 결과만으로 기존 문제가 해결되었다고 볼 수는 없습니다. 실패했던 사례가 이제 통과하는지, 관련된 정상 사례가 유지되는지 확인해야 합니다. 변경이 영향을 줄 수 있는 범위에 맞춰 검증을 추가하세요.

예를 들어 수량 0 처리를 바꿨다면 정상 수량, 여러 항목 합계, 잘못된 수량의 처리도 확인 대상으로 생각할 수 있습니다. 어떤 사례가 필요한지는 프로젝트의 요구에 따라 달라집니다. 결과 보고에서는 “실행했다”, “통과했다”, “환경 때문에 실행하지 못했다”가 분명히 나뉘어야 합니다. 테스트를 새로 만들었다는 사실 자체는 테스트 실행 결과와 다릅니다.

5. 계속 실패할 때 확인하는 질문

• 실패 지점이 달라졌는가? 새 오류와 기존 오류를 구분해 비교합니다.
• 환경이 준비되었는가? 필요한 도구, 의존성, 로컬 설정을 확인합니다.
• 외부 서비스에 의존하는가? 연결 실패와 기능 오류를 구분합니다.
• 가끔만 실패하는가? 재현 조건과 실행 기록을 남기고 원인을 단정하지 않습니다.
• 테스트 내용이 약해졌는가? 기대값 변경이나 검증 삭제가 요구사항과 맞는지 검토합니다.

PR의 실패한 검사에서 작업을 시작하는 흐름도 공식 코드 리뷰 문서가 안내합니다. 제공되는 진단은 검사 서비스에 따라 달라질 수 있으므로, 화면에서 실패 상태만 보이는지 실제 로그까지 연결되는지 구분하세요.

6. 오류 메시지에서 다음 조사 위치 고르기

긴 로그를 처음부터 모두 해석하려 하지 말고 테스트가 어느 단계에서 멈췄는지 찾으세요. 명령 시작, 설정 읽기, 의존성 로딩, 테스트 실행, 결과 비교의 순서로 나누면 조사할 위치가 달라집니다. 아래 오류 표현은 종류를 설명하기 위한 예시입니다. 실제 도구의 표현과 환경에 따라 다를 수 있으므로 자신의 첫 오류를 기준으로 판단해야 합니다.

명령 오류를 함수 수정으로 해결하거나 값 비교 오류를 재설치만으로 해결하려 하면 원래 실패를 놓칠 수 있습니다. Codex가 제시한 조치가 로그의 어느 단계와 연결되는지 물어보세요. 여러 문제가 있다면 첫 실행을 막는 원인을 해결하고 다음 실패를 새로 읽습니다. 로그가 달라졌다고 항상 상황이 나빠진 것은 아니며, 이전 단계를 통과해 다음 문제를 발견한 것일 수 있습니다.

7. 가상 합계 테스트를 재현 정보로 정리하기

다음은 수량 0 문제를 설명하기 위해 만든 가상 사례입니다. 실제 프로젝트에서 테스트를 실행한 기록이 아닙니다. JavaScript 프로젝트의 npm test가 Vitest 실행으로 설정되어 있고 tests/total.test.js가 있다고 가정합니다. 이 조건이 없는 프로젝트에서는 아래 파일명이나 명령을 그대로 사용할 수 없습니다.

실행 폴더: C:\Projects\cart-demo
실행 명령: npm test -- tests/total.test.js
실패 사례: 수량 0 항목은 합계에서 제외
가상 비교 로그:
Expected: 0
Received: 1200
입력: [{ price: 1200, quantity: 0 }]

조사할 함수가 아래처럼 작성되어 있다면 0이 기본 수량 1로 바뀌는 부분이 원인 후보가 됩니다. 코드의 계산 경로를 읽어 그렇게 설명할 수 있지만 실제 프로젝트의 실패와 같은 원인인지 확인하려면 테스트 입력과 호출부를 연결해야 합니다. 테스트가 다른 함수를 불러오거나 설정에 따라 다른 구현을 사용한다면 이 코드만 고쳐도 원래 실패는 남을 수 있습니다.

function sumCart(items) {
  return items.reduce((total, item) => {
    const quantity = item.quantity || 1;
    return total + item.price * quantity;
  }, 0);
}

수정 방향을 정할 때는 값 누락의 기존 정책도 봅니다. “수량이 없으면 1”이 의도라면 0과 누락을 구분하는 처리가 필요합니다. 음수나 문자열 입력을 어떤 계층에서 검사하는지는 별도 요구사항입니다. 이번 실패를 고치면서 임의의 숫자 변환과 데이터 형식 변경까지 추가하지 않도록 범위를 정하세요.

실패 입력이 실제로 호출하는 함수를 찾아 주세요.
수량 0과 값 누락을 현재 코드가 어떻게 구분하는지 설명하세요.
기존 요구사항과 테스트의 기대값이 맞는지 먼저 확인하세요.
그 근거를 바탕으로 최소 수정하고 원래 실패 명령을 다시 실행하세요.
입력 형식이나 다른 수량 정책을 임의로 새로 정하지 마세요.

8. 실패 사례 주변의 정상 동작까지 확인하기

한 사례를 통과시키기 위해 모든 수량을 0으로 처리하면 실패 테스트는 통과해도 기능은 망가집니다. 그래서 수정 후 검증은 원래 실패와 가까운 정상 사례를 함께 보아야 합니다. 다음 표는 가상 합계 요구사항을 기준으로 한 검증 설계입니다. 아직 정해지지 않은 정책은 답을 만들어 내기보다 요구사항 확인 항목으로 남깁니다.

먼저 원래 실패한 사례를 다시 실행하고 관련된 검증을 수행합니다. 이후 변경 영향에 맞춰 프로젝트의 필수 검사를 진행하세요. 아주 작은 함수 수정에 전혀 관련 없는 도구를 새로 설치하는 것보다 이미 쓰는 검증 절차를 따르는 편이 좋습니다. 반대로 여러 호출부가 쓰는 공통 함수를 바꿨다면 호출부의 기대 동작도 확인해야 합니다.

테스트 코드를 바꾼 경우에는 무엇을 바꿨는지 차이를 읽으세요. 입력 조건을 약하게 만들거나 검증 문장을 삭제하거나 테스트를 skip한 뒤 통과를 보고하는 것은 원래 문제 해결의 근거가 되지 않습니다. 요구사항 자체가 바뀌었다면 변경 근거를 남기고 새 정책을 검증하도록 고치는 것은 가능합니다. 구현과 테스트 중 무엇이 맞는지는 제품 규칙으로 결정합니다.

9. 로컬과 CI 차이, 가끔 실패하는 문제 조사하기

로컬에서 통과하지만 CI에서 실패하면 실행 환경을 표로 비교해 보세요. 실제로 확인한 버전과 명령만 적고, 보지 못한 CI 설정은 미확인으로 남깁니다. 운영체제 차이 때문에 파일 대소문자나 경로 처리 문제가 드러날 수 있고, 시간대·환경 변수·서비스 준비 상태 때문에 결과가 달라질 수도 있습니다. 이런 가능성을 모두 원인이라고 단정하지는 마세요.

로컬 통과와 CI 실패를 비교해 주세요.
각 환경의 실제 실행 명령, 작업 폴더, 런타임 버전,
설정 파일, 필요한 서비스의 준비 조건을 근거와 함께 정리하세요.
첫 오류가 같은지 비교하고 차이와 실패 사이의 연결을 조사하세요.
확인되지 않은 환경 정보는 추측하지 마세요.

가끔만 실패하는 문제에서는 성공과 실패 실행의 차이를 모으는 것이 출발점입니다. 실행 순서, 동시에 실행한 테스트, 공유 데이터, 시간에 의존하는 입력 등을 기록하세요. 기다리는 시간을 무조건 늘리는 조치는 증상을 숨길 수 있으므로 무엇을 기다리는지 먼저 설명하게 합니다. 특정 순서에서만 실패하면 앞선 테스트가 남긴 상태가 다음 테스트에 영향을 주는지도 조사할 수 있습니다.

이 테스트는 가끔 실패합니다.
실패한 실행과 성공한 실행의 로그를 각각 제공합니다.
차이를 비교하고 재현 가능한 조건부터 좁혀 주세요.
대기 시간 증가나 무조건 재시도보다 실패 원인의 근거를 우선 찾으세요.
원인을 확정하지 못하면 추가로 수집할 정보와 다음 실험을 제안하세요.

최종 결과에는 원래 명령의 결과, 관련 정상 사례, 필요한 후속 검증을 남기세요. 원래 실패를 재현하지 못한 상태에서 수정했다면 그 한계를 설명해야 합니다. CI 로그를 읽었다는 것과 CI를 실제 다시 실행해 통과한 것은 다릅니다. 구분된 보고가 있어야 다음 담당자가 같은 조건에서 조사를 이어 갈 수 있습니다.

10. 자주 묻는 질문

실패 테스트만 지워도 되나요? 테스트가 무엇을 보장하던 것인지 먼저 확인하세요. 제품 규칙이 바뀌었다면 근거를 남기고 검증을 수정할 수 있지만, 실패를 숨기기 위한 삭제는 해결을 증명하지 못합니다.

한 번 통과하면 완료인가요? 일정하지 않은 실패라면 한 번의 성공만으로 원인을 확정하기 어렵습니다. 어떤 조건에서 문제가 생겼는지와 수정의 근거를 함께 확인하세요.

실행할 수 없으면 어떻게 하나요? 필요한 환경과 미확인 사항을 보고받고, 실행 가능한 환경에서 같은 절차를 이어 가세요. 실행하지 않은 테스트를 통과했다고 표현하지 않는 것이 중요합니다.

공식 출처 및 확인일: OpenAI 공식 문서: Prompting — Fix a bug · OpenAI 공식 문서: Code review — Failing checks. 2026년 10월 3일 확인. 예시는 자신의 프로젝트와 현재 기능에 맞게 조정하세요.