AI 코딩하는 사람 지금 멈춰

“미래가 예측 불가능할 때마다 작동하는 기법을 쓰라. 미래는 언제나 예측 불가능하니까.” 오늘 GeekNews에서 가장 많이 읽힌 글의 마지막 문장입니다. 공교롭게도 오늘 화제에 오른 개발 도구들이 모두 같은 곳을 가리켰습니다. AI 에이전트가 “다 구현했습니다”라고 말할 때, 프레임워크가 “상태는 잘 흐르고 있습니다”라고 말할 때, 우리는 그 자신감을 얼마나 믿어야 할까요. Framein, Foldkit, 그리고 ‘확신의 함정’까지 — 검증 가능한 구조가 자신감을 이기는 하루를 정리했습니다.

Framein, AI 코딩 에이전트 ‘아래’를 노리다

당신이 ‘사람 클립보드’가 되는 순간

개발자 chunbak 님이 오늘(6월 30일) 공개한 Framein의 출발점은 익숙한 풍경입니다. VS Code 안에 Claude Code, Codex, Gemini CLI를 나란히 띄워두고 기본 구현은 Claude에, 보안·회귀 검토는 Codex에 맡기는 식으로 일하다 보면, 모델을 바꿀 때마다 “목표가 무엇인지, 깨뜨리면 안 되는 게 무엇인지, 직전 모델이 뭘 시도하다 실패했는지”를 매번 다시 설명하게 됩니다. 결국 개발자 자신이 세 터미널 사이를 잇는 ‘사람 클립보드’가 되어버린다는 것이죠.

기존 도구들도 많았습니다. 여러 에이전트를 한 창에 띄우는 콕핏(Claude Squad, Orch term류), 한 하네스에서 다른 모델을 부르는 프록시, 역할을 나눠 작업을 분배하는 오케스트레이터까지. 그러나 대부분은 ‘핸드오프를 더 잘하는’ 방향이었습니다. Framein은 정반대를 택했습니다. 핸드오프를 잘하는 대신, 핸드오프 자체가 필요 없게 만드는 것. 새 IDE도, 콕핏도, 프록시도 아닌, 이미 쓰는 에이전트 ‘아래’에 깔리는 얇은 로컬 작업 상태(work-state) 레이어입니다. 세 에이전트가 같은 작업 계약·결정 기록·검증 결과를 repo 안에서 함께 읽기 때문에, 다음 모델은 누군가 요약한 사실이 아니라 사실 그 자체를 읽습니다.

핵심은 네 개의 동사로 도는 루프입니다. 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는 캐시일 뿐 정본은 git 친화 JSON 스냅샷이라 반년 뒤 의존성 변동으로 설치가 깨질 일이 없다는 설명입니다. 현재 pre-release v0.0.6이며 테스트 249개를 통과했고, npm install -g framein(Node 22.5+ 필요), MIT 라이선스로 받을 수 있습니다.

Foldkit, ‘정확성’을 프레임워크로 강제하다

React·Vue가 건드리지 않은 영역

Foldkit는 Effect 위에 구축되고 Elm 아키텍처처럼 설계된 TypeScript 프론트엔드 프레임워크입니다. 핵심 주장은 도발적입니다. React·Vue·Svelte가 ‘렌더링’만 해결한다면, Foldkit는 ‘아키텍처 자체’를 규정한다는 것. 애플리케이션 전체 상태를 하나의 불변 모델로 관리하고 모든 변경이 단일 update 함수를 거쳐 흐르므로, 숨겨진 변형이나 오래된 클로저 없이 예측 가능한 상태가 보장됩니다.

이펙트를 다루는 방식도 다릅니다. 사이드 이펙트를 핸들러 안에 숨긴 명령형 호출 대신, update에서 반환하는 값으로 다루는 ‘명시적 이펙트’ 방식입니다. Command가 무엇을 할지 서술하면 런타임이 언제·어떻게를 처리합니다. 덕분에 50개 파일짜리 앱도 5개 파일 앱과 같은 패턴을 따르는, 복잡도가 늘지 않는 확장성을 내세웁니다. 라우팅, UI 컴포넌트, 필드 검증, 모델 변화 구독, WebSocket 같은 장기 리소스의 생명주기 관리, 부모·자식 메시징(Submodel/OutMessage), Virtual DOM, Story/Scene 테스팅, DevTools(MCP 포함), 크래시 리포팅, HMR까지 별도 라이브러리 없이 하나로 묶어 제공합니다.

다만 대가가 있습니다. 컴포넌트·훅·로컬 상태가 없는 Elm 아키텍처 기반이라 사고방식의 전환이 필요하고, 기존 React 코드베이스에는 점진적 도입이 아니라 재작성이 요구됩니다. 반대로 구조가 명시적이고 예측 가능하다는 점은 LLM 코드 생성과 사람 리뷰 양쪽 모두에 유리하다고 강조합니다. 라이선스는 MIT입니다.

