효과적인 커머스 에이전트 구조 해부 가이드

지난 1년간 우리는 소매, 마켓플레이스, 여행, 엔터테인먼트, 통신 등 커머스 전반의 다양한 팀과 협력해 Claude 기반의 커머스 에이전트를 구축해왔습니다.

이 에이전트들은 현재 실제 서비스에서 운영 중이며, 기업 고객들은 에이전트 도입 후 장바구니 규모 증가와 판매자 운영 효율화를 경험하고 있습니다. 구조도 단순합니다. 에이전트 루프 안에서 스킬(skill), 툴(tool), 그리고 견고한 평가 세트를 갖춘 Claude가 작동하는 방식입니다.

이 글은 커머스 에이전트(또는 그 외 소비자 대면 에이전트)를 구축하는 엔지니어와 엔지니어링 리더를 위해 작성되었습니다. 1부에서는 한 번 결정하면 되는 아키텍처를 다루고, 2부에서는 레이턴시(latency)와 비용을, 3부에서는 메모리, 안전성, 평가, 조직 전반의 협업 방식 등 실제 프로덕션 운영을 다룹니다.

커머스 에이전트란?

커머스 에이전트란 온라인 카탈로그에서의 구매와 판매를 단순화하는 에이전트를 말합니다.

소비자를 대면하는 에이전트는 검색, 비교, 대체 상품 제안, 주문 구성 등을 수행합니다. 소매 장바구니 담기, 여행 일정 구성, 모바일 요금제 변경, 공연 좌석 예약 등이 여기에 해당합니다. 비즈니스를 대면하는 에이전트는 매출 관련 질문에 답하고, 프로모션과 캠페인을 운영하며, 재고와 가격을 관리합니다.

핵심 아키텍처는 표준 에이전트 루프에서 동작하는 모델입니다. 목표를 추론하고, 컨텍스트를 탐색하며, 툴을 통해 행동하고, 스킬로 절차를 익히며, 필요할 때 명확한 질문을 던지고, 결과를 관찰하면서 목표가 달성될 때까지 루프를 이어갑니다.

앞단에 대화를 분류하는 인텐트 라우터도 없고, 뒤에 도메인별 에이전트가 줄지어 있는 구조도 아닙니다.

엔지니어링 컨텍스트

서브에이전트 대신 스킬

커머스 에이전트는 다양한 카테고리와 인텐트에 걸쳐 폭넓은 기능을 커버해야 하기 때문에, 도메인마다 서브에이전트를 하나씩 만들고 싶은 유혹이 생깁니다.

그러나 실제로 이 방식은 최선이 아닙니다. 커머스 대화는 여러 인텐트와 여러 턴에 걸쳐 강하게 결합된 하나의 세션이며, 상당한 공유 컨텍스트를 필요로 하기 때문입니다.

서브에이전트 아키텍처에서는 오케스트레이터가 장바구니나 준비 중인 변경 사항, 사용자 선호도, 대화 이력을 모두 보유합니다.

서브에이전트로 넘어갈 때마다 상태 손실이 발생하며, 이는 서브에이전트 응답의 품질과 전체 응답 품질에 영향을 미칩니다. 게다가 핸드오프(handoff)마다 수 배에 달하는 토큰 비용이 발생하고 레이턴시도 몇 초씩 늘어납니다.

도메인 간 경계가 명확하게 나뉘는 경우도 드뭅니다. 반품 처리 흐름에는 주문 이력, 현재 장바구니, 상품 카탈로그가 모두 필요할 수 있어서, 도메인별 서브에이전트 방식을 택하면 이 접근 권한을 어디서나 중복으로 가져가거나 작업 도중에 핸드오프를 해야 합니다.

모델이 발전할수록 더 긴 컨텍스트, 더 많은 스킬과 툴을 처리할 수 있게 되므로, 현재의 배치 기준 뒤에 있는 제약들은 모델 세대가 바뀔 때마다 완화됩니다.

반면 에이전트 스킬은 핸드오프 비용 없이 도메인별 모듈성과 컨텍스트 제어를 비슷하게 제공합니다. 스킬 지시문이 전체 이력을 이미 보유한 메인 에이전트로 로드되기 때문입니다.

여러 기업 배포 사례를 비교한 결과, 스킬을 갖춘 단일 에이전트는 프롬프트 하나로 모든 것을 처리하는 방식과 서브에이전트 방식 모두를 품질 면에서 일관되게 앞섰으며, 태스크당 비용과 레이턴시 측면에서도 더 유리한 경우가 많았습니다.

서브에이전트가 제 역할을 하는 경우는, 오케스트레이터가 좁고 독립적인 태스크에 대해 전용 컨텍스트 윈도우가 필요한 서브에이전트를 툴처럼 호출할 때입니다.

실제 프로덕션에서 흔히 쓰이는 예로는 딥 리서치 서브에이전트가 있습니다. 서브에이전트가 문서를 검색하고 읽고, 코드를 작성해 실행하며, 데이터 모델을 탐색하고, 막힌 지점에서 방향을 바꾸는 모든 작업이 하나 이상의 서브에이전트 내부에서 이루어지고, 오케스트레이터에는 간결한 답만 돌아옵니다.

또 다른 예외는 해당 도메인에 이미 전용 에이전트가 구축되어 있는 경우입니다. 약국이나 금융 서비스 경험이 자체적인 컴플라이언스 체계를 갖춘 전용 에이전트로 운영되고 있다면, 핸드오프가 올바른 선택일 수 있습니다. 이때 도메인 에이전트가 태스크를 인계받아 자체 루프 안에서 태스크가 완료될 때까지 사용자와 직접 소통합니다.

핵심은 대화의 주도권입니다. 핸드오프는 도메인 에이전트를 사용자의 직접 상대방으로 세우는 반면, 위임은 오케스트레이터가 주도권을 유지한 채 도메인 에이전트를 한 턴 안에서 들락날락하게 하는 구조여서 교환이 이뤄질수록 품질이 떨어집니다.

시스템 프롬프트냐 스킬이냐: 빈도로 결정하라

