4개월 동안 AI 에이전트 아키텍처를 두 번 재구축했다

새로운 시스템을 도입할 때 설계도 하나를 완성하는 데만 수개월이 걸리는 일이 흔하다. 하지만 인튜이트(Intuit, 금융 소프트웨어 기업)는 단 4개월 만에 AI 에이전트 아키텍처(시스템 설계 구조)를 두 번이나 완전히 갈아엎었다.

처음에는 특정 업무만 수행하는 전문 에이전트들을 모아 운영했다. 이후 이를 총괄 지휘하는 중앙 오케스트레이션 레이어(전체 흐름을 제어하는 관리 층)를 도입해 효율을 높이려 했다. 하지만 결국 관리 층마저 걷어내고 기술과 도구 기반 시스템으로 전환했다. AI가 상황에 맞춰 필요한 기능(Skill)과 도구(Tool)를 라이브러리에서 직접 꺼내 쓰는 방식이다. 이 두 번째 재구축 과정은 총 60일이 소요되었으며, 20일 이내에 첫 작동 버전을 구현하며 속도를 냈다.

민감한 금융 데이터를 보호하기 위해 권한 승인 모델을 엄격하게 적용했다. 에이전트가 고객의 금융 데이터에 대해 취하는 모든 행동은 반드시 사전에 명시적인 허가를 받아야만 실행된다. 동시에 모든 활동 내역을 감사 로그(작업 기록 저장소)에 실시간으로 기록한다. 기록된 로그를 통해 잘못된 작업이 수행되었을 때 이를 추적하고 원래 상태로 되돌리는 복구 설계를 갖췄다.

거대한 단독 에이전트를 구축하는 것보다, 작고 명확한 기술과 도구 단위로 기능을 쪼개 설계하는 것이 정확도를 높이는 길이다. 이러한 모듈형 설계는 새로운 기능을 추가할 때 전체 시스템을 건드리지 않아도 되어 확장성 면에서도 유리하다.

기술이 실제로 작동하는 방식

어떤 이는 AI끼리 대화를 나누면 효율이 극대화될 거라 믿었지만, 실제 현장에서는 정반대의 결과가 나왔다. 인튜이트가 처음 구축한 중앙 오케스트레이션 시스템(전체 AI 흐름을 관리하고 지시하는 관제탑)은 에이전트들이 결과물을 자연어로 주고받는 구조였다. 이 방식에서는 하위 에이전트가 상위 에이전트가 어떤 논리적 과정을 거쳐 결론을 내렸는지 스스로 추론해야 했다. 정보가 전달되는 단계인 홉(hop)이 하나씩 추가될 때마다 추론의 정확도는 낮아졌고, 그 틈으로 발생한 작은 오류는 다음 단계에서 더 크게 불어났다. 에이전트 10개가 사슬처럼 연결된 구조에서는 가끔 실수가 발생하는 수준이 아니라, 설계 자체가 오류를 복리로 증폭시키는 구조적 결함을 갖고 있었다. 상위 단계의 작은 오해가 하위 단계로 갈수록 걷잡을 수 없이 커지는 식이다.

AI의 추론 한계를 보완하기 위해 대화 도중 전체 맥락을 유지한 채 인간 전문가를 즉시 연결하는 기능을 도입했다. 고객은 AI와 대화하다가 막히는 지점에서 인튜이트 제품 지원 담당자나 본인의 회계사, 또는 인튜이트의 북키퍼(장부 기록원)를 직접 호출할 수 있다. 이때 연결된 전문가는 AI 에이전트가 고객과 나눈 모든 대화 내용과 수행한 작업 내역을 그대로 공유받는다. 전문가는 AI가 어디까지 처리했는지 즉시 파악해 끊김 없는 지원을 제공하며, 고객은 처음부터 상황을 다시 설명하는 번거로움을 덜게 된다. 현재 인튜이트는 전체 고객의 약 1%를 대상으로 이 기능의 실효성을 테스트하고 있다. AI가 해결하지 못한 지점을 인간이 즉시 이어받아 처리하는 하이브리드 구조를 검증하는 단계다.

채팅 기반 시스템 도입 이후 고객 피드백 수집률이 약

보통 고객의 속마음을 알기 위해서는 정성스러운 설문조사나 명시적인 요청이 필요하다고 믿는다. 하지만 채팅 기반 시스템을 도입하자 고객 피드백 수집률이 0.3%에서 거의 100%로 급증했다. 사용자가 AI와 나누는 모든 대화 내용 자체가 곧 피드백으로 기능했기 때문이다. 인튜이트(Intuit, 세무·회계 소프트웨어 기업)는 고객이 직접 의견을 남겨주길 기다리는 명시적 피드백 방식에서 벗어나, 대화 데이터 전체를 체계적으로 분석하는 모델을 구축했다. 이를 통해 시스템의 어떤 지점에서 사용자가 어려움을 겪고 있는지 정확히 찾아내고 빠르게 개선하는 선순환 구조를 만들었다. 데이터의 양이 비약적으로 늘어나면서 시스템의 빈틈을 메울 수 있는 근거가 명확해졌다.

실제 고객이 입력한 질문 데이터를 활용한 데모가 내부 설득의 핵심이었다. 리더십에게는 실제 쿼리를 사용해 새 아키텍처가 기존 방식보다 성능이 뛰어나다는 점을 눈앞에서 증명했다. 엔지니어들에게는 확장성 논리를 앞세웠다. 특정 좁은 문제 하나만 해결하고 끝나는 단독 에이전트보다, 제품의 특정 기능을 사용하는 모든 고객에게 서비스될 수 있는 공유 기술(Skill)과 도구(Tool) 단위의 설계가 유리하다는 점을 강조했다. 개별 에이전트를 여러 개 만드는 대신, 누구나 꺼내 쓸 수 있는 공용 도구함을 만드는 방식이 서비스 전체의 품질을 균일하게 높이고 운영 효율을 극대화하는 길이라는 판단이었다. 단일 목적의 도구가 아닌 범용적인 기술 단위로 설계했을 때 비로소 수많은 고객에게 동일한 수준의 성능을 제공할 수 있기 때문이다.

인튜이트가 4개월 만에 설계를 두 번이나 갈아엎은 이유는 AI 에이전트 간의 대화가 생각보다 부정확하기 때문이다. 에이전트끼리 자연어로 결과물을 주고받으면 원래 의도가 희석되고 오류가 쌓이는 맥락 손실이 발생한다.

결국 중요한 것은 단독 에이전트를 만드는 것이 아니라, 어디서든 꺼내 쓸 수 있는 기술과 도구 단위로 기능을 쪼개 설계하는 일이다. 복잡한 업무 프로세스를 얼마나 작은 기능 단위로 정교하게 분해하느냐가 AI 에이전트의 실질적인 정확도를 결정한다.