AI 에이전트 운영에서 가장 비싼 부분은 토큰 비용이 아니라, 왜 그런 결과가 나왔는지 파악하는 시간이다.

완전 동의함

완전 동의함. 토큰 비용은 측정하기 쉽지만, 디버깅 비용 때문에 팀들이 조용히 몇 주씩 날려 먹지. 기존 소프트웨어는 보통 결정론적으로 실패하지만, 에이전트 시스템은 확률적으로 실패하거든. 똑같은 워크플로우가 9번은 성공하다가도 10번째에 실패할 수 있어. 리트리벌 품질, 툴 응답, 컨텍스트 드리프트, 스키마 변경, 모델 동작 때문이지. 그래서 옵저버빌리티 툴, 트레이스, 이밸, 꼼꼼한 로깅이 사람들이 생각하는 것보다 훨씬 일찍 필수 요소가 되는 거야. 프로덕션 환경에서는 질문이...

에이전트가 여러 툴에 의존하기 시작하면, 대부분의 실패는 '모델 문제'가 아니라 시스템 옵저버빌리티 문제가 돼. 프롬프트, 툴, 업스트림 변경 사항을 넘나들며 디버깅하는 게 금방 가장 큰 비용이 되지.

에이전트가 결정을 설명하도록 로그를 포함해서 해석 가능성을 구축해 볼 수는 있어. 토큰 측면에서는 좀 비싸고 검토하기도 어렵긴 한데, 치명적인 오류가 발생했을 때 로직의 어느 부분에서 실패했는지 좁혀 나가는 데 정말 도움이 돼.

엔지니어링이 아니라 CX 쪽에서 일하는데, 우리 AI 레이어에서도 똑같은 현상을 겪고 있어. 뭔가 고장 났을 때 디버깅하는 시간이 실제 추론이나 해결 비용보다 훨씬 비싸. Kayako의 AI 에이전트를 쓰는데, 티켓 분류 처리 방식에서 이상한 일이 생기면 왜 그런지 파악하는 데 한참 걸려. 학습 데이터 문제인가, 연동 문제인가, 아니면 누가 설정을 바꾼 건가? 그런 진단 시간이 진짜 인건비지. 해결 건당 비용은...

프롬프트부터 건드리는 게 당연한 본능인 이유는 프롬프트가 우리가 제어할 수 있는 유일한 레버이기 때문이지. 하지만 멀티 툴 환경에서는 모델 출력이 잘못된 진단 레이어라고 봐. 그건 무언가 실패했다는 것만 보여주지, 무엇이 원인인지나 체인의 어디서 문제가 생겼는지는 안 보여주거든. 툴 호출 페이로드를 단순히 성공/실패 상태가 아니라 구조화된 diff로 캡처했더라면 첫 번째 트레이스에서 바로 API 형식 변경을 잡아냈을 거야. 대신 그건 아무도 설명할 수 없는 품질 저하로 나타났지.

Langfuse가 문제 해결에 도움을 줬다고는 하지만, 이걸 eval 스택 탓으로 돌리지는 않겠어. 그냥 스키마 유효성 검사가 빠진 단순한 문제일 뿐이야.