1. 이 문제가 처음 발생한 실제 상황은 무엇입니까?
다단계 에이전트 워크플로에 대한 단위 테스트를 작성하는 동안 이런 일이 발생했습니다. 에이전트는 MCP 도구를 순서대로 호출하고 컨텍스트를 읽고 조건부 점프를 수행해야 합니다. 기존의 pytest 모의는 각 도구 호출을 고정된 반환 값으로 대체하지만 테스트는 항상 통과하지만 온라인 상태가 된 후 자주 시간 초과됩니다. 이틀을 미루다가 모의가 실제 도구의 지연 및 오류 응답을 시뮬레이션하지 않는다는 것이 문제라는 것을 발견했습니다. 그리고 하네스는 "테스트 환경과 프로덕션 환경의 차이"를 해결하기 위해 사용되는 도구입니다.
하네스(테스트 하네스)는 기본적으로 에이전트의 입력 및 출력을 대신하는 경량 실행 프레임워크로, 격리된 환경에서 모의 데이터를 삽입하고, 오류를 시뮬레이션하고, 동작을 기록할 수 있도록 해줍니다. 그러나 그 당시 내가 밟은 첫 번째 함정은 하네스를 일반 모의로 사용하고 반환 값만 바꾸고 시간 초과, 재시도 및 예외 흐름을 완전히 무시하는 것이었습니다.
2. 이 작업을 수행한 후 내 판단 방식을 크게 바꿔 놓은 몇 가지 결론.
하네스를 사용하여 테스트를 성공적으로 안정화한 후 세 가지 주요 결론에 도달했습니다.
- 하네스는 범용 접착제가 아닙니다. 외부 종속성을 시뮬레이션하는 데는 좋지만 코드 논리 자체를 대체할 수는 없습니다. 에이전트의 의사 결정 논리에 버그가 있는 경우 이를 활용하면 버그가 더 빨리 노출될 뿐입니다. 이는 좋은 일이지만 많은 팀은 활용이 취약한 코드 통과 테스트를 만들 수 있다고 잘못 믿고 있습니다.
- 하네스의 가치는 "통제 가능한 불확실성"에 있습니다. 상담원 행동은 LLM의 무작위 출력에 의존하는 경우가 많습니다. 하네스는 프롬프트와 도구 출력을 수정하여 각 테스트 동작을 반복 가능하게 만듭니다. 이는 컨텍스트 어셈블리 프로세스도 캡처하므로 LLM 끝점을 단순히 조롱하는 것보다 더 철저합니다.
- 학습 곡선은 생각보다 가파릅니다. 하네스에는 많은 구성 항목(시간 초과, 재시도, 오류 주입, 로깅)이 있으며 구성 단계에서 새로운 버그가 발생하기 쉽습니다. 처음에는 첫 번째 하네스를 실행하는 데 3일이 걸렸고 실제 테스트를 작성하는 데는 단 하루가 걸렸습니다.
3. 당시 우리가 겪었던 문제점과 이를 이후에 어떻게 수정했는지
가장 큰 함정은 과도한 하네스입니다. 그 당시 나는 상수 버전을 반환하는 정적 함수를 포함하여 모든 외부 호출을 하네스에 포함시키고 싶었습니다. 결과적으로 하네스 개체가 비대해지고 각 테스트마다 불필요한 모의 개체가 많이 로드됩니다. 해결 방법은 간단합니다. 하네스에서 실제로 외부의 불안정한 종속성(예: LLM 호출, 타사 API, 파일 시스템)만 관리하고 일반 단위 테스트를 통해 순수한 계산 논리를 다루는 것입니다.
두 번째 함정은 하네스의 수명주기를 무시하는 것입니다. 하네스에는 일반적으로 설정 및 해체 단계가 있으며 처음에는 테스트 간의 컨텍스트를 정리하지 못했기 때문에 동일한 모의 상태를 공유하는 여러 테스트와 업스트림 부작용으로 인해 다운스트림 테스트가 오염되었습니다. 나중에 각 테스트 전후에 명시적으로 Reset()을 호출하여 문제가 해결되었습니다.
세 번째 함정은 불완전한 오류 시뮬레이션입니다. 정상적인 반환 및 시간 초과만 시뮬레이션했지만 일부 오류(예: 인증 실패, 속도 제한)를 놓쳤습니다. 결과적으로 에이전트는 온라인에 접속한 후 429 오류가 발생했으며 하네스 테스트에서는 이 상황을 다루지 않았습니다. 교훈은 하네스를 사용하여 오류를 시뮬레이션할 때 최소한 시간 초과, HTTP 4xx/5xx 및 네트워크 중단이라는 세 가지 일반적인 예외를 다루라는 것입니다.
4. 비슷한 작업을 하고 있다면 가장 먼저 복사해야 할 가장 가치 있는 단계
가장 직접적인 시작 작업: 에이전트에서 가장 중요한 외부 호출(예: 유일한 LLM API)에 대해 하네스를 사용하여 "템플릿 하네스"를 작성합니다. 구체적인 작업은 다음과 같습니다.
- 현재 프로젝트(일반적으로 LLM 또는 데이터베이스)에서 핵심 불안정 종속성을 선택합니다.
- 설정(모의 서버 초기화), 실행(에이전트 호출 및 출력 캡처) 및 해체(모의 서버 정리)를 포함하여 하네스 클래스를 작성합니다.
- 하네스에서 호출 응답을 수정하고(예: 고정된 JSON 반환) 실제로 호출된 프롬프트와 매개변수를 기록합니다.
- 테스트를 실행하여 출력이 예상한 대로인지 확인합니다.
이 단계를 통해 30분 이내에 첫 번째 재사용 가능한 하니스 테스트를 받을 수 있으며 프롬프트가 올바르게 연결되었는지, 매개변수가 올바르게 전달되었는지 즉시 확인할 수 있습니다. 내 경험에 따르면 하네스를 한 번 실행하면 프롬프트 오류의 90%가 노출될 수 있습니다.
5. 언제 투자를 계속하고, 언제 노선을 바꿔야 할까요?
하네스 시나리오에 계속 투자하세요.
- 에이전트에 3개 이상의 외부 종속성이 있습니다.
- 새로운 기능을 개발 중이며 새 코드가 기존 동작을 손상시키지 않는지 확인해야 합니다.
- 팀은 지속적으로 새로운 에이전트나 새로운 도구를 추가하고 있습니다.
경로를 변경할 시간임을 알리는 신호:
- 비즈니스 테스트를 작성하는 대신 하네스 구성 자체를 디버깅하는 데 2일 이상을 소비했습니다.
- 외부 종속성이 자주 변경되어 하네스 유지 관리 작업이 테스트 이점보다 더 중요해집니다.
- 프로젝트는 아직 프로토타입 단계이며, API와 프로세스는 매일 바뀌고 있습니다.
이러한 경우에는 먼저 가벼운 모조품을 사용하여 지지한 후 안정성이 개선된 후 하네스를 도입하십시오.
마지막에 쓰세요
하네스는 만능은 아니지만 올바른 위치에 사용하면 에이전트 프로젝트의 테스트 신뢰도를 크게 향상시킬 수 있습니다. 핵심은 비결정론 제어, 실제 오류 시뮬레이션, 외부 종속성 격리 등 적용 가능한 경계를 명확히 하는 것입니다. 이 5가지 강의가 우회로를 피하는 데 도움이 되기를 바랍니다.
아직 댓글이 없습니다