간단한 에이전트 프레임워크를 찾을 수 없어서 직접 만들었습니다
요약
복잡한 기존 에이전트 프레임워크의 한계를 극복하기 위해 설계된 경량화된 에이전트 프레임워크 'swarmvault'를 소개합니다. 불필요한 컨텍스트를 줄이기 위해 엄선된 13가지 기술만을 사용하며, 명세 기반의 워크플로우와 단일 폴더 구조의 볼트(vault) 시스템을 통해 효율적인 에이전트 협업을 지원합니다.
핵심 포인트
- 복잡성을 최소화한 13가지 핵심 기술 중심의 경량 프레임워크
- SRS(소프트웨어 요구사항 명세서) 기반의 엄격한 에이전트 워크플로우
- 단일 폴더 구조(vault)를 통한 프로젝트 상태 및 메모리 관리
- 에이전트 간 작업 중복을 방지하는 티켓 점유(claim) 시스템
- 불필요한 출력(filler)을 제거하고 명세에 집중하는 설계
나는 내 라이브러리에 추가하고 싶은 새로운 에이전트 기술(agent skill)을 계속해서 발견하곤 합니다. 각각의 기술은 그 자체로 훌륭한 추가 요소이지만, 바로 그것이 함정입니다. 기술은 공짜가 아닙니다. 기술을 추가할 때마다 컨텍스트 (context)를 차지하며, 어느 시점에는 도움이 되지 않고 오히려 모델을 악화시키기 시작할 수도 있습니다.
더 큰 라이브러리는 진전처럼 보입니다. 하지만 저는 그것이 진전이라고 확신하지 않습니다.
제가 살펴본 프레임워크들은 더 심각한 동일한 문제를 가지고 있었습니다. 모두 수십 개의 기능, 학습해야 할 설정 영역, 그리고 코드를 작성하기도 전에 파악해야 할 수많은 에이전트들로 어지럽혀져 있었습니다. 저는 머릿속에 다 담을 수 있을 만큼 충분히 작은 무언가를 원했습니다.
그래서 저는 이미 알고 있는 것 중 가장 좋은 것들을 하나의 세트로 결합하고 거기서 멈췄습니다.
git clone https://github.com/AnmarHani/swarmvault && cd swarmvault && ./install.sh
숫자가 곧 디자인입니다
13은 목표치가 아닙니다. 제가 실제로 사용했거나 좋다고 판단한 기술들을 가져와서, 중복을 제거하고 서로 잘 맞도록 (Claude의 도움을 받아) 다시 작성하고 남은 숫자입니다. 살아남은 것들은 대부분의 작업에 충분할 것입니다.
만약 무언가 누락되었다면, 그 해답은 동일한 컨텍스트를 두고 경쟁하는 또 다른 전체 기술이 아니라, 얇은 확장 (thin extension) 형태여야 합니다. 그 제약 조건이 이 아이디어의 핵심이며, 제가 여러분에게 이 프레임워크를 판단해 달라고 요청하고 싶은 부분입니다.
모든 기술은 또한 단독으로 실행됩니다. 어떤 에이전트의 기술 디렉토리에 하나를 복사하기만 하면, 볼트 (vault)도, 스크립트도, 형제 기술도 없이 작동합니다.
분위기가 아닌 명세(spec)를 따릅니다
워크플로우는 실제 SRS (Software Requirements Specification, 소프트웨어 요구사항 명세서)로 끝나는 요구사항 인터뷰를 실행한 다음, 결정 사항이 기록된 설계, 그리고 완료 정의 (definition of done)에 테스트가 포함된 의존성 순서의 티켓(tickets) 생성으로 이어집니다. 핵심은 명세가 에이전트가 작성하고 잊어버리는 문서가 아니라는 점입니다. 에이전트들은 명세를 정확히 따르며, 모든 마일스톤(milestone)마다 강력한 모델이 명세에 따라 작업 내용을 감사 (audit)합니다.
동일한 기준이 결과물에도 적용됩니다. 많은 에이전트의 출력물은 불필요한 내용(filler)입니다. 불필요한 형식을 갖춘 코드(code with ceremony)나, 읽기 위한 목적보다는 완결되어 보이게만 작성된 문서 등이 그러합니다. 코드와 문서에서 이러한 부분을 걷어내는 것은 사후에 정리해야 할 작업이 아니라, 작업 흐름(flow)의 일부입니다.
에이전트가 기록하고자 하는 무엇이든 담는 하나의 볼트 (vault)
볼트(vault)는 단순한 폴더 구조입니다: 10 Projects, 20 Memory, 30 Plans, 40 Sessions, 50 Decisions. 에이전트는 기록할 가치가 있다고 판단한 내용을 기록하며, 이후 어떤 플랫폼에서든 진행되는 세션은 이를 다시 읽어옵니다. 의존성이 없는(zero-dependency) 단일 스크립트를 통해 모든 에이전트는 볼트에 대해 query, sync, claim, context 권한을 가집니다.
실질적으로 이는 새로운 세션을 열고 "프로젝트 X를 계속해줘"라고 말하면, 마지막 작업이 멈춘 지점부터 바로 이어서 시작할 수 있음을 의미합니다. 티켓(ticket)은 가장 먼저 점유(claim)하는 사람의 소유가 되므로, 두 에이전트가 병렬로 작업하더라도 동일한 작업에 중복으로 투입되지 않습니다.
적절한 작업에 적절한 모델 배치
선택 사항이며, 활성화하지 않으면 꺼져 있습니다. 시스템은 Claude Code, Codex, Cursor와 같이 사용자가 보유한 에이전트 플랫폼이 무엇인지 파악하고, 사용량 제한(usage limits)을 고려하면서 각 모델이 잘하는 작업에 따라 업무를 분배합니다.
이를 모니터링하기 위한 중앙 보드(central board)가 있으며, 고정된 목록이 아닌 모든 CLI(Command Line Interface)와 함께 작동하도록 설계되었습니다. 새로운 CLI를 추가하는 것은 플러그인이 아니라 실행 명령 템플릿(launch-command template)을 통해 이루어집니다.
지원하지 않는 기능
대시보드, 호스팅 서비스, 플러그인 시스템은 없습니다. Claude Code와 Codex는 검증된 플랫폼이며, Gemini CLI, OpenCode, Cursor, Copilot은 최선의 노력(best-effort) 기반으로 동일한 볼트에서 작동합니다. Linux, macOS, WSL은 퍼스트 클래스(first-class)로 지원되며, 네이티브 Windows는 최선의 노력(best-effort) 기반으로 지원됩니다.
오케스트레이터(orchestrator)를 활성화하지 않는 한 아무것도 백그라운드에서 실행되지 않습니다. 네트워크 호출도, 텔레메트리(telemetry)도 없습니다. 사용자의 디스크에 저장되는 단순한 마크다운(markdown) 파일이며, MIT 라이선스입니다.
전체 코드는 신뢰하고 맡기기 전, 오후 한나절이면 충분히 읽어볼 수 있을 만큼 작습니다. 그것이 바로 이 프로젝트의 핵심입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기