앤스로픽, 커머스 에이전트 청사진 오픈소스 공개

쇼핑 에이전트는 고객이 말로 물어보는 것을 받아요. 카탈로그를 검색하고 여러 상품을 비교해 화면에 띄우고, 장바구니를 채우고, 주문 상태나 반품 규정 같은 질문에 답해요. 여기에 다섯 개의 스킬이 붙어요 — 검색·발견, 구매 조사, 계획 세우기, 고객 응대, 기억과 개인화예요.

판매자 에이전트는 가게 쪽 화면에서 돌아요. 매출을 분석하고 재고를 추적하고 가격과 프로모션을 제안하고 마케팅 캠페인 초안을 써요. 이쪽 스킬도 다섯 개로 성과 분석, 카탈로그 관리, 재고 운영, 가격·프로모션, 마케팅 캠페인이에요.

무엇을 시스템 프롬프트에 넣고 무엇을 스킬로 뺄지는 규칙이 하나예요. 전체 대화의 3분의 1쯤에 해당하는 일은 프롬프트에 상주시키고, 나머지 긴 꼬리는 스킬로 내려요.

구조에서 눈에 띄는 대목은 앞에 인텐트 분류기가 없다는 점이에요. 대화를 잘라 부서별 전문 에이전트로 넘기는 방식 대신, 모델 하나가 표준 에이전트 루프를 돌면서 필요한 스킬만 꺼내 써요. 민원실로 옮겨 보면 차이가 분명해져요. 창구에서 용건을 듣고 "그건 3층 가세요"라며 넘기는 방식이 인텐트 라우터라면, 이 설계는 안내 데스크 직원 한 명이 끝까지 붙어 필요할 때마다 서류철을 꺼내 오는 방식이에요.

화면을 그리는 방식도 같은 결이에요. 모델이 마크업을 직접 쓰지 않고 present_products나 present_itinerary 같은 도구를 호출하면, 서버가 인자를 검증하고 살을 붙여 화면을 만들어요. 도구 결과는 필요한 필드만 남기고 잘라서 넘겨요 — 이미지 주소 같은 건 아예 지워요.

모델은 돈을 움직이지 못해요

가장 공들인 자리는 매출이 아니라 제동 장치예요. 앤스로픽은 "모델의 어떤 도구 호출도 돈을 움직이거나 사업을 바꾸지 않는다"는 문장을 설계 원칙으로 내걸었어요.

방식은 세 겹이에요. 첫째, 실행 대신 대기예요. 결제는 장바구니와 버튼을 화면에 그리는 데서 끝나고, 판매자 쪽 가격 변경이나 캠페인 시작은 승인 대기 상태로 쌓여요. 담당자가 포털에서 버튼을 누르거나 CLI에서 확인해야 실제로 적용돼요.

둘째, 서버가 발급한 ID만 받아요. 세션마다 모델에게 돌려준 ID를 서버가 전부 기록해 두고, 모델이 지어낸 ID나 사용자가 붙여넣은 ID, 리뷰에 심어 놓은 ID는 백엔드에 닿기 전에 잘라내요.

셋째, 수수료와 고지 문구, 규제 문구는 승인된 카피에서만 나와요. 모델이 문장을 새로 만들지 못하고, 판매자 에이전트도 가격 조건 같은 보호 필드는 건드리지 못해요.

한도를 거는 자리도 다르게 잡았어요. 요청이 아니라 결과 상태에 한도를 적용하고, 한 세션 안의 쓰기는 순서대로 한 줄로 세워요. 도구 호출을 병렬로 여러 개 던져 한도를 우회하는 길을 막으려는 설계예요.

기억은 메모장이 아니라 표에 쌓아요

장기 기억을 마크다운 프로필로 두지 않고 데이터베이스에 타입이 있는 레코드로 넣은 것도 특징이에요. 사실 하나가 키, 값, 분류, 출처 세션으로 쪼개져 한 줄이 돼요.

기억을 쓰는 시점은 턴이 끝난 뒤 비동기예요. 응답을 기다리게 하지 않으려는 선택이고, 추출기는 대화 텍스트만 읽고 도구 결과는 보지 않아요. 상품 설명이 사용자의 취향으로 둔갑하는 사고를 막기 위해서인데, 앤스로픽은 이 방식으로 내부 시험에서 사실 회상률이 13% 올랐다고 밝혔어요.

읽는 쪽은 세 층이에요. 기본 매장이나 배송 선호처럼 늘 붙어 있는 값, 신발을 찾을 때의 사이즈처럼 턴마다 미리 가져오는 값, 그 밖에는 조회 도구로 그때그때 찾는 값이에요.

