컴퍼니 브레인 축적하기

1. 1
   2025 · Anthropic · 구조적 노트 작성

   AI가 대화창 밖 파일에 메모를 남겨 지식을 쌓아 두는 기법입니다. 이 실습의 memory/ 폴더가 여기서 나왔습니다. Anthropic 엔지니어링 글

2. 2
   2026-04-04 · Andrej Karpathy · LLM 위키

   원본 문서는 손대지 않습니다. 위키는 사람이 아니라 LLM이 쓰고 유지합니다. 규칙은 따로 파일에 적습니다. 위키를 무너뜨리는 것은 읽고 판단하는 일이 아니라 정리하고 링크를 잇는 잔업입니다. 사람은 그 잔업 때문에 위키를 버립니다. LLM은 지루해하지 않고 상호 참조를 빠뜨리지 않습니다. 카파시의 X 글 · llm-wiki gist 원문

3. 3
   2026-04-05 · Garry Tan · GBrain

   YC 대표가 자기 에이전트가 읽을 기억을 직접 만들어 공개했습니다. 회의와 메일을 계속 넣어 두면, 사람이 보지 않는 사이에도 정리와 병합이 이어집니다. GitHub 저장소

4. 4
   2026년 4월 말 · Y Combinator · Company Brain

   Summer 2026 창업 주제 목록에 이 이름이 올랐습니다. 파트너 Tom Blomfield가 썼습니다. AI 자동화를 막는 것은 이제 모델 성능이 아니라 회사에 흩어진 업무 지식이라는 진단입니다. 그 지식을 모아 구조를 잡고 최신으로 유지해, AI가 실행할 수 있는 스킬 파일로 바꾸는 장치를 회사마다 두자고 제안합니다. 문서 검색이나 챗봇과는 다릅니다. 환불을 어떻게 처리하고 가격 예외를 누가 정하는지까지 담은 회사 작동 방식의 지도입니다. 당시 페이지 아카이브

5. 5
   2026년 · Y Combinator Spring 2026 · Hyper

   제안이 회사로 나왔습니다. 2인 팀이 문서와 캘린더, 메일, 슬랙, 깃허브에서 지식을 끌어모아 회사 지식 베이스를 만들고, 쓰고 있는 AI 도구에 그것을 연결합니다. 내건 한 줄이 자율주행하는 컴퍼니 브레인입니다. YC 런치 페이지

아래 실습은 이 구조를 따릅니다. 회사가 파는 제품을 사는 대신, 폴더와 규칙을 직접 짜서 만든다는 점만 다릅니다.

한 사람이 모으고, 합치고, 답까지 하면 자기가 정리한 걸 그대로 믿습니다. 분류가 틀려도 본인은 모릅니다. 모으는 눈(정리가), 합치는 눈(편집자), 찾아주는 눈(사서)을 나눠 두면, 정리가가 잘못 분류한 걸 편집자가 잡고, 편집자가 빠뜨린 링크를 사서가 잡습니다. 보는 눈이 달라야 중복과 모순이 걸립니다.

우리 팀에는 위 4역할을 그대로 써도 될까? 종이에 한번 적어 보세요. 자료가 적은 팀이라면 정리가와 편집자를 한 스킬로 합쳐도 됩니다. 반대로 부서가 여러 개라면 부서별 사서를 두는 식으로 늘릴 수 있습니다. 우리 지식을 굴리는 데 필요한 손이 빠지지 않으면 됩니다.

책 쓰기 실습은 기획서 하나로 한 번에 완성하는 파이프라인입니다. 컴퍼니 브레인은 계속 도는 루프입니다. 그 루프를 지탱하는 것이 memory/의 처리 이력입니다. 이미 본 파일을 기억해 두지 않으면, 매주 같은 회의록을 또 읽고 위키에 중복으로 쌓입니다. 증분 갱신은 "무엇을 이미 처리했는가"를 기억하는 데서 시작합니다.

