프로덕션 환경에서 에이전트가 실제로 고장 나는 지점은 어디인가요?

가장 많이 보는 실패는 모델 품질 문제가 아님. 상태와 제어 평면 드리프트가 문제임: 인증 만료, 도구의 부분적 성공, 사용자 컨텍스트를 벗어난 백그라운드 작업, 그리고 에이전트가 이미 일어난 일을 놓치는 것. 데모는 짧고 깔끔한 루프에서 실행되니까 이런 걸 숨김. 프로덕션은 내구성 있는 세션, 재시도, 승인, 로그, 그리고 전체 흐름을 재시작하지 않고도 사람이 개입할 수 있는 합리적인 방법이 필요할 때 깨짐.

완전 공감함. 프로덕션 실패의 대부분은 모델이 아니라 상태와 제어 평면 드리프트임. 인증 만료, 도구의 부분적 성공, 컨텍스트 상실, 동기화되지 않은 백그라운드 작업 같은 것들. 데모는 짧은 루프에서 도니까 깔끔해 보이지만, 실제 시스템은 내구성 있는 상태, 재시도, 승인, 적절한 로깅이 필요함. 우리도 똑같은 걸 봤음. 진짜 도전은 긴 워크플로우 동안 에이전트와 도구를 동기화 상태로 유지해서 모든 게 망가지지 않고 사람이 개입할 수 있게 하는 거임.

솔직히 예상치 못한 사용자 행동이 80%는 차지함. 사람들은 흐름을 전혀 안 따르고, 그냥 아무거나 막 누르면서 마법 같은 결과를 기대함.

• 도구/API 실패: 많은 에이전트가 외부 API와 통합할 때 신뢰성 문제로 데이터를 가져오거나 작업을 수행하는 데 실패함. - 예상치 못한 사용자 행동: 실제 사용자는 개발 중에 예상하지 못한 방식으로 상호작용해서 에이전트가 입력을 오해하거나 적절히 대응하지 못하게 함. - 평가 커버리지 부족: 부적절한 평가 지표는 성능의 사각지대를 만들어 문제를 식별하기 어렵게 함.

가장 어려운 건 상식임. 사람들은 에이전트 잠재력의 낮은 부분만 사용함. 말한 대로 워크플로우를 설계하고, 데모하고, 프로덕션에 올리는 거지. 갑자기 의도대로 작동 안 하고 파이프라인을 고쳐야 함. 설명한 대로 이게 정확히 문제고, 왜 안 되는지는 그냥 뉘앙스 차이일 뿐임. 문제는 유지보수나 자기 개선, 뭐라 부르든 그거임. 만약 에이전트가 스스로를 인식하지 못하고, 시간이 지나면서 진화하지 않고, 수집된 데이터로 파인튜닝이나 LoRA를 하지 않는다면...