며칠 전, Tesla의 전 AI 디렉터이자 OpenAI의 공동 창립자인 Andrej Karpathy는 트윗과 gist를 통해 간단한 아이디어를 게시했습니다. 그것은 LLM (Large Language Models)을 메모리가 없는 검색 시스템으로 사용하는 것이 아니라, 마크다운 (markdown)으로 구조화된 지식 베이스의 능동적인 관리자로 사용하는 것입니다. AI 스스로가 업데이트하며 시간이 지날수록 더욱 가치 있어지는 살아있는 위키 (wiki)와 같은 방식입니다.

« 최근 나의 토큰 처리량 중 상당 부분은 코드를 조작하는 데 쓰이기보다 지식을 조작하는 데 쓰이고 있다. »
— Andrej Karpathy, X에서

이 글을 읽으며 나는 미소를 지었습니다. 이것은 바로 내가 지난 6개월 동안 지원해 온 프로젝트들에 적용해 온 방법이며, 덕분에 나는 2개월 만에 일회용 프로토타입이 아닌 완성된 V1에 가까운 MVP (Minimum Viable Product)를 인도할 수 있습니다.

문제점: 에이전틱 AI (Agentic AI)는 강력하지만 건망증이 있다

2026년의 에이전틱 AI (Agentic AI)는 놀라울 정도로 발전했습니다. 백만 토큰의 컨텍스트 (Context), 에이전틱 모드, 통합 도구 — AI는 인상적인 품질 수준으로 코딩, 리팩토링 (refactor), 감사 (audit), 작성을 수행할 수 있습니다. 하지만 구조적인 결함이 하나 있습니다. 바로 두 세션 사이의 모든 것을 잊어버린다는 점입니다. 6주간의 프로젝트 지원 과정에서 이 결함이 누적된다면, 그것은 조용한 재앙이 될 것입니다.

세션 3에서 AI는 데이터가 매우 관계형(relational)이기 때문에 제가 세션 1에서 제외했던 MongoDB 스택을 다시 제안합니다. 세션 7에서는 우리가 2주 전에 프리미엄(freemium) 모델로 결정했음에도 불구하고 월간 구독 모델을 제안합니다. 세션 12에서는 세션 4에서 내린 결정과 호환되지 않는 인증(auth) 아키텍처를 새로 만들어냅니다. 모든 망각은 시간을 비용으로 치릅니다. 때로는 추론 과정을 재구축하는 데 몇 시간이 걸리고, 종종 며칠간의 개발 작업이 통째로 버려지기도 합니다. 두 달짜리 프로젝트에서 이는 전체 시간의 최대 30%에 달합니다. 해결책은 프롬프트를 더 잘 작성하는 것이 아닙니다. AI에게 진정한 메모리(memory)를 부여하는 것입니다.

해결책: 프로젝트의 메모리로서의 모노레포 (monorepo)

원칙은 한 문장으로 요약됩니다. 코드와 마크다운(markdown)으로 구조화된 문서를 동일한 Git 내에서 함께 버전 관리(versioning)하는 것입니다. 제가 지원하는 프로젝트들의 디렉토리 구조는 다음과 같습니다:

mon-projet/
├── apps/
│   └── app/                      # MVP 코드
...

각 파일은 사람이 읽을 수 있도록 작성되며, 매 세션마다 에이전트(agent)의 컨텍스트(context)로 로드됩니다. 이것은 단순히 보기 좋게 꾸미는 문서화가 아닙니다. AI가 장기적으로 일관성을 유지하기 위한 필수 조건입니다.

왜 별도의 공간이 아닌 모노레포인가

외부 위키(Notion, Confluence)와 Git의 코드를 분리하는 것과, 코드와 문서를 동일한 저장소(repository)에 두는 것 사이에는 근본적인 차이가 있습니다. 첫 번째 경우, 에이전트는 코드는 보지만 비즈니스 로직은 보지 못하거나, 그 반대의 상황이 발생합니다. 매 세션마다 컨텍스트를 제공하기 위해 발췌문을 복사하여 붙여넣어야 하며, 이 과정에서 대부분의 교차 연결(cross-links)을 놓치게 됩니다.

