실무 AI 에이전트 구축 교훈: 플랫 구조·범용 도구·평가 주도 개발(EDD)

핵심 메시지

• 팀마다 서브에이전트를 두자 컨텍스트 공유·핸드오프·인터럽트 문제가 커졌고, 이를 하나의 ‘플랫 에이전트’로 단순화해 성능을 끌어올렸다.
• 도구가 많아질수록 도구 선택이 취약해지므로, 파라미터로 동작을 바꾸는 소수의 범용·조합형 도구를 택했다(유닉스 철학).
• 원본 데이터를 그대로 컨텍스트에 넣지 않고, 스키마와 질의를 주어 LLM이 SQL을 작성·실행하게 하니 환각이 줄고 훨씬 강력했다.
• 어떤 변경이든 결과를 장담할 수 없으므로 평가를 먼저 세우는 ‘평가 주도 개발(EDD)’을 따르며, 통계적 신뢰구간으로 반복 횟수를 정한다.
• 평가는 비용·불확실성·지연의 삼각 트레이드오프로, 세 가지 중 둘만 얻을 수 있다. 커밋마다 도는 스모크 평가와 사전 배포용 헬스 평가로 나눈다.

쉽게 이해하기

Rippling은 급여·복리후생·기기 관리 등 HR 업무를 한데 모은 플랫폼이다. 이 회사는 모든 데이터를 직원 중심으로 엮은 ‘직원 그래프(employee graph)’ 위에 AI 계층을 얹어 Rippling AI를 출시했다. 여러 시스템에 흩어진 답을 직접 찾는 대신, 시스템에 물어보면 답을 주는 경험을 목표로 했다.

아키텍처는 LangGraph 기반이다. 상위 에이전트가 오케스트레이션을 맡고, 이름을 실제 직원 레코드로 잇는 엔티티 해소, 질의에 맞는 도구 선택, 스킬과 SOP로 주입하는 도메인 컨텍스트가 핵심 축이다. 다만 처음부터 이 모습은 아니었다. 첫 교훈은 “에이전트를 플랫하게 유지하라”이다. 팀마다 서브에이전트를 두자 컨텍스트 공유·핸드오프·인터럽트·여러 서브에이전트에 걸친 질의가 뒤엉켰고, 결국 하나의 플랫 에이전트로 합치고 도메인 지식은 선언적 스킬과 SOP로만 주입해 추상화를 걷어냈다.

두 번째 교훈은 범용·조합형 도구다. 팀마다 도구를 만들자 카탈로그가 비대해지고, 잘못된 도구를 고르면 답도 틀렸다. 그래서 여러 개의 데이터 조회 메서드 대신, 직원·기기·세금을 파라미터로 받는 하나의 조회 메서드처럼 단순하게 만들었다. 단순한 도구를 잘 만들고 에이전트가 조합하게 하는 유닉스 철학이다.

세 번째 교훈은 데이터를 컨텍스트에 밀어 넣지 않는 것이다. 원본 데이터를 통째로 넣으면 환각이 생기고, 답이 틀리면 안 되는 급여·복리후생 질의에서는 치명적이다. 대신 데이터의 스키마와 질의만 주고 LLM이 SQL을 작성하게 한 뒤 실제로 실행한다. 데이터 자체는 컨텍스트 창에 들어가지 않으며, SQL은 수많은 맞춤 도구보다 강력했다. 비용이 큰 데이터 조회는 한 번 캐시해 후속 질문에 재사용한다.

마지막 교훈은 평가 주도 개발(EDD)이다. 시스템 프롬프트·도구·스킬을 조금만 바꿔도 LLM의 반응은 장담할 수 없으니, 직관이 아니라 평가가 진실을 말한다. LLM은 확률적이라 한 번 통과했다고 100%가 아니며, 윌슨 신뢰구간으로 보면 1회 중 1회 통과도 95% 신뢰수준에서 실제 성공률이 20%까지 낮을 수 있다. 반복을 늘릴수록 확신이 커지지만, 비용·불확실성·지연이라는 삼각 트레이드오프에서 둘만 얻을 수 있다. Rippling은 커밋마다 도는 소수의 스모크 평가와, 사전 배포 단계에서 더 많이 반복하는 헬스 평가로 나눠 운영한다.

주요 인사이트

• 모델이 강해질수록 에이전트의 ‘접착 코드(glue code)’를 걷어내고 LLM이 스스로 하도록 비켜서는 것이 낫다. 플랫 구조는 사용자가 보는 메시지와 LLM이 보는 것을 일치시켜 성능을 높였다.
• 도구 수가 많을수록 도구 선택 오류의 위험이 커진다. 원자적이고 조합 가능한 범용 도구로 내려갈수록 LLM이 더 많은 일을 해낸다.
• 데이터를 컨텍스트에 넣는 대신 스키마를 노출해 SQL을 쓰게 하면, 환각을 줄이면서도 여러 시스템에 걸친 복잡한 질의를 한 번에 해결할 수 있다.
• 평가 주도 개발은 TDD보다 어렵다. LLM의 확률성 때문에 몇 번의 통과로는 성공률을 확신할 수 없고, 필요한 반복 횟수는 현재 성능·검출하려는 회귀 폭·오탐 허용도에 따라 달라진다.
• 비용·불확실성·지연의 삼각 트레이드오프를 인정하고, 커밋 단위 스모크 평가와 배포 전 헬스 평가로 목적에 맞게 나누는 것이 현실적인 운영 방식이다.

자주 묻는 질문

관련 AI 소식