AI 에이전트에서 가장 어려운 부분은 예외 상황(Unhappy Path)입니다.

대부분의 AI 에이전트 데모는 완벽한 시나리오를 보여줍니다. 깔끔한 질문이 정돈된 답변으로 이어지고, 모두가 박수를 칩니다.

진짜 엔지니어링은 상황이 틀어질 때 시작됩니다.

API가 다운되면 어떻게 될까요? 에이전트가 무한 루프에 빠져 신용카드를 탕진하면 어떻게 될까요? 에이전트가 데이터가 없는데도 마치 진짜인 것처럼 보이는 보고서를 작성하면 어떻게 될까요?

저는 유전체학(genomics) 분야의 이러한 문제들을 해결하기 위해 BioAgent를 구축했습니다. BioAgent는 데이터를 추출하고, PubMed를 검색하며, 임상 보고서를 작성하는 자율 분석가입니다.

저는 LangGraph와 Claude를 사용하여 이를 구축했습니다. 실패에 대비한 구축 과정에서 제가 배운 점들은 다음과 같습니다.

  • 모든 루프에 제한을 두세요 에이전트는 반드시 엄격한 재시도 제한(retry limit)을 가져야 합니다. 에이전트가 유료 API를 호출한다면, 루프는 곧 재정적 리스크가 됩니다. 제한은 매 단계마다 카운터를 증가시켜야만 제대로 작동합니다. 코드 한 줄을 깜빡한다면, 에이전트는 시스템이 충돌할 때까지 루프를 돌게 됩니다.

  • 성공이 아닌 실패를 테스트하세요 개발 중에는 해피 패스(happy path)가 항상 잘 작동합니다. 테스트 중에는 의존성(dependencies)이 실패하도록 강제해야 합니다. API가 오프라인 상태일 때 에이전트가 루프를 도는 대신, 기능이 우아하게 저하(degrade gracefully)되는지 확인하는 테스트를 작성하세요.

  • 확신에 찬 헛소리를 방지하세요 가장 큰 위험은 시스템 충돌이 아닙니다. 진짜 위험은 전문적으로 보이지만 가짜 데이터가 포함된 보고서입니다. 환각(hallucination)을 막기 위해 프롬프트 지침에만 의존하지 마세요. 에이전트가 절대로 지표를 지어내지 못하도록 테스트를 통해 보장해야 합니다.

  • 결과를 근거에 기반시키세요 검색(Retrieval)은 텍스트가 작성자에게 전달될 때만 유용합니다. 전체 초록(abstract) 대신 ID만 전달하면 모델이 관련성을 지어낸다는 사실을 발견했습니다. 보고서가 사실에 기반하도록 하려면 모델에 실제 텍스트를 전달해야 합니다.

프롬프트의 규칙은 희망일 뿐이지만, 테스트의 규칙은 보장입니다.

예외 상황(unhappy path)을 대비해 구축하세요. 그것이 실제로 중요한 부분입니다.

출처: https://dev.to/gbadedata/the-hardest-part-of-an-autonomous-ai-agent-is-the-unhappy-path-3p2c

선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi