작성처: 프레임아웃 AX Center

하나의 코딩 에이전트로 작업이 끝나는 시대는 지났다. 실무에서는 구현·리뷰·설명에 각각 강한 모델을 번갈아 쓰고, 사용량 한도나 작업 적합도에 따라 모델을 전환한다. 이때 두 가지 문제가 동시에 발생한다. 전환할 때마다 작업의 맥락이 끊기고, 모델이 내놓는 “모든 구현을 완료했다”라는 판단을 다음 단계로 넘기기 전에 검증하기가 점점 어려워진다는 것이다.

프레임아웃 AX Center는 실제 프로젝트에서 Claude Code·Codex·Gemini를 함께 운용하며 이 문제를 반복해서 마주쳤다. 그리고 이를 풀기 위해 Framein을 만들었다.

한 번의 전환, 사라지는 맥락

상황을 그려보자. 한 모델에게 기능을 맡긴다. 목표를 설명하고, 건드리면 안 되는 부분을 일러두고, 몇 번의 시행착오 끝에 동작하는 코드를 얻는다.

그런데 그 모델이 막힌다. 같은 실수를 반복한다. 혹은 사용량 한도에 걸린다. 혹은 이 작업은 다른 모델이 더 낫다는 걸 알게 된다.

그래서 모델을 바꾼다. 그 순간, 앞서 쌓은 것이 사라진다.

목표. 제약. 이미 시도해서 실패한 접근. 검증을 통과한 상태. 내려둔 결정들. 이 모든 것이 모델 경계를 넘지 못한다. 새 모델은 깨끗한 상태에서, 또 자신만만하게 시작한다. 그리고 사람은 같은 설명을 다시 한다.

결국 사람이 모델 사이를 잇는 ‘통합 레이어’가 된다. 대화를 요약해 옮겨 붙이는, 사람으로 된 클립보드. 멀티 에이전트를 쓸수록 이 비용은 줄지 않고, 오히려 늘어난다.

그리고 더 깊은 문제가 하나 더 있다. 모델의 판단을 따져볼 기회가 사라진다는 것이다.

한 모델이 “완료했다”라고 할 때, 그 계획과 변경이 정말 안전한지를 다른 모델이 같은 맥락 위에서 곧바로 따져보게 하려면 어떻게 해야 할까? 지금은 또 새 창을 열고, 프로젝트를 처음부터 설명해야 한다. 너무 번거롭다. 그래서 우리는 대개, 그 검토를 그냥 건너뛴다. 빌드와 테스트가 통과했다는 사실과, “이 접근이 애초에 옳은가”라는 판단은 다른 층위의 문제인데도 말이다.

그래서 프레임아웃이 던진 질문

여러 AI를 함께 쓰는 게 당연해진 시대에, 우리는 이렇게 물었다.

모델 사이의 ‘인계’를 더 잘하게 만드는 게 답일까? 아니면, 인계라는 행위 자체가 문제는 아닐까?

시장의 도구 대부분은 전자를 택했다. 요약과 diff와 테스트 결과를 잘 포장해 다음 모델에 넘기는 — 더 나은 핸드오프 묶음.

프레임아웃은 후자라고 봤다. 넘기지 않으면 된다.

세 에이전트가 각자 맥락을 들고 가는 대신, 하나의 공유된 사실을 함께 읽으면, ‘넘긴다’는 단계가 통째로 사라진다. 다음 모델은 누군가의 요약이 아니라 사실 그 자체를 읽는다. 애초에 분리된 적이 없으니, 인계할 것도 없다.

이 발상에서 나온 것이 Framein이다.

Framein은 ‘새 도구’가 아니다

오해를 먼저 풀어둘 필요가 있다. Framein은 새로운 AI 코딩 도구가 아니다. 여러 모델을 한 화면에 띄워 조종하는 콕핏도 아니다.

그것은 팀이 이미 쓰는 에이전트 아래에 깔리는 얇은 레이어다. Claude를 쓰든, Codex를 쓰든, 무엇이 새로 등장하든, 그 밑에서 작업을 잃지 않게 잡아주는 층.

이 선택에는 이유가 있다. 2026년의 AI 코딩 도구는 몇 달 단위로 새것이 뜨고 진다. 그 경쟁에 또 하나의 도구로 뛰어드는 대신, 프레임아웃은 무엇이 위에 오든 그 아래에 그대로 남을 수 있는 자리를 택했다. 유행을 타지 않는 층은, 유행하는 도구보다 오래간다.

Framein이 저장소 안에 유지하는 ‘작업 프레임’은 네 가지다.

• 작업 계약 — 목표, 완료 기준, 보호할 영역, 하지 말 것
• 결정 기록(ADR) — 추적 가능한 결정 이력. 고쳐 쓸 수 없고, 추가만 된다
• 검증·리스크 상태 — 빌드·테스트 결과와 변경의 민감도
• 캡슐 — 다음 모델이 사실 그대로 이어받도록 압축한 상태

두 가지 다른 ‘검증’

