컴퍼니 브레인 만드는 법: 바로 복사해 쓰는 프롬프트 6종

요약

AX LABS가 2026년 8월 27일에 발행한 한국어 실무 가이드다. 개인 채팅 안에서 끝나 버리는 AI 교정을 조직 자산으로 옮기는 절차를 다룬다. 산출물은 세 가지로, 에이전트가 가장 먼저 읽는 회사 지도 파일 템플릿 한 장, 교정을 저장 위치로 보내는 라우팅 표 한 개, 그리고 여섯 자리에 넣는 프롬프트 6종이다.

글의 중심 판단은 한 문장이다. 교정은 결과물보다 비싸다. 결과물은 한 번 쓰이고 끝나지만 교정은 규칙이 될 수 있는데, 실무는 결과물만 저장하고 교정은 버린다. 그래서 회사는 매일 AI를 가르치면서 아무것도 기억하지 못한다.

프롬프트는 전문이 그대로 실려 있어 복사해 쓸 수 있는 형태다. 이 페이지는 그 6종을 원문 그대로 인용하고, 각 프롬프트가 무엇을 강제하는지를 항목별 표로 풀어 둔다. 정량 실험이나 벤치마크는 없는 자료이므로, 검증된 것은 방법이 아니라 저자가 정리한 운영 규칙이다.

배경

이 글은 회사에서 가장 똑똑한 AI가 보통 한 사람 밑에서 일한다는 관찰에서 출발한다. 누군가는 회사 전략을 이해한 채팅을 갖고 있고, 누군가는 배포 절차를 에이전트에게 가르쳐 두었고, 누군가는 대표가 원하는 제안서 문장을 정확히 아는 세션을 갖고 있다. 그 학습은 전부 채팅 안에서 끝난다. 개인은 빨라지고 조직은 그대로다.

저자가 드는 장면은 네 가지다. 영업 리드가 어떤 반론이 딜을 죽이는지 설명한다. 마케터가 낡은 제품 설명을 고친다. 운영 담당이 어떤 숫자를 믿어도 되는지 알려 준다. 대표가 같은 문장을 다섯 번째 고쳐 쓴다. 전부 회사가 AI에게 "우리는 이렇게 생각한다"를 가르치는 순간인데, 결과는 채팅 로그에 묻힌다.

그 상태를 저자는 "조용한 분기(fork)"라 부른다. 한 에이전트는 지난 분기 캠페인을 현재로 알고, 다른 에이전트는 승인된 적 없는 선호를 규칙으로 따르며, 세 번째만 결과가 좋은데 그 이유는 그 사람이 마법의 프롬프트를 알고 있어서다. 같은 회사 안에서 에이전트마다 서로 다른 회사 사실을 들고 갈라진 상태다.

원문은 이 대비를 흐름 도식으로 그린다. 위쪽은 "지금, 교정은 각자의 채팅에서 끝난다"라는 제목 아래 영업, 마케팅, 개발, 대표 네 상자를 나란히 두고 각 상자에서 점선이 내려가 X로 끝나는 그림이다. 붙은 주석은 "네 사람이 각각 조금씩 다른 회사를 안다"다. 아래쪽은 "회사 브레인, 한 번 배우면 전원이 나아진다"라는 제목 아래 같은 네 상자가 "검토를 통과한 교정만 모인 한 곳"으로 모이고, 거기서 "다음 사람과 다음 에이전트의 출발점"으로 이어진다.

두 그림이 가리키는 차이는 저장 지점 하나다. 교정이 각자의 세션에서 끝나는지, 아니면 검토를 통과한 뒤 한 곳에 모이는지에 따라 다음 사람이 물려받는 출발점이 달라진다. 이 도식은 HTML로 그려져 있어 개별 이미지 파일로 수집되지 않았고, 원문 페이지 전체 스크린샷(fig02) 안에만 남아 있다.

여기서 문제의 위치가 옮겨간다. 고쳐야 할 것은 프롬프트 문구가 아니라 프롬프트가 사는 곳이다. 원문의 제목도 그 진단을 그대로 쓴다.

핵심 개념

