IDE 에 종속되지 않는 AI 코딩 엔진, 그리고 스스로 개선되는 에이전트
IDE 에 종속되지 않는 AI 코딩 엔진, 그리고 스스로 개선되는 에이전트
하나의 엔진이 VS Code 에서도, 터미널에서도, iPhone 음성에서도 동일하게 돈다. 그리고 벤치마크에서 실패하면, 그 실패가 엔진 자신을 고친다.
왜 또 하나의 AI 코딩 스택인가
지난 2년 동안 AI 코딩 툴은 폭발적으로 늘었습니다. Cursor, Windsurf, Continue, Aider, OpenDevin, Claude Code, Codex CLI… 좋은 도구가 많아졌다는 뜻이기도 하지만, 동시에 똑같은 엔진을 여섯 번 다시 쓰는 중 이라는 뜻이기도 합니다.
각 툴은 자기 UI 안에 오케스트레이션 루프, 도구 실행기, 세션 관리자, MCP 클라이언트를 직접 품고 있습니다. VS Code 확장이면 확장대로, 터미널 TUI 면 TUI 대로 엔진이 한 벌씩 존재합니다. 팀이 에이전트 로직을 개선하고 싶어도, 개선 대상이 "VS Code 확장 안의 JavaScript 코드" 로 묶여 있으면 그 개선을 CLI 로 옮기는 일은 사실상 재구현입니다.
banya-framework 는 이 문제를 설계 단계에서 갈라놓은 프로젝트입니다. 엔진을 IDE 에서 분리해 하나의 공용 바이너리로 빼고, 여러 개의 얼굴(terminal, VS Code, JetBrains, iOS 음성)이 그 바이너리를 공유하게 만들었습니다.
이 글에서는 그 구조 결정의 핵심 세 가지를 소개합니다.
IDE-agnostic 엔진 — banya-core 가 어떻게 자신을 "라이브러리" 로 배포하는가
Host-Owned LLM 패턴 — LLM 백엔드가 바뀌어도 엔진 재빌드가 필요 없는 이유
SIBDD 루프 — 벤치마크 실패를 자기 코드 개선으로 순환시키는 자기개선 구조
1. 하나의 SEA 바이너리가 네 개의 프런트엔드에 연결된다
banya-core 는 TypeScript 로 작성된 AI 코딩 엔진이지만, 사용자에게 dist/banya-core-<platform>-<arch> 라는 Bun SEA (Single-Executable Application) 단일 바이너리 로 배포됩니다. 이 바이너리는 두 개의 전송 레이어를 동일 프로토콜(JSON-RPC + 이벤트 스트림)로 노출합니다.
banya-core (Bun SEA binary)
├─ stdio NDJSON ← cli / agent (headless)
└─ WebSocket JSON-RPC ← VS Code / JetBrains (interactive)
핵심은 core 코드베이스에 vscode 나 JetBrains SDK 에 대한 참조가 0건 이라는 점입니다. 모든 에디터 기능(diff 표시, 터미널 조작, 파일 I/O, LSP 실행)은 IDE 인터페이스의 27개 메서드로 정의되어 있고, core 는 필요할 때 이 인터페이스를 역방향 호출 합니다. 새 에디터를 지원하려면 이 인터페이스만 구현하면 됩니다.
현재 이 인터페이스를 구현한 클라이언트는:
클라이언트
언어
전송
용도
banya-cli
Go (Bubble Tea TUI)
stdio NDJSON
터미널
banya-agent
Python (FastAPI)
stdio NDJSON
iOS 음성 허브
VS Code 확장
TypeScript
WebSocket JSON-RPC
데스크톱 IDE
JetBrains 플러그인
Kotlin
WebSocket JSON-RPC
IntelliJ/PyCharm/…
빌드 파이프라인
cd banya-core
pnpm install
pnpm run build:core
# → dist/banya-core-darwin-arm64 (단일 실행파일)
echo '{"id":"1","method":"ping"}' | ./dist/banya-core-darwin-arm64
# → {"id":"1","result":{"version":"1.0.0","uptime_ms":X}}
2. Host-Owned LLM: 엔진을 재빌드하지 않고 모델을 바꾸는 법
대부분의 AI 코딩 툴에서 LLM 연결 설정을 바꾸는 일은 여전히 번거롭습니다. API 키, URL, 모델 ID 가 엔진 설정에 묶여 있고, 어떤 툴은 업데이트 없이는 새 provider 를 추가할 수도 없습니다.
banya-framework 는 이 의존성을 뒤집었습니다.
LLM 호출은 호스트(cli/agent)가 소유한다. Core 는 추론이 필요할 때 호스트에 llm.chat RPC 로 콜백한다.
양방향 RPC 흐름
사용자가 메시지 입력 → cli → core: chat.start
core 가 LLM 추론이 필요하다고 판단 → core → cli: llm.chat (콜백)
cli 가 llm-server 로 OpenAI-compatible streaming 호출
토큰이 스트림으로 돌아오면 cli → core: RpcResponse
core 가 tool 실행/오케스트레이션 진행 → content_delta 이벤트
cli TUI 가 점진 렌더링
3. 30개 도구, 세 개의 실행 모드, 그리고 Skills
30개 내장 도구
카테고리
대표 도구
File (10)
create_file , update_file , read_file , glob_files , ripgrep_search …
Terminal (2)
run_command , watch_output
MCP (3)
mcp_tool_call , mcp_resource_list , mcp_resource_read
Agent (5)
spawn_agent , send_message , work_plan …
4. SIBDD — 벤치마크 실패가 엔진 자신을 고친다
여기가 banya-framework 의 가장 특이한 부분입니다. banya-framework 의 agent-evaluation/ 하니스는 벤치마크 실패 로그를 분석하고, 가설을 세우고, 코드를 고치고, 다시 돌리는 루프 자체를 자동화 했습니다. 이름은 SIBDD — Self-Improving Benchmark-Driven Development .
루프 구조
벤치 실패를 룰 기반으로 분류해 Fail Dossier 생성
LLM(Gemini 2.5 Pro)이 verbatim-snippet 프롬프트 를 통해 패치 제안
trial 브랜치에 적용 후 빌드, 그리고 n=5 스모크 + Wilson 95% CI 로 검증
IMPROVED 면 → draft PR 자동 생성 및 fail→pass 번들을 learned skill 로 저장
그 외 판정은 trial 브랜치 자동 롤백
5. 모바일 음성으로 에이전트를 조종하기
banya-agent 는 iOS 앱과 FastAPI 허브로 구성된 모바일 음성 프런트엔드 입니다. 내부적으로는 동일한 core sidecar 를 spawn 합니다. 터미널에서 돌던 에이전트가, 출퇴근길 지하철 안에서 음성 명령 한 줄로 서버에 SSH 해 배포 스크립트를 돌리고 그 결과를 마크다운으로 정리해 보여줍니다.
6. 디자인이 그대로 실행되는 앱이 된다 — vibesynth
vibesynth 는 프롬프트 한 줄이 실제 실행 가능한 React 앱 이 되어 로컬 Vite dev server 로 뜨고, 팝업 윈도우에서 HMR 로 라이브 렌더링됩니다. 보고 있는 것이 바로 빌드 결과물입니다.
왜 Gemini 를 직접 호출하지 않고 banya-cli 를 spawn 하는가?
"banya-core uses its tool-based workflow (write_file, update_file, …) to create or modify files directly on disk over multiple LLM turns — so we're not bound to the ~4k-token single-response limit that ask mode imposes."
설계 결정 요약
결정
무엇을 얻는가
Bun SEA 단일 바이너리
네 개의 프런트엔드가 하나의 엔진을 공유
IDE protocol (27 methods)
core 에 IDE 참조 0건 — 높은 이식성
Host-owned LLM
LLM 백엔드 변경 시 core 재빌드 불필요
SIBDD 루프
벤치마크 실패가 엔진과 skill 양쪽을 자동 개선
vibesynth HMR
디자인과 앱 구현의 실시간 정렬
앞으로
banya-framework 는 "AI 코딩 툴을 어떻게 만들 것인가" 라는 질문을 "AI 코딩 툴이 스스로를 어떻게 개선할 것인가" 로 바꾸려는 시도입니다. 공용 엔진이라는 기반 위에 자기개선 루프를 올려놓은 것이 그 핵심입니다.
터미널에서도, 에디터에서도, 주머니 속의 전화기에서도 — 같은 엔진이 돕니다. 그리고 그 엔진은 벤치마크 실패를 통해 조용히 더 나아지고 있습니다.