AI 코딩 에이전트의 가장 큰 병목은 속도가 아니다. 맥락 망각이다. 새 세션을 열 때마다 프로젝트 구조를 다시 설명하고, 이미 시도해서 실패한 방법을 AI가 다시 제안하는 상황을 겪어봤다면, 이건 도구의 성능 문제가 아니라 구조의 부재다. 그리고 바로 그 지점을 정면으로 겨냥한 오픈소스 프로젝트가 dev.to에서 주목받고 있다.
금붕어 AI를 벗어나는 방법: CtxNest의 3단 구조
CtxNest는 AI 코딩 에이전트에 Brain·Hands·Eyes라는 세 개의 레이어를 붙이는 로컬 MCP 기반 시스템이다. 클라우드도 없고, 서브스크립션도 없고, 코드베이스가 외부로 나가지 않는다. 전체 루프가 내 머신 위에서 돈다.
- Brain: FTS5 풀텍스트 검색과 git 버전 관리를 갖춘 마크다운 지식 저장소. 프로젝트 표준, 아키텍처 결정, 과거 시도 이력이 여기에 누적된다.
- Hands:
ctxnest.json에 선언한 명령만 MCP 툴로 노출하는 샌드박스 실행 레이어. 쉘 탈출 없고, 작업 디렉터리 이탈 없고, 사람 승인 옵션도 있다. - Eyes: 실행 결과를 읽고, Brain의 diff 인식 쿼리로 변화를 관찰하며,
journal_append로 학습 내용을 다시 Brain에 기록하는 피드백 루프.
핵심은 마지막 화살표, Eyes → Brain이다. 에이전트가 한 일을 스스로 문서화하고, 다음 세션이 그 노트를 찾아 시작한다. 루프가 돌수록 에이전트는 점점 더 많은 맥락 위에서 판단한다. 단순한 자동완성 도구가 아니라, 프로젝트 히스토리를 내재화한 동반자에 가까워진다.
이 구조가 빌드 속도를 어떻게 바꾸는가
7시간 단일 스프린트로 풀스택 에이전시 OS를 완성한 사례(RevOs 빌드)는 이 맥락에서 다시 읽어야 의미가 살아난다. React + TypeScript + Drizzle ORM + Neon + Cloudflare Pages로 10개 CRUD 모듈을 단독으로 완성한 그 속도는, 단순히 "AI가 코드를 빠르게 써줘서"가 아니다. 개발자가 매 결정마다 맥락을 다시 설명하지 않아도 될 때—즉, AI가 프로젝트의 스택 선택, 인증 전략, 배포 구조를 이미 알고 있는 상태에서 시작할 때—실질적인 속도가 나온다.
CtxNest의 Brain이 바로 그 전제 조건을 만든다. "이 프로젝트는 Drizzle을 쓰고, Clerk는 development instance로 유지하며, CORS는 Cloudflare Pages origin으로 고정한다"는 결정이 한번 기록되면, 다음 세션의 에이전트는 그 결정 위에서 출발한다. 같은 질문을 두 번 하지 않아도 된다.
기존 에이전트 도구와의 구조적 차이
Claude Code, Cursor, Windsurf는 모두 실행 능력은 있다. 하지만 CtxNest가 지적하는 공백은 명확하다: 프로젝트 지식 베이스가 없고, 크로스 프로젝트 맥락이 없고, 커맨드 표면을 개발자가 직접 설계할 수 없다. 실행은 이미 상품화됐다. 차별점은 실행을 감싸는 구조—누적되는 기억, 통제된 권한, 관찰 가능한 피드백—에서 나온다.
로컬 SQLite FTS5를 쓰는 결정도 눈여겨볼 지점이다. 벡터 임베딩 기반 검색은 클래스명·함수 시그니처처럼 결정론적 정확도가 중요한 코드베이스 쿼리에서 할루시네이션 리스크를 품는다. FTS5는 느릴 수 있지만 예측 가능하다. 에이전트가 "지난달 인증 관련해서 어떤 결정을 했지?"라고 물었을 때 엉뚱한 파일을 가져오지 않는다.
실전 시사점: 지금 당장 적용 가능한 것
CtxNest 자체를 도입하지 않더라도, 이 아키텍처가 던지는 질문은 모든 AI 워크플로우에 유효하다.
첫째, Brain에 해당하는 레이어를 어떻게 관리하고 있는가? MEMORY.md든, Notion이든, CtxNest의 knowledge vault든—에이전트가 참조할 수 있는 구조화된 맥락 저장소가 없으면 세션마다 리셋이 반복된다.
둘째, Hands에 해당하는 명령 표면을 누가 설계하는가? AI가 실행할 수 있는 것의 범위를 개발자가 명시적으로 선언하지 않으면, 에이전트는 매번 즉흥적으로 판단한다. 그 즉흥성이 쌓이면 재현 불가능한 실행 히스토리가 된다.
셋째, Eyes—피드백 루프가 닫혀 있는가? 에이전트가 실행한 결과가 다음 세션의 입력으로 연결되지 않으면, 매번 같은 실수를 반복하는 구조다.
전망: 빌드 속도의 진짜 레버는 '기억 설계'다
빠른 프로토타이핑 → 사용자 검증 → 고도화 흐름에서 AI가 실질적인 가속을 만들려면, 각 단계의 결정과 학습이 다음 단계로 이월되어야 한다. 지금까지의 AI 코딩 도구 논의는 "얼마나 빠르게 코드를 생성하는가"에 집중했다. 하지만 CtxNest가 보여주는 방향은 다르다: 얼마나 잘 기억하고, 얼마나 통제 가능하게 행동하며, 얼마나 정확하게 관찰하는가.
7시간 풀스택 빌드가 가능했던 진짜 이유는 LLM의 코드 생성 능력이 아니라, 개발자가 AI와 협업하는 구조를 먼저 설계했기 때문이다. Brain·Hands·Eyes는 그 구조를 명시적으로 만드는 하나의 구현이다. 도구보다 구조가 먼저다—그리고 그 구조의 핵심은 결국 기억이다.