컴퍼니 브레인은 개인 채팅에 갇힌 학습을 조직 자산으로 옮겨 담은 층을 뜻한다. 자료 창고가 아니라 기억, 판단, 역량, 학습 네 층을 갖춘 구조여야 한다는 것이 저자의 정의다.

지도 파일은 에이전트가 가장 먼저 읽는 파일을 말한다. 회사 전체가 아니라 여기가 어디이고 지금 무엇이 중요하고 다음에 어디를 열어야 하는지만 담는다. 회사 자료 전체를 프롬프트에 넣는 방식의 대안으로 제시된다.

진실의 순서는 두 출처가 충돌할 때 어느 시스템의 값을 채택할지 미리 정해 둔 우선순위다. 지도 파일의 한 절로 들어가며, 규칙 절이 충돌 시 이 순서를 따르도록 지시한다.

교정 라우팅은 교정이 드러낸 결함 유형을 저장 위치로 보내는 대응 규칙이다. 결과물을 고치는 대신 원인이 있던 자리를 고치기 위한 장치다.

워커는 반복 업무를 다음 사람이 그대로 재실행할 수 있게 적은 명세를 뜻한다. 중단 조건과 실패 신호가 필수 항목이며, 둘이 없으면 명세로 인정하지 않는다.

유령 권위는 확정일과 소유자가 없는데도 정책처럼 따르게 된 문장을 가리킨다. 저장 메타를 요구하는 규칙이 이 상태를 막기 위해 존재한다.

교정의 비용 비대칭도 개념으로 다뤄 둘 만하다. 결과물은 한 번 쓰이고 소멸하는 산출물이고 교정은 다음 번에도 적용될 규칙의 재료다. 저자가 교정이 결과물보다 비싸다고 말하는 것은 만드는 데 든 시간이 아니라 재사용 가치를 기준으로 한 판단이다.

방법

브레인의 네 층

사내 지식 프로젝트의 통상 경로는 회의록, 전략 덱, 지난 캠페인, 고객 통화, 제품 문서를 전부 모으고 그 위에 검색창을 설치한 다음 브레인이라 부르는 것이다. 저자의 진단은 짧다. 정보는 늘었고 판단은 그대로다.

쓸 만한 브레인에는 네 층이 들어 있어야 한다. 각 층에는 그 층이 없을 때 실제로 나타나는 증상이 짝지어져 있다.

대부분의 조직은 첫 층만 만들고 브레인이라 부른다. 저자는 나머지 세 층이 실제로 결과를 바꾸는 부분이라고 본다. 검색 가능성과 판단 품질은 서로 다른 문제이기 때문이다.

네 층은 축적 방식도 다르다. 기억은 사실이 갱신될 때마다 바뀌고, 판단과 역량은 검토를 통과한 규칙과 절차가 쌓일 때 늘어나며, 학습은 교정이 들어올 때만 자란다. 뒤의 세 층에는 검토 절차가 개입한다는 공통점이 있다.

지도 우선 원칙

회사 자료를 전부 프롬프트에 밀어 넣으면 낡은 캠페인이 현재 포지셔닝과 같은 무게로 경쟁한다. 흘러가는 회의 메모가 승인된 결정과 같은 줄에 서고, 이력이 정책처럼 보이기 시작한다. 저자가 제시하는 해법은 매 프롬프트에 기억을 더 넣는 것이 아니라 더 나은 내비게이션이다.

원문은 여기서도 두 경로를 흐름 도식으로 대비시킨다. 앞선 도식과 마찬가지로 fig02 스크린샷에만 남아 있는 요소이며, 내용은 다음 표와 같다.

지도만 상시로 두고 나머지는 작업이 필요로 할 때 열게 한다. 역할별로 여는 문이 다르다. 콘텐츠 에이전트는 포지셔닝과 승인 문구와 톤을 열고, 고객 에이전트는 계정 이력과 에스컬레이션 규칙을 열고, 개발 에이전트는 아키텍처 결정과 보안 정책을 연다. 같은 브레인을 쓰지만 회사 전체를 매 대화에 끌고 들어오지는 않는다.

