← 목록으로

컴퍼니 브레인 점검과 운영 7가지

만든 위키를 믿어도 되는지 재보는 점검 넷과, 실제로 쓰고 다음 프로젝트로 남기는 운영 셋입니다

컴퍼니 브레인 점검과 운영 7
이 카드들을 언제 쓰나
본편

컴퍼니 브레인 축적하기는 위키 한 벌을 처음부터 끝까지 짓는 실습입니다. 한 번 따라가면 끝납니다.

이 페이지

지은 다음이 이 페이지입니다. 앞의 넷은 그것을 믿어도 되는지 재보는 점검이고, 뒤의 셋은 실제로 쓰고 남기는 운영입니다. 카드마다 따로 완결되므로 순서를 지키지 않아도 되지만, 01번은 먼저 하는 편이 좋습니다.

남는 것

점검 카드는 숫자가 적힌 표를 남기고, 운영 카드는 파일을 남깁니다. 워크샵에서 손에 쥐고 나가는 것은 요약이 아니라 그 둘입니다.

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

일곱 장을 다 돌리면 넉 장이 남습니다

프로젝트 사전, 사실과 판단이 나뉜 위키, 건강검진 프롬프트, 그리고 다음 프로젝트로 가져갈 승계본입니다.
이 넷은 프로젝트가 끝나도 사라지지 않습니다.