컴퍼니 브레인: 무엇이고 AI 에이전트를 위해 어떻게 만드는지

컴퍼니 브레인(company brain)은 회사가 일하는 방식을 글로 남긴 공유 기억이에요. 결정, 정의, 프로세스, 고객, 배운 점을 최신 상태로 구조 있게 정리해서, 사람과 AI 에이전트가 모두 찾고 읽고 믿을 수 있게 해요.

“여기서 활성 고객은 어떻게 세나요?”, “무료 요금제는 왜 없앴죠?”, “결제 내보내기는 누가 맡고 있나요?” 같은 질문에 대한 답이에요. 이런 답은 보통 누군가의 머릿속, 지난봄의 채팅 스레드, 서로 말이 다른 위키 페이지 세 곳에 흩어져 있어요. 컴퍼니 브레인은 지금 유효한 답 하나를 한곳에 두고, 그 답이 어디서 왔는지도 기록해요.

컴퍼니 브레인이 아닌 것도 몇 가지 있어요.

• 모델이 아니에요. 브레인은 지식 그 자체예요. 그 지식으로 질문에 답하는 챗봇이나 에이전트는 그 위에 얹힌 인터페이스예요.
• 모든 걸 쌓아 둔 더미가 아니에요. 이메일과 채팅 메시지를 전부 색인하면 검색은 생기지만 기억은 생기지 않아요. 브레인에는 걸러 낸 결과가 들어가요. 결정에 이르기까지 오간 메시지 200개가 아니라 그 결정 자체요.
• 개인 노트 앱이 아니에요. 세컨드 브레인(second brain)은 한 사람의 생각을 돕는 도구예요. 컴퍼니 브레인은 함께 쓰는 것이라서, 빨리 적는 것보다 정확성, 담당자, 검토가 더 중요해요.

회사들은 위키가 생긴 이래로 늘 단 하나의 정답 출처를 원했어요. 달라진 건 그걸 누가 읽느냐예요. 이제 AI 에이전트가 코드를 쓰고, 고객에게 답하고, 보고서 초안을 만들고, 분석을 돌려요. 그리고 모두 일을 잘하려면 회사의 맥락이 필요해요.

사람은 맥락이 없어도 어떻게든 해 나가요. 동료에게 묻고, 지난 분기를 떠올리고, 숫자가 이상하면 알아채요. 에이전트는 그중 아무것도 못 해요. 컨텍스트 창에 있는 것만 알고, 대부분은 세션마다 백지에서 시작해요. Claude Code의 문서도 분명히 말해요. 세션은 매번 새 컨텍스트 창으로 시작하고, 다음으로 이어지는 건 CLAUDE.md나 AGENTS.md 같은 파일에 적힌 것뿐이에요. 맥락이 글로 남아 있지 않으면 에이전트는 추측해요.

두 번째 이유는 위키가 낡는다는 거예요. Andrej Karpathy가 2026년 4월에 공개한 LLM Wiki 노트는 그 문제를 한 줄로 짚어요.

“사람들이 위키를 버리는 건 유지 관리 부담이 가치보다 빨리 커지기 때문이에요.”

그의 제안은 장부 정리를 모델에게 맡기자는 거예요. 에이전트가 원자료를 읽고, 서로 링크된 마크다운 페이지를 쓰고 고치며, 모순되는 내용, 낡은 주장, 아무 데서도 링크되지 않은 페이지가 없는지 주기적으로 살펴요. 사람은 내용을 고르고 질문을 해요. 에이전트가 지식을 검색만 하는 게 아니라 직접 관리한다는 이 생각이, 컴퍼니 브레인을 지금 쓰는 위키와 갈라놓아요. (이 패턴은 LLM 위키 가이드에서 차근차근 설명해요.)

이 말은 거기서 퍼져 나갔고, 지금은 AI 검색이 붙은 호스팅 위키부터 에이전트의 기억을 git 안의 마크다운 파일로 두는 오픈 소스 프로젝트까지 아울러요. 가장 크게 갈리는 건 Karpathy의 노트가 사람에게 남겨 둔 질문이에요. 에이전트가 쓴 걸 누가 확인하느냐는 거죠.

