#전자상거래 Agent는 어떻게 가격을 약속해야 틀리지 않는가

← 전체 목차 · 이전: Agent 월권 경계 — 안전 샌드박스는 무엇을 가두는가 · 다음: 이미지 생성 Agent — 중복 과금·결과 뒤섞임·원본 유실을 어떻게 막나

같은 휴대폰이 지역·채널·시간에 따라 가격이 다를 때 전자상거래 Agent는 어떻게 견적을 내야 하는가. 진짜 쟁점은 컴포넌트 나열이 아니라 Agent 시스템이 이 능력들을 어떻게 떠받치고, 실패했을 때 어떻게 안전하게 수습하는가이다.

경계를 못 박는 것이 답이다. 대규모 모델은 의도 이해, 후보 계획 생성, 다음 호출 결정만 담당하고, 확정적 서비스가 실제 상태와 최종 제약을 담당한다. 최종 견적은 반드시 버전화된 가격 서비스를 실시간 호출해야 하고, 모델은 약속 가격을 캐싱하지 않으며, 주문 시점에 지역·채널·시간·규칙 버전을 재검증한다.

원칙 한 줄: 유연성은 변화 속도를 해결하고, 버전 관리는 변화 리스크를 해결하며, 가격 시스템의 최종 경계는 주문 스냅샷이다.

#모델은 약속을 보유할 수 없고 의도만 보유할 수 있다

주문 시점에는 지역·채널·시간·규칙 버전을 반드시 재검증한다. 그렇게 하지 않으면 Agent의 한 번의 잘못된 계획, 중복 실행, 만료된 상태가 그대로 실제 업무 사고가 된다.

이 세 가지 실패 모드가 모두 Agent 고유의 것이라는 점에 주목할 것 — 계획 오류, 재시도로 인한 중복, 오래된 상태. 일반 인터페이스 호출에서는 만나지 않는 유형이다.

Agent 실행 사슬에 포함시켜야 할 것들:

그리고 이 사슬에 대해 정상 경로, 실패 상태, 다운그레이드 방식을 명확히 해야 한다 — 성공 플로우 하나만 그리는 것이 아니다.

#규칙 설정화, 그러나 설정화가 아무나 고쳐도 된다는 뜻은 아니다

규칙 자체에 다섯 필드가 갖춰져야 한다.

1. 발효 시각
2. 적용 대상
3. 채널
4. 우선순위
5. 종료 시각

여러 할인이 동시에 적중하면 중첩인지, 최저가 채택인지, 상호 배타인지를 명확히 해야 한다.

다중 할인 적중 →  중첩?  최저가?  배타?
                  ↑
          설정에 명시된 의미론이어야 하며
          if-else의 작성 순서가 아니다

#배포 전: 실제 주문 시뮬레이션 + 카나리

1. 배포 전 실제 주문으로 시뮬레이션해 세 가지 이상을 검사한다: 음수 가격, 할인 한도 초과, 비정상 대상.
2. 시뮬레이션 통과 후 카나리 배포.
3. 카나리 기간에 거래·환불·불만을 관찰.
4. 이상 없음을 확인한 뒤 확대 — 한 번에 전량 발효시키지 않는다.

#견적 ≠ 약속: 두 개념을 분리해 모델링한다

규칙 조정 후의 처리 방식: 신규 주문은 새 버전을 사용하고, 기존 주문은 스냅샷대로 정산한다.

이중 수익이 생긴다 — 운영은 빠르게 가격을 바꿀 수 있고, 재무는 각 거래가 왜 그 금액인지 설명할 수 있다.

#통합 가격 서비스와 price_id

가격은 프런트엔드와 각 업무 서비스에 흩어져 있으면 안 되고 통합 가격 서비스로 들어가야 한다.

• 요청에 실어야 할 것: 상품, 지역, 채널, 사용자 신분, 시간
• 가격 서비스가 순차 적용: 기본가 → 지역 규칙 → 채널 행사 → 할인 자격. 그리고 규칙 우선순위, 중첩 가능 여부, 발효 구간을 명확히 한다.

계산 결과 반환:

price_id        ← 이후 주문 시 이 식별자로 검증
규칙 버전        ← 당시 어떤 규칙을 썼는지 복원하는 데 사용

맨 금액만 넘기면 안 된다. 주문 생성 시 가격 스냅샷도 함께 저장한다. 사용자가 페이지에서 본 가격이 이미 만료되었다면 명시적으로 재확인을 안내해야 하며, 백엔드에서 조용히 가격을 바꿔치기하면 안 된다.

#주문 가격 스냅샷

주문에는 반드시 가격 스냅샷을 저장한다. 내용은 단가, 할인, 세금, 규칙 버전.

근거는 시간축 위의 불변량이다 — 현재 상품가는 변하지만 과거 주문이 오늘의 설정에 의해 다시 쓰여서는 안 된다.

#설정 배포의 거버넌스

설정 배포는 버전 롤백과 차이 미리보기를 지원해야 한다. 운영 담당자가 규칙을 제출하면 시스템이 영향받는 주문과 사용자 범위를 보여준다.

긴급 차단의 의미론은 정확해야 한다 — 신규 견적만 중단하고, 이미 결제된 주문을 임의로 다시 쓰지 않는다.

모든 가격 변경 조작은 세 가지 감사 정보를 남긴다: 승인자 / 이전 값·새 값 / 발효 시각.

#검증과 모니터링