이 원칙은 context engineering 논의와 같은 자리를 겨냥한다. context engineering은 유한한 attention budget에 넣을 토큰을 고르는 설계를 말한다. 이 글의 기여는 그 선택을 모델 쪽 기법이 아니라 폴더 구조와 운영 규칙으로 옮겨 놓은 데 있다.

회사 지도 파일 템플릿

지도 파일 템플릿은 다섯 절로 되어 있다.

"어디를 볼 것인가" 절은 저장 대상을 위치마다 지정한다. 이 목록이 곧 브레인의 물리 구조다.

규칙 절의 다섯 문장이 이 템플릿의 실질이다. 각 문장이 막으려는 실패가 분명하다.

템플릿 전문은 다음과 같다.

# 회사 지도

## 우리가 하는 일
(회사·고객·제공물·포지셔닝을 다섯 줄 이내로)

## 지금 중요한 것
1. (최우선)
2. (그다음)
3. (그다음)

## 진실의 순서
1. (현재 사실을 소유한 시스템)
2. (프로젝트 상태를 소유한 시스템)
3. (고객 약속을 소유한 시스템)

## 어디를 볼 것인가
- decisions/ — 무엇을 왜 정했는가. 확정일·소유자·대체된 결정 포함
- people/ — 승인 권한과 결재 경계
- projects/ — 진행 중인 일과 상태
- policies/ — 매번 지켜야 하는 규칙
- skills/ — 검증된 작업 수행 방법
- workers/ — 반복 실행 가능한 작업 명세
- learnings.md — 검토를 통과한 교정

## 규칙
- 승인된 최신 정보를 쓴다
- 두 출처가 충돌하면 위 "진실의 순서"를 따른다
- 답이 없으면 없다고 말한다. 무엇을 못 찾았는지 함께 적는다
- 추측을 회사 지식으로 승격하지 않는다
- 확정일이 6개월 지난 항목은 인용 전에 "확인 필요"로 표시한다

프롬프트 여섯 자리

프롬프트 6종은 브레인의 수명 주기를 따라 배치된다. 기존 대화에서 재료를 캐내고(1), 지도를 세우고(2), 실행 중 나온 교정을 원인으로 되돌리고(3), 반복 업무를 명세로 굳히고(4), 승격 전에 심사하고(5), 주 1회 구멍을 찾는다(6).

여섯 자리는 입력과 산출물도 서로 다르다. 사람이 무엇을 붙여 넣어야 하고 무엇을 받아 어디에 저장하는지를 함께 보면 실행 순서가 분명해진다.

프롬프트 3이 이 흐름의 중심이다. 1과 2가 브레인을 세우는 일회성 작업이라면 3은 업무를 실행하는 동안 계속 돌아오는 자리이고, 4와 5는 3이 뽑아낸 것을 굳히는 단계이며, 6은 그 사이에 생긴 구멍을 주 단위로 회수한다.

채굴 프롬프트

첫 프롬프트는 새로 쓰지 말고 먼저 꺼내라는 원칙을 구현한다. 팀원 각자가 자기 AI 도구에 넣어 지난 30일의 작업 기록에서 네 가지를 찾는다.

네 번째 항목을 저자는 특히 강조한다. 매번 붙여 넣어야 했던 자료가 곧 브레인에 없는 것의 목록인데, 사람들은 보통 그것을 불편으로 느끼고 넘기며 구멍의 증거로 읽지 않는다.

출력은 네 열의 표로 받는다. 유형, 내용 한 줄, 사용자가 실제로 쓴 원문, 그리고 나만의 취향인지 회사가 알아야 하는가다. 세 번째 열이 원문 인용을 강제해서 요약 과정에서 표현이 뭉개지는 것을 막고, 네 번째 열이 승격 판단을 뒤로 미뤄 둔다.

출력 규칙 세 문장에는 환각을 막는 장치가 들어 있다. 요약하지 말고 사용자가 쓴 문장을 그대로 인용할 것, 확실하지 않으면 "확인 필요"로 표시하고 추측으로 채우지 말 것, 취향인지 회사 규칙인지 애매하면 둘 다 적고 판단은 사람에게 넘길 것. 판정을 모델에 맡기지 않고 사람에게 되돌리는 설계다.

