2026년 4월, 일주일 사이에 두 가지 사건이 크게 화제가 됐습니다.

Andrej Karpathy는 Obsidian으로 LLM 지식 베이스를 만드는 방법을 공유했고, 그 글은 빠르게 퍼졌습니다. 비슷한 시기에 Stripe의 Minions는 주 1,300개 이상의 PR을 에이전트가 작성하고 머지하고 있다는 점으로 계속 주목받았습니다.

겉으로 보면 다른 이야기처럼 보이지만, 두 사례는 같은 진실을 가리킵니다.

에이전트의 성능을 결정하는 것은 모델이 아니라 맥락입니다.

Karpathy가 보여준 것: 지식은 구조화되어야 합니다

Karpathy의 시스템은 단순합니다. raw/ 폴더에 원본을 넣고, LLM이 그것을 위키처럼 컴파일합니다. 벡터 DB도 없고, 복잡한 RAG 파이프라인도 없습니다. 마크다운과 grep만으로도 충분하다는 관점입니다.

그의 핵심 비유는 이렇습니다. Obsidian은 IDE이고, LLM은 프로그래머이며, 위키는 코드베이스입니다.

이 방식이 통하는 이유는 LLM이 직접 지식을 구조화했기 때문입니다. 자기가 정리한 구조이기 때문에 어디에 무엇이 있는지 더 잘 다룹니다. 검색보다 이해가 먼저인 시스템입니다.

하지만 한계도 분명합니다.

Karpathy의 시스템은 혼자 연구하는 사람에게는 매우 강력한 도구입니다. 하지만 현실의 대부분은 팀으로 일합니다.

Stripe Minions가 증명한 것: 맥락은 인프라입니다

Stripe의 Minions는 다른 방향에서 같은 사실을 보여줍니다.

Minions가 주 1,300개 PR을 만들어내는 이유는 단순히 모델이 더 좋아서가 아닙니다. Stripe가 수년에 걸쳐 만든 조직 인프라가 있기 때문입니다. devbox, 500개 이상의 내부 도구, 300만 개의 테스트 스위트, 블루프린트 아키텍처가 모두 에이전트에게 "Stripe답게 코드를 짜는 맥락"을 제공합니다.

ByteByteGo의 분석도 핵심을 잘 짚었습니다. "AI 코딩 도구는 빠르고 유능하지만 완전히 맥락 맹목적이다"라는 지적입니다.

에이전트가 아무리 똑똑해도 아래를 모르면 결과가 흔들립니다.

Stripe는 이 문제를 수년의 엔지니어링 투자로 풀었습니다. 하지만 대부분의 팀은 그렇게 할 수 없습니다.

보통의 팀에게 필요한 것은 무엇인가

두 사례를 나란히 놓으면 필요한 조건이 분명해집니다.

관점Karpathy (Obsidian)Stripe (Minions)팀에 필요한 것
지식 구조화LLM이 위키 컴파일내부 도구 + 블루프린트자동 구조화
에이전트 접근로컬 파일 중심내부 인프라 연동프로토콜 레벨 접근
팀 공유1인용조직 전체팀 지식 공간
구축 비용낮음매우 높음합리적 비용
단위문서코드베이스Atom

핵심은 이것입니다.

에이전트에게 팀 맥락을 주는 인프라는 필요합니다. 하지만 Stripe처럼 수년을 투자할 수는 없습니다.

이 지점이 Norfolk와 Nexus가 필요한 이유입니다.

Norfolk + Nexus: 팀의 에이전트에게 기억을 주는 인프라

Norfolk: 팀의 지식이 쌓이는 곳

Norfolk는 개인 지식 관리 도구로 시작했지만, 본질은 에이전트가 참조할 수 있는 형태로 지식을 구조화하는 시스템입니다.

Karpathy의 raw/ -> wiki 흐름과 비슷하지만, 차이는 분명합니다.

1. Atom 단위

Karpathy의 시스템이 문서 단위라면 Norfolk는 Atom 단위까지 쪼갭니다. Atom은 검색하고, 조합하고, 다른 Atom과 연결할 수 있는 최소 지식 단위입니다.

에이전트 입장에서 "문서 전체가 아니라 이 문서의 세 번째 인사이트만 가져와"가 가능하냐는 차이가 큽니다. 파일 단위에서는 다시 읽고 요약해야 하지만, Atom 단위에서는 직접 참조가 됩니다.

2. Citation Graph