어떤 도구를 쓰든 컴퍼니 브레인이 할 일은 네 가지예요. 대부분은 앞의 세 가지를 꽤 잘해요. 가장 크게 갈리는 건 네 번째이고, 누군가 그 답에 기댈지 말지가 여기서 정해져요.

1. 중요한 것을 담기

사람이 손으로 옮겨 적지 않아도 지식이 들어와야 해요. 회의록, 결정, 고객 지원에서 반복되는 패턴, 장애 보고서, 가격이나 프로세스의 변화 같은 것들이요. 실제로는 에이전트가 원자료를 읽고 해당 문서를 쓰거나 고치는 방식이에요.

2. 최신 상태 유지하기

3월에 맞았던 브레인은 9월에는 위험해요. 똑같이 자신 있게 말하니까요. 바뀔 수 있는 사실에는 모두 누군가 다시 확인할 날짜가 있어야 하고, 그 사실이 바뀌었을 때 그것에 기대는 내용을 전부 찾아낼 방법도 있어야 해요.

3. 사람도 에이전트도 꺼내 쓸 수 있기

사람은 둘러보고 검색할 수 있어야 해요. 에이전트는 도구마다 따로 연동하지 않아도 읽을 수 있어야 해요. 일반 텍스트, 예측 가능한 구조, 그리고 문서 전체를 열기 전에 훑어볼 수 있는 짧은 설명이 필요해요.

4. 믿을 수 있기

내용의 상당 부분을 에이전트가 쓴다면, 모든 문서가 보자마자 네 가지 질문에 답할 수 있어야 해요.

• 누가 썼나요? 사람인가요, 에이전트인가요(어떤 에이전트인가요)?
• 누가 확인했나요? 사람이 검토했나요, 다른 에이전트만 봤나요, 아무도 안 봤나요?
• 어디서 왔나요? 각 주장을 어떤 출처가 뒷받침하나요?
• 아직 맞나요? 마지막으로 확인한 게 언제고, 언제 만료되나요?

이게 없으면 브레인은 아무도 검증하지 않은 그럴듯한 글로 서서히 채워지고, 사람들은 어느 것도 믿지 않게 돼요. 검토받지 않은 1년 전 문서를 인용하는 AI 답변은 답이 없는 것보다 나빠요. 권위 있어 보이니까요.

호스팅 위키와 AI 검색

가장 흔한 방법이에요. 호스팅 지식 베이스를 그대로 쓰거나 새로 들이고, 그것과 다른 도구들을 검색하는 AI 층을 얹어요. 이 분야의 제품들은 닿는 범위와 AI가 얼마나 고칠 수 있는지에서 차이가 나요.

• 엔터프라이즈 검색. 채팅, 공유 드라이브, 이슈 트래커, CRM 같은 업무 앱 수백 개에 연결해서 그 전체를 대상으로 답해요. 사용자마다 볼 권한이 있는 것만 보여 줘요.
• 어시스턴트가 내장된 위키. 위키와 연결된 일부 앱의 내용으로 질문에 답하고, 자체 에이전트가 페이지를 만들고 고칠 수 있어요.
• 스스로 관리하는 위키. 다른 도구들을 지켜보다가 페이지가 낡으면 업데이트 초안을 만들고, 사람이 승인하도록 넘겨요.

잘하는 것: 권한 관리, 비개발 팀의 온보딩, 모든 걸 한 번에 검색하기, 대부분의 사람에게는 설정이 필요 없다는 점. 약한 것: 지식이 업체의 데이터베이스에 있고, 저장소에서 일하는 코딩 에이전트는 보통 직접 읽지 못하고 API나 MCP 서버를 거쳐서 닿아요. 원자료 전체를 검색하면 정리된 답만큼이나 서로 어긋나는 채팅 스레드도 쉽게 찾아져요.

벡터 저장소와 RAG

엔지니어링 팀은 직접 만들기도 해요. 문서를 조각내서 임베딩하고, 벡터를 저장해 두었다가, 질문할 때 가장 가까운 조각을 꺼내요(검색 증강 생성, RAG). 유연하고 아주 큰 자료에도 잘 버텨요.