지시문을 시스템 프롬프트에 넣을지 스킬에 넣을지를 결정하는 주요 기준은 에이전트가 그것을 얼마나 자주 필요로 하느냐입니다. 스킬을 로드하는 데는 모델 턴이 하나 소비되므로, 대부분의 턴에서 필요한 내용은 시스템 프롬프트에 넣는 것이 일반적입니다.

다만 이는 트래픽 분포와 평가 결과에서 드러나는 에이전트 동작 양상에 따라 달라집니다. 출시 전에 예상되었거나 프로덕션에서 관찰된 것을 막론하고, 트래픽의 3분의 1 이상에서 관련성이 있는 내용은 시스템 프롬프트에, 나머지는 스킬에 넣는 것이 좋은 출발점입니다.

이미 보유한 신호, 예를 들어 사용자가 진입한 페이지 등으로 스킬이 예측 가능하다면, 첫 번째 모델 호출 전에 하니스에서 직접 스킬을 주입해 스킬 로드를 위한 추가 턴을 생략하는 것을 권장합니다.

안전 및 법적 규정, 브랜드 제약, 알레르기처럼 사용자에게 중요한 핵심 정보 등 반드시 지켜야 할 지시문은 항상 시스템 프롬프트에 넣습니다.

커머스 에이전트의 경우, 거의 모든 세션에서 상품 검색이 이루어지므로 이는 프롬프트에 두고, 나머지 롱테일 기능들은 스킬로 처리합니다.

우리의 레퍼런스 구현체에서 쇼핑 에이전트의 프롬프트는 그라운딩(grounding), 장바구니 및 체크아웃 의미론, 표현 규칙을 담고 있으며, 나머지는 search-discovery, purchase-research, planning-goals, customer-care, memory-personalization 스킬이 커버합니다.

판매자 에이전트도 같은 방식으로 구분되며, 운영 도메인별로 performance-insights, catalog-listings, inventory-operations, pricing-promotions, marketing-campaigns 스킬이 각각 배치됩니다.

에이전트 툴링 설계

에이전트를 위한 효과적인 툴 작성에 관한 게시물에서 툴 설계 일반론을 다루고 있습니다. 커머스 영역에서 특히 중요했던 두 가지 포인트를 소개합니다.

기존 핵심 시스템과 로직 위에 에이전트 툴을 구축하세요.

커머스 기업은 이미 검색 및 랭킹, 장바구니, 선호도 및 프로필 저장소, 재고 시스템, 프로모션 및 캠페인 엔진, 판매 분석 등 다양한 시스템을 보유하고 있습니다. 이 각각의 시스템에는 수년간 튜닝된 로직이 담겨 있고, 모델이 결코 볼 수 없는 신호를 처리합니다.

에이전트 툴은 이 시스템들을 다시 구현하는 것이 아니라 호출해야 하며, 툴의 경계가 바로 해당 시스템의 로직이 끝나고 모델의 판단이 시작되는 지점입니다.

예를 들어, 에이전트가 search_products을 호출할 때 결과는 이미 랭킹이 적용된 상태로 도착해야 합니다. 에이전트의 역할은 어떤 결과가 사용자의 목표에 부합하는지, 몇 개를 보여줄지, 어떻게 표현할지를 판단하는 것입니다.

툴 결과는 컨텍스트입니다.

모델이 추론에 활용하는 필드만 반환하고 나머지는 제거하세요. 검색 결과 각 행에 포함된 이미지 URL이 대표적인 문제입니다.

필요하다면 툴 내부에서 응답을 재구성하고, 데이터만으로는 다음 단계가 명확하지 않을 때는 다음 단계 안내를 덧붙이세요.

오류 상황에서 특히 중요한데, 모델은 에러 코드보다 지시문에서 더 많은 도움을 얻습니다. 예를 들어 일반적인 403 대신 "재고 조회 시 상품 ID를 포함하세요"와 같은 오류 안내문을 추가하세요.

UI 컴포넌트도 툴이다

커머스 에이전트의 응답은 대부분 상품 캐러셀, 여행 일정, 좌석 배치도, 차트 같은 UI 컴포넌트이지 일반 텍스트가 아닙니다. 따라서 에이전트는 텍스트가 아닌 스키마를 출력해야 합니다.

초기에 많은 팀이 모델에게 커스텀 태그를 출력하도록 프롬프트하고 클라이언트 사이드에서 파싱하는 방식으로 시작합니다. 하지만 서비스가 성장하면 이 방식은 한계에 부딪힙니다.

• 모델은 여러분의 마크업보다 툴 호출에 더 잘 훈련되어 있어서, 중첩 컴포넌트가 추가될수록 신뢰성이 떨어집니다. 프롬프트만으로는 형식이 보장되지 않습니다.
• 태그 정의가 시스템 프롬프트에 자리 잡으므로, 새 컴포넌트를 추가할 때마다 컨텍스트가 늘어나고 수정할 때마다 프롬프트 다른 부분에 회귀(regression)가 생길 위험이 있습니다.
• 과거 대화가 여러분의 파서만 읽을 수 있는 형식으로 저장되어, 이력을 불러오려면 클라이언트에서 원시 메시지를 파싱하거나 모델 API 네이티브 형식이 아닌 별도 복사본을 유지해야 합니다.

검증된 패턴은 각 UI 컴포넌트를 하나의 툴로 만드는 것입니다. 모델이 타입이 지정된 인수와 함께 present_products, present_itinerary, present_plan_comparison를 호출하면, 서버가 해당 호출을 검증하고 보강해 이벤트를 발행하며, 클라이언트가 이를 렌더링합니다.

컴포넌트가 툴 호출이므로 네이티브 형식으로 이미 메시지 배열에 저장되어, 이전 대화를 불러올 때 재파싱이 필요 없습니다. 아래와 레퍼런스 레포에서 프레젠테이션 툴 계약의 예시를 확인할 수 있습니다.

트레이드오프는 스트리밍 세분성에 있습니다. 툴 호출의 최상위 인수는 각각 서버에서 검증을 위해 버퍼링되므로, 스트리밍이 켜져 있어도 프레젠테이션 툴의 하위 컴포넌트는 단계적으로 도착합니다. 이는 체감 레이턴시에 영향을 줍니다.