지난 30일 동안 내가 너와 나눈 작업 기록을 훑어서, 회사 자산이 될 만한 것만 뽑아 줘.

찾을 것
1. 내가 너를 고친 지점 — 사실 정정, 표현 교정, 방향 수정
2. 내가 두 번 이상 반복해서 설명한 회사 사정 — 제품·고객·용어·금기
3. 결과가 좋았던 요청문과, 그때 내가 덧붙였던 조건
4. 네가 끝까지 몰라서 내가 매번 붙여 넣어야 했던 자료

출력 형식
| 유형 | 내용 한 줄 | 내가 실제로 쓴 원문 | 나만의 취향인가 / 회사가 알아야 하는가 |

규칙
- 요약하지 말고 내가 쓴 문장을 그대로 인용할 것
- 확실하지 않으면 "확인 필요"로 표시하고 추측으로 채우지 말 것
- 취향인지 회사 규칙인지 애매하면 둘 다 적고 판단은 나에게 넘길 것

지도 초안 프롬프트

지도 파일의 빈칸을 혼자 채우기 어려울 때 쓰는 프롬프트다. 입력은 반복 업무 하나와 좋은 결과 예시, 나쁜 결과 예시 세 가지이고, 수행 단계는 다섯 개다.

마지막 줄이 이 프롬프트의 급소다. 에이전트가 사용자에게 물어야 하는 질문을 5개 이내로 정리하게 하는데, 저자는 이 줄을 빼지 말라고 못 박는다. 에이전트가 무엇을 못 물어보고 지나갔는지가 지도의 첫 번째 구멍이기 때문이다.

우리 팀이 반복하는 업무 하나를 기준으로 회사 지도 초안을 만들어 줘.

업무: (반복되는 업무 하나)
좋은 결과의 예: (붙여넣기)
나쁜 결과의 예: (붙여넣기)

할 일
1. 이 업무를 잘 해내려면 반드시 알아야 하는 최소한의 회사 지식을 나열해라.
 "있으면 좋은 것"은 빼고, 없으면 틀리는 것만 남겨라.
2. 그 지식 각각에 대해 지금 진실을 소유한 곳이 어디인지 물어라.
 내가 답하지 않은 항목은 "소유자 미정"으로 표시해라.
3. 이 업무에 항상 적용되는 규칙과, 이번 건에만 해당하는 조건을 분리해라.
4. 승인이 필요한 지점과 승인자를 명시해라.
5. 위 구조로 지도 파일 초안을 작성하고, 각 항목이 왜 필요한지 한 줄씩 붙여라.

마지막에, 네가 나에게 물어야 하는 질문을 5개 이내로 정리해라.

교정 프롬프트

저자가 드는 상황은 구체적이다. 콘텐츠 에이전트가 좋은 제안서를 썼는데 지난 분기 포지셔닝을 썼다. 대부분은 문장을 고치고 제안서를 보내고 넘어가며, 그러면 문서는 나아지고 나머지는 그대로다. 프롬프트가 요구하는 것은 낡은 포지셔닝이 왜 아직 거기 있었는지를 확인하는 일이다.

원인 6종은 라우팅 표의 6행과 1대 1로 대응한다. 원인을 고르는 일이 곧 저장 위치를 고르는 일이 되도록 설계되어 있다.

네 번째 단계의 자기 반박이 이 프롬프트의 안전장치다. 규칙 후보를 만든 모델에게 그 규칙이 틀리는 상황을 직접 만들어 보게 하고, 그 반례를 견디는지 확인한 뒤에야 저장 후보로 인정한다. 3회 규칙이 사람 수로 취향을 걸러 내는 장치라면, 자기 반박은 한 건 안에서 규칙의 적용 범위를 좁혀 보는 장치다.

출력은 다섯 항목이다. 원인 한 줄, 저장 위치 한 곳, 저장할 문장, 취향과 규칙 판정과 근거, 그리고 이 문장을 승인해야 하는 사람이다. 마지막 항목이 있어서 프롬프트의 출력이 곧바로 브레인에 들어가지 않고 승인 대기 상태로 남는다.

