이 카드들을 언제 쓰나
컴퍼니 브레인 축적하기는 위키 한 벌을 처음부터 끝까지 짓는 실습입니다. 한 번 따라가면 끝납니다.
지은 다음이 이 페이지입니다. 앞의 넷은 그것을 믿어도 되는지 재보는 점검이고, 뒤의 셋은 실제로 쓰고 남기는 운영입니다. 카드마다 따로 완결되므로 순서를 지키지 않아도 되지만, 01번은 먼저 하는 편이 좋습니다.
점검 카드는 숫자가 적힌 표를 남기고, 운영 카드는 파일을 남깁니다. 워크샵에서 손에 쥐고 나가는 것은 요약이 아니라 그 둘입니다.
난이도
★ 입문
★★ 기초
★★★ 중급
★★★★ 고급
믿어도 되는지 재보기
01
▼
사전 한 장으로 얼마나 달라지는지 재보기
★★
~40분
먼저 던질 질문
지금 진행 중인 프로젝트에 대해 아래 질문에 답해줘. 근거가 된 자료의 이름과 위치를 함께 적고, 모르면 모른다고 답해줘.
1. 이 프로젝트에서 "고객"은 무엇을 세는 단위인가
2. 지금까지 확인된 사실 중 숫자가 붙은 것은 몇 건인가
3. 그 숫자들은 각각 어느 시점 기준인가
4. 서로 어긋나는 정보가 있다면 무엇인가
5. 아직 확인하지 못한 것은 무엇인가
실행 순서
- 1사전을 만들기 전에 위 질문을 던지고 답을 표에 적습니다. 이것이 before입니다. 순서를 뒤집으면 이 카드는 아무것도 증명하지 못합니다
- 2지난 프로젝트 보고서 목차와 회의록 하나를 열고 등장하는 명사를 전부 뽑습니다. 보통 마흔 개에서 예순 개가 나옵니다
- 3세 칸으로 나눕니다. 객체가 될 것 · 속성으로 들어갈 것 · 버릴 것. 판정 기준은 한 줄입니다. id를 붙여 두 번 이상 가리킬 일이 있으면 객체이고, 아니면 속성입니다
- 4객체마다 정의 한 줄과 세는 기준을 적습니다. 스무 줄이면 충분합니다
- 5그 사전을 붙이고 같은 질문 다섯 개를 그대로 다시 던져 after를 적습니다
재는 법
- A답에 출처가 붙은 비율
- B조용한 오답. 형식은 멀쩡한데 값이 틀린 답의 개수
- C일관성. 같은 질문을 세 번 던졌을 때 값이 달라지는 횟수
기대 효과
세 번째 지표가 회의실에서 가장 잘 먹힙니다. 같은 질문에 매출 숫자가 세 번 다르게 나오는 장면은 따로 설명할 필요가 없습니다. 4KB짜리 마크다운 한 장이 프런티어 모델 세 종의 정확도를 45%대에서 68%대로 올린 실험이 있습니다(arXiv 2604.25149). 모델을 바꿔 얻는 차이보다 큽니다.
02
▼
틀린 한 줄을 심어 보기
★★
~10분
두 번 던질 질문
활성 고객이 몇 명이고 그 기준이 무엇인지 알려줘.
근거가 된 문장을 그대로 인용하고, 그 값을 믿어도 되는지 함께 판단해줘.
실행 순서
- 1사전에서 정의 한 줄을 고릅니다. 활성 고객 기준처럼 여러 답에 영향을 주는 것이 좋습니다
- 2위 질문을 던지고 답을 적어 둡니다
- 3그 정의를 몰래 바꿉니다. 90일을 180일로 고치는 식입니다
- 4같은 질문을 다시 던집니다. 답이 어떻게 달라지는지, 그리고 AI가 그 변화를 스스로 의심하는지 봅니다
여기서 알게 되는 것
정본은 힘이 셉니다. 맞을 때도 세고 틀릴 때도 셉니다. 그래서 최종 확인일이 오래된 날짜로 채워져 있으면 신뢰가 올라가는 것이 아니라 내려갑니다. 아무 표시가 없으면 읽는 사람이 알아서 의심하지만, 날짜가 적혀 있으면 그 문서를 그냥 믿어 버립니다.
03
▼
마스킹을 뚫어 보기
★★
~10분
프롬프트
아래 문서에서 회사 이름을 지웠다.
남아 있는 정보만으로 이 회사가 어디인지 추정하고,
어떤 항목이 결정적 단서였는지 영향이 큰 순서대로 알려줘.
추정이 어려우면 어떤 항목이 하나만 더 있으면 특정 가능한지도 알려줘.
실행 순서
- 1위키 페이지 한 장을 골라 회사명, 사람 이름, 제품명을 지웁니다
- 2옆 사람에게 건네고 5분 안에 맞혀 보라고 합니다. 위 프롬프트로 AI에게도 시켜 봅니다
- 3무엇이 단서가 됐는지 적습니다. 대개 순위, 규모, 진출 연도 같은 항목입니다
- 4그 항목을 고칩니다. 수치는 구간으로 바꾸고, 연도는 T와 T-1처럼 상대 표기로 바꿉니다
여기서 알게 되는 것
마스킹은 이름을 지우는 일이 아니라 필드를 설계하는 일입니다. "국내 3위 편의점 체인, 매장 1만 개대, 2024년 진출"은 이름이 없어도 한 회사만 가리킵니다. 속성 몇 개가 겹치면 그것으로 특정됩니다. 보안 가이드의 민감정보 기준과 함께 봅니다.
04
▼
위키 건강검진
★★★
~20분
프롬프트
wiki/ 폴더 전체를 읽고 아래 네 가지를 찾아줘. 고치지는 말고 목록만 만들어줘.
1. 모순. 서로 어긋나는 내용이 정리되지 않은 채 두 페이지에 남아 있는 것
2. 낡은 주장. 최종 확인일이 30일을 넘긴 것
3. 외톨이 페이지. 어디에서도 이어지지 않고 어디로도 이어지지 않는 것
4. 근거 쏠림. 판단 하나가 같은 자료 한 건에만 기대고 있는 것
항목마다 파일 경로와 문제가 되는 줄을 함께 적어줘.
그다음 고칠 때는 내용을 지어내서 채우지 마라.
근거가 없으면 확신도를 낮추거나 가설로 내리고,
무엇을 어떻게 처리했는지 한 줄씩 남겨라.
실행 순서
- 1위 프롬프트를 돌리고 나온 목록을 세어 봅니다. 처음 돌리면 대개 열 건 안팎이 나옵니다
- 2네 번째 항목부터 봅니다. 근거 쏠림이 가장 위험합니다
- 3고치게 한 뒤 다시 돌립니다. 0이 될 때까지 반복합니다
- 4이 프롬프트를
lint.md로 저장해 두고, 매주 갱신이 끝날 때마다 한 번씩 돌립니다
왜 필요한가
본편의 검증 여섯 항목은 사람이 읽고 판단하는 검증입니다. 페이지가 열 장일 때는 됩니다. 쉰 장이 넘으면 눈으로 못 훑습니다. LLM 위키가
lint를 따로 둔 이유가 여기 있습니다. 네 번째 항목은 컨설팅에서 특히 중요합니다. 발견 여섯 건이 전부 같은 임원 인터뷰에서 나왔다면, 그것은 발견이 아니라 그 사람의 의견입니다.쓰고 남기기
05
▼
코드 없이 한 주 써 보기
★
15분 + 한 주
프로젝트 지시문
이 프로젝트의 모든 답변은 아래 규칙을 따른다.
1. 사전에 정의된 용어는 그 뜻으로만 쓴다. 사전에 없는 용어를 써야 하면 먼저 알려준다.
2. 숫자를 말할 때는 값, 단위, 기준 시점, 출처를 함께 적는다.
3. 사전이나 첨부 자료에 근거가 없으면 "자료에 없습니다"라고 답하고 추측하지 않는다.
4. 사실과 판단을 한 문단에 섞지 않는다. 판단에는 "판단"이라고 표시한다.
실행 순서
- 1claude.ai에서 프로젝트를 새로 만들고 이름을 프로젝트명으로 둡니다
- 201번에서 만든 사전 파일을 프로젝트 지식에 올립니다
- 3위 규칙을 프로젝트 지시문에 넣습니다
- 4한 주 동안 이 프로젝트 안에서만 대화합니다. 자료를 붙여넣지 않게 되는 지점이 언제인지 세어 둡니다
알아 둘 것
프로젝트 지식은 자료가 컨텍스트 한계에 가까워지면 검색 방식으로 자동 전환됩니다. 그래서 매 답변이 올린 자료를 전부 읽는다는 보장이 없습니다. 관계를 묻는 질문, 조건으로 걸러 내는 질문, 정렬해 달라는 요청은 여기서 잘 되지 않습니다. 그 벽에 닿는 순간이 Claude Code로 넘어갈 시점입니다.
06
▼
사실과 판단을 나눠 쓰기
★★★
~40분
프롬프트
아래 회의록을 읽고 세 종류로 나눠서 정리해줘. 섞지 마.
[사실] 회의록에 적힌 관찰. 값, 단위, 기준 시점, 그리고 회의록 안 위치까지 적는다.
[판단] 그 사실로 내린 결론. 제목을 명사구로 쓰지 말고 주어와 서술어가 있는 문장으로 쓴다.
[가설] 근거가 한 건뿐인 것. 판단으로 올리지 말고 여기에 둔다.
판단마다 아래 두 항목을 반드시 채운다. 채울 내용이 없으면 회의록을 다시 읽어라.
- 이 판단이 틀릴 수 있는 조건
- 이 문서가 답하지 않는 것
회의록에 없는 내용을 채워 넣지 마라. 비어 있으면 비어 있다고 적어라.
실행 순서
- 1회의록 한 건을 고릅니다. 길수록 좋습니다
- 2위 프롬프트로 세 종류를 뽑습니다
- 3판단 하나를 골라 근거를 직접 세어 봅니다. 한 건뿐이면 가설로 내립니다
- 4판단 제목을 소리 내어 읽습니다. 명사구로 끝나면 문장으로 고칩니다. "프리미엄 라인 수익성 분석"이 아니라 "프리미엄 라인은 원가가 오른 만큼 판가를 올리지 못했다"입니다
왜 나누는가
한 페이지에 섞여 있으면 AI가 둘을 같은 무게로 인용합니다. 마진이 21.0%라는 관찰과, 그것이 판가 결정 방식 탓이라는 판단이 한 문단에 있으면 두 번째도 사실처럼 인용됩니다. 그리고 "이 문서가 답하지 않는 것"을 적어 두면 AI가 그 빈칸을 지어내지 않습니다. 환각을 막는 일이 프롬프트가 아니라 문서 쪽에서도 됩니다.
07
▼
끝난 프로젝트를 얼려서 남기기
★★
~20분
프롬프트
이 프로젝트가 오늘 종료됐다. 위키를 두 벌로 나눠줘.
[동결본] 지금 내용을 그대로 두고 모든 페이지 맨 위에 frozen 표시와 종료일을 넣는다.
앞으로 갱신하지 않는다는 문장을 index.md 맨 위에 적는다.
[승계본] 다음 프로젝트에서 다시 쓸 수 있는 것만 남긴다.
객체 정의, 분석 구조, 판정 규칙만 가져가고 이 고객사의 값은 전부 뺀다.
무엇을 뺐는지 목록으로 보고한다.
고객사 이름, 사람 이름, 금액, 점유율은 승계본에 남기지 마라.
실행 순서
- 1종료일을 정하고 동결본을 만듭니다. 이후로는 갱신하지 않습니다
- 2승계본에서 값을 전부 걷어냅니다. 남는 것은 구조뿐이어야 합니다
- 3승계본을 03번 마스킹 검사에 한 번 더 통과시킵니다
- 4동결본에는 계약상 파기 기한을 파일 이름이나 첫 줄에 적어 둡니다
이 카드가 답하는 질문
"매달 최종 확인일을 갱신한다"는 규칙은 워크샵에서는 합리적으로 들리지만, 바쁜 3주가 지나면 아무도 하지 않습니다. 한 번 밀리면 그대로 멈춥니다. 그래서 유지를 요구하지 않는 최소 버전을 따로 둡니다. 계속 살려 두는 위키가 아니라 끝나면 얼려서 남기는 파일입니다.
승계본에서 드러나는 것
사전을 산업별로 만들면 다음 프로젝트에서 못 씁니다. 문제 유형별로 만들면 씁니다. 수익성 진단의 객체 구성은 유통이든 제조든 거의 같고, 다른 것은 값과 배부 규칙뿐입니다. 수익성 진단, 원가 절감, 시장 진입, 채널 재설계, 조직 재설계. 다섯 벌이면 수주의 상당 부분을 덮습니다.
실습 팁과 다음 단계
실습 팁
- 01번을 건너뛰지 마세요. 효과를 재 두지 않으면 나머지 카드가 전부 "그런가 보다"로 끝납니다
- 02번과 03번은 각각 10분입니다. 워크샵에서 집중력이 떨어지는 자리에 넣으면 분위기가 살아납니다
- 프롬프트는 그대로 한 번 돌린 뒤 자기 프로젝트 용어로 고쳐 씁니다
- 실습에 진짜 클라이언트 자료를 쓰기 전에, 회사에서 승인한 도구와 데이터 등급을 먼저 확인합니다
일곱 장을 다 돌리면 넉 장이 남습니다
프로젝트 사전, 사실과 판단이 나뉜 위키, 건강검진 프롬프트, 그리고 다음 프로젝트로 가져갈 승계본입니다.
이 넷은 프로젝트가 끝나도 사라지지 않습니다.