AI 에이전트가 A/B 테스트 선택을 직접 하게 두지 마세요 — MCP를 통해 실제 Contextual Bandit 연결하기 (무료, 키

만약 LLM 에이전트에게 A/B 변형(variants) 테이블을 주고 "다음에 어떤 것을 보내야 할까요?"라고 묻는다면, 에이전트는 확신에 차서 전환율(conversion rate)이 가장 높은 것을 선택할 것입니다.

그것이 맞는 것처럼 느껴지지만, 종종 틀립니다.

모델은 표본 크기 (sample size), 탐색 (exploration), 또는 _후회 (regret)_에 대한 개념이 없습니다. 모델은 "가장 큰 숫자 = 승자"라는 패턴을 매칭하고 넘어가 버립니다. 일회성 질문이라면 괜찮습니다. 하지만 이메일 제목, 광고 문구, 모델 라우팅(model routing), 추천 순위(recommendation ranking)와 같이 매 요청마다 변형을 선택하는 에이전트 루프(agent loop) 내부에서는, 이러한 순진한 선택이 조용히 후회(regret)를 축적하고 공정한 기회를 얻지 못한 옵션들을 고사시킵니다.

해결책은 더 나은 프롬프트를 만드는 것이 아닙니다. LLM에게 수학 계산을 아예 시키지 않는 것입니다. 결정을 실제 밴딧(bandit) 알고리즘으로 라우팅하고, 모델은 모델이 잘하는 일(오케스트레이션, 언어)을 하게 두는 한편, 결정론적 솔버(deterministic solver)가 잘하는 일(최적화)을 하게 하세요.

이 포스트는 회원 가입이나 API 키 없이 지금 당장 터미널에서 실행할 수 있는 복사-붙여넣기 데모입니다. 저는 결정론적 의사결정 지능(decision-intelligence) MCP 서버인 OraClaw를 사용하겠지만, 도구와 상관없이 핵심은 동일합니다. 모델이 검증할 수 있는 수학을 추측하게 만들지 마세요.

구체적인 함정

다음은 실험 중간의 현실적인 상태입니다. 세 가지 제목과 서로 다른 트래픽 양입니다:

변형 (Variant)	풀 (Pulls)	보상 (Rewards, 전환)	원시 비율 (Raw rate)
A	120	18	15.0%
...

LLM에게 "다음에 무엇을 보내야 할까요?"라고 물으면 보통 B를 얻게 됩니다. B는 충분히 테스트된 변형들 중에서 가장 좋은 비율을 가지고 있고, C는 "샘플이 15개뿐이라 너무 노이즈가 심해 신뢰할 수 없다"라고 답하기 때문입니다.

이러한 추론은 책임감 있게 들리지만, 정확히 반대입니다. 단 15번의 풀(pull)만 수행된 상태에서 C는 탐색이 부족한 (under-explored) 상태입니다. 우리는 C가 실제로 더 나쁘다는 것을 알지 못하며, 이를 확인하는 비용은 매우 작습니다. 밴딧(bandit)의 전체 역할은 불확실성을 무시하는 대신 그 무게를 측정하는 것입니다.

진짜 답변을 얻어봅시다.

직접 실행해 보세요: 키가 필요 없는 REST 엔드포인트 (60초)

curl -s -X POST https://oraclaw-api.onrender.com/api/v1/optimize/bandit \
  -H "Content-Type: application/json" \
  -d '{
...

응답 (이것이 실제 출력이며, 축약되었습니다):

{
  "selected": { "id": "variant_c", "name": "Subject line C" },
  "score": 1.4633997784480877,
...

UCB1은 C를 선택하며, 응답은 당신이 감사(audit)할 수 있는 방식으로 그 이유를 보여줍니다: 낮은 exploitation (exploitation, 착취) 항(관찰된 비율이 보통임)을 갖지만 높은 exploration (exploration, 탐색) 보너스(테스트를 거의 해보지 않음)를 가집니다. 이 둘의 합인 상한 신뢰 구간 (upper confidence bound)이 실제로 최적화되는 대상입니다. 이것이 바로 LLM이 그저 암시만 했던, "샘플링이 부족한 옵션에 기회를 주자"라는 원칙적인 추론입니다.

주목할 만한 두 가지 사항이 있습니다:

• 결정론적(Deterministic)입니다. 해당 curl 명령을 다시 실행하면 정확히 동일한 score: 1.4633997784480877을 얻게 됩니다. UCB1에는 무작위성이 없습니다. 동일한 입력은 항상 동일한 결정을 내립니다. 이것이 CI 테스트에 넣을 수 있는 도구와, 실행할 때마다 답변이 표류(drift)하는 모델 사이의 차이점입니다. (만약 확률적(stochastic) 탐색을 원한다면, "algorithm": "thompson"으로 교체하세요.)
• 키가 필요 없습니다. 무료 티어는 IP 속도 제한(IP-rate-limited)이 걸려 있을 뿐, 인증(auth-gated)이 필요한 것은 아닙니다. 이메일을 제공하지 않고도 전체 과정을 검증했습니다.

이제 에이전트에 연결하세요 (진정한 핵심)

REST 호출은 증거일 뿐입니다. 진짜 인체공학적 편의성(ergonomics)은 MCP에서 나옵니다. 당신의 에이전트는 별도의 글루 코드(glue code) 없이 다른 도구와 마찬가지로 이를 호출합니다.

단 한 줄로 Claude Code(또는 모든 MCP 클라이언트)에 서버를 추가하세요:

claude mcp add oraclaw -- npx -y @oraclaw/mcp-server

또는 클라이언트 설정에 바로 넣으세요:

{
  "mcpServers": {
    "oraclaw": {
...

이제 당신의 에이전트는 optimize_bandit 도구를 갖게 됩니다. 모델에게 탐색에 대해 추론하도록 *프롬프트(prompting)*를 주는 대신, 솔버(solver)를 호출하고 검증 가능한 결과에 따라 행동하게 만듭니다. MCP 호출은 동일한 페이로드(동일한 score: 1.4633997784480877)를 반환합니다. MCP 서버와 REST API는 동일한 엔진입니다.

최선의 선택이 컨텍스트(context)에 따라 달라질 때

일반적인 밴딧 (bandit)은 최적의 암 (arm)이 고정되어 있다고 가정합니다. 하지만 실제로는 그렇지 않은 경우가 많습니다. 적절한 모델/경로/변형 (variant)은 요청에 따라 달라집니다. 이것이 바로 컨텍스추얼 (contextual) 밴딧이며, 단 하나의 도구 교체(optimize_contextual, LinUCB 구현체)만으로 가능합니다. 현재 상황을 설명하는 피처 벡터 (feature vector)를 입력하세요:

curl -s -X POST https://oraclaw-api.onrender.com/api/v1/optimize/contextual-bandit \
  -H "Content-Type: application/json" \
  -d '{
...

여기서 컨텍스트 벡터 (context vector)는 [task_difficulty, latency_budget, needs_reasoning]를 인코딩할 수 있습니다. 난이도가 낮고 지연 시간 (latency)에 민감한 작업에서 승리하는 모델은 어려운 추론 (reasoning) 작업에서 승리하는 모델과 다릅니다. LinUCB는 사용자가 직접 if difficulty > 0.7과 같은 취약한 계층 구조를 수동으로 유지하는 대신, 과거 이력으로부터 그 매핑을 학습합니다. 이것이

1. 위의 curl 명령어를 실행하세요 — 가입 없이도 결정론적 (deterministic) 출력을 직접 확인할 수 있습니다: https://oraclaw-api.onrender.com/api/v1/health (모든 엔드포인트 목록을 보여줍니다).
2. 단 한 줄로 에이전트(agent)에 추가하세요:

   claude mcp add oraclaw -- npx -y @oraclaw/mcp-server

무료 MCP 도구는 키(key)가 필요하지 않습니다.

1. 해당 도구를 빈번하게 호출하는 무언가를 구축 중인가요? 무료 키(이메일만 입력)를 사용하면 제한(limits)이 상향됩니다:

   curl -s -X POST https://oraclaw-api.onrender.com/api/v1/auth/signup \
     -H "Content-Type: application/json" -d '{"email":"you@example.com"}'

무료 티어(free tier)를 초과하는 경우, 월 $9부터 더 높은 제한이 시작됩니다 — 여기서 직접 결제하세요. 하지만 이 포스트에 나온 모든 기능은 $0로 이용할 수 있습니다.

만약 당신의 에이전트가 의사결정을 내리고 있다면, 검증 가능한 결정을 내리게 하세요. 모델에게 수학적 계산을 눈대중으로 처리하라고 요구하는 것을 멈추고 — 증명 가능한 방식으로 정확한 결과를 도출하는 무언가로 경로를 지정(route)하세요.

데모를 실행해 본 후, 당신의 에이전트가 하지 말았어야 할 어떤 것을 눈대중으로 처리하고 있었는지 댓글로 알려주세요.