이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Leviath는 모델·도구·컨텍스트 예산을 stage마다 다르게 배정하는 28 MB Rust 기반 agent runtime으로, 한 프로세스에서 최대 10,000개 에이전트를 실행한다. task와 plan은 pinned 영역으로 유지하고 conversation은 sliding window로 압축하며, Run journal은 중단된 작업에서 완료된 도구 호출을 재실행하지 않도록 상태를 기록한다. 컨텍스트 윈도 스트레스 실험에서 structured agent는 32k·64k·128k 조건 모두 10회 중 10회 보고서를 완성했지만 single-model loop는 모두 0회였고, 128k 검증 실험에서는 조작 수치가 8개에서 0개로 줄었다. 다만 자체 제작한 극한 조건의 실험이며, 자료가 한 윈도에 충분히 들어가는 작업에는 단일 loop를 우선하라는 결론이다.
섹션별 상세
Leviath는 모델, 도구 세트, stage별 컨텍스트 예산을 하나의 에이전트 실행 단위로 묶고, 별도 설치물 없이 28 MB Rust binary 하나로 동작하는 runtime이다. 하나의 프로세스 안에서 에이전트를 여러 개 실행해 에이전트마다 runtime과 메모리를 복제하는 구조를 피한다. 글의 부하 테스트에서는 Apple M3 Max의 16코어 환경에서 최대 10,000개 에이전트를 같은 프로세스에 올렸고, 10,000개 구간의 peak live memory는 2.8 GB, CPU 사용률은 44%였다.
긴 agent run에서 전체 transcript를 한 번에 압축하면 초기 제약과 이미 읽은 파일의 세부 정보가 사라져 같은 작업을 반복하기 쉽다. Leviath는 task·plan·codebase 같은 pinned Context regions를 계속 유지하고, conversation만 sliding window로 별도 압축하며 tool calls도 규칙에 따라 창에서 밀어낸다. 이 분리 구조는 작업의 목표와 계획을 최근 대화 요약에 묻히지 않게 하면서 컨텍스트 예산을 stage 단위로 관리한다.
Stages는 탐색·구현·검토·재평가처럼 역할을 나누고 각 단계에 다른 모델, 도구, 컨텍스트 예산과 반복 한도를 배정한다. 제공된 coder 설정에서는 plan stage가 claude-sonnet-5와 read_file·ask_user_choice·edit_document를 사용하고, implement stage가 claude-opus-5와 write_file·edit_file·bash를 사용하며, 같은 파일을 5회 편집하거나 20회 반복·15분이 지나면 reassess로 전환한다. 따라서 파일 목록 확인이나 diff 검토에 비싼 모델을 계속 쓰지 않고, 실제 코드 작성처럼 필요한 단계에만 더 강한 모델을 배치할 수 있다.
Run journal은 도구 호출이 시작될 때와 완료될 때마다 기록을 남겨 프로세스가 중단돼도 수행 상태를 복원한다. 예를 들어 파일 작성과 migration, branch push가 완료된 뒤 release mail 단계에서 OOM이 발생하면 daemon이 앞선 세 작업을 재실행하지 않고 미완료 작업만 사용자 확인 대상으로 돌린다. 외부 저장소에 별도 설정을 요구하지 않으면서 중복 push나 migration 재실행 같은 복구 위험을 줄이는 방식이다.
text
[stages.plan] ← Stages
mode = "interactive_points" ← Live steering
model = { models = [{ provider = "anthropic", model = "claude-sonnet-5" }] }
available_tools = ["read_file", "ask_user_choice", "edit_document"]
max_iterations = 20
[stages.implement]
model = { models = [{ provider = "anthropic", model = "claude-opus-5" }] }
available_tools = ["write_file", "edit_file", "bash"]
max_iterations = 50
[stages.implement.transitions.reassess] ← Stages
condition = "stuck"
stuck_after_iterations = 20
stuck_after_minutes = 15
stuck_after_same_file_edits = 5
hint = "No forward progress - step back and reassess"
[context.regions] ← Context regions
task = { kind = "pinned", budget = "2%" }
plan = { kind = "pinned", budget = "5%" }
conversation = { kind = "sliding_window", max_items = 40, budget = "20%" }plan과 implement stage의 모델·도구·반복 한도를 지정하고, 반복 정체 조건과 Context regions의 보존 예산을 설정하는 Leviath 에이전트 파일이다.
글의 컨텍스트 한계 실험에서는 32k, 64k, 128k 윈도에서 17개의 정확한 수치를 포함한 보고서 생성 여부를 비교했고, 단일 모델 loop는 각 크기에서 10회 중 0회, structured agent는 각 크기에서 10회 중 10회 성공했다. 128k 윈도의 동일 pipeline 실험에서는 검증 단계가 없을 때 5회 중 3개 보고서가 완성됐지만 8개의 수치가 조작됐고, 검증 단계를 넣자 5개 모두 완성되며 조작 수치는 0개였다. 다만 자체 작업과 윈도 스트레스를 겨냥한 사전 동결 실험이므로 일반적인 업무 성능의 보편적 점수로 읽지 말아야 한다.
Leviath는 모든 작업에 복잡한 pipeline을 강제하지 않고 자료와 대화가 충분한 여유를 두고 한 윈도에 들어가면 single loop를 권장한다. 자료가 윈도보다 크거나 결과가 원문과 정확히 일치해야 하면 stage 경계를 통해 무엇을 보존할지 결정하고 draft 뒤에 source 검증 단계를 둘 수 있다. 두 방식은 같은 binary와 blueprint 파일을 사용하므로 single loop에서 pipeline으로 바꾸는 일이 별도 시스템 이전이 아니라 설정 편집으로 남는다.
10,000개 에이전트 부하 측정은 Apple M3 Max 16코어, 28 MB binary, 1.5초 고정 지연의 mocked model, 512개 inference pool 조건에서 수행됐다. 에이전트 수가 10개·100개·1,000개·10,000개로 늘어날 때 peak live memory는 각각 34 MB, 197 MB, 945 MB, 2.8 GB였고, 에이전트당 비용은 10개에서 3.4 MB, 10,000개에서 0.28 MB로 낮아졌다. 1,000개 에이전트의 완료 시간은 pool 128·256·512·1,024에서 각각 277초·160초·105초·89초였으며, pool을 128에서 1,024로 넓힐 때 총 CPU 사용량은 14.5 machine-seconds에서 2.9로 감소했다.
비교 표는 Leviath와 다른 framework의 우열을 직접 판정하지 않고 서로 다른 측정 조건을 병기한다. 2026년 2월 n1n.ai benchmark에서 Agents와 Rig의 peak RSS는 각각 1,046 MB와 1,019 MB였고, LangChain·PydanticAI·LlamaIndex·GraphBit·LangGraph는 4,718~5,706 MB 범위였지만 해당 실험은 50개 요청과 GPT-5.1 네트워크 호출을 사용했다. Leviath 측정은 최대 10,000개 agent를 mocked model로 실행하고 reclaimable pages를 제외한 live memory를 사용했으므로 RSS·실제 end-to-end latency와 숫자를 그대로 맞세우기 어렵다.
용어 해설
- Context regions
- — 에이전트가 장시간 작업에서 정보를 보존하는 이름 있는 컨텍스트 영역이다. task와 plan처럼 계속 유지하는 영역, conversation처럼 sliding window로 압축하는 영역을 분리해 각기 다른 예산과 보존 규칙을 적용한다. 전체 대화를 한 번에 요약하는 방식보다 핵심 상태와 최근 상호작용을 독립적으로 관리할 수 있다는 점이 중요하다.
- Sliding window
- — 최근 항목만 컨텍스트에 남기고 오래된 항목을 밀어내는 메모리 관리 방식이다. Leviath에서는 conversation 영역에 max_items와 예산을 지정하고, task·plan·codebase 같은 고정 영역은 별도로 보존한다. 긴 작업에서 전체 기록을 하나의 손실성 요약으로 압축하는 문제를 줄이는 데 쓰인다.
- Run journal
- — 에이전트가 수행한 도구 호출과 결과를 실행 중 기록하는 журнал이다. 호출이 시작될 때와 완료될 때 상태를 남기므로 프로세스가 중단된 뒤 daemon이 완료된 작업은 재실행하지 않고, 진행 중이던 작업만 확인 대상으로 돌릴 수 있다. 마이그레이션이나 브랜치 push처럼 반복 실행이 위험한 작업의 복구에 의미가 있다.
- 여러 에이전트의 모델 추론 요청을 함께 처리하는 고정 크기 실행 풀이다. 글의 부하 테스트에서는 풀 크기를 128, 256, 512, 1,024로 바꾸면서 동시에 처리하는 작업 수와 메모리·CPU·완료 시간을 측정했다. 풀을 넓히면 같은 1,000개 작업을 더 빨리 끝내지만 실행 중 메모리 사용량은 높아진다.(Inference pool)
- — 여러 에이전트의 모델 추론 요청을 함께 처리하는 고정 크기 실행 풀이다. 글의 부하 테스트에서는 풀 크기를 128, 256, 512, 1,024로 바꾸면서 동시에 처리하는 작업 수와 메모리·CPU·완료 시간을 측정했다. 풀을 넓히면 같은 1,000개 작업을 더 빨리 끝내지만 실행 중 메모리 사용량은 높아진다.
- 하나의 긴 루프 대신 여러 stage와 컨텍스트 예산, 전환 조건으로 작업 흐름을 나눈 에이전트다. 각 stage가 모델·도구·반복 횟수를 따로 선택하고, stuck 조건이 충족되면 reassess stage로 이동해 작업을 다시 판단한다. 자료가 한 번의 컨텍스트 윈도에 들어가지 않거나 결과 검증이 필요한 작업에서 단일 루프보다 안정적인 형태로 쓰인다.(Structured agent)
- — 하나의 긴 루프 대신 여러 stage와 컨텍스트 예산, 전환 조건으로 작업 흐름을 나눈 에이전트다. 각 stage가 모델·도구·반복 횟수를 따로 선택하고, stuck 조건이 충족되면 reassess stage로 이동해 작업을 다시 판단한다. 자료가 한 번의 컨텍스트 윈도에 들어가지 않거나 결과 검증이 필요한 작업에서 단일 루프보다 안정적인 형태로 쓰인다.
기술
- Leviath
- Rust
- The Lair
- claude-sonnet-5
- claude-opus-5
- lev dash
- MCP tool servers
- REST API
- WebSocket API
- OpenTelemetry tracing
- sandboxing
- taint tracking
활용 사례
- 코딩 agent의 계획·구현·검토 workflow
- 대규모 battery technology research
- 자료가 컨텍스트 윈도보다 큰 조사 보고서 작성
- 원문 대조가 필요한 수치 검증
- rate limiting을 포함한 API 코드 변경
- sub-agents와 fan-out을 사용하는 병렬 작업
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 18.수집 2026. 08. 18.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