토큰 수준의 스트림을 얻으려면 툴 정의에서 eager_input_streaming:를 true로 설정하세요. 이렇게 하면 버퍼링을 건너뛰되 서버 사이드 스키마 보장도 함께 생략됩니다.

평가 결과, Claude Sonnet 급 이상 모델에서는 스키마 위반이 매우 드물었지만, 간혹 발생하는 경우를 대비해 재시도 로직으로 감싸두세요.

프레젠테이션 툴은 에이전트에게 현재 화면에 무엇이 표시되는지에 대한 기록도 제공합니다. 고객이 "첫 번째 호텔" 또는 "왼쪽에서 세 번째"라고 말할 때, 레이아웃 정보는 메시지 배열 안 마지막 프레젠테이션 호출의 인수에 담겨 있습니다.

이를 위해 인수가 실제 렌더링 레이아웃을 반영해야 합니다. 클라이언트가 임의로 재배열하는 평면 목록이 아니라, 정렬된 행과 캐러셀 구조로, UI가 구성된 방식 그대로 인수를 구조화하세요.

커머스에서 레이턴시는 중요하며, 소비자 대면 서비스는 가장 용납하지 않는 환경입니다. 그러나 에이전트 환경에서 리텐션, 참여도, 장바구니 규모 같은 지표를 실제로 움직이는 것은 일관되게 결과의 품질이었습니다.

답변의 관련성과 태스크 완료 여부가 미미한 레이턴시 개선보다 이 지표들에 훨씬 더 큰 영향을 미쳤습니다.

따라서 레이턴시는 두 전선에서 공략해야 합니다. 탄탄한 엔지니어링으로 종단 간 레이턴시를 최소화하고, 에이전트가 작업하는 모습을 보여주는 것이 진행 중이라는 신호로 읽히므로 체감 레이턴시도 함께 줄여야 합니다.

모든 사용자에게는 허용 가능한 레이턴시 한계가 있습니다. 아래 기법들을 활용하면 지능을 희생하지 않으면서 그 한계 안에 에이전트를 유지할 수 있습니다.

태스크 완료 레이턴시 최소화

태스크 완료 레이턴시는 모델 턴별로 마지막 토큰까지의 시간과 툴 처리 시간을 합산한 값입니다. 이를 줄이는 세 가지 레버가 있습니다. 턴 수 줄이기, 툴 속도 높이기, 토큰 속도 높이기입니다. 이 레버들은 때로 서로 상충하므로, 하나만 최소화하려 하지 말고 전체 합산을 최소화하는 데 집중해야 합니다.

턴 수 줄이기

쿼리 복잡도는 턴 수를 늘리지만 대체로 통제 밖의 요소입니다. 모델 지능과 관련 컨텍스트가 에이전트로 하여금 더 적은 턴으로 태스크를 완료하게 돕습니다. 이 부분에서 우리가 얻은 핵심 학습 내용은 다음과 같습니다.

• 예상 컨텍스트를 미리 로드하세요. 사용자가 상품 페이지에서 어시스턴트를 열었거나, 판매자가 캠페인 대시보드에서 열었다면 해당 페이지의 데이터를 세션 컨텍스트에 넣어두세요. 대화가 그 페이지에 관한 것일 가능성이 높고, 컨텍스트에서 답하면 추가 턴이 들지 않습니다.
• 모델 지능을 높이세요. 더 스마트한 모델은 더 효율적으로 계획하고 툴을 호출하기 때문에 태스크 완료에 필요한 전체 턴 수를 줄일 수 있으며, 이것이 느린 토큰 속도를 상쇄하는 경우가 많습니다. 쿼리가 복잡한 편이거나 프로덕션에서 태스크당 약 5턴을 초과하는 경우라면, 더 빠른 모델이 오히려 더 스마트한 모델인 경우가 자주 있습니다. 어떤 모델이 적합한지는 트래픽에 따라 다르므로, 아래 "모델 선택" 항목에서 설명하는 스위프(sweep) 방식으로 결정하세요.
• 독립적인 툴은 병렬로 호출하세요. 커머스 사용 사례에서는 여러 상품 검색, 다수의 정책 문서 조회, 여러 판매 데이터 소스에서의 레코드 조회 등 많은 작업을 병렬로 수행해야 합니다. 병렬 툴 호출은 독립적인 쿼리들이 추가 턴을 소모하지 않도록 합니다. 한 턴에 여러 툴을 호출하고 툴 결과 배열로 한 번에 반환하도록 모델에게 프롬프트하세요 (병렬 툴 사용 문서 참고).

툴 속도 높이기

• 툴 자체의 백엔드를 최적화하세요. 때로는 툴이 진정으로 병렬 작업을 수행하기도 합니다. 판매자 에이전트의 "오늘 스냅샷 조회" 쿼리가 매출, 재고, 캠페인 상태를 세 번의 독립적인 호출로 읽는 경우가 그렇습니다. 그러나 툴 경계가 누락된 백엔드 로직을 이어 붙이는 장소가 되는 경우도 자주 목격합니다. 예를 들어 재고 확인 툴이 카탈로그에서 SKU를 조회하고, 매장별 재고 서비스를 호출하고, 마감 시간을 위해 풀필먼트 서비스에 접근한 뒤, 대체 상품 규칙과 픽업 가능 여부를 툴 자체 코드에서 처리하는 식입니다. 이런 툴은 도메인 지식을 과도하게 떠안고, 규칙이 바뀔 때마다 유지하기 어려우며, 상위 시스템에 있어야 할 로직을 끌어당기고 있습니다. 툴 안에 그런 로직을 작성하게 된다면, 해결책은 해당 질문에 직접 답하는 백엔드 엔드포인트를 하나 만들고 에이전트 툴로 그것을 호출하는 것입니다.
• 툴을 적극적으로 디스패치하세요. 툴 인수는 다른 토큰과 마찬가지로 모델에서 스트리밍되므로, 하니스는 각 툴의 인수가 완성되는 즉시 호출을 실행하고 모델이 다른 병렬 툴이나 컨텐츠 블록을 스트리밍하는 동안 처리할 수 있습니다. 이로 인해 몇 초에 달하던 간격이 수백 밀리초로 줄어드는 경우를 목격했으며, Claude Agent SDK는 이를 기본으로 지원합니다. 레이턴시 절감 효과를 극대화하려면 가장 느린 호출을 먼저 발행하도록 모델에게 프롬프트하세요.