Framein의 작업 흐름은 네 동사로 짧게 요약된다. 시작(start) → 반론(challenge) → 전환 준비(capsule) → 마무리(ship).

여기서 프레임아웃이 분명히 구분한 것이 있다. AI의 “완료했다”를 점검하는 방법은 사실 두 층위로 나뉜다는 점이다. 하나는 판단의 점검이고, 다른 하나는 사실의 점검이다.

판단의 점검 — challenge. 빌드가 통과해도, 접근 자체가 틀렸을 수 있다. challenge는 다른 모델에게 계획·diff·리스크에 대한 반론을 구한다. 단, 새 대화를 열어 다시 설명하는 방식이 아니라, 이미 기록된 사실 위에서 범위를 좁혀 묻는다. “이 계획이 놓친 위험은 무엇인가?” 막힌 모델을 교체하려는 게 아니라, 작업이 살아 있는 동안 두 번째 눈을 들이는 것이다. 결제 콜백처럼 재시도와 멱등성이 얽힌 코드에서는, 테스트가 초록불이어도 설계가 위험할 수 있다. 그럴 때 다른 모델의 날카로운 반론 한 번이, 통과한 테스트보다 더 많은 것을 잡아낸다.

사실의 점검 — verify와 ship. 반면 빌드·테스트가 실제로 통과했는지는 기계가 따져야 한다. verify는 리허설이다. 설정된 빌드/테스트 검사를 돌려 결과를 기록한다. ship은 강제 게이트다. 검증과 리스크 기준을 통과하지 못하면 실패로 처리하고(비정상 종료), 커밋·배포 준비가 됐다고 인정하지 않는다. 모델이 “다 됐다”고 선언하는 것과, 게이트가 실제로 통과되는 것은 전혀 다른 일이다.

이 둘을 분리한 것이 핵심이다. challenge는 방향이 옳은가를 다른 지능에게 묻고, verify/ship은 사실이 맞는가를 기계적으로 강제한다. 그리고 그 모든 단계를 거친 뒤에도, 배포의 최종 결정은 끝까지 사람의 몫으로 남긴다.

지키기로 한 선

기술 선택보다 먼저, 프레임아웃이 분명히 한 것이 있다. 무엇을 하지 않을 것인가이다.

2026년 들어 주요 AI 제공사들은 구독 트래픽을 우회하거나 자격증명을 모으는 도구를 제재해 왔다. 프레임아웃은 이것을 피해야 할 장애물이 아니라, 지켜야 할 선으로 받아들였다.

그래서 Framein은 자격증명을 수집하지 않는다. 토큰을 중계하지 않고, 구독을 공유하지 않으며, 프록시를 두지 않고, 터미널 화면을 몰래 읽지 않는다. Claude도 Codex도 Gemini도, 각자의 공식 인증을 그대로 쓴다. 작업 상태는 전부 사용자의 저장소 안에 머문다. 클라우드로 보내는 것은 없다.

정상적인 범위 안에서, 로컬에서, 투명하게. 멀티 AI 도구가 오래 살아남으려면 반드시 지켜야 할 선이라고 본다.

보이지 않던 비용을 줄이는 일

프레임아웃은 UX에서 출발해 AI 전환으로 영역을 넓혀 온 디지털 에이전시다. 오프라인 AI 개발 환경(AIRGAP Studio), 멀티에이전트 교차검증 분석(APNALYST), 온디바이스 한국어 음성 키보드(ArdusKey)처럼, 현장에서 부딪힌 문제를 자체 제품으로 풀어 온 흐름 위에 Framein이 있다. 공교롭게도 이들은 한 줄기로 이어진다. 데이터를 함부로 밖으로 내보내지 않고, 로컬에서, 검증 가능한 방식으로 — Framein 역시 같은 자리에 선다.

멀티 AI 협업은 이제 실험이 아니라 기본값이다. 매끄러워 보이는 그 협업의 이면에는, 모델이 바뀔 때마다 사람이 손으로 맥락을 나르고, 정작 “이 접근이 옳은가”라는 점검은 조용히 건너뛰는 비용이 숨어 있다. Framein은 그 보이지 않던 비용을, 작업 상태를 저장소에 묶어두는 방식으로 줄이려는 시도다.

“모두 완료되었습니다”라는 한마디를 그냥 믿는 대신, 다른 모델이 같은 맥락 위에서 한 번 더 따져보게 하고(challenge), 빌드와 테스트가 실제로 통과했는지 게이트로 강제하는 것(verify·ship). 그 두 겹의 점검이, 멀티 AI 시대의 신뢰를 만든다고 프레임아웃은 본다.

If harnesses are the engine, Framein is the shared logbook the engines write to.

Framein은 프레임아웃 AX Center가 만든 오픈소스(MIT) 프로젝트입니다. 현재 공개 프리릴리스 단계이며, 프레임아웃의 실제 개발 프로세스에서 검증되며 다듬어지고 있습니다. — https://framein.dev

Where AI Drives UX, FRAMEOUT