# 모델 버전 간 코딩 에이전트 실패를 어떻게 재현하나요? > 전체 실행을 버전 관리된 테스트 픽스처로 캡처한 뒤 같은 프롬프트, 저장소 커밋, 도구 계약, 환경, 중지 규칙을 고정 모델 ID에 재생하세요. 에이전트의 문장뿐 아니라 구조화된 이벤트와 최종 저장소 상태를 비교해야 합니다. # 모델 버전 간 코딩 에이전트 실패를 어떻게 재현하나요? 유용한 재현은 복사한 대화 기록이 아니라 실행 가능한 실험입니다. 실패 당시 저장소 상태에서 시작해 에이전트가 볼 수 있었던 모든 입력을 고정하고, 기계로 판정할 수 있는 단언으로 실패를 정의하세요. 그런 다음 고정 모델 버전으로 같은 픽스처를 여러 번 재생합니다. 에이전트 실행은 모델 동작, 도구, 파일, 네트워크, 오케스트레이션, 시간의 결합입니다. 하나라도 바뀌면 다른 결과만으로 모델이 문제를 만들거나 해결했다고 증명할 수 없습니다. ## 실패를 단언으로 정의하기 실패와 성공을 구분하는 최소 관측 조건을 작성하세요. 테스트가 계속 실패함, 예상치 못한 파일 변경, 금지된 명령, 누락된 마이그레이션, 컴파일되지만 동작이 달라지는 패치 등이 좋습니다. “답변이 더 나빠 보인다” 같은 기준은 피하세요. 수정 작업의 수락 조건은 다음과 같을 수 있습니다. * 원래 회귀 테스트가 통과한다. * 기존 테스트도 모두 통과한다. * 허용 목록 밖 파일은 바뀌지 않는다. * 고정된 모델 호출 횟수 안에 에이전트가 멈춘다. * 최종 diff에 생성된 비밀이나 불필요한 lockfile 변경이 없다. ## 전체 실행 경계 캡처하기 프롬프트는 입력 중 하나일 뿐입니다. 픽스처와 함께 다음을 저장하세요. | 계층 | 고정할 항목 | 결과가 달라지는 이유 | |---|---|---| | 저장소 | 커밋, submodule, 미커밋 패치, 추적되지 않은 파일 | 에이전트가 정확한 소스 상태를 바탕으로 추론함 | | 지침 | 시스템 프롬프트, 저장소 규칙, 사용자 작업 | 작은 문구 차이가 계획을 바꿈 | | 모델 | 제공자, 불변 ID, 매개변수 | 별칭과 기본값이 바뀔 수 있음 | | 도구 | 이름, JSON schema, 권한, timeout | 도구 능력이 계획을 결정함 | | 환경 | 이미지, OS, 아키텍처, 의존성 잠금 | 명령과 테스트가 다르게 동작할 수 있음 | | 외부 데이터 | 모의 HTTP, 시계, 무작위 입력 | 실시간 서비스가 변동을 만듦 | | 오케스트레이터 | 루프 제한, 재시도, 컨텍스트 압축 | 같은 모델도 다른 이력을 받을 수 있음 | 비밀 값은 제거하되 자격 증명의 존재와 범위는 보존합니다. ## 텍스트가 아니라 구조화 이벤트 기록하기 모델 요청과 응답, 도구 호출과 결과, 재시도, 중지 결정을 순서가 있는 이벤트로 저장하세요. 큰 도구 출력에는 해시를 붙이고 원본 산출물은 별도로 둡니다. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` 이를 통해 새 모델이 다른 도구를 골랐는지, 같은 오류를 다르게 해석했는지, 다른 증거를 받았는지 확인할 수 있습니다. ## 버전을 고정하고 실시간 변동 제거하기 가능하면 날짜가 붙거나 불변인 모델 ID를 사용하세요. 과거 실패를 `latest`와 비교하면 이미 다른 빌드를 가리킬 수 있습니다. 깨끗한 컨테이너나 VM에서 실행하세요. 실시간 검색과 변경 가능한 패키지 인덱스는 기록된 응답이나 내부 snapshot으로 바꿉니다. 날짜 민감 로직은 시계를 고정합니다. 네트워크가 필요하면 모든 응답을 기록하고 부분 통제 시험이라고 표시하세요. 난수 시드는 도움이 되지만 분산 추론, 도구 시점, 제공자 변경은 고정하지 못합니다. ## 한 쌍이 아니라 행렬 재생하기 버전마다 한 번 실행해서는 회귀와 변동을 구분할 수 없습니다. 픽스처를 고정하고 작은 행렬을 사용하세요. | 모델 버전 | 반복 | 통과율 | 호출 중앙값 | 실패 시그니처 | |---|---:|---:|---:|---| | 고정 기준 ID | 5 | 4/5 | 9 | 경계 테스트 누락 | | 고정 후보 ID | 5 | 1/5 | 13 | 생성 파일 수정 | | 후보와 이전 프롬프트 | 5 | 1/5 | 12 | 같은 시그니처 | 5회는 유용한 시작점입니다. 간헐적이거나 중요한 실패는 더 늘리세요. 매개변수 자체를 시험하지 않는 한 temperature 등은 같게 유지합니다. ## 결정과 저장소 상태를 따로 비교하기 다음 계층을 각각 비교하세요. * 정규화된 모델 및 도구 이벤트. * 명령과 종료 코드. * 최종 파일 트리와 패치. * 수락 테스트와 자원 사용량. 자연어 추론이 같을 필요는 없습니다. 다른 경로로 동등한 올바른 패치를 만들 수 있고, 비슷한 문장이 중요한 명령 차이를 숨길 수도 있습니다. ## 재현 후 픽스처 최소화하기 실패가 반복되면 관련 없는 파일, 도구, 프롬프트 문단, 외부 호출을 하나씩 제거하세요. 작은 픽스처는 빠르고 원인 경계를 더 잘 드러냅니다. 감사용 전체 사고 재생과 지속 평가용 최소 회귀 테스트를 모두 보관하세요. 최소 사례를 모델 업그레이드 게이트에 추가합니다. ## 이식 가능한 모델 어댑터 사용하기 Atlas Cloud 같은 게이트웨이는 여러 모델을 하나의 OpenAI 호환 클라이언트 뒤에 둘 수 있지만 호환성이 동일한 동작을 의미하지는 않습니다. 모델 ID와 고유 옵션은 어댑터에 두고 공통 하네스가 픽스처, 이벤트, 재시도, 단언을 관리합니다. 이 구조를 사용하면 평가 로직을 다시 쓰지 않고 제공자 간에 같은 재현을 실행할 수 있습니다. ## 결론 실행 경계를 고정하고 고정 모델을 여러 번 재생하며 실행 가능한 결과로 판단하세요. 사고의 모든 조건을 재현할 수 없다면 어떤 입력이 여전히 실시간인지 명시하고 모델 회귀의 증명이 아닌 비교 연구로 다루세요. ## FAQ ### 코딩 에이전트 실패를 재현하려면 무엇을 기록해야 하나요? 저장소 커밋과 미커밋 패치, 프롬프트와 시스템 지침, 모델 ID와 매개변수, 도구 schema와 결과, 환경 이미지, 잠금 파일, 자격 증명 정책, 네트워크 정책, 정확한 성공 조건을 기록하세요. ### latest 모델 별칭으로 실패를 재생해도 되나요? 아니요. 변경 불가능하거나 날짜가 포함된 모델 ID를 사용하세요. latest 별칭은 테스트 중 바뀔 수 있어 성공과 실패의 원인을 정확히 구분할 수 없습니다. ### 고정 난수 시드만으로 부족한 이유는 무엇인가요? 시드는 제공자 인프라, 도구 실행 시점, 검색 결과, 모델 개정판을 고정하지 못합니다. 여러 통제 중 하나일 뿐 결정성을 보장하지 않습니다. ### 코딩 에이전트에 가장 좋은 성공 판정은 무엇인가요? 테스트, lint, 예상 파일 diff, 금지 파일 검사, 명령 종료 코드 같은 실행 가능한 단언을 우선하세요. 텍스트 유사도는 코딩 작업 판정에 대체로 부족합니다. ### 모델 버전마다 몇 번 재생해야 하나요? 결정적 회귀와 변동성을 구분할 수 있을 만큼 반복하세요. 소규모 시작점으로 5회가 실용적이며, 영향이 큰 실패는 20회 이상이 필요할 수 있습니다. ### 같은 하네스로 여러 제공자 모델을 비교할 수 있나요? 예. 요청, 도구 계약, 이벤트 로그, 출력 단언을 정규화하고 제공자별 옵션을 어댑터에 격리하면 픽스처를 이식 가능하게 유지할 수 있습니다.