잘하는 것: 크고 빨리 바뀌는 자료, 맞춤 파이프라인. 약한 것: 벡터 저장소는 아무도 읽을 수 없어요. 모순되는 내용이 나란히 놓이고, 검색은 점수가 가장 높은 조각을 돌려줄 뿐이며, 누가 사실을 확인했는지나 언제 만료되는지 적을 자연스러운 자리가 없어요. 결국 그 위에 검토 층을 따로 만들게 돼요.

git 안의 마크다운 파일, 에이전트가 직접 읽기

코딩 팀이 스스로 도달한 방식이에요. 지식이 저장소 안의 마크다운 파일 폴더예요. Claude Code, Codex, Cursor 같은 에이전트가 코드를 다룰 때 쓰는 도구 그대로 파일을 읽고 고쳐요. 규칙 파일(AGENTS.md는 agents.md에 따르면 Codex, Cursor를 비롯한 많은 코딩 에이전트가 지원하는 열린 형식이고, Claude Code에는 CLAUDE.md가 있어요)이 폴더가 어떻게 짜여 있는지 알려 줘요. Karpathy의 LLM 위키가 바로 이런 모양이에요.

잘하는 것: 에이전트가 따로 연동하지 않아도 읽고 관리할 수 있고, 모든 변경이 검토할 수 있는 diff이며, git이 기록과 blame을 공짜로 주고, 어느 업체에도 묶이지 않아요. 약한 것: 저장소가 허락하는 것 이상의 권한은 없고, 비개발 동료를 위한 다듬어진 편집기가 없으며, git만으로는 사람이 어떤 문서를 확인했는지 알 수 없어요.

어느 것도 틀리지 않았어요. 직원이 수백 명이고, 접근 규칙이 엄격하고, 터미널을 여는 사람이 거의 없다면 호스팅 위키가 더 잘 맞을 거예요. 이 페이지의 나머지는 세 번째 방식을 다뤄요. 에이전트가 관리를 맡는 방식이 이것이기 때문이에요. Knowtarium도 이 위에 만들어졌어요. 같은 마크다운 문서와 frontmatter를, 에이전트가 MCP로 닿는 종단 간 암호화 워크스페이스에 두는 거예요.

git 저장소 하나와 지금 쓰는 코딩 에이전트만 있으면 오후 한나절에 시작할 수 있어요. 아래 단계는 Open Knowledge Format(OKF)을 따라요. 에이전트가 쓰는 마크다운 지식을 위해 Google Cloud가 공개한 열린 명세예요(GitHub의 v0.2). 이 형식은 특정 도구에 기대지 않고, 폴더를 만지는 사람이 한두 명일 때는 git diff와 꼼꼼한 눈만으로도 충분할 수 있어요. 단계마다 Knowtarium이 무엇을 더하는지 대부분 적어 두었어요.

1. 가장 아픈 영역 하나부터 고르기

회사 전체를 담으려 하지 마세요. 가장 자주 묻거나 가장 자주 틀리게 답하는 질문을 고르세요. 가격과 요금제 한도, 지표 정의, 출시 프로세스, 온콜 런북 같은 것들이요. 열 가지를 정확히 아는 브레인이 천 가지를 어렴풋이 아는 브레인보다 나아요.

2. 저장소와 폴더 구조 만들기

파일 하나에 개념 하나, 그리고 팀이 이해하기 쉬운 폴더로 묶어요.

company-brain/
  AGENTS.md                 # 이 폴더에서 에이전트가 따르는 규칙
  index.md                  # 여기 있는 것, 문서마다 한 줄씩
  log.md                    # 바뀐 내용, 최신순
  company/
    glossary.md             # '활성 고객', '이탈', 'MRR'이 뜻하는 것
    decisions/
      2026-08-pricing.md    # 결정 하나에 파일 하나, 이유와 함께
  product/
    plans-and-limits.md
    release-process.md
  meetings/
    2026-08-14-pricing-review.md
  customers/
    segments.md
    accounts/northwind.md
  runbooks/
    refunds.md
    on-call.md

