AI는 웹사이트를 빠르게 구축할 수 있습니다. 하지만 출시 후 유지보수는 누가?
AI 웹사이트 빌더는 몇 분 만에 스토어프론트를 생성할 수 있습니다. 하지만 실제 비용은 출시 후에 드러납니다.
더 읽기
한 달 동안 에이전트 아키텍처를 설계했다. 결국 가장 단순한 것이 이겼다.
Foundax Agent를 개발하면서 계속 떠오르는 터무니없는 순간이 있다.
우리는 정말 많은 아키텍처를 시도했다. 고정 workflow. 디렉터리 기반 도구 탐색. 스킬 기반 도구 추천. 런타임 검색. 정규식 매칭. 구조화된 플랜. 멀티라운드 ReAct 루프. 한때는 embedding 기반 검색까지 진지하게 고려했다.
각 버전은 문서상으로는 말이 되었다.
도구가 너무 많으니 필터링해야 한다. 모델이 놓치는 부분이 있으니 제약을 걸어야 한다. 컨텍스트가 너무 기니 검색으로 줄여야 한다. 실행은 안전해야 하니 절차화해야 한다. 비즈니스 정밀도는 원자화된 하위 도구를 요구한다.
개별적으로 보면, 이 판단들 중 어느 것도 틀리지 않았다.
하지만 결국 우리는 가장 단순한——거의 원시적인——테스트를 실행했다. 모든 도구를 가벼운 언어화 카탈로그로 압축하고, 그대로 모델에 던져서, 스스로 읽고 선택하게 했다.
결과는 놀라울 정도로 좋았다.
정말 할 말을 잃었다.
왜냐하면 그동안의 복잡한 설계 대부분이 모델의 역량을 해방하는 게 아니라, "모델이 실패할 것"이라고 미리 가정하고 아키텍처라는 레이어로 감싸서 보상하려는 시도에 불과했기 때문이다.
이 글은 "모든 도구를 노출하는 것이 베스트 프랙티스다"라고 말하려는 게 아니다.
내가 정말 말하고 싶은 건 이것이다: 비즈니스 Agent를 만들 때 가장 위험한 건 모델이 충분히 똑똑하지 않다는 점이 아니다. 당신의 도메인에서 모델이 실제로 무엇을 할 수 있는지 테스트하기도 전에, 모델을 위한 우리를 먼저 설계하기 시작한다는 점이다.
Foundax Agent는 챗봇이 아니다
Foundax는 이커머스 SaaS 플랫폼이다.
따라서 Foundax Agent가 다루는 건 일상적인 채팅이나 일반 지식 Q&A가 아니다. 머천트들이 관리 화면에서 실제로 마주하는 운영상의 문제들이다.
머천트들은 이렇게 말하지 않는다:
"상품 variant 읽기 API를 호출해 주세요."
그들이 실제로 말하는 건:
"왜 이 상품이 안 팔리지?"
"스페인어 페이지는 설정됐어?"
"이 상품 Google Shopping에 올릴 수 있어?"
"장바구니에 담는 사람은 많은데 왜 결제까지 안 가지?"
"빠진 SEO 채워 줘."
이 질문들은 자연어처럼 들리지만, 그 뒤에는 전체 비즈니스 시스템이 숨어 있다. 상품, SKU, 재고, 가격, SEO, 번역, 프로모션, 배송, 결제, 체크아웃, 주문, 환불, GMC 피드, 스토어프론트 표시 상태——이 중 어느 하나라도 결과에 영향을 미칠 수 있다.
그래서 Foundax Agent의 목표는 "사람처럼 응답하는 것"이 아니다.
실제로 해야 하는 일은: 머천트의 진짜 의도를 이해하고, 시스템에서 해당 사실을 찾고, 올바른 도구를 선택하고, 필요하면 쓰기를 준비하고, runtime 제약 아래에서 권한·확인·readback 규율에 따라 실행하는 것이다.
사용자 입력은 모호할 수 있다. 하지만 시스템 실행은 정확해야 한다.
이 긴장 관계가 이후 모든 아키텍처 고민의 출발점이다.
원자화의 역설
나는 엔지니어링 완벽주의 성향이 있다.
그래서 Foundax Agent를 설계하기 시작했을 때, 덩어리째 뭉뚱그린 도구를 본능적으로 거부했다.
analyzeProductReadiness라는 도구가 있다고 치자. 겉보기에는 편리하다. 하지만 내부에서 어떤 필드를 읽고 있는가? 어떤 판단 기준을 쓰고 있는가? 권한 경계는 어디인가? 쓰기 후 readback이 가능한가?——이 모든 것이 불투명해진다.
Foundax는 데모가 아니다. 머천트가 "SEO를 고쳐 달라"고 했을 때, 블랙박스 도구가 뒤에서 멋대로 변경을 가하는 건 용납될 수 없다.
그래서 나는 하위 도구의 원자화를 고집했다:
상품 기본 필드 읽기. 상품 variant 읽기. 재고 및 가격 읽기. 상품 SEO 읽기. 상품 번역 읽기. 배송 설정 읽기. 결제 설정 읽기. 특정 필드 쓰기. 특정 locale 콘텐츠 쓰기. 수정 초안 생성. 쓰기 후 readback.
모든 도구는 단일 목적, 깔끔하고, 상호 중복되지 않는다. 정확한 실행, 명확한 권한, 테스트 용이성.
이 판단은 지금도 옳았다고 생각한다.
진짜 문제는 따로 있었다: 하위 도구를 원자화할수록 도구 수는 늘어난다. 도구 수가 늘어날수록 모델이 컨텍스트 안에서 그것들을 이해하고 선택하기가 더 어려워진다.
이게 내가 만난 첫 번째 역설이다.
하위 도구가 시스템 실행에 적합해질수록, 모델의 인지적 인터페이스로는 부적합해진다.
원자화가 잘못된 게 아니다. 잘못은 원자화된 도구 더미를 그대로 모델 앞에 쏟아붓고, 매번 안정적으로 올바른 선택을 해주길 기대한 것이다.
1.0: 고정 workflow——안정적이지만, 금방 멍청해진다
도구 선택 문제를 해결하기 위해, 우리가 처음 시도한 건 고정 workflow였다.
이건 아주 자연스러운 발상이었다. 머천트의 고빈도 작업은 유한하니까, 흔한 작업들을 미리 스크립팅해 두는 거다.
예를 들어: 상품 SEO 점검. 번역 커버리지 점검. 상품 런칭 readiness 점검. 낮은 전환율 진단. GMC readiness 점검.
모델의 역할은 사용자 의도를 식별하고, 해당 workflow에 매핑한 다음, runtime에 넘겨 고정 실행하는 것이다.
이 방식은 안전해 보였다. 엔지니어링적으로도 그럴듯했다.
하지만 테스트해 보니, 금방 멍청한 키워드 시스템으로 전락했다.
사용자 표현은 너무나 다양하기 때문이다. 똑같이 "상품 SEO를 점검하고 싶다"는 의도여도, 누군가는 "SEO 다 됐나?"라고 말하고, 누군가는 "이 페이지 Google에 인덱싱되나?"라고 말하고, 누군가는 "상품 제목 잘못 썼나?"라고 말하고, 누군가는 "광고 돌릴 때마다 피드가 왜 에러 나지?"라고 말한다.
모든 변형을 태스크에 매핑하려면 키워드, 별칭, 규칙을 계속 추가해야 한다. 결국 시스템은 부정확해지고, 유지보수는 갈수록 어려워진다.
더 중요한 건, 모델에게 거의 운용의 여지가 없었다는 점이다. 모델은 그저 의도 분류기일 뿐이었다. 실제 분석 경로, 도구 선택, 증거 수집 순서——전부 우리가 미리 정해 놓은 것.
그때 깨달았다:
모든 태스크가 사전에 workflow로 스크립팅되어 있다면, 그건 더 이상 Agent가 아니다——AI 탈을 쓴 workflow 도구일 뿐이다.
고정 workflow의 본질은, 모델의 추론을 인간의 비즈니스 열거로 대체하는 것이다. 시스템은 더 통제 가능해지지만, Agent에게서 Agency를 박탈한다.
2.0: 디렉터리 탐색——정확하지만, 참을 수 없이 느리다
다음으로 방향을 바꿨다.
모든 도구를 한 번에 던지는 대신, 디렉터리로 정리한다. 모델이 먼저 비즈니스 도메인을 고르고, 그다음 서브디렉터리를 펼치고, 그 후에 특정 도구를 선택한다.
상품. 주문. 결제. 배송. 프로모션. 분석. GMC.
"상품" 아래에는: 기본 정보, SKU, 재고, 가격, SEO, 번역.
이건 고정 workflow보다 훨씬 정확했다. 모델이 키워드를 사전 정의된 경로에 매칭하는 게 아니라, 구조화된 도구 지도를 탐색하고 있었다. 실제로 올바른 도구를 찾는 빈도가 분명히 높아졌다.
하지만 문제는 명백했다: 속도다.
모든 태스크가 디렉터리 순회를 필요로 했다. 간단한 질문조차 탐색 체인을 거쳐야 했다. 토큰 소비는 높았고, 레이턴시는 컸다.
머천트가 "이 상품의 SEO는 다 갖춰져 있나요?"라고 물으면, Agent는 두꺼운 관리자 매뉴얼을 한 장 한 장 넘기고 있는 것처럼 행동한다.
디렉터리 탐색이 방향성 자체는 틀리지 않았다. 문제는 "도구 체계에 대한 이해"를 호출마다의 비용으로 바꿔버렸다는 점이다. 모델이 매번 처음부터 시스템을 다시 탐색해야 했고, 이는 제품 경험으로 받아들이기 어렵다.
3.0: 의도 분해 + runtime 검색——드디어 아키텍처다워진다
다음으로, 더 정교한 것을 구축했다.
모델이 먼저 사용자 프롬프트의 구조화된 이해를 생성한다: 의도 분해, 키워드, 관련 비즈니스 도메인, 태스크가 읽기·쓰기·혼합·불명 중 무엇인지.
그다음 이 플랜이 runtime으로 전달된다. runtime은 스킬, 정규식 매칭, 도구 메타데이터를 사용하여 후보 도구를 검색한다. 모델은 후보 중에서 선택한다. 사실을 읽은 후, 모델은 다른 라운드에서 탐색을 계속할지 여부를 결정할 수 있다.
이 버전은 성숙한 Agent Runtime처럼 보였다. 그리고 실제로 몇 가지 진전을 이루었다.
예를 들어, 구조화된 필드가 모델 동작을 개선할 수 있다는 걸 발견했다. 모델이 후보 목록을 전부 읽지 않고 처음 보이는 "그럴듯한" 도구에 달려드는 것을 방지하기 위해, hasreadalltools 같은 필드를 설계했다——도구 호출 전에 모든 후보를 다 읽었는지 명시적으로 선언하도록 모델에 요구하는 것이다. 이건 실제로 도움이 되었다.
하지만 더 흥미로웠던 건, 나중에 발견한 사실이다: 단일의, 잘 쓰인 자연어 지시문이 복잡한 구조화 필드보다 더 효과적일 수 있다.
모델이 도구를 선택하기 전에, 우리는 이렇게 추가했다:
"사용자의 비즈니스 목표에 기반하여, 필요한 모든 분석 도구와 쓰기 도구를 선택하라. 처음 보이는 그럴듯한 도구만 고르지 마라."
모델이 답변을 출력하려 하기 전에, 우리는 이렇게 추가했다:
"성급하게 답하지 마라. 먼저 필요한 사실이 다 모였는지 판단하라. 모자라면 도구 선택을 계속하라."
이 단순한 프롬프트들이 모델의 추론 깊이를 현저하게 개선했다.
이건 큰 경종이었다:
LLM은 전통적인 프로그램이 아니다. 구조화된 프로토콜은 유용하지만, 모델은 항상 언어를 읽고 추론을 모방한다. 종종 하나의 정확하고, 직접적이고, 모호함이 적은 자연어 지시문이 복잡한 구조화 필드보다 더 효과적으로 작동한다.
하지만 이 아키텍처는 더 깊은 문제도 드러냈다.
runtime 도구 검색은 컨텍스트 과부하와 부정확한 도구 선택을 해결하기 위해 설계되었다. 하지만 runtime은 본질적으로 규칙 시스템이다.
정규식이든, 스킬이든, 키워드든, 도메인 필터링이든——첫 패스에서 모델이 진짜 필요로 하는 도구를 걸러내 버릴 수 있다.
머천트가 "왜 이 상품이 안 팔리지?"라고 묻는 경우를 생각해 보자.
이 질문은 분석과 관련될 수 있다. 동시에 상품 콘텐츠, 가격, 재고, 프로모션, 배송, 결제, 체크아웃, 트래픽 소스, 지역, 기기, SEO, 페이지 카피 진정성과도 관련될 수 있다.
runtime이 너무 성급하게 단일 도메인으로 버킷팅해 버리면, 모델의 시야는 제한된다.
이게 세 번째 역설이다:
runtime 도구 검색은 컨텍스트를 절약한다——하지만 동시에 모델 시야의 천장이 될 수도 있다.
우리는 모델의 부담을 줄이려다, 결과적으로 모델의 판단을 제한할 뻔한 상황에 이르렀다.
Embedding이라는 우회로——거의 빠질 뻔했다
도구 수가 늘어나면서, 나는 embedding 기반 검색을 진지하게 고려했다.
발상은 자연스럽다. 사용자 프롬프트 → 벡터. 도구 설명 → 벡터. 유사도 점수. Top-k를 모델에 전달.
표준적으로 들린다. "AI 네이티브"처럼 들린다.
하지만 생각할수록, 이건 뭔가 잘못된 방향이라는 느낌이 들었다.
광고 검색, 콘텐츠 추천, 대규모 문서 검색이라면 embedding은 타당하다. 후보 세트가 방대하고, 전통적인 시스템은 진정으로 언어를 이해할 수 없다. 의미를 벡터로 압축해서 근사 매칭해야 하는 거다.
하지만 Foundax의 도구들은, 오픈 월드의 수백만 개 미지의 문서가 아니다. 그것들은 유한하고, 열거 가능하고, 기술 가능하고, 압축 가능한, 우리 자신의 시스템 내 비즈니스 역량이다.
그리고 LLM의 최대 강점은 바로 언어를 읽고, 언어를 이해하고, 의미를 비교하고, 의도를 판단하는 것이다.
그런데 왜 도구 설명을 벡터로 변환하고, 유사도 점수로——모델을 대신해서——모델이 무엇을 볼지 결정하는가?
완벽하게 읽을 수 있는 목차가 있는 책을 앞에 두고, 목차를 숫자로 인코딩한 후, 독자에게 수치적 거리로 어떤 장을 읽을지 판단하게 하는 것과 같다.
전통적인 검색 시스템에서는 그게 말이 된다. LLM 네이티브 Agent에서는, 점점 더 그건 우회로라고 확신한다.
Foundax 같은 비즈니스 Agent에게 우선순위는 벡터 검색이 아니다. 언어 압축이다——도구, 문서, 역량, 경계를, 모델이 직접 읽을 수 있는 명확하고 정확하며 고밀도의 언어적 컨텍스트로 압축하는 것.
풀 스키마 문제
우리는 또 다른 고전적인 문제에도 부딪혔다: 도구 노출이 너무 무거웠다.
초기에는 각 도구가 극도로 완전한 정보를 모델에 노출했다: 함수명, 긴 설명, 팩트 범위, 답변 경계, 제외 소스, 필드 열거형, 상세도 열거형, 인자 설명, observation 반환 형식.
엄격해 보인다.
하지만 나는 결국 깨달았다: 모델은 이 정보의 대부분을 알 필요가 없다.
실제 쿼리 실행, 필드 검증, 권한 체크, 오너 executor 경계, 확인 플로우, readback이 모두 runtime에 의해 처리된다면, 모델이 매번 전체 API 스키마를 읽어야 할 이유가 없다.
모델이 실제로 알아야 할 것은:
- 이 도구가 대략 무엇을 조회할 수 있는지.
- 어떤 비즈니스 팩트에 대응하는지.
- 언제 관련성이 있을지.
- 선택에 사용할 ID는 무엇인지.
예를 들어:
- Read: [12] 상품 Variant — SKU / 가격 / 재고 / 판매 가능 상태
- Read: [13] 상품 SEO — 제목 / 설명 / 키워드
- Search: [21] 상품 검색 — 이름 / 핸들 / 쿼리로 상품 찾기
- Write: [42] 상품 SEO 초안 — SEO 제목 / 설명 변경 준비
이걸로 충분하다.
후보 목록의 "Read / Write / Search" 접두사만으로도 모델이 액션 타입을 구분하기에 충분하다. 실제 읽기/쓰기 권한, 확인 플로우, 오너 executor 경계——이것들은 runtime 내부에 머물러야 하며, 실행 시점에 강제되어야 한다. 모델이 읽도록 토큰을 소비하지 마라. 그리고 절대로, 모델이 자발적으로 준수할 것이라고 의존하지 마라.
여기서의 결론:
스키마는 runtime을 위한 것이지, 모델을 위한 것이 아니다. 모델이 봐야 할 것은 언어화된 역량 카탈로그다, API 사전이 아니다.
4.0: 언어화 카탈로그——모델이 읽게 하라
마침내, 가장 단순한 테스트를 실행했다.
모든 도구를 극도로 압축된 언어적 설명으로 모델에 노출한다. 모델이 읽게 한다. 모델이 선택하게 한다.
결과는 놀라울 정도로 좋았다.
솔직히 말해서, 이 결과는 약간 뺨을 맞는 기분이었다. 왜냐하면 그전까지 구축한 모든 복잡한 아키텍처는 하나의 가정에 고정되어 있었기 때문이다: 모델은 너무 많은 도구를 보면 처리할 수 없다, 그러니 runtime이 필터링해야 한다.
하지만 테스트는 이 가정이——적어도 Foundax의 현재 컨텍스트에서는——완전히 성립하지 않는다는 것을 보여주었다.
질문은 "모든 도구를 노출할 수 있는가"가 아니다. 질문은 "도대체 모델에게 무엇을 노출하고 있는가"다.
만약 완전한 API 스키마의 벽——긴 설명, 필드 열거형, 파라미터 사양——을 노출하고 있다면, 확실히 모델을 익사시킬 것이다. 하지만 가볍고 명확한 언어화 역량 카탈로그를 노출하고 있다면, 모델은 스스로 읽고 스스로 선택할 수 있다——그리고 runtime의 사전 필터링보다 더 나은 결과를 낼 수 있다.
이건 초기의 원시적인 전면 노출로 돌아가는 게 아니다.
초기에는: 전체 API 사전을 모델에게 던져주는 것이었다.
최종형은: 압축된 운영 매뉴얼을 모델에게 건네는 것이다——가볍고, 번호가 매겨진, 언어화된 역량 메뉴.
이 둘은 완전히 다른 것이다. 전자는 도구의 바다. 후자는 읽을 수 있는 지도.
구체적으로 말하자면, 우리 시스템에는 수십 개의 읽기 도구와 쓰기 명령——총 백 개가 넘는 정식 도구가 존재한다. 각 태스크에서 노출되는 도구는 기껏해야 열 몇 개로, 노출 예산에 의해 제어된다. toolselection 단계의 컨텍스트 버짓은 수만 자 정도. 각 도구의 스키마 설명은 천수백 자(수백 토큰) 정도. 열 몇 개의 도구를 노출하면 대략 만이만 자——약 사천오천 토큰. 충분히 관리 가능하다.
하지만 모든 도구를 풀 스키마로 노출한다면? 그건 거의 이십만 자——약 오만 토큰. 그건 정말로 들어가지 않는다.
핵심 인사이트: runtime은 정식 레지스트리로부터 컴팩트하고 번호가 매겨진 도구 시그니처를 제공한다. 모델이 읽는 건 백과사전 항목이 아니라, 인덱스 카드다.
runtime은 여전히 극도로 중요하다
이건 오해되기 쉽다.
"모델이 읽고 선택하게 한다"는 것은 runtime이 중요하지 않다는 뜻인가?
정반대다.
runtime은 여전히 결정적으로 중요하다——다만, 시기상조로 모델을 대신해 생각하려고 해서는 안 된다는 것이다.
모델의 책임은: 이해하고, 판단하고, 선택하고, 설명하는 것.
runtime의 책임은: 권한, 확인, 필드 검증, 오너 executor 경계, 실제 실행, readback.
특히 쓰기 작업에 관해서: 모델이 자발적으로 규칙을 따를 것이라고 절대로 의존해서는 안 된다.
모델은 "이 상품의 SEO를 업데이트하고 싶다"고 말할 수 있다.
하지만 runtime이 판단해야 한다: 현재 사용자에게 권한이 있는가? 이 액션에 확인이 필요한가? 먼저 초안만 생성해야 하는가? 필드가 허용 목록에 있는가? 객체가 현재 머천트에게 속하는가? 쓰기가 실제로 성공했는가? readback 후, 비즈니스 상태가 정말 목표와 일치하는가?
Agent의 목표는 도구 호출이 성공했음을 증명하는 것이 아니다. 비즈니스 결과가 성립함을 증명하는 것이다.
이 경계는 본질적이다. 모든 것이 모델로 가는 것도 아니고, 모든 것이 runtime으로 가는 것도 아니다. 진짜 질문은 분업이다.
가장 큰 교훈: 설계하기 전에 테스트하라
이 여정에서 얻은 가장 큰 수확은 4.0이 결정적으로 최고의 아키텍처라는 게 아니다.
그건 Agent를 구축할 때, 현실의 엔지니어링적 우려의 연쇄에 휩쓸리는 것이 위험할 정도로 쉽다는 점이다.
고빈도 태스크를 모델의 즉흥에 맡기면 불안정하지 않을까? → 고정 workflow를 구축하자.
컨텍스트가 너무 길어서 모델의 주의력이 분산되지 않을까? → 디렉터리 탐색을 구축하자.
도구 수가 늘어서 토큰이 폭발하지 않을까? → runtime 검색을 구축하자.
키워드 기반 검색이 다국어·크로스 도메인 태스크에 너무 취약하지 않을까? → embedding, 스코어링, 리랭킹을 고려하자.
모델이 전체 목록을 읽지 않고 도구를 고르거나, 사실이 다 모이기 전에 답변을 출력하지 않을까? → 구조화 제약 필드를 추가하자.
이 우려들 중 어느 것도 상상의 산물이 아니다. 모두 실제 문제에 대응한다.
우리는 그저——혹독하게——많은 해결책이 하나의 문제를 해결하면서 다른 문제를 끌어들인다는 걸 배웠을 뿐이다.
고정 workflow는 안정성을 더했지만 모델 추론에 상한을 걸었다. 디렉터리 탐색은 정확했지만 느리고 토큰 소비가 컸다. runtime 검색은 컨텍스트를 절약했지만 모델에게 필요한 도구를 차단할 수 있었다. embedding은 똑똑해 보였지만, LLM 네이티브 도구 선택에 있어서는 아마도 우회로였다. 구조화 필드는 모델을 제약할 수 있었지만, 때로는 자연어 프롬프트가 더 잘 작동했다.
그리고 더 결정적인 깨달음:
이 문제들은 실재하지만, 당신의 프로젝트에서 반드시 똑같은 심각도로 나타나지는 않는다.
긴 컨텍스트가 실제로 당신의 유스케이스에서 주의력 분산을 일으키는가? 테스트하라. 도구 수가 실제로 토큰 비용을 수용 불가능하게 만드는가? 테스트하라. 전체 도구 노출이 실제로 모델을 게으르게, 경로 의존적으로, 오류 경향적으로 만드는가? 테스트하라. runtime 검색이 실제로 모델이 필요로 하는 도구를 차단하는가? 그것도 테스트하라.
Agent 아키텍처에서 가장 저지르기 쉬운 실수는, "누군가의 프로젝트에서 실제로 존재하는 문제"를 "내 프로젝트에서도 확실히 존재하는 문제"로 취급하는 것이다.
그러므로 Agent 구축의 첫 단계는, 발생 가능한 모든 문제를 선제적으로 방어하기 위한 복잡한 아키텍처를 설계하는 게 아니다. 테스트하는 것이다:
모델이 당신의 도메인에서 실제로 무엇을 이해할 수 있는가? 도구 설명을 읽을 수 있는가? 스스로 도구를 선택할 수 있는가? 어디에서 사실을 놓치는가? 어떤 판단을 모델에 맡길 수 있는가? 어떤 것은 runtime이 강제해야 하는가? 어떤 액션에 사용자 확인이 필요한가? 어떤 결과를 readback해야 하는가?
이 질문들에 대한 답이——블로그 포스트의 레퍼런스 아키텍처가 아니라——당신의 Agent 설계를 결정해야 한다.
Foundax에 관해서는, 이제 명확해졌다: 이커머스 운영은 모델이 잘 아는 도메인이다. 전환 퍼널, 상품 페이지, 가격, 배송, 프로모션, 결제, 트래픽 품질, SEO——이 분석 프레임워크는 훈련 데이터에 무수히 등장한다. 모델에게 비즈니스 분석 본능이 부족한 게 아니다. 부족한 것은 Foundax의 특정 시스템에 대한 지식이다: 어떤 사실을 읽을 수 있는지, 어떤 쓰기를 준비할 수 있는지, 어떤 액션을 runtime이 소유해야 하는지, 어떤 결과를 readback해야 하는지.
따라서 Foundax Agent의 본질은, 모델에게 이커머스 분석 방법을 가르치는 게 아니다. 모델에게 Foundax의 비즈니스 역량을, 모델이 읽을 수 있는 언어로 건네는 것이다.
비즈니스 Agent 구축의 첫 단계는 완벽한 아키텍처를 설계하는 게 아니다. 모델을 실제로 어디까지 신뢰할 수 있는지 테스트하는 것이다.
이것은 우리만의 이야기가 아니다
이러한 결론에 도달한 것은 우리만이 아니다.
2024년 12월, Anthropic은 가이드 "Building Effective Agents"를 발표했다. 그 핵심 메시지: 단순함이 승리한다. 가능한 한 가장 단순한 솔루션으로 시작하라. 도구 접근이 있는 증강된 LLM만으로 충분할 수 있다. 당시에 읽었을 때는 고개를 끄덕였을 뿐이었다. 위에서 서술한 내용을 직접 겪은 지금은, 그것을 뼛속 깊이 이해한다.
그리고 2026년 5월, LangChain은 Interrupt 컨퍼런스에서 주목할 만한 피벗을 보여주었다: 테마가 '에이전트가 프로덕션에 갈 수 있는가'에서 '엔터프라이즈 스케일과 프로덕션 운영'으로 이동했다. 그들의 자료가 강조하는 진짜 병목은 에이전트를 작성하는 것이 아니다——스케일에서 프로덕션으로 관리하는 것이다.
증가하는 연구들이 이 방향을 뒷받침한다. Google DeepMind의 2025년 embedding 한계에 관한 연구는, 고정 크기 벡터 임베딩이 스케일에서 구조적·관계적 정보를 손실한다는 것을 수학적으로 보여주었다——embedding 기반 도구 검색을 고려하는 이들에게 직접적으로 관련된 내용이다. Neo4j의 "컨텍스트 엔지니어링" 개념은, 신뢰할 수 있는 AI는 교묘한 프롬프트 표현이 아니라 아키텍처에서 나온다고 주장한다.
우리의 경험은 업계 전반에서 보이는 방향과 일치한다: Anthropic의 단순/조합 가능 패턴, LangChain의 프레임워크 추상화보다 프로덕션 운영을 중시하는 태도. 기성 스캐폴딩을 줄이고, 모델의 직접적 역량을 늘리는 것——하지만 항상 실제 사용에서 검증하고, 교리로 채택하지 않는 것. 사전 필터링을 줄이고, 모델의 판단을 늘리는 것. 물어야 할 것은 "모델 주위에 완벽한 아키텍처를 어떻게 구축할까"가 아니다. "모델이 실제로 필요로 하는 것을 어떻게 주고, 그 길을 어떻게 방해하지 않을까"이다.
이것이 Foundax의 결론을 보편적으로 만드는 것은 아니다. 다른 비즈니스, 다른 모델, 다른 도구 서피스는 다른 답에 도달할 것이다. 보편적인 것은 방법론이다: 먼저 테스트하고, 그다음에 설계하라.
FAQ
Q: 이 말은 모든 도구를 항상 모델에 노출해야 한다는 뜻인가요?
아닙니다. 도구 수, 모델, 컨텍스트 버짓, 도메인에 따라 다릅니다. 포인트는 "항상 모든 것을 노출하라"가 아닙니다. 포인트는: 필터링하기 전에 테스트하라, 입니다. 모델이 처리하지 못할 것이라고 가정하지 말고——검증하세요. 우리 케이스에서는 태스크당 열 몇 개의 압축된 도구 시그니처가 관리 가능하고 효과적이었습니다. 당신의 숫자는 다를 수 있습니다.
Q: 그렇다면 언제 고정 workflow를 사용해야 하나요?
태스크가 진정으로 결정적이고, 오류의 위험이 치명적이며, 해당 도메인에서 모델의 배경 지식이 약할 때입니다. workflow가 잘못된 게 아닙니다——모델이 할 수 있었을 추론을 대체할 때 잘못된 것입니다. 안전 가드레일과 결정적 포스트 프로세싱에 사용하고, 모델 판단의 대체재로 사용하지 마세요.
Q: 언어화 카탈로그와 API 스키마의 차이는 무엇인가요?
언어화 카탈로그는 도구가 무엇을 할 수 있는지를 압축된 자연어로 모델에 전달합니다——예: "Read: [12] 상품 Variant — SKU / 가격 / 재고 / 판매 가능 상태". API 스키마는 도구를 어떻게 호출하는지를 전체 파라미터 사양, 열거형, 제약과 함께 모델에 전달합니다. 모델에게 필요한 건 역량 메뉴입니다. runtime에 필요한 건 기술 매뉴얼입니다. 이 둘을 섞는 것은 가장 비싼 실수 중 하나입니다.
Q: 모델과 runtime의 담당 영역을 어떻게 나누나요?
좋은 휴리스틱: 모델은 이해, 판단, 선택, 설명을 담당한다. runtime은 권한, 실행, 확인, 검증, readback을 담당한다. 모델에게 규칙 집행을 요구하고 있다면, 선의 잘못된 쪽에 서 있는 것입니다. 모델은 제안하고, runtime이 결정하고 실행한다.
Q: 비용은 어떤가요? 더 많은 도구를 노출하면 토큰 사용량이 늘지 않나요?
우리 케이스에서는, 압축된 언어화 카탈로그가 실제로 멀티라운드 디렉터리 탐색이나 검색 체인보다 저렴했습니다. 각 도구 항목은 천수백 자 정도입니다. 태스크당 열 몇 개의 도구를 노출하면 총 만이만 자——약 사천오천 토큰입니다. 이를 여러 라운드의 의도 분해, 검색, 후보 리뷰, 재선택과 비교해 보세요. 단순한 접근이 토큰 효율이 더 좋은 경우가 많았습니다.
Q: 이 과정에서 얻은 가장 중요한 단일 인사이트는 무엇인가요?
"모델을 돕는 것"과 "모델을 제약하는 것"은 설계자의 관점에서는 동일해 보이지만, 시스템에 대해서는 정반대의 효과를 가진다는 것입니다. 우리가 구축한 모든 아키텍처는 돕기 위한 것이었습니다. 대부분은 결과적으로 제약하는 것이 되었습니다. 그 차이는 테스트를 통해서만 분명해졌습니다. 이 글에서 단 하나만 가져간다면, 이것으로 하세요: 모델이 실제로 무엇을 할 수 있는지 테스트한 후에, 할 수 없다고 가정한 것을 보상하기 위한 아키텍처를 설계하기 시작하라.
Related Reading
References
- Anthropic — Building Effective Agents (Dec 2024)
- LangChain Interrupt 2026: The Platform Pivot
- Google DeepMind — On the Theoretical Limitations of Embedding-Based Retrieval (Aug 2025)
- Neo4j — Context Engineering: Beyond Prompt Engineering (Jan 2026)
- Foundax 살펴보기 — 이 Agent 아키텍처들이 구축되고 테스트된 이커머스 SaaS 플랫폼입니다.