Framein을 만든 이유

Claude, Codex, Gemini를 오가도 작업 기준은 하나로.

시작은 지저분한 풍경이었다

요즘 내 코딩은 대부분 터미널 에이전트로 한다. VS Code 안에 Claude Code, Codex, Gemini CLI를 나란히 띄워두고. 무슨 거창한 "멀티 에이전트" 꿈 때문이 아니다. 이유는 훨씬 시시하다.

• 기본 구현은 Claude가 잘한다.
• 외부 시선이 필요할 때 — 보안 구멍, 회귀, 어딘가 냄새나는 계획 — Codex가 Claude가 못 잡는 걸 잡는다.
• 결과를 남에게 넘길 때 Gemini의 설명이 더 친절하다.
• 그리고 솔직히, 한쪽이 사용 한도에 걸리면 다른 쪽으로 갈아타며 계속 일한다.

그래서 터미널 세 개를 띄워두고, 내가 그 사이의 통합 레이어가 되어 있었다. 모델을 바꿀 때마다 같은 걸 다시 설명했다. 목표는 이거고, 이건 깨면 안 되고, 직전 모델이 뭘 시도했고 왜 실패했는지. 모델 사이를 채팅 요약으로 복붙하는, 사람으로 된 클립보드였다.

가장 괴로운 건 타이핑이 아니었다. 작업이 경계에서 계속 죽는다는 거였다. 모델을 바꾸는 순간 맥락 — 실제 계약, 실패한 시도들, 결정들, 검증 상태 — 이 사라졌다. 각 모델은 깨끗하고 자신만만하게 다시 시작했고, 나도 처음부터 다시 시작했다.

안 만들 뻔했다

설계를 시작하기 전에 당연히 해야 할 걸 했다. 이미 있는지 찾아봤다. 있었다. 그것도 많이.

CCB, Claude Squad, CC Switch, 점점 커지는 SuperClaude 계열, gstack, Matt Pocock의 스킬팩 — 시장은 이미 붐볐다. 첫 감정은 안도였다가 곧 맥이 빠졌다. 나와 똑같은 고통을 느낀 사람이 이렇게 많고, 이미 여럿이 출시했구나. 냉정하게 보면, 평범한 "멀티 CLI 매니저"를 또 만들면 이 도구들이 다 듣는 그 댓글을 들을 게 뻔했다. "이거 CCB랑 뭐가 달라요?"

그런데 그 질문이 그날 가장 쓸모 있는 사건이었다. CLI 매니저를 만들려는 시도를 멈추고 나서야, 진짜로 비어 있는 게 보였기 때문이다.

통찰: 더 나은 핸드오프를 만들지 말고, 핸드오프를 없애라

내가 본 모든 도구 — 그리고 내 첫 설계 — 는 전환 문제를 더 나은 핸드오프 묶음으로 풀고 있었다. 요약, diff, 테스트 결과를 싸서 다음 모델에 넘기는 것. 나도 똑같은 걸 만들기 직전이었다.

그러다 깨달았다. 핸드오프 그 자체가 버그였다.

세 에이전트가 하나의 공유된 진실원천 — 작업 계약, 결정 기록(ADR), 검증 결과, 리스크 상태 — 을 읽으면, "넘긴다"는 행위가 더 이상 단계가 아니다. 다음 모델은 내가 요약한 사실이 아니라 사실 그 자체를 읽는다. 아무도 뭔가를 넘기는 걸 기억할 필요가 없다. 애초에 분리된 적이 없으니까.

이 재정의가 제품의 전부다. Framein은 세 에이전트를 격자로 띄우는 콕핏이 아니다. 이미 쓰는 에이전트 아래에 하나의 작업 프레임을 두는 얇은 로컬 레이어다. 그래서 작업이 어떤 단일 모델이나 세션보다 오래 산다.

실제로 하는 일

루프는 네 개의 동사다.