index.md와 log.md는 OKF에서 예약된 이름이에요. 앞의 것은 폴더에 무엇이 있는지 적고, 뒤의 것은 무엇이 바뀌었는지 기록해요. 에이전트는 인덱스부터 읽기 때문에 필요한 문서만 열어요.

3. 에이전트를 위한 규칙 적어 두기

규칙은 AGENTS.md에 적어요(Claude Code를 쓴다면 CLAUDE.md가 그 파일을 가리키게 하세요). 짧고 구체적으로 쓰세요. 더 자세한 버전은 지식 베이스를 위한 AGENTS.md 가이드에 있어요.

# 이 지식 베이스의 규칙
 
- 파일 하나에 개념 하나. 만들기 전에 먼저 검색하고, 있으면 그 파일을 고쳐요.
- 모든 파일은 frontmatter로 시작해요: type, title, description.
- 파일을 쓰거나 고치면 generated.by에 에이전트 이름과 버전을 적어요.
- 자기 자신이든 누구든 verified에 추가하지 않아요. 그건 검토하는 사람만 해요.
- 사실을 말하는 문장마다 각주로 출처를 달아요: [^source-id].
- 자주 바뀌는 사실(가격, 담당자, 한도)에는 stale_after 날짜를 붙여요.
- 관련 문서는 번들 루트 기준 마크다운 링크로 이어요: [Churn](/metrics/churn.md).
- 바꿀 때마다 log.md에 한 줄을 남겨요: 날짜, 파일, 무엇을, 왜.

4. 모든 문서에 출처 기록하기

브레인을 믿을 수 있게 만드는 건 frontmatter예요. OKF에는 앞의 네 가지 질문에 딱 맞는 필드가 있어요. generated(누가 언제 썼는지), verified(누가 확인했는지), sources(주장이 어디서 왔는지), stale_after(언제 다시 확인해야 하는지)예요.

---
type: Decision
title: 연간 요금제는 두 달 무료
description: 연간 요금이 월 요금의 10배인 이유와 다시 검토할 시점.
status: stable
generated: { by: claude-code/2.1, at: 2026-09-20T09:12:00Z }
verified:
  - { by: human:sara, at: 2026-09-21T14:30:00Z }
stale_after: 2027-03-31T00:00:00Z
sources:
  - id: pricing-review
    resource: /meetings/2026-08-14-pricing-review.md
    author: human:sara
---
 
연간 요금제는 월 요금의 열 배예요.[^pricing-review]
1분기 말, 이탈 수치가 나오면 다시 검토해요.

행위자는 정해진 형식으로 적어요. 버전이 붙은 에이전트(claude-code/2.1), 사람(human:sara), 프로세스(process:billing-sync)예요. 그러면 읽는 사람이 라벨을 믿는 대신 verified 목록을 보고 문서의 신뢰 수준을 판단할 수 있어요. 각주 규칙은 에이전트가 출처를 밝히게 하는 방법을 보세요.

5. 이미 있는 자료로 채우기

에이전트에게 기존 위키 내보내기 파일, 회의록, 결정 폴더를 가리키고, 주장마다 출처 파일을 인용하면서 개념 하나에 문서 하나씩 쓰라고 하세요. 처음에는 중복과 모순이 나올 거예요. 그것도 쓸모가 있어요. 지금 문서들이 어디서 서로 엇갈리는지 보여 주니까요.

6. 누군가 기대기 전에 모든 변경 검토하기

대부분의 팀이 건너뛰는 단계이자, 가장 중요한 단계예요. 에이전트는 메인 브랜치에 바로 쓰지 말고 풀 리퀘스트를 열어야 해요(아니면 변경을 커밋하지 않은 채로 두거나요). 사람이 diff를 읽고, 인용된 출처를 확인하고, 맞으면 자기 verified 항목을 추가해요. 무엇을 살펴볼지는 에이전트 편집 검토하는 방법에서 다뤄요.