두 번째 경우, 에이전트(agent)는 모든 것을 동시에 봅니다. 제가 체크아웃(checkout) 모듈을 구현해 달라고 요청하면, 에이전트는 docs/prd/checkout.md에 있는 제품 요구 사항 문서(PRD), docs/adr/002-stripe-vs-adyen.md에 있는 아키텍처 결정 기록(ADR), apps/app/에 있는 기존 코드, 그리고 UX가 "바쁜 부모" 페르소나를 겨냥해야 하는지 아니면 "까다로운 미식가" 페르소나를 겨냥해야 하는지 알기 위해 docs/marketing/personas.md에 있는 마케팅 계획을 교차 참조할 수 있습니다. 그 결과: 고립된 상태(silo)가 아니라 전체 컨텍스트를 바탕으로 결정이 내려집니다. 이는 우리가 주니어 개발자나 눈먼 AI에게 흔히 하는 "X를 고려하지 않았잖아"라는 피드백의 80%를 제거해 줍니다.

또 다른 이점은 모든 것이 Git에 버전 관리된다는 점입니다. 모든 결정에는 커밋(commit), 작성자, 날짜가 있습니다. 3주 전에 왜 Postgres 대신 MongoDB를 선택했는지 추적할 수 있고, 되돌리거나(revert), 대안을 테스트하기 위해 브랜치(branch)를 만들 수도 있습니다. Git의 모든 속성이 기업의 메모리에 적용됩니다. 그리고 동료나 첫 기술 채용 인력을 합류시킬 때, 그들은 저장소(repo)를 클론(clone)하여 축적된 모든 메모리를 즉시 상속받습니다. 개발자가 아닌 창업자조차 이 루프에 참여할 수 있습니다. 저는 Notion이나 GitHub 계정 없이도 이 모든 Git 문서를 그의 LLM에 직접 제공할 수 있는 시스템을 구축하여, 그가 나머지 팀원들과 마찬가지로 프로젝트의 메모리를 읽고 편집할 수 있도록 했습니다.

각 프로젝트를 위해 내가 구성하는 전문가 팀

에이전틱 AI(Agentic AI)는 놀라울 정도로 사실적으로 역할을 수행할 수 있습니다. 각자의 전문 분야, 태도, 평가 기준을 가진 가상 전문가 팀을 프로젝트 전담으로 구성할 수 있습니다.

**기술적인 측면 (Côté technique)**에서, 품질 감사 (quality audit)를 위해 저는 한 명의 전문가가 아니라 11명을 동원합니다: Symfony/PHP, React Native/Expo, Go, Next.js/SEO, DevOps/SRE, DBA MongoDB, 모노레포 (monorepo) 아키텍트, 편집증적인 스태프 엔지니어 (Staff Engineer, "운영 환경(prod)에서 무엇이 깨질 것인가" 패턴), 펜테스터 (pentester), i18n 전문가, 기술 제품 관리자 (technical product manager). 각 전문가는 병렬적으로 코드베이스의 자신의 영역을 감사하고, 수치화된 점수가 포함된 구조화된 마크다운 (markdown) 보고서를 생성하며, 이들의 권장 사항은 다음 사이클을 위한 스토리 (stories)가 됩니다. 컨설팅 에이전시가 이와 동일한 횡단적 감사를 수행하는 데 2주와 10,00015,000유로를 쓰는 반면, 11명의 하위 에이전트 (subagents)는 각각 1520분 만에 보고서를 만들어냅니다. 이는 10배 빠른 것이 아니라, 100배에 가깝습니다.