어떤 결론이 어떤 Atom을 근거로 만들어졌는지를 시스템 차원에서 추적합니다. 지식의 출처와 계보를 남기는 구조입니다.

3. 팀 공간

Norfolk 팀 플랜에서는 팀원들의 Atom이 공유 공간에 모입니다. 개인 Atom과 팀 Atom의 경계가 있고, 에이전트는 권한에 따라 팀 지식을 recall할 수 있습니다.

Norfolk 플랜 구성은 다음과 같습니다.

Nexus: 에이전트가 기억을 읽고 쓰는 프로토콜 인프라

Nexus는 Norfolk에 쌓인 지식을 에이전트가 실제로 사용할 수 있게 하는 레이어입니다.

AMCP, Agent Memory Continuity Protocol을 통해 Claude Code든, 커스텀 에이전트든, 다른 런타임이든 팀 메모리를 recall할 수 있습니다. MCP가 에이전트에게 도구를 주고, A2A가 에이전트 간 협업을 가능하게 한다면, AMCP는 에이전트에게 기억을 줍니다.

Nexus 플랜 구성은 다음과 같습니다.

팀 플랜이 만드는 실제 시나리오

시나리오 1: 신입 개발자의 첫날

신입이 Claude Code를 열고 "우리 팀 API 설계 원칙이 뭐예요?"라고 묻습니다.

그러면 Nexus가 Norfolk 팀 공간에서 관련 Atom을 recall합니다. 예를 들어 아래 같은 맥락이 즉시 전달됩니다.

Obsidian만 있었다면 "이 볼트 클론 받아서 읽어보세요"가 됩니다. Stripe 수준의 내부 시스템이라면 먼저 거대한 내부 도구부터 익혀야 합니다. Norfolk + Nexus라면 에이전트가 이미 알고 시작합니다.

시나리오 2: 팀의 에이전트 간 지식 전파

팀원 A의 에이전트가 프로덕션 이슈를 디버깅하면서 중요한 인사이트를 발견하고 Nexus에 저장합니다. 다음 날 팀원 B의 에이전트가 비슷한 문제를 만나면, AMCP를 통해 그 인사이트를 바로 recall합니다.

이것은 Slack에 "참고로 이거 발견했어요"라고 남기는 것과 본질적으로 다릅니다. Slack 메시지는 에이전트가 바로 쓰기 어렵지만, Atom은 에이전트가 곧바로 사용할 수 있는 형태입니다.

시나리오 3: 조직 지식의 자동 컴파일

팀원 다섯 명이 일하면서 만든 Atom이 Norfolk 팀 공간에 쌓입니다. Karpathy가 혼자 하던 위키 컴파일을 팀 스케일로 올리는 셈입니다.

파일 단위에서는 충돌이 나기 쉽지만, Atom 단위에서는 합성이 가능합니다.

Obsidian과 경쟁하려는 것이 아닙니다

Norfolk는 Obsidian의 대체재가 아닙니다. Obsidian은 여전히 개인 사고의 도구로 훌륭합니다.

다만 Obsidian의 마크다운 파일은 사람이 읽기 위한 형태입니다. Norfolk의 Atom은 에이전트가 쓰기 위한 형태입니다. 그리고 Nexus의 AMCP는 그 Atom을 어떤 에이전트든 접근할 수 있게 만드는 프로토콜입니다.

Karpathy도 에이전트가 지식 베이스를 쌓고, 그 지식 베이스가 다시 문제 해결 능력을 높이는 루프를 이야기했습니다. 우리가 하려는 일은 그 구조를 팀 레벨로 올리는 것입니다.

Stripe를 부러워하지 않아도 됩니다

Stripe는 수년의 투자로 에이전트에게 조직 맥락을 줬습니다. 하지만 대부분의 팀은 그런 투자를 할 수 없습니다.

Norfolk + Nexus 팀 플랜은 합리적인 비용으로 에이전트에게 팀 기억을 주는 빠른 경로입니다.

Stripe가 보여준 원리, 즉 "에이전트 성능의 차이는 모델이 아니라 맥락이 만든다"는 사실을 500명 조직이 아니라 3명 팀에서도 실현할 수 있게 합니다.

에이전트 시대의 팀 경쟁력은 결국 이것으로 갈립니다. 어떤 모델을 쓰느냐보다, 에이전트에게 어떤 기억을 줄 수 있느냐가 더 중요합니다.

시작하기

이 글은 Nunchi AI의 인디해커 홍보 실험기 시리즈의 일부입니다.