정상 요청 하나만 돌려보지 말 것. 함께 테스트해야 할 이상·극한 시나리오: 피크 트래픽, 중복 이벤트, 의존 지연, 노드 재시작, 복구 후 상태.

주제마다 진짜 대응되는 리소스 지표를 고를 것 — 모니터링 항목을 통째로 외우는 것이 아니다. 배포는 카나리 먼저, 중단선과 롤백 조건을 미리 명문화해 둔다.

#핵심 통찰

1. 쟁점은 "컴포넌트가 있는가"가 아니라 "떠받칠 수 있는가 + 수습할 수 있는가"다 — 같은 컴포넌트 목록이라도 이름만 나열하는 것과 정상 경로 / 실패 상태 / 다운그레이드 방식을 말할 수 있는 것은 다른 층위다.
2. 모델은 약속을 보유할 수 없고 의도만 보유할 수 있다 — 분업선은 "의도와 계획"과 "실제 상태와 최종 제약" 사이에 그어진다. 모델이 약속 가격을 캐싱하는 순간 그것은 기획자에서 장부 담당자로 바뀌는데, 모델은 장부에 필요한 일관성 보장을 갖고 있지 않다.
3. Agent의 실패 모드는 일반 서비스와 다르다 — 잘못된 계획, 중복 실행, 만료된 상태 세 가지다. 전통 인터페이스 호출은 주로 타임아웃과 에러 코드를 막지만, Agent 사슬은 "모델이 스스로 잘못 생각함", "재시도로 같은 동작을 두 번 함", "오래된 상태를 들고 계속 진행함"까지 막아야 한다. 검증 지점 설계는 마이크로서비스 방식을 그대로 베끼면 안 된다.
4. 설정화의 진짜 난점은 구현이 아니라 거버넌스다 — "규칙 설정화"는 설계 문서에 한 줄이면 되지만, 설정화 직후에 누가 고칠 수 있는지, 언제 발효되는지, 여러 개가 적중하면 어떻게 되는지, 잘못 고치면 어떻게 되돌리는지가 새로 생긴다. 다섯 필드와 3택1 의미론이 이 문제들을 설정 구조에 선반영하는 장치다.
5. 판정 의미론은 설정에 써야지 코드 순서에 떨어지면 안 된다 — 결과가 if-else의 작성 순서에 좌우되면 규칙은 설명 불가·테스트 불가·회귀 불가가 되고, 코드 한 줄 고치는 것이 전체 가격을 조용히 바꿀 수 있다.
6. 스냅샷은 "위변조 방지"가 아니라 "설명력"의 담체다 — 단가·할인·세금·규칙 버전을 저장하는 표면적 목적은 과거 주문이 오늘의 설정에 덮어쓰이지 않게 하는 것이지만, 더 깊은 목적은 재무가 각 거래의 금액을 설명하고 CS가 분쟁 시 어떤 규칙이 쓰였는지 복원하게 하는 것이다. 설명 가능성은 사후에 덧붙이는 것이 아니라 데이터 모델에 미리 자리를 잡아두는 것이다.
7. 유연성과 리스크는 두 개의 메커니즘으로 각각 해결한다 — 빠르게 하려면 설정화, 안정적으로 하려면 버전화. 충돌하지도 않고 서로 대체하지도 못한다. 앞만 하면 사고가 나고 뒤만 하면 운영이 마비된다.
8. 시스템의 신뢰도는 무엇을 계산할 수 있느냐가 아니라 무엇을 약속했느냐가 결정한다 — 최종 경계는 주문 스냅샷이다. 규칙은 마음대로 바뀌어도 되지만 약속한 것은 안정적이고 추적 가능하고 보상 가능해야 한다. 견적·한도·재고·SLA 등 대외 약속이 있는 모든 시스템에 그대로 성립한다.

#엔지니어링 실전 Tips

• 모델은 약속 가격을 캐싱하지 않는다: 이 문서에서 가장 실행 가능한 하드 제약이다. "모델이 지난 라운드에 계산했으니 이번엔 그대로 쓰자"는 모든 최적화가 견적 시나리오에서는 사고 원인이다.
• 맨 금액은 전달 금지 데이터 타입: 금액은 반드시 price_id + 규칙 버전과 함께 흘러야 한다. 숫자만 넘기면 하류에서 검증도, 소급도, 설명도 불가능하다.
• 만료된 견적은 명시적으로 안내하고 조용히 바꿔치기하지 말 것: 조용한 교체가 기술적으로는 매끄럽지만 시스템의 불확실성을 사용자에게 전가하고 CS가 설명할 근거를 없앤다.
• 긴급 차단은 "신규 중단"과 "기존 변경"을 구분할 것: 두 의미론을 하나의 스위치에 섞으면 사고가 한 건에서 두 건으로 확대된다.
• 배포 전 시뮬레이션은 실제 주문으로 돌릴 것: 실제 주문으로 "구 규칙 결과 vs 신 규칙 결과" 차이를 보는 편이, 테스트 케이스를 구성하는 것보다 음수 가격·할인 한도 초과·비정상 대상 세 유형을 훨씬 잘 드러낸다.
• 모니터링 지표는 주제에 맞게 고를 것: 견적 사슬이 관심 두는 것은 큐 적체와 캐시 원본 조회이지 모든 미들웨어 지표를 외우는 것이 아니다.
• 중단선과 롤백 조건은 배포 전에 문서화할 것: 사고가 터지면 "무엇이 비정상인가"를 정의할 여유가 없다. 미리 써두어야 카나리에 의미가 생긴다.