start     -> 구현이 흔들리기 전에 요청을 작업 계약으로 고정
challenge -> 가치가 있을 때 다른 모델에게 범위를 좁힌 반론을 요청
capsule   -> 다음 리드가 읽을 사실을 준비: 계약, diff, 검증, ADR, ledger
ship      -> 모델이 "끝났다"고 말하는 게 아니라, 실제 빌드/테스트/리스크 게이트로 닫음

터미널에서 부르거나, Claude/Gemini 안에서 /fr:* 슬래시 명령으로, Codex에서 $fr-* 스킬로 부른다. 밑에서는 같은 엔진, 같은 로컬 상태다. 기존 스킬팩과 페르소나는 그대로 둔다. Framein은 그 아래에 계약·원장·게이트만 깐다.

가장 확신하는 결정들

컴플라이언스가 먼저다. 아니면 출시 안 한다. 2026년 초 Anthropic이 약관을 명확히 하고, 구독 트래픽을 라우팅하거나 자격증명을 모으는 서드파티 도구를 차단하기 시작했다. 이건 넘어야 할 장애물이 아니라 내가 동의하는 설계 경계다. 그래서 Framein은 자격증명을 수집하지 않고, 토큰을 중계하지 않고, 구독을 공유하지 않고, 터미널 입출력을 화면 스크래핑하지 않는다. 요청할 때 공식 CLI를 로컬에서 부를 뿐이고, 인증은 각 CLI가 그대로 갖는다. README의 신뢰 경계는 마케팅이 아니라, 이런 도구가 존재할 자격이 있는지를 가르는 선이다.

결정은 append-only다. ADR은 수정도 삭제도 안 되고, 새 기록으로 대체만 된다. 조용히 고쳐 쓸 수 있는 결정 기록은, 두 번째 모델이나 두 번째 사람이 그걸 믿는 순간 무가치해진다.

런타임 의존성 0. 전체가 Node 22의 내장 node:sqlite와 내장 테스트 러너로 돈다. 네이티브 빌드도, 반년 뒤 설치를 깨뜨릴 의존성 변동도 없다. SQLite store는 로컬 캐시이고, 정본 스냅샷은 git 친화 JSON이다.

한 시점에 한 명만 쓴다. 공유 에이전트 메모리의 진짜 어려움은 공유가 아니라, 두 에이전트가 같은 대상에 대해 일관되지 않은 사실을 쓰는 거다. 그래서 지루하고 안전한 답부터 시작했다. TTL 있는 원자적 write lock. 영리함보다 정확성 먼저.

지금 상태

pre-release v0.0.4. 코어 — store, CLAUDE.md / AGENTS.md / GEMINI.md에 걸친 managed block 투영, 작업 계약, verify/risk/ship 게이트, /fr:*와 $fr-* 래퍼, MCP 서버 — 는 구현되어 있고 240개 이상의 테스트로 다루고 있다.

실행 파일 배포 경로도 실제 검증 단계에 들어왔다. GitHub Actions에서 Windows, Linux, macOS ARM, macOS Intel artifact를 만들고, macOS ARM과 Intel artifact는 CI에서 Developer ID 서명과 공증까지 통과한다. 아직 다듬는 중인 것: SignPath를 통한 Windows Authenticode, 깨끗한 장비에서의 설치 검증, 다중 개발자 워크플로, 공개 npm 릴리스.

이게 당신의 일하는 방식을 바꿀 거라고 주장하지 않는다. 터미널 세 개와 사람 클립보드로 하루를 보내는 게 너무 별로여서 만들었고, 해법은 거창하고 영리한 게 아니라 작고 로컬한 거였다. 두 개 이상의 코딩 에이전트 안에서 산다면, 당신에게도 도움이 되는지 듣고 싶다.

MIT, Frameout에서 만들었다. 이름은 영화 용어다. 프레임아웃은 피사체가 화각을 벗어나 상상의 off-screen 공간에만 존재하게 되는 것. 프레임인은 그걸 다시 들이는 것 — 흩어진 세 에이전트를 실제로 볼 수 있는 하나의 프레임 안으로.

— 구자호, AX Center, 프레임아웃
— 레포·문서: framein.dev