회사에서 가장 똑똑한 AI는 보통 한 사람 밑에서 일한다.
누군가는 회사 전략을 이해한 채팅을 갖고 있다. 누군가는 우리가 어떻게 배포하는지 에이전트에게 가르쳐 놨다. 누군가는 대표가 원하는 제안서 문장을 정확히 아는 세션을 갖고 있다. 그 학습은 전부 채팅 안에서 끝난다.
그래서 이상한 일이 벌어진다. 회사는 매일 AI를 가르치는데, 회사는 아무것도 기억하지 못한다. 개인은 빨라지고 조직은 그대로다.
이 글은 그 학습을 밖으로 꺼내는 방법을 다룬다. 도구 이야기가 아니라 프롬프트 이야기다. 여섯 개의 프롬프트, 하나의 지도 파일, 하나의 라우팅 표. 전부 그대로 복사해서 오늘 쓸 수 있는 형태로 적었다.
문제는 프롬프트가 아니라, 프롬프트가 사는 곳이다
영업 리드가 어떤 반론이 딜을 죽이는지 설명한다. 마케터가 낡은 제품 설명을 고친다. 운영 담당이 어떤 숫자를 믿어도 되는지 알려 준다. 대표가 같은 문장을 다섯 번째 고쳐 쓴다.
전부 회사가 AI에게 "우리는 이렇게 생각한다"를 가르치는 순간이다. 그리고 전부 채팅 로그에 묻힌다.
결과는 조용한 분기(fork)다. 한 에이전트는 지난 분기 캠페인을 현재로 안다. 다른 에이전트는 승인된 적 없는 선호를 규칙으로 따른다. 세 번째 에이전트만 결과가 좋은데, 이유는 그 사람이 마법의 프롬프트를 알고 있기 때문이다.
교정은 결과물보다 비싸다. 결과물은 한 번 쓰이고 끝나지만 교정은 규칙이 될 수 있다. 그런데 우리는 결과물만 저장하고 교정은 버린다.
회사 브레인은 검색창이 아니다
사내 지식 프로젝트는 대개 이렇게 간다. 회의록, 전략 덱, 지난 캠페인, 고객 통화, 제품 문서를 전부 모은다. 그 위에 검색창을 얹는다. 그리고 브레인이라고 부른다.
정보는 늘었다. 판단은 그대로다.
쓸 만한 브레인에는 네 가지가 들어 있다.
| 층 | 무엇을 담는가 | 없으면 생기는 일 |
|---|---|---|
| 기억 | 지금 유효한 사실·결정·이력 | 낡은 사실을 확신에 차서 말한다 |
| 판단 | 좋은 결과를 규정하는 규칙과 기준 | 매번 다른 기준으로 만든다 |
| 역량 | 다시 실행할 수 있는 스킬과 워커 | 사람마다 절차를 새로 발명한다 |
| 학습 | 검토를 통과한 교정 | 같은 실수를 조직 전체가 반복한다 |
대부분의 조직은 첫 번째 층만 만들고 브레인이라 부른다. 나머지 세 층이 실제로 결과를 바꾸는 부분이다.
프롬프트 1 — 이미 있는 지능부터 캐낸다
새로 쓰지 말고 먼저 꺼내야 한다. 팀원 각자가 자기 AI 도구에 이 프롬프트를 넣는 것으로 시작한다.
지난 30일 동안 내가 너와 나눈 작업 기록을 훑어서, 회사 자산이 될 만한 것만 뽑아 줘.
찾을 것
1. 내가 너를 고친 지점 — 사실 정정, 표현 교정, 방향 수정
2. 내가 두 번 이상 반복해서 설명한 회사 사정 — 제품·고객·용어·금기
3. 결과가 좋았던 요청문과, 그때 내가 덧붙였던 조건
4. 네가 끝까지 몰라서 내가 매번 붙여 넣어야 했던 자료
출력 형식
| 유형 | 내용 한 줄 | 내가 실제로 쓴 원문 | 나만의 취향인가 / 회사가 알아야 하는가 |
규칙
- 요약하지 말고 내가 쓴 문장을 그대로 인용할 것
- 확실하지 않으면 "확인 필요"로 표시하고 추측으로 채우지 말 것
- 취향인지 회사 규칙인지 애매하면 둘 다 적고 판단은 나에게 넘길 것
네 번째 항목이 특히 중요하다. 매번 붙여 넣어야 했던 자료가 곧 브레인에 없는 것의 목록이다. 사람들은 보통 그걸 불편으로 느끼고 넘기지, 구멍의 증거로 읽지 않는다.
프롬프트 2 — 지도 파일부터 만든다
에이전트가 가장 먼저 읽는 파일은 회사 전체가 아니라 회사 지도여야 한다. 여기가 어디이고, 지금 무엇이 중요하고, 다음에 어디를 열어야 하는지만 있으면 된다.
# 회사 지도
## 우리가 하는 일
(회사·고객·제공물·포지셔닝을 다섯 줄 이내로)
## 지금 중요한 것
1. (최우선)
2. (그다음)
3. (그다음)
## 진실의 순서
1. (현재 사실을 소유한 시스템)
2. (프로젝트 상태를 소유한 시스템)
3. (고객 약속을 소유한 시스템)
## 어디를 볼 것인가
- decisions/ — 무엇을 왜 정했는가. 확정일·소유자·대체된 결정 포함
- people/ — 승인 권한과 결재 경계
- projects/ — 진행 중인 일과 상태
- policies/ — 매번 지켜야 하는 규칙
- skills/ — 검증된 작업 수행 방법
- workers/ — 반복 실행 가능한 작업 명세
- learnings.md — 검토를 통과한 교정
## 규칙
- 승인된 최신 정보를 쓴다
- 두 출처가 충돌하면 위 "진실의 순서"를 따른다
- 답이 없으면 없다고 말한다. 무엇을 못 찾았는지 함께 적는다
- 추측을 회사 지식으로 승격하지 않는다
- 확정일이 6개월 지난 항목은 인용 전에 "확인 필요"로 표시한다
빈칸을 혼자 채우기 어렵다면 이 프롬프트로 초안을 뽑는다.
우리 팀이 반복하는 업무 하나를 기준으로 회사 지도 초안을 만들어 줘.
업무: (반복되는 업무 하나)
좋은 결과의 예: (붙여넣기)
나쁜 결과의 예: (붙여넣기)
할 일
1. 이 업무를 잘 해내려면 반드시 알아야 하는 최소한의 회사 지식을 나열해라.
"있으면 좋은 것"은 빼고, 없으면 틀리는 것만 남겨라.
2. 그 지식 각각에 대해 지금 진실을 소유한 곳이 어디인지 물어라.
내가 답하지 않은 항목은 "소유자 미정"으로 표시해라.
3. 이 업무에 항상 적용되는 규칙과, 이번 건에만 해당하는 조건을 분리해라.
4. 승인이 필요한 지점과 승인자를 명시해라.
5. 위 구조로 지도 파일 초안을 작성하고, 각 항목이 왜 필요한지 한 줄씩 붙여라.
마지막에, 네가 나에게 물어야 하는 질문을 5개 이내로 정리해라.
마지막 줄을 빼지 마라. 에이전트가 무엇을 못 물어보고 지나갔는지가, 지도의 첫 번째 구멍이다.
컨텍스트를 더 주면 판단은 나빠진다
지도부터 주는 이유가 있다. 회사 자료를 전부 프롬프트에 밀어 넣으면 낡은 캠페인이 현재 포지셔닝과 같은 무게로 경쟁한다. 흘러가는 회의 메모가 승인된 결정과 같은 줄에 선다. 이력이 정책처럼 보이기 시작한다.
해법은 매 프롬프트에 더 많은 기억을 넣는 것이 아니다. 더 나은 내비게이션이다.
지도를 먼저 주고, 나머지는 작업이 필요로 할 때 열게 한다. 콘텐츠 에이전트는 포지셔닝·승인 문구·톤을 연다. 고객 에이전트는 계정 이력과 에스컬레이션 규칙을 연다. 개발 에이전트는 아키텍처 결정과 보안 정책을 연다. 같은 브레인을 쓰지만 회사 전체를 매 대화에 끌고 들어오지는 않는다.
프롬프트 3 — 교정을 원인 쪽으로 되돌린다
콘텐츠 에이전트가 좋은 제안서를 썼는데 지난 분기 포지셔닝을 썼다고 하자. 대부분은 문장을 고치고, 제안서를 보내고, 넘어간다. 문서는 나아졌고 나머지는 그대로다.
물어야 할 것은 하나다. 왜 낡은 포지셔닝이 아직 거기 있었는가.
방금 내가 네 결과물을 고쳤다. 결과물 말고 원인을 고치고 싶다.
내가 고친 내용: (붙여넣기)
작업 종류: (…)
할 일
1. 이 교정이 필요했던 원인을 하나로 특정해라.
(지식 부재 / 낡은 사실 / 규칙 미기록 / 방법 미기록 / 절차 미기록 / 안전장치 부재)
2. 아래 라우팅 표에서 저장 위치를 하나 고르고,
그 위치에 넣을 문장을 그대로 복사 가능한 완성형으로 써라.
3. 이것이 이번 한 번짜리 취향인지, 다음에도 적용될 회사 규칙인지 판정하고 근거를 대라.
4. "회사 규칙"이라고 판정했다면, 이 규칙이 틀리는 상황을 하나 만들어
스스로 반박해 보고 그래도 살아남는지 확인해라.
출력
- 원인 한 줄
- 저장 위치 한 곳
- 저장할 문장
- 취향/규칙 판정과 근거
- 이 문장을 승인해야 하는 사람
라우팅 표는 이렇게 쓴다.
| 교정이 드러낸 것 | 저장 위치 | 형태 |
|---|---|---|
| 빠졌거나 낡은 사실 | 회사 지식 | 확정일과 출처가 붙은 한 줄 |
| 새로 내린 전략적 선택 | 결정 기록 | 무엇을 대체하는지 명시 |
| 반복되는 선호 | 정책 | 항상 적용되는 규칙 문장 |
| 효과가 검증된 기법 | 스킬 | 언제 쓰는지 + 절차 |
| 반복되는 절차 | 워커 | 입력·단계·출력·중단 조건 |
| 위험한 행동 | 기계적 차단 | 프롬프트가 아니라 권한과 게이트 |
마지막 줄이 실무에서 가장 자주 틀리는 지점이다. 돈이 나가거나 회사 밖으로 나가는 행동은 문장으로 막지 마라. "함부로 보내지 마세요"는 정책이 아니라 희망이다. 발송·결제·삭제는 권한과 승인 단계로 막고, 프롬프트에는 그 게이트의 존재만 적는다.
3회 규칙 — 교정의 절반은 저장하면 안 된다
여기서 대부분의 팀이 반대 방향으로 실패한다. 교정이 중요하다는 말을 듣고, 모든 교정을 저장하기 시작한다. 3개월 뒤 정책 파일이 200줄이 되고, 그중 절반은 한 사람의 그날 기분이다.
실무에서 쓰는 기준은 단순하다.
- 1회 — 그냥 고치고 버린다. 기록하지 않는다.
- 2회 — 같은 교정이 다시 나오면 메모만 남긴다. 아직 승격하지 않는다.
- 3회 — 서로 다른 사람에게서, 서로 다른 건에서 세 번째 나오면 그때 정책으로 올린다.
여기서 "서로 다른 사람"이 핵심이다. 한 사람이 세 번 같은 말을 한 것은 회사 규칙이 아니라 그 사람의 취향이다. 취향을 정책으로 올리면 나머지 팀은 그 규칙을 우회하는 방법을 배우게 된다.
그리고 저장할 때는 세 가지 메타를 반드시 붙인다. 확정일, 소유자, 무엇을 대체했는가. 이 셋이 없는 문장은 시간이 지나면 유령 권위가 된다. 아무도 언제 왜 썼는지 모르는데 모두가 따르는 규칙 말이다.
프롬프트 4 — 반복 업무를 워커 명세로 바꾼다
아래 업무를 다음 사람이 그대로 다시 실행할 수 있는 명세로 바꿔라.
업무: (…)
좋은 결과의 예: (붙여넣기)
나쁜 결과의 예: (붙여넣기)
명세에 반드시 포함할 것
- 이름: 동사로 시작하는 한 줄
- 입력: 시작하려면 반드시 있어야 하는 것. 없으면 시작하지 않는다
- 참조: 회사 지도에서 열어야 할 파일과 그 이유
- 단계: 번호가 붙은 실행 순서. 각 단계에 판단 기준을 명시
- 출력: 형식·길이·저장 위치
- 중단 조건: 이럴 땐 멈추고 사람에게 묻는다 (최소 3가지)
- 승인: 결과가 회사 밖으로 나가기 전 확인해야 하는 사람
- 실패 신호: 이 결과가 잘못됐다는 걸 무엇으로 알아채는가
금지
- "적절히", "필요시", "잘" 같은 판단 유예 표현
- 중단 조건이 없는 명세
중단 조건이 없는 워커는 워커가 아니다. 자동화된 사고다. 그리고 실패 신호를 적어 두지 않으면, 잘못된 결과가 조용히 몇 주를 돌아간다.
프롬프트 5 — 공유 전에 반대편에서 심사한다
브레인이 오염되는 가장 빠른 길은, 에이전트가 자기 교정을 자기가 저장하는 것이다. 승격 사이에는 반드시 게이트가 있어야 한다.
아래 항목을 회사 전체의 기본값으로 승격할지 심사해라.
옹호하지 말고 반대편에 서서 검토해라.
제안 항목: (…)
제안자: (…)
근거로 제시된 사례: (…)
심사 질문
1. 이 문장이 틀렸다면, 어디서 처음 티가 나는가
2. 기존 결정·정책과 충돌하는 것이 있는가. 있다면 무엇을 대체하는가
3. 한 사람의 취향이 회사 규칙으로 올라가는 것은 아닌가.
다른 팀 상황 두 개를 만들어 검증해라
4. 이 규칙을 지킬 수 없는 상황은 언제인가. 그 예외를 문장에 포함해라
5. 소유자는 누구이고, 언제 다시 검토해야 하는가
출력
- 승인 / 조건부 승인 / 보류 중 하나
- 조건부라면, 고쳐 쓴 문장
- 이 항목이 대체하는 기존 항목 목록
- 재검토 시점
깃 저장소를 쓰고 있다면 이 게이트는 이미 있다. 브레인을 레포 안에 파일로 두면 승격은 곧 풀 리퀘스트가 되고, 검토는 코드 리뷰가 되고, 이력은 커밋 로그가 된다. 별도 도구를 사기 전에 이미 갖고 있는 리뷰 장치부터 쓰는 편이 빠르다.
프롬프트 6 — 주간 브레인 헬스체크
브레인은 만드는 것보다 유지가 어렵다. 매주 한 번 이 프롬프트로 구멍을 찾는다.
이번 주 우리 팀이 너에게 한 요청과 그 결과를 근거로, 회사 브레인의 구멍을 찾아라.
찾을 것
1. 답을 못 찾아 사람에게 되물은 항목 — 무엇이 없어서였는가
2. 서로 충돌한 출처 — 어느 쪽이 이겼고, 그것이 규칙대로였는가
3. 인용했지만 확정일이 오래된 항목
4. 같은 교정이 두 번 이상 반복된 항목 — 저장이 안 됐다는 뜻이다
5. 아무도 열지 않은 파일 — 지도에 있지만 쓰이지 않는다
출력
| 구멍 | 증거가 된 요청 | 어디에 무엇을 추가하는가 | 소유자 |
마지막 한 줄: 이번 주 브레인은 지난주보다 나아졌는가. 판단 근거는 무엇인가
다섯 번째 항목이 브레인을 가볍게 유지한다. 아무도 열지 않는 파일은 지식이 아니라 소음이다. 지우거나, 지도에서 내린다.
관리 지표는 파일 개수가 아니라 충돌 개수여야 한다. 파일이 늘어도 충돌이 없으면 건강하고, 파일이 적어도 충돌이 잦으면 이미 망가진 것이다.
브레인이 망가지는 네 가지 방식
- 아카이브화. 있는 자료를 다 넣는다. 검색은 되는데 판단은 나빠진다. 브레인은 도서관이 아니라 편집된 기준이다.
- 유령 권위. 확정일과 소유자가 없는 문장이 정책 행세를 한다. 아무도 왜 그런지 모르는데 모두가 따른다.
- 랩탑 감금. 한 사람의 폴더에서 시작한 브레인이 그 폴더에 남는다. 두 번째 사람이 합류하는 순간 사본이 갈라지고, 회사 브레인은 다시 개인 브레인 다섯 개가 된다.
- 검토 없는 자동 승격. 에이전트가 스스로 학습을 저장한다. 처음 몇 주는 마법 같고, 그다음에는 아무도 틀린 문장이 언제 들어왔는지 모른다.
어디에 둘 것인가
파일로 시작하는 것이 맞다. 지도 파일 하나와 폴더 여섯 개면 첫 버전으로 충분하다.
코딩 에이전트를 쓰고 있다면 진입점은 이미 표준이 있다. 2026년 8월 기준 Codex·Cursor·Copilot·Gemini CLI 등 대부분의 CLI가 AGENTS.md를 읽는다. Linux Foundation 산하 Agentic AI Foundation이 관리하는 규격이다. Claude Code는 여전히 CLAUDE.md를 먼저 읽으므로, CLAUDE.md 첫 줄에 @AGENTS.md 한 줄을 넣어 둘을 잇는 방식이 흔히 쓰인다. 진입점 하나에 지도를 두고, 나머지는 폴더로 두면 된다.
팀이 커지고 도구가 갈라지기 시작하면 — 누군가는 Claude Code, 누군가는 Cursor, 누군가는 ChatGPT — 파일 방식은 사본 문제에 부딪힌다. 이 지점을 노린 제품들이 나오고 있다. 이 글의 출발점이 된 글에서 소개하는 HQ가 그런 도구다. 다만 순서를 바꾸지는 마라. 도구가 브레인을 만들어 주지 않는다. 지도와 라우팅 표와 리뷰 게이트가 이미 돌고 있어야 도구가 그것을 여러 사람에게 복제해 준다.
이번 주에 할 일
- 팀이 설명하기 지친 업무를 하나 고른다. 자주 하고, 좋은 결과가 뭔지 알고, 결과를 빨리 검토할 수 있는 것.
- 팀원 각자에게 프롬프트 1을 돌리게 한다. 나온 항목을 한 문서에 모은다.
- 프롬프트 2로 지도 파일 초안을 만든다. 유지할 수 없는 칸은 비워 둔다.
- 그 업무를 실제로 한 번 돌린다. 교정이 나올 때마다 프롬프트 3으로 원인 쪽에 되돌린다.
- 금요일에 프롬프트 6을 돌린다. 나온 구멍이 다음 주의 작업 목록이다.
한 달짜리 설계를 하지 마라. 아름다운 아카이브 하나보다, 매주 반복되던 실수 하나를 없애는 작은 브레인이 낫다.
첫 테스트에서 에이전트가 머뭇거리거나 추측하거나 낡은 답을 내놓는 지점 — 그게 브레인이 다음에 무엇을 필요로 하는지 알려 주는 유일한 신호다.
우리 조직의 반복 업무를 어떤 순서로 에이전트에 옮길지, 어디에 사람 승인을 남길지 설계하는 일은 AX Ops 방법론 →에서 다룬다.
참고
- J.B. (@VibeMarketer_), "How to Build a Company Brain That Gets Smarter Every Week", 2026년 8월: https://x.com/VibeMarketer_
- HQ by Indigo — 컴퍼니 브레인 제품: https://hqforwork.com/
- AGENTS.md — Agentic AI Foundation(Linux Foundation)이 관리하는 에이전트 컨텍스트 파일 규격: https://agents.md/
- Anthropic, "Claude Code 메모리 관리" (
CLAUDE.md로딩 규칙): https://docs.claude.com/en/docs/claude-code/memory