방금 내가 네 결과물을 고쳤다. 결과물 말고 원인을 고치고 싶다.

내가 고친 내용: (붙여넣기)
작업 종류: (…)

할 일
1. 이 교정이 필요했던 원인을 하나로 특정해라.
 (지식 부재 / 낡은 사실 / 규칙 미기록 / 방법 미기록 / 절차 미기록 / 안전장치 부재)
2. 아래 라우팅 표에서 저장 위치를 하나 고르고,
 그 위치에 넣을 문장을 그대로 복사 가능한 완성형으로 써라.
3. 이것이 이번 한 번짜리 취향인지, 다음에도 적용될 회사 규칙인지 판정하고 근거를 대라.
4. "회사 규칙"이라고 판정했다면, 이 규칙이 틀리는 상황을 하나 만들어
 스스로 반박해 보고 그래도 살아남는지 확인해라.

출력
- 원인 한 줄
- 저장 위치 한 곳
- 저장할 문장
- 취향/규칙 판정과 근거
- 이 문장을 승인해야 하는 사람

교정 라우팅 표

프롬프트 3이 참조하는 표다. 교정이 드러낸 결함 유형을 저장 위치와 저장 형태로 함께 보낸다. 형태를 지정하는 이유는 같은 위치에 들어가도 메타가 빠지면 나중에 쓸 수 없기 때문이다.

저자가 두 표를 직접 잇지는 않지만, 라우팅 표의 저장 위치는 앞서 제시한 네 층에 그대로 대응한다. 교정 하나를 어디에 저장하느냐가 곧 브레인의 어느 층을 보강하느냐를 결정한다.

마지막 항목이 예외인 점이 중요하다. 위험한 행동은 문서로 옮기는 대상이 아니라 브레인 밖의 권한 층에서 처리해야 한다.

마지막 행이 실무에서 가장 자주 틀리는 자리다. 돈이 나가거나 회사 밖으로 나가는 행동을 문장으로 막으면 안 된다. 저자의 표현으로 "함부로 보내지 마세요"는 정책이 아니라 희망이다. 발송과 결제와 삭제는 권한과 승인 단계로 막고, 프롬프트에는 그 게이트가 있다는 사실만 적는다. 가드레일을 프롬프트 층이 아니라 권한 층에 두라는 주문이다.

3회 규칙

교정이 중요하다는 말을 들은 팀은 반대 방향으로 실패한다. 모든 교정을 저장하기 시작하면 3개월 뒤 정책 파일이 200줄이 되고 그중 절반은 한 사람의 그날 기분이다. 승격 기준은 횟수와 사람 수를 함께 본다.

"서로 다른 사람"이 핵심이다. 한 사람이 세 번 같은 말을 한 것은 회사 규칙이 아니라 그 사람의 취향이고, 취향을 정책으로 올리면 나머지 팀은 그 규칙을 우회하는 방법을 배우게 된다.

저장할 때 붙이는 메타는 세 가지이며, 이 셋이 없는 문장은 시간이 지나면 유령 권위가 된다.

워커 명세 프롬프트

네 번째 프롬프트는 반복 업무를 다음 사람이 그대로 재실행할 수 있는 명세로 바꾼다. 명세에 반드시 들어가는 항목이 여덟 개다.

금지 항목은 두 가지다. "적절히", "필요시", "잘" 같은 판단 유예 표현을 쓰지 못하게 하고, 중단 조건이 없는 명세를 명세로 인정하지 않는다. 판단 유예 표현이 금지되는 이유는 명세를 쓴 사람과 실행하는 사람이 다르기 때문이다. "적절히 판단한다"고 적으면 판단 기준이 명세에 남지 않고 실행자의 머릿속에 남아, 다음 사람이 재실행할 수 있다는 워커의 전제가 깨진다. 저자의 근거는 두 문장으로 요약된다. 중단 조건이 없는 워커는 워커가 아니라 자동화된 사고다. 실패 신호를 적어 두지 않으면 잘못된 결과가 조용히 몇 주 동안 실행된다.