체감 레이턴시

체감 레이턴시란 화면에 무언가가 나타날 때까지 사용자가 느끼는 시간입니다. 결제 과정의 마찰이 체크아웃 비율과 매출에 직접 영향을 미치는 소비자 대면 서비스에서 특히 중요합니다. 모델을 건드리지 않고 체감 레이턴시를 줄이는 두 가지 기법이 있습니다.

• 컴포넌트를 형성되는 대로 스트리밍하세요. 렌더링된 커머스 응답은 일반적으로 500~700개의 출력 토큰으로 구성되어 있어, 스트리밍 없이는 스피너가 5초 이상 돌아갑니다. 프레젠테이션 툴의 각 파라미터를 스트리밍되는 대로 클라이언트에 전송하고 페이지를 점진적으로 렌더링하세요.
• 작업 과정을 보여주세요. 에이전트가 컨텍스트를 수집하는 동안 각 단계를 자연스러운 언어로 짧은 진행 문구로 표시하세요 (예: "물가 근처 호텔을 찾고 있습니다"). 툴의 기존 인수(상품 검색 쿼리 등)를 활용해 만들거나, 모델이 문구를 작성하도록 유도하는 추가 user_facing_message 파라미터 툴을 넣을 수도 있습니다.

프롬프트 캐싱

프롬프트 캐싱은 비용을 줄일 수 있는 가장 큰 수단이며, 커머스 트래픽은 이에 매우 적합합니다. 캐시된 입력 토큰 읽기 비용은 신규 토큰의 10분의 1이며, 캐시 쓰기에는 약 1.25배의 프리미엄이 붙지만 캐시된 프리픽스(prefix)는 두 번째 사용부터 비용을 회수합니다. 대용량 트래픽의 소비자 대면 서비스에서는 가장 저렴한 기본 5분 캐시 만료 설정만으로도 매우 높은 캐시 수준을 달성할 수 있는 기회가 있습니다.

가장 잘 구축된 커머스 배포 사례들은 90~99%의 캐시 히트율을 기록하며, 처음부터 이 범위를 목표로 설계해야 합니다. 우리의 경험에 따르면 캐시된 토큰 읽기는 약 10만 토큰 기준으로 1.5~2배 빠르며, 토큰이 많을수록 거의 선형적으로 확장됩니다.

캐싱은 프리픽스 기반으로 동작합니다. 요청은 이전 요청과 처음으로 달라지는 바이트까지만 캐시에서 읽으므로, 중요한 것은 컨텍스트에 무엇이 있느냐뿐만 아니라 그 순서입니다. 요청을 변경 빈도 순으로 세 구간으로 나누어 생각하세요.

• 글로벌: 시스템 프롬프트 대부분과 툴 정의로, 모든 세션에 걸쳐 동일합니다. 가장 따뜻한 캐시이며, 규모가 커지면 만료되지 않을 가능성이 높습니다. 턴과 세션 전반에 걸쳐 바이트 수준으로 동일하게 유지하고, 끝부분에 캐시 브레이크포인트를 두세요.
• 세션: 사용자별 컨텍스트와 대화 이력으로, 세션마다 다르지만 한 세션 내에서는 안정적입니다. 이 구간은 글로벌 구간 다음에 위치합니다.
• 변동: 현재 시간이나 현재 페이지처럼 세션 내에서 변하는 모든 것입니다. 요청의 맨 끝에 두세요. 최신 사용자 턴의 태그 블록으로 넣거나, 세션 중간 시스템 메시지를 지원하는 모델이라면 메시지 배열에 추가하는 시스템 역할 메시지로 넣으면 됩니다. 가장 흔한 실수는 타임스탬프나 현재 페이지를 시스템 프롬프트 상단에 두는 것인데, 이렇게 하면 매 요청마다 캐시가 조용히 무효화됩니다.

구현 시 기억해야 할 두 가지 세부 사항이 있습니다. 첫째, 스킬은 시스템 프롬프트에 덧붙이는 것이 아니라 툴 결과로 로드해야 합니다. 스킬 본문이 대화 프리픽스에 위치하게 되어 함께 캐시됩니다.

둘째, 매 턴마다 브레이크포인트를 앞으로 갱신하세요. 요청에 허용되는 브레이크포인트 수가 제한되어 있으므로, 최신 것을 각 사용자 턴의 끝으로 이동시키세요. 그러면 매 라운드마다 검색 응답 같은 긴 툴 결과를 포함한 누적 이력을 캐시에서 읽게 됩니다.

모델 및 설정 선택

모델 크기와 에포트(effort) 설정은 같은 트레이드오프, 즉 지능 대 레이턴시와 비용의 문제이므로, 두 가지 모두 측정으로 결정해야 합니다.

1. 지표와 하한선을 정하세요. 비즈니스가 의존하는 품질 지표(태스크 완료율, 답변 관련성, 근거 있는 정확도)와 이 이하로 내려가지 않을 평가 점수, 그리고 p50과 p99 레이턴시 및 비용 예산을 정하세요.
2. 스위프하세요. 검토 대상의 모든 모델과 에포트 레벨에 대해 전체 평가 스위트를 실행하세요. 분석 위주의 태스크를 수행하는 판매자 에이전트는 Opus부터, 레이턴시가 더 중요한 소비자 에이전트는 Sonnet부터 시작하는 것을 권장합니다. 프로덕션 트래픽이 있다면 실제 쿼리 구성에 따라 결과에 가중치를 두세요. 그리고 데이터가 결정하게 하세요. Opus 5가 장바구니 전환 태스크에서 보여주는 향상이 Sonnet과의 비용 차이를 정당화하는 경우도 있고, 그렇지 않은 경우도 있습니다.‍
3. 결과를 주의 깊게 읽으세요. 두 가지가 팀을 자주 놀라게 합니다. 첫 번째는 프롬프트가 특정 모델에 맞춰 튜닝되어 있기 때문에, 하나의 프롬프트로 스위프를 실행하면 해당 프롬프트 작성 대상이 아닌 다른 모델들이 저조한 성능을 보일 수 있다는 점입니다. 작은 모델은 현재 모델이 스스로 추론하는 지시문을 명시적으로 필요로 하고, 큰 모델은 작은 모델이 무시하던 지시문을 문자 그대로 따릅니다. 각 후보 모델의 실패 케이스를 몇 차례 반복해서 개선하는 과정은, 어떤 모델을 제외하기 전에 거쳐야 할 저렴한 단계입니다. 두 번째는 더 지능적인 설정이 토큰 속도가 느림에도 불구하고 레이턴시에서 이기는 경우가 있다는 점입니다(가장 복잡한 요청에서 p90, p99 기준으로 자주 나타납니다). 툴 호출 계획을 더 잘 세우고 여러 라운드가 필요 없기 때문입니다.

