모든 제품 로드맵에는 "AI 에이전트"라는 항목이 있습니다. 이 단어는 진보처럼 들립니다. 리더십에게 여러분의 팀이 단순히 현재를 유지하는 것이 아니라 미래를 구축하고 있다는 신호를 보냅니다. 하지만 대부분의 데모 영상이 보여주지 않는 불편한 진실이 있습니다. 에이전트는 일을 끝내는 가장 비싸고 예측 불가능한 방법이라는 점입니다. 대부분의 비즈니스 작업에서 에이전트는 완전히 잘못된 도구입니다. 최고의 엔지니어는 에이전트를 서둘러 만드는 사람이 아닙니다. 언제 멈춰야 할지를 아는 사람입니다.
분류의 함정
팀이 첫 에이전트의 범위를 정하는 것을 보면 보통 다음과 같은 모습을 보게 됩니다. 고객 지원 이메일이 도착합니다. 대규모 언어 모델(LLM)이 제목과 본문을 읽고, 이것이 결제 관련 질문인지 기술적 버그인지 결정한 뒤 적절한 큐(queue)로 보냅니다. 팀은 이것을 에이전트라고 부릅니다. 하지만 아닙니다.
그들이 구축한 것은 내부에 단일 모델 호출이 포함된 결정론적 흐름(deterministic flow)입니다. 단계는 고정되어 있습니다: 이메일 수신, 모델 호출, 큐로 라우팅. 루프도 없고, 도구 사용도 없으며, 첫 번째 시도가 실패했을 때 시스템이 계획을 재검토하기 위해 멈추는 순간도 없습니다. 중간에 지식 베이스를 검색하거나, 코드를 작성하거나, 주문 상태를 확인하지도 않습니다. 단 한 번의 판단을 내리고 다음으로 넘어갈 뿐입니다. 그 단일 호출을 마이크로서비스로 감싼다고 해서 에이전트가 되는 것은 아닙니다.
흐름을 에이전트로 착각했을 때 발생하는 진짜 비용은 단순히 추가적인 인프라 비용만이 아닙니다. 그것은 아무런 이득 없이 초래한 비결정론성(non-determinism)입니다. 온도(temperature) 설정이 0이 아니거나 프롬프트가 드리프트(drift)하기 때문에, 화요일 아침과 수요일 오후에 동일한 이메일이 서로 다르게 라우팅될 수 있습니다. 분류 단계가 하나뿐인 흐름은 더 빠르고 저렴하게 문제를 해결할 수 있음에도, 여러분은 지연 시간, 토큰 비용, 평가 오버헤드에 대해 에이전트 급의 비용을 지불하게 됩니다.
사다리를 타고 내려가며 해결하라
대부분의 문제는 그만큼 잘 해결할 수 있는 더 단순한 대안들이 있습니다. 사다리라고 생각하고, 가장 아래 단계부터 시작하십시오.
프로세스를 수정하십시오. 때로는 두 시스템이 서로 일치하지 않기 때문에 작업이 발생하기도 합니다. CRM의 고객 기록이 티켓팅 플랫폼과 동기화되지 않아 매일 아침 사람이 수동으로 그 간극을 메워야 한다면, 에이전트로 그 간극을 자동화하지 마십시오. 간극 자체를 없애십시오. 데이터 파이프라인이 정상적이라면 그 작업은 사라질 것입니다.
쿼리를 사용하십시오. 답이 단순한 조회나 집계라면, 그렇게 처리하십시오. "지난주 화요일에 처리된 환불 건수는 몇 건인가?"라는 질문에는 추론이 필요하지 않습니다. SQL이 필요할 뿐입니다. 자연어를 SQL로 변환하는 에이전트는 우아하게 들리겠지만, 그 유지보수 부담이 팀이 대시보드에서 실행하는 세 개의 문서화된 쿼리를 작성하는 것보다 크다는 사실을 깨닫게 될 것입니다.
결정론적 흐름을 구축하십시오. 규칙이 고정되어 있고 결과가 반복 가능하다면 명시적인 로직을 사용하십시오. 주문 금액이 임계값을 초과하면 재무팀으로 에스컬레이션합니다. 사용자가 30일 동안 활동이 없으면 재참여 이메일을 보냅니다. 코드는 변동성 없이 완벽한 관찰 가능성을 가지고 이를 처리합니다. 유닛 테스트도 가능합니다. 막연한 느낌(vibe)을 유닛 테스트할 수는 없습니다.
단일 모델 호출이 포함된 흐름을 사용하십시오. 분류, 감성 태깅 또는 데이터 추출은 이 단계에 해당합니다. 모델은 엄격한 스크립트 내에서 단 한 번의 판단을 내립니다. 문서를 수신하여 송장 번호를 추출하고 데이터베이스에 기록합니다. 주변 단계들은 하드코딩되어 있습니다. 모델은 다음에 무엇을 할지 선택하지 않습니다. 단지 보이는 것에 라벨을 붙일 뿐입니다. 이는 강력한 패턴이지만, 여전히 흐름(flow)입니다.
에이전트는 마지막에 구축하십시오. 다음 행동이 실행 도중 모델이 발견한 내용에 진정으로 의존하는 작업에만 이 단계를 남겨두십시오. 시스템이 이메일을 읽고, 물류 API에서 배송 정보를 조회해야 함을 깨닫고, 배송이 지연되었음을 확인한 뒤, 그 최신 데이터를 바탕으로 맞춤형 답변 초안을 작성해야 한다면, 그때가 바로 에이전트의 영역입니다. 모델이 새로운 사실을 접할 때마다 무엇을 할지 결정하기 때문에 경로를 미리 그려둘 수 없습니다.
화이트보드 테스트
회의 중에 논쟁을 빠르게 종결시킬 방법이 있습니다. 팀에게 화이트보드에 결정 분기(decision branches)를 그려보라고 요청하십시오.
모델이 실행되기 전에 모든 경로를 매핑할 수 있다면, 흐름을 구축하십시오. 다이아몬드 형태의 결정 기호를 그리고, if 문을 작성하면 끝입니다. 예측 가능성은 제한 사항이 아니라 기능(feature)입니다.
모델 자체가 다음 단계가 무엇인지 스스로 결정해야 한다면, 즉 모델이 도구를 선택하고, 파라미터를 설정하며, 다시 루프를 돌아 재사고해야 한다면, 그때는 에이전트가 필요합니다. 그 동적 라우팅이 경계선입니다. 단순히 새로운 API를 사용하고 싶다는 이유로 실수로 그 선을 넘지 마십시오.
숨겨진 세금
데모에서는 에이전트가 아무런 마찰 없이 매끄럽게 작동하는 것처럼 보입니다. 하지만 실제 운영 환경에서는 네 가지 세금이 빠르게 누적됩니다.
비결정론성. 동일한