아래 업무를 다음 사람이 그대로 다시 실행할 수 있는 명세로 바꿔라.

업무: (…)
좋은 결과의 예: (붙여넣기)
나쁜 결과의 예: (붙여넣기)

명세에 반드시 포함할 것
- 이름: 동사로 시작하는 한 줄
- 입력: 시작하려면 반드시 있어야 하는 것. 없으면 시작하지 않는다
- 참조: 회사 지도에서 열어야 할 파일과 그 이유
- 단계: 번호가 붙은 실행 순서. 각 단계에 판단 기준을 명시
- 출력: 형식·길이·저장 위치
- 중단 조건: 이럴 땐 멈추고 사람에게 묻는다 (최소 3가지)
- 승인: 결과가 회사 밖으로 나가기 전 확인해야 하는 사람
- 실패 신호: 이 결과가 잘못됐다는 걸 무엇으로 알아채는가

금지
- "적절히", "필요시", "잘" 같은 판단 유예 표현
- 중단 조건이 없는 명세

승격 심사 프롬프트

다섯 번째 프롬프트는 승격 게이트다. 브레인이 오염되는 가장 빠른 길이 에이전트가 자기 교정을 자기가 저장하는 것이라는 진단에서 나온다. 프롬프트는 옹호를 금지하고 반대편에 서서 검토하게 한다.

출력은 네 항목이다. 승인과 조건부 승인과 보류 중 하나를 고르고, 조건부라면 고쳐 쓴 문장을 내고, 이 항목이 대체하는 기존 항목을 목록으로 적고, 재검토 시점을 정한다. 세 번째 질문이 3회 규칙과 같은 목적을 프롬프트 안에서 다시 확인하는 자리다.

아래 항목을 회사 전체의 기본값으로 승격할지 심사해라.
옹호하지 말고 반대편에 서서 검토해라.

제안 항목: (…)
제안자: (…)
근거로 제시된 사례: (…)

심사 질문
1. 이 문장이 틀렸다면, 어디서 처음 티가 나는가
2. 기존 결정·정책과 충돌하는 것이 있는가. 있다면 무엇을 대체하는가
3. 한 사람의 취향이 회사 규칙으로 올라가는 것은 아닌가.
 다른 팀 상황 두 개를 만들어 검증해라
4. 이 규칙을 지킬 수 없는 상황은 언제인가. 그 예외를 문장에 포함해라
5. 소유자는 누구이고, 언제 다시 검토해야 하는가

출력
- 승인 / 조건부 승인 / 보류 중 하나
- 조건부라면, 고쳐 쓴 문장
- 이 항목이 대체하는 기존 항목 목록
- 재검토 시점

주간 헬스체크 프롬프트

여섯 번째 프롬프트는 유지 장치다. 저자는 브레인이 만드는 것보다 유지가 어렵다고 보고 주 1회 실행을 권한다. 이번 주 팀의 요청과 결과를 근거로 다섯 가지 구멍을 찾는다.

출력은 구멍, 증거가 된 요청, 어디에 무엇을 추가하는가, 소유자 네 열의 표다. 마지막에 한 줄을 더 요구하는데, 이번 주 브레인이 지난주보다 나아졌는지와 그 판단 근거다.

다섯째 항목이 브레인을 가볍게 유지한다. 아무도 열지 않는 파일은 지식이 아니라 소음이므로 지우거나 지도에서 내린다.

이번 주 우리 팀이 너에게 한 요청과 그 결과를 근거로, 회사 브레인의 구멍을 찾아라.

찾을 것
1. 답을 못 찾아 사람에게 되물은 항목 — 무엇이 없어서였는가
2. 서로 충돌한 출처 — 어느 쪽이 이겼고, 그것이 규칙대로였는가
3. 인용했지만 확정일이 오래된 항목
4. 같은 교정이 두 번 이상 반복된 항목 — 저장이 안 됐다는 뜻이다
5. 아무도 열지 않은 파일 — 지도에 있지만 쓰이지 않는다