비용은 모델 호출당이 아니라 완료된 태스크당으로 측정하세요. 더 많은 턴이 필요하거나 더 자주 실패하는 저렴한 모델은 사실 저렴하지 않습니다. 결과가 비슷하고 태스크당 경제성과 레이턴시가 맞는다면 지능을 선택하세요. 품질이 채택과 리텐션을 이끌며, 모델이 계속 발전하는 만큼 향후 6개월을 위한 구축 여유를 만들어줍니다.

마지막으로, 에이전트를 프로덕션에 안착시키는 요소들을 다룹니다. 메모리, 안전성, 평가, 그리고 조직 전반의 협업 방식입니다.

세션을 넘어 유지되는 메모리

고객과의 관계와 상호작용은 중요합니다. 메모리는 에이전트가 이전 대화를 이어받아 처음부터 다시 시작하지 않도록 해줍니다. 3월에 견과류 알레르기를 언급한 쇼핑객이 6월에 다시 말할 필요가 없어야 하고, 매주 월요일 같은 세 개의 캠페인을 확인하는 판매자가 매번 이름을 일일이 말할 필요가 없어야 합니다. 장기 메모리, 즉 세션을 넘어 유지되어야 하는 정보는 직접 구축해야 하는 시스템이며, 세 가지 구성 요소가 있습니다. 사실을 저장하는 방법, 쓰는 방법, 읽는 방법입니다.

메모리 저장

메모리는 모델이 아닌 여러분의 시스템에 속합니다.

프로필이 작고 에이전트가 유일한 독자인 경우에는 평면 마크다운 프로필도 작동합니다. 하지만 대부분의 프로덕션 커머스 에이전트는 이를 넘어서며, 현실적인 대안은 이미 운영 중인 데이터베이스입니다. 사실(fact)은 키(예: shoe_size, default_store, preferred_report_cadence), 짧은 값, 카테고리, 출처 세션으로 구성된 작은 타입 레코드입니다. 일부 키는 미리 정해두어 모든 사용자에게 적용하고, 나머지는 추출기가 발견합니다. 데이터베이스는 저장소가 커져도 쿼리가 가능하고, 특정 속성에 대한 결정론적 동작을 구축할 수 있으며, 기존 사용자 데이터와 조인할 수 있습니다.

판매자 대면 에이전트의 경우 계정이 아닌 개인 단위로 메모리를 키잉(keying)하세요. 판매자 로그인은 운영자들 사이에 공유되는 경우가 많아 각 운영자마다 자체 프로필이 필요하며, 읽기는 해당 운영자의 권한을 따라야 합니다. 매장 관리자의 에이전트가 지역 담당자가 언급한 사실을 불러와서는 안 됩니다.

커머스 도메인에서 에이전트 메모리는 개인 데이터를 담습니다. 기억할 가치가 있는 사실이 종종 가장 엄격하게 규제되는 정보이며, 관할 지역마다 규정이 다릅니다. 메모리를 단순한 저장 문제가 아닌 데이터 처리 설계 문제로 접근하세요. 실제로 이는 네 가지를 의미합니다.

• 보유할 메모리 유형을 결정하세요. 프롬프트만이 아니라 모든 저장이 거치는 검증기를 통해 쓰기 경로에서 이를 강제하세요.
• 사용자가 저장된 내용을 확인하고, 수정하고, 삭제할 수 있는 방법을 제공하세요. 계정 삭제 및 데이터 요청 흐름에 삭제 기능을 연결하세요.
• 보존 기간을 설정하세요. 몇 년 전의 선호도는 이미 낡았을 가능성이 높으므로, 보존 기간을 두면 메모리 사실을 최신 상태로 유지하는 데 도움이 됩니다.
• 메모리는 배포별 스위치로 두세요. 이 의무를 수용하기 어려운 지역에서 메모리 없이 운영할 수 있습니다.

메모리 쓰기

메모리는 비동기로 쓰세요. 각 턴의 끝, 또는 긴 세션에서 몇 턴마다 별도의 스레드나 프로세스에서 에이전트가 대화를 읽고 저장소의 사실을 생성, 수정, 삭제하면서 세션이 진행되는 동안 자체 작업 컨텍스트를 유지합니다.

이는 대화 레이턴시에 전혀 영향을 주지 않으며, 내부 커머스 메모리 평가 스위트에서 사실 재현율이 13% 높아지는 결과를 달성했습니다.

에이전트가 사실을 저장하기 위해 툴을 호출하는 방식은 레이턴시에 민감한 커머스 에이전트에게 잘못된 선택입니다. 모든 저장이 사용자 대면 턴 내부의 툴 호출이 되며, 전체 저장소가 컨텍스트에 없는 한 저장에 앞서 업데이트나 중복 제거를 위한 읽기가 먼저 필요해 한 라운드가 더 생깁니다.

또한 에이전트의 매 턴에 하나의 결정이 더해지는데, 평가 결과 이 주의 분산이 메모리 누락으로 나타났습니다.

추출기를 분리하면 프롬프트도 정밀하게 작성할 수 있습니다. 추출기는 사용자와 어시스턴트의 텍스트만 읽고 툴 결과는 읽지 않으므로, 상품 설명이나 리뷰가 사용자에 관한 사실로 변환될 수 없습니다. 추출기의 프롬프트는 무엇이 사실로 간주되는지, 예컨대 명시된 사이즈, 식이 제한, 배송 선호도, 판매자의 일상적인 머티리얼라이즈드 뷰(materialized view), 그리고 무엇이 아닌지, 즉 상품 목록의 내용이나 일회성 세부 사항 등을 명확히 정의합니다.

