두 개의 사이드 프로젝트를 결합해 보았습니다 — 그 화학 반응은 이렇습니다

제 노트북에는 완전히 다른 이유로 만들어진 두 개의 작은 사이드 프로젝트가 있었습니다. 하나는 천 명의 사람이 동시에 "구매"를 클릭하더라도 재고보다 더 많은 아이템을 판매하는 것을 거부하는 타임 세일(flash-sale) 스토어입니다. 다른 하나는 당신을 대신해 쇼핑을 하지만, 실제로 돈을 쓰기 전에 "이대로 괜찮을까요?"라고 멈춰서 물어보는 AI 에이전트(AI agent)입니다. 두 프로젝트 모두 작동하기 위해 서로를 필요로 하지는 않았습니다. 하지만 저는 만약 이 둘을 강제로 결합한다면 어떤 일이 벌어질지 계속 궁금했습니다. 즉, 매 초가 중요한 스토어를 향해 허락을 구하는 AI 말입니다. 그래서 시도해 보았고, 이는 놀라울 정도로 명확한 해답을 주는 작은 실험이 되었습니다.

프로젝트 1: 절대 초과 판매하지 않는 스토어

첫 번째 프로젝트의 이름은 DROPZERO입니다. 스니커즈 드롭(sneaker drop)이나 콘서트 티켓 판매를 생각해보세요. 정해진 수량의 아이템이 있고, 판매할 아이템보다 훨씬 더 많은 사람이 구매를 시도합니다. 타이머가 0에 도달하는 순간, 모든 사람이 동시에 "구매"를 누릅니다. 대부분의 온라인 스토어는 한 구매가 완료되는 동안 인벤토리(inventory) 행을 잠그는(locking) 방식으로 이를 처리하며, 이는 작동은 하지만 실제적인 폭주 상황에서는 그 잠금이 교통 체증으로 변합니다. 어떤 스토어들은 아예 잠금을 하지 않아서 재고가 10개뿐인 스니커즈를 12켤레 판매해 버리기도 합니다. 즉, "초과 판매(oversell)\

두 번째 프로젝트는 wallet-agent입니다. 이는 사용자를 대신해 쇼핑을 하도록 구축된 AI 에이전트(AI agent)입니다. 무언가를 검색하고, 그것이 좋은 구매라고 결정한 뒤, 구매까지 진행합니다. 반전은 이 에이전트가 마음대로 돈을 쓸 수 없다는 점입니다. 모든 구매 전에 에이전트는 동작을 멈추고, 무엇을 왜 사고 싶은지 사용자에게 보여준 뒤, 사람이 승인(yes) 또는 거절(no)을 할 때까지 기다려야 합니다. 저는 이것을 승인 게이트(approval gate)라고 부르며, 이는 직원이 큰 주문을 하기 전에 관리자의 결재를 받아야 하는 것과 같은 개념입니다.

이것은 들리는 것보다 더 중요합니다. 아무도 확인하지 않는 상태에서 돈을 쓸 수 있는 AI 에이전트는 다소 무서울 수 있습니다. 잘못된 물건을 사거나, 너무 많이 사거나, 혹은 사지 말아야 할 것을 사도록 속을 수도 있기 때문입니다. 승인 게이트는 이를 위한 안전벨트와 같습니다. 하지만 안전벨트는 속도를 약간 늦추기도 하며, 저는 바로 그 트레이드오프(trade-off)를 측정하고 싶었습니다.

결합하기

저는 wallet-agent에 세 가지 새로운 도구(tool)를 부여했습니다. 하나는 DROPZERO의 현재 재고를 확인하는 도구, 하나는 사람에게 승인을 요청하는 도구, 그리고 승인되었을 때 실제로 구매를 진행하는 도구입니다.

저는 이를 처음부터 끝까지 한 번 실행해 보았습니다. 에이전트는 재고를 확인했고, 정확히 한 개의 아이템이 남은 것을 확인한 뒤, 왜 지금 구매하고 싶은지 설명하는 승인 카드("마지막 남은 제품입니다, 놓치고 싶지 않습니다")를 출력하고 기다렸습니다. 저는 다른 터미널에서 approve를 입력했습니다. 몇 초 후 에이전트는 DROPZERO의 구매 API를 호출했고, 페이지는 "지금 구매(buy now)"에서 "품절(sold out)"로 바뀌었습니다. 한 명의 에이전트, 한 번의 사람의 끄덕임, 하나의 확정된 주문. 제가 희망했던 방식 그대로 작동했습니다. 보통 이 지점이 제가 데모를 신뢰하는 것을 멈추고, 그것을 망가뜨려 보려고 시도하기 시작하는 단계입니다.

