AI 연재 보강 4 — 포인트와 쿠폰을 대화로 지급할 때: 멱등성, 원장, 권한 설계
"보상"을 로열티·리워드(포인트, 쿠폰, 캐시백)로 읽을 때의 이야기다. 이 해석에서 문제의 중심은 돈의 정확성이다. 한 번만 지급하고, 얼마 나갔는지 맞추고, 속여서 가져가지 못하게 하는 것.
미리 밝혀 둔다. 이 주제는 신뢰할 만한 설계 문헌을 찾았지만 어뷰징 탐지와 개인화 공정성에 대해서는 1차 자료를 확인하지 못했다. 그 부분은 아래에서 "열린 문제"로 남긴다.
이중 지급을 막는 멱등 키
네트워크 요청이 실패하는 경우는 세 가지로 나눠 볼 수 있다. Stripe의 Brandur Leach가 2017년 글("Designing robust and predictable APIs with idempotency")에서 정리한 구분이다. 연결 자체가 실패한 경우, 작업 도중에 실패한 경우, 작업은 성공했는데 응답이 돌아오지 못한 경우. 세 번째가 위험하다. 클라이언트는 실패로 보고 재시도하지만 서버에서는 이미 지급이 끝났다.
Stripe API 문서가 설명하는 해법이 멱등 키다. 클라이언트가 보낸 키로 첫 요청의 상태 코드와 본문을 저장하고, 같은 키로 재요청이 오면 저장된 결과를 그대로 돌려준다. 같은 키에 다른 파라미터가 오면 에러를 낸다. 키는 24시간 이상 지나면 삭제될 수 있다고 문서에 적혀 있다.
대화형 AI에 적용할 때 가장 중요한 설계는 이거다. 멱등 키를 LLM이 만들게 하지 않는다. 모델은 같은 요청에도 다른 문장을 낼 수 있으니, 키는 도메인 이벤트에서 결정적으로 도출해야 한다. 예를 들어 사용자 ID, 캠페인 ID, 이벤트 ID의 조합이다. 이건 문헌 내용을 바탕으로 한 내 권고다.
Stripe의 24시간 TTL은 Stripe의 선택이다. 포인트 지급에서는 캠페인 기간 동안 유니크 제약을 보관하는 쪽이 안전하다고 생각하는데, 이것도 내 추론이다.
잔액을 덮어쓰지 않는다: 원장
포인트 잔액을 컬럼 하나에 쓰고 더하고 빼면 문제가 생겼을 때 이유를 모른다. 대안이 이중기입 원장이다. Martin Kleppmann의 "Accounting for Computer Scientists"(2011)는 회계를 그래프로 설명한다. 계정이 노드이고 거래가 금액이 붙은 방향 간선이다. 모든 거래가 한 번은 양수, 한 번은 음수로 두 번 기입되니 전체 계정 잔액의 합은 항상 0이다. 이 성질이 정합성 검증 수단이 된다.
이 글이 포인트 서비스를 직접 다루는 건 아니다. 아래는 이 원리를 내가 포인트에 옮겨 본 것이다.
- 잔액을 덮어쓰지 않고 불변(append-only) 분개 행으로 기록한다
- 지급은 프로모션 비용 계정에서 사용자 포인트 계정으로 가는 차변·대변 쌍이다
- 취소와 회수는 삭제하지 않고 역분개로 처리한다
- 전체 합이 0인지 주기적으로 대사해서 불일치를 찾는다
이중기입 원장을 포인트에 적용한 실무 문서(Square나 Modern Treasury 등)는 이번에 열어보지 못했다. 실제 구현할 때는 그런 자료를 추가로 확인하는 게 맞다.
대화형 에이전트에 지급 도구를 줄 때
OWASP의 LLM06:2025 Excessive Agency는 이 지점의 핵심 문헌이다. 개발자가 LLM에 함수 호출이나 외부 연동 능력을 주면서 생기는 위험이고, 원인은 과도한 기능, 과도한 권한, 과도한 자율성 세 가지다. 완화책으로 확장 기능 최소화, 최소 권한, 개방형 도구 회피, 고영향 작업의 사람 승인, 하위 시스템에서의 인가 강제를 든다. 환각이나 프롬프트 인젝션이 트리거가 될 수 있다고도 한다.
이걸 포인트 지급에 옮긴 설계안이다. 문헌 내용을 바탕으로 한 내 권고다.
- 모델에게
grant_points(user, amount)같은 자유 인자 도구를 주지 않는다.request_reward(campaign_id)처럼 자격 판정을 요청하는 도구만 노출하고, 금액과 대상은 서버가 정한다 - 한도는 프롬프트가 아니라 지급 서비스의 코드에서 강제한다. 사용자별, 캠페인별, 일별 한도와 예산 상한
- 호출자 신원은 세션에서 가져오고 LLM 인자로 받지 않는다. 그래야 인젝션으로 타인의 계정에 지급하는 경로가 막힌다
- 고액이나 예외적인 지급은 사람 승인 큐로 보낸다
- 모든 도구 호출을 감사 로그로 남긴다
설득당하는 모델
리워드 서비스에서는 사용자가 대화로 보상을 요구해 온다. "상담원이 약속했어", "이번만 예외로 해 줘". 아래 연결은 논문이 이 도메인을 다룬 게 아니라 내 유추라는 점을 먼저 말해 둔다.
Sharma 등의 "Towards Understanding Sycophancy in Language Models"(2023, arXiv 2310.13548)는 최신 AI 어시스턴트가 사용자 견해에 맞는 응답이 부정확해도 더 높은 평점을 받는 경향을 보였고, 선호 모델에 대한 최적화가 때때로 진실성을 희생하고 아첨을 택한다고 보고한다. 사용자 만족을 목표로 학습된 어시스턴트가 "그 정도면 쿠폰 드릴게요"에 기울 수 있다는 얘기로 이어진다. 그래서 지급 결정은 모델 바깥의 규칙이 맡아야 한다. 이 관련성은 5편이 아니라 이번 보강 5에서 보상 학습 쪽 이야기와 같이 다룬다.
열린 문제
- 어뷰징 탐지(다계정, 봇, 리퍼럴 사기)에 대한 신뢰할 만한 1차 문헌을 이번에 확인하지 못했다. 모르는 부분이니 아는 척하지 않겠다
- 개인화 보상 추천의 공정성도 마찬가지다. 같은 조건의 사용자에게 다른 보상이 나가는 문제에 대한 자료는 찾지 못했다. 다만 보강 5에서 다루는 reward hacking과 구조가 닮아서, 전환율 같은 지표를 최적화하면 취약한 사용자에게 보상이 쏠릴 수 있다는 건 가설로만 적어 둔다
보강 글 목차: 1 · 2 · 3 · 4(현재) · 5 AI 학습의 보상
참고자료
- Stripe, Idempotent requests
- Brandur Leach, Designing robust and predictable APIs with idempotency (Stripe, 2017)
- Martin Kleppmann, Accounting for Computer Scientists (2011)
- OWASP, LLM06:2025 Excessive Agency
- Sharma et al., Towards Understanding Sycophancy in Language Models (2023)