반대 방향도 마찬가지예요. 사람이 손으로 문서를 고치면, 예를 들어 가격을 바꾸면, 예전 가격을 언급하는 다른 문서들이 이제 틀린 게 돼요. 에이전트에게 연결된 문서를 모두 그 편집과 대조해서 고칠 곳을 제안하라고 하세요.

Knowtarium에서는

Knowtarium은 검토를 켠 곳(워크스페이스나 폴더별 “Ask me first”)에서 두 방향을 모두 처리해요. 거기서는 에이전트의 변경이 diff로 기다리다가, 승인하면 verified에 내가 추가돼요. 내가 한 편집은 에이전트에게 확인을 부탁할 때까지(“오늘 편집한 것 확인해 주세요”) 기다리고, 마지막 변경 이후 양쪽이 모두 확인한 문서는 완전히 검증된 상태가 돼요. 그 밖의 곳에서는 에이전트의 변경이 바로 저장되고, 서명이 남고, 되돌릴 수 있어요.

(새 탭에서 원래 크기로 열림) (새 탭에서 원래 크기로 열림)

7. 최신성 점검을 일정에 넣기

바뀔 수 있는 건 모두 stale_after 날짜를 받아요. 일주일에 한 번, 에이전트에게 날짜가 지났거나 곧 만료되는 문서를 뽑아서 출처와 다시 대조하고 업데이트를 제안하게 하세요. 아무도 다시 확인하지 않는 문서는 잘못된 정보를 주게 두지 말고 status: deprecated로 표시해요.

Knowtarium에서는

Knowtarium에서는 Stale and expiring 페이지가 stale_after가 지난 문서와 곧 다가오는 문서를 보여 주고, 에이전트도 다시 확인할 수 있게 같은 목록을 요청할 수 있어요.

(새 탭에서 원래 크기로 열림) (새 탭에서 원래 크기로 열림)

8. 모든 에이전트에게 같은 입구 주기

저장소에서 일하는 코딩 에이전트는 파일을 직접 읽어요. 파일에 접근할 수 없는 채팅 앱에는 폴더 위에 MCP 서버를 두어 요청할 때 문서를 건네줄 수 있어요. 어느 쪽이든 에이전트는 사람이 검토하는 바로 그 파일을 읽으니, 진실은 한 버전뿐이에요.

같은 과정을 Knowtarium과 함께 해 볼게요. 위 예시의 가격 결정을 따라가요. Knowtarium은 에이전트를 대신하지 않아요. 문서가 종단간 암호화된 채로 머무는 곳이고, 각 에이전트가 무엇을 했는지 보는 곳이며, 무엇을 확인된 것으로 칠지 내가 정하는 곳이에요.

company-brain 폴더를 워크스페이스로 가져오고, npx knowtarium connect로 에이전트를 연결한 다음, company/decisions/처럼 돈이 걸린 결정을 하는 폴더에 검토를 켜세요.

1. 에이전트에게 쓰게 하고, 바뀐 걸 보기. 에이전트에게 가격 회의록을 결정 문서로 바꿔 달라고 하세요. 그 폴더는 검토가 켜져 있으니 변경이 unverified로 표시된 diff로 기다려요. 읽어 보고, 인용된 회의록을 열어 보고, 승인하세요. Knowtarium이 시각과 함께 나를 verified에 추가해요. 틀렸다면 댓글을 달아 거절하세요. 검토가 없는 폴더에서는 변경이 바로 저장되고, 에이전트의 서명과 함께 문서에 표시되며, 클릭 한 번이면 Undo할 수 있어요.
2. 사실을 직접 고치고, 에이전트에게 확인받기. 연간 할인이 바뀐다고 해 볼게요. Knowtarium에서 결정 문서를 고치면 그 변경은 내 것으로 서명되고, 에이전트의 확인을 기다려요. 에이전트에게 “오늘 편집한 것 확인해 주세요”라고 하세요. 에이전트가 diff를 읽고, plans-and-limits.md 같은 문서로 이어진 링크를 따라가서, 예전 숫자가 남아 있는 곳을 고치거나 표시해요. 두 확인이 모두 기록되면 그 결정은 완전히 검증된 상태가 돼요.
3. 최신성 지켜보기. 이 결정은 2027년 3월 31일에 만료돼요. 날짜가 다가오면 Stale and expiring 페이지에 나타나고, 날짜가 지나면 누군가 새로 고칠 때까지 오래된 문서로 남아요. 새로 고치는 것도 새로운 변경이라서, 다시 한번 확인을 받아요.
4. 가지고 나가기. 워크스페이스나 폴더를 언제든 일반 마크다운으로 내보낼 수 있어요. verified 항목이 파일과 함께 따라가서, 어떤 편집기로 열든 누가 무엇을 확인했는지 보여요.