15분과 한 시간

앤스로픽은 클로드로 쇼핑 에이전트를 돌린 소매업체에서 장바구니가 최대 35% 커지고 구매를 끝내는 비율이 60% 높아졌다고 밝혔어요. 도입 속도를 두고는 고객사 발언을 인용했어요. 윅스의 커머스 총괄 드로르 잘리카는 "우리 엔지니어들이 15분 만에 프롬프트를 받는 커머스 에이전트를 띄웠다"고 했고, 페치의 스태프 프로덕트 매니저 애슐리 네이더는 "청사진의 두 에이전트를 한 시간이 채 안 되어 로컬에서 돌렸고 실제 대화가 첫 시도에 됐다"고 했어요.

엔지니어링 문서에는 운영 수치도 함께 실렸어요. 배포 사례의 캐시 적중률은 90~99%였고, 캐시된 토큰은 새로 읽는 토큰의 10분의 1 비용에 1.5~2배 빠르게 처리돼요. 작업 하나는 보통 모델 턴 3~5회 안에 끝나고, 커머스 응답의 출력 길이는 500~700 토큰 언저리예요. 평가셋은 사용자 흐름마다 50~100 케이스에서 시작하라고 권했어요.

실행 경로는 세 갈래예요. 메시지 API로 도는 참조 루프, 클로드 에이전트 SDK, 그리고 베타인 매니지드 에이전트예요. 여기에 스캐폴딩용 클로드 코드 플러그인이 딸려 있어요. 배포처로는 클로드 API와 아마존 베드록, 마이크로소프트 파운드리, 구글 클라우드 버텍스 AI를 들었어요.

에디터의 시선

이 발표를 읽으면서 계속 걸린 것은 성과 수치가 아니라 저장소의 디렉터리 이름이었어요. docs/safety.md, gates, guardrails, 승인 콘솔 — 커머스 에이전트를 만들어 보겠다고 앉으면 대개 마지막에 붙이고 자주 빼먹는 것들이 처음부터 폴더 이름으로 박혀 있어요.

청사진의 무게가 여기 있어요. 데모를 만드는 법이 아니라, 데모를 남의 돈이 오가는 자리에 올려도 되는 상태로 만드는 법을 적어 놓은 거예요.

에이전트를 붙여 본 팀이라면 어디서 무너지는지 알아요. 잘 돌던 데모가 실서비스에서 처음 사고를 내는 지점은 거의 언제나 모델이 없는 상품 코드를 지어내거나, 어디선가 주워 온 ID로 남의 주문을 건드리는 자리예요. 서버가 발급한 ID만 받는다는 규칙 한 줄이 그 사고를 통째로 막아요.

국내 커머스 회사들이 지금 붙잡고 있는 문제와도 정확히 겹쳐요. 상품 검색과 상담 챗봇을 붙이는 일은 이미 여러 곳이 해봤고, 대부분 "말은 잘하는데 결제까지는 못 맡기겠다"에서 멈춰 있어요.

그 마지막 한 칸을 넘기는 방법이 더 똑똑한 모델이 아니라 모델에게서 실행 권한을 빼앗는 설계라는 것이 이번 코드의 답이에요. 결제는 모델이 누르지 않고 사람이 버튼을 눌러요. 판매자 화면의 가격 변경은 승인함에 쌓여요. 이 구조라면 사고의 최대치가 "이상한 제안이 승인함에 하나 쌓인다"로 묶여요.

한 가지 더 짚을 것은 기억을 데이터베이스 레코드로 만든 선택이에요. 요즘 에이전트들이 사용자 기억을 마크다운 파일에 문장으로 쌓는데, 커머스에서는 그 방식이 위험해요. 상품 설명 한 줄이 취향으로 굳으면 다음 추천이 통째로 틀어지거든요. 도구 결과를 아예 읽지 않는 추출기를 따로 둔 이유가 그거고, 회상률 13% 개선은 그 격리에서 나온 값이에요.

앤스로픽이 이 시점에 코드를 푼 이유도 분명해요. 미국 소매업이 연말 성수기 준비에 들어가는 9월 초에, 경쟁사보다 먼저 "우리 모델 위에 커머스 에이전트를 지어라"는 표준 배치를 깔아 놓은 거예요. 아파치 2.0에 커넥터를 비워 둔 구조는 누구의 백엔드에도 붙을 수 있다는 뜻이고, 붙는 순간 그 위에서 도는 모델은 클로드가 돼요. 오픈소스로 푼 것은 청사진이고, 파는 것은 그 위에서 돌아갈 토큰이에요.