코딩 에이전트가 작성한 오류 처리를 확인하는 방법

코딩 에이전트는 재시도 및 속도 제한 처리를 추가했으며 테스트가 통과했다고 말합니다. 그것을 신뢰하기 전에 테스트가 무엇을 기준으로 실행되었는지 확인합니다.

코딩 에이전트 3개(실행 210개)를 사용하여 실행한 테스트에서 앱에서 API 오류를 처리하고 작동함을 보여 달라고 요청했습니다. 작업 코드를 요청한 140개 실행 중 76%에서 에이전트는 fetch 스텁, httpx.MockTransport, 또는 일회성 HTTP 서버를 사용하여 실패 사례를 수동으로 구축했습니다. 실제 API를 사용할 수 있고 프롬프트가 이를 배제하지 않는 75개의 실행에서 앱을 실제 API URL로 테스트한 경우는 0건이었다. 이와 같은 테스트를 통과하면 에이전트의 코드가 에이전트가 상상한 실패를 처리한다는 것을 증명합니다. 이는 API가 보내는 것과 다른 실패입니다.

Checklist

  1. 무엇을 기준으로 테스트했는지 물어봅니다. 에이전트에게 "테스트 중에 앱이 어떤 URL을 호출했고, 무엇이 오류를 반환했나요?"라고 물어보세요. 답이 작성한 스텁 또는 로컬 서버이면 테스트를 추가한 분기들의 단위 테스트로 처리합니다.
  2. 테스트를 위해 추가된 스위치를 찾으세요. diff에서 새 환경 변수, 기본 URL 설정 또는 플래그를 검색합니다. 테스트에서 105회 실행 중 61회는 GitHub, OpenAI 또는 날씨 API를 호출하는 앱에서 하나를 추가했습니다. 프로덕션 환경에 둘지 여부를 결정합니다.
  3. API의 문서화된 동작과 대조하여 코드를 확인합니다. 각 API는 고유한 방식으로 실패합니다.
    • GitHub: 기본 속도 제한을 초과하면 403 또는 429가 반환되고 x-ratelimit-remaining가 0로 설정되며, UTC epoch 초 단위인 x-ratelimit-reset의 시간까지 기다립니다. 보조 속도 제한의 경우, retry-after가 있으면 그때까지 기다립니다. 그렇지 않으면 0가 x-ratelimit-reset이면 x-ratelimit-remaining까지, 그렇지 않으면 최소 1분 동안 기다립니다. 429만 확인하는 코드는 403을 누락합니다.
    • OpenAI: 일부 429 오류는 청구 및 지출 한도에 관한 것입니다. 예: credit_balance_exhausted. 그것들을 다시 시도해도 도움이 되지 않습니다. 429마다 재시도하는 코드는 사용자에게 문제를 숨깁니다.
    • Anthropic: 지출 한도 429에는 헤더가 없으며 retry-after 과부하 시에는 표준 상태 코드만 알고 있는 코드가 예상하지 못할 수 있는 529를 반환합니다.
  4. 어떻게 읽히는지 확인합니다 Retry-After. 헤더는 몇 초 또는 HTTP 날짜(RFC 9110)를 포함합니다. 코드가 API에서 보내는 형식을 처리하고, 시도 횟수와 총 대기 시간을 제한하며, 이미 다시 시도하는 SDK를 기반으로 다시 시도하지 않는지 확인합니다.
  5. 재시도 횟수를 모두 소진했을 때 사용자에게 표시되는 내용을 확인합니다. 스택 추적 또는 무한 스피너 대신 명확한 메시지를 찾고 사용자가 작업을 잃지 않는지 확인합니다.
  6. 시뮬레이션된 실패를 사용하여 실제 URL에서 앱을 실행합니다. 실행 중인 앱, 해당 SDK 및 재시도 정책이 함께 작동하는 방식을 보여주는 유일한 단계입니다.

에이전트가 작성한 오류 처리를 확인하는 방법

Approach 찾은 내용 당신이 놓친 것
diff 읽기 코드가 올바른지 여부 API의 실제 응답에 대해 올바르게 동작하는지 여부
에이전트의 테스트 실행 작성한 브랜치가 실행된다는 것 스텁이 모델링하지 않은 모든 것: 실제 상태 코드, 헤더, 오류 본문 및 SDK 재시도
실패할 때까지 실제 API를 호출하세요 실제 동작 요청 시 실패를 임의로 유발할 수 없으며 실제 할당량을 사용합니다.
시뮬레이션된 실패를 사용하여 실제 URL에서 앱을 실행 실행 중인 앱, 해당 SDK 및 재시도 정책이 API 자체 오류를 처리하는 방법 독립된 상태의 코드입니다. 그 용도로는 에이전트의 단위 테스트를 유지하세요.

앱에서 시도해 보기

Dev Proxy는 앱이 실제 API에 보내는 요청을 가로채고 앱 코드를 변경하지 않고 선택한 오류를 반환합니다. 많이 사용되는 API는 프리셋으로 시작하세요. 에이전트가 작성한 GitHub 속도 제한 처리 내용을 확인하려면 다음을 작성했습니다.

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

앱을 실행하고 개발 프록시 출력을 확인합니다. 사전 설정은 앱이 제한을 초과하면 GitHub 속도 제한 헤더가 있는 429를 반환합니다. 사전 설정의 RetryAfterPlugin은 대기 시간이 끝나기 전에 앱이 API를 다시 호출하는지를 알려줍니다. anthropic-throttling 및 openai-throttling 사전 설정은 공급자 자체의 속도 제한 오류에 대해서도 동일한 작업을 수행하며, openai-throttling 다시 시도해서는 안 되는 credit_balance_exhausted 429도 반환합니다.

다른 API의 경우:

코딩 에이전트에 Dev Proxy 구성을 작성하도록 요청할 수도 있습니다. Dev Proxy 문서 및 모범 사례를 조회하고 설치한 버전을 확인할 수 있도록 에이전트에 Dev Proxy MCP 서버를 추가합니다. 에이전트가 작성하는 다른 코드와 마찬가지로 해당 구성을 검토하세요.

Dev Proxy를 설치하려면 Dev Proxy 설정을 참조하세요.

다음 단계

임의 오류로 내 앱 테스트

또한, 다음을 참조하세요.

  • 에 마지막으로 업데이트됨