git 안의 마크다운 컴퍼니 브레인은 코드를 공유하듯 저장소로 공유해요. 모두가 복제하고, 에이전트와 사람이 파일을 고치고, 변경은 커밋과 풀 리퀘스트로 들어와요. 기록, 브랜치, 병합 충돌은 git이 맡고, 접근 제어는 git 호스트가 맡아요.

여기서 Knowtarium이 지금 무엇을 하고 무엇을 안 하는지 분명히 해 둘게요.

• 팀 공유 기능은 아직 없어요. Knowtarium 계정과 그 워크스페이스는 한 사람의 것이에요. 공유 워크스페이스, 구성원 권한, 실시간 공동 편집은 없어요. 공유 워크스페이스는 계획에 있지만 첫 버전에는 들어가지 않아요.
• 공유할 수 있는 건 파일이에요. Knowtarium에서 변경을 승인하면 내 이름과 시각이 그 문서의 verified 목록에 들어가요. 워크스페이스를 일반 마크다운으로 내보내서 저장소에 넣으면, 어떤 도구로 파일을 열든 읽는 사람 모두가 그 검토를 볼 수 있어요. 실시간 연결이 아니라 사본이에요.
• 한 사람, 여러 에이전트. 에이전트 여러 개(Claude Code, Codex, Cursor, Claude Desktop)를 연결할 수 있고, 각각 워크스페이스 하나 또는 그 안의 일부 폴더에만, 읽기 전용이나 읽기·쓰기로 연결할 수 있어요. 모든 변경에 어느 에이전트가 했는지 나오고, 하나를 해제하면 그 즉시 끊겨요.
• 모두에게 필요한 건 아니에요. 검토하지 않는 팀원은 내보낸 파일을 편집기에서 읽거나, git 호스트에서 둘러보거나, 자기 에이전트에게 읽게 할 수 있어요.

지금 당장 공유 워크스페이스, 문서별 권한, 관리자 콘솔, 실시간 공동 편집이 필요하다면 Knowtarium은 아직 그런 용도로 만들어지지 않았어요. 지금은 브레인을 관리하고 에이전트가 쓴 걸 확인하는 한 사람을 위한 도구예요.

• 전부 집어넣기. 모든 채널과 받은편지함을 브레인에 쏟아부으면 정리된 답이 논의 속에 묻혀요. 결정과 정의를 담고, 원자료는 출처로 링크하세요.
• 출처 기록이 없음. 어떤 문서를 에이전트가 썼고 아무도 확인하지 않았는지 구분할 수 없게 되면, 전부 의심해야 해요.
• 에이전트가 에이전트를 승인하기. 두 번째 에이전트가 첫 번째를 확인해 주는 건 쓸모 있지만, 사람의 검토는 아니에요. 둘을 따로 두세요.
• 만료 날짜가 없음. 가격, 담당자, 한도, 조직도는 몇 달이면 낡아요. stale_after가 없으면 오래된 문서가 최신 문서와 똑같아 보여요.
• 사라지는 것을 인용하기. 채팅 메시지 링크나 아무도 기록하지 않은 회의는 출처가 아니에요. 출처를 저장소에 저장하고(회의록이나 내보내기 파일로) 그 파일을 인용하세요.
• 담당자가 없음. 에이전트가 바꾼 걸 누군가는 봐야 해요. 검토가 모두의 일이면 결국 아무의 일도 아니게 돼요.