출력
| 구멍 | 증거가 된 요청 | 어디에 무엇을 추가하는가 | 소유자 |

마지막 한 줄: 이번 주 브레인은 지난주보다 나아졌는가. 판단 근거는 무엇인가

저장 위치와 진입점

파일로 시작하는 것이 맞다는 입장이다. 지도 파일 하나와 폴더 여섯 개면 첫 버전으로 충분하다. 코딩 에이전트를 쓰는 팀이라면 진입점에 이미 표준이 있다.

두 파일을 잇는 방식으로 CLAUDE.md 첫 줄에 @AGENTS.md 한 줄을 넣는 형태가 흔히 쓰인다. 진입점 하나에 지도를 두고 나머지는 폴더로 둔다.

승격 게이트를 새로 살 필요가 없다는 지적도 붙는다. 브레인을 레포 안 파일로 두면 승격은 풀 리퀘스트가 되고 검토는 코드 리뷰가 되며 이력은 커밋 로그가 된다. 별도 도구를 사기 전에 이미 갖고 있는 리뷰 장치부터 쓰는 편이 빠르다는 것이다.

이 대응은 앞의 세 요구를 한꺼번에 충족한다. 프롬프트 5가 요구한 반대편 검토는 리뷰어 지정으로, 저장 메타 중 확정일과 소유자는 커밋 정보로, 무엇을 대체했는가는 diff로 각각 남는다. 브레인을 문서 도구가 아니라 저장소에 두라는 권고가 여기서 나온다.

파일 방식의 한계도 인정한다. 팀이 커지고 도구가 갈라지면, 다시 말해 누군가는 Claude Code를 쓰고 누군가는 Cursor를 쓰고 누군가는 ChatGPT를 쓰는 상태가 되면 사본 문제에 부딪힌다. 저자는 이 지점을 노린 제품으로 출발점 글이 소개한 HQ를 든다. 다만 순서를 바꾸지 말라고 못 박는다. 도구가 브레인을 만들어 주지 않으며, 지도와 라우팅 표와 리뷰 게이트가 이미 작동하고 있어야 도구가 그것을 여러 사람에게 복제해 준다.

결과

정량 실험은 없다. 대신 운영 지표를 하나 제안하는데, 관리 지표는 파일 개수가 아니라 충돌 개수여야 한다는 것이다. 파일이 늘어도 충돌이 없으면 건강하고, 파일이 적어도 충돌이 잦으면 이미 망가진 상태다.

지표를 개수에서 충돌로 옮기면 측정되는 대상이 달라진다. 파일 개수를 세면 자료를 더 넣는 일이 성과로 잡히지만, 충돌 개수를 세면 서로 어긋나는 문장을 정리하는 일이 성과가 된다. 충돌을 세려면 프롬프트 6의 두 번째 항목처럼 어느 출처가 이겼고 그것이 규칙대로였는지를 기록해 두어야 하므로, 지표와 주간 점검이 같은 절차 안에서 맞물린다.

브레인이 망가지는 방식은 네 가지로 정리된다.

네 방식은 앞에서 제시한 장치와 짝을 이룬다. 아카이브화는 지도 우선 원칙이, 유령 권위는 저장 메타 세 가지가, 검토 없는 자동 승격은 프롬프트 5의 심사 게이트가 각각 대응 지점이다. 랩탑 감금만 파일 방식 자체의 한계로 남아 도구 이야기로 넘어간다.

착수 절차는 일주일 단위로 제시한다.

다섯 단계는 앞에서 본 프롬프트 순서와 그대로 맞물린다. 2단계가 프롬프트 1, 3단계가 프롬프트 2, 4단계가 프롬프트 3이고, 5단계의 금요일 점검이 프롬프트 6이다. 프롬프트 4와 5는 첫 주 목록에 들어가지 않는데, 워커 명세와 승격 심사는 교정이 실제로 쌓인 다음에 필요해지는 단계이기 때문이다.

