우리는 라벨만 바꾼 게 아닙니다. Norfolk가 무엇인지 자체를 바꿨습니다.

---

한동안 Norfolk는 설명하기 쉬웠습니다. 노트 앱. 뭔가를 저장하고, 정리하고, 나중에 다시 찾는 도구. 간단했죠.

그 설명은 유용했습니다. 하지만 불완전했습니다.

우리가 만드는 동안 Norfolk는 조용히 다른 것이 되었기 때문입니다. 에이전트가 provenance, scope, structure를 가진 메모리를 읽고, recall하고, 쓰는 장소.

"노트와 대화하기"가 아닙니다. 폴더 위에 얹은 RAG도 아닙니다.

하나의 memory surface입니다.

예전 질문이 틀렸습니다

Norfolk가 그저 "노트 앱"이던 시절, 당연한 질문은 이거였습니다. 왜 Obsidian이 아니고, 왜 Notion이 아닌가?

타당한 질문입니다. 하지만 프레이밍이 틀렸습니다.

Norfolk는 더 좋은 에디터가 되는 방식으로 이기려는 제품이 아닙니다. Norfolk의 장점은 캡처 이후에 일어나는 일에 있습니다.

스크린샷, PDF, 거친 메모, 링크, 아직 형태도 안 잡힌 생각을 떨어뜨려 넣습니다. 그 부분은 어떤 노트 앱과도 비슷하게 느껴집니다. 하지만 그 재료는 그냥 거기 앉아 있지 않습니다. Recall 가능한 맥락이 됩니다. 에이전트가 그것을 찾고, 인용하고, 그 위에 쌓을 수 있습니다.

노트가 working memory가 됩니다.

그게 차이입니다. 그리고 우리는 그걸 더 일찍 말했어야 했습니다.

실제로 바뀐 것

이제 두 개의 사용자 경로가 분명해졌습니다.

Personal Norfolk — 당신의 에이전트가 Norfolk 공간을 직접 읽고 쓸 수 있습니다. 노트가 AI 워크플로우와 분리된 섬으로 남지 않습니다. 코딩 에이전트, 리서치 에이전트, 업무 보조 에이전트가 Norfolk를 맥락으로 쓸 수 있습니다.

하지만 cross-recall은 꺼져 있습니다. 개인 플랜에서는 Norfolk와 Nexus가 하나의 검색 표면으로 합쳐지지 않습니다. 에이전트는 Norfolk와 함께 일하지만, 각 저장소는 따로 남아 있습니다. 어느 쪽과 대화할지 당신이 고릅니다.

의도적인 결정입니다. 직접 연결이지, 완전한 공유 인프라는 아닙니다.

Nunchi Team ($29/month) — 흥미로운 건 여기서부터입니다.

Norfolk와 Nexus가 하나의 recall surface가 됩니다. 사람이 Norfolk에 남긴 것과 에이전트가 Nexus에 기억한 것을 함께 검색할 수 있습니다. 쿼터도 공유하고, recall도 공유합니다. 둘을 합쳐 120,000 MU입니다.

왜 중요할까요? 팀은 더 좋은 모델이 없어서 실패하지 않습니다. 사람도 에이전트도 모두 같은 맥락을 매번 처음부터 다시 만들기 때문에 실패합니다. PM은 Norfolk에 결정을 적어뒀는데, 개발자의 코딩 에이전트는 그게 있는지도 모릅니다. 그래서 개발자가 슬랙에 다시 묻습니다. 아니면 더 나쁘게는, 에이전트가 추측합니다.

Team memory는 그걸 고칩니다. 한 번의 recall 호출로 두 저장소를 함께 찾고, provenance도 유지됩니다.

그 뒤에 있는 아키텍처

이렇게 생각하시면 됩니다.

Nexus는 agent memory layer입니다. 세션, 결정, 작업 히스토리, 실행 맥락. 에이전트가 기억하는 것입니다.

Norfolk는 human knowledge layer입니다. 노트, 문서, 리서치, 업로드, 남겨둘 가치가 있는 에이전트 출력. 팀이 아는 것입니다.

AMCP는 어떤 에이전트든 같은 인터페이스, recall, remember, sessions, export로 두 저장소 중 하나와 일할 수 있게 해주는 프로토콜입니다.

Claude Code / Cowork / Your Agent
              ↓
       AMCP-MCP Server
              ↓
        Policy Layer
         ├── Nexus   (remembering)
         └── Norfolk (knowing)

에이전트는 저장 방식의 디테일을 알 필요가 없습니다. recall을 target과 함께 호출하면 됩니다. 서버가 routing, scope, access control을 처리합니다. 팀 플랜에서는 target=auto가 두 저장소를 모두 검색하고 source 태그가 붙은 결과를 돌려줍니다.