규칙 본체는 AGENTS.md에 적습니다. 이 파일은 Claude Code와 Codex가 함께 읽는 표준 파일이라, 한 곳에 써 두면 도구를 바꿔도 같은 규칙이 그대로 적용됩니다. 스킬 4개도 파일 형식(SKILL.md 앞머리에 name과 description)이 같아서, 폴더 위치만 바꿔 옮기면 두 도구가 같은 매뉴얼을 씁니다.

Claude Code는 CLAUDE.md를 먼저 읽습니다. 그래서 그 파일에는 "규칙은 AGENTS.md를 봐"라고 한 줄만 적어 두고, 내용은 AGENTS.md에 몰아 둡니다. 스킬은 .claude/skills/ 아래 이름별 폴더에 넣습니다.

Codex는 AGENTS.md를 직접 읽으므로 진입점 파일이 따로 필요 없습니다. 지금 폴더에서 저장소 루트까지 올라가며 만나는 AGENTS.md를 모두 읽고, 가까운 쪽을 우선합니다. 스킬은 .agents/skills/ 아래 이름별 폴더에 넣습니다.

회사에도 같은 구분이 있습니다. 취업 규칙과 결재 절차는 고정이고, 직원 명부와 프로젝트 현황은 계속 갱신됩니다. 만약 직원이 결재 절차까지 마음대로 바꾼다면 조직이 흔들립니다. 여기서도 같습니다. AGENTS.md와 스킬 파일은 운영 규칙이라 그대로 두고, wiki-config.md가 이 조직의 설정이라 회사마다 바꿔 씁니다. 그래서 같은 하네스를 다른 팀에 그대로 옮길 수 있습니다.

회사 문서로 시작한다면 원본 폴더를 그대로 연결하지 말고 복사본을 만들어 그 폴더를 엽니다. 결과를 확인한 뒤에 원본으로 옮깁니다. 재무 자료나 인사 기록이 섞인 폴더는 연결하지 않습니다.

각 스킬은 memory/의 처리 이력을 먼저 확인합니다. digest 도중 멈춰도, 다시 실행하면 아직 처리 안 한 자료부터 이어서 작업합니다. 이미 본 파일은 다시 읽지 않습니다. 게임의 자동 저장과 같습니다.

위 표를 보면 위키 파일을 직접 고치는 건 편집자뿐입니다. 정리가는 분류만 하고, 사서는 목차만 잇고, 안내데스크는 읽기만 합니다. 본문을 손대는 손을 한 명으로 묶어야 형식과 톤이 흔들리지 않습니다. 사람으로 치면 "검토는 여러 명이 하지만, 위키에 글을 쓰는 사람은 한 명"인 구조입니다. 책 쓰기 실습에서 저자(블랙)만 본문을 고친 것과 같은 원리입니다.

위 여섯 항목과 프롬프트는 사람이 읽고 판단하는 검증입니다. 페이지가 열 장일 때는 됩니다. 쉰 장이 넘으면 눈으로 못 훑습니다. LLM 위키가 lint를 따로 둔 이유가 여기 있습니다. 모순, 낡아 버린 주장, 어디에도 이어지지 않은 페이지, 비어 있는 항목을 기계가 먼저 걸러 낸 다음 사람이 봅니다.

이 실습에는 그 단계가 없습니다. 실습 카드 04번 · 위키 건강검진에서 이어서 만듭니다.

노드를 드래그해 옮기고, 스크롤로 확대·축소합니다. 노드를 클릭하면 연결된 것만 남겨 관계를 좁혀 보고, 더블클릭하면 그 페이지로 바로 들어갑니다. 빈 곳을 클릭하면 전체 그래프로 돌아옵니다. 위 샘플은 블로그 글로 만든 것이지만, 회의록·정책·결정으로 채운 우리 위키에 그대로 적용됩니다.