클로드·코덱스, 토크나이저 장난감은 30분 만에 실전은 실패

리퀴드AI는 온디바이스(edge) LLM의 어휘 크기가 성능에 미치는 영향을 연구하던 중, 단일 머신에서 수조 개 토큰을 처리할 수 있는 바이트 페어 인코딩(BPE) — 자주 등장하는 글자 쌍을 묶어 어휘를 만드는 토큰화 방식 — 트레이너가 필요했다. 그런데 기존 도구들은 하나같이 부족했다. sentencepiece는 BPE가 아닌 방식에 최적화돼 느렸고, 허깅페이스(Hugging Face)의 tokenizers 라이브러리는 대용량 코퍼스에서 메모리 부족을 일으켰으며, tiktoken은 애초에 훈련 기능 자체가 없었다.

리퀴드AI가 이 과제를 실험 대상으로 고른 이유는 세 가지다. 첫째, 기존 시스템을 다른 언어로 옮기는 포팅 작업이 아니라 실제 배포를 목표로 하는 과제였다. 둘째, 토크나이저 훈련을 이해하는 ML 연구자와 메모리 인식 멀티스레드 코드를 짜는 러스트 엔지니어라는 서로 다른 두 전문성이 동시에 필요했다. 리퀴드AI는 "우리 엔지니어 누구도 혼자서는 감당하지 못하는 전문성 범위를 에이전트가 대신할 수 있는가"를 확인하려 했다고 설명했다. 셋째, 결과물이 tiktoken과 허깅페이스 tokenizers에 그대로 로드돼야 하는 외부 검증 조건이 있어, 에이전트가 스스로 성공을 조작할 여지가 없었다.

목표와 검증을 분리해 설계하다

실험 설계자는 에이전트가 코드를 한 줄도 쓰기 전에 두 가지를 먼저 준비했다. 하나는 목표를 규정한 AGENTS.md·CLAUDE.md 명세 문서였다. 이 문서는 구현 방법이 아니라 결과와 제약만 담았다 — 메모리가 가장 큰 제약이므로 RAM보다 훨씬 큰 코퍼스도 안정적으로 처리해야 하고, 연산과 입출력은 러스트와 멀티스레딩으로 처리하면 충분하다는 식이었다.

다른 하나는 에이전트가 손댈 수 없는 검증 장치였다. 에이전트에는 실제 프로덕션 훈련 데이터셋과 이를 처리할 수 있는 AMD EPYC 9755 서버(128코어 256스레드, 메모리 2TB)에 대한 샌드박스 접근권이 주어졌다. 훈련된 어휘는 tiktoken과 허깅페이스 tokenizers 양쪽에 로드돼 인코딩·디코딩 왕복 결과가 일치하는지, 여러 언어·숫자·통화 표기·탭·줄바꿈·소스코드에서까지 문제가 없는지 검사받았다.

코드는 통과했는데 왜 무너졌나

문제는 규모였다. 몇 메가바이트짜리 테스트 데이터에서는 드러나지 않던 결함이 실제 코퍼스에서는 줄줄이 터져 나왔다. 리퀴드AI가 정리한 7가지 문제는 다음과 같다.

발견된 문제	어떻게 드러났나	무엇이 잡아냈나	수정 소요
파일 인코딩 불일치	테스트에서는 멀쩡했지만 코퍼스에서 조용히 오작동	실제 코퍼스 파일	수 시간
메모리 인식 부족	목표 코퍼스의 약 1% 지점에서 메모리 부족	전체 규모 실행	2~3일
병렬화 미흡	모든 코어가 바쁜데도 처리량 미달	전체 규모 실행	1~2일
사전 토큰화 속도 저하	정규식 역추적으로 처리 속도 급감	프로파일러	수 시간
순위(rank) 정렬 오류	어휘는 로드되지만 의도와 다르게 인코딩	외부 검증 도구	수 시간
중복 병합	어휘 개수 부족, 이후 순위 전부 밀림	외부 검증 도구	수 시간
숫자 인코딩 오류	두 라이브러리가 숫자에서만 결과 불일치	외부 검증 도구	한 줄 수정

루프를 걸자 달라진 것

리퀴드AI는 이 시점에서 방식을 바꿨다. 에이전트가 실제 데이터로 실행하고, 벽에 부딪히면 증상을 보고하고, 스스로 진단해 고친 뒤 다시 실행하는 순환 구조를 도입했다. 이 반복이 여러 차례 이어지면서 두 에이전트는 앞서 표에 정리된 문제들을 하나씩 해결해 나갔다고 리퀴드AI는 밝혔다. 결과물로 나온 BPE 토크나이저 트레이너 toktoktok은 현재 리퀴드AI GitHub 계정에 오픈소스로 올라와 있다.

업계에서는 이런 반복 구조를 에이전트 루프라고 부른다. 한 바퀴는 네 단계다. 실제 데이터로 실행하고, 무엇이 어떻게 깨졌는지 증상을 그대로 보고하고, 증상이 아니라 원인을 짚고, 고친 뒤 다시 처음으로 돌아간다. 앞의 표에서 수정 소요가 「수 시간」부터 「2~3일」까지 벌어진 것은 결함마다 이 바퀴가 돈 횟수가 달랐기 때문이다.

이 구조에서 채점을 맡는 쪽은 에이전트가 아니다. 앞의 표에서 「무엇이 잡아냈나」 열을 다시 보면 에이전트의 자체 단위 테스트가 잡아낸 결함은 하나도 없다. 실제 코퍼스 파일과 전체 규모 실행, 프로파일러, 그리고 외부 검증 도구가 일곱 개를 전부 잡았다. 30분 만에 나온 장난감 트레이너도 자체 테스트만큼은 통과했다는 사실이 같은 이야기를 반대편에서 보여 준다. 루프가 일을 하려면 에이전트가 손댈 수 없는 채점표가 먼저 있어야 한다.

