무엇을 준비하나
이 페이지는 화면 앞에서 그대로 따라 하는 실습입니다. 컴퍼니 브레인이 무엇이고 왜 4역할로 나누는지는 설명 편에 있습니다. 먼저 읽고 오면 각 프롬프트가 무엇을 시키는지 보입니다.
여기서 만드는 것은 이렇습니다. 흩어진 자료를 한 폴더에 모으고, 스킬 4개(digest·update·catalog·ask)로 가 위키로 정리하게 만듭니다. 거기에 전체 규칙을 담은 규칙서(AGENTS.md)와 이 회사의 분류 체계를 담은 설정서(wiki-config.md)를 더하면, 한 세트가 됩니다. 한 번 만들고 끝나지 않습니다. 새 회의록을 폴더에 넣을 때마다 위키가 알아서 자랍니다.
여기서부터는 폴더 구조와 호출 방식이 도구마다 다릅니다. 쓰는 쪽을 고르면 아래 내용이 그 기준으로 바뀝니다.
Codex는 ChatGPT의 코딩 에이전트입니다.
- Claude Code나 Claude 데스크톱 앱 중 하나가 있으면 됩니다. 터미널이 부담스러우면 데스크톱 앱으로 합니다 (Claude Code 101, Claude Cowork 참고)
- 정리할 문서 몇 개가 필요합니다. 준비된 것이 없으면 아래 실습용 샘플 8개를 받아 그대로 씁니다. 회사 문서로 바로 시작해도 됩니다
- 민감 정보(인사·급여·개인정보)는 위키에 넣지 않을 기준을 미리 정해 둡니다
가상의 회사 한 곳이 넉 달 동안 남긴 회의록·정책·결정 기록·장애 기록·메일입니다. 압축을 풀면 inbox/ 폴더가 그대로 나오니, 만든 실습 폴더에 옮겨 넣고 바로 돌리면 됩니다.
| 파일 | 종류 | 이 문서로 무엇을 보나 |
|---|---|---|
| 2026-03-04_주간회의록 | 회의록 | 환불 기한을 7일로 정한 결정 |
| 2026-03-18_제품회의록 | 회의록 | 결정되지 않은 논의(월 9,000원 안) |
| 2026-04-08_가격정책_결정기록 | 결정 기록 | 논의와 다른 최종안(월 11,000원)과 반대 의견 |
| 2026-05-12_주간회의록 | 회의록 | 환불 기한을 14일로 바꾼 결정 |
| 고객응대_정책_v3 | 정책 | 2월 기준이라 7일이 그대로 남은 문서 |
| 2026-06-02_파트너십_안내_메일 | 메일 | 수수료 조건과 접수 절차 |
| 2026-06-20_장애_대응_기록 | 장애 기록 | 담당과 기한이 흩어진 후속 조치 3건 |
| 2026-07-01_인사평가_메모 | 대외비 | 위키에 올리면 안 되는 문서 |
- 정보 충돌. 환불 기한이 3월 7일 기준에서 5월 14일 기준으로 바뀝니다. 정책 문서 v3에는 아직 7일이 적혀 있습니다. 최신을 본문에 살리고 옛 기준을 변경 이력으로 내리는지 보세요.
- 논의와 결정의 구분. 3월에 나온 월 9,000원 안은 논의였고, 4월 결정 기록의 월 11,000원이 확정입니다. 논의를 결정처럼 적으면 실패입니다.
- 민감 정보. 인사평가 메모에는 등급과 연봉 조정폭, 개인 간병 사정이 들어 있습니다. 설정서의 민감도 기준이 이것을 걸러 내야 합니다.
- 흩어진 후속 조치. 장애 기록의 조치 3건은 담당과 기한이 제각각입니다. 위키에서 한 자리에 모이는지 보세요.
무엇을 만드는지 한눈에
이 실습이 만드는 것은 컴퍼니 브레인 네 가지 중 LLM 위키입니다. Karpathy가 정리한 LLM 위키의 구성 요소가 여기서 어떤 이름으로 나오는지 먼저 맞춰 둡니다.
| LLM 위키 | 여기서 부르는 이름 |
|---|---|
raw · 손대지 않는 원본 문서 | inbox/ |
wiki · LLM이 쓰는 마크다운 | wiki/ |
schema · 규칙 문서 | AGENTS.md + wiki-config.md |
ingest · 새 자료 흡수 | digest → update |
query · 근거를 달아 답하기 | ask |
lint · 건강 점검 | 점검 편 04번 카드가 메웁니다 |
그냥 폴더에 쌓기
- 파일은 많은데 어디에 뭐가 있는지 모름
- 같은 내용이 여러 문서에 중복
- 옛 정보와 새 정보가 뒤섞여 무엇이 최신인지 불명
- 아는 사람이 나가면 맥락도 함께 사라짐
LLM 위키로 정리하기
- 분류 체계가 파일에 규칙으로 정리되어 있어 일관성 유지
- 새 자료가 들어오면 중복·모순을 정리해 병합
- 충돌하면 최신 우선, 옛 내용은 변경 이력으로 보존
- 모든 문장에 출처가 붙어 "어디서 온 정보인지" 추적 가능
핵심 추출·분류
(중복·모순 정리)
+ 변경 이력 갱신
(출처 표시)
1단계. 누가 이 위키를 굴리나
도서관을 떠올려 보세요. 들어온 책을 분류하는 사람, 같은 주제 책을 한 서가에 정리하는 사람, 목록과 위치를 관리하는 사서, 그리고 방문자에게 "그 자료는 저쪽에 있어요"라고 안내하는 데스크 직원이 있습니다. 컴퍼니 브레인도 똑같이 네 가지 역할로 나눕니다. 역할마다 스킬을 하나씩 두고, 이름을 불러 실행합니다.
위키를 만드는 쪽은 정리·병합·목차 관리 세 역할입니다. 질의응답은 만들어진 위키를 쓰는 쪽입니다.
정리가
inbox에 새로 들어온 문서를 읽고, 무엇이 핵심인지 뽑아 어느 위키 페이지로 갈지 분류합니다. 회의록인지 정책인지 결정 기록인지, 출처와 날짜까지 함께 표시합니다.
편집자
정리가가 분류한 내용을 실제 위키 페이지에 병합합니다. 같은 내용이 있으면 합치고, 옛 정보와 충돌하면 최신을 살리되 옛것은 변경 이력으로 남깁니다.
사서
전체 목차(index.md)와 내부 링크, 태그, 변경 이력을 관리합니다. 새 페이지가 생기면 목차에 등록하고, 깨진 링크가 없는지 점검합니다.
한 사람이 모으고, 합치고, 답까지 하면 자기가 정리한 걸 그대로 믿습니다. 분류가 틀려도 본인은 모릅니다. 모으는 눈(정리가), 합치는 눈(편집자), 찾아주는 눈(사서)을 나눠 두면, 정리가가 잘못 분류한 걸 편집자가 잡고, 편집자가 빠뜨린 링크를 사서가 잡습니다. 보는 눈이 달라야 중복과 모순이 걸립니다.
추가 역할 · 안내데스크
- 안내데스크
ask· 완성된 위키를 근거로 질문에 답합니다. "지난 분기 가격 정책 누가 정했지?" 같은 질문에 출처 페이지를 달아 답하고, 위키에 없으면 "모름"이라고 말합니다. - 위키를 만드는 3역할과 분리해서 봅니다. 안내데스크는 위키를 고치지 않고 읽기만 합니다.
관리자 (사람 = 나)
- 이 회사의 분류 체계(
wiki-config.md)를 정합니다. - 회의록과 정책 문서를 inbox에 넣고 스킬을 호출합니다.
- 위키에 올라간 내용이 맞는지 직접 확인합니다. 무엇을 신뢰할지는 사람이 결정합니다.
우리 팀에는 위 4역할을 그대로 써도 될까? 종이에 한번 적어 보세요. 자료가 적은 팀이라면 정리가와 편집자를 한 스킬로 합쳐도 됩니다. 반대로 부서가 여러 개라면 부서별 사서를 두는 식으로 늘릴 수 있습니다. 우리 지식을 굴리는 데 필요한 손이 빠지지 않으면 됩니다.
2단계. 어떤 순서로 도나
1단계에서 누가 일할지 정했으니, 이번에는 언제 어떤 순서로 일할지를 설계합니다. 책 쓰기는 한 번 완성하면 끝이지만, 위키는 다릅니다. 새 회의록은 매주 들어옵니다. 그래서 들어온 것만 처리하고 나머지는 건드리지 않습니다. 이것을 증분 갱신이라고 부릅니다. 전체를 매번 다시 읽으면 느리고, 멀쩡한 페이지까지 흔들립니다.
전체는 4단계입니다. 스킬을 한 번 부르는 것이 한 단계입니다.
memory/의 처리 이력으로 걸러 건너뜁니다. 각 자료의 핵심을 뽑아 "이건 정책 페이지", "이건 의사결정 기록"처럼 분류하고, 출처와 날짜를 붙입니다.index.md 목차에 반영하고, 페이지 사이 내부 링크와 태그를 다시 잇습니다. 깨진 링크나 어디에도 연결되지 않은 외톨이 페이지가 없는지 점검합니다.책 쓰기는 기획서 하나로 한 번에 완성하는 파이프라인입니다. 컴퍼니 브레인은 계속 도는 루프입니다. 그 루프를 지탱하는 것이 memory/의 처리 이력입니다. 이미 본 파일을 기억해 두지 않으면, 매주 같은 회의록을 또 읽고 위키에 중복으로 쌓입니다. 증분 갱신은 "무엇을 이미 처리했는가"를 기억하는 데서 시작합니다.
3월 회의록에는 "환불 기한 7일", 5월 회의록에는 "환불 기한 14일"이라고 적혀 있다면? 편집자는 최신(5월) 정보를 본문에 살리고, 옛 정보는 페이지 하단의 변경 이력에 "2026-03 기준 7일 → 2026-05 14일로 변경"처럼 남깁니다. 옛 정보를 그냥 지우면 "왜 바뀌었나"라는 맥락이 사라집니다. 바뀐 이유를 물었을 때 답이 나오려면 옛 기준이 남아 있어야 합니다.
3단계. 무엇을 파일로 두나
AI 에이전트는 사람과 달리 구두로 알려준 규칙을 기억하지 못합니다. 대신 매번 같은 파일을 읽고 시작합니다. 그러니 분류 체계·역할·갱신 원칙을 파일에 박아 둡니다. 그 파일 묶음이 하네스입니다. 전체 폴더는 아래처럼 구성됩니다.
폴더 구조와 호출 방식은 도구마다 다릅니다. 쓰는 쪽을 고르면 아래 내용이 그 기준으로 바뀝니다.
Codex는 ChatGPT의 코딩 에이전트입니다.
규칙 본체는 AGENTS.md에 적습니다. 이 파일은 Claude Code와 Codex가 함께 읽는 표준 파일이라, 한 곳에 써 두면 도구를 바꿔도 같은 규칙이 그대로 적용됩니다. 스킬 4개도 파일 형식(SKILL.md 앞머리에 name과 description)이 같아서, 폴더 위치만 바꿔 옮기면 두 도구가 같은 매뉴얼을 씁니다.
Claude Code는 CLAUDE.md를 먼저 읽습니다. 그래서 그 파일에는 "규칙은 AGENTS.md를 봐"라고 한 줄만 적어 두고, 내용은 AGENTS.md에 몰아 둡니다. 스킬은 .claude/skills/ 아래 이름별 폴더에 넣습니다.
| 파일 | 역할 | 수정 가능 여부 |
|---|---|---|
| CLAUDE.md | AGENTS.md를 가리키는 진입점 (Claude Code가 먼저 읽음) | 수정 불가 (고정) |
| AGENTS.md | 갱신 원칙·페이지 형식·금지 사항 + 4역할 작업 절차 등 규칙 본체 (Claude Code·Codex 공통) | 수정 불가 (고정) |
| /*/SKILL.md | 4역할(정리가·편집자·사서·안내데스크)의 업무 절차 | 수정 불가 (고정) |
| wiki-config.md | 이 회사의 분류 체계·페이지 형식·민감도 기준 | 수정 가능 (교체) |
| inbox/ | 아직 정리되지 않은 원본 문서를 넣는 곳 | 사람이 투입 |
| wiki/ · memory/ | 정리된 위키 페이지와 처리 이력 | 자동 생성 |
회사에도 같은 구분이 있습니다. 취업 규칙과 결재 절차는 고정이고, 직원 명부와 프로젝트 현황은 계속 갱신됩니다. 만약 직원이 결재 절차까지 마음대로 바꾼다면 조직이 흔들립니다. 여기서도 같습니다. AGENTS.md와 스킬 파일은 운영 규칙이라 그대로 두고, wiki-config.md가 이 조직의 설정이라 회사마다 바꿔 씁니다. 그래서 같은 하네스를 다른 팀에 그대로 옮길 수 있습니다.
설정서(wiki-config.md)에는 일곱 가지를 적습니다
이 일곱 칸이 위키의 품질을 결정합니다. 하나라도 비면 AI가 알아서 판단해 버립니다.
분류 체계
지식을 어떤 카테고리로 나눌지. 예: 정책·제품·고객·의사결정·회의. 새 자료가 어느 페이지로 갈지 판단하는 기준.
페이지 형식
각 위키 페이지의 표준 틀. 예: 한 줄 요약 → 핵심 내용 → 근거·출처 → 갱신일 → 변경 이력.
자기완결 규칙
AI는 문서를 통째로 읽지 않고 조각으로 잘라 몇 개만 꺼내 읽습니다. 그래서 "앞에서 본"·"위에서 말한" 같은 표현을 금지하고, 핵심 사실은 페이지마다 다시 적게 합니다.
출처 규칙
모든 내용에 출처를 붙이는 방식. 예: "(2026-05-12 주간회의록)". 어느 문서에서 왔는지 역추적할 수 있게.
갱신 원칙
새 정보가 기존과 충돌할 때 처리법. 최신 우선 + 옛 내용은 변경 이력으로 보존하는 규칙.
민감도 기준
위키에 올리면 안 되는 내용. 예: 인사·급여·개인정보·미공개 계약. 정리가가 걸러야 할 선.
질문 응답 규칙
안내데스크의 답변 원칙. 출처 필수, 위키에 없으면 "모름", 추측 금지.
이 일곱 칸을 빠짐없이 채워 두면, 다른 팀에 옮길 때 wiki-config.md 한 파일만 갈아끼우면 끝입니다. 영업팀용, 개발팀용, 경영지원팀용 설정서를 각각 만들어 두면 같은 하네스로 부서별 컴퍼니 브레인을 찍어낼 수 있습니다. 바뀌는 것은 AI가 아니라 AI가 일하는 환경입니다. 도구를 Claude Code에서 Codex로 바꿔도 같은 설정서를 그대로 씁니다.
에게 실행을 맡긴다
여기부터는 화면 앞에서 그대로 따라 하면 됩니다. 폴더를 하나 만들고, 쓰는 앱에서 그 폴더를 열고, 아래 프롬프트를 순서대로 붙여 넣습니다.
바탕화면에 company-brain 폴더를 하나 만듭니다. 샘플 문서 8개를 내려받아 압축을 풀면 inbox/ 폴더가 나옵니다. 그 inbox 폴더를 통째로 company-brain 안에 옮겨 둡니다. 회사 문서로 하겠다면 빈 inbox 폴더를 만들고 그 안에 파일을 넣습니다. 여기까지는 탐색기와 파인더로 합니다.
쓰는 앱에 따라 폴더를 여는 방법이 다릅니다. 어느 쪽으로 열어도 다음 프롬프트는 똑같습니다.
| 쓰는 앱 | 폴더를 여는 방법 |
|---|---|
| Claude Code 터미널 |
터미널을 열고 cd ~/Desktop/company-brain을 입력한 뒤 claude를 실행합니다. 폴더 이름을 직접 치기 어려우면 cd 까지 친 다음 폴더를 터미널 창에 끌어다 놓으면 경로가 붙습니다. |
| Claude 데스크톱 앱 터미널 없이 |
Cowork를 열고 작업할 폴더로 company-brain을 연결합니다. 연결한 폴더가 Claude가 읽고 쓸 수 있는 경계입니다. 자세한 화면은 Claude Cowork에 있습니다. |
| Codex 터미널 |
터미널을 열고 cd ~/Desktop/company-brain을 입력한 뒤 codex를 실행합니다. 폴더 이름을 직접 치기 어려우면 cd 까지 친 다음 폴더를 터미널 창에 끌어다 놓으면 경로가 붙습니다. |
| ChatGPT 데스크톱 앱 터미널 없이 |
Work를 열고 작업할 프로젝트에 company-brain 폴더를 지정합니다. 지정한 범위가 ChatGPT가 참조할 자료의 경계입니다. 자세한 화면은 ChatGPT Work에 있습니다. |
회사 문서로 시작한다면 원본 폴더를 그대로 연결하지 말고 복사본을 만들어 그 폴더를 엽니다. 결과를 확인한 뒤에 원본으로 옮깁니다. 재무 자료나 인사 기록이 섞인 폴더는 연결하지 않습니다.
폴더를 연 상태에서 아래를 그대로 붙여 넣습니다. 규칙서와 설정서, 스킬 4개, 나머지 폴더가 한 번에 생깁니다.
이 파일 하나가 "우리 회사 위키"를 결정합니다. 설명 편 3단계에서 본 일곱 칸을 빠짐없이 채웁니다. 아래는 샘플 문서에 맞춘 값이라, 회사 문서로 한다면 분류 체계와 민감도만 우리 팀 것으로 바꿔 넣습니다.
여기서부터가 본 작업입니다. 네 개를 순서대로 하나씩 붙여 넣습니다. 하나가 끝나면 결과 파일을 열어 눈으로 확인한 뒤 다음으로 갑니다. 한 번에 몰아서 넣지 않습니다.
스킬을 만들어 두었으니 digest처럼 이름만 불러도 같은 일을 합니다. 아래 전문은 스킬을 쓰지 않는 데스크톱 앱에서도 그대로 도는 형태입니다.
프롬프트 3 · 정리가 (digest)
프롬프트 4 · 편집자 (update)
프롬프트 5 · 사서 (catalog)
프롬프트 6 · 안내데스크 (ask)
- 환불 기한은 14일, 2026-05-20 시행. 3월의 7일 기준이 변경 이력에 남아 있어야 합니다
- 라이트 요금제는 월 11,000원 / 40건. 사용자 62%가 월 35건 이하라는 근거까지 나와야 합니다. 3월에 논의된 9,000원이 답으로 나오면 논의를 결정으로 적은 것입니다
- 후속 조치 3건과 담당·기한이 한 자리에 모여 나와야 합니다
- 인사 평가는 "위키에 없습니다". 등급이 나오면 민감도 기준이 작동하지 않은 것입니다
한 바퀴 돌고 나면 프롬프트 전문을 다시 붙여 넣을 필요가 없습니다. 같은 일을 스킬 이름으로 부릅니다. 단계마다 결과를 열어서 확인한 뒤 다음으로 갑니다.
| 순서 | 역할 | 호출 | 하는 일 | 예상 소요 시간 |
|---|---|---|---|---|
| 1 | 정리가 | digest |
inbox의 새 자료를 읽고 핵심을 추출해 분류합니다 | 5~10분 |
| 2 | 편집자 | update |
분류 결과를 위키 페이지에 병합하고 충돌을 정리합니다 | 10~20분 |
| 3 | 사서 | catalog |
목차·내부 링크·변경 이력을 갱신합니다 | 약 5분 |
| 4 | 안내데스크 | ask |
완성된 위키를 근거로 질문에 출처와 함께 답합니다 | 수시 |
각 스킬은 memory/의 처리 이력을 먼저 확인합니다. digest 도중 멈춰도, 다시 실행하면 아직 처리 안 한 자료부터 이어서 작업합니다. 이미 본 파일은 다시 읽지 않습니다. 게임의 자동 저장과 같습니다.
월요일 아침, 지난주 회의록 3개를 inbox/에 넣고 스킬을 순서대로 부르면 아래처럼 진행됩니다. 한 산출물이 다음 산출물의 입력이 됩니다. 각 줄 오른쪽에 누가 맡는지 적었습니다.
위 표를 보면 위키 파일을 직접 고치는 건 편집자뿐입니다. 정리가는 분류만 하고, 사서는 목차만 잇고, 안내데스크는 읽기만 합니다. 본문을 손대는 손을 한 명으로 묶어야 형식과 톤이 흔들리지 않습니다. 사람으로 치면 "검토는 여러 명이 하지만, 위키에 글을 쓰는 사람은 한 명"인 구조입니다. 책 쓰기 실습에서 저자(블랙)만 본문을 고친 것과 같은 원리입니다.
만든 위키를 믿어도 되는지 재본다
네 스킬을 다 돌리면 wiki/ 폴더에 정리된 페이지들이 생깁니다. 컴퍼니 브레인은 책과 달리 여러 사람이 두고두고 참고합니다. 한 번 잘못 들어간 정보는 계속 잘못 안내합니다. 아래 여섯 가지를 직접 확인합니다.
출처 추적
모든 위키 문장에 "어느 문서에서 왔는지" 출처가 붙어 있는가
중복 없음
같은 내용이 여러 페이지에 흩어져 있지 않은가
최신성
충돌하는 정보 중 최신이 본문에, 옛것은 변경 이력에 남았는가
민감 정보 제외
인사·급여·개인정보가 위키에 새어 들어가지 않았는가
링크 정합
목차와 내부 링크가 깨지지 않고 실제 페이지로 연결되는가
답변 신뢰
ask가 위키에 없는 건 "모름"이라 답하고 지어내지 않는가
위키가 믿을 만한지 점검하는 프롬프트
답에 출처가 붙는지, 그리고 마지막 질문에 "위키에 없다"고 답하는지가 합격선입니다.
- 지금 환불 기한은 며칠이고 언제 바뀌었나? (14일, 2026-05-20 시행. 옛 7일 기준이 변경 이력에 남아 있어야 합니다)
- 라이트 요금제 가격은 얼마이고 왜 그 숫자로 정했나? (월 11,000원 / 40건. 사용자 62%가 월 35건 이하라는 근거까지 나와야 합니다)
- 결제 장애 이후 남은 후속 조치는? (알림 수신처 변경, 만료일 달력 등록, 실패 임계 알림 3건과 담당·기한)
- 한지우의 인사 평가 등급은? (위키에 없다고 답해야 정상입니다)
위 여섯 항목과 프롬프트는 사람이 읽고 판단하는 검증입니다. 페이지가 열 장일 때는 됩니다. 쉰 장이 넘으면 눈으로 못 훑습니다. LLM 위키가 lint를 따로 둔 이유가 여기 있습니다. 모순, 낡아 버린 주장, 어디에도 이어지지 않은 페이지, 비어 있는 항목을 기계가 먼저 걸러 낸 다음 사람이 봅니다.
이 실습에는 그 단계가 없습니다. 실습 카드 04번 · 위키 건강검진에서 이어서 만듭니다.
다음 주가 되면 AGENTS.md와 4개 스킬, wiki-config.md는 그대로 두고, 새 회의록을 inbox/에 넣은 뒤 digest부터 다시 부릅니다. 이미 처리한 자료는 건너뛰고 새것만 정리됩니다. 지식을 한 번 정리하는 대신, 정리하는 방식을 한 번 설계해 둡니다. 그다음은 매주 환경이 알아서 자랍니다.
지식 그래프를 그려 본다
위키 페이지가 수십 개로 늘면 목록만으로는 전체가 안 보입니다. 어떤 정책이 어떤 제품에 걸려 있는지, 작년 결정이 지금 어디에 영향을 주는지 같은 관계는 표로는 드러나지 않습니다. 지식 그래프는 위키의 페이지·태그·결정을 노드(점)로, 그 사이 연결을 엣지(선)로 그려 전체 지형을 한눈에 보여줍니다. 연결이 많아 커진 노드가 우리 조직이 가장 많이 다루는 주제입니다.
한 바퀴 돌렸다면, 다음은 운영입니다
정확도를 전후로 재고, 위키가 낡는 것을 막고, 매주 스스로 돌게 만드는 일이 남았습니다.
점검과 운영 7가지 카드에서 이어서 만듭니다.