ONEDEV검색

옥토마인드가 CI와 데몬까지 아우르는 오픈소스 코딩 에이전트 런타임을 공개했다

Hacker News2026-11-04

옥토마인드는 LLM이 저장소를 실제로 다루도록 만드는 CLI 우선 코딩 에이전트 런타임이다. 파일 읽기와 쓰기, 셸 명령 실행, 코드 검색, 하위 에이전트 위임을 MCP 도구로 연결하며, 하나의 바이너리로 터미널·CI·데몬·WebSocket·다른 에이전트의 ACP 하위 에이전트까지 같은 세션 엔진을 재사용한다.

일반적인 코딩 에이전트가 대화형 화면을 전제하는 것과 달리, 옥토마인드는 stdin 파이프, 백그라운드 데몬, 스케줄 실행처럼 사람이 자리를 비운 뒤에도 이어지는 작업을 겨냥한다. 예를 들어 파이프로 질문을 넣거나 `--daemon`으로 세션을 띄운 뒤 다른 터미널에서 명령을 보낼 수 있고, 결과는 plain 또는 JSONL로 받을 수 있다.

자율 실행의 통제는 승인 팝업 대신 정책 코드로 처리한다. 저장소에 `.agents/guardrails.toml`을 두면 호출 전 차단, 결과 후 훅, 턴 종료 후 검증을 TOML과 스크립트로 결정적으로 집행한다. 셸 명령의 인자 정규식, 세션 이력 조건, 기능 단위 거부를 걸 수 있고, 후처리 훅이 비정상 종료하면 표준출력이 에이전트의 다음 입력으로 들어가 린트나 포맷 실패를 별도 턴 재시작 없이 교정하게 만든다.

비용 통제도 설정 파일에 들어간다. 역할별 모델과 온도, 시스템 프롬프트, 도구를 지정하고 요청당·세션당 지출 임계값을 둔다. 요청이 임계값을 넘으면 중단되고, 세션 임계값에 닿으면 대화형 세션은 계속할지 y/N을 묻지만 비대화형 `octomind run`은 종료 코드 75로 멈춘다. OpenRouter, Anthropic, OpenAI, DeepSeek, Ollama 또는 Octomind Cloud를 쓸 수 있다.

공개된 옥토벤치 결과는 25개 과제 중 24개 해결을 기록했다. Python, PHP, Rust, C++, JavaScript의 병합된 풀 리퀘스트에서 뽑은 과제로, 각 에이전트는 수정 전 저장소에서 작업하고 병합된 수정의 held-out 테스트로 통과 여부를 판정한다. 같은 모델과 엔드포인트를 쓴 opencode와 비교해 24대 19였고 비용은 대략 절반이었다. 네 에이전트 모두 별도 튜닝 없는 기본 호출로 돌렸다.

가장 불리한 가격 조건에서도 앞섰다고 설명한다. GLM-5.2는 프롬프트 캐싱 없이, Opus는 컨텍스트 재읽기의 약 97%가 캐시 요금으로 계산되는 조건이었는데도 해결 수, 비용, 실제 소요 시간에서 옥토마인드가 우위였다는 것이다. 다만 이 수치는 공개된 벤치마크 결과이며 현재 체크아웃 자체를 측정한 값은 아니라고 원문은 전제한다.

전문 에이전트는 tap 레지스트리에서 당겨 쓴다. `developer:general`은 프롬프트, 모델, MCP 서버, 도구 권한을 묶은 패키지형 에이전트이며 처음 실행할 때 필요한 도구와 자격 증명을 준비한다. 팀 단위 tap을 만들고 GitHub에 배포할 수 있고, 저장소 이름 앞에는 `octomind-` 접두사가 자동으로 붙는다. 기본 설정 없이 `octomind run`을 실행하면 `assistant:concierge` 역할이 시작된다.

설정은 TOML 한 벌로 모델, 도구, 역할, 가드레일, 예산을 정의하며 프레임워크 코드를 요구하지 않는다. 긴 작업은 적응형 압축으로 작업 지식과 현재 교환을 유지하면서 계속 진행한다. MCP는 stdio와 Streamable HTTP, OAuth를 지원하고 세션 중 서버를 켜고 끌 수 있다. `.agents/tools/`의 실행 스크립트는 도구로 자동 등록되고, `--sandbox`는 파일 쓰기를 작업 디렉터리로 제한한다. `--schema`로 최종 응답을 JSON 스키마에 맞출 수 있지만 구조화 출력을 지원하는 모델이 필요하다.

CI와 데몬, 스케줄러에서 코딩 에이전트를 운용하려는 팀에는 승인 UI 대신 저장소에 정책을 두는 방식이 실무적이다. 실패한 린트를 자동 교정 입력으로 되돌리고, 요청·세션 예산을 코드로 제한하며, 같은 세션 엔진을 파이프와 WebSocket, 다른 에이전트 내부까지 확장할 수 있다는 점이 기존 대화형 도구와 다른 지점이다.

도입 전 확인할 전제도 있다. 벤치마크는 공개된 결과이며 현재 코드 상태의 재측정이 아니고, 구조화 출력은 모델 지원에 의존한다. 첫 전문 에이전트 실행 시 도구 설치와 자격 증명 요청이 발생할 수 있으며, 소스 빌드에는 protoc가 필요하다.