루프를 직접 걸어 보려면

이 실험의 구조는 특별한 장비 없이도 따라 할 수 있다. 클로드 코드와 코덱스 모두 사람이 지켜보지 않아도 도는 실행 모드를 이미 제공한다. 순서는 네 단계다.

첫째, 목표와 채점표를 다른 파일에 둔다. 명세에는 결과와 제약만 적고 구현 방법은 적지 않는다. 제약은 가장 먼저 무너질 것을 맨 위에 쓴다 — 이번 실험에서는 메모리가 거기 해당했다. 클로드 코드는 AGENTS.md 를 직접 읽지 않으므로, 앤스로픽 문서가 안내하는 대로 CLAUDE.md 첫 줄에 @AGENTS.md 를 넣거나 심링크를 걸어 두 도구가 같은 명세를 보게 한다.

둘째, 채점표를 에이전트 권한 밖으로 뺀다. 클로드 코드는 .claude/settings.json 의 permissions.deny 에 검증 스크립트 경로를 넣으면 편집 자체가 막힌다. 명세 파일에 「이 파일은 고치지 마라」라고 적어 두는 것과는 강제력이 다르다. 같은 문서도 CLAUDE.md 는 참고할 문맥이지 강제되는 설정이 아니라고 못 박는다.

셋째, 루프를 도는 주체를 셸로 옮긴다. 에이전트에게 「될 때까지 반복해」라고 맡기면 스스로 끝났다고 판단하는 순간 멈춘다. 검증 스크립트를 먼저 돌리고 실패하면 그 로그를 통째로 붙여 에이전트를 다시 부르는 반복문을 셸에 두는 편이 확실하다. 로그는 요약하지 말고 그대로 넘긴다. 「두 라이브러리가 숫자에서만 어긋난다」 같은 단서는 요약할 때 가장 먼저 사라진다.

하는 일	클로드 코드	코덱스
사람 없이 한 회차 실행	claude -p "지시"	codex exec "지시"
파일 수정 허용	--permission-mode acceptEdits	--sandbox workspace-write
승인 창 끄기	--allowedTools 로 도구 지정	--ask-for-approval never
앞 회차 맥락 잇기	--resume 세션ID	codex exec resume --last
회차·비용 상한	--max-turns · --max-budget-usd	셸 반복문에서 직접

코덱스의 --full-auto 는 폐기됐고 --sandbox workspace-write 가 그 자리를 대신한다. 승인 설정을 끄지 않으면 승인 요청이 뜨는 순간 실행이 그대로 실패하므로, 비대화 실행에서는 반드시 함께 지정한다.

넷째, 멈추는 조건을 미리 정한다. 회차 수와 비용에 각각 천장을 두고, 클로드 코드라면 Stop 훅으로 검증을 통과하기 전에는 아예 멈추지 못하게 막을 수도 있다. 훅 스크립트가 종료 코드 2를 돌려주면 정지가 차단되고, 표준 오류에 쓴 내용이 그대로 에이전트에게 전달된다. 이때 훅 입력으로 들어오는 stop_hook_active 값을 먼저 확인해, 이미 훅 때문에 돌고 있는 상태면 놓아줘야 한다. 이 장치를 빼면 못 고치는 결함 하나에 에이전트가 갇힌다.

같은 로그가 세 번 반복되면 회차를 늘릴 일이 아니다. 명세가 모호하거나 채점표가 원인을 못 짚고 있다는 신호이고, 그때는 사람이 명세를 다시 써야 한다.

에디터의 시선

이 실험이 흥미로운 이유는 '에이전트가 코드를 잘 짜는가'를 묻지 않았다는 점이다. 리퀴드AI가 확인한 건 '사람 없이 프로덕션 검증을 통과할 수 있는가'였고, 여기서 갈렸다. 30분 만에 나온 장난감 트레이너는 자체 테스트를 통과한다는 이유로 얼핏 성공처럼 보이지만, 실제 실패는 규모를 키우는 순간에만 드러났다. 벤치마크나 데모에서 흔히 보이는 성공 사례 다수가 이 '장난감 단계'에 머물러 있을 가능성을 이 실험이 보여준다.

비슷한 크기의 코딩 에이전트 작업을 실무에 붙여 보면 결론이 늘 비슷하게 흘러간다 — 처음 결과물은 그럴듯하지만, 실제 데이터 규모나 엣지 케이스를 만나는 순간 숨어 있던 가정이 깨진다. 이번 실험에서 메모리 부족이 목표 코퍼스의 겨우 1% 지점에서 터졌다는 사실이 그 증거다. 작은 테스트로는 절대 잡히지 않는 오류였다.

실무적으로 의미 있는 대목은 '목표와 검증을 분리하라'는 설계 원칙이다. 구현 방법 대신 결과와 제약만 명세하고, 에이전트가 손댈 수 없는 외부 라이브러리로 검증하는 방식은 국내 팀이 에이전트에 실제 업무를 맡기려 할 때 참고할 만한 최소 조건이다. 코드 리뷰를 사람이 대신하는 대신, 검증 자체를 자동화하고 반복 실행을 허용하는 구조가 먼저 갖춰져야 한다는 뜻이다.

앞으로 몇 주 안에 비슷한 '루프 기반' 에이전트 평가 사례가 다른 회사에서도 나올 가능성이 크다. 프론티어 모델의 코딩 벤치마크 점수 경쟁이 이어지는 상황에서, 이번 실험처럼 '장난감 대 프로덕션'을 가르는 평가 방식이 벤치마크 신뢰도를 검증하는 새로운 기준으로 자리 잡을 수 있다.