메모리 읽기

메모리는 세 가지 레이어로 읽으세요.

메모리는 사용자별 컨텍스트이므로, 모두 글로벌 캐시 브레이크포인트 아래 세션 구간에 위치합니다.

안전성: 하니스에서 강제하라

안전한 동작은 프롬프트에서 시작하지만, 커머스에서는 프롬프트가 안전을 강제하는 곳이 되어서는 안 됩니다. 실패는 금전적 손실로 이어지고 돌이키기 어려운 경우가 많으며, 프롬프트 규칙은 인젝션(injection) 하나 또는 불량 샘플 하나로 우회될 수 있습니다. 아래의 모든 규칙은 소비자 에이전트와 판매자 에이전트 모두에서 코드로 강제되며, 모든 런타임이 공유할 수 있도록 한 곳에 정의됩니다.

모델은 준비하고, 사람이나 정책이 적용한다

어떤 모델 툴 호출도 금전을 이동시키거나 비즈니스를 변경하지 않습니다. 주문 처리, 결제, 환불, 가격 변경, 캠페인 런칭은 모두 모델이 아닌 하니스가 제어하는 행동으로 마무리됩니다.

소비자 측에서는 이것이 구조적으로 보장됩니다. 체크아웃 툴은 주문 버튼이 있는 장바구니를 렌더링하며, 에이전트가 호출하는 백엔드 인터페이스에는 아예 결제 메서드가 없습니다.

판매자 측에서는 모든 쓰기 툴이 서버에서 생성된 ID를 가진 준비된(staged) 변경 사항을 만들어내며, apply_change는 실제 인터페이스, 즉 운영자 포털의 버튼, CLI 확인, 또는 에이전트가 Managed Agents에서 실행될 때 플랫폼 자체의 툴 승인 프롬프트를 통해 승인된 ID에 대해서만 성공합니다.

가드레일은 변경이 준비된 시점의 한도가 아니라 현재 한도에 따라 적용 시점에 재확인됩니다. 인터페이스가 어떠하든 구조는 동일합니다. 모델의 가장 위험한 행동은 제안하는 것이며, 승인은 해당 변경 유형에 비즈니스가 이미 사용하는 메이커-체커(maker-checker) 흐름을 통해 이루어집니다.

쓰기와 렌더링은 서버에서 발급된 ID만 허용한다

하니스는 세션마다 서버가 모델에 전달한 모든 ID를 기록하며, 그 기록만이 쓰기나 렌더링이 허용하는 유일한 키입니다.

장바구니는 해당 세션에서 서버가 반환한 상품 ID만 허용하고, 판매자 툴은 에이전트가 실제로 읽은 상품 목록과 캠페인 ID만 허용합니다. 다른 방식으로 전달된 ID, 즉 환각으로 생성되었거나, 사용자가 붙여넣었거나, 리뷰에 심어진 ID는 백엔드에 도달하기 전에 거부됩니다.

같은 규칙이 UI에도 적용됩니다. 프레젠테이션 툴은 ID를 받고, 서버가 상품, 주문, 변경 레코드를 직접 채워 넣으므로, 카드는 서버가 직접 채운 레코드만 렌더링합니다.

위임된 에이전트에도 동일하게 적용됩니다. 판매자 분석 서브에이전트는 데이터를 읽을 수 있지만, 에이전트가 쓸 수 있는 ID 목록에 추가할 수는 없습니다.

수수료, 고지 사항 및 기타 규제 콘텐츠의 경우, 모델이 어떤 상품을 고지할지 선택하고 서버가 승인된 문구에서 모든 내용을 제공합니다. 동일한 수수료 필드가 판매자 에이전트의 보호 목록에도 있어, 양쪽 어느 쪽도 내용을 변경하거나 바꿔 쓸 수 없으며, 평가는 렌더링된 문자열을 바이트 단위로 확인합니다.

한도가 있는 거래는 반복 요청에도 지켜져야 한다

대부분의 커머스 서비스는 티켓 배분, 프로모션 가격, 또는 사기 방지를 위해 사용자당 구매 가능 수량에 한도를 두는데, 에이전트는 버튼을 클릭하는 인간이 결코 하지 않는 방식으로 재시도하고, 표현을 바꿔 시도하고, 병렬로 처리합니다.

따라서 한도는 쓰기 후 상태를 기준으로 라인 단위에서 강제되어, "두 개 더 추가해줘"를 두 번 해도 한도를 초과할 수 없으며, 한 세션의 장바구니 쓰기는 직렬화되어 한 턴의 병렬 툴 호출이 합산으로 한도를 넘길 수 없습니다.

판매자 변경도 가격 변동 폭, 할인 깊이, 재입고 규모, 캠페인 예산에 대한 한도와 어떤 변경도 건드릴 수 없는 보호 필드 목록에 대해 동일한 방식으로 확인됩니다. 규칙은 일반화됩니다. 모든 한도를 요청이 아닌 결과 상태에 대해 강제하고, 세션별로 쓰기를 직렬화하세요.

서드파티 콘텐츠는 정제된다

커머스에서는 컨텍스트의 대부분이 판매자, 리뷰어, 경쟁자 등 여러분이 아닌 사람들이 작성하므로, 모든 백엔드 읽기는 신뢰할 수 없는 입력으로 간주하고 하나의 새니타이저(sanitizer)를 통과시킵니다.

상품 목록, 리뷰, 정책, 판매자 메시지, 저장된 메모리 등 서드파티가 작성한 모든 툴 결과는 정제되어 고정 레이블이 붙은 펜스(fence)로 감싸진 뒤 모델에 전달됩니다.

새니타이저는 제어 문자와 양방향 문자를 제거하고, 펜스 마커를 흉내 내는 내용을 제거하며, 대화 턴이나 툴 호출처럼 보이는 텍스트를 무력화하고, 크기를 제한합니다. 이는 악의적인 상품 목록이 시스템을 사칭하거나 컨텍스트를 채우는 것을 막기 위해 설계되었습니다.