‘확신 점수’는 어떻게 좋은 프로젝트를 죽이는가

RICE를 의심하라

A Smart Bear의 Jason Cohen이 쓴 ‘잃어버린 확신(Lost confidence)’은 우선순위 프레임워크의 급소를 찌릅니다. RICE는 점수 계산식에 확신(Confidence)을 직접 곱해 넣습니다. Score = (Reach × Impact × Confidence) / Effort. RPS도 Reach × Potential × Solution Confidence로 비슷합니다. 문제는 보통 작은 프로젝트엔 확신이 높게, 큰 프로젝트엔 낮게 매겨진다는 점입니다. 확신을 곱하는 순간, 가치를 최대로 전달하는 대형 프로젝트가 체계적으로 밀려납니다. 저자는 “Agile 운동의 핵심 동기 자체가 대형 프로젝트의 성공은 늘 확신이 낮다는 통찰이었다”고 지적합니다.

확신 점수를 믿을 수 없는 이유는 더 있습니다. “30%”가 무엇을 뜻하는지 정의가 모호하고, 매년 소수의 기능만 출시하니 사후 검증할 데이터 자체가 부족하며, 프로젝트는 거의 항상 늦고 기대보다 임팩트가 작습니다. 저자는 Hofstadter의 법칙(“Hofstadter의 법칙을 감안해도 항상 예상보다 오래 걸린다”)까지 끌어옵니다. 답은 확률(probability)이 아니라 불확실성(uncertainty) 영역에 있습니다. 경제학자 Frank Knight가 1921년 정리한 ‘나이트적 불확실성’ 개념처럼, 스타트업의 거의 모든 것은 유의미한 확률을 부여할 수 없습니다. 그러니 질문을 바꿔야 합니다. “어떤 확률 분포에서도 현명한 행동은 무엇인가.”

대안으로 제시되는 기법들이 실용적입니다. (1) 항상 참인 것에 집중하기 — 사용자는 보편적으로 빠른 소프트웨어를 선호하고, SOC 2 같은 컴플라이언스는 흥미롭지 않아도 확실히 가치가 있습니다. (2) 빠른 발견·빠른 회복 — MVP를 넘어선 SLC(Simple·Lovable·Complete)를 만들고, “이 기능은 아직 없습니다, 어떻게 쓰실지 알려주세요”가 뜨는 ‘더미 기능’ 버튼으로 실제 행동 신호를 얻습니다. 저자는 이것이 설문보다 100배 나은 신호라며 “관찰된 행동이 진술된 의도를 이긴다”고 말합니다. (3) 고객 임팩트 — 고객의 최소 51%가 정기적으로 쓰거나, 최소 15%가 선택·유지 이유 상위 3개로 꼽는 기능을 고임팩트로 정의합니다.

압권은 마지막 두 기법입니다. 베팅 포트폴리오는 변동성을 줄이는 대신 최대 상방도 줄입니다. 벤처·엔젤 투자에서 65%가 손실을 보고 약 10%만이 리스크를 정당화할 수익을 낸다는 분포에서, 아웃라이어를 노린다면 포트폴리오가 아니라 올인이 필요합니다. 반대로 비대칭 베팅은 하방이 제한·정량화되고 상방이 큰 베팅을 취합니다. 정확한 확률은 몰라도 베팅의 ‘형태’는 알 수 있기 때문입니다. 핵심 장치는 시작 전에 적어두는 예산, 즉 “엔지니어 2명, 3주, 그 후 멈추고 점검” 같은 타임박스입니다. 타임박스가 곧 제한된 하방인 셈이죠. 확신을 “얼마나 비대칭적인가”로 대체하면, 추정 불가능한 확률 대신 실제로 추정 가능한 두 가지 — 시간·비용 기준 최악과 고객 가치 기준 최선 — 만 물으면 됩니다.

관련 글

• Orch term — AI 코딩 에이전트 여러 개를 한 창에서 조율하는 데스크톱 터미널
• Devflow Native — AI 코딩 에이전트 작업 흐름을 repo 안에 남기는 CLI
• Effect — TypeScript로 강력한 앱 구축을 돕는 라이브러리
• 취향(Taste)이 새로운 10x다
• 우리 직장의 LLM 집단 망상

출처

1. GeekNews — Show GN: Framein, AI 코딩 에이전트 아래의 작업 상태 레이어
2. GeekNews — Foldkit, 정확성을 위한 프론트엔드 프레임워크
3. GeekNews — 잃어버린 확신(Lost confidence)
4. Framein 공식 사이트 (framein.dev)
5. A Smart Bear — Lost confidence (Jason Cohen)