모든 결과에는 provenance가 붙습니다. 누가 만들었는지(사람인지 에이전트인지), 어느 저장소에서 왔는지, 어느 세션에 속하는지. 무엇이 인간의 결정이고 무엇이 에이전트의 작업 메모인지 애매하지 않습니다.

왜 그냥 위키가 아니고, 왜 그냥 파일이 아닌가

지금 인기 있는 아이디어가 있습니다. AI에게 마크다운 파일 폴더를 주고 위키를 유지하게 하자는 생각입니다. 소스를 읽고, 페이지를 업데이트하고, 교차 참조하게 하는 방식입니다.

통찰 자체는 맞습니다. 지식은 매 세션마다 다시 시작하는 게 아니라 복리처럼 쌓여야 합니다. RAG는 원금을 돌려주고, 위키는 이자를 줍니다.

하지만 파일 기반 위키는 빨리 한계에 닿습니다.

파일이 수백 개가 되면 에이전트는 어떤 파일을 읽어야 하는지 알기 위해 인덱스 파일이 필요합니다. 그 인덱스도 관리가 필요합니다. 인덱스가 어긋나기 시작하면 위키 전체가 불신뢰해집니다. 유지비를 줄이려 시스템을 만들었는데, 돌아온 건... 또 하나의 유지보수 문제입니다.

그보다 더 어려운 질문은 그 다음입니다. 두 에이전트가 같은 지식을 공유할 수 있는가? 한 팀원의 노트가 다른 팀원의 에이전트에게 recall 가능해질 수 있는가? 어떤 지식이 사람이 쓴 건지, 에이전트가 생성한 건지 구분할 수 있는가?

파일은 그런 질문에 답하지 못합니다. 프로토콜은 답할 수 있습니다.

그래서 메모리는 폴더가 아니라 인프라여야 합니다.

우리가 생각하는 메모리

많은 AI 제품이 메모리를 모호하게 설명합니다. 채팅 기록, 폴더와 태그, 하니스 안에 숨겨 붙여둔 retrieval, 혹은 모델 자체의 기능처럼.

우리는 메모리에 더 날카로운 속성이 필요하다고 봅니다.

메모리는 세션보다 오래 살아야 합니다. 탭을 닫거나 런타임을 재시작하면 사라지는 건 메모리가 아니라 임시 컨텍스트입니다.

메모리는 provenance를 가져야 합니다. 에이전트는 무엇이 기억되었는지만이 아니라, 그것이 어디서 왔고, 누가 만들었고, 어떤 scope에 속하는지 알아야 합니다.

메모리는 둘 이상의 행위자가 쓸 수 있어야 합니다. 인간의 노트가 인간 전용 UI에 갇히면 안 됩니다. 에이전트의 메모리도 특정 벤더의 런타임 안에 잠기면 안 됩니다.

메모리는 portable해야 합니다. 모델은 좋아지고, 하니스는 바뀌고, 벤더도 바뀝니다. 메모리는 그 모든 변화를 통과해 살아남아야 합니다. 그래서 AMCP가 열린 프로토콜로 존재합니다. 메모리가 어떤 단일 도구에 결합되지 않게 하기 위해서입니다.

Norfolk는 여전히 노트 앱입니다

그렇다고 Norfolk가 쓰기 쉬운 도구이기를 포기한다는 뜻은 아닙니다.

오히려 반대입니다. 이제는 인간 쪽 메모리가 자연스럽게 유지되어야 하기 때문에, 캡처 경험이 더 중요해졌습니다.

사람은 스키마로 시작하지 않습니다. 스크린샷으로 시작합니다. 거친 생각 하나, 너무 이른 시점에 저장된 링크 하나로 시작합니다.

그냥 넣으세요. 구조를 강요하지 마세요. 인간을 데이터베이스 관리자로 만들지 마세요.

Norfolk는 앞단에서는 계속 단순하게 남습니다. 하지만 그 캡처된 재료가 백엔드에서 가지는 의미는 훨씬 커졌습니다. 노트로 시작한 것이 recall 가능한 맥락이 될 수 있고, 개인 캡처로 시작한 것이 나중에는 agent workflow에 참여할 수 있습니다.

우리는 노트에서 멀어지는 게 아닙니다. 노트에 더 큰 일을 맡기고 있습니다.

그래서 사용자에게는 어떻게 보이냐

사용자 관점에서는 이야기가 이제 더 깔끔합니다.

업계는 계속 어떤 모델이 이길지를 묻고 있습니다. 우리는 그 질문이 자주 틀렸다고 생각합니다.

모델은 계속 좋아질 겁니다. 더 오래 중요한 건 메모리가 그 변화들을 통과해 살아남느냐입니다.

우리가 만드는 게 바로 그겁니다.

---

Norfolk는 Nunchi AI 메모리 인프라의 일부입니다. nunchiai.com에서 확인해보세요.