**비즈니스 측면 (Côté business)**에서도 패턴은 동일합니다. 최근 전략적 스트레스 테스트 (stress-test) 전 비즈니스 플랜 (business plan)을 검토하기 위해, 저는 "프리 시드 (pre-seed) 펀드의 시니어 파트너이자 창업자의 친구이며, 어떤 것도 숨기지 않는" 프로필을 동원했습니다. 그 피드백의 품질은 실제 VC (Venture Capital)의 피드백과 맞먹었습니다: 유닛 이코노믹스 (unit economics)의 문제점이 줄 단위로 지적되었고, 재무적 궤적의 불일치가 식별되었으며, 타협 없는 직설적인 어조를 유지했습니다. 이러한 피드백 덕분에 저는 교육용 가상 사례(가상의 가족 식단 계획 앱, "Bouch.ee")에 대한 완전한 서류를 작성할 수 있었습니다 — 비즈니스 플랜 (business plan), 자금 조달 전략 (stratégie de financement), 시드 덱 (deck seed), VC 소개 메일 (mail d'intro VC). 이 결과물들은 실제 펀딩 사례가 아니라, 이 방법론이 만들어내는 결과물의 샘플 역할을 합니다.

제가 정기적으로 활용하는 다른 프로필들로는 B2B 마케팅 전문가, 가격 전략가 (pricing strategist), 시니어 제품 디자이너 (senior product designer), GDPR 준수 전문가, 이용약관(CGU/CGV) 법률 작성가, SEO/GEO 전문가 등이 있습니다. 각 프로필은 docs/experts/에 문서화되어 있어 프로젝트 간에 재사용이 가능하며, 축적된 경험과 함께 더욱 정교해집니다. 이러한 AI 전문가들은 인간을 대체하는 것이 아닙니다. 제가 이용약관 검토를 위해 변호사에게 비용을 지불할 때, 변호사는 백지 상태에서 시작하는 것이 아니라 표준적인 사례의 80%를 커버하는 구조화된 초안 (draft)을 검토하게 됩니다. 이제 막 시작하는 창업자에게 이는 전체 작성 비용 8,000유로와 전문가 검토 비용 1,500유로 사이의 차이를 의미합니다. 이러한 접근 방식의 누적된 경제적 영향은 스프린트 기간 동안 상당해집니다.

결과: 2개월 만에 완성되는 거의 V2 수준의 MVP

이 세 가지 요소 — 동일한 레포지토리(repo) 내의 코드와 문서, 기업 전체의 구조화된 문서화, 온디맨드(on-demand) AI 전문가 팀 — 를 결합하는 것은 단순한 생산성 향상을 넘어선 체제의 변화를 가져옵니다. 제가 참여하는 프로젝트들에서 저는 2개월 만에 기능적으로 프로토타입이라기보다 완성된 V1에 가깝고, 초기 범위(scope)가 잘 설정되었다면 초기 단계의 V2에 가까운 MVP를 인도합니다. 이를 통해 창업자는 제품-시장 적합성 (product-market fit) 검증이 실질적으로 이루어질 수 있을 만큼 충분히 신뢰할 수 있는 버전으로 시장에 제품을 선보일 수 있습니다.

이것을 가능하게 하는 요소는 다음과 같습니다: 각 AI 세션이 과거의 결정을 상속받기 때문에 몇 주가 지나도 드리프트 (drift)가 발생하지 않으며, 에이전트 (agent)가 매 선택 전에 코드와 비즈니스를 체계적으로 교차 검증하므로 오류가 줄어들고, 문제가 쌓이기 전에 거의 매일 문제를 보고하는 감사 (audit)가 이루어지며, 프로젝트에 합류하는 모든 사람에게 즉각적인 정보 전달이 가능합니다. 메모리 모노레포 (memory monorepo)는 단순한 생산성 팁이 아닙니다. 이것은 기업 자산입니다. 즉, 특정 시점에 회사의 거의 모든 기억을 담고 있는 공유 가능한 Git 리포지토리 (repository)입니다. 이 자산은 자금 조달, 채용, 실사 (due diligence), 매각과 같은 구조적인 결정이 내려질 때마다 그 가치가 높아집니다.

Karpathy가 방금 공식화한 것은 여러 실무자가 발전시켜 온 직관입니다. 즉, LLM (Large Language Model)을 대할 때 진정한 레버리지 (leverage)는 프롬프트 (prompt)가 아니라, 모델에게 제공하는 메모리 구조 (memory structure)라는 점입니다. 이제 중요한 질문은 '무엇을 저장할 것인가', '어떻게 조직할 것인가', '어떻게 최신 상태로 유지할 것인가'가 됩니다. 이것이 제가 실제 프로젝트에서 에이전트형 AI를 산업화하기 위한 가이드에 모아둔 모든 것의 토대입니다.

이 방법을 귀하의 프로젝트에 적용하기

이것은 제가 Sprint Fondateur에서 전개하는 접근 방식과 정확히 일치합니다. 2개월 안에, 저는 창업자에게 프로젝트의 살아있는 메모리 — 비즈니스 플랜, 자금 조달 전략, VC 덱 (deck), 상세한 PRD, 배포된 기능적 MVP — 를 포함하는 완전한 모노레포를 전달하여, 투자자에게 발표하고 향후 기술 팀과 함께 확장할 준비를 마칠 수 있도록 합니다.