PyTorchKR - 최신 글

Claude Opus 5.5 마이그레이션 가이드 소개 Anthropic 의 Claude Opus 5.5 마이그레이션 가이드 는 기존 Messages API 코드를 claude-opus-5-5 로 옮길 때 바꿔야 하는 요청 설정과 응답 처리 코드를 출발 모델별로 정리한 공식 문서입니다. Opus 5.5는 Opus 5에서 문제없이 돌던 요청 중 일부를 400…

GravityOCR 소개 GravityOCR은 문서 이미지를 텍스트, HTML 표, LaTeX 수식으로 옮기는 OCR 모델로, 하나의 가중치가 확산(Diffusion) 방식으로 여러 토큰의 초안을 한 번에 쓰고 같은 모델의 자기회귀(AR) 경로가 그 초안을 검증하는 방식으로 디코딩 속도를 높였습니다. 기반 모델인 GLM-OCR ( GLM-OCR: 0.9B…

Top-Conf Figure Gallery 소개 논문의 첫 번째 그림인 Figure 1(또는 티저(Teaser) 그림)은 연구 내용을 한 장으로 압축하는 개요도(Overview Figure) 역할을 하는 경우가 많아, 모듈과 화살표를 어떻게 배치할지 정하는 데 시간이 오래 걸립니다. 참고할 만한 예시를 찾으려면 보통 학회 프로시딩(Proceedings)에…

한 장의 이미지에서 시작해 보세요. Image to 3D AI는 캐릭터, 제품 이미지, 스케치, 컨셉 아트 등을 바탕으로 3D 모델을 생성할 수 있는 온라인 AI 도구입니다. 복잡한 3D 프로그램을 먼저 배울 필요 없이, 이미 가지고 있는 이미지를 업로드하고 결과를 확인해 보세요. 이미지 하나로, 생각보다 빠르게 3D를 시작할 수 있습니다. 이미지를 올리…

AI 에이전트 평가가 도구 호출 채점에서 과업 완수 채점으로 옮겨간 이유 NVIDIA 기술 블로그 가 2026년 9월 21일 공개한 How to Evaluate AI Agents From Tool Calls to Task Completion 은 AI 에이전트 의 평가 방법이 함수 호출 한 건을 채점하는 방식에서 과업 전체를 채점하는 방식으로 어떻게 옮겨왔…

Step 5 Preview 소개 StepFun (阶跃星辰)이 에이전트 작업을 겨냥한 플래그십 모델 Step 5 Preview 를 공개했습니다. 희소 전문가 혼합(Mixture-of-Experts, MoE) 구조로 전체 600B 파라미터 중 토큰당 27B만 활성화하고, 1M 토큰 컨텍스트 윈도우와 이미지 및 영상 입력을 함께 지원합니다. StepFun은 이…

GPT-6 Sol과 Luna 소개 OpenAI 가 2026년 9월 22일, GPT-6 제품군의 중간 티어 GPT-6 Sol 과 경량 티어 GPT-6 Luna 를 공개했습니다. 이달 초 출시한 최상위 모델 GPT-6 Astra 와 비슷한 방법으로 학습한 더 빠르고 저렴한 모델이며, API 가격은 GPT-5.6 Sol과 Luna의 프로모션 가격 대비 50%…

Claude Opus 5.5 소개 Anthropic 이 2026년 9월 22일 새 5.5 세대의 첫 모델인 Claude Opus 5.5 를 공개했습니다. Anthropic은 이 모델이 대부분의 작업에서 Claude Fable 5.1 수준으로 동작하면서, 일반적인 작업량 기준 실행 비용은 Claude Opus 5 보다 40% 낮다고 밝혔습니다. 한 줄로 요…

pgjev 소개 고객 문의 테이블에서 화가 난 고객이 보낸 문의만 골라내는 작업을 생각해 보면, PostgreSQL 안에서 쓸 수 있는 수단이 생각보다 좁습니다. 전문 검색(Full Text Search) 은 키워드가 들어 있는지를 볼 뿐이라 환불을 요구하지는 않았는데 화가 난 문의를 가려내지 못합니다. pgvector 로 임베딩(Embedding) 컬럼…

AIPerf 소개: 측정 도구가 측정 대상을 가려 버리는 문제

모델을 서버에 올리고 프롬프트를 던지면 응답이 돌아옵니다. 그다음에 반드시 나오는 질문은 "이거 빠른 건가요?" 입니다. 이 질문에 답하려고 개발자들이 가장 먼저 하는 일은 대개 curl을 몇 번 날려 보거나, asyncio 기반의 짧은 부하 스크립트를 직접 짜거나, 일회용 부하 생성기를 하나 더 만드는 것입니다. NVIDIA 기술 블로그가 지적하는 문제는 이 세 갈래가 결국 같은 곳에서 무너진다는 점입니다. 단일 프로세스의 성능 한계에 걸리거나, 파이썬의 전역 인터프리터 잠금(Global Interpreter Lock, GIL) 이 동시성을 제한하거나, 애초에 자기가 만든 기준선에 대고 측정한 숫자가 나옵니다. 어느 쪽이든 완전히 신뢰하기 어려운 결과가, 요구사항이 바뀌는 순간 다시 짜야 하는 도구에 묶인 채로 남습니다.

이 문제가 LLM 서빙에서 유독 고약한 이유가 있습니다. 부하 생성기가 병목이 되면 측정값은 서버의 성능이 아니라 클라이언트의 성능을 반영하게 되는데, 겉으로는 구분이 되지 않습니다. 서버가 낼 수 있는 토큰 속도보다 클라이언트가 파싱할 수 있는 속도가 낮으면 리포트에는 낮은 쪽 숫자가 찍히고, 그 숫자를 근거로 GPU를 더 사는 결정이 내려집니다. 게다가 LLM 추론은 요청 하나가 수 초 동안 스트리밍되면서 수십에서 수백 개의 청크를 보내기 때문에, 부하 생성기가 처리해야 하는 이벤트 수가 일반적인 HTTP 벤치마크와 자릿수가 다릅니다.

AIPerf는 이 지점을 겨냥해 NVIDIA가 바닥부터 다시 만든 생성형 AI 추론(inference) 벤치마크 도구입니다. NVIDIA는 AIPerf를 Triton Inference Server의 perf_analyzer 안에 있던 GenAI-Perf의 지정된 후속 도구(designated successor) 로 규정하고, GenAI-Perf가 얹혀 있던 Perf Analyzer 위에서 돌아가는 구조 자체를 끊어 냈습니다. 저장소는 ai-dynamo 조직 아래에 있어 같은 조직의 추론 프레임워크인 Dynamo와 나란히 관리되고, Apache License 2.0으로 공개되어 있으며, PyPI에는 aiperf 패키지로 올라가 있습니다. 2026년 9월 21일 기준 최신 버전은 0.12.0이고 Python 3.11 이상 3.14 미만을 요구합니다.

이 글은 2026년 9월 18일에 Francesco Di Natale, Elias Bermudez, Anthony Casagrande, Matthew Kotila, Harshini Komali, Ganesh Kudleppanavar가 함께 쓴 NVIDIA 기술 블로그 Benchmarking LLM Inference at Scale with AIPerf를 바탕으로, 원문이 짧게 스치고 지나간 개념들을 AIPerf 저장소의 문서로 보강해 정리한 것입니다.

세 개의 평면으로 나눈 구조: 클라이언트가 병목이 되지 않는다는 것

AIPerf가 "클라이언트가 병목이 되지 않는다"고 말할 때 그것은 구호가 아니라 프로세스 배치의 결과입니다. 저장소 README는 AIPerf를 10개의 서비스가 ZeroMQ 메시지 버스로 통신하는 다중 프로세스 구조라고 요약합니다. 아키텍처 문서는 이 서비스들을 역할에 따라 세 개의 평면으로 나눕니다.

핵심은 요청을 보내는 주체와 결과를 해석하는 주체가 서로 다른 프로세스라는 점입니다. Worker는 HTTP 요청을 보내고 응답 타이밍만 기록한 뒤 곧바로 다음 요청으로 넘어가고, 스트리밍 청크를 파싱해서 TTFT와 ITL을 계산하는 무거운 일은 Record Processor가 별도 프로세스에서 병렬로 처리합니다. GIL이 문제가 되는 지점이 바로 이 파싱과 계산인데, 그것을 요청 발송 경로에서 떼어 냈기 때문에 Worker를 10개, 50개, 100개로 늘리는 것이 그대로 부하 용량 증가로 이어집니다. Worker들 사이에는 조율이 없으므로 수평 확장에 조정 비용도 들지 않습니다.

부하의 시점을 맞추는 방식도 눈여겨볼 만합니다. AIPerf는 Timing Manager가 발급하는 크레딧(credit) 을 Worker가 받아야만 요청을 보낼 수 있는 구조입니다. 요청을 언제 보낼지 결정하는 책임이 Worker가 아니라 중앙의 Timing Manager에 있으므로, 포아송 분포에 따른 불규칙한 도착이든 트레이스에 기록된 실제 시각이든 동일한 메커니즘으로 재현됩니다. 데이터셋 역시 메시지로 주고받지 않고 메모리 맵 파일(memory-mapped file) 에 써 두어 Worker가 직접 읽게 함으로써, 프롬프트 전달이 메시지 버스의 부하가 되지 않도록 했습니다.

이 구조 위에서 원문이 내세우는 두 가지 폭이 나옵니다. 하나는 워크로드의 폭입니다. 원문은 15종 이상의 엔드포인트 타입을 지원한다고 적었는데, 저장소의 플러그인 정의 파일을 직접 세어 보면 현재 등록된 엔드포인트 플러그인은 19종입니다(폴백용 raw 와 플러그인 개발용 template 포함). 채팅과 텍스트 완성, OpenAI Responses API, Anthropic Messages API, 임베딩, 리랭킹(NIM, Hugging Face TEI, Cohere 각각 별도 구현), 음성 인식, 이미지 생성과 편집, 영상 생성까지 들어 있습니다. 여기에 ShareGPT 같은 공개 데이터셋과 Mooncake, Baseten, WEKA 등의 프로덕션 트레이스 재생 포맷이 더해집니다.

다른 하나는 부하 모양의 폭입니다. 총량만 정하는 것이 아니라 요청이 어떤 리듬으로 도착하는지, 동시성과 요청 속도를 얼마 동안 서서히 올릴지, 입출력 길이를 vLLM과 SGLang의 range-ratio 방식으로 흩뿌릴지까지 지정할 수 있습니다. 도착 리듬은 뒤에서 따로 다룹니다.

첫 벤치마크: vLLM 위의 Qwen3-0.6B에 정적 128/128 부하 걸기

원문의 실습은 vLLM으로 서빙한 Qwen3-0.6B를 대상으로 합니다. 모델 선택은 의도적입니다. GPU 한 장에서 돌아갈 만큼 작고, 기다리지 않고 반복할 수 있을 만큼 빠릅니다. 목적은 Qwen3-0.6B 자체를 평가하는 것이 아니라 측정 루프를 만드는 것이고, 루프가 손에 익으면 다른 모델이나 엔드포인트로 바꾸는 것은 플래그 하나를 고치는 일이 됩니다.

서버는 vLLM의 OpenAI 호환 컨테이너를 그대로 씁니다. 추론 파서를 켜 두는 것이 중요한데, 그 이유는 뒤의 TTFT 절에서 설명합니다. 한 가지 덧붙이면, 저장소의 기본 튜토리얼은 같은 명령에 --enforce-eager 를 더 붙입니다. CUDA 그래프 캡쳐를 끄는 옵션이라 기동은 빨라지지만 디코딩 성능은 달라지므로, 블로그의 숫자와 튜토리얼의 숫자를 나란히 놓고 비교할 생각이라면 이 차이를 먼저 맞춰야 합니다.

docker pull vllm/vllm-openai:latest
docker run --gpus all -p 8000:8000 -e HF_TOKEN vllm/vllm-openai:latest \
  --model Qwen/Qwen3-0.6B \
  --reasoning-parser qwen3 \
  --host 0.0.0.0 --port 8000

AIPerf 설치는 uv로 한 벌을 전역에 두거나, 가상 환경 안에 넣는 두 가지 방법이 있습니다.

uv tool install aiperf

uv venv venv
source venv/bin/activate
uv pip install aiperf

플랫폼과 관련해 한 가지 주의할 점이 있습니다. Linux aarch64(arm64) 에서는 의존성 중 하나인 crick 이 소스 배포본만 제공하므로 설치 시점에 C 컴파일러가 필요합니다. Debian과 Ubuntu 계열은 build-essential, RHEL 계열은 Development Tools 를 미리 깔아 두어야 하고, 설치가 그 패키지에서 멈춰 있다면 원인은 십중팔구 이것입니다. x86_64 Linux와 macOS, Windows는 미리 빌드된 휠을 받으므로 툴체인이 필요 없습니다.

서버가 준비되고 AIPerf 설치가 끝났으면 첫 프로파일을 실행합니다.

aiperf profile \
  --model Qwen/Qwen3-0.6B \
  --endpoint-type chat \
  --streaming \
  --url localhost:8000 \
  --synthetic-input-tokens-mean 128 \
  --synthetic-input-tokens-stddev 0 \
  --output-tokens-mean 128 \
  --output-tokens-stddev 0 \
  --extra-inputs min_tokens:128 \
  --extra-inputs ignore_eos:true

실행 중에는 대시보드가 실행됩니다. 정확히는 대화형 터미널에서만 dashboard 가 기본값이고, 출력이 파이프나 리다이렉션으로 넘어가는 비대화형 환경에서는 자동으로 none 이 됩니다. 화면은 세 구역으로 나뉘어 위쪽 3분의 2의 왼편에 진행 상황이, 오른편에 백분위별로 쪼갠 지표가 실시간으로 갱신되고, 아래쪽 3분의 1에는 백엔드 로그가 흐릅니다. 대시보드 대신 진행 막대만 보는 simple 모드도 있으며, --verbose 를 주면 터미널에서도 자동으로 simple 로 바뀝니다. CI에서 돌릴 때 --ui none 을 따로 붙일 필요는 없습니다.

대시보드 오른편을 자세히 보면 AIPerf가 클라이언트에서 잰 값만 보여주는 것이 아니라는 점을 알 수 있습니다. 접두어 캐시 적중률(Prefix Cache Hit Rate), KV 캐시(Key-Value Cache) 사용률, 서버에서 실행 중인 요청 수와 대기 중인 요청 수, 선점(preemption) 횟수 같은 항목이 함께 올라와 있습니다. 이것은 AIPerf가 모델 엔드포인트의 /metrics 경로를 수집하는 서버 지표(server metrics) 기능으로, 기본값이 활성화입니다. 클라이언트가 관측한 지연이 길어졌을 때 그것이 큐 대기 때문인지 KV 캐시 압박 때문인지를 별도 도구 없이 같은 화면에서 대조할 수 있습니다.

플래그 네 개가 결과를 좌우합니다

위 명령에서 겉보기보다 훨씬 큰 일을 하는 플래그가 넷 있습니다. 벤치마크 결과가 재현되지 않거나 남의 숫자와 어긋난다면 대개 이 넷 중 하나가 빠져 있습니다.

--synthetic-input-tokens-stddev 0 과 --output-tokens-stddev 0: 입력과 출력을 정확히 128토큰으로 고정합니다. 요청 길이와 출력 길이를 상수로 고정하는, 널리 쓰이는 정적 벤치마크 설정을 재현하는 것입니다.

--extra-inputs min_tokens:128 과 --extra-inputs ignore_eos:true: 모델이 실제로 128토큰을 생성하도록 강제합니다. 이 둘이 없으면 출력 토큰 수는 목표가 아니라 권고에 그칩니다. 모델은 자연스럽게 끝났다고 판단하는 지점에서 멈추므로 목표 출력 시퀀스 길이(Output Sequence Length, OSL)에 한참 못 미치는 경우가 생기고, 처리량은 실제보다 낮게 나오면서 실행마다 값이 달라집니다. AIPerf 저장소도 이 점을 알려진 문제로 명시해 두고 있습니다. 출력 길이 제약은 서버가 ignore_eos 와 min_tokens 를 지원할 때만 보장됩니다.

--streaming: TTFT와 ITL을 재려면 선택이 아니라 필수입니다. 스트리밍을 켜지 않으면 서버가 응답 전체를 모아 한 번에 보내므로, 첫 토큰 이벤트도 디코딩 토큰 이벤트도 존재하지 않아 잴 것이 없습니다.

핵심 지표 네 가지와, 평균 대신 백분위를 봐야 하는 이유

실행이 끝나면 AIPerf는 콘솔에 지표 표를 찍고 전체 결과를 CSV와 JSON으로 남깁니다. 아래가 원문이 보여준 정적 128/128 실행의 출력입니다.

먼저 가장 자주 인용되는 네 가지입니다. 지표 레퍼런스 문서에 실린 정의와 수식을 함께 정리합니다.

TTFT(Time to First Token): 요청을 보낸 시점부터 첫 토큰을 받기까지의 시간입니다. 대화형 서비스의 체감 반응성을 좌우하는 1차 지표이고, 네트워크 지연과 큐 대기, 프롬프트 처리, 첫 토큰 생성이 모두 포함됩니다. 수식으로는 \text{TTFT} = t_{\text{first chunk}} - t_{\text{request start}} 입니다.

ITL(Inter Token Latency): 생성 도중 연속한 토큰 사이의 평균 간격으로, TTFT 오버헤드를 뺀 정상 상태의 생성 속도를 나타냅니다. TTFT가 멀쩡해도 ITL이 높으면 디코딩 단계가 버거운 것입니다. 기본 계산식은 다음과 같습니다.

분모가 \text{OSL} - 1 인 것은 첫 청크에 토큰이 하나만 들어 있다고 가정하기 때문입니다. TensorRT-LLM의 stream-interval 처럼 서버가 첫 청크에 여러 토큰을 묶어 보내면 이 가정이 깨지면서 ITL이 과소평가되고 사용자당 처리량은 부풀려집니다. 이 경우 --per-chunk-usage 를 켜면 서버가 보고하는 누적 사용량을 근거로 분모가 \text{OSL} - \text{첫 청크 토큰 수} 로 바뀝니다. 다만 이 플래그는 단독으로 동작하지 않아서 --use-server-token-count 와 chat 엔드포인트, --streaming 이 함께 필요하고, 서버도 continuous_usage_stats 를 받아 주어야 합니다. vLLM과 TensorRT-LLM은 지원하지만 엄격한 OpenAI API는 거부합니다.

요청 지연(Request Latency): 응답 전체를 받기까지의 종단 간 시간입니다. 프리필과 디코딩 비용을 한 숫자로 합칩니다.

출력 토큰 처리량(Output Token Throughput): 동시에 처리되는 모든 요청을 합산한 초당 생성 토큰 수로, 용량 산정의 1차 지표입니다. \text{OutputTokenThroughput} = \text{TotalOSL} / \text{BenchmarkDuration} 으로 계산되므로 TTFT가 분모에 포함됩니다. 같은 이름처럼 보이는 사용자당 출력 토큰 처리량(Output Token Throughput Per User)은 1 / \text{ITL} 이라 TTFT를 제외하므로, 두 값을 직접 비교하면 안 됩니다.

이 넷을 포함한 모든 지표는 p25, p50, p75, p90, p95, p99 백분위와 최솟값, 최댓값, 평균, 표준편차로 함께 보고됩니다. 백분위가 중요한 이유는 꼬리에 있습니다. 위 화면에서 TTFT의 평균은 242.03ms지만 p99는 414.92ms이고 최댓값은 433.20ms입니다. 평균만 보면 건강해 보이는 서버의 꼬리가 1.7배 느리다는 뜻이고, 이런 서버는 집계에서 멀쩡해 보이다가 프로덕션에서 무너집니다. 다만 이 실행은 요청이 10건뿐이라 p99가 사실상 최댓값이므로, 백분위가 제 몫을 하는 것은 뒤에 나오는 200건 실행 쪽입니다.

여기에 더해 DCGM(Data Center GPU Manager)이나 pynvml을 쓸 수 있는 환경이라면 GPU 전력 소모와 사용률, 메모리 점유가 같은 실행 결과 안으로 들어옵니다. AMD GPU는 amdsmi로 수집합니다. 지연 스파이크와 메모리 압박 이벤트를 맞춰 보려고 별도 프로파일링 세션을 다시 잡을 필요가 없습니다.

Effective와 Active: 같은 실행에서 처리량이 14배 차이 나는 이유

위 스크린샷을 다시 보면 표가 세 개입니다. 맨 아래가 익숙한 지표 표이고, 위의 두 표는 각각 Effective 와 Active 라는 이름을 달고 있습니다. 원문은 이 두 표를 화면에 보여만 주고 설명하지 않는데, 저장소의 기술 개요 문서가 이유를 정리해 두었습니다. 요약하면 LLM 추론에는 산술 평균이 감추는 함정이 셋 있습니다.

첫째, 레코드 단위로 평균을 내면 빠른 요청 쪽으로 편향됩니다. 10초짜리 요청 하나에 1초짜리 아흔아홉 개인 실행과, 100초짜리 요청 하나에 1초짜리 아흔아홉 개인 실행은 레코드 산술 평균이 같습니다. 앞쪽이 훨씬 건강한 서버인데도 그렇습니다.

둘째, 전체 구간 평균은 빈 시간으로 희석됩니다. 요청 하나는 계산 집약적이고 짧은 프리필과 메모리 집약적이고 긴 디코딩의 두 단계를 거칩니다. 어느 순간을 잘라 보아도 진행 중인 요청의 대부분은 디코딩에 있고 프리필 구간은 짧고 드뭅니다. 그래서 전체 구간에 걸쳐 프리필 처리량을 평균 내면 디코딩만 진행되던 시간에 희석된, 하드웨어가 실제로 낸 것보다 훨씬 작은 숫자가 나옵니다.

셋째, 조율된 누락(coordinated omission) 입니다. 부하 생성기가 서버를 포화시키면 요청들이 발송 전에 AIPerf의 크레딧 큐에 쌓입니다. 서버 쪽 타이밍은 이 대기 시간을 빼고 재므로, 실제로 그 시각에 요청을 보낸 사용자가 겪었을 지연보다 낙관적인 숫자가 나옵니다.

AIPerf의 답은 시간 가중 평균입니다. 관심 있는 값의 계단 함수를 만든 뒤 전체 실행 구간에 대해 적분합니다.

Effective 지표는 이 식을 실행 전체 구간에 적용한 값이고, Active 지표는 해당 단계에 요청이 하나라도 진행 중인 구간으로만 적분 범위를 좁힌 값입니다. 백분위도 마찬가지로 시간 가중이라, "p99가 920 tok/s" 는 "실행 시간의 99% 동안 디코딩 처리량이 920 tok/s 이하였다" 는 뜻이지 "레코드의 99%가 그 이하" 라는 뜻이 아닙니다. 그리고 effective_latency 는 end_ns - credit_issued_ns 로 계산되어 크레딧 큐 대기까지 요청에 부과하는, AIPerf에서 유일하게 조율된 누락을 고려한 지연 지표입니다.

차이가 얼마나 큰지는 위 스크린샷의 숫자가 보여줍니다. 같은 실행에서 Effective Prefill Throughput은 36.47 tok/s인데 Active Prefill Throughput은 528.86 tok/s입니다. 14배가 넘는 격차인데, 둘 다 맞는 값입니다. 앞엣것은 "이 워크로드를 실행하는 동안 프리필에 쓰인 평균 능력" 이고 뒤엣것은 "프리필이 실제로 진행되고 있을 때의 강도" 입니다. 문서가 제시하는 인용 기준은 명확합니다. 측정한 워크로드 조합 그대로 용량을 산정할 때는 Effective를, 단계별 최대 강도를 특성화할 때는 Active를, 포화 가능성이 있는 부하에서 사용자 체감 지연을 보고할 때는 effective_latency 를 인용합니다.

추론 토큰이 TTFT를 바꿉니다: TTFT, TTFO, 그리고 OSL의 함정

앞의 vLLM 명령에 --reasoning-parser qwen3 가 들어 있던 이유가 여기 있습니다. Qwen3나 DeepSeek-R1, gpt-oss 계열처럼 최종 응답 전에 추론 토큰(reasoning token) 을 생성하는 모델은 그 내용을 API 응답의 reasoning_content 필드로 돌려줍니다. 마이그레이션 문서가 경고하듯, GenAI-Perf는 이 필드를 아예 파싱하지 않고 무시했습니다. 그래서 GenAI-Perf의 TTFT는 추론이 아닌 첫 출력 토큰이 나올 때까지 기다린 값이 됩니다.

AIPerf는 추론 토큰을 파싱하고 지표를 둘로 쪼갭니다.

이 표가 왜 중요한가 하면, 두 도구의 숫자를 나란히 놓고 "AIPerf로 바꿨더니 TTFT가 좋아졌다" 고 결론 내리는 일이 실제로 가능하기 때문입니다. 추론 모델을 재는 경우 GenAI-Perf의 TTFT와 비교해야 할 값은 AIPerf의 TTFT가 아니라 TTFO이고, GenAI-Perf의 OSL과 비교해야 할 값은 AIPerf의 OSL이 아니라 Output Token Count입니다. 추론 능력이 없는 모델에서는 TTFT와 TTFO가 같은 값이 되므로 이 구분이 필요 없습니다.

고정된 부하에서 현실의 트래픽으로: 도착 패턴 조정하기

정적 벤치마크는 기준선으로는 훌륭하지만 현실의 추론 트래픽은 그렇게 흐르지 않습니다. 원문은 두 번째 실행에서 합성 워크로드 관련 옵션 몇 개를 조정해 변동성을 집어넣습니다.

aiperf profile \
  --model Qwen/Qwen3-0.6B \
  --endpoint-type chat \
  --streaming \
  --url localhost:8000 \
  --request-rate 10 \
  --arrival-pattern poisson \
  --synthetic-input-tokens-mean 512 \
  --synthetic-input-tokens-stddev 128 \
  --output-tokens-mean 128 \
  --output-tokens-stddev 32 \
  --random-seed 42 \
  --request-count 200

--arrival-pattern poisson 과 --request-rate 10 의 조합은 평균 초당 10건으로 요청을 보내되 도착 간격을 지수 분포에서 뽑습니다. 단일 사용자가 꾸준히 두드리는 흐름이 아니라 몰림과 공백이 번갈아 오는 흐름, 즉 실제 트래픽에서 큐가 만들어지는 방식을 서버가 겪게 됩니다. 도착 패턴 문서를 보면 선택지는 넷입니다.

--arrival-smoothness 는 감마 분포의 형상 모수 k 입니다. 1보다 작으면 몰림이 심해지고, 1이면 포아송과 같아지며, 1보다 크면 등간격에 가까워집니다. 척도 모수는 평균 속도가 유지되도록 자동으로 계산됩니다. vLLM의 자체 벤치마크 스크립트에서 넘어온다면 이 옵션에 --vllm-burstiness 라는 별칭이 있고, 같은 값을 주면 vLLM의 --burstiness 와 같은 분포가 나옵니다. 참고로 --request-rate 를 줄 때 도착 패턴의 기본값이 이미 포아송이므로, 위 명령의 --arrival-pattern poisson 은 의도를 명시하는 역할입니다.

나머지 플래그도 각자 역할이 있습니다. --synthetic-input-tokens-stddev 128 은 512토큰 평균 주변에 분산을 넣어 짧은 프롬프트와 긴 프롬프트가 섞이게 하고, --output-tokens-stddev 32 는 출력 쪽에 변동을 줍니다. 여기서 min_tokens 와 ignore_eos 가 사라진 것은 실수가 아니라 의도입니다. 정적 기준선에서는 출력을 정확히 128토큰으로 고정해 기준선을 깨끗하게 유지했지만, 이번에는 출력 분포가 변하도록 그 제약을 일부러 풀었습니다. --random-seed 42 는 포아송 타이밍과 합성 길이 추출을 재현 가능하게 만들어, 같은 명령을 다시 실행하면 같은 요청 시퀀스가 나오게 합니다.

요청이 실제로 어떻게 나갔는지는 아래 그림이 보여줍니다. 회색 점선이 지터 없이 고정 10 req/s로 보냈을 때의 기울기이고, 파란 선이 포아송 모드의 실제 누적 발송량입니다. 200건을 20.7초에 보내 평균 9.6 req/s가 나왔고, 선이 점선을 중심으로 오르내리며 들쭉날쭉한 것이 도착 간격에 넣은 변동입니다.

입력 길이 쪽도 요청한 대로 흩어졌습니다. 평균 512토큰, 표준편차 128을 지정한 결과 실측 평균은 514토큰(표준편차 123.5)이고, 가장 짧은 요청이 154토큰, 가장 긴 요청이 818토큰으로 대칭에 가까운 종 모양 분포가 만들어졌습니다.

두 실행을 나란히 놓기: 평균이 아니라 분포가 달라집니다

포아송 실행의 지표 요약은 아래와 같습니다.

두 실행의 숫자를 한 표에 모으면 무엇이 달라졌는지가 분명해집니다. 다만 두 실행은 워크로드 자체가 다르므로(요청 10건의 128/128 고정에 동시성 1 대 요청 200건의 512±128 입력과 128±32 출력에 초당 10건), 통제된 A/B 비교가 아니라 부하 형태가 바뀌면 분포가 어떻게 반응하는지를 보여주는 대조로 읽어야 합니다.

위 표에서 눈여겨볼 것은 두 가지입니다. 하나는 평균보다 꼬리가 훨씬 크게 움직였다는 점입니다. TTFT 평균은 1.4배 늘었는데 p99는 2.5배로 뛰었고 표준편차는 2.6배가 되었습니다. 동시에 여러 요청이 GPU를 두고 경쟁하고, 프리필 길이가 요청마다 다르며, 프리필과 디코딩이 서로 겹치면서 생기는 결과입니다. 다른 하나는 처리량과 지연이 맞바꿔졌다는 점입니다. 동시성 1은 한 번에 요청 하나만 처리하는 이상화된 상황이라 가능한 가장 낮은 TTFT를 주지만, 그 대가로 출력 토큰 처리량이 36 tok/s에 그칩니다. 부하를 걸면 처리량은 29배가 되고 꼬리 지연은 나빠집니다. 용량 산정이란 결국 이 곡선 위에서 어느 점을 고를지의 문제입니다.

원문은 두 실행의 TTFT 분포를 겹쳐 놓은 히스토그램도 함께 싣습니다. 파란 쪽이 동시성 1, 초록 쪽이 초당 10건이고 각각 200건씩입니다. 동시성 1은 하나의 막대에 요청의 66%가 몰릴 만큼 뾰족하고, 초당 10건은 100ms대 초반부터 160ms 너머까지 완만하게 퍼져 있습니다.

이 그림의 중앙값은 각각 88ms와 131ms로 표시되어 있는데, 바로 위 표의 p50(220.57ms, 261.10ms)과는 맞지 않습니다. 같은 실행에서 뽑은 그림이 아니라 별도로 실행한 한 쌍에서 그린 것이므로, 절대값을 앞의 표와 이어 붙이지 말고 분포의 모양 차이를 읽는 용도로 보는 편이 안전합니다.

GenAI-Perf에서 넘어올 때 확인할 것

AIPerf는 현재 지원하는 기능에 한해 GenAI-Perf의 대체재(drop-in replacement) 로 설계되었습니다. 이 단서는 형식적인 표현이 아닙니다. CLI 기능 비교 문서를 보면 AIPerf가 훨씬 넓은 영역이 대부분이지만, GenAI-Perf에 있고 AIPerf에 아직 없는 항목도 분명히 존재합니다.

• dynamic_grpc 와 --grpc-method: gRPC 기반 서비스 호출 경로가 없습니다.
• kserve 와 tensorrtllm_engine: KServe 엔드포인트와 TensorRT-LLM 엔진 직접 접근이 빠졌습니다. AIPerf는 OpenAI 호환 HTTP 표면을 중심으로 재설계되었기 때문에, Triton 네이티브 경로로 재던 벤치마크는 그대로 옮겨지지 않습니다. 같은 이유로 Triton 전용이던 --output-tokens-mean-deterministic 도 없습니다.
• nvclip 과 generate: NVIDIA CLIP 엔드포인트와 범용 텍스트 생성 엔드포인트가 없습니다. 다만 Hugging Face TGI의 /generate 는 huggingface_generate 로 그대로 지원합니다.
• --backend {tensorrtllm,vllm}: 백엔드 선택 플래그 자체가 사라졌습니다.
• --checkpoint-dir 과 --enable-checkpointing: 체크포인트 관련 옵션이 없습니다.

반대로 이름이 같거나 비슷해서 헷갈리기 쉬운 항목도 있습니다. 가장 주의할 것은 --server-metrics-url 입니다. 이름과 달리 GenAI-Perf의 이 플래그는 Triton과 DCGM의 GPU 텔레메트리 엔드포인트를 가리키는 것이지 범용 Prometheus 스크레이퍼가 아니었습니다. AIPerf는 이 관심사를 둘로 쪼개서, GPU 텔레메트리는 --gpu-telemetry 가, 모델 엔드포인트의 Prometheus 지표는 --server-metrics 가 담당합니다. 따라서 --server-metrics-url http://node:9400 은 --gpu-telemetry http://node:9400 으로 옮겨야 하며, 이름이 비슷하다고 --server-metrics 에 지정하면 전혀 다른 표면을 겨누게 됩니다.

나머지 차이는 단순합니다. --max-threads 는 없어졌고, 요청을 보내는 워커 수는 --workers-max 로 더 세밀하게 조절합니다. 패스스루 인자 구분자 -- 도 필요 없어졌습니다. 입력 파일 포맷에서는 payload 가 payloads 복수형으로 바뀌면서 배열의 각 항목이 대화의 한 턴을 뜻하게 되었고, 요청과 페이로드를 연결할 수 있도록 session_id 필드가 추가되었습니다.

여기서 더 나아가기

원문은 다중 노드 쿠버네티스 배포, KV 캐시 재사용 워밍업, 트레이스 재생, 프리픽스 합성, 커스텀 데이터셋, 스윕 설정을 한 문단에 열거하고 링크만 건 채 끝나지만, 저장소의 튜토리얼 디렉토리에는 74개의 문서가, docs/ 전체로는 150개의 문서가 들어 있습니다. 측정 루프를 손에 익힌 다음 실제로 쓸모가 큰 것들만 골라 보면 다음과 같습니다.

굿풋(Goodput): 단순 처리량이 아니라 지정한 제약을 만족한 요청만 세는 초당 완료 요청 수입니다. TTFT 100ms 이하, ITL 3.40ms 이하 같은 서비스 수준 목표(Service Level Objective, SLO)를 --goodput "time_to_first_token:100 inter_token_latency:3.40" 형태로 주면 그 조건을 통과한 요청만 집계합니다. 서비스 수준 협약(Service Level Agreement, SLA)을 지키면서 낼 수 있는 처리량이 얼마인지가 용량 산정의 실제 질문이라면, 이쪽이 처리량보다 정직한 숫자입니다. 자세한 절차는 굿풋 튜토리얼에 있습니다.

파라미터 스윕과 적응형 탐색: 동시성이나 요청 속도를 바꿔 가며 여러 번 실행하는 일을 YAML 설정의 sweep: 블록으로 묶을 수 있고, 베이지안 최적화 기반의 적응형 탐색으로 격자를 나열하지 않고 목표 지표가 가장 좋아지는 지점을 찾게 할 수도 있습니다. SLA 아래의 최대 처리량이나 최대 동시성처럼 자주 나오는 질문은 max-concurrency-under-sla 같은 이름 붙은 탐색 레시피로 준비되어 있습니다. aiperf plot 은 여러 실행 결과를 받아 처리량 대 상호작용성의 파레토 곡선을 그려 줍니다.

트레이스 재생: 합성 부하 대신 실제로 기록된 트래픽을 그대로 재생합니다. Mooncake, Bailian, BurstGPT, Baseten Parquet, Amazon SageMaker 데이터 캡처, WEKA와 TraceLab의 실제 에이전틱 코딩 세션 트레이스까지 로더가 준비되어 있습니다. KV 캐시 재사용률처럼 합성 프롬프트로는 재현하기 어려운 특성을 보려면 이쪽이 유일한 길입니다.

Kubernetes 오퍼레이터: 클러스터 위에서 CRD로 벤치마크를 정의하고, Kueue로 큐잉하며, 결과를 사이드카로 수거하는 운영 경로가 문서화되어 있습니다.

텔레메트리 연동: Weights & Biases, MLflow, OpenTelemetry로 결과와 실시간 지표를 내보내는 선택적 의존성이 각각 aiperf[wandb], aiperf[mlflow], aiperf[otel] 로 제공됩니다.

AIPerf가 NVIDIA 단독 프로젝트가 아니라는 점도 짚어 둘 만합니다. 원문의 감사의 글은 AWS, CoreWeave, Baseten, Pinterest 소속 기여자들의 이름을 나열하면서 AIPerf로 표준화하려는 회사 간 협업을 언급합니다. Weights & Biases 익스포터, Baseten 트레이스 재생, 방향 비순환 그래프(Directed Acyclic Graph, DAG) 벤치마킹 방법론 같은 기능이 이 협업에서 나왔습니다. 서로 다른 회사가 같은 도구로 측정하면, 벤치마크 결과를 비교할 때 도구 차이부터 의심할 필요가 줄어듭니다.

라이선스

AIPerf는 Apache License 2.0으로 배포되고 있어, 연구 목적은 물론 상업적 용도로도 자유롭게 사용 및 수정이 가능합니다.

Benchmarking LLM Inference at Scale with AIPerf 소개 블로그

R4T(Retrieve-for-Train) 논문 소개

검색창에 "캠핑 장비"라고 입력한 사용자가 기대하는 결과는 4인용 텐트 열 개가 아닙니다. 텐트, 침낭, 버너, 헤드램프처럼 서로 보완하는 물건들이 한 묶음으로 나와야 합니다. Google Research와 일리노이 대학교(UIUC) 연구팀이 ICML(International Conference on Machine Learning) 2026에서 발표한 R4T(Retrieve-for-Train) 논문은 이렇게 결과 하나가 아니라 결과 집합(Set) 의 품질이 중요한 검색 문제를 다룹니다. 이 논문은 강화학습(Reinforcement Learning, RL)을 추론(Inference) 시점의 엔진으로 배포하는 대신, 학습 데이터를 만드는 1회성 도구로 쓰는 방법을 제안합니다. RL로 찾아낸 좋은 질의 분해 행동을 합성 데이터로 컴파일하고, 그 데이터로 53.9M 파라미터의 작은 확산 모델(Diffusion Model)을 학습해 추론 시에는 단일 패스(Single Pass)로 결과 집합을 생성합니다. 이번 글에서는 논문과 Google Research 블로그 글을 함께 읽고 배경, 방법론, 실험 결과를 정리하려고 합니다.

결과 하나가 아니라 결과 집합을 돌려줘야 하는 검색

검색 시스템과 추천 시스템은 점점 더 가장 잘 맞는 결과 하나가 아니라, 함께 놓았을 때 좋은 결과 여러 개를 요구받고 있습니다. 검색 인터페이스는 넓은 질의를 여러 의도로 확장해 커버리지(Coverage)를 높여야 하고, 추천 시스템은 다양하면서도 일관된 슬레이트(Slate, 한 화면에 함께 노출되는 결과 묶음)를 만들어야 하며, 번들 구성 시스템은 서로 보완하는 품목을 모아야 합니다. 이런 요구는 후보를 단순히 골라내는(select) 대신 모델이 후보를 생성하는 생성형 검색(Generative Retrieval) 접근으로 이어졌습니다. DSI(Differentiable Search Index)처럼 문서 식별자를 직접 생성하는 방식이 대표적입니다.

문제는 이런 과제의 품질 기준이 집합 수준(Set-level) 에 있고, 분해되지 않는(Non-decomposable) 다는 점입니다. 다양성, 의도 커버리지, 보완성, 스타일 일관성은 결과 하나를 보고 매길 수 있는 점수가 아니라 집합 전체를 놓고 봐야 정의되는 성질입니다. 게다가 정답이 하나로 정해지지 않습니다. "보헤미안 페스티벌 스타일"이라는 질의에 대해 서로 다른 여러 결과 집합이 모두 정답일 수 있습니다. 그래서 기존의 지도학습(Supervised Learning) 데이터셋처럼 (질의, 콘텐츠) 쌍을 모아 top-1 검색을 학습시키는 방식으로는 이 성질을 담을 수 없고, 집합 수준 성질을 반영한 (질의, 콘텐츠) 쌍을 사람이 라벨링하는 것은 비용이 크고 주관적이며 도메인 특화 코퍼스에서는 거의 불가능합니다.

실무에서는 이 문제를 질의 팬아웃(Query Fan-out) 으로 풉니다. 넓은 질의 하나를 여러 하위 질의(Sub-query)로 나눠 각각 검색하고 결과를 합치는 방식으로, Google이 AI Mode 검색에 적용했다고 소개한 기법이기도 합니다. R4T 논문이 다루는 것은 바로 이 팬아웃을 누가, 어떤 비용으로, 어떤 목표에 맞춰 수행하는가의 문제입니다.

기존 접근법 1: 제로샷 LLM 팬아웃

가장 손쉬운 방법은 기성 LLM에 "이 질의를 10개의 하위 질의로 나눠라"라고 시키는 것입니다. 그러나 연구팀은 블로그에서 여기에 두 가지 구조적 문제가 있다고 지적합니다. 첫째는 의역 붕괴(Paraphrastic Collapse) 입니다. 데이터베이스를 모르는 제로샷(Zero-shot) LLM은 주제의 서로 다른 측면을 탐색하는 대신 거의 같은 뜻의 질의를 반복해서 만듭니다. "Bohemian festival style"을 넣으면 "bohemian festival fashion", "bohemian festival clothes"가 나오는 식이어서, 패션 전문가라면 떠올릴 프린지 재킷, 크로셰 드레스, 스웨이드 부츠 같은 갈래를 찾아내지 못합니다. 연구팀도 실험에서 제로샷 팬아웃의 하위 질의가 데이터베이스 매니폴드(Manifold) 바깥으로 벗어나거나 거의 같은 표현으로 붕괴해 근거성(Groundedness)이 낮고 결과가 중복된다고 보고합니다.

둘째는 자기회귀(Autoregressive) 지연 병목입니다. 복잡한 질의를 보완적인 갈래로 분해하려면 최신 모델은 사고 연쇄(Chain-of-Thought, CoT) 토큰을 수백 개 생성하며 계획을 세워야 하는데, 이는 토큰 단위 순차 생성이라 결과 집합의 크기가 커질수록 비용이 나쁘게 늘어납니다. 대화형 AI에서는 감내할 수 있는 지연이지만, 1초 미만 응답이 요구되는 검색창에서는 구조적으로 맞지 않는 하한선이 됩니다.

기존 접근법 2: RL로 미세조정한 LLM을 그대로 배포

집합 수준 목표를 보상(Reward)으로 정의할 수 있다면, 데이터베이스와 상호작용하며 그 보상을 최대화하는 RL이 자연스러운 선택입니다. 실제로 첫 저자 Pengcheng Jiang이 참여한 DeepRetrieval과 s3는 RL로 실제 검색 엔진과 상호작용하는 검색 에이전트를 학습시켜, 보상 기반 최적화가 점 단위 관련성(Pointwise Relevance)을 넘어선 검색 목표를 담을 수 있음을 보였습니다.

그러나 RL로 학습한 언어 모델을 추론 시점에 그대로 배포하는 것은 다른 문제입니다. 자기회귀 팬아웃 생성과 반복적인 검색 호출은 상당한 지연을 만들고, 집합 수준 보상은 분산이 크며 지름길 악용(Shortcut Exploitation)에 취약합니다. 저자들은 이 두 가지가 안정적인 배포를 어렵게 만들며, 보상 기반 최적화와 추론 시점 검색을 분리해야 할 이유가 된다고 설명합니다.

기존 접근법 3: 확산 기반 생성 검색

한편 임베딩 공간에서 비자기회귀(Non-autoregressive) 샘플링을 수행하는 확산 기반 생성 검색도 등장했습니다. 음악 검색에 확산 사전분포(Diffusion Prior)를 적용한 Diff4Steer와 텍스트-음악 검색용 GD-Retriever가 대표적입니다. 이 계열은 검색을 잡음 제거(Denoising) 과정으로 모델링해 슬레이트나 번들 전체를 단일 패스로 생성할 수 있습니다. 저자들은 이를 무겁고 순차적인 "System 2" 생성에서 병렬적인 "System 1" 샘플링으로의 전환이라고 표현합니다.

다만 확산 검색기는 성질에 맞춰 정렬된 학습 타깃(Property-aligned Training Targets) 을 대량으로 필요로 합니다. 그리고 그 타깃이야말로 분해되지 않는 집합값 검색 과제에서 가장 부족하고 애매한 자원입니다. 빠르게 생성할 수는 있는데, 무엇을 생성하도록 가르칠 데이터가 없는 상황입니다.

발상의 전환: RL을 목적 변환기로

R4T의 핵심 아이디어는 위 두 접근법의 약점이 서로의 강점으로 채워진다는 관찰에서 나옵니다. RL은 복잡한 집합 수준 목표를 최적화할 수 있지만 배포가 비싸고, 확산 검색기는 배포가 싸지만 학습 데이터가 없습니다. 그렇다면 RL을 배포용 추론 메커니즘이 아니라, 복잡한 보상 명세를 확장 가능한 지도 데이터로 바꿔 주는 1회성 목적 변환기(Objective Transducer)로 쓰면 됩니다. 블로그는 이를 "보상을 데이터로 컴파일하는(reward-to-data compilation)" 프레임워크라고 부릅니다.

연구팀이 든 비유를 옮기면, 사용자가 기다리는 동안 매번 시험을 치르게 하는 대신 오프라인 연습 시간을 한 번 갖게 하는 것입니다. 추상적인 목표("결과가 다양하고 실제로 재고에 있어야 한다")를 엄격한 보상 체계로 명시해 RL을 한 번 실행하고, 그 결과를 단계별 지침서처럼 데이터로 만들어 둔 뒤, 실제 검색에서는 그 지침서를 즉시 실행하는 구조입니다.

실험 결과를 미리 말씀드리면, R4T는 패션 데이터셋 Polyvore와 비공개 음악 플레이리스트 데이터셋에서 같은 기본 모델 계열의 제로샷 팬아웃과 Best-of-N 기준선(Baseline)을 모두 앞섰고, 확산 검색기 변형은 자기회귀 LLM 팬아웃 대비 12\times 에서 20\times 의 지연 단축을 달성했습니다.

R4T의 방법론: 보상을 데이터로 컴파일하는 세 단계

문제 정의: 집합값 팬아웃 검색

R4T가 다루는 문제를 먼저 형식화하겠습니다. 넓은 질의 q 가 주어지면 시스템은 고정된 데이터베이스 \mathcal{D} 에서 결과 집합을 돌려줘야 합니다. 팬아웃 형식에서는 정책(Policy)이 먼저 k 개의 하위 질의 Q = \{q_1, \ldots, q_k\} 를 생성하고, 고정된 검색기 R(\cdot) 가 각 하위 질의를 실행해 후보 \mathcal{C}_i = R(q_i, \mathcal{D}) 를 가져옵니다. 최종 결과는 이들의 합집합 \mathcal{R}(Q) = \bigcup_{i=1}^{k} \mathcal{C}_i 입니다.

핵심 가정은 결과의 품질이 다양성, 커버리지, 보완성 같은 집합 수준 성질로 정의되고, 이 성질이 일반적으로 분해되지 않으며, 정답이 하나가 아니라 여럿이라는 것입니다. 마지막 성질 때문에 정답 라벨(Ground Truth) 기반 지도학습이 어려워집니다.

전체 구조와 두 가지 배포 변형

R4T는 세 단계로 구성됩니다. 첫째는 RL 정책 최적화로, 하위 질의를 생성하는 팬아웃 언어 모델(Fan-Out Language Model, FOLM) \pi_\theta 를 학습해 데이터베이스와의 상호작용 결과가 과제별 집합 수준 보상을 최대화하도록 만듭니다. 둘째는 합성 지도 데이터(Synthetic Supervision) 생성으로, 최적화된 FOLM을 실행해 고보상 궤적을 모으고 이를 집합값 타깃 데이터셋으로 바꿉니다. 셋째는 컴파일된 배포로, 질의가 주어졌을 때 집합값 타깃의 조건부 분포를 모델링하는 경량 생성형 검색기를 그 데이터로 학습해 추론 시 단일 패스 팬아웃을 가능하게 합니다.

이 구조에서 눈여겨볼 점은 RL 단계를 공유하면서 추론 시점의 실행 방식만 다른 두 배포 변형을 함께 평가한다는 것입니다.

• R4T-FOLM: RL로 최적화한 FOLM \pi_{\theta^\ast} 를 추론 시점에 그대로 배포합니다. k 개의 하위 질의를 자기회귀로 생성하고 각각 검색해 합칩니다. 보상 최적화된 팬아웃의 품질을 그대로 반영하지만, 자기회귀 생성과 반복 검색 호출 비용을 그대로 부담합니다.
• R4T-Diffusion: FOLM의 보상 정렬 행동을 합성 데이터로 학습한 경량 확산 모델 D_\phi 에 증류(Distillation)합니다. 추론 시 D_\phi 는 질의 임베딩 z_q 에서 L 개의 검색 방향 \mathbf{Z}_0 \sim p_\phi(\mathbf{Z} \mid z_q) 를 비자기회귀 단일 패스로 생성하고, 이를 최근접 이웃(Nearest Neighbor) 검색으로 데이터베이스 콘텐츠에 대응시킵니다.

두 변형을 나란히 두면 보상 최적화된 팬아웃이 주는 이득과 그것을 배포하는 비용을 분리해서 볼 수 있고, RL이 발견한 행동이 효율적인 추론 형태로 증류될 수 있는지를 직접 검증할 수 있습니다.

집합 수준 보상 설계

R4T의 성패는 좋은 검색 행동을 보상으로 어떻게 정의하느냐에 달려 있습니다. 연구팀은 집합값 검색의 대표적인 두 상황을 설정하고 각각에 맞는 보상을 설계했습니다.

개방형 추상 검색(OAR)의 복합 보상

개방형 추상 검색(Open-Ended Abstract Retrieval, OAR) 은 정답 집합이 아예 존재하지 않는 탐색적 상황입니다. "bohemian festival style"처럼 테마나 시나리오를 나타내는 넓은 질의가 주어지면, 여러 해석을 아우르는 다양한(Diverse) 컬렉션 수준 결과를, 질의와 잘 정렬(Aligned)되고, 데이터베이스에 근거한(Grounded) 형태로 가져와야 합니다. 이 세 성질을 각각 부분 보상으로 두고 가중합한 복합 보상이 다음과 같습니다:

다양성(Diversity) 은 각 하위 질의의 대표 검색 결과(예: top-1 항목) c_i^\star 의 콘텐츠 임베딩에 대해 Vendi Score를 계산해 측정합니다. Vendi Score는 유사도 행렬의 고유값 엔트로피로 정의되는 다양성 지표로, 참조 데이터 없이도 집합 내부의 의미적 폭을 잴 수 있습니다:

근거성(Groundedness) 은 하위 질의가 임베딩 공간이 만드는 데이터베이스 매니폴드 위에 머물도록, 각 하위 질의 임베딩과 데이터베이스 안 최근접 이웃 사이의 거리에 벌점을 줍니다:

정렬(Alignment) 은 하위 질의가 원 질의 q 의 의도에서 멀어지는 의미 표류(Semantic Drift)를 막기 위해, 각 하위 질의 임베딩과 원 질의 임베딩의 코사인 유사도(Cosine Similarity) 평균으로 정의합니다:

기본 가중치는 \lambda_g = 0.6, \lambda_d = \lambda_a = 0.2 입니다. 세 항이 서로를 견제하는 구조라는 점이 중요한데, 이 부분은 뒤의 보상 해킹(Reward Hacking) 절제 실험에서 다시 다루겠습니다.

약지도 조합 검색(WSCR)의 커버리지 보상

약지도 조합 검색(Weakly Supervised Compositional Retrieval, WSCR) 은 질의마다 여러 유효한 항목 집합이 있을 수 있지만, 그중 하나의 그럴듯한 실현을 담은 약한 참조 집합(Weak Reference Set) \mathcal{Y} = \{y_1, \ldots, y_m\} 이 주어지는 상황입니다. Polyvore의 코디(outfit) 하나가 그런 참조 집합입니다. 중요한 점은 \mathcal{Y} 를 유일한 정답으로 보지 않는다는 것입니다.

이 경우의 보상은 참조 집합을 팬아웃 결과가 얼마나 덮었는지로 정의합니다:

이 보상은 정책이 고정된 타깃을 암기하는 대신, 합집합이 참조 집합에 반영된 서로 다른 의미 구성요소를 아우르도록 보완적인(Complementary) 하위 질의를 만들게 유도합니다. 상의, 하의, 신발, 액세서리를 각각 겨냥한 하위 질의를 만들어야 코디 전체를 덮을 수 있기 때문입니다.

1단계: 소프트 PPO 정규화를 더한 GRPO로 팬아웃 LM 학습

R4T의 첫 단계는 FOLM의 RL 학습입니다. 입력 질의 q 에 대해 FOLM \pi_\theta 가 하위 질의 집합 Q 를 생성하고, 고정된 밀집 검색기(Dense Retriever) R(\cdot) 가 이를 실행해 후보 문서를 가져오며, 위에서 정의한 과제별 보상이 샘플된 팬아웃 출력 하나하나에 매겨집니다. 이번 논문에서 FOLM은 Gemma3-4B와 Qwen3-4B 두 가지 4B 규모 오픈 모델의 명령 조정(Instruction-tuned) 체크포인트에서 시작하며, 질의마다 k = 10 개의 하위 질의를 생성합니다. 부록에 공개된 프롬프트는 <think> 태그 안에 사고 과정을 쓰고 <queries> 태그 안에 최대 10개의 질의를 JSON 배열로 내도록 요구합니다.

정책 최적화에는 GRPO(Group Relative Policy Optimization) ( GRPO:Zero, GRPO를 간단하고 효율적으로 구성한 LLM용 강화학습 프레임워크)를 씁니다. 질의 하나에 대해 G 개의 출력 \{o_1, \ldots, o_G\} 를 샘플링하고, 그룹 통계로 어드밴티지(Advantage)를 계산합니다:

별도의 가치 모델 없이 같은 질의에서 뽑은 그룹 안의 상대적 순위만으로 학습 신호를 만드는 것이 GRPO의 특징이고, 정답이 하나가 아닌 집합값 보상에서도 그대로 적용됩니다.

여기에 개방형 생성을 안정화하기 위해 소프트 PPO(Soft PPO) 정규화를 더합니다. KL 정규화 정책 경사 설계와 TROLL(Trust Regions improve reinforcement Learning for Large language models) 연구를 따라, 현재 정책 \pi_\theta 와 샘플링 정책 \pi_{\text{old}} 사이의 순방향(Forward) KL(Kullback-Leibler) 발산과 역방향(Reverse) KL 발산 벌점을 모두 GRPO 목적에 추가하는 방식입니다:

실제 구현에서는 토큰별 손실에 두 KL 항을 직접 얹는 형태로 계산하며, \rho_t = \pi_\theta / \pi_{\text{old}} 를 중요도 비율(Importance Ratio)로 씁니다:

논문에 공개된 학습 설정을 보면 그룹 크기 G = 8, 클리핑 \epsilon = 0.2, 두 KL 계수 \beta_1 = \beta_2 = 0.05, 학습률 1 \times 10^{-7}, 전역 배치 크기 512, 최대 시퀀스 길이 1,024 토큰이며, 학습은 TPUv6e-16 포드에서 수행했습니다. (학습 하이퍼파라미터 전체는 논문의 Appendix F, Table 3을 참고해주세요)

2단계: 합성 지도 데이터 생성

두 번째 단계에서 최적화된 FOLM \pi_{\theta^\ast} 는 행동 생성기(Behavior Generator) 역할을 합니다. 보상이 빚어낸 팬아웃 검색 패턴의 분포를 그대로 유도하는 장치인 셈입니다. 질의마다 \pi_{\theta^\ast} 에서 팬아웃 출력을 샘플링하고 고정 데이터베이스에 대해 검색을 실행한 뒤, 그 결과를 지도 데이터로 삼습니다. 사람 라벨은 전혀 필요하지 않습니다.

이때 하류 모델이 여러 검색 임베딩을 한 번의 순전파로 생성할 수 있도록, 팬아웃 결과 하나를 일관 타깃 텐서(Coherent Target Tensor) \mathbf{Z}_{\text{target}} \in \mathbb{R}^{L \times d} 로 표현합니다. 각 행이 FOLM이 발견한 검색 방향 하나에 대응합니다. 무엇을 행에 담는지는 과제에 따라 다릅니다:

• OAR: 목표가 다양하고 근거 있는 검색 결과 자체이므로, 팬아웃 출력에 대응하는 검색된 콘텐츠의 임베딩 \{z_{c_1}, \ldots, z_{c_L}\} 로 타깃을 구성합니다. RL 정책이 유도한 데이터베이스에 근거한 컬렉션의 분포를 직접 증류하는 것입니다.
• WSCR: 목표가 참조 집합을 함께 덮는 검색 방향의 발견이므로, FOLM이 생성한 최적화된 하위 질의의 텍스트 임베딩 \{e_{\text{text}}(q_1), \ldots, e_{\text{text}}(q_L)\} 로 타깃을 구성합니다. RL이 학습한 질의 분해 전략 자체를 하류 모델이 내재화하게 하는 선택입니다.

집합값 검색은 순서와 무관하므로 학습 중 \mathbf{Z}_{\text{target}} 의 행을 무작위로 섞어 순열 강건성(Permutation Robustness)을 유도합니다. 이렇게 만든 합성 데이터셋 \mathcal{T}_{\text{syn}} = \{(z_q, \mathbf{Z}_{\text{target}})\} 이 보상 최적화 정책이 유도하는 팬아웃 검색 분포 전체를 담습니다. 규모를 보면, OAR에서는 43,874개의 고유한 넓은 질의를, WSCR에서는 84,704개의 질의를 8:1:1로 학습, 검증, 테스트에 나눈 뒤, 학습용 질의마다 온도(Temperature) 0.9 로 128개 샘플을 생성해 확산 모델 학습 타깃을 만들었습니다. 이 데이터 생성 단계는 TPUv6e-4 포드에서 수행했습니다.

3단계: 단일 패스 팬아웃을 위한 확산 검색기

마지막 단계는 p(\mathbf{Z}_{\text{target}} \mid z_q) 를 모델링하는 생성형 검색기 D_\phi 의 학습입니다. 연구팀은 Song et al.의 점수 기반 확률 미분 방정식(Stochastic Differential Equation, SDE) 연구에서 제안된 분산 폭발(Variance Exploding, VE) 확산 형식을 Karras et al.의 EDM(Elucidating the Design space of diffusion-based generative Models) 프레임워크 안에서 채택했습니다. 잡음 제거기(Denoiser) D_\phi(\mathbf{Z}_t; \sigma, z_q) 는 잡음이 섞인 입력에서 깨끗한 타깃을 복원하도록 다음 손실로 학습됩니다:

여기서 \lambda(\sigma) = (\sigma^2 + \sigma_{\text{data}}^2) / (\sigma \cdot \sigma_{\text{data}})^2 는 잡음 수준별 기여를 균형 잡는 EDM 가중치입니다.

아키텍처는 구조적 일관성을 위해 설계된 트랜스포머(Transformer) 잡음 제거기로, DiT(Diffusion Transformer) 계열을 연속 입력에 맞게 손본 형태이며 EDM의 전처리(Preconditioning) 기법을 그대로 따릅니다. 입력은 L 개의 타깃 임베딩을 이어 붙인 시퀀스이고, 질의 임베딩 z_q 는 교차 어텐션(Cross-attention)으로 주입됩니다. 학습 중 z_q 를 확률 0.1 로 무작위 제거해 분류기 없는 가이던스(Classifier-Free Guidance, CFG)를 적용하고, 추론 시에는 확률 흐름 SDE를 256 스텝으로 풀어 \mathbf{Z}_0 를 생성한 뒤 L 개의 임베딩으로 잘라 최근접 이웃 검색으로 데이터베이스 콘텐츠에 대응시킵니다.

확산 모델의 주요 설정은 다음과 같습니다.

전체 파라미터 수는 53.9M에 그칩니다. 4B 규모의 FOLM이 발견한 행동을 그 \frac{1}{70} 규모도 안 되는 모델이 이어받는 셈이고, 이 크기 차이가 뒤에서 볼 지연 단축의 근원입니다.

실험 설계

데이터셋과 검색 백본

연구팀은 서로 다른 검색 모달리티(텍스트-이미지, 텍스트-음악)와 도메인을 대표하는 두 데이터셋에서 R4T를 평가했습니다.

Polyvore는 사용자가 직접 큐레이션한 코디로 구성된 대규모 패션 벤치마크로, Han et al.(2017)이 공개했습니다(GitHub). 각 코디는 상의, 하의, 신발, 액세서리처럼 서로 다른 카테고리의 호환되는 패션 상품을 담은 정답 항목 집합으로 기능하며, 상품 이미지와 텍스트 메타데이터가 함께 제공되어 멀티모달 근거성과 집합 일관성을 함께 평가할 수 있습니다. 후보 검색 풀은 Task 1(OAR)에서 21,888개의 컬렉션, Task 2(WSCR)에서 142,472개의 개별 항목입니다.

Music은 전문가가 만든 음악 플레이리스트로 구성된 비공개 산업 데이터셋(Proprietary Industrial Dataset)입니다. 각 플레이리스트가 일관된 트랙 시퀀스이자 검색의 정답 집합 역할을 하며, 음악 도메인에서 주제 일관성과 의도 커버리지를 모델링하는 능력을 봅니다. 후보 검색 풀은 8,522개의 플레이리스트 임베딩이고 Task 1에만 사용됩니다.

검색 백본은 데이터셋별로 고정된 임베딩 모델을 씁니다. Polyvore에는 마트료시카 표현 학습(Matryoshka Representation Learning)으로 학습한 CLIP(Contrastive Language-Image Pre-training) 기반 이미지-텍스트 인코더를 써서 임베딩을 유연하게 잘라 쓸 수 있게 했고, 주 실험에서는 정확도와 효율의 균형을 위해 임베딩 차원 128을 사용했습니다. Music에는 대규모 오디오-언어 쌍으로 학습된 음악-텍스트 결합 임베딩 모델 MuLan을 써서 그 임베딩 공간 안에서 직접 검색합니다. R4T는 이 고정된 인코더 위에서 동작하므로 임베딩 공간 자체는 건드리지 않습니다.

넓은 질의는 LLM으로 합성했습니다. OAR용 질의는 미학적 테마("bohemian festival style"), 활동 시나리오("weekend brunch outfit"), 계절("summer vacation vibes"), 라이프스타일("sustainable living"), 기분("confident and bold") 등 여러 템플릿으로 2~6단어짜리 개방형 질의를 생성하고 중복을 제거한 것이고, WSCR용 질의는 반대로 기존 코디의 항목 이름을 LLM(Gemini-2.5-Pro)에 주고 개별 항목을 나열하지 않는 코디 수준의 넓은 질의를 만들게 한 것입니다. WSCR에서는 원래 코디에 무작위 항목을 섞은 후보 풀에서 LLM이 스타일이 다른 10개 항목 집합 8개를 한 번에 고르게 하는 식으로 학습 데이터를 증강하고, 테스트 집합도 원래 항목의 33\% 에서 60\% 만 남긴 시드에서 새 코디를 완성하게 해 한 질의에 여러 그럴듯한 조합이 존재하도록 만들었습니다. (질의 생성 프롬프트 전문은 논문의 Appendix C를 참고해주세요)

비교 대상과 평가 지표

비교 대상은 세 가지입니다. No Fan-out은 하위 질의 확장 없이 원 질의로 n \times k 개의 콘텐츠를 직접 검색하는 전통적 밀집 검색으로, 팬아웃 방법들의 하한 역할을 합니다. Zero-shot Fan-out은 RL 학습 전의 기본 언어 모델로 k 개의 하위 질의를 생성하고 각각 n 개를 검색하는 방식이며, 하위 질의 생성 모델로 대규모 상용 모델인 Gemini-2.5-Flash, 그리고 Gemma3-4B와 Qwen3-4B를 각각 실험했습니다. Best-of-N은 제로샷 모델로 팬아웃을 N = 5 번 수행한 뒤 학습에 쓴 보상 기준으로 가장 좋은 결과를 고르는 강력한 기준선입니다. 모든 팬아웃 방법과 R4T는 k = 10 개의 하위 질의를 사용합니다.

평가 지표는 과제별로 다릅니다. OAR은 정답 집합이 없으므로 Gemini 2.5(논문 본문은 Pro, 부록은 Flash로 표기)를 심판으로 쓰는 LLM-as-a-Judge 평가를 채택해, 컬렉션 다양성, 질의-컬렉션 정렬, 근거성 세 차원을 각각 5점 리커트(Likert) 척도로 매기게 했습니다. 항목 순서를 무작위로 섞고, 점수마다 근거 설명을 요구하고, 프롬프트에 검색 방법을 언급하지 않는 등 편향을 줄이는 장치를 두었습니다. 근거성은 각 하위 질의의 검색 결과가 그 하위 질의와 맞는지만 보는 지표라, 중간 하위 질의가 없는 R4T-Diffusion에는 적용되지 않습니다.

WSCR은 참조 기반 커버리지 지표인 Recall@5K와 Hit@5K, 그리고 다양성과 생성 안정성을 보는 Vendi Score(VS) 를 보고합니다. 하위 질의(또는 생성된 임베딩) 10개마다 후보 500개씩 가져와 한 번의 추론에 5,000개 풀을 만들고, Recall@5K는 참조 항목 중 이 풀에 들어온 비율, Hit@5K는 참조 항목이 하나라도 들어온 질의의 비율입니다. Vendi Score는 질의마다 독립적인 추론을 N = 5 회 수행하고 각 실행의 하위 질의 임베딩 평균을 대표 임베딩으로 삼아, 그 대표 임베딩들 사이의 의미적 분산을 계산한 값입니다. 참조 집합이 유일한 정답이 아니므로 연구팀은 재현율(Recall)을 정확성이 아니라 의미 커버리지의 대리 지표로 해석합니다.

실험 결과 및 성능 분석

개방형 추상 검색(OAR) 결과

OAR 과제의 결과는 다음과 같습니다(논문 Table 1). 논문이 함께 보고한 표준편차(대체로 1.5 에서 3.6 사이)는 생략했습니다. 근거성은 중간 하위 질의가 없는 R4T-Diffusion에는 해당하지 않습니다.

Polyvore (패션)

Music (음악 플레이리스트)

위 표를 통해 세 가지를 알아볼 수 있습니다.

첫째, 팬아웃은 필요하지만 충분하지 않습니다. 모든 데이터셋과 기본 모델에서 제로샷 팬아웃은 원 질의로 직접 검색하는 No Fan-out을 앞섰습니다. 질의 확장이 의미적 측면의 커버리지를 넓힌다는 오래된 가설이 다시 확인된 것입니다. 그러나 제로샷 팬아웃의 하위 질의는 데이터베이스 매니폴드에서 벗어나거나 거의 같은 표현으로 붕괴하는 일이 잦아 근거성이 낮고 결과가 중복되었고, 정답의 제약이 없는 OAR에서 이 약점이 특히 두드러졌습니다. 흥미로운 점은 상용 대형 모델인 Gemini-2.5-Flash의 제로샷 팬아웃이 Polyvore에서 평균 31.5 로, 4B 규모 Gemma3-4B의 38.5 보다 낮았다는 것입니다.

둘째, 보상 기반 선택은 품질을 높이지만 확장되지 않습니다. Best-of-N은 고보상 팬아웃 사례를 골라내 제로샷보다 나은 결과를 냈고, 이는 연구팀이 설계한 보상 함수가 검색 행동을 빚는 의미 있는 신호라는 증거이기도 합니다. 그러나 질의마다 독립적인 팬아웃을 여러 번 실행해야 하므로 추론 비용이 한 차수(약 10배) 늘어나고, 지연과 확장성을 대가로 얻은 이득이라 실용 시스템에는 적용이 제한적입니다.

셋째, R4T는 정확도-효율 경계에서 일관되게 우위에 있습니다. R4T-FOLM은 Gemma 계열의 Polyvore 평균을 40.9 (Best-of-N)에서 49.1 로, Music 평균을 49.2 에서 58.1 로 끌어올렸고, 다양성 점수는 Polyvore에서 56.0 (제로샷)이 76.8 까지 올랐습니다. Qwen 계열에서는 근거성이 23.8 에서 37.0 으로 크게 개선되었습니다. 그리고 R4T-Diffusion은 단일 추론 패스만 쓰면서도 다양성과 정렬에서 R4T-FOLM에 근접했고, Polyvore의 Qwen 계열에서는 다양성 65.0 으로 FOLM(62.8)을 오히려 넘었습니다. 다만 이 우위는 같은 기본 모델 계열 안에서의 비교이고, 계열을 가로지르면 Music에서 Qwen 기반 R4T-FOLM의 평균 47.5 는 Gemini-2.5-Flash Best-of-N의 48.5 와 Gemma3-4B 제로샷의 48.1 에 미치지 못했습니다. 연구팀은 이 결과가 R4T의 핵심 이점, 즉 "RL로 고품질 팬아웃 행동을 한 번 발견하고, 그 행동을 경량 확산 검색기로 증류한다"는 설계가 실제로 작동함을 보여준다고 설명합니다.

약지도 조합 검색(WSCR) 결과: 커버리지와 다양성의 교환

WSCR 과제(Polyvore)의 결과는 다음과 같습니다. LLM 기반 검색은 온도 0.9 로 샘플링하고, 모든 방법에서 질의당 5회 실행(총 50개 하위 질의)으로 Vendi Score를 계산했습니다.

커버리지 측면에서 R4T-FOLM(Qwen)은 Recall@5K 20.9, Hit@5K 64.6 으로 가장 높았고, 제로샷 Qwen3-4B(10.1, 33.9)의 약 두 배에 이르는 수치입니다. 4B 모델로 RL 학습을 거친 FOLM 두 변형은 상용 모델 Gemini-2.5-Flash(15.7, 52.1)도 넘어섰습니다. 확산 변형은 Hit@5K에서는 둘 다 Gemini-2.5-Flash를 앞섰지만, Recall@5K에서는 Gemma 기반이 15.0 으로 조금 못 미치고 Qwen 기반이 16.5 로 근소하게 앞서는 수준이었습니다.

이 표에서 연구팀이 주목한 것은 참조 기반 커버리지와 다양성 사이의 뚜렷한 교환 관계(Trade-off) 입니다. LLM 기반 방법들 사이에서는 Recall@5K와 Hit@5K가 높을수록 Vendi Score가 낮아지는 경향이 나타났습니다. 참조 집합과의 겹침을 목표로 최적화된 자기회귀 팬아웃은 소수의 지배적인 의미 모드(Mode) 주변으로 검색을 집중시킨다는 뜻이고, 이는 RL이 언어 모델의 출력 엔트로피를 낮추고 모드 붕괴를 유도한다는 최근 연구 결과와도 일치합니다. 반대로 제로샷 LLM과 확산 기반 검색은 실행마다 더 넓은 의미 공간을 탐색해 다양성이 높았습니다.

연구팀은 여기서 재현율이 낮다고 검색 품질이 낮은 것은 아니라고 강조합니다. 참조 집합은 완전한 정답이 아니라 질의 의도의 그럴듯한 실현 하나일 뿐이므로, 다양성이 높다는 것은 참조 항목에 담기지 않은 다른 유효한 해석을 찾아내고 있다는 뜻일 수 있습니다. R4T-FOLM은 다양성을 희생하며 커버리지를 높인 반면, R4T-Diffusion은 확산 생성 고유의 다양성을 상당 부분 유지하면서 커버리지를 크게 끌어올렸습니다. Gemma 계열을 보면 R4T-Diffusion은 Vendi Score 46.2 로 제로샷 Gemma3-4B(44.2)보다도 높은 다양성을 유지하면서 Hit@5K를 25.9 에서 54.1 로 두 배 넘게 올렸습니다. 연구팀은 보상 정렬 행동을 확산 사전분포에 증류하는 것이 약한 지도 아래에서 커버리지와 의미적 풍부함의 균형을 잡는 실용적인 방법이라고 정리합니다.

한 가지 알려드릴 점은, Google Research 블로그의 결과 차트는 Vendi Score를 "낮을수록 좋다"고 표기하고 R4T-FOLM(Qwen)의 27.5 를 최고 성적으로 굵게 표시했다는 것입니다. 이는 이 지표를 실행 간 생성 안정성으로 읽은 것으로, 논문 본문이 같은 값을 다양성으로 읽어 R4T-Diffusion의 높은 값을 장점으로 서술하는 것과는 방향이 반대입니다. 이 글은 논문 본문의 해석을 따랐습니다.

보상 해킹 절제 실험: 다양성 항이 닫아 주는 지름길

하지만 "왜 보상을 세 개나 합쳐야 하는가?"라는 의문이 남습니다. 연구팀은 OAR 과제에서 보상 구성 요소를 하나씩 빼 보는 절제 실험(Ablation Study)으로 이 질문에 답합니다.

결과는 명확합니다. 근거성 보상만으로 학습하면 정책은 "line ending line ending line ending" 같은 퇴화된 무의미 문자열로 수렴합니다. 이런 문자열이 우연히 특정 데이터베이스 항목과의 임베딩 거리를 최소화하기 때문입니다. 위 그림의 보상 곡선을 보면, 근거성만 쓴 정책과 근거성+정렬을 쓴 정책은 수백 스텝 만에 보상 0.82 부근까지 치솟아 그대로 고정됩니다. 학습이 잘 된 것이 아니라 보상의 허점을 찾아낸 것입니다.

근거성과 정렬을 함께 쓰면 붕괴가 오히려 더 빨라집니다. 정책이 원 질의의 의역을 반복하기만 해도 정렬 점수가 손쉽게 최대화되고, 의미적 분산은 아무 벌점을 받지 않기 때문입니다. 반면 근거성, 정렬, 다양성을 함께 최적화한 정책은 붕괴하지 않고 보상이 0.53 에서 0.62 까지 1만 스텝에 걸쳐 완만하게 오르며 안정적인 GRPO 학습을 보였습니다.

연구팀은 이 세 항이 상호 견제 앵커(Mutual Counter-anchors) 로 작동한다고 설명합니다. 근거성만 최적화하면 데이터베이스 좌표를 수학적으로 맞추는 퇴화 문자열로 보상을 해킹하고, 정렬을 더하면 원 질의의 의역으로 붕괴합니다. 여기에 Vendi Score라는 기하학적 다양성 지표를 견제 앵커로 넣으면 이런 지름길이 모두 막혀, 정책은 유효하고 엄격하게 근거를 갖추면서도 의미적으로 서로 다른 변형을 찾아내는 균형 잡힌 임베딩 공간 영역으로 밀려납니다. 높은 보상을 받을 수 있는 방법이 검색 전문가처럼 행동하는 것 하나만 남는 셈입니다.

가중치 비율도 학습 동역학을 바꿉니다. Qwen3-4B에서 \lambda_g : \lambda_d : \lambda_a 를 6:2:2, 4:3:3, 2:4:4로 바꿔 본 결과, 근거성이 지배하면 다양성은 오르지만 정렬이 무너지고(위 첫 번째 그림, 정렬 점수가 0.65 부근에서 0.3 아래로 하락), 반대로 정렬과 다양성을 강조하면 탐색이 억제되어 대안적 해석에 대한 커버리지가 줄었습니다. 균형 잡힌 4:3:3 설정에서 세 점수가 모두 안정적으로 수렴했습니다(위 두 번째 그림). 논문의 기본 가중치가 6:2:2(\lambda_g = 0.6, \lambda_d = \lambda_a = 0.2)로 명시된 점을 함께 고려하면, 이 가중치는 도메인과 기본 모델에 따라 조정이 필요한 하이퍼파라미터로 보는 것이 안전합니다. 탐색과 의미 충실도 사이의 교환 관계가 이 실험 전반에 깔려 있습니다.

정성 비교: "Bohemian festival style"

숫자 뒤에 실제로 어떤 결과가 있는지 살펴보겠습니다. "Bohemian festival style" 질의에 대해 R4T는 "bohemian festival dress", "straw boots festival style", "lace bohemian festival"처럼 서로 다른 주제 방향의 하위 질의를 생성했습니다. 각 하위 질의는 시각적으로 일관되면서도 서로 다른 코디 묶음을 가져와, 전체 스타일과의 일관성을 유지하면서 다양성을 확보했습니다. 반면 Qwen3-4B 제로샷은 "bohemian festival style", "bohemian festival fashion", "festival bohemian clothes"처럼 같은 표현의 변형만 만들어, 위 그림의 아래 세 행이 보여주듯 거의 같은 이미지가 반복되는 균질한 결과를 냈습니다.

"Labor day picnic outfit" 질의에서도 같은 경향이 나타났습니다. R4T는 보헤미안, 미니멀리스트, 점프수트 스타일처럼 보완적인 측면으로 질의를 분해해 실루엣, 색상, 액세서리가 서로 다르면서도 계절과 피크닉 맥락에 맞는 코디를 가져왔습니다. Gemini-2.5-Flash는 문장 형태는 다양한 하위 질의를 만들었지만, 검색된 집합은 더 균질하고 의미 커버리지가 제한적이었습니다. 연구팀은 이 정성 결과가 세 보상 항의 역할을 그대로 보여준다고 정리합니다. 근거성은 각 하위 질의가 실제 데이터베이스 항목에 대응하게 하고, 정렬은 원 질의 의도와의 일관성을 지키고, 다양성은 여러 유효한 해석의 탐색을 이끕니다.

효율 분석: 12~20배 빠른 팬아웃

마지막으로 이 논문의 제목에 "Efficient"가 붙은 이유를 보겠습니다. 연구팀은 k = 10 개의 검색 방향을 한 번의 순전파로 생성하는 확산 검색기와, 하위 질의를 순차 생성하고 검색을 호출하는 자기회귀 LLM 팬아웃의 벽시계 지연(Wall-clock Latency)을 배치 크기별로 측정했습니다.

자기회귀 LLM은 작은 배치에서도 큰 고정 비용에 지배되어 배치 8에서 이미 약 1.46 초가 걸리고, 이후 선형으로 늘어나 배치 1,024에서는 50초 가까이 소요됩니다. 반면 53.9M 파라미터의 확산 모델은 임베딩 공간의 비자기회귀 생성 덕분에 작은 배치를 0.07 초, 가장 큰 배치를 4.21 초에 처리합니다. 배치 크기 전 구간에서 12\times 에서 20\times 의 일관된 속도 향상이고, 모델이 작아 배포 메모리 부담도 크게 줄어듭니다. 연구팀은 이 결과가 팬아웃의 부담을 무거운 자기회귀 System 2에서 가벼운 System 1 확산 사전분포로 옮기는 것이 실용적인 실시간 검색에 필수적임을 확인해 준다고 설명합니다.

정리하면, R4T-FOLM을 그대로 배포해도 검색 품질은 우수하지만 자기회귀 지연과 사고 예산(Thinking Budget)이라는 비용이 그대로 따라오고, 그 행동을 확산 모델에 증류하면 품질의 대부분을 유지한 채 지연 병목이 사라집니다. 이것이 논문이 두 배포 변형을 함께 보고한 이유입니다.

한계점 및 향후 연구 방향

연구팀은 논문의 부록에서 네 가지 한계를 밝히고 있습니다.

첫째, RL 단계의 선행 비용입니다. 고정된 검색기와 반복적으로 상호작용하며 보상을 명시적으로 계산해야 하므로, 배포 시점에는 비용이 상각되더라도 데이터베이스가 매우 크거나 자주 바뀌는 환경에서는 학습 오버헤드가 상당할 수 있습니다. 검색 인덱스가 매일 갱신되는 상용 서비스라면 FOLM과 확산 검색기를 얼마나 자주 다시 학습해야 하는지가 실무적인 질문이 됩니다. 연구팀은 더 표본 효율적인 RL, 부분적인 검색기 갱신, 오프라인 근사 등을 후속 방향으로 제시합니다.

둘째, 보상으로 표현할 수 있는 성질만 다룰 수 있다는 가정입니다. 근거성, 정렬, 다양성의 조합이 안정적으로 작동함은 보였지만, 창의성이나 신선함, 문화적 민감성처럼 주관적인 선호는 스칼라 보상으로 옮기기 어렵습니다. 사용자 피드백이나 선호 데이터에서 보상 함수 자체를 학습하는 것이 유망한 방향으로 제시됩니다.

셋째, LLM-as-a-Judge 평가에 대한 의존입니다. OAR의 개방형 품질을 사람이 아닌 Gemini 심판이 매겼으므로, 선행 연구가 사람 판단과의 높은 상관을 보고했다 해도 심판 모델의 편향이 평가에 유입될 수 있고 검색 유용성의 모든 정성적 측면을 담지 못할 수 있습니다. 연구팀은 사람 평가 또는 혼합 평가 프로토콜의 보강을 제안하며, 비교 대상 중 하나가 심판 모델과 같은 계열의 Gemini-2.5-Flash라는 점도 독자가 함께 염두에 둘 부분입니다.

넷째, 특정 아키텍처에 묶인 실증입니다. 프레임워크 자체는 일반적이지만, 실험 결과는 기본 언어 모델, 임베딩 공간, 확산 아키텍처 선택에 의존할 수 있습니다. 다른 검색 백본, 모달리티, 과제 설정으로의 확장은 열려 있는 과제입니다. 연구팀은 R4T를 복잡한 목표 아래 집합값 검색 시스템을 확장 가능하게 학습하는 첫걸음으로 보며, 제어 가능한 검색의 모든 형태를 해결한 완성된 답으로 보지는 않는다고 적었습니다.

여기에 더해 논문의 영향 진술은 보상 명세가 곧 검색 행동을 결정하는 구조의 위험을 지적합니다. 보상을 부주의하게 설계하면 학습 데이터의 편향이 검색 결과에 반영되고, RL 기반 합성은 그 편향을 합성 데이터를 통해 대규모로 전파할 수 있습니다. 이번 실험은 패션과 음악이라는 비교적 무해한 도메인에 한정되었지만, 같은 기법이 민감한 맥락에 적용될 때는 도메인별 편향 감사와 감독 장치가 함께 가야 한다는 것입니다.

한 걸음 물러서 보면, R4T가 제시하는 "RL을 추론 엔진이 아니라 데이터 생성 엔진으로 쓴다"는 구도는 검색 바깥에서도 쓸 수 있는 일반적인 패턴입니다. 정답이 애매하거나 주관적이어서 지도 데이터를 모으기 어렵지만 보상은 정의할 수 있는 문제, 즉 계획, 디자인, 창작 생성 같은 구조화된 생성 과제에 같은 방식을 적용할 수 있다고 연구팀은 전망합니다. 비싼 System 2의 탐색 결과를 싼 System 1 모델에 컴파일해 두는 이 구조가, 추론 시점 연산 비용이 급증하는 최근 흐름에 대한 하나의 대안적 해법이라는 점에서 눈여겨볼 가치가 있습니다.

Efficient, Property-Aligned Fan-Out Retrieval via RL-Compiled Diffusion 논문

으으... 안하던 트위터를 하게 되네요 https://x.com/thsottiaux/status/2102254445082116335 2개의 게시물 - 1명의 참여자 전체 글 읽기

MiMo-V2.6 소개

Xiaomi의 MiMo 팀이 2026년 9월 22일 MiMo-V2.6 시리즈 를 공개하고 가중치를 오픈소스로 배포했습니다. 텍스트와 이미지, 영상, 음성을 한 모델에서 처리하는 옴니모달(Omnimodal) 구조에 희소 전문가 혼합(Sparse Mixture of Experts, MoE) 백본을 얹었고, 컨텍스트 길이는 두 모델 모두 100만(1M) 토큰입니다. 크기는 서로 다릅니다. MiMo-V2.6-Pro는 총 1.02조(1.02T) 파라미터 중 42B를 활성화하고, 지능 대비 비용 균형을 노린 MiMo-V2.6-Flash는 총 310B 중 15B를 활성화합니다. 여기에 같은 품질에서 출력 속도를 최대 20배까지 끌어올린 MiMo-V2.6-Pro-UltraSpeed가 더해집니다.

이 시리즈가 앞선 MiMo-V2.5와 다른 점은 모델 크기가 아니라 사후 학습(post-training)에 투입한 계산량입니다. MiMo 팀은 이번 릴리즈를 재귀적 자기 개선(Recursive Self-Improvement, RSI) 경로를 탐색하는 단계로 설명하면서, 검증 가능한 복잡한 과제 위에서 강화학습(Reinforcement Learning, RL) 계산량 자체를 키우면 모델이 탐색과 피드백만으로 능력의 경계를 계속 넓힐 수 있는지를 확인하려 했다고 밝혔습니다. RL에 들어가기 전에는 광범위한 멀티모달 말뭉치로 중간 학습(mid-training)을 돌려 에이전트가 탐색할 공간부터 넓혀 두었습니다. 실제 RL은 6일이 채 안 되는 기간에 30번의 스텝으로 진행했고, 그 과정을 별도 페이지에서 실시간으로 중계했습니다.

그리고 이번에는 결과물만 내놓지 않았습니다. 기술 보고서와 학습 환경, RL 프레임워크, 그리고 RL 실험의 출발점으로 쓰라고 만든 9B 증류 모델까지 함께 공개해 다른 연구자가 같은 실험을 재현하고 검증할 수 있게 하겠다는 것이 이번 발표의 두 번째 축입니다. 오픈 웨이트 모델이 늘어나는 동안에도 사후 학습 레시피와 환경은 대체로 닫혀 있었다는 점을 생각하면, 공개 범위 자체가 이번 릴리즈에서 눈여겨볼 대목입니다.

같은 가격표로 파레토 프론티어를 한 번 더 민 결과

MiMo-V2.6-Pro는 Artificial Analysis 지능 지수(Intelligence Index) v4.3에서 46.32점을 기록했습니다. 이 지수는 AA-Briefcase, GDPval-AA v2, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR v1.1의 10개 평가를 묶은 값입니다. 같은 지수에서 Kimi K3는 44점, Qwen3.8 Max는 45점이고, MiMo 팀은 이 두 모델을 넘어선 현재까지 가장 강력한 오픈소스 모델이라고 밝혔습니다. MiMo-V2.5-Pro가 26점이었으니 한 세대 만에 20점가량 올라온 셈입니다.

다만 지수 상위권은 여전히 상용 모델이 차지하고 있습니다. Claude Fable 5.1과 GPT-6 Astra가 53점, Claude Opus 5가 51점, Muse Spark 1.3이 48점, GPT-5.6 Sol이 47점입니다. MiMo-V2.6-Pro의 위치는 "프론티어를 추월했다" 가 아니라 "오픈소스 진영에서 프론티어와의 거리를 가장 좁혔다" 에 가깝습니다.

그러나 가격 쪽에서는 이야기가 달라집니다. MiMo 팀은 V2.5 시리즈의 API 가격표를 그대로 유지했습니다. 지능은 올라가고 비용은 그대로이므로, 작업 한 건당 비용 대비 지능을 그린 평면에서 파레토 경계가 한 번 더 바깥으로 밀려납니다. 아래 산점도에서 MiMo-V2.6-Pro는 작업당 0.15달러 안팎 지점에 놓여 있는데, 비슷한 점수대의 GLM-5.3(max)이나 Kimi K3(max)가 2달러 부근에 있는 것과 비교하면 자릿수가 다릅니다.

1.02T MoE 위에 올린 옴니모달 백본

모델 구조는 시각과 음성 두 갈래의 입력 인코더, 하나의 하이브리드 백본, 그리고 투기적 디코딩(speculative decoding)용 헤드로 나뉩니다.

백본은 70개 레이어로, 이 중 60개가 슬라이딩 윈도우 어텐션(Sliding Window Attention, SWA), 10개가 전역 어텐션(Global Attention, GA)입니다. 첫 블록만 전역 어텐션에 밀집(dense) FFN을 쓰고 나머지 블록은 SWA와 GA를 번갈아 배치하면서 공유 전문가 없이 희소 MoE FFN을 사용합니다. 라우팅되는 전문가는 384개이고 토큰당 8개가 활성화됩니다. 히든 크기는 6144, 어텐션 헤드는 Q 128개에 KV 8개이며 슬라이딩 윈도우 크기는 128입니다.

시각 인코더인 MiMo ViT는 681M 파라미터에 28개 레이어(SWA 24개, GA 4개)로 구성되고, 패치 크기는 시간 2 곱하기 높이 16 곱하기 너비 16입니다. 음성 쪽은 20개의 잔차 벡터 양자화(Residual Vector Quantization, RVQ) 코드북을 가진 308M AudioTokenizer 인코더와 127M 오디오 패치 인코더로 나뉘며, 패치 하나가 네 프레임을 묶어 25Hz 입력을 6.25Hz로 줄입니다.

마지막으로 다중 토큰 예측(Multi-Token Prediction, MTP) 드래프터가 5개 SWA 레이어로 붙어 한 번의 순전파에서 뒤따르는 7개 토큰을 예측하고, 본 모델이 이를 병렬로 검증합니다. DFlash 계열 구조이며, 토큰을 하나씩 순차로 뽑는 대신 여러 개를 미리 뽑아 두고 한꺼번에 확인하므로 디코딩 처리량이 올라갑니다.

6일, 30스텝, 75만 궤적: 강화학습 계산량을 키운 방식

이번 릴리즈의 핵심은 여기입니다. MiMo-V2.6-Flash와 MiMo-V2.6-Pro는 각각 약 75만 개의 궤적(trajectory) 위에서 30번의 RL 스텝을 6일 이내에 마쳤고, 비용은 각각 약 85만 달러와 262만 달러가 들었습니다. 학습 과제의 평균 통과율은 상대 기준으로 각각 25%와 12% 올랐습니다.

한편 더 중요한 것은 학습에 쓰지 않은 벤치마크에서도 같은 방향으로 움직였다는 점입니다. 장기 과제형 소프트웨어 엔지니어링 벤치마크인 DeepSWE v1.1에서 Flash는 48.8점에서 65.68점으로 약 17점, Pro는 58.4점에서 72.57점으로 약 14점 올랐습니다. 아래 곡선을 보면 30스텝 내내 점수가 계속 오르고 있어서, 학습이 수렴해 멈춘 것이 아니라 계산량을 더 넣을 여지가 남아 있는 상태에서 끊긴 것에 가깝습니다.

MiMo 팀은 RL 계산량을 세 축으로 나누어 키웠다고 설명합니다.

• 더 큰 배치와 더 높은 처리량: 완전 비동기(fully asynchronous) 아키텍처 위에서 한 스텝에 1,568개 프롬프트를 쓰고, 각 프롬프트마다 그룹 크기 16으로 롤아웃(rollout)을 생성합니다. 그룹 상대 정책 최적화(Group Relative Policy Optimization, GRPO) 구성이며, 스텝 하나가 2만 5천 개 시퀀스, 시퀀스당 11만에서 15만 토큰, 합쳐서 2.7B에서 3.7B 학습 토큰이 됩니다. 최대 컨텍스트는 100만 토큰입니다. (블로그는 같은 값을 3.5B에서 3.7B로 적고 있습니다.)

• 더 많은 과제와 더 풍부한 환경: 코딩, 범용 에이전트, 시각, 사이버 보안을 아우르는 멀티태스크 학습 세트를 여러 하네스(harness)에 섞어 한 배치 안에 함께 넣습니다. 한 능력에서 얻은 개선이 다른 능력을 밀어 올리도록 만드는 구성이고, 모델 카드는 이를 "You Only RL Once" 라고 부릅니다. 도메인별로 RL을 따로 돌리지 않습니다.

• 더 많은 채점 계산량: 통과와 실패를 나누는 이진 보상만으로는 통과한 해답들 사이의 우열을 가릴 수 없습니다. 그래서 보상 신호 자체에 계산량을 투입해, 같은 그룹 안의 롤아웃끼리 상대 비교를 시킵니다. 장기 과제형 RL에 더 정밀하고 더 다양한 보상 신호가 들어가고, 모델은 더 짧은 경로와 더 적은 토큰으로 유도됩니다. 기술 보고서가 밝힌 Pro의 RL 비용 배분은 롤아웃 43.8%, 학습 43.5%, 채점 12.7%로, 채점에만 전체의 8분의 1가량이 들어갔습니다.

그룹 단위 채점으로 닫은 자기 개선 루프

세 번째 축을 구현한 장치가 두 가지입니다. 그룹 단위 보상 합성(Groupwise Reward Synthesis, GRS) 은 서로 대비되는 롤아웃들로부터 과제별 루브릭(rubric)을 오프라인에서 만들어 두고, 루브릭 품질 점수와 테스트 통과 결과를 합쳐 보상으로 씁니다. 그룹 단위 어드밴티지 재분배(Groupwise Advantage Redistribution, GAR) 는 통과한 궤적들을 온라인으로 순위 매겨 어드밴티지를 더 나은 해답 쪽으로 옮깁니다. 두 장치 모두 판단 기준이 외부 정답이 아니라 정책 자신이 뽑아낸 샘플이므로, 모델이 좋아질수록 채점 기준도 함께 올라가는 자기 개선 루프가 닫힙니다.

한편 학습 규모가 커지면서 따라오는 문제도 함께 다뤘습니다. 학습 중 드리프트를 억제하려고 MoE 라우터를 동결했고, 보상 해킹(reward hacking)에 대해서는 보상 설계와 적대적 평가, 이상 탐지, 검증기 간 교차 확인을 묶은 방어를 구성했습니다. 확인된 해킹 궤적은 그룹 통계를 다시 계산하기 전에 보상을 0으로 만들며, 기술 보고서는 이 보정 이후 확인된 해킹 비율이 두 모델 모두 학습 전 구간에서 2% 아래로 유지되었다고 밝혔습니다. 정렬(alignment) 쪽은 자기 교정에서 출발하는 콜드 스타트를 씁니다. 모델이 자신의 어긋난 응답을 돌아보고 근거 있는 다음 단계로 다시 쓰게 하는 방식입니다.

혼합 RL이 끝난 뒤에는 다중 프리픽스 다중 교사 온폴리시 증류(Multi-Prefix Multi-Teacher On-Policy Distillation, MOPD2) 를 적용합니다. 학생 모델이 스스로 만든 롤아웃과, 교사 궤적 및 지도 미세조정(SFT) 시연에서 가져온 앞부분을 조건으로 건 단일 턴 롤아웃을 함께 씁니다. 앞선 턴들을 다시 생성하지 않고도 의사 결정 지점만 골라 학습시킬 수 있어서, 검증하기 어려운 과제까지 능력을 넓히는 데 쓰입니다.

이질적인 과제를 대규모로 함께 돌리기 위한 시스템 작업도 적지 않습니다. 통합 궤적 표현과 페널티 메커니즘으로 더 세밀한 학습 신호를 만들었고, 여러 에이전트 프레임워크와의 고동시성 상호작용을 지원하도록 제어 평면(control plane)과 데이터 평면(data plane)을 분리해 대규모 궤적 이관을 가능하게 했으며, 혼합 배치 안에서 과제별 샘플링 비율이 흔들리지 않도록 안정화했으며, 학습 엔진과 추론 엔진 각각은 물론 둘 사이의 일관성까지 함께 최적화했습니다.

무엇을 함께 공개했는가

가중치만 던지고 끝내지 않은 부분이 이번 릴리즈에서 가장 실용적인 대목입니다. 기술 보고서는 세 가지를 함께 공개한다고 밝히고 있습니다. 첫째는 MiMo-V2.6-Distill-Qwen-9B입니다. Qwen3.5-9B를 MiMo가 생성한 데이터로 지도 미세조정한 9B 모델로, 학습 데이터는 코드와 사이버, 범용, 시각 네 도메인에 걸쳐 총 774억 토큰이고 이 중 손실 계산에 실제로 기여하는 토큰이 272억 개입니다. 원본 Qwen3.5-9B 대비 SWE-bench Pro가 32.0에서 44.6으로, AutomationBench가 5.0%에서 30.3%로 올랐습니다. 큰 모델을 돌릴 수 없는 연구자가 RL 실험을 시작할 공통 출발점으로 쓰라는 의도입니다.

둘째는 검증기가 붙은 RL 환경입니다. 네 도메인에 약 7천 개 과제가 들어 있고, 여기에 음악 생성 과제 약 1천 개가 더해집니다.

셋째는 이 환경을 실행하는 엔드투엔드 RL 프레임워크입니다. 기술 보고서는 위 9B 체크포인트에서 출발해 도메인별 GRPO를 돌린 베이스라인까지 함께 싣고 있는데, 표에 오른 11개 평가가 모두 개선되었습니다. SWE-bench Verified는 61.1에서 66.2로, Terminal Bench 2.1은 37.1에서 52.8로, MiMo Visual Coding(mini)은 64.0에서 72.4로 올랐습니다. 공개한 자원만으로 재현 가능한 출발선을 그려 둔 셈입니다.

에이전트 강화학습 환경의 공통 인터페이스에 관심이 있으시다면 다음 글도 함께 참고해주세요:

[OpenEnv 종합 정리, 에이전트 강화학습 환경의 공통 인터페이스 계층 구조도] OpenEnv 소개: 에이전트에게 부족한 것은 모델이 아니라 환경입니다 OpenEnv는 AI 에이전트가 상호작용할 환경(Environment) 을 만들고, 배포하고, 학습 루프에 연결하는 절차를 하나의 규격으로 묶는 오픈소스 인터페이스 라이브러리입니다. 터미널, 브라우저, 코드 저장소, 캘린더처럼 에이전트가 실제로 조작하는 대상을 격리된 컨테이너로 감싸고, 그 안에서 무엇을 볼 수 있고 무엇을 할 수 있는지를 명시적으로 선언합니다. 2025년 10월 Meta와 Hugging Face가 공동으로 시작했고, 2026년 6월에는 11개 조직으로 구성된 기술위원회가 운영을 맡는 중립 프로젝트로 전환했습니다. 강화학습(Reinforcement Learning, RL) 으로 에이전트를 학습시키려면 세 가지가 필요합니다. 정책을 갱신하는 학습기, 모델이 도구를 부르고 결과를 읽는 하네스(harness), 그…

Bend 2 소개

Bend 2는 프로그램이 지켜야 할 규칙을 사람이 LAWS.bend라는 파일에 적어 두면, 코드가 바뀔 때마다 컴파일러가 그 규칙의 수학적 증명(Proof) 을 요구하는 프로그래밍 언어입니다. 증명이 없으면 bend PROOF.bend 검증이 실패하므로, 이 명령을 커밋 게이트로 걸어 두면 규칙을 깨는 코드는 사람이 일일이 검토하지 않아도 걸러집니다. Bend 2는 2026년 9월에 GitHub 저장소를 통해 공개되었고, 라이선스는 Apache License 2.0입니다.

이 설계가 나온 배경에는 지난 2년간 코딩 도구가 놓인 자리 변화가 있습니다. 에이전트가 수백 줄짜리 변경을 몇 분 만에 만들어 내면서, 사람이 모든 diff를 읽는 전제가 무너졌습니다. 그 공백을 메우려고 등장한 것이 AGENTS.md 같은 지침 파일이고, PyTorchKR에도 AGENTS.md 표준을 소개한 글이 올라와 있습니다. 다만 이런 파일에 적히는 것은 결국 자연어 문장이라, 모델이 따르지 않았을 때 그것을 잡아내는 장치가 파일 자체에는 없습니다. Higher Order Company에서 Bend를 만든 Victor Taelin은 저장소 첫 문단에서 이 문제를 문제와 해법 두 줄로 제시합니다. 읽지 않은 AI 코드를 어떻게 신뢰할 것인가가 문제이고, AI에게 정확성 증명을 쓰도록 강제하는 것이 해법이라는 것입니다.

Bend는 여기에 두 번째 조건을 답니다. 증명 검사가 느리면 에이전트가 수정할 때마다 실행할 수 없으니 실제로는 쓰이지 않는다는 것입니다. 그래서 Bend는 정리 증명기의 검사 속도를 끌어올리는 쪽으로 타입 시스템을 설계했고, 같은 컴파일러가 만든 실행 파일이 CPU 한 코어에서 C에 가까운 속도로, 그리고 수정 없이 GPU에서도 실행되도록 런타임(Runtime)을 붙였습니다. 프로젝트가 스스로를 소개하는 네 마디가 C 수준 속도, CUDA 수준 병렬성, Lean 수준 증명, Python 문법입니다.

Bend라는 이름은 처음 나온 것이 아닙니다. 2024년 공개된 Bend 1은 같은 저자의 HVM2 위에서 상호작용 조합자(Interaction Combinators)로 평가를 수행하는 언어였습니다. Bend 2는 그 메커니즘을 완전히 제거했습니다. 저장소의 제약 목록 첫 줄이 "Bend 2는 새로운 언어입니다. Bend 1 프로그램과 HVM은 이어지지 않습니다" 이고, 런타임 논문도 관련 연구 절에서 목표는 유지하고 메커니즘은 버렸다고 명시합니다. 최적 공유(optimal sharing)를 포기하는 대신 네이티브 속도의 순차 코드, 평평한 메모리, 프로그래머가 읽을 수 있는 비용 모델을 얻었다는 설명입니다.

자연어 지침, 테스트, 법칙은 무엇이 다른가

Bend가 무엇을 새로 제공하는지 보려면, 코드가 규칙을 지키는지 확인하는 기존 수단들과 나란히 놓고 보는 편이 빠릅니다.

위 표에서 갈라지는 지점은 세 번째 열과 네 번째 열입니다. 테스트가 보장하는 것은 작성자가 떠올린 입력들에서 통과했다는 사실이고, 법칙이 보장하는 것은 그 타입의 값 전부에 대해 참이라는 사실입니다. Bend 데모 저장소의 설명이 이 차이를 짧게 정리합니다. "많이 테스트했다가 아니라, 모든 길이의 모든 입력 시퀀스에 대한 기계 검증된 정리입니다."

물론 법칙 자체를 사람이 잘못 적으면 보장은 그만큼만 유효합니다. 이 점은 뒤의 제약 절에서 다시 다루겠습니다.

LAWS.bend와 PROOF.bend: 사람이 쓰는 파일과 AI가 쓰는 파일

Bend 프로젝트는 저장소 루트에 파일 두 개를 두는 관례를 제시합니다. LAWS.bend는 코드를 import한 뒤 지켜야 할 성질을 선언만 합니다. 사람이 쓰고 AI는 건드리지 않습니다. PROOF.bend는 LAWS.bend를 import해 같은 이름의 정의로 각 법칙을 채웁니다(law sorted는 def Laws.sorted가 채웁니다). 이쪽은 AI가 코드와 함께 씁니다. 검증 명령은 bend PROOF.bend 하나이고, 법칙이 하나라도 비어 있거나 거짓이면 실패하며, 전부 채워졌을 때만 All terms check. 를 출력합니다.

데모의 README는 이 분업을 한 문장으로 요약합니다. "사람은 벽을 유지하고, 기계는 벽 반대편에서 거짓말하는 것만 빼고 무엇이든 합니다."

여기서 자연스럽게 나오는 반론이 있습니다. AI가 LAWS.bend를 지우거나 PROOF.bend에서 그 import를 빼 버리면 되지 않느냐는 것입니다. 가이드는 이 구멍 하나를 도구 차원에서 막아 둡니다. bend는 LAWS.bend 옆에 있으면서 그것을 import하지 않는 PROOF.bend를 거부합니다. 나머지는 관례의 영역입니다. LAWS.bend는 사람의 파일이고, 그 파일의 변경은 diff에서 몇 줄에 불과해 사람이 실제로 읽을 수 있는 분량이라는 점이 이 분업의 전제입니다.

저장소는 법칙으로 옮길 만한 규칙의 예시를 다음과 같이 듭니다. 도메인을 가리지 않고 "무엇이 절대 일어나면 안 되는가" 로 쓸 수 있는 것이면 법칙이 됩니다.

• 모든 잔고의 합은 0이어야 한다
• 플레이어는 단단한 벽을 통과할 수 없다
• list_sort() 는 언제나 오름차순 숫자를 반환해야 한다
• array_set() 은 범위 밖으로 호출될 수 없다
• 승리는 불가능하다

승리가 불가능하다는 것을 증명한 게임

공식 데모 app_win_is_bug_2d는 깃발을 밟으면 이기는 아주 작은 게임에, "승리는 불가능하다" 는 법칙 하나를 붙여 둔 것입니다. 출발 상태에서는 깃발이 좌상단 방 안에 있고 벽이 그 방을 막고 있어, 플레이어가 아무리 움직여도 벽에 부딪힐 뿐입니다.

여기에 새 기능을 요청합니다. "Claude, 보드가 가장자리에서 반대편으로 이어지게 해 줘." LAWS.bend가 없다면 AI는 요청대로 랩어라운드를 구현하고, 그 결과 플레이어가 가장자리를 돌아 깃발에 도달합니다. 규칙은 깨졌고 버그는 병합됩니다.

LAWS.bend가 있으면 같은 수정이 컴파일을 통과하지 못합니다. AI는 법칙이 다시 성립할 때까지 재시도해야 하고, 이 데모에서는 먼 쪽 가장자리에 벽을 세우는 것으로 해결했습니다. 보드가 토러스(torus)가 되었으므로 화면 반대편 가장자리가 곧 그 방의 나머지 두 벽입니다. 저장소에 실린 최종 지도는 다음과 같고, F가 깃발, P가 플레이어입니다.

...#.......#
.F.#.......#
...#.......#
####.......#
............
........P...
............
####........

깃발을 옮기든, 방을 즉사 지역으로 만들든 방법은 자유이고, 할 수 없는 것은 오직 버그를 커밋하는 일입니다.

법칙과 증명은 다음과 같은 모양입니다. for는 전칭 한정(for all)이고, 중괄호로 감싼 {a == b : T} 가 명제적 동등성입니다.

# LAWS.bend
law you_cant_win:
  for moves: List<Game.Move>                # any sequence of moves
  board = Game.replay(Game.start(), moves)  # replayed from the start
  {Game.is_won(board) == False{} : Bool}    # never leads to victory

「프로그램 소개」 Ship to Production(STP)은 CloudBro Community가 운영하는 시즌제 오픈소스 인큐베이팅 프로그램입니다. 현장의 문제에서 출발한 오픈소스 프로젝트가 12주 동안 아이디어 검증과 기술 검증을 거쳐 실제 프로덕션까지 도달하도록 지원합니다. 현제, 시즌 I~III을 통해 17개 프로젝트가 론칭되었고, 이 중 8개가…

Jev Search 소개

웹 검색에 언어 모델을 결합하는 방식은 지금 거의 하나로 수렴해 있습니다. 사용자의 질문을 모델이 읽고, 검색어를 새로 써서 엔진에 던지고, 돌아온 문서를 다시 읽어 답변 문장을 만들어 냅니다. 편리한 대신 대가가 따릅니다. 검색어를 모델이 매번 새로 쓰기 때문에 같은 질문이 같은 검색으로 이어진다는 보장이 없고, 화면에 남는 것이 링크가 아니라 문장이라 그 문장이 원문을 정확히 옮겼는지는 사용자가 따로 확인해야 합니다. 이번에 소개하는 Jev Search는 반대쪽에서 출발한 웹 검색 애플리케이션으로, 모델에게 문장을 쓰게 하지 않고 어디를 찾을지 고르는 일과 돌아온 결과가 질문에 맞는지 채점하는 일만 맡깁니다.

Jev Search가 판단에 쓰는 모델은 TypeSafe의 Jev ( Jev, 토큰 대신 확률적 결정을 내놓는 새로운 형태의 System One 모델 (feat. TypeSafe AI))인데, 이 모델은 애초에 문자열을 만들어 내지 못합니다. Jev는 타입이 정해진 질문에 확률로 답하는 System One 모델이라, 주어진 선택지 중 하나를 고르거나 어떤 진술이 참일 확률을 돌려주는 일만 합니다. 그래서 Jev Search는 보통과 반대 방향으로 설계되어 있습니다. 검색어 후보, 출처 목록, 기간 구간을 전부 코드가 미리 만들어 두고, Jev는 그중에서 고르기만 합니다. 저장소의 src/lib/candidates.ts 주석은 이 설계를 "The judge selects, it does not generate" 라고 한 줄로 적어 두었습니다.

Jev Search를 만든 곳은 TypeSafe가 아니라 웹 검색 API 업체인 Search1API입니다. 저장소는 이 회사의 GitHub 조직인 SuperAgents Lab에 있고, 개발사인 Search1API는 이 프로젝트가 독립 프로젝트이며 TypeSafe의 공식 제품이 아니라는 점을 명시하고 있습니다. 실제 검색은 Search1API의 상용 검색 API가 처리하므로 직접 배포하려면 이 회사의 API 키가 필요하고, 신규 계정에는 1회성 무료 크레딧 100건이 주어지며 기본 검색 한 건이 1크레딧을 씁니다. 애플리케이션 자체는 TanStack Start와 React로 작성되어 Cloudflare Workers 위에서 돌아가고, 개발사가 운영하는 공개 데모는 가입 없이 바로 쓸 수 있습니다. 브라우저에서 앱으로 설치하는 것도 되지만 오프라인에 저장되는 것은 안내 페이지 한 장뿐이라, 검색 자체는 네트워크가 있어야 동작합니다.

Jev Search와 모델이 문장을 만들어 주는 방식의 차이

Jev Search는 자신이 무엇을 하지 않는지로 스스로를 설명합니다. 화면 아래쪽 크레딧 줄에 "No generated answers" 라고 적어 둔 것이 그 선언입니다. 모델이 문장을 만들어 주는 방식과 견주면 다른 점은 다음과 같습니다:

오른쪽 열이 이렇게 된 것은 Jev Search가 고른 제품 전략이라기보다 모델의 제약에서 따라온 결과입니다. Jev가 문자열을 생성하지 못하니 검색어를 지어낼 수 없고, 그래서 규칙으로 후보를 만들어 고르게 하는 방법 외에 다른 선택지가 없습니다. 이 제약에서 두 가지가 따라옵니다. 검색어가 규칙으로 만들어지므로 같은 요청은 같은 후보 집합을 낳고, 화면에 남는 것이 링크라 사용자가 원문을 직접 엽니다. 잃는 것도 분명합니다. 여러 문서를 읽고 결론을 정리해 주는 일은 Jev Search가 하지 않습니다.

Jev Search를 사용하면 좋을 사용자

질문을 던진 뒤 그 결과가 왜 올라왔는지 확인하고 싶은 사람에게 Jev Search가 맞습니다. 어느 출처를 어떤 기간으로 뒤졌는지가 칩으로 드러나 있고 결과마다 관련도 숫자가 붙어 있어서, 검색이 빗나갔을 때 무엇을 바꿔야 하는지가 화면에서 읽힙니다. 반대로 여러 문서를 읽고 결론을 요약해 주는 도구를 찾고 있다면 Jev Search가 적절한 선택지가 아닙니다. 자체 호스팅을 검토하는 팀이라면 Search1API 키와 Jev 제공자 자격 증명이 둘 다 필요하고 검색 한 번이 여러 번의 유료 호출로 이어진다는 점을 먼저 계산해 봐야 합니다.

Jev Search가 요청을 해석하는 방식

Jev Search는 사용자가 입력한 문장 하나를 받습니다. src/lib/validate.ts가 이 문장을 300자까지만 받아들이고, 그다음부터는 코드가 선택지를 만드는 단계입니다. src/lib/candidates.ts는 정규식으로 검색어 후보를 최대 4개까지 만듭니다. 첫 번째는 사용자가 입력한 문장 그대로이고, 두 번째는 시간 표현과 출처 표현을 제거한 것, 세 번째는 거기서 의문사와 조동사 같은 기능어까지 뺀 내용어만 남긴 것, 네 번째는 대문자로 시작하는 낱말과 숫자가 든 토큰만 모은 고유명사 후보입니다. 네 번째 후보는 IMDb처럼 문장이 아니라 작품 이름을 받아야 하는 카탈로그 엔진을 위한 것입니다.

후보가 준비되면 Jev를 한 번 호출하면서 질문 15개를 함께 보냅니다. 기간을 고르는 질문 1개(전체, 24시간, 1주, 1개월), 출처 12곳에 하나씩 붙는 예/아니오 질문 12개, 검색어 후보 중 하나를 고르는 질문 1개, 카탈로그 엔진용 이름 후보를 고르는 질문 1개입니다. 뒤의 두 질문은 후보가 둘 이상일 때만 실리므로, 고를 것이 없는 짧은 요청에서는 질문이 13개로 줄어듭니다. 출처 질문의 문구는 src/lib/sources.ts에 출처별로 박혀 있고, 질문만 있는 것이 아니라 예라고 볼 조건과 아니오라고 볼 조건이 함께 적혀 있습니다. GitHub 출처를 예로 들면 사용자가 코드를 찾고 있는지 묻고, 저장소, 릴리즈, 이슈, 오픈소스 도구를 찾는 요청이면 예, 코드가 아니라 토론이나 뉴스, 의견을 찾는 요청이면 아니오라고 판단 기준을 적어 둡니다.

돌아온 확률이 0.6 이상인 출처만 실제로 검색합니다. 12곳 모두 같은 기준을 적용받고, 어느 곳도 이 기준을 넘지 못했을 때만 기본값인 Google, DuckDuckGo, Yandex 세 곳으로 대신 검색합니다. Hacker News, Reddit, GitHub은 각각 두 갈래(lane)로 검색하는데, 한쪽은 Google을 해당 사이트로 제한해 검색하고 다른 한쪽은 그 플랫폼 전용 엔진을 씁니다. 두 갈래는 병렬로 돌아가고 나중에 합쳐지므로, 한쪽 엔진이 죽어도 다른 쪽 결과가 남습니다.

Jev의 판단은 사용자가 덮어쓸 수 있습니다. 화면 위쪽의 출처 칩과 기간 칩을 직접 바꾸면 src/lib/pipeline.ts가 모델이 고른 값 대신 사용자가 지정한 값을 씁니다. 여기까지가 첫 번째 판단이고, 결과가 돌아온 뒤에 두 번째 판단이 한 번 더 있습니다:

Jev Search의 관련도 점수와 결과 정렬

두 번째 판단은 채점입니다. 엔진이 돌려준 결과 하나하나에 대해 Jev에게 예/아니오 질문을 하나씩 던지는데, 질문의 내용은 이 결과가 사용자가 물은 주제에 관한 것인지입니다. 이때도 판단 기준이 함께 갑니다. 제목이나 요약이 같은 주제를 다루면 짧게 스쳐도 예, 같은 낱말을 공유할 뿐 다른 뜻이거나 동명이인이면 아니오입니다. 결과가 많으면 40건씩 묶어 여러 호출로 나누고, 묶음들은 병렬로 돌립니다. Cloudflare와 Vercel의 모델 목록에 적힌 Jev의 컨텍스트 창이 32,000 토큰이라, 한 호출에 넣을 수 있는 결과 수에는 상한이 있습니다. 모델에게 넘어가는 것은 각 결과의 출처, 제목, 요약뿐이고 본문은 가져가지 않습니다.

이렇게 돌아온 0에서 1 사이의 확률이 화면에 백분율로 표시됩니다. 기본 정렬인 Best match 의 규칙은 src/lib/rank.ts에 있는데, 관련도가 높은 순서가 1순위이고, 같으면 같은 URL을 돌려준 엔진이 많은 쪽이 앞이며, 그것도 같으면 엔진이 매긴 원래 순위를 따릅니다. 두 번째 기준이 있는 이유는 서로 다른 엔진이 같은 문서를 올렸다는 사실 자체를 신호로 쓰기 위해서입니다. 관련도가 0.3 미만인 결과는 목록에서 지우지 않고 접어 둔 뒤, 몇 건이 접혀 있는지를 적은 버튼 아래로 옮깁니다. 관련도 앞의 점 색깔은 0.7 이상이면 초록, 0.4 이상이면 주황, 그 아래면 회색입니다. 오른쪽 위의 Newest 로 바꾸면 최근에 발행된 순서가 앞에 오고 발행 시각을 모르는 결과가 맨 뒤로 갑니다. 이 전환은 이미 받아 둔 결과를 다시 늘어놓을 뿐이라 검색을 새로 돌리지 않습니다.

같은 내용이 여러 줄을 차지하지 않도록 병합도 두 겹으로 합니다. 먼저 URL을 정규화해서 utm_으로 시작하는 추적 파라미터와 fbclid, gclid 같은 값을 떼어내고 twitter.com은 x.com으로 맞춘 뒤 같은 주소를 한 줄로 합칩니다. 그러고 나서 제목에서 | Hacker News, : r/서브레딧 같은 꼬리표를 제거하고 앞쪽 여덟 낱말이 같으면 같은 이야기로 묶습니다.

아래 화면은 Rust async runtimes on Hacker News this month 를 그대로 입력했을 때의 결과입니다. 위쪽 칩 두 개가 Jev가 고른 기간(Past month)과 출처(Hacker News)이고, 그 아래 줄의 16 found · 13 answer you는 엔진이 16건을 돌려줬고 그중 13건이 질문에 답한다고 채점됐다는 뜻이며, 각 결과 밑의 95% on topic이 관련도입니다:

이 숫자를 정확도로 읽으면 안 된다는 점은 Jev Search가 직접 적어 두었습니다. 관련도는 모델의 판단이지 검증된 정확도가 아니고, 검색 요약문은 틀렸거나 불완전하거나 낡았을 수 있으며, 기존 결과를 고르고 순위를 매기는 일이 그 결과의 주장을 검증해 주지는 않는다는 것이 한계 항목의 내용입니다.

Jev Search의 스트리밍 파이프라인과 장애 처리

Jev Search의 검색 엔드포인트는 src/routes/api/ask.ts의 POST /api/ask 하나이고, 응답은 줄 단위 JSON을 흘려보내는 방식입니다. 흐르는 이벤트는 네 종류로, 요청을 어떻게 해석했는지 알리는 intent, 엔진이 몇 건을 찾았는지 알리는 found, 채점이 끝난 결과 묶음을 보내는 lane, 끝났다고 알리는 done 순서입니다. intent 이벤트에는 어느 Jev 제공자가 답했는지도 judge 필드로 함께 실립니다. 마감 시간은 엔진 하나당 15초, 요청 전체가 30초입니다.

첫 응답을 앞당기려고 투기적 검색(speculative search)도 한 갈래 미리 던져 둡니다. Jev가 질문을 해석하는 동안 사용자가 입력한 문장을 그대로 Google에 던져 두고, 나중에 Jev가 마침 그 문장을 검색어로 고르고 기간 제한도 두지 않았다면 미리 받아 둔 결과를 그대로 씁니다. 조건이 어긋나면 그 결과는 버립니다. 성공한 응답은 Cloudflare KV에 캐시되는데, 보존 시간은 사용자가 원한 기간에 따라 다릅니다. 24시간 범위는 10분, 1주는 1시간, 1개월은 2시간, 기간 제한이 없으면 6시간입니다.

장애가 나는 경로마다 처리 방식이 정해져 있습니다. 엔진 한 갈래가 실패하면 결과 0건으로 세지 않고 경고를 띄우며, 다른 갈래의 결과는 그대로 남습니다. Jev 제공자는 체인으로 묶여 있어서 앞의 제공자가 실패하면 다음으로 넘어가는데, 넘어가는 조건은 크레딧이 없는 HTTP 402와 요청이 몰린 429, 그리고 5xx뿐입니다. 400이나 401 같은 클라이언트 오류는 재시도하지 않고, 요청이 취소된 뒤에도 재시도하지 않습니다. 공개 데모에는 IP당 분당 10회의 요청 제한(rate limit)이 걸려 있고, Jev Search는 이것이 Cloudflare 위치별로 적용되는 값이라 전역 지출 상한이 아니라는 점을 함께 적어 두었습니다. 출처나 기간 칩을 바꿔 다시 도는 검색도 같은 한도에 들어갑니다.

Jev Search가 다루는 검색 데이터

검색 도구를 고를 때 남는 질문은 입력한 문장이 어디까지 흘러가느냐입니다. Jev Search에서 검색 요청은 두 곳으로 갑니다. 엔진을 호출하는 Search1API, 그리고 요청을 해석하는 Jev 제공자입니다. 채점 단계에서는 결과의 제목과 요약도 Jev 제공자에게 넘어갑니다. Jev Search 자체는 검색 문구와 해석된 검색어, 결과 클릭을 자기 분석 데이터로 기록하지 않고, Cloudflare KV에는 질의에서 파생된 캐시 키와 결과 요약이 앞서 적은 보존 시간만큼 남습니다.

공개 데모에는 Cloudflare Web Analytics 스크립트가 하나 더 들어 있습니다. 쿠키를 쓰지 않고 URL 질의 문자열을 기록하지 않으므로 /search?q= 에 실린 검색어는 그쪽에 남지 않습니다. 다만 Workers 요청 로그는 별도로 켜져 있고, 이 로그의 요청 URL에는 검색어가 들어갈 수 있습니다. 요청 제한은 클라이언트 IP를 기준으로 셉니다. 자체 호스팅에서는 분석 스크립트를 지우고 캐시 바인딩을 떼어낼 수 있으며, 그렇게 하면 결과 캐시도 함께 꺼집니다.

Jev Search 설치와 사용

로컬 실행에는 Node.js 22.12 이상과 pnpm 10.8.0이 필요하고, Search1API 키와 Jev 제공자 자격 증명이 최소 하나 있어야 합니다. 저장소 이름과 Worker 이름은 프로젝트 이름과 달리 jev-search 이므로, 아래 명령에서는 그 이름을 그대로 씁니다:

git clone https://github.com/superagents-lab/jev-search.git
cd jev-search
corepack enable
pnpm install --frozen-lockfile
cp .dev.vars.example .dev.vars
# .dev.vars 에 SEARCH1API_API_KEY 와 Jev 제공자 키를 하나 이상 설정합니다.
pnpm dev

실행하면 http://localhost:3030 에서 열립니다. 테스트는 제공자를 모의로 대체하므로 API 키 없이도 돌릴 수 있고, 빌드 역시 어떤 제공자도 호출하지 않습니다.

Jev를 받아올 수 있는 경로는 세 가지이고, 하나만 있어도 동작하며 나머지는 장애 시 넘어갈 대비책입니다:

다만 세 경로의 조건이 같지는 않습니다. Vercel 무료 등급 팀은 모델별 요청 제한에 걸려 몇 번 만에 429를 받고, 키가 필요 없는 Cloudflare 경로도 AI Gateway 선불 크레딧이 없으면 바인딩이 실패합니다. Vercel은 모델 목록에 Jev의 입출력 토큰을 무료로 올려 두었고, 데이터 미보존(Zero Data Retention)과 프롬프트 데이터 미학습도 함께 표시하고 있습니다. 이 무료 표시가 2026년 9월 25일에 끝나는 프로모션 가격이라는 단서도 같은 자리에 달려 있으므로, 이 경로를 고르기 전에 현재 단가를 확인해야 합니다. 어느 제공자를 어떤 순서로 쓸지는 JEV_PROVIDERS 환경 변수가 정하고, 기본값은 typesafe 하나입니다. 목록에 없는 제공자는 자격 증명이 있어도 켜지지 않고, 목록에 있는데 자격 증명이 없으면 건너뜁니다. 배포는 Cloudflare Workers로 합니다:

pnpm exec wrangler secret put SEARCH1API_API_KEY
pnpm exec wrangler secret put TYPESAFE_API_KEY
pnpm cf-typegen
pnpm test
pnpm run deploy

직접 배포할 때 손봐야 하는 값이 몇 개 있습니다. wrangler.jsonc의 routes에서 jev.s1.dev를 지워 workers.dev 주소를 쓰거나 자기 도메인으로 바꾸고, src/lib/seo.ts와 public/robots.txt와 public/sitemap.xml의 origin을 같은 주소로 맞춥니다. 커밋되어 있는 KV 네임스페이스 ID와 요청 제한 네임스페이스 ID는 공개 데모의 것이므로 자기 계정에서 새로 만들어 교체하고, src/routes/__root.tsx에 들어 있는 Cloudflare Web Analytics 스니펫도 지우거나 자기 토큰으로 바꿉니다. 검색 한 번이 여러 번의 유료 제공자 호출을 일으키므로, 공개된 주소로 띄울 생각이라면 제공자 쪽에 지출 한도를 먼저 걸어 두는 편이 안전합니다.

Jev Search의 라이선스

Jev Search는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

단, TypeSafe와 Jev라는 이름과 브랜드 자산은 각 권리자의 것이고 이 MIT 라이선스에 포함되지 않습니다. 파비콘과 Apple Touch Icon은 typesafe.ai의 아이콘을 그대로 가져온 것이고 public/ 의 설치형 웹 앱(PWA) 아이콘도 Apple Touch Icon의 크기를 줄인 것이므로, 자기 서비스로 배포하려면 이 아이콘들과 src/components/wordmark.tsx, public/manifest.webmanifest, 페이지 메타데이터를 자기 브랜드로 교체해야 합니다.

Jev Search 공개 데모 (개발사가 운영하는 호스팅 인스턴스)

Fast Jev Compaction 소개

코딩 에이전트와 한 세션을 오래 이어 가면 주고받은 대화가 컨텍스트 창을 채웁니다. 이때 대부분의 도구는 오래된 대화를 언어 모델에 넘겨 요약문으로 바꿔 놓는데, 요약은 본질적으로 정보가 줄어드는 처리입니다. 나중에 다시 필요해지는 파일 경로, 정확한 오류 문구, 사용자가 걸어 둔 제약, 실행했던 명령어가 요약 과정에서 빠질 수 있습니다. 한 번 빠지고 나면 그런 내용이 원래 대화에 있었다는 사실조차 남지 않아서, 에이전트가 같은 파일을 다시 읽거나 이미 손대지 말라고 했던 경로를 건드리는 일이 생깁니다. 이번에 소개하는 fast-jev-compaction은 그 요약 단계를 생략하고, 오래된 도구 호출 가운데 더 이상 필요 없는 것만 골라 지우는 Claude Code 플러그인입니다.

fast-jev-compaction은 대화 내용을 다시 쓰지 않고 삭제만 합니다. 무엇을 지울지는 TypeSafe AI의 Jev ( Jev, 토큰 대신 확률적 결정을 내놓는 새로운 형태의 System One 모델 (feat. TypeSafe AI))에 맡기는데, Jev는 문장을 생성하는 대신 질문마다 확률을 돌려주는 System One 모델입니다. 플러그인은 도구 호출 하나마다 두 가지를 묻습니다. 이 호출이 기록에 남아야 하는지, 그리고 그 결과가 원문 그대로 남아야 하는지입니다. 질문을 던질 때는 대화 전체를 함께 보여주기 때문에, 오래된 호출 하나를 지울지 판단하는 근거에 그 뒤에 일어난 일까지 모두 들어갑니다. 사용자와 어시스턴트가 주고받은 텍스트는 이 과정에서 손대지 않고 원문 그대로, 순서 그대로 남습니다.

fast-jev-compaction의 저장소는 두 가지를 겸합니다. src/는 TypeScript로 작성한 npm 라이브러리이고, hooks/와 .claude-plugin/은 그 라이브러리를 호출해 Claude Code의 기본 압축 요약을 대체하는 플러그인입니다. 공개한 사람은 TypeSafe AI가 아니라 개인 개발자 tamara tran이며, 같은 저자가 Bash 출력이 모델에 닿기 전에 Jev로 줄이는 jev-pruner도 함께 내놓았습니다.

fast-jev-compaction과 Claude Code 기본 압축 요약의 차이

Claude Code의 기본 압축은 압축이 끝난 시점에 대화 요약문을 만들어 두고, 훅에 compact_summary 필드로 그 요약문을 넘깁니다(Claude Code 훅 레퍼런스). fast-jev-compaction은 같은 자리에서 요약문 대신 원래 메시지를 돌려주며, 두 방식이 다른 점은 다음과 같습니다:

표의 마지막 행이 이 플러그인의 안전장치입니다. Jev 요청이 실패하거나, 응답 형식이 깨지거나, 키를 찾지 못하거나, 대화 기록이 상태 예산에 들어가지 않거나, 줄어든 양이 minReductionRatio 기본값인 25%에 못 미치면 훅은 폴백을 기록하고 Claude Code의 기본 압축에 처리를 넘깁니다. 결과는 세션에 토스트로 뜨는데, 원래 기록이 기본 요약을 대신했을 때는 fast-jev-compaction: kept N/M messages, no summary (…)가, 되돌아갔을 때는 fallback to built-in summary (…)가 표시됩니다.

fast-jev-compaction을 사용하면 좋을 사용자

도구 호출이 많고 그 결과가 긴 세션을 오래 이어 가는 사람에게 fast-jev-compaction이 맞습니다. 큰 저장소를 훑거나 테스트와 빌드 로그를 반복해서 읽는 작업은 대화의 대부분이 도구 결과이고, 그중 상당수는 몇 턴만 지나면 다시 쓰이지 않습니다. 이런 세션에서는 지울 대상이 분명하고, 지우고 남은 부분이 요약문이 아니라 원문이라는 점이 곧 이득이 됩니다.

반대로 대화가 주로 텍스트로 이루어져 지울 도구 호출이 적은 세션에서는 fast-jev-compaction을 켜 둘 이유가 크지 않습니다. 텍스트 메시지는 애초에 삭제 후보가 아니어서, 줄어드는 양이 minReductionRatio에 못 미치면 결국 기본 요약으로 되돌아갑니다.

대화 전체가 외부로 전송되는 것이 문제가 되는 환경이라면 fast-jev-compaction은 선택지가 아닙니다. 압축할 때마다 도구 결과를 한 줄 메모로 바꾼 대화 전문이 TypeSafe의 System One 엔드포인트로 실려 나가고, 도구 입력과 사용자 프롬프트는 내용이 그대로 포함됩니다. TypeSafe API 키를 발급받을 수 없는 경우에도 마찬가지로 쓸 수 없습니다.

fast-jev-compaction의 동작 원리

첫 단계는 짝짓기와 고정입니다. fast-jev-compaction은 모든 tool_use 블록을 tool_use_id로 해당 tool_result와 짝지어 하나의 호출 단위로 묶고, 결과가 아직 없는 호출은 후보에서 뺍니다. 여기에 더해 첫 번째 메시지와 가장 최근 preserveRecentMessages개(기본값 6) 메시지에 속한 호출은 고정되어 어떤 경우에도 건드리지 않습니다. preserveRecentMessages를 0으로 낮추더라도 첫 번째 메시지는 언제나 남습니다.

두 번째 단계에서 Jev에 보낼 상태를 만듭니다. 상태는 지금까지의 대화 전체를 오래된 것부터 담되, 모든 도구 결과를 ok, 4213 chars (omitted) 같은 짧은 메모로 바꾼 형태입니다. 도구 입력과 텍스트는 그대로 들어가고 요약되는 것은 없습니다. 함께 보내는 goal 필드에는 진행 중인 작업 설명이 들어가며, 값을 주지 않으면 최근 사용자 프롬프트 세 개가 쓰입니다.

세 번째 단계가 질문입니다. 고정되지 않은 호출마다 Noul 질문 두 개가 만들어집니다. Noul은 Jev가 제공하는 세 가지 질문 유형 중 하나로, 진술 하나가 참인지를 0에서 1 사이 값으로 돌려줍니다. 첫 번째 질문은 그 호출이 이루어졌다는 사실과 입력값이 앞으로의 작업에 여전히 중요한지를 묻고, 두 번째 질문은 그 결과의 내용이 여전히 필요하며 도구를 다시 실행하는 것으로는 대신할 수 없는지를 묻습니다. 질문은 상태와 합쳐 maxRequestTokens(기본값 30000) 안에 들어가도록 여러 요청으로 쪼개지고, 같은 상태가 매 요청에 함께 실려 나가며, 요청들은 동시에 실행된 뒤 답이 합쳐집니다.

마지막 단계에서 두 확률을 keepThreshold(기본값 0.5)와 견주어 호출마다 처리 방향을 정합니다:

잘라낸 결과 자리에는 [fast-jev-compaction truncated N chars of this tool result; re-run the tool if needed]라는 안내가 붙어, 몇 글자가 잘렸는지와 필요하면 도구를 다시 실행하라는 지시가 함께 남습니다. 결정을 반영해 대화를 다시 조립할 때는 내용이 전부 없어진 메시지를 통째로 제거하고, 손대지 않은 메시지는 원래 객체를 그대로 돌려주며, 호출이 사라진 자리에 결과만 남는 상태는 만들지 않습니다.

fast-jev-compaction이 대화 상태를 줄이는 단계

Jev에 보내는 상태에는 maxStateTokens(기본값 25000)라는 상한이 있습니다. 대화가 이 상한을 넘으면 fast-jev-compaction은 다음 단계를 순서대로 적용하며, 각 단계는 직전 단계로도 부족했을 때만 실행됩니다:

1. 도구 입력을 200자로, 그래도 부족하면 60자로 더 자릅니다. 기본 상태에서 입력은 이미 1000자로 잘려 있습니다.
2. 긴 텍스트를 앞 400자와 뒤 150자만 남기고 줄입니다. 고정되지 않은 오래된 메시지부터 처리합니다.
3. 오래된 비고정 메시지를 [… N chars omitted …] 메모 한 줄로 접습니다.
4. 오래된 도구 호출을 t12 Read file_path=src/a.ts → ok 480ch 형태의 한 줄로 바꿉니다.
5. 호출이 없는 오래된 메시지를 상태에서 제외합니다.
6. 호출만 있는 오래된 메시지가 연달아 있으면 하나로 합칩니다.

여섯 단계를 다 거치고도 상한에 들어가지 않으면 압축은 예외를 던지고, 그 뒤 처리는 호출자가 결정합니다. 플러그인으로 쓸 때는 이 예외도 기본 요약으로 되돌아가는 경로로 이어집니다.

fast-jev-compaction은 토큰을 셀 때 토크나이저를 쓰지 않고 문자 구성으로 추정하는데, 알파벳 낱말은 6자당 1토큰, 숫자는 한 글자당 0.5토큰, 나머지 기호는 하나당 0.9토큰으로 계산합니다. 저자는 실제 Jev가 보고한 사용량보다 2%에서 18% 높게 나오도록 이 계수를 맞췄다고 src/state.ts의 주석에 적어 두었습니다. 단순히 글자 수를 일정 비율로 나누는 방식은 JSON이 많은 상태에서 실제보다 최대 40% 적게 세기 때문에, 일부러 넉넉하게 잡는 쪽을 골랐다는 설명입니다.

fast-jev-compaction이 밝힌 한계

저자는 한계를 네 가지로 정리해 두었습니다. 첫째, 후보가 되는 것은 도구 호출과 결과뿐이고 텍스트 메시지는 출력에서 제거되거나 짧아지지 않습니다. 텍스트가 줄어드는 것은 Jev가 보는 상태 안에서일 뿐입니다. 둘째, 토큰 크기는 토크나이저가 아니라 문자 수에서 나온 추정치입니다. 셋째, 보정은 요청 단위로 이루어지므로 확률값 하나가 그 결과를 지워도 안전하다는 증명은 되지 못하며, 대신 어시스턴트가 언제든 도구를 다시 실행할 수 있다는 점이 안전장치가 됩니다. 넷째, 전체 상태가 매 요청에 반복되기 때문에 상태 상한에 가까운 대화 기록은 질문 몇 개마다 요청 하나씩을 쓰게 됩니다.

여기에 저장소 밖에서 확인되는 한계가 하나 더 있습니다. 이 플러그인이 활용하는 함수 훅(function hook)은 Claude Code 2.1.274 이상에서 쓸 수 있는 얼리 액세스 기능이고, 공개된 훅 레퍼런스와 플러그인 레퍼런스에는 아직 함수 훅도, 이 플러그인이 쓰는 session.compact와 turn.complete 이벤트도 실려 있지 않습니다. 공개 문서에 적힌 hooks/hooks.json도 이벤트 매처와 동작을 담은 JSON 설정인데, 이 저장소의 같은 파일은 {"modules": ["./fast-jev.ts"]} 한 줄로 TypeScript 모듈을 가리킵니다. 저자도 함수 훅이 릴리스 사이에 바뀔 수 있다고 적으면서, types/claude-code.d.ts의 타입 선언을 Claude Code 업그레이드 후에 다시 생성해 검토하라고 안내합니다.

fast-jev-compaction 설치와 사용

함수 훅은 기본적으로 꺼져 있으므로, Claude Code가 실행되는 곳의 설정에 옵트인 플래그를 먼저 넣어야 합니다. ~/.claude/settings.json에 넣는다면 다음과 같습니다:

{ "env": { "CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1", "TYPESAFE_API_KEY": "<your key>" } }

그 다음 저장소를 플러그인 마켓플레이스로 추가하고 플러그인을 설치합니다. 셸에서 실행해도 되고 세션 안에서 슬래시 명령으로 실행해도 됩니다:

claude plugin marketplace add tamaratran/fast-jev-compaction
claude plugin install fast-jev-compaction@fast-jev-compaction

설치 과정에서 API 키와 임계값 같은 플러그인 옵션을 묻는데, 기본값으로 두면 환경 변수의 TYPESAFE_API_KEY를 씁니다. 설치 후 Claude Code를 다시 시작하거나 /reload-plugins를 실행하면 그때부터 /compact와 자동 압축이 Jev를 거칩니다. 훅은 줄어든 비율과 사유별 개수, 상태 크기, 요청 수를 로그에 남기고 호출마다 두 확률을 담은 decisions: 줄도 함께 기록하므로, keepThreshold를 조정할 때 그 값을 근거로 삼을 수 있습니다. 저장소를 내려받아 바로 시험해 보려면 저장소 루트에서 CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude --plugin-dir .을 실행하면 되고, 마켓플레이스가 저장소의 .claude-plugin/marketplace.json 자체라 따로 배포하는 단계는 없습니다. TypeSafe 키 없이 동작만 먼저 보고 싶다면 demo/JevDemo를 demo/JevDemo/build.sh로 빌드해 실행할 수 있는데, 이 macOS 앱은 미리 준비한 대화 기록을 각색해 보여줄 뿐 실제로 API를 호출하지는 않습니다.

플러그인이 받는 설정값은 .claude-plugin/plugin.json에 선언되어 있습니다:

이 가운데 compactAtPercent는 플러그인에만 있는 값입니다. turn.complete 훅이 매 턴 끝에서 컨텍스트 사용률을 보고 이 비율에 닿으면 압축을 스스로 요청하므로, 컨텍스트가 가득 차기를 기다리지 않고 60% 지점에서 미리 정리하는 동작이 기본값이 됩니다.

라이브러리로 쓸 때는 compactMessages 하나로 시작할 수 있습니다. 저장소가 제시하는 최소 예시는 다음과 같습니다:

import { compactMessages, reductionRatio, type Message } from 'fast-jev-compaction';

Stonkfly 소개

자동 매매 도구는 판단을 만드는 자리가 대체로 정해져 있습니다. 가격과 거래량을 숫자로 받아 사람이 설계한 지표와 규칙으로 방향을 정하거나, 최근에는 그 숫자와 뉴스를 대규모 언어 모델(LLM)에 넘겨 매수와 매도를 고르게 합니다. 어느 쪽이든 판단의 출처는 사람이 쓴 규칙이거나 대규모 텍스트로 학습한 모델이고, 방금 낸 주문의 이유를 되짚으면 결국 사람이 적어 둔 조건이나 모델의 출력으로 돌아갑니다. 이번에 소개하는 Stonkfly는 그 자리에 전혀 다른 것을 끼워 넣어 본 실험으로, 초파리의 뇌 배선을 그대로 옮긴 스파이킹 신경망(Spiking Neural Network)이 매수와 매도, 관망 중 하나를 제안하고 그 제안이 실제 거래소 주문까지 이어지는 프로젝트입니다.

Stonkfly는 Coinbase Advanced의 공개 시세로 320x180 크기의 가격 차트를 로컬에서 직접 그린 뒤, 그 차트의 RGB 픽셀만 신경망에 넣습니다. 가격 숫자도, 이동평균 같은 지표도, 잔고와 손익도 들어가지 않습니다. 픽셀은 MaleCNS v1.0 커넥톰(Connectome)에서 가져온 166,700개 뉴런과 25,582,938개 연결 중 시각 수용체 자리를 자극하고, 스파이크는 그 그래프를 타고 퍼집니다. 마지막에 고정된 판독기가 좌우 DNp20 뉴런의 발화율 차이를 읽어 매수와 매도, 관망 중 하나를 고르며, 별도의 주문 가드가 한도와 시세 신선도를 검사한 뒤 Coinbase AgentKit ( Coinbase, AI 에이전트를 위한 블록체인 통합 프레임워크 AgentKit 공개 (Python & TypeScript))의 ActionProvider 인터페이스를 통해 현물 주문을 냅니다. AgentKit이 기본으로 제공하는 온체인 지갑 스왑은 쓰지 않고, 주문은 Coinbase Advanced 거래소 API로만 나갑니다. 저장소는 자금이 들어 있거나 누군가의 계정에 연결된 상태로 배포되지 않으며, 실거래에는 사용자가 직접 준비한 자격 증명과 명시적인 동의가 필요합니다.

Stonkfly는 Python 3.11과 C++17 컴파일러를 요구하는 파이썬 프로젝트로, 그래프 적분은 직접 작성한 네이티브 커널이 담당합니다. 개발자 nftechie가 같은 커넥톰으로 Doom을 플레이하게 만든 DOOMFLY에서 커넥톰 임포터와 스파이킹 커널, 가소성 구현을 가져왔고, 거래 환경과 주문 가드, AgentKit 연결을 새로 얹었습니다. Stonkfly는 수익이 나는 학습이 입증되지 않았다는 사실을 README 첫 문단에서 스스로 명시하고 있으며, 시냅스(Synapse) 효능이 변한다는 것이 곧 매매를 학습했다는 뜻은 아니라고 docs/model.md에서 반복해 적고 있습니다.

본 게시물은 초파리 커넥톰 시뮬레이션을 거래 환경에 연결한 실험 프로젝트의 구조와 안전장치를 소개하는 글로, PyTorchKR은 이번 글을 통해 인공지능 기술이 금융 분야에서 어떻게 활용될 수 있는지 가능성과 그 방법에 대한 소개를 하는 것을 목적으로 합니다. 즉, 어떠한 경우에도 PyTorchKR 및 이 게시물은 투자를 권유, 제안, 또는 추천하려는 목적으로 작성한 것이 아님을 알려드리며, 투자에 대한 조언을 구성하지 않습니다.

Stonkfly와 DOOMFLY 비교

Stonkfly의 위치를 가장 정확히 보여주는 비교 대상은 같은 개발자가 먼저 공개한 DOOMFLY입니다. 두 프로젝트는 같은 MaleCNS v1.0 그래프를 쓰고, 뉴런 수와 연결 수가 같으며, 감각 입력의 규모도 3,335개의 R1부터 R6까지의 밝기 입력과 811개의 R8 색 입력으로 동일합니다. 바뀐 것은 뇌가 무엇을 보고 무엇을 움직이는가, 그리고 무엇을 되먹임으로 받는가입니다:

가소성 대상이 4,184개에서 7,835개로 늘어난 것은 보상 구획이 하나 추가됐기 때문입니다. DOOMFLY는 피해라는 부정적 신호만 다루면 됐지만, 거래에는 이익과 손실이 모두 있어 Stonkfly는 보상 쪽 구획인 PAM11에서 MBON07로 가는 경로를 함께 씁니다. 프로젝트는 같은 규칙을 두 구획에 적용한 것이 검증되지 않은 자체 확장이라고 docs/model.md에 명시하고 있습니다.

LLM 기반 트레이딩 에이전트와의 차이는 더 단순합니다. TradingAgents나 Vibe-Trading처럼 언어 모델이 시장 정보를 읽고 판단을 내리는 구조와 달리, Stonkfly에서는 어떤 언어 모델도 거래를 고르지 않습니다. 매수와 매도를 정하는 것은 발화 수만 읽는 고정된 판독기 하나이고, 주문 가드는 제안을 거부할 수만 있을 뿐 다른 거래로 바꿔 놓을 수 없습니다.

Stonkfly를 사용하면 좋을 사용자

커넥톰 데이터로 대규모 스파이킹 신경망을 돌려 보고 싶거나, 신경 활동을 실제 외부 환경에 연결했을 때 무엇이 문제가 되는지 보고 싶은 연구자와 개발자에게 Stonkfly가 잘 맞습니다. Stonkfly가 모델 가정과 검증하지 못한 항목을 문서로 함께 공개해 두어서, 커넥톰 기반 시뮬레이션이 어디까지를 주장할 수 있고 어디부터가 공학적 선택인지를 구분해 읽는 연습 자료로도 쓸 수 있습니다. 감각 입력에서 가소성 규칙까지 각 단계가 별도 모듈로 분리돼 있어 한 부분만 바꿔 실험하기도 쉽습니다.

반대로 수익을 내는 자동 매매를 찾고 있는 분에게는 Stonkfly가 적절한 선택지가 아닙니다. Stonkfly가 공개한 검증 결과에는 수익이 난 전략도, 학습이 일어났다는 증거도 없습니다. 준비 단계에서 약 1.1GB의 커넥톰 데이터를 내려받고 여기에 의존성과 파생 데이터까지 더해 수 GB의 디스크와 16GB 정도의 메모리를 쓰는데, 그 비용으로 얻는 것은 거래 성과가 아니라 실행 가능한 실험 루프입니다. 지원 환경도 macOS와 Linux뿐이라 Windows 사용자는 별도 준비가 필요합니다.

Stonkfly의 동작 원리

관측 한 번은 차트를 그리는 데서 시작합니다. Stonkfly는 Coinbase의 공개 1분봉 종가로 가격 이력을 채우고 이후 관측의 중간값을 덧붙여 320x180 차트를 로컬에서 렌더링합니다. 이 차트에는 과거 가격을 꺾은선으로 이어 상승 구간과 하락 구간을 다른 색으로 칠하고, 위쪽 띠에 거래쌍 이름을, 아래쪽에 현재 호가를 적습니다. 잔고와 손익은 들어가지 않습니다. 로그인한 거래소 화면을 캡처한 것이 아니라는 뜻이기도 합니다. 초기 버전은 어두운 배경의 차트를 썼는데 KC 뉴런이 거의 반응하지 않아 밝은 배경으로 바꿨고, 프로젝트는 이때 신경 파라미터는 건드리지 않았으며 표시 방식에 대한 민감도가 검증이 필요한 큰 교란 요인으로 남아 있다고 적고 있습니다.

픽셀은 두 갈래로 들어갑니다. 3,335개의 R1부터 R6까지의 수용체가 선형 sRGB 휘도를 받고, 811개의 R8 수용체가 파랑과 초록 채널을 대리 신호로 받습니다. 수용체의 위치는 열(column) 주석이 붙은 시각 뉴런과의 접촉에서 역으로 추정한 것이며, 대응되는 수용체가 없는 자리에는 없는 입력을 지어내지 않습니다. 실제 초파리의 광수용체는 등급 전위(graded potential)로 반응하지만 Stonkfly는 스파이크를 쓰므로, 프로젝트는 이 부분을 검증된 망막 생리가 아니라 명시적인 표시 장치 어댑터라고 부릅니다.

Stonkfly가 자기 그래프를 두고 쓰는 전체 보존(full retained)이라는 말은 무엇을 남겼는가에 대한 표현입니다. 배정된 뉴런 상위분류를 불확실한 것까지 모두 남기고 명시적인 신경아교세포와 미해결 분할 객체만 제외했다는 뜻이지, 실제 초파리의 모든 시냅스가 재구성됐다는 뜻은 아니라고 프로젝트가 따로 적어 두었습니다. 약한 연결과 자기 연결도 그대로 둡니다.

네이티브 커널은 0.1ms 간격으로 누설 적분 발화(Leaky Integrate-and-Fire) 뉴런을 근사 적분합니다. 막전위 시정수 20ms, 시냅스 시정수 5ms, 발화 임계값 -45mV, 전달 지연 1.8ms, 불응기 2.2ms가 쓰이고, 아세틸콜린은 흥분성으로, GABA와 글루탐산과 히스타민은 억제성으로 배정됩니다. 시장 관측 한 번은 기본값으로 500ms의 신경 시간을 진행시키며, 실제 관측 간격은 최소 60초입니다. 프로젝트는 이 시간 압축이 실시간 초파리 생리가 아니라 의도적으로 압축한 시장 대 신경 시계라고 밝히고 있습니다.

주문 방향은 다음과 같이 결정됩니다:

이 대응은 사람이 정한 인터페이스이지 매수 뉴런을 찾아낸 결과가 아닙니다. 프로젝트도 회전 방향으로 치우친 네트워크 편향이 그대로 한쪽 방향의 매수로 나타날 수 있다고 경고합니다. 판독기가 정하는 것은 방향뿐이고 어떤 자산을 볼지는 네트워크가 고르지 않습니다. 기본값은 BTC-USDC 하나이며 ETH-USDC와 SOL-USDC를 선택지로 더할 수 있는데, 여러 개를 켜면 정해진 순서대로 돌아가며 한 번에 하나씩 보여줍니다.

Stonkfly의 되먹임과 기억 규칙

거래가 체결되면 다음 관측에서 평가액이 다시 계산됩니다. 평가액은 현금에 보유 자산을 현재 매수 호가로 평가한 값을 더한 것이고, 직전 관측 대비 변화에는 체결 수수료와 미실현 손익이 모두 들어갑니다. 변화가 미국 달러에 연동된 스테이블코인인 USDC 기준으로 +0.01 이상이면 15개의 PAM11 도파민 세포에 200ms 길이의 20mV 상당 인공 전류가 들어가고, -0.01 이하면 같은 펄스가 2개의 PPL101 세포로 들어갑니다. 펄스의 크기는 이익 규모에 비례하지 않고 임계값을 넘었는지만 봅니다. 아래 그림은 관측 한 번마다 도는 이 순환을 정리한 것으로, 손익 계산에서 시작해 도파민 세포 자극과 시냅스 효능 갱신을 거쳐 다음 관측으로 돌아옵니다.

도파민 활동은 초파리의 기억 구획에 해당하는 KC에서 MBON07과 MBON11로 가는 기존 연결 7,835개의 효능을 바꿉니다. 규칙은 Huang, Luo et al., 2024의 기준선 중심 반헵 규칙을 가져온 것으로, KC 활동 뒤에 도파민이 따라오면 해당 연결이 약해지고 순서가 반대면 강해지는 쪽입니다. 가격이나 손익 값이 시냅스 가중치를 직접 고쳐 쓰는 경로는 없고, 실제 네트워크 스파이크에서 나온 발화율만 규칙에 들어갑니다. 1초짜리 적격 흔적, 1,800초 기억 감쇠, 50ms 효능 필터, 0.001 게인, 기준값 대비 0.1배에서 2배의 효능 상한은 모두 선언된 모델 선택이며 측정된 도파민 농도가 아닙니다. 파라미터와 구현은 stonkfly/neural/rule.py에 모여 있습니다.

평가액 변화는 포트폴리오 가치에 대한 피드백일 뿐, 직전 행동이 그 변화를 일으켰다는 증거가 아닙니다. 자산을 그냥 들고 있어도 양쪽 신호가 다 나올 수 있고 수수료는 손실로 계산되며, 외부 입금처럼 설명되지 않는 잔고 변화는 보상이 되는 대신 실행을 멈춥니다. 프로젝트는 통증 수용체나 주관적 고통, 쾌감, 의식은 모델링하지도 측정하지도 않는다고 명시합니다.

Stonkfly의 주문 한도와 정지 조건

Stonkfly는 실거래에서 사고를 막는 검사를 stonkfly/risk.py의 가드와 stonkfly/config.py의 설정값에 모아 두었습니다. 설정 클래스는 값 범위를 직접 검사해서, 한도를 넘는 값을 넣으면 실행 자체가 거부됩니다. 운영 절차 전반은 docs/operations.md에 정리돼 있습니다. 주요 한도는 다음과 같습니다:

• 초기 자금과 주문 규모: 초기 자금은 최대 100 USDC, 매수 한 건은 2% 수수료 예비분을 포함해 최대 10 USDC입니다. 매도 수량은 보유량과 10 USDC 상당 중 작은 쪽으로 제한되고, 차입과 공매도, 레버리지, 출금 동작은 아예 노출되지 않습니다.

• 빈도: UTC 하루 최대 24회 시도, 시도 사이 최소 60초입니다. 거부된 미리보기도 시도 횟수에 포함되고, 실패한 주문이 새로운 전략 선택으로 바뀌지 않습니다.

• 가격과 시세: 가격 제한이 걸린 FOK(Fill-or-Kill) 주문을 쓰며 슬리피지는 최대 0.5%, 호가 스프레드도 0.5%까지만 허용합니다. 시세는 15초보다 오래되면 안 되고, 신경 적분이 끝난 뒤 호가를 다시 받아 관측 시점과 차이가 크면 거래를 취소합니다.

• 손실 정지: 시작 평가액 대비 20 USDC가 줄면 새 주문을 멈춥니다. 다만 이것은 청산 명령이 아니며 보유 자산은 그대로 시장에 노출된 채로 남습니다. 프로젝트도 이 조건이 최대 손실을 보장하지 않는다고 적어 두었으니, 보유 자산을 어떻게 정리할지는 별도로 정해 두어야 합니다.

주문 식별자는 전송 전에 SQLite에 기록됩니다. 응답이 불확실하면 같은 식별자를 거래소에서 되찾아 조회하고 새 주문을 다시 보내지 않으며, 결과가 끝내 불분명하면 워커를 멈춰 사람이 확인하도록 합니다. 기본값은 모의 거래라서 키가 없어도 실제 공개 시세로 돌려볼 수 있고, 실거래는 View와 Trade 권한만 가진 포트폴리오 범위의 ECDSA 키와 환경 변수, 그리고 --live 플래그가 모두 갖춰져야 시작됩니다.

Stonkfly의 검증 결과와 한계

개발자 nftechie가 구현 시점에 기록해 docs/validation.md로 공개한 결과를 보면, 전체 커넥톰 테스트를 포함해 로컬 테스트 42개가 통과했습니다. 거래소 주문 테스트는 전부 인메모리 SDK 대역을 쓴 것이고 실제 주문이나 자금이 들어간 계정 검사는 수행되지 않았습니다. 확인된 것과 확인되지 않은 것은 항목마다 다음과 같이 나뉩니다:

마지막 행이 Stonkfly가 스스로 가장 중요한 한계로 꼽는 대목입니다. 6회 관측에서 첫 체결 이후 나온 제안이 모두 매수였고, 고정된 방향 판독기가 회로의 편향을 그대로 한쪽 노출로 바꿔 놓을 수 있다는 뜻이기 때문입니다. 같은 실행에서 KC는 관측당 11회에서 16회 발화했는데, 이는 흰 화면을 넣은 신경 테스트에서 활성화되는 KC보다 훨씬 적은 수라서 프로젝트는 시각 표현을 어떻게 만들 것인가가 아직 큰 숙제로 남아 있다고 적고 있습니다. 손실 펄스가 들어간 다음 관측에서는 2개의 PPL101 세포에서 55회의 스파이크가 관측됐습니다. 여기서 변한 후보 연결 5개는 외부 손실 펄스가 들어오기 전에 이미 바뀌어 있었고, 프로젝트는 이를 근거로 모든 가중치 변화를 손익 탓으로 돌리지 말라고 적고 있습니다.

Stonkfly는 학습을 주장하려면 무엇이 더 필요한지도 함께 적어 두었습니다. 시간 순서를 지킨 별도 구간의 시장 재현, 독립적인 시작점, 가중치를 고정한 대조군과 강화 신호를 섞은 대조군, 수수료와 슬리피지 반영, 동일한 예산, 기억 유지 확인, 학습된 가중치를 초기화했을 때 이득이 사라지는지 확인이 모두 필요합니다. 현금과 단순 보유 전략도 함께 비교해야 하는데, 가격이 오르는 구간에서는 누가 사도 잘한 것처럼 보이기 때문입니다.

Stonkfly 설치와 사용

Stonkfly 실행에는 Python 3.11과 C++17 컴파일러가 필요하며 macOS와 Linux를 지원합니다. 데이터셋과 의존성으로 수 GB의 공간이 필요하고 16GB 메모리를 권장합니다. 기본 실행은 모의 거래이므로 API 키 없이도 시작할 수 있습니다:

python3.11 -m venv .venv
source .venv/bin/activate
pip install -e '.[test]'
python -m stonkfly prepare
python -m stonkfly run

prepare 단계에서 약 1.1GB의 MaleCNS 파일을 내려받아 체크섬을 확인하고 전체 그래프를 만듭니다. 기본 실행은 실제 공개 BTC-USDC 시세를 쓰면서 체결만 100 USDC의 모의 잔고로 흉내 내며, 한쪽당 0.6%의 수수료를 적용합니다. 로그와 감각 이미지, 재개 가능한 신경 상태는 runs/paper/에 남고, Ctrl-C로 멈춘 뒤 같은 명령으로 이어서 실행할 수 있습니다.

실험으로 돌릴 때 쓰는 모드도 따로 있습니다. --fixture는 합성 시세로 오프라인 실행을 하고, --frozen은 기억 효능을 고정한 대조군을 돌립니다. 대조군은 항상 별도의 실행 디렉토리를 써야 합니다:

python -m stonkfly run --fixture --fast --frozen --steps 10 --out runs/frozen

실거래는 별도의 선택이 필요합니다. 최대 100 USDC만 넣은 전용 Coinbase Advanced 포트폴리오를 만들고, 그 포트폴리오로 범위를 제한한 ECDSA 키를 View와 Trade 권한만으로 발급한 뒤 출금 권한은 꺼 둡니다. .env.example을 .env로 복사해 키 경로와 포트폴리오 ID를 채우고 나면 다음 두 명령을 직접 실행하게 되어 있습니다:

python -m stonkfly run --live --preflight-only
python -m stonkfly run --live

앞 명령은 권한과 잔고, 주문 상태를 읽고 원장을 초기화할 뿐 주문을 넣지 않습니다. 상태 확인과 테스트 실행은 다음과 같습니다:

python -m stonkfly status
python -m pytest -q

Stonkfly의 라이선스

Stonkfly는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

다만 함께 쓰는 구성 요소는 조건이 다릅니다. MaleCNS v1.0 데이터는 크리에이티브 커먼즈 저작자표시 4.0 조건으로 별도 배포되므로, 결과를 공개할 때는 데이터셋과 관련 논문을 인용해야 합니다. Coinbase AgentKit과 Coinbase Advanced Python SDK는 Apache-2.0으로 각 패키지의 라이선스를 그대로 따릅니다. 자세한 귀속 정보는 THIRD_PARTY.md에 정리돼 있으며, 프로젝트는 여기서 Stonkfly가 Coinbase의 공식 제품도, 보증을 받은 것도 아니라는 점을 함께 밝히고 있습니다.

Stonkfly 프로젝트 GitHub 저장소

OpenArm 소개

로봇 팔로 조작 데이터를 모으는 연구는 팔을 손에 넣었다고 시작되지 않습니다. 사람이 어떤 장치로 팔을 조종해 시연을 만들지, 그 기록을 관절 각도와 영상까지 어떤 형식으로 남길지, 학습시킨 정책이 실제로 동작하는지를 어디에서 확인할지가 연구실마다 다르기 때문입니다. 조명과 카메라 위치가 다른 책상에서 모은 시연으로 학습한 정책은 다른 팀이 같은 조건에서 다시 돌려볼 수 없고, 논문의 성공률은 비교할 대상을 잃습니다. 이번에 소개하는 OpenArm은 그 간극을 메우려고 팔의 CAD 도면부터 데이터 기록 형식과 정책 평가 서비스까지를 한 조직이 묶어서 공개한 7자유도 양팔 로봇 프로젝트입니다.

OpenArm이 내세우는 차별점은 팔의 사양보다 공개 범위에 있습니다. 로봇 팔의 설계도를 공개한 프로젝트는 이미 여럿 있지만, OpenArm은 그 위에 조명과 카메라 배치를 통일한 실험 부스인 OpenArm Cell, 에피소드 기록 형식을 정의한 데이터셋 라이브러리, 그리고 학습한 정책을 제출하면 실제 장비나 시뮬레이션에서 실행해 순위를 매기는 평가 서비스까지 더했습니다. 공식 홈페이지가 프로젝트를 한 줄로 요약한 문구도 "Making SOTA reproducible." 로, 팔 자체보다 재현 가능성을 앞세우고 있습니다.

OpenArm을 만든 곳은 도쿄에 자리 잡은 로보틱스 기업 Enactic입니다. Enactic은 2025년 7월에 설립돼 일손이 부족한 일본의 돌봄 시설에 투입할 휴머노이드 로봇 Ena를 개발하고 있고, OpenArm은 그 자율 동작 스택의 바탕이 되는 연구를 오픈소스로 떼어 놓은 결과물입니다. 상용 제품인 Ena는 공개되지 않지만 OpenArm 쪽 저장소는 누구나 받아서 쓸 수 있고, 현재 enactic 조직에 51개 저장소가 올라와 있습니다.

OpenArm과 기존 저비용 로봇 팔의 차이

조작 데이터 수집에 쓰이는 오픈소스 팔 중 가장 널리 퍼진 것은 Hugging Face의 LeRobot 생태계에서 쓰는 SO-101입니다. 두 프로젝트는 같은 문제를 다루지만 겨냥하는 쓰임새가 다르고, 그 차이는 대부분 가격에서 갈립니다:

완제품 가격과 부품 합계라는 서로 다른 기준이긴 하지만 두 값은 자릿수가 다르고, 그 차이를 만드는 것이 토크 제어가 가능한 구동기와 그 위에 얹힌 양방향 힘 피드백입니다. 서보 기반 팔은 위치 명령을 따라가는 데는 충분하지만 조작자가 접촉하는 힘을 되돌려 받지 못하므로, 물건을 쥐거나 표면을 훑는 접촉이 많은 작업에서는 시연 중에 과도한 힘이 들어가기 쉽습니다. OpenArm은 그 구간을 겨냥한 장비이고, 반대로 자유 공간에서 물건을 집어 옮기는 시연을 값싸게 많이 모으는 목적이라면 이 비용 차이를 정당화하기 어렵습니다.

가격 표기는 자료마다 기준이 다르다는 점도 알아 둘 만합니다. README는 완전한 양팔 시스템을 6,500달러로 적고 공식 홈페이지는 같은 금액을 부품 비용(Bill of Materials Cost)으로 표시하므로, 실제 지출을 가늠할 때는 제조사별 판매가가 정리된 구매 문서를 기준으로 삼는 편이 낫습니다. 참고로 OpenArm Cell은 6,200달러부터, OpenArm KER은 2,599달러부터로 팔과 따로 값이 매겨져 있습니다.

두 프로젝트를 고를 때 갈아타는 비용이 걱정된다면, 소프트웨어 쪽은 생각보다 가깝습니다. OpenArm의 공식 학습 튜토리얼이 수집한 데이터를 LeRobot 데이터셋 형식으로 변환한 뒤 LeRobot 정책을 학습시키는 경로를 정본으로 삼고 있어서, 학습 코드와 도구 사슬은 SO-101 쪽과 그대로 겹칩니다. 인증 제조사인 WowRobo가 SO-101 키트도 함께 판매한다는 점까지 더하면, 두 프로젝트는 경쟁 관계라기보다 같은 생태계 안에서 다른 가격대를 맡고 있습니다.

OpenArm을 사용하면 좋을 사용자

접촉이 많은 조작 작업의 시연 데이터를 직접 모아야 하고, 조작자가 힘을 느끼면서 시연해야 품질이 확보되는 연구팀에게 OpenArm이 잘 맞습니다. 팔에 더해 표준 실험 환경과 기록 형식이 함께 제공되므로, 데이터 수집 파이프라인을 처음부터 설계하는 비용을 줄일 수 있습니다. 시뮬레이션만으로 정책을 학습하다가 실제 장비로 넘어가려는 팀에게도 MuJoCo와 Isaac Lab 환경이 같은 로봇 기술 파일을 공유한다는 점이 이점입니다. 장비 구매를 결정하기 전에 공개된 시뮬레이션 데이터셋과 학습 모델로 수집부터 추론까지의 흐름을 먼저 돌려볼 수 있다는 점도 검토 비용을 크게 낮춥니다.

반대로 조작 알고리즘보다 학습 코드 자체를 검증하는 것이 목적이거나 팔을 여러 대 두고 시연 수를 늘리는 것이 우선인 팀에게는 OpenArm이 아직 적절한 선택지가 아닙니다. 완제품 1대에 수천 달러가 들고, 하드웨어에 적용된 CERN-OHL-S-2.0은 설계를 고쳐 배포할 때 같은 조건으로 공개할 의무를 지우므로 사내 개조판을 비공개로 유지하려는 조직에는 제약이 됩니다. 국내에서 바로 구할 수 있는 판매처가 목록에 없어 해외 주문과 통관을 감수해야 한다는 점도 도입 전에 따져야 합니다.

OpenArm의 하드웨어 사양과 가반하중 정의

OpenArm 2.0의 팔 하나는 7자유도이고, 공식 홈페이지가 공개한 수치로는 도달 거리 633mm, 팔 하나 무게 5.5kg, 모터와 주고받는 통신 규격인 CAN-FD 기준 제어 주기 1kHz입니다. 사람 크기에 맞춘 비례와 기계적인 관절 가동 범위 제한을 두어 사람과 같은 공간에서 쓰는 것을 전제로 설계됐고, 지지 기둥은 MiSUMi 알루미늄 프레임이라 치수를 바꾸거나 카메라와 센서를 덧붙이기 쉽습니다.

가반하중은 수치보다 정의를 먼저 읽어야 하는 항목입니다. 프로젝트는 하드웨어 문서에서 두 값을 각각 이렇게 규정합니다:

• 정격 가반하중 4.1kg: 팔을 최대로 뻗은 가장 불리한 자세에서 1분 동안 버틸 수 있는 무게
• 피크 가반하중 6.0kg: 팔을 내린 자세에서 가장 불리한 자세까지 3초에 걸쳐 옮겨 1초 동안 버틴 뒤 되돌아오는 무게

프로젝트는 이 값에 엔드이펙터 무게가 포함된다는 단서를 함께 붙여 두었습니다. 1.5kg짜리 엔드이펙터를 달면 실제로 다룰 수 있는 물체는 정격 2.6kg, 피크 4.5kg으로 줄어듭니다. 카탈로그의 숫자만 보고 작업 대상의 무게를 맞추면 실제 여유가 이만큼 달라집니다.

OpenArm의 단방향 제어와 양방향 힘 피드백

OpenArm은 리더 암의 움직임을 팔로워 암이 1:1로 따라가는 원격 조작을 두 가지 제어 방식으로 지원합니다. 단방향 제어(unilateral control)는 리더가 보낸 위치 명령을 팔로워가 그대로 따르는 한 방향 구성이라 단순하고 안정적이지만, 조작자에게 촉각이 돌아오지 않아 접촉 중에 힘이 과하게 들어가거나 정렬이 어긋나기 쉽습니다. 프로젝트는 이 방식을 자유 공간에서의 조작과 초기 시험에 적합한 기본 구성으로 안내합니다.

양방향 제어(bilateral control)는 리더와 팔로워 사이에 힘을 양쪽으로 주고받아 조작자가 팔로워가 닿은 대상을 느끼게 합니다. 아래 그림은 원격 조작 문서에 실린 4채널 양방향 제어 블록도로, 리더와 팔로워의 가속도 제어 출력이 힘 제어(Force Control)와 위치 제어(Position Control) 두 갈래로 합쳐지고 그 결과가 다시 양쪽으로 되먹임되는 구조를 보여줍니다:

리더 암 쪽에는 조작자의 피로를 줄이려는 별도 장치도 있습니다. OpenArm KER(Kinematic Equivalent Replica)은 모터가 없는 어깨 장착형 리더 암으로, 모든 축에 자기 엔코더와 베어링, 하드웨어 리밋, 드라이버를 한 몸에 넣은 공통 모듈을 쓰고 이 모듈들을 데이지 체인으로 연결해 배선을 줄였습니다. 관절 구조를 OpenArm 2.0과 똑같이 맞추고 링크 길이만 70%로 줄여 두어, 좌표 변환이나 리타게팅(retargeting) 없이 1:1로 동작이 옮겨집니다. 탄소섬유 강화 플라스틱(CFRP) 파이프와 가공 알루미늄, 수지를 섞어 본체를 1.7kg으로 맞췄고, 배낭처럼 어깨에 메는 구조라 도움 없이 30초 안에 착용할 수 있으며 배낭부를 접으면 일반 여행 가방에 들어갑니다.

다만 KER의 출시 상태는 문서마다 다르게 적혀 있습니다. 하드웨어 문서에는 3D CAD와 부품표 드라이브 링크가 이미 올라와 있고 제조사들도 2,599달러부터 판매 중이지만, 2.0 변경점 문서에는 아직 미출시이며 CAD와 부품표는 준비되는 대로 공개한다고 적혀 있습니다. 구매를 검토한다면 이 점을 판매처에 먼저 확인하는 편이 안전합니다.

OpenArm의 소프트웨어 계층 구성

OpenArm 저장소의 README에 실린 표는 9개 저장소를 소개하지만, enactic 조직에는 51개가 올라와 있습니다. 그중 29개가 dora- 로 시작하는 dora-rs 데이터 흐름 노드입니다. 아래 그림은 이 저장소들을 역할에 따라 다섯 계층으로 정리한 것입니다:

각 계층의 진입점은 다음과 같습니다.

• 하드웨어: openarm_hardware에 STL과 STEP 파일, Fusion 360 어셈블리를 포함한 CAD 데이터와 부품표가 들어 있습니다.
• 제어: openarm_can이 Damiao 모터와 통신하는 C++ 라이브러리이고, openarm_driver가 그 위의 파이썬 API, openarm_control이 MuJoCo와 mink 기반 기구학을 맡습니다. openarm_ros2는 로봇 소프트웨어 프레임워크인 ROS 2 연동 패키지입니다.
• 시뮬레이션: openarm_description에 담긴, 로봇의 관절과 링크 구조를 기술하는 URDF/xacro 파일을 openarm_mujoco와 openarm_isaac_lab이 공유합니다.
• 데이터: openarm_dataset이 기록 형식과 파이썬 API를, dora 노드들이 수집과 추론(inference) 실행을 맡습니다.
• 평가: openarm-online-web과 openarm-online-runner가 정책 제출과 실행을 처리합니다.

openarm_driver의 안전 검사가 이 스택의 성격을 잘 보여줍니다. 명령을 보낼 때 관절 위치 한계로 값을 자르는 JointPosChecker, 한 번에 너무 크게 움직이는 명령을 거부하는 JointDeltaPosChecker, 경과 시간을 재서 속도를 제한하는 JointVelocityChecker가 이 순서로 걸립니다. 연구용 코드가 아니라 사람 옆에서 실제로 움직이는 장비를 전제로 한 설계입니다.

OpenArm Dataset의 기록 형식과 표현 변환

조작 데이터를 다루는 입장에서 가장 눈여겨볼 부분은 openarm_dataset입니다. 에피소드마다 관절 위치(qpos), 속도(qvel), 토크(qtorque)와 여러 대의 카메라 프레임을 기록하고, 관측과 행동을 각각 불러오는 API를 제공합니다.

설계에서 흥미로운 점은 저장과 표현을 분리한 것입니다. 데이터셋은 기록 당시의 원시 표현만 저장하고, 필요한 표현은 불러올 때 변환합니다. state= 인자로 요청한 표현이 기록된 것과 다르면 openarm_control의 기구학이 붙어 관절 각도를 순기구학으로 말단 자세(pose)로 바꾸거나, 말단 자세를 역기구학으로 관절 각도로 되돌립니다. 역기구학 변환은 에피소드에 기록된 관측 관절값을 초기값으로 삼아 자세 궤적을 따라가며 풀고, 해가 수렴하지 않은 샘플은 경고로 보고합니다. 회전을 6차원으로 표현하는 rot6d도 같은 경로로 유도됩니다.

카메라 프레임 저장 방식에도 실전에서 나온 판단이 들어가 있습니다. 프레임을 타임스탬프별 JPEG 파일로 두거나 에피소드마다 하나의 tar 아카이브로 묶을 수 있는데, 묶는 쪽은 Hugging Face Hub의 저장소 권장 사항에 맞춰 파일 개수를 줄이기 위한 선택입니다. 두 방식 모두 같은 API로 읽히므로 데이터를 허브에 올려 공유할 때 코드를 고칠 일이 없습니다.

OpenArm 데이터를 LeRobot으로 학습시키는 경로

수집한 데이터를 어떻게 학습에 넣는지가 이 스택에서 가장 실용적인 부분입니다. OpenArm은 자체 형식을 고집하지 않고 LeRobot 데이터셋 형식으로 변환하는 명령을 제공합니다:

git clone https://github.com/enactic/openarm_dataset.git
cd openarm_dataset
uv sync
uv run openarm-dataset-convert path/to/collected_dataset_path path/to/output_path --format lerobot_v3.0

--format lerobot_v2.1 을 주면 구버전 형식으로도 변환됩니다. 변환 뒤에는 LeRobot의 학습 명령을 그대로 씁니다. 공식 튜토리얼은 LeRobot 0.6.1에서 ACT(Action Chunking with Transformers) 정책을 학습시키는 예시를 싣고 있습니다:

lerobot-train \
  --dataset.repo_id=enactic/openarm-2-cell-pick_up_cube_mujoco-lerobot \
  --policy.type=act \
  --output_dir=outputs/train \
  --policy.device=cuda \
  --num_workers=8 \
  --steps=10000

여기서 중요한 것은 로봇 없이도 이 경로를 끝까지 따라가 볼 수 있다는 점입니다. 학습에 쓰는 데이터셋과 학습을 마친 모델이 모두 Hugging Face Hub에 공개돼 있기 때문입니다.

• enactic/openarm-2-cell-pick_up_cube_mujoco-lerobot: MuJoCo 시뮬레이션 안의 Cell에서 가상현실(VR) 원격 조작으로 기록한 큐브 집기 시연입니다. 에피소드 30개에 30fps로 5,405프레임이고, 천장/머리 좌우/손목 좌우 카메라 5대와 16차원 상태와 행동이 들어 있습니다. 16차원은 오른팔 7축과 그리퍼 1축, 왼팔 7축과 그리퍼 1축입니다.
• enactic/act-openarm-2-cell-pick_up_cube_mujoco: 위 데이터로 학습한 ACT 정책입니다. 비전 백본은 ImageNet 사전학습 ResNet-18이고, 행동 청크 길이 100, 트랜스포머는 512차원에 헤드 8개, 인코더 4층과 디코더 1층 구성입니다.

학습한 정책을 로봇에 붙이는 지점도 계약으로 정해져 있습니다. 정책은 정책 서버(policy server) 프로세스로 뜨고, dora 노드가 유닉스 소켓으로 관측을 넘기면 행동을 돌려주는 방식입니다. 관측은 카메라 프레임과 관절 위치를 담은 Arrow IPC 형식 파일로 오고, 응답은 16차원 관절 위치의 시퀀스를 담은 JSON입니다. 응답에는 스텝 간격(interval)과 저역 통과 필터 차단 주파수(cutoff_hz)를 같이 실어 동작의 부드러움을 조절합니다. 다른 모델을 붙이고 싶다면 이 계약만 맞추면 되고, 모델 코드는 dora 노드가 실행하는 프로세스 안에 그대로 두면 됩니다.

OpenArm Online의 정책 평가와 리더보드

OpenArm Online은 정책을 담은 Docker 이미지를 등록하면 실제 장비나 시뮬레이션에 연결된 실행기가 그것을 받아 과제를 수행시키고 결과를 돌려주는 평가 서비스입니다. GitHub 계정으로 로그인해 과제를 고르고 제출하는 흐름이며, 서버 설정에 따라 제출 권한을 특정 계정이나 조직으로 제한할 수 있습니다. 각 평가 실행은 Rerun 기록으로 남아 브라우저에서 되돌려 볼 수 있고, 과제별 리더보드가 제출물의 순위를 매깁니다. 시뮬레이션 과제에는 브라우저에서 WebRTC로 직접 조작하는 경로도 제공되어 키보드나 WebXR을 지원하는 헤드셋으로 움직여 볼 수 있습니다. 실제 장비를 쓰는 Cell 과제에는 이 조작 링크가 없습니다.

다만 도입을 검토하는 입장이라면 현재 상태를 함께 봐야 합니다. 등록된 과제는 시뮬레이션 환경의 Pick and place (MuJoCo)와 실제 장비를 쓰는 Pick and place (Cell) 두 가지이고, 각각 2026년 8월에 만들어졌습니다. 두 과제 모두 제출물과 실행 기록이 아직 없어 리더보드는 비어 있습니다. 평가 기반은 열려 있지만 비교 대상이 쌓이기 전이므로, 지금 시점에 OpenArm Online을 다른 팀과 성능을 견주는 용도로 기대하기에는 이릅니다.

OpenArm 설치와 사용

제어 스택은 SocketCAN을 지원하는 리눅스와 CAN 인터페이스 하드웨어를 전제로 하며, macOS와 윈도우용 안내는 없습니다. 모터와 통신하는 CAN 라이브러리는 우분투(Ubuntu) 22.04/24.04/26.04와 레드햇 계열 배포판에 패키지로 올라와 있고, 우분투에서는 저장소를 추가한 뒤 설치합니다:

sudo apt install -y software-properties-common
sudo add-apt-repository -y ppa:openarm/main
sudo apt update
sudo apt install -y libopenarm-can-dev openarm-can-utils

설치 후에는 CAN 인터페이스를 설정하고 버스에 붙은 모터를 확인합니다:

# CAN-FD, 데이터 구간 5Mbps
openarm-can-configure-socketcan can0 -fd