요즘 대부분의 코딩을 터미널 에이전트와 함께 하고 있습니다. VS Code 안에 Claude Code, Codex, Gemini CLI를 나란히 띄워두고, 기본 구현은 Claude에 맡기고 보안·회귀처럼 외부 시선이 필요할 때 Codex에게 검토를 시키는 식입니다. 그러다 보니 모델을 바꿀 때마다 목표가 무엇인지, 깨뜨리면 안 되는 게 무엇인지, 직전 모델이 뭘 시도하다 실패했는지를 매번 다시 설명하고 있었습니다. 결국 제가 세 터미널 사이를 잇는 사람 클립보드가 되어 있더군요.
비슷한 도구를 찾아보니 이미 많았습니다. 여러 에이전트를 한 창에 띄우는 콕핏(Claude Squad, Orch term류), 한 하네스에서 다른 모델을 부르게 해주는 프록시(opencodex, oh-my-free-models류), 역할을 나눠 작업을 분배하는 오케스트레이터(Oh My OpenCode류)까지요. 그런데 정작 제가 겪던 문제 - 모델을 바꿔도 작업 자체가 끊기지 않게 하는 것. 이걸 정면으로 다루는 건 의외로 적었습니다. 대부분 "핸드오프를 더 잘하는" 방향이었습니다.
Framein은 핸드오프를 더 잘하는 대신, 핸드오프가 따로 필요 없게 만드는 쪽을 택했습니다. 새 IDE도, 콕핏도, 프록시도, 또 하나의 하네스도 아닙니다. 이미 쓰는 에이전트 아래에 깔리는 얇은 로컬 작업 상태(work-state) 레이어입니다. 세 에이전트가 같은 작업 계약·결정 기록·검증 결과를 repo 안에서 함께 읽기 때문에, "넘긴다"는 행위 자체가 별도 단계가 아니게 됩니다. 다음 모델은 제가 요약한 사실이 아니라 사실 그 자체를 읽습니다.
루프는 네 개의 동사입니다. 여기서 '리드(lead)'는 지금 실제 구현을 맡고 있는 모델을 가리킵니다. 리뷰를 맡는 모델과 구분하기 위한 표현입니다.
- start : 구현이 흔들리기 전에 요청을 작업 계약(목표·인수 조건·보호 영역·non-goal)으로 고정합니다.
- challenge : 다른 모델에게 범위가 좁은 반론을 요청하고, 리드가 한 번만 응답하게 한 뒤 제가 결정합니다. 한 모델이 자신 있게 "구현을 모두 완료했습니다"고 말할 때, 같은 계약과 diff를 읽은 다른 모델이 "이 계획에서 빠진 위험은 무엇인가"를 물어봐 주는 자리입니다.
- capsule : 다음 리드가 읽을 사실(계약·diff·검증·ADR·ledger)을 준비합니다.
- ship : 모델이 "끝났다"고 말하는 게 아니라, 실제 빌드/테스트/리스크 게이트로 작업을 닫습니다.
터미널에서 바로 호출할 수도 있고, Claude/Gemini 안에서는 /fr:* 슬래시 명령으로, Codex에서는 $fr-* 스킬로 부를 수 있습니다. 어느 쪽에서 부르든 같은 로컬 엔진과 같은 상태를 읽고 씁니다. 기존 하네스·스킬팩·페르소나는 그대로 두고, 그 아래에 계약·원장·게이트만 깔아주는 구조입니다.
설계에서 특히 신경 쓴 부분입니다.
- 결정 기록(ADR)은 append-only입니다. 수정·삭제 없이 새 기록으로 대체만 합니다. 조용히 고쳐 쓸 수 있는 결정 기록은 두 번째 모델이 그걸 믿는 순간 무가치해진다고 봤습니다.
- 자격증명을 수집하지 않습니다. 토큰 중계도, 구독 풀링도, 터미널 입출력 스크래핑도 하지 않습니다. 인증은 각 공식 CLI가 그대로 갖고, 필요할 때 로컬에서 호출만 합니다. (그래서 프록시 계열과는 다른 층입니다.)
- 런타임 의존성이 0입니다. Node 22의 내장 node:sqlite와 내장 테스트 러너만 씁니다. SQLite store는 캐시이고 정본은 git 친화 JSON 스냅샷이라, 반년 뒤 의존성 변동으로 설치가 깨질 일이 없습니다.
현재 pre-release v0.0.6이고, 코어(store, CLAUDE.md/AGENTS.md/GEMINI.md 투영, 작업 계약, verify/risk/ship 게이트, /fr:·$fr- 래퍼, MCP 서버)까지 구현되어 있고, 테스트 249개를 통과한 상태입니다. 아직 다듬는 중인 것은 Windows 코드 서명 경로, 서명·공증된 실행 파일 배포, 깨끗한 장비에서의 설치 검증, 다중 개발자 워크플로입니다.
npm install -g framein으로 설치할 수 있고(Node 22.5+ 필요), MIT 라이선스입니다. 이름은 영화 용어에서 따왔습니다. 피사체가 화각 밖으로 사라지는 게 프레임아웃, 그걸 다시 화면 안으로 들이는 게 프레임인입니다. 흩어진 세 에이전트를 하나의 프레임 안으로 들인다는 뜻으로 지었습니다.
콕핏·프록시·하네스를 이미 쓰고 계신 분이라도, 그 아래에서 작업 상태가 자꾸 새는 느낌을 받으셨다면, 또는 코딩 에이전트 두 개 이상을 오가며 일하고 계시다면, Framein이 그 빈칸을 메우는지 피드백을 받고 싶습니다.
웹사이트 : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
개발자 노트(왜 만들었나) : https://www.framein.dev/ko/why