컴퍼니 브레인이란?
새로 입사한 직원은 회사의 맥락과 히스토리를 물어볼 곳이 필요합니다. 가격은 누가 정하는지, 작년 그 결정은 왜 그렇게 났는지, 환불 규정은 무엇인지를 묻습니다. 그런데 답은 흩어져 있습니다. 회의록은 누군가의 노트북에 있고, 정책은 메일 어딘가에 있고, 결정의 맥락은 사람 머릿속에만 있습니다. 그래서 회사의 지식 체계를 한 군데 모아놓은 곳이 필요합니다.
컴퍼니 브레인은 AI가 회사의 업무와 맥락을 알고 일하게 만드는 체계입니다. 세 가지로 이루어집니다. 검증한 업무 방식을 담은 스킬 라이브러리, 도구와 데이터를 잇는 MCP 허브, 일하며 쌓인 기록을 모은 LLM 위키입니다. 이 셋은 일이 실제로 벌어지는 서비스 앱 위에 섭니다.
컴퍼니 브레인은 IT 부서가 도구 하나를 도입하는 일이 아닙니다. 세 개의 구성 요소를 나눠 만들고, 그 결과가 서로 맞물려 돌아가게 하는 일입니다. 사람은 무엇이 맞는지 정하고, AI는 그 기준대로 실행하고 기록합니다. 이 페이지는 셋이 각각 무엇인지 다룹니다. 그중 LLM 위키를 직접 만드는 방법은 실습 편에 있습니다.
창고가 아니라 브레인이라고 부르는 이유가 있습니다. 사람의 뇌는 겪은 것을 전부 담지 않습니다. 중요한 것만 남기고 나머지는 잊습니다. 컴퍼니 브레인도 같은 맥락입니다. 모든 파일을 쌓아 두는 데이터 저장소가 아니라, 판단에 필요한 맥락만 걸러 남기는 지식 체계입니다. 그래서 설계의 핵심은 망각과 기억 사이의 균형점을 잡는 일입니다.
컴퍼니 브레인의 유래
개인이 남기는 메모에서 시작해 회사의 기억으로 발전해왔습니다.
-
1
2025 Anthropic · 파일 메모리Anthropic 엔지니어링 글
AI에게 긴 일을 시키면 앞부분을 잊습니다. 그래서 대화창 안에 다 넣지 말고, 대화 밖 파일에 메모를 남기게 했습니다. 다음 작업은 그 파일을 다시 읽고 시작합니다.
기억의 거처를 대화창에서 파일로 옮겼습니다. 대화가 끝나면 소멸하던 맥락이 파일에 남아 다음 작업으로 이어집니다.
-
2
2026-04-04 Andrej Karpathy · LLM 위키카파시의 X 글llm-wiki gist 원문
메모를 흩어진 파일이 아니라 위키라는 한 덩어리로 묶었습니다. 원본 문서는 손대지 않고 그대로 둡니다. 위키를 쓰고 고치는 쪽은 사람이 아니라 LLM입니다. 규칙은 따로 파일에 적어 둡니다.
위키의 유지 주체를 사람에서 LLM으로 바꿨습니다. 위키 제작이 어려운 이유는 문서 정리와 상호 참조가 갈수록 복잡해지기 때문입니다. LLM은 이 지루한 작업을 지치지 않고 수행합니다.
-
3
2026-04-05 Garry Tan · GBrainGitHub 저장소
실리콘밸리의 대표 액셀러레이터 Y Combinator를 이끄는 Garry Tan이 이 개념을 직접 만들어 공개했습니다. 회의와 메일을 계속 넣어 두면, 사람이 보지 않는 사이에도 AI가 정리와 병합을 이어 갑니다.
개념을 자율적으로 작동하는 시스템으로 구현했습니다. 다만 적용 범위는 아직 개인 한 사람입니다.
-
4
2026년 4월 말 Y Combinator · Company Brain당시 페이지 아카이브
Y Combinator가 개인용이던 것을 회사 단위로 넓히자고 제안하며, Summer 2026 창업 주제 목록에 올렸습니다. 파트너 Tom Blomfield가 썼습니다. AI 자동화를 막는 것은 이제 모델 성능이 아니라 회사에 흩어진 업무 지식이라는 진단입니다.
이 컨셉에 명확한 이름을 붙이고 적용 단위를 회사로 확장했습니다. 문서 검색이나 챗봇을 넘어, 환불 처리와 가격 예외 권한까지 담은 회사 운영 방식의 가이드로 정의했습니다.
컴퍼니 브레인의 세 가지 구성 요소
스킬 라이브러리
방법숙련자가 일하는 방식을 적어 둔 매뉴얼입니다. 사람이 읽는 문서가 아닙니다. AI가 읽고 그대로 실행하는 파일입니다. 검증을 통과한 것만 올려야 라이브러리가 유지됩니다.
- 포함 범위 업무 절차, 판단 기준, 체크리스트
- 부재 시 리스크 품질 편차 발생, 검증된 방식 소실
MCP 허브
연결AI가 서비스 앱과 데이터에 닿는 표준 방식입니다. 서비스마다 연결 방식이 다르면 붙일 때마다 새로 만들어야 합니다. 그래서 방식을 하나로 정해 둡니다. 권한을 어디까지 열지도 여기서 정합니다.
- 포함 범위 MCP 서버, 커넥터, 권한 범위
- 부재 시 리스크 수작업 이관 비용 지속
LLM 위키
기억일하는 과정에서 나온 결정과 근거가 쌓이는 곳입니다. 사내 위키와 다른 점은 읽고 쓰는 주체입니다. 쓰는 쪽도 먼저 읽는 쪽도 AI입니다. 설계와 제작 순서는 실습 편이 다룹니다.
- 포함 범위 회의록, 정책, 결정 기록, 변경 이력
- 부재 시 리스크 동일 질의 반복, 지식 누적 부재
서비스 앱
바이브코딩 앱재고 조회, 견적 계산, 승인 요청처럼 직원이 매일 쓰는 화면을 AI로 직접 만든 것입니다. 예전에는 SaaS를 사거나 개발팀에 요청해야 했습니다. 이제는 필요한 것만 골라 바로 만듭니다. 여기서 활용된 데이터들이 컴퍼니 브레인의 원재료가 됩니다.
- 포함 범위 바이브코딩으로 만든 업무 화면, 조회 도구, 자동화 스크립트
- 부재 시 리스크 업무 데이터가 외부 서비스에 축적
LLM 위키의 네 가지 구성
Documents · Data
원본 자료회의록과 정책, 결정 기록 같은 문서와 업무 시스템에 쌓인 데이터가 재료입니다. 원본은 가공하지 않고 그대로 보존합니다. 데이터는 시점을 붙인 기록으로 들어오며, 원 시스템에 실시간으로 연결되지는 않습니다. 위키의 모든 문장은 이 원본으로 역추적할 수 있어야 합니다.
- 포함 범위 원본 문서, 시점이 찍힌 업무 데이터, 작성일, 작성자
- 부재 시 리스크 답변의 근거 소실
Ontology
분류와 판단 기준회사가 무엇을 어떤 이름으로 부를지, 어디까지를 정책으로 보고 어디부터를 결정으로 볼지 규정합니다. 민감 정보의 경계도 이 층에서 정합니다.
- 포함 범위 분류 체계, 페이지 형식, 민감도 기준, 출처 규칙
- 부재 시 리스크 분류 일관성 붕괴, AI의 임의 판단
Knowledge Graph
문서 사이의 관계어떤 결정이 어떤 정책에 연결되는지, 어떤 회의가 어떤 제품을 다뤘는지를 내부 링크와 태그로 잇습니다. 문서가 점이 되고 관계가 선이 됩니다.
- 포함 범위 내부 링크, 태그, 목차
- 부재 시 리스크 연관 문서 누락, 맥락 단절
Search / RAG
찾아서 답하는 층질문에 해당하는 대목을 찾아 출처와 함께 답합니다. 위키에 근거가 없으면 추측하지 않고 없다고 밝힙니다.
- 포함 범위 검색, 인용, 출처 표기 규칙
- 부재 시 리스크 수작업 탐색, 출처 없는 답변
온톨로지는 원래 철학 용어입니다. 정보 시스템에서는 어떤 영역에 무엇이 존재하고 그것들이 서로 어떤 관계인지를 형식으로 규정한 것을 뜻합니다. 테이블 스키마보다 범위가 넓습니다. 스키마는 열의 자료형만 정하지만, 온톨로지는 개체와 속성과 관계에 더해 지켜야 할 규칙까지 규정합니다.
목적은 기계가 뜻을 읽게 만드는 데 있습니다. 데이터베이스는 CUST_1024가 무엇인지 모릅니다. 값이 담긴 칸일 뿐입니다. 온톨로지는 그 칸을 고객으로 정의하고, 고객 한 명이 주문 여러 건과 이어진다는 관계까지 기록합니다. 그래서 "이 고객이 지난 분기에 무엇을 샀는가"라는 질문에 사람이 테이블을 결합하지 않아도 시스템이 답을 찾아냅니다.
팔란티어가 기업에 공급하는 플랫폼이 Foundry입니다. 공식 문서는 Foundry를 "온톨로지로 구동되는 기업용 운영체제"로 소개하고, 온톨로지를 그 핵심으로 규정합니다. Foundry의 온톨로지는 회사에 흩어진 데이터 위에 얹는 운영 계층이며, 문서는 이를 조직의 디지털 트윈이라 부릅니다. 구성은 두 종류입니다.
- 의미 요소 객체와 속성과 링크로 구성됩니다. 설비와 제품 같은 물리 자산부터 고객 주문과 금융 거래 같은 개념까지 데이터에 연결합니다.
- 운동 요소 액션과 함수와 동적 권한으로 구성됩니다. 현업의 결정을 받아 기존 시스템에 반영합니다.
| 구분 | 팔란티어 온톨로지 | LLM 위키의 ① 문서·데이터 + ② 온톨로지 + ③ 지식 그래프 |
|---|---|---|
| 재료 | 정형 데이터. ERP, 센서, 거래 기록 | 비정형 문서가 중심. 회의록, 정책, 결정 기록. 정형 데이터도 기록 형태로 함께 들어옴 |
| 정의 대상 | 객체와 속성과 링크 | 분류 체계와 문서 사이의 관계 |
| 형태 | 타입 스키마 + 실행 함수 | 규칙 파일 + 내부 링크와 태그 |
| 담는 것 | 회사가 지금 어떤 상태인지 | 회사가 왜 그렇게 하기로 했는지 |
| 시점 | 원 시스템과 연결된 실시간 현재값 | 기록 시점의 값과 그 변경 이력 |
| 순서 | 정의가 먼저. 객체와 액션을 설계해야 쓰기 시작 | 자료가 먼저. 문서를 넣으면 AI가 구조를 잡음 |
| 실행 | 액션이 기존 시스템에 직접 반영 | 없음. 실행은 MCP 허브가 맡음 |
| 유지 주체 | 데이터 엔지니어링 팀 | AI가 읽고 쓰고 갱신 |
| 구현 기간 | 데이터 통합 프로젝트. 수개월에서 수년 | 폴더와 파일. 당일 착수 가능 |
팔란티어의 온톨로지는 사실의 현재값을 관리하고, LLM 위키의 문서·데이터와 온톨로지, 지식 그래프는 판단의 로그를 축적합니다. 전자는 지금 재고가 몇 개인지 답하고, 후자는 재고 기준을 왜 7일에서 14일로 바꿨는지 답합니다. 위키에도 데이터가 들어가지만 시점이 찍힌 기록이라 현재값을 대신하지 못합니다. 실시간 데이터가 필요하면 MCP 허브로 원 데이터를 가진 시스템에 접속해 값을 가져옵니다.
경쟁사도 같은 모델을 쓴다면, 어떻게 차별화해야 할까요?
경쟁사도 같은 모델을 사용한다면, 유일한 차별점은 컴퍼니 브레인이 될 것입니다. 그 차별을 만드는 것은 우리 회사에만 있는 데이터와 우리 회사만 아는 워크플로우입니다.
맥킨지 Lilli
맥킨지는 100년 가까이 쌓은 자사 지식을 한곳에 모았습니다. 지식 출처 40곳과 문서·인터뷰 기록 10만 건이 재료입니다. 전사 배포 뒤 임직원 72%가 쓰고, 자료를 찾고 종합하는 시간은 30% 줄었습니다.
모건스탠리 AI @ Morgan Stanley Assistant
모건스탠리는 사내에 쌓인 지식 자산 전체를 AI가 읽게 했습니다. 상담사 팀의 98%가 이 도구를 씁니다. 경쟁사는 같은 모델을 살 수 있지만 그 자료는 가져가지 못합니다.
스트라이프 Radar
스트라이프는 결제망에 쌓인 70조 개 데이터로 학습했습니다. 그래서 들어온 카드의 92%를 이미 본 카드로 알아봅니다. 도입한 곳의 사기는 평균 32% 줄었습니다. 같은 알고리즘을 사도 데이터가 없으면 이 정확도는 나오지 않습니다.
존디어 See & Spray
컴퓨터 비전은 어디서나 구할 수 있는 기술입니다. 존디어는 그 기술을 자사 장비와 현장 데이터, 딜러망에 붙였습니다. 그 결과 초당 2,100제곱피트를 훑어 잡초에만 약을 뿌리고, 제초제를 평균 59% 줄였습니다.
여기서 만드는 것은 AI가 아닙니다. AI가 우리 회사를 알게 만드는 환경입니다.
컴퍼니 브레인이라는 이름이 어디서 나왔는지, 그리고 이 설계가 무엇을 근거로 삼았는지 보여 주는 자료입니다.
ingest·query·lint 세 동작으로 이루어진 구조. 위키를 사람이 아니라 LLM이 쓰고 유지한다는 것이 이 글의 핵심입니다. 실습 편에서 나누는 4역할이 그 구현입니다.
Karpathy
Effective context engineering for AI agents
Anthropic Engineering (2025) · 에이전트가 컨텍스트 밖 파일에 메모를 남겨 "시간이 지나며 지식 베이스를 쌓는다"는 파일 메모리 개념. 기록 파일과 규칙 파일을 나눠 두는 설계가 여기서 나왔습니다.
Anthropic
"Context engineering" (프롬프트 엔지니어링을 넘어서)
Andrej Karpathy (前 Tesla AI 총괄, OpenAI 창립 멤버) · 컨텍스트를 모델의 작업 기억, 곧 RAM에 비유하며, 무엇을 읽히느냐가 곧 성능이라고 짚습니다.
Karpathy
Building effective agents
Anthropic (2024) · 정해진 순서로 도는 "워크플로우"와 역할 분리의 효용을 다룹니다. 실습 편의 4역할 설계가 이 글을 근거로 삼았습니다.
Anthropic
구조를 알았으면, 이제 만들어 봅니다
샘플 문서 8개를 받아 폴더에 넣고, 프롬프트를 위에서부터 하나씩 붙여 넣으면 위키 한 벌이 나옵니다.
만든 다음에는 점검 카드로 그것을 믿어도 되는지 재봅니다.