범용 에이전트의 운영 리스크
- •디미트리스 키르코스(Dimitris Kyrkos)는 범용 에이전트가 하나의 시스템 프롬프트를 운영 장애 지점으로 만든다고 경고했다
- •4,000단어짜리 지원 프롬프트는 과금, 환불, 문제 해결, 응대 톤 규칙을 격리 없이 섞을 수 있다
- •키르코스는 거대한 에이전트 프롬프트 대신 의도 분류기, 전문 함수, 결정론적 라우팅을 권고했다
디미트리스 키르코스(Dimitris Kyrkos)는 2026년 7월 31일, 하나의 범용 AI 에이전트가 데모에서는 효율적으로 보일 수 있지만 실제 운영에서는 취약해진다고 주장했다. 실제 트래픽에서는 하나의 프롬프트, 하나의 API 호출, 하나의 사고 모델이 서로 무관한 작업을 모두 처리해야 하기 때문이다. 원문은 이런 패턴이 장애, 토큰 낭비, 수천 개의 엣지 케이스 전반에 걸친 회귀 문제를 겪기 전까지 비용을 숨기는 경우가 많다고 설명했다.
키르코스는 제품 질문에서 시작한 지원 에이전트가 과금, 환불, 기술 문제 해결, 세 고객 세그먼트별 응대 톤 규칙까지 담은 4,000단어짜리 시스템 프롬프트로 커지는 사례를 들었다. 엣지 케이스 #41을 추가하면 같은 모델이 엣지 케이스 #12를 처리하는 방식도 바뀔 수 있다. 두 지시가 하나의 주의 예산 안에서 경쟁하기 때문에, 팀은 어떤 줄이 회귀를 일으켰는지 분리해 확인하기 어렵다.
원문은 단일 구조의 에이전트를 통과하는 모든 요청이 쓰지 않는 기능의 비용까지 부담한다고 밝혔다. “내 주문 상태가 뭐야”처럼 단순하고 빈도가 높은 의도는 다섯 줄짜리 함수로 처리할 수 있는데도, 거대한 프롬프트 전체를 거치게 된다. 또한 라우팅, 작업 실행, 서식 지정을 한 번의 추론 패스(모델 실행 1회)에 넣으면 하나의 잘못된 지시가 이후 모든 단계에 영향을 줄 수 있으며, 사용자가 보기 전에 변화를 잡아낼 경계도 없다고 지적했다.
키르코스는 4,000단어짜리 만능 프롬프트를 테스트하는 일이 “확률 연습”이 된다고 말했다. 팀이 같은 대화를 열두 번 다시 실행하면서 실패가 허용 가능한 임계값 아래에 머물기를 기대해야 하기 때문이다. 그가 제안한 해법은 병합이 아니라 라우팅이다. 작은 분류기가 의도를 판단하고, 전문 함수가 분리된 작업을 맡으며, 비LLM 코드가 라우팅과 상태, 최종 서식을 담당하면 각 구성 요소는 단위 테스트가 가능할 만큼 작아진다.