프롬프트는 계약의 나머지 절반을 담당합니다. 펜스로 감싸진 텍스트는 보고할 자료이지, 행동의 근거가 아닙니다.

평가: 비결정론적 시스템 배포하기

작은 프롬프트 변경부터 새로운 툴 추가까지 무엇이든 에이전트 동작을 예측하기 어려운 방식으로 바꿀 수 있으며, 배포하는 변경이 회귀를 일으키는 변경이 아닌 경우도 많습니다. 평가는 배포 전에 이를 발견하는 수단입니다. 에이전트 평가에 관한 이전 블로그 게시물인 에이전트 평가에서 일반적인 방법론을 다룹니다. 이 섹션은 커머스 에이전트에 특화된 내용을 다룹니다.

대화가 아닌 스냅샷을 평가하라

모델의 API는 무상태(stateless)이므로, 에이전트가 출력하는 것은 시스템 프롬프트, 툴, 메시지 배열의 함수입니다. 즉 커머스 대화가 도달할 수 있는 어떤 상태든 직접 구성할 수 있습니다. 따라서 평가 케이스를 만드는 것은 테스트 상태를 구성하고, 테스트 사용자 메시지를 추가한 뒤, 에이전트가 거기서부터 실행되도록 하는 것입니다.

그런 다음 결과를 채점하세요. 최종 상태와 렌더링된 응답, 마지막 쓰기의 인수까지 포함해서 평가합니다. 대부분의 경우 에이전트가 거기에 도달하기까지 거친 경로는 채점하지 않는 것을 권장합니다. 그런 테스트 케이스는 취약하고 제약적입니다.

두 번째 모델이 사용자 역할을 맡고 심판 모델이 전체 대화를 채점하는 시뮬레이션 사용자 평가는 측정 도구로는 부적합합니다. 두 개의 비결정론적 시스템이 상호작용하면 더 많은 샘플이 필요하고, 시도당 비용이 더 높으며, 채점이 어렵고, 실패 원인 파악이 어렵습니다. 커버리지 공백을 찾거나 에이전트에 대한 전반적인 감을 잡는 데는 유용하므로, 케이스를 발견하는 데 활용한 뒤 각 케이스를 스냅샷으로 작성하세요.

까다로운 조건에서의 동작을 평가하라

대부분의 팀이 주입된 상태를 제대로 테스트하지 않습니다. 케이스는 단순히 태스크만이 아니라 실패의 전제 조건을 담아야 합니다. 특정 동작이 여러 툴 호출이 있는 바쁜 첫 번째 턴 이후에나, 또는 세션 앞부분의 모순 이후에만 나타난다면, 깨끗한 상태에서 시작하는 케이스는 모든 설정에서 통과되어 의미 있는 데이터를 제공하지 못합니다.

대부분의 스위트가 이런 깨끗한 상태 케이스에 치우쳐 있는 것을 자주 봐왔습니다. 여러분의 스위트 중 일부는 길고, 복잡하며, 모순이 있는 이력에서 시작하도록 만드세요.

다양한 유형의 커머스 에이전트 평가를 커버하라

효과적인 평가는 원하는 동작과 원하지 않는 동작 모두를 테스트해야 합니다.

모든 긍정 케이스에 부정 케이스를 짝지어 작성하세요. "응해야 함"마다 "거부해야 함"을, "그냥 해야 함"마다 "물어봐야 함"을 짝지어 씁니다. 스위트에서 가장 흔히 발견되는 공백은 부정 케이스의 부재입니다.

다음 항목들에 대한 평가를 구성하세요.

• 핵심 요청: 트래픽의 대부분을 차지하므로 여기서 실패하면 대부분의 세션에 영향을 미칩니다. 단순 조회, 다중 조건 요청, 상품 및 플랜 질문, 다중 인텐트 메시지가 포함됩니다. 질문의 경우, 모든 가격, 재고, 속성이 반환된 데이터로 추적 가능한지, 데이터가 없을 때 에이전트가 만들어내지 않고 없다고 말하는지 확인하세요.
• 컨텍스트 의존 요청: 화면에 표시된 내용 참조, 이전 턴에서 이어진 조건, 기존 장바구니에 대한 쓰기 등이 해당합니다. 메모리 평가도 이 범주에 속합니다. 메모리가 추출되었는지, 검색되었는지, 답변이 달라졌는지 확인하세요.
• 안전 및 브랜드 케이스: 실패 시 금전적 손실이나 신뢰 손상이 발생합니다. 인젝션 시도, 다른 사용자 데이터 접근 시도, 바이트 단위로 확인되는 규제 언어가 포함됩니다. 인젝션은 두 케이스로 분리하세요. 사용자 작성 인젝션, 즉 지시문이 사용자 자신의 메시지에서 오는 경우와, 데이터 플레인 인젝션, 즉 상품 이름, 리뷰, 툴 결과로 들어오는 웹 스니펫에 심어진 경우입니다.
• 인터페이스 평가: 올바른 컴포넌트가 렌더링되는지, 수량 한도가 지켜지는지, 사용자 대면 텍스트에 내부 식별자가 노출되지 않는지 확인합니다. 타임아웃과 빈 결과도 테스트하세요.
• 여러 기능이 동시에 필요한 요청: 운영자가 "이 상품을 15% 할인하면 수요를 감당할 만큼 재고가 충분한가요?"라고 묻는 경우처럼, 가격 질문과 재고 질문이 동시에 필요합니다. 올바른 답변은 재고 예측이 첨부된 마크다운(markdown)을 준비하는 것이고, 잘못된 답변은 둘 중 하나만 하고 나머지를 건너뜁니다. 기능별로 작성된 평가는 이를 잡지 못합니다. 각 평가가 자신의 절반만 채점하기 때문입니다. 인접한 두 기능이 함께 필요한 요청에 대한 케이스를 작성하고, 답변의 두 절반 모두 채점하세요.

SME와 함께 평가를 작성하고 실제 사고를 활용하라

실패를 직접 목격하는 현업 전문가(subject-matter expert, SME), 즉 프로덕트, 법무, 판매자 운영, 고객 케어, 카테고리 관리 팀원들과 협력해 테스트 케이스를 설계하세요. 실제 실패가 가장 좋은 평가 케이스가 되며, 사용자 플로우당 50~100개의 평가 케이스가 좋은 출발점입니다.

