복리 이자 계산을 LLM에게 시켰더니 검증 오류가 터졌습니다. Google이 주최한 실전 해커톤에서 실제로 벌어진 일입니다. AI가 틀린 게 아닙니다. 처음부터 그 일을 시키면 안 됐던 거였죠.

Google이 실제 개발자들을 한 방에 모아 극한의 시간 제약 속에서 AI 에이전트를 만들게 한 ‘Google Cloud AI Agent Bake-Off’. 전자상거래 반품 처리, 레거시 뱅킹 시스템 현대화, 스타트업 GTM 자동화처럼 현실적인 과제들이 주어졌습니다. 그 과정에서 성공한 팀과 실패한 팀을 가른 차이를 Google이 5가지 패턴으로 정리했습니다.

출처: Build Better AI Agents: 5 Developer Tips from the Agent Bake-Off – Google Developers Blog

LLM이 해야 할 일과 하면 안 될 일

뱅킹 챌린지에서 여러 팀이 같은 실수를 했습니다. 금융 계산을 LLM에게 맡긴 것입니다. 복리 이자, 거래 검증, 잔액 계산—LLM은 의미를 이해하고 추론하는 데는 탁월하지만, 수학적으로 정확한 답을 반복 재현하는 일에는 본질적으로 확률적입니다. 결과는 예상대로 대규모 검증 오류였습니다.

성공한 팀의 패턴은 명확했습니다. LLM은 의도 파악과 추론에만 쓰고, 그 결과를 엄격한 JSON 스키마로 받아 검증한 뒤, 실제 계산과 DB 쓰기는 전통적인 결정론적 코드에 넘겼습니다. AI가 생각하고, 코드가 실행하는 구조입니다. “AI가 할 수 있는 일”과 “AI에게 맡겨도 되는 일”은 다릅니다.

하나의 거대한 에이전트는 한계가 있다

의도 파악, DB 조회, 스타일 추론을 단일 LLM 하나에게 한꺼번에 시키면 환각과 지연이 동시에 발생합니다. Bake-Off에서 눈에 띈 팀은 이 문제를 마이크로서비스처럼 풀었습니다. 좁은 역할을 가진 전문 서브에이전트들을 병렬로 돌리고, 슈퍼바이저 에이전트가 트래픽을 라우팅하는 구조입니다. 한 팀은 이 방식으로 처리 시간을 1시간에서 10분으로 줄였습니다.

이 구조의 또 다른 장점은 유지보수입니다. 새 모델을 도입하거나 DB 스키마가 바뀌어도 해당 서브에이전트 하나만 수정하면 됩니다. 전체 워크플로를 건드릴 필요가 없습니다.

오늘 만든 에이전트 하네스는 내년에 쓸모없을 수 있다

전자상거래 챌린지에서 한 팀은 가상 피팅 경험을 구현하기 위해 3시간 만에 복잡한 멀티스텝 솔루션을 완성했습니다. 그런데 몇 주 후, 같은 기능이 프롬프트 한 줄로 가능해졌습니다. 모델이 발전한 것입니다.

Google은 이를 ‘에이전트 하네스의 단명(impermanence)’이라고 표현합니다. 복잡하게 구축한 에이전트 구조가 모델 업데이트 한 번에 불필요해질 수 있다는 현실입니다. 이에 대응하는 방법은 하나입니다. 모듈식으로 만들어서, 모델이 따라잡는 순간 해당 코드를 빠르게 걷어낼 수 있게 해두는 것입니다.

텍스트만으로는 부족한 문제들

“파란 청바지를 입으세요”라는 텍스트 추천은 실제 패션 문제를 해결하지 못합니다. 챌린지에서 멀티모달을 후처리로 붙인 팀과 처음부터 네이티브로 통합한 팀의 결과는 달랐습니다. 사용자 사진을 받아 시각적 맥락을 추출하고 이미지 생성까지 이어지는 파이프라인—멀티모달을 부가 기능이 아닌 핵심 입출력으로 설계한 팀이 정확도와 사용자 경험 모두에서 앞섰습니다.

AI 에이전트 개발의 무게중심이 바뀌고 있다

Bake-Off가 보여준 것은 단순한 팁 모음이 아닙니다. LLM과 자연어로 대화하던 시대에서, 에이전트를 소프트웨어 시스템으로 설계하는 시대로의 전환입니다. 프롬프트를 잘 쓰는 것만으로는 충분하지 않고, 역할 분리·모듈화·결정론적 실행이라는 전통적 소프트웨어 원칙이 다시 중심에 섭니다.

성공한 팀들의 공통점은 AI를 마법처럼 다루지 않았다는 점입니다. AI가 잘하는 것에만 쓰고, 나머지는 신뢰할 수 있는 코드에 맡겼습니다. 각 챌린지의 상세한 진행 과정과 팀별 아키텍처는 원문에서 확인할 수 있습니다.