실험: "허락을 구하는 것"의 실제 비용은 얼마인가?

제가 실제로 궁금했던 질문은 이것입니다. DROPZERO는 매 순간이 중요한 세상을 위해 구축되었습니다. 반면 wallet-agent는 멈춰서 인간을 기다리도록 구축되었습니다. 이 두 가지를 같은 공간에 두면 어떤 일이 벌어질까요?

저는 부하 테스트 (load-testing) 도구인 k6를 사용하여 작은 테스트를 실행했습니다. DROPZERO의 재고를 20개로 설정한 다음, 두 그룹의 100회 구매 시도를 동시에 보냈습니다.

• 그룹 A ("승인 없음"): 결정하는 즉시 대기 없이 구매합니다.
• 그룹 B ("승인 포함"): 인간이 승인 카드(approval card)를 확인하고 '예'를 누르는 데 걸리는 시간을 대신하기 위해 잠시 기다립니다. 지연 시간(delay)은 0, 0.5, 1, 3, 5초로 설정했습니다.

두 그룹은 동시에 동일한 20개의 아이템을 두고 경쟁했습니다. 결과는 다음과 같습니다.

지연 시간이 3초에 도달했을 때, 승인 그룹은 단 하나의 아이템도 얻지 못했습니다. 100번의 시도 중 단 한 번도 없었습니다. 모든 아이템은 멈춰서 묻지 않은 그룹에게 돌아갔습니다.

하지만 저를 실제로 놀라게 한 부분은 패배의 연속이 아니었습니다. 바로 이것이었습니다: 모든 실행에서 성공한 총 구매 건수가 재고 수량과 정확히 일치했습니다. 두 그룹이 어떻게 나누어 가졌든 상관없이, 재고 20개에 확정 주문 20개가 발생했습니다. 단 20개의 아이템에 대해 200개의 요청을 몰아붙였을 때조차, 상점이 초과 판매 (oversell)하는 일은 단 한 번도 없었습니다.

이것이 실제로 의미하는 바

승인 여부와 상관없이 DROPZERO의 데이터베이스는 초과 판매의 위험이 전혀 없었습니다. 그 보장은 인간이 개입 (human in the loop)하기 때문이 아니라, 데이터베이스 자체에서 나옵니다. 승인 단계가 실제로 당신에게 치르게 하는 비용은 바로 속도이며, 선착순 (first-come-first-served) 상황에서는 속도가 전부입니다. "이대로 괜찮을까요?"라고 묻기 위해 몇 초를 기다리는 것은 상점을 더 안전하게 만들지 않습니다. 그저 멈춰서 묻지 않은 누군가에게 경주에서 패배한다는 것을 의미할 뿐입니다.

만약 여러분이 언젠가 AI 에이전트 (AI agent)가 여러분을 대신해 돈을 쓰도록 허용할 수 있는 무언가를 구축하고 있다면, 이는 진정으로 유용한 지식입니다. 승인 게이트 (Approval gate)는 에이전트가 어리석거나 승인되지 않은 행동을 하는 것을 막기 위한 훌륭한 아이디어입니다. 하지만 이것이 데이터베이스의 초과 판매 (overselling)를 방지하는 방법은 아닙니다. 그 역할은 데이터베이스의 몫이며, DROPZERO는 wallet-agent가 등장하기 전부터 이미 그 기능을 갖추고 있었습니다. 각 구성 요소가 실제로 어떤 문제를 해결하는지 아는 것이 중요합니다. 왜냐하면 "인간을 루프에 추가하기 (add a human in the loop)"라는 말은 모든 것에 대한 안전 업그레이드처럼 들리지만, 여기서는 이 특정 문제에 대한 해결책이 전혀 아니었기 때문입니다.

직접 시도해 보세요

원본 프로젝트와 결합된 프로젝트 모두 오픈 소스 (open source)입니다:

• dsql-drop-app — 초과 판매가 없는 플래시 세일 상점, DROPZERO
• wallet-agent — 승인 게이트를 갖춘 AI 쇼핑 에이전트
• dropzero-wallet-agent — 결합된 프로젝트, 그리고 전체 실험 및 결과

서로 아무런 관련이 없는 두 개의 작은 프로젝트를 가지고 있다면, 그것들을 같은 방에 강제로 밀어 넣어 볼 가치가 있을지도 모릅니다. 어쩌면 그중 어느 하나도 단독으로는 가르쳐 줄 수 없었던 무언가를 배우게 될 수도 있습니다.