위에서 설명한 것처럼 다양한 케이스를 확보하세요. 프로덕션 트랜스크립트, 특히 까다로운 케이스는 새로운 케이스를 발굴하기에 좋은 소스입니다. 코딩 에이전트는 추가 케이스와 적대적 변형을 생성하는 데 능합니다. 레퍼런스 레포에는 우리가 권장하는 방식으로 구축된 평가 작성 스킬을 탑재한 Claude Code 플러그인이 포함되어 있습니다.

대규모 조직에서의 배포

커머스 기업에서 에이전트는 여러 엔지니어링 팀이 함께 구축합니다. 검색, 체크아웃, 가격, 마케텍(마케팅 기술), 고객 케어, 카탈로그 플랫폼 팀은 각자 에이전트가 의존하는 시스템을 보유하고, 각자의 배포 주기로 운영하며, 저마다 툴, 스킬, 또는 프롬프트 규칙을 추가하거나 변경하고 싶어 합니다.

서비스와 달리 에이전트는 다른 팀을 보호하는 엄격한 모듈 경계가 없습니다. 가격 팀이 만든 변경이 체크아웃과 컨텍스트 윈도우를 공유합니다.

시스템을 사업부별로 여러 서브에이전트로 나누고 싶은 유혹이 생깁니다. 1부에서 논의했듯이, 품질상의 이유로 이 방식은 권장하지 않습니다. 대신, 다팀 협업의 리스크를 줄이는 프로세스를 소개합니다.

• 소유권은 시스템을 따른다. 모든 스킬과 툴에는 단일 오너 팀이 있습니다. 예를 들어, 가격 팀은 프로모션 툴과 가격 스킬을 소유하고, 케어 팀은 주문·반품 툴과 고객 케어 스킬을 소유합니다. 공유 프롬프트의 경우, 공통 부분은 플랫폼 레벨의 단일 오너가, 도메인별 섹션은 해당 도메인 오너가 관리합니다.
• 변경 사항은 해당 케이스와 함께 배포되며, CI는 그에 맞게 선별된 케이스 셋을 실행한다. 스킬을 기여하는 팀은 해당 케이스도 함께 기여해야 하며, 인접 스킬과의 경계 케이스와 네거티브 케이스도 포함해야 합니다. 풀 리퀘스트마다 전체 스위트를 실행하면 속도와 비용 면에서 지속하기 어려우므로, 그 대신 CI용 케이스 셋을 별도로 구성하세요. 이 셋은 트래픽이 가장 높은 요청과 모든 안전 케이스로 이루어진 코어 셋을 기반으로 합니다. 여기에 더해, 변경 사항이 영향을 미치는 케이스를 추가로 실행합니다. 스킬 변경이라면 해당 스킬의 케이스와 인접 스킬의 경계 케이스를, 툴 변경이라면 해당 툴을 호출하는 모든 케이스를, 공유 프롬프트 변경이라면 시스템 프롬프트를 모두가 참조하므로 전체 평가 스위트를 실행합니다. 몇 차례 시험에 걸친 통과율, 캐시 히트율, 턴당 비용을 기준으로 게이팅할 것을 권장합니다. 전체 스위트를 매일 밤과 릴리스 전마다 실행하는 것도 좋은 습관입니다. 팀 간 리그레션은 이 실행에서 발견됩니다.
• 에이전트도 릴리스 캘린더 안에 포함되어야 한다. 에이전트는 단일 배포 단위이므로, 잘못된 변경이 생기면 모든 사용자에게 동시에 영향을 미칩니다. 프롬프트와 스킬 변경은 먼저 카나리 코호트에 롤아웃하고, 별도 배포 없이 특정 스킬을 끌 수 있는 스위치를 유지하며, 다른 시스템을 동결하는 것과 마찬가지로 피크 기간 전에는 에이전트도 동결하세요.

이 체계의 인적 측면에 대해서는 효과적인 휴먼-에이전트 팀 구성을 참고하세요.

앞으로의 전망

이 글에서 설명하는 내용의 대부분은 모델과 직접적인 관계가 없습니다. 툴은 이미 운영 중인 시스템을 호출하고, 스킬은 이미 따르고 있는 절차를 코드로 옮긴 것이며, 평가는 테스트로 작성된 제품 요구사항 문서이고, 하네스는 어떤 클라이언트에든 적용했을 정책을 강제하는 것입니다. 모델은 계속 발전할 것이고, 더 나은 모델이 출시되면 여기서 설명하는 아키텍처는 설정 변경과 평가 스위프만으로 이를 수용할 수 있습니다. 나머지 모든 것은 그대로 작동합니다.

제품 서피스에 대한 로드맵도 함께 고민해야 합니다. 이 아키텍처는 채팅 패널보다 오래 살아남을 것입니다. 동일한 에이전트가 음성으로도 동작할 수 있고, 사용자가 요청하기 전에 운임 인하를 먼저 감지해 능동적으로 행동할 수도 있습니다. 이미 평가와 툴을 갖춘 팀에게 이런 기능들은 프레젠테이션 레이어 프로젝트에 불과합니다. 더 나아가, 스토어프런트로 유입되는 트래픽 중 일부는 사용자를 대신해 쇼핑하는 에이전트에서 오게 될 것입니다. 자체 에이전트를 안전하게 운영하기 위해 적용한 출처 확인, 스테이징, 승인 규칙이 바로 외부 에이전트에게 툴을 안전하게 개방하는 기반이 됩니다.

커머스는 언제나 구매 과정을 최대한 매끄럽게 만드는 것을 보상해 왔습니다. 에이전트는 그 일을 훨씬 쉽게 만들어 줍니다. 소비자 에이전트와 판매자 에이전트, 그리고 리테일·여행·통신·엔터테인먼트를 아우르는 실행 가능한 예제가 담긴 완전한 레퍼런스 구현을 살펴보세요.

감사의 말

Matthew Koen과 Ali Shazal이 작성했습니다. Michael Segner, Rodrigo Olivares, Amandeep Khurana, Aiza Usman, John Lopus를 비롯해 기여해 주신 모든 분께 감사드립니다.