한 달짜리 설계를 하지 말라는 것이 마지막 당부다. 아름다운 아카이브 하나보다 매주 반복되던 실수 하나를 없애는 작은 브레인이 낫다는 이유에서다. 본문은 첫 테스트에서 에이전트가 머뭇거리거나 추측하거나 낡은 답을 내놓는 지점이 브레인이 다음에 무엇을 필요로 하는지 알려 주는 유일한 신호라는 문장으로 닫는다.

한계

근거가 저자의 현장 경험이다. 4층 구조와 3회 규칙과 중단 조건 3개 같은 수치에 실측이나 사례 데이터가 붙어 있지 않다.

출발점이 된 J.B.의 원글은 참고 목록에 X 계정 링크로만 걸려 있다. 각 프롬프트가 원글에서 온 것인지 저자가 작성한 것인지 본문에 표시되지 않아 원 주장과 확장분을 가르기 어렵다.

글 말미가 자사 방법론(AX Ops) 링크로 이어지는 마케팅 동선이다. 함께 소개하는 HQ는 자사 제품이 아니라 출발점 글이 든 타사 제품이고, 도구가 브레인을 만들어 주지 않는다고 선을 긋기도 한다. 그렇더라도 자료를 읽을 때 프레임과 홍보를 갈라 볼 필요가 있다.

프롬프트 6종은 모두 사람이 직접 붙여 넣는 형태다. 이 절차를 스킬이나 훅으로 자동화하는 경로는 다루지 않는다. 프롬프트 1이 요구하는 "지난 30일 채팅 기록 훑기"도 도구가 세션 이력을 노출해야 성립하는데, 어떤 도구에서 이 조회가 가능한지는 언급되지 않는다.

지도 파일이 커진 뒤의 운영은 열려 있다. 폴더 여섯 개 구조가 수십 명 규모에서 어떻게 유지되는지, 진실의 순서를 누가 갱신하는지에 대한 답이 없다.

원문 페이지의 정보 요소 일부는 이 저장소에 이미지로 남지 않았다. 4층 표와 교정 라우팅 표는 HTML 표라서 본문 표로 옮겼고, 흐름 도식 두 개는 <img> 요소가 아니어서 개별 파일로 수집되지 않았다. 도식을 임베드하려면 수집 단계에서 두 영역을 다시 지정해야 한다.

핵심 용어

관련 페이지

• Effective Context Engineering for AI Agents: 컨텍스트를 늘릴수록 판단이 나빠진다는 이 글의 전제를 attention budget과 context rot 개념으로 정식화한 자료
• GBrain 생태계 자료 지도와 학습 경로: markdown 파일로 조직 지식을 쌓아 에이전트 메모리로 쓰는 계열을 다룬다. 그 계열은 제품에, 이 글은 운영 규칙에 무게를 둔다
• DESIGN.md: A format specification for describing a visual identity to coding agents: 시각 아이덴티티를 단일 .md로 기술해 코딩 에이전트에 넘기는 규격. 지도 파일과 같은 발상을 디자인 시스템에 적용했다
• Agent Skills Overview (agentskills.io): AGENTS.md 계열 진입점 표준의 확산을 다룬다. 해당 페이지는 포맷을 지원하는 클라이언트 42개 목록을 정리한다
• SkillOpt: Executive Strategy for Self-Evolving Agent Skills: 승격 전에 게이트를 두는 구조가 같다. 이 글은 사람이, SkillOpt은 held-out validation gate가 게이트를 지킨다
• Agent Skills: 워커 명세의 중단 조건과 실패 신호 요구를 non-negotiable verification이라는 원칙으로 부른다
• Why Do Multi-Agent LLM Systems Fail?: 프롬프트 5가 막으려는 자기 승격 실패가 MAST의 Task Verification 카테고리와 겹친다
• The Art of Loop Engineering (Sydney Runkle, 2026-06-16): 주간 헬스체크는 loop 3과 loop 4의 자기 개선 루프에 해당한다
• Beyond the Prompt: Claude Code (Arpan Patel, 2026-05-26): CLAUDE.md를 지식 베이스가 아니라 가드레일로 쓰라는 원칙과 실패에서 룰을 뽑는 절차를 Claude Code 사례로 다룬다