반은 맞고, 반은 아직 부족합니다. 노션에 문서가 많다고 해서 바로 AI Native 회사가 되는 건 아니에요. AI가 읽을 수 있는 방식으로 기록되어 있고, 그 기록이 반복 업무와 연결되고, 실패했을 때 다음 실행이 좋아지는 구조까지 있어야 합니다.
최근 YC에서 나온 영상을 보면서 이 생각이 더 분명해졌어요.
기록되지 않은 일은 AI에게 일어나지 않은 일입니다.
사람끼리는 “그때 얘기했잖아요”하면서 맥락을 쉽게 전달하고 나눌 수 있어요. AI에게는 통하지 않아요. 회의에서 말했어도, 슬랙에서 흘러갔어도, 고객과 통화하면서 중요한 힌트를 얻었어도, AI가 읽을 수 있는 곳에 남아 있지 않으면 그 일은 회사의 자산 안으로 들어오지 않습니다.
저는 요즘 헤르메스 에이전트를 제 AI 에이전트로 쓰고 있어요. 오픈클로도 써봤는데, 두 도구를 비교해보면 헤르메스는 피드백을 받고 스킬을 개선하거나 다음 작업에 반영하는 흐름이 확실히 더 잘 맞았습니다. 물론 영상에 나온 YC의 모니터링 에이전트처럼 실패한 쿼리를 밤사이에 분석하고, 필요한 도구를 만들고, 코드까지 배포하는 수준은 아직 아닙니다.
하지만 AI에게 일을 시키는 것”에서 한 단계 더 나아가, 매번 작업이 끝날 때마다 업무 방식이 조금씩 좋아지는 루프를 만들려고 합니다.
출처: YC 유튜브
핵심 요약
AI 에이전트를 잘 쓰려면 먼저 회사의 맥락이 AI에게 읽혀야 합니다.
컴퍼니 브레인은 자료 창고가 아니라, 회사가 어떻게 일하는지 알려주는 살아 있는 운영체계입니다.
좋은 AI 업무 시스템은 센서, 정책, 도구, 검수, 학습 루프를 갖습니다.
기록되지 않은 회의, 고객 대화, 의사결정은 AI에게 없는 일과 같습니다.
작은 조직일수록 처음부터 “AI가 읽을 수 있는 회사”로 만드는 게 유리합니다.
AI를 붙였는데 회사는 왜 그대로일까요?
많은 분들이 AI를 생산성 도구로 먼저 생각합니다.
개발자에게 코파일럿을 붙이면 코드를 더 빨리 짜고, 마케터가 ChatGPT를 쓰면 콘텐츠를 더 빨리 만들고, 고객지원팀이 AI 답변 초안을 쓰면 응답 시간이 줄어든다는 식이에요.
물론 이것도 도움이 됩니다. 저도 매일 그렇게 쓰고 있고요. 그런데 이 방식은 기존 일하는 방식에 AI라는 더 강한 엔진을 붙이는 것에 가깝습니다.
영상에서는 이 관점이 충분하지 않다고 말합니다. AI의 진짜 변화는 “사람 한 명의 생산성을 20% 올리는 것”이 아니라, 회사라는 구조 자체를 다시 설계하는 데 있다는 거예요.
기존 회사는 위계로 움직였습니다. 대표가 방향을 정하고, 팀장이 전달하고, 실무자가 실행하고, 다시 보고가 올라오는 구조입니다. 사람은 그 사이에서 정보를 전달하는 통로가 됩니다.
그런데 AI가 들어오면 이 구조가 달라질 수 있어요. 회사 안의 지식, 고객 대화, 의사결정 기준, 반복 업무가 AI가 읽을 수 있는 형태로 정리되면, AI는 단순 보조자가 아니라 회사의 운영 루프 안으로 들어올 수 있습니다.
여기서 컴퍼니 브레인이 중요해집니다.
컴퍼니 브레인은 문서함이 아니라 회사의 작동 방식입니다
컴퍼니 브레인이라고 하면 많은 분들이 노션 문서함을 떠올립니다.
회의록 DB, 프로젝트 DB, 고객 DB, 업무 매뉴얼, 체크리스트를 잘 정리해두는 것이죠. 이것도 출발점으로는 맞습니다. 하지만 여기서 멈추면 AI는 아직 제대로 일하기 어렵습니다.
진짜 컴퍼니 브레인은 이런 질문에 답할 수 있어야 해요.
우리 회사는 어떤 기준으로 의사결정하나요?
반복되는 업무는 어떤 순서로 처리하나요?
고객 문의가 들어오면 무엇을 먼저 확인하나요?
어떤 일은 AI가 처리해도 되고, 어떤 일은 사람이 승인해야 하나요?
지난번 실패한 업무는 왜 실패했고, 다음에는 무엇을 바꿔야 하나요?
단순히 자료를 모아두는 것이 아니라, 회사가 일하는 방식을 AI가 이해할 수 있게 만드는 겁니다.
저는 이전 글에서 2026년 1인 대표에게 필요한 세 가지 무기로 AI 에이전트, 바이브 코딩, 컴퍼니 브레인을 이야기했어요. 그중에서도 시간이 갈수록 더 중요해지는 건 컴퍼니 브레인이라고 느낍니다.
AI 에이전트는 실행할 수 있습니다. 바이브 코딩은 작은 도구를 만들 수 있게 해줍니다. 그런데 어떤 맥락에서 무엇을 실행해야 하는지, 어떤 기준으로 판단해야 하는지, 이전에 무슨 일이 있었는지 모르면 AI는 계속 헛돌게 됩니다.
결국 AI 에이전트는 컴퍼니 브레인을 먹고 일합니다.
회사가 스스로 좋아지는 AI 루프
영상에서 가장 인상 깊었던 개념은 “스스로 개선되는 AI 루프”였습니다.
이 루프는 대략 다섯 단계로 구성됩니다.
첫 번째는 센서입니다. 고객 이메일, 지원 티켓, 회의록, 제품 사용 데이터, 구독 취소, 코드 변경처럼 회사 안팎에서 생기는 신호를 모으는 단계예요.
두 번째는 정책과 의사결정 기준입니다. AI가 어디까지 해도 되는지, 언제 사람에게 물어봐야 하는지, 어떤 행동은 반드시 기록해야 하는지 정하는 규칙입니다.
세 번째는 도구입니다. 데이터베이스 조회, 캘린더 확인, 문서 업데이트, 코드 작성, API 호출처럼 AI가 실제로 쓸 수 있는 손발입니다.
네 번째는 검수 장치입니다. 위험한 작업은 사람이 승인하게 하거나, 발행 전 체크리스트를 통과하게 하거나, 잘못된 답변을 걸러내는 단계예요.
다섯 번째는 학습입니다. 실행 결과를 보고 무엇이 잘됐고 무엇이 실패했는지 기록한 뒤, 다음 실행에 반영하는 구조입니다.
이 다섯 가지가 연결되면 AI는 단순히 한 번 답하고 끝나는 도구가 아닙니다. 실패를 보고, 원인을 찾고, 도구나 문서를 고치고, 다음번에 더 잘 일하는 시스템이 됩니다.
이게 제가 헤르메스 에이전트에서 기대하는 방향이기도 해요. 지금은 아직 완성된 자동 개선 회사라고 말할 수는 없습니다. 하지만 업무가 반복될 때마다 스킬을 정리하고, 잘못 참조한 맥락을 고치고, 다음번에는 더 정확하게 일하게 만드는 흐름을 만들 수 있습니다.
예전에는 제가 매번 설명해야 했던 내용을 이제는 스킬로 남깁니다. 프로젝트별 맥락은 노션에 모으고, 반복되는 작업 방식은 스킬로 만듭니다. 그리고 에이전트가 실수하면 그 실수를 그냥 넘기지 않고 “다음에는 어떻게 다르게 해야 하는지”를 반영합니다.
작게 보면 귀찮은 정리처럼 보이지만, 길게 보면 이게 회사가 스스로 좋아지는 루프의 시작입니다.
YC의 모니터링 에이전트 사례
영상에서 나온 YC 사례가 이 개념을 아주 잘 보여줍니다.
처음에는 내부 데이터베이스에 질문하는 에이전트가 있었습니다. 예를 들면 “이 회사와 마지막으로 오피스아워를 한 게 언제지?” 같은 질문을 할 수 있는 수준이었어요. 조금 더 발전하자 “이 회사에 소개해줄 만한 관련 창업자 5명을 찾아줘” 같은 요청도 할 수 있게 됩니다.
여기까지는 우리가 흔히 생각하는 AI 비서에 가깝습니다. 사람의 일을 20%나 30% 정도 더 빠르게 도와주는 방식이죠.
진짜 전환점은 그다음입니다.
YC는 그 위에 모니터링 에이전트를 올렸습니다. 이 에이전트는 직원들이 어떤 질문을 했는지, 어떤 질문이 성공했고 어떤 질문이 실패했는지 봅니다. 그리고 실패한 질문에 대해 이렇게 묻습니다.
왜 실패했을까?
다른 데이터베이스 뷰가 필요했을까? 새로운 인덱스가 필요했을까? 도구가 부족했을까? 스킬 파일을 업데이트해야 했을까?
그리고 필요한 경우 밤사이에 코드를 만들고, 리뷰하고, 배포하는 흐름까지 연결됩니다. 다음 날 같은 질문을 하면 어제 실패했던 질문이 오늘은 성공하는 구조가 되는 거예요.
출처: YC 유튜브
이 부분이 정말 중요합니다.
AI가 똑똑한 답변을 하는 것과, AI가 실패를 바탕으로 업무 시스템을 고치는 것은 완전히 다른 단계입니다. 전자는 생산성 도구이고, 후자는 운영체계입니다.
작은 조직도 이 방향으로 갈 수 있습니다. 처음부터 코드 배포까지 자동화할 필요는 없어요. 대신 이렇게 시작할 수 있습니다.
AI가 자주 실패하는 질문을 모읍니다.
실패 원인이 자료 부족인지, 규칙 부족인지, 도구 부족인지 구분합니다.
반복되는 설명은 스킬이나 매뉴얼로 만듭니다.
프로젝트 맥락은 노션 페이지에 정리합니다.
다음번 같은 업무에서 그 맥락을 다시 쓰게 합니다.
이 정도만 해도 매번 처음부터 설명하는 구조에서 벗어날 수 있습니다.
기록되지 않은 일은 AI에게 일어나지 않은 일입니다
영상에서 가장 강하게 남는 문장은 이거였어요.
기록되지 않은 일은 AI에게 일어나지 않은 일입니다.
대표가 고객과 통화하면서 중요한 니즈를 들었습니다. 그런데 그 내용이 어디에도 남지 않았다면 AI는 알 수 없습니다. 회의에서 좋은 아이디어가 나왔습니다. 그런데 회의록이 없다면 AI는 그 아이디어를 다음 기획에 반영할 수 없습니다. 슬랙에서 중요한 의사결정을 했습니다. 그런데 검색 가능한 형태로 정리되지 않았다면 AI는 그 결정을 기준으로 삼기 어렵습니다.
사람은 기억으로 일할 수 있습니다. 하지만 AI는 접근 가능한 맥락으로 일합니다.
그래서 컴퍼니 브레인의 첫 번째 원칙은 기록입니다. 모든 것을 완벽하게 정리하자는 뜻은 아니에요. 처음부터 거창한 지식관리 시스템을 만들 필요도 없습니다.
대신 중요한 대화와 결정이 흘러가 버리지 않게 해야 합니다.
고객 미팅 후 핵심 니즈 3줄 남기기
회의가 끝나면 결정사항과 다음 액션 정리하기
반복 질문은 FAQ나 스킬로 바꾸기
프로젝트 진행 중 바뀐 기준은 노션 프로젝트 페이지에 반영하기
AI가 실수한 지점은 “다음부터 이렇게”라는 규칙으로 남기기
이렇게 남겨진 기록이 쌓이면 AI는 점점 더 회사답게 일할 수 있습니다.
출처: YC 유튜브
기록만 많다고 좋은 컴퍼니 브레인은 아닙니다
여기서 한 가지를 조심해야 합니다.
모든 것을 기록한다고 해서 자동으로 좋은 컴퍼니 브레인이 되는 건 아니에요. 기록이 너무 많아지면 오히려 AI도 사람도 찾기 어려워집니다.
영상에서도 이 부분을 짚습니다. 10만 시간의 녹음 파일을 그대로 AI에게 넣을 수는 없습니다. 중요한 건 원본을 남기는 것과 동시에, 그것을 압축하고 분류하고 합성하는 일입니다.
YC는 최근 몇 달 동안 쌓인 오피스아워 녹음을 바탕으로 기존 user manual을 새로 만들었다고 합니다. 창업자들에게 했던 조언을 주제별로 분류하고, 중요한 내용을 합성해서 더 나은 매뉴얼로 만든 거예요. 그리고 앞으로는 이 매뉴얼을 매달 업데이트할 수도 있습니다.
이게 좋은 컴퍼니 브레인의 모습에 가깝습니다.
정적인 문서함이 아니라 살아 있는 매뉴얼입니다. 새로운 경험이 들어오면 기존 문서와 비교하고, 쓸모 있는 내용은 반영하고, 오래된 내용은 고칩니다.
AI네버슬립의 업무에도 이 관점을 적용할 수 있습니다.
강의 상담에서 반복적으로 나오는 질문은 FAQ가 될 수 있습니다. 블로그를 쓰면서 자주 쓰는 구조는 글쓰기 스킬이 될 수 있습니다. 클라이언트 프로젝트에서 반복되는 체크리스트는 프로젝트 템플릿이 될 수 있습니다. 에이전트가 자주 헷갈리는 맥락은 더 명확한 프로젝트 브리프로 바꿀 수 있습니다.
이렇게 보면 문서 정리는 일이 끝난 뒤 하는 정리가 아닙니다. 다음 일을 더 잘하게 만드는 학습 장치입니다.
앞으로 중요한 건 툴보다 맥락입니다
영상 후반에는 내부 소프트웨어와 대시보드에 대한 이야기도 나옵니다.
예전에는 내부 도구 하나를 만드는 것도 큰 일이었습니다. 기획하고, 개발하고, 유지보수하고, 계속 고쳐야 했죠. 그런데 이제는 Codex나 Claude Code 같은 도구로 간단한 내부 대시보드나 업무 도구를 훨씬 빠르게 만들 수 있습니다.
그러면 진짜 중요한 자산은 소프트웨어 자체가 아닐 수 있어요.
중요한 건 “우리 회사가 어떻게 일하는지”에 대한 맥락입니다.
어떤 데이터를 봐야 하는지
어떤 순서로 판단해야 하는지
어떤 기준이면 승인하고, 어떤 기준이면 보류해야 하는지
어떤 고객에게 어떤 메시지를 보내야 하는지
어떤 업무는 자동화해도 되고, 어떤 업무는 사람이 봐야 하는지
이 맥락만 잘 정리되어 있으면 도구는 다시 만들 수 있습니다. 모델이 더 좋아지면 기존 도구를 버리고 더 좋은 방식으로 다시 만들 수도 있어요.
저도 헤르메스 에이전트를 쓰면서 이걸 많이 느낍니다. 중요한 건 특정 파일 하나, 특정 자동화 하나가 아닙니다. 중요한 건 “이 일을 어떻게 판단하고 처리해야 하는지”가 스킬과 프로젝트 맥락으로 남아 있는지입니다.
그래야 에이전트가 바뀌어도, 도구가 바뀌어도, 업무 방식은 계속 이어집니다.
출처: YC 유튜브
1인 대표와 작은 팀은 무엇부터 시작하면 좋을까
이 이야기가 큰 회사 이야기처럼 들릴 수도 있습니다. YC처럼 수많은 이메일, 오피스아워, 내부 데이터베이스가 있는 조직에서나 가능한 일처럼 보일 수 있어요.
그런데 저는 오히려 작은 조직이 더 빨리 시작할 수 있다고 봅니다.
작은 조직은 기존 위계가 두껍지 않습니다. 중간관리자도 많지 않고, 복잡한 승인 체계도 적어요. 대표가 직접 판단하고 실행하는 일이 많기 때문에, 처음부터 AI가 읽을 수 있는 방식으로 업무를 설계하기 좋습니다.
처음부터 거창한 자동화가 필요하지는 않습니다. 아래 정도면 충분히 시작할 수 있어요.
첫째, 모든 프로젝트에 한 장짜리 브리프를 만듭니다. 이 프로젝트의 목표, 현재 상태, 중요한 기준, 하지 말아야 할 것, 다음 액션을 적어두는 페이지입니다.
둘째, 회의와 상담은 끝나자마자 요약합니다. 녹음이 가능하면 녹음하고, 어렵다면 끝나고 바로 핵심 결정과 고객 니즈만이라도 남깁니다.
셋째, 세 번 이상 반복되는 일은 스킬로 만듭니다. 글쓰기 방식, 썸네일 요청 방식, 상담 후 정리 방식, 콘텐츠 발행 체크리스트처럼 반복되는 것은 매번 설명하지 않게 만들어야 합니다.
넷째, AI가 실패한 일을 그냥 넘기지 않습니다. 답변이 틀렸다면 “왜 틀렸는지”를 봐야 합니다. 정보가 없었는지, 기준이 애매했는지, 도구가 부족했는지에 따라 고치는 위치가 달라집니다.
다섯째, 사람이 승인해야 하는 선을 정합니다. 결제, 발행, 고객에게 보내는 민감한 메시지, 계약 관련 판단은 처음부터 사람 검수 흐름을 넣는 게 좋습니다.
이 정도만 해도 단순한 AI 사용에서 AI 업무 시스템으로 넘어가기 시작합니다.
AI 시대의 대표는 루프를 설계하는 사람입니다
저는 예전에는 AI를 잘 쓰는 사람이 “좋은 프롬프트를 잘 쓰는 사람”에 가깝다고 생각했어요.
지금은 조금 다르게 봅니다.
좋은 프롬프트도 중요하지만, 더 중요한 건 좋은 루프입니다. 어떤 정보가 들어오고, 어떤 기준으로 판단하고, 어떤 도구를 실행하고, 어떤 검수를 거치고, 실패를 어떻게 다음 실행에 반영할지 설계하는 능력이 중요해지고 있습니다.
AI 에이전트가 똑똑해질수록 이 차이는 더 커질 거예요.
기록이 없는 회사는 AI에게 매번 처음 설명해야 합니다. 반대로 컴퍼니 브레인이 있는 회사는 AI가 기존 맥락을 보고 바로 일할 수 있습니다. 그리고 실패할 때마다 조금씩 더 나아질 수 있습니다.
이게 제가 헤르메스 에이전트와 노션을 연결해서 만들고 싶은 방향입니다.
아직 완성된 시스템은 아니지만 이미 체감은 있습니다. 오픈클로를 쓸 때보다 헤르메스에서는 피드백이 다음 스킬에 반영되고, 프로젝트 맥락을 더 정확히 가져오고, 반복 작업이 조금씩 정리되는 느낌이 있습니다.
이 작은 개선들이 쌓이면 결국 회사의 일하는 방식이 바뀝니다.
AI가 우리 회사와 함께 일할 수 있나요?
AI 에이전트는 점점 더 똑똑해질 겁니다. 바이브 코딩 도구도 더 좋아질 거고, 내부 대시보드나 자동화 도구를 만드는 일도 점점 쉬워질 거예요.
그럴수록 중요한 질문은 “어떤 AI를 쓸까?”에서 “우리 회사는 AI가 읽을 수 있는가?”로 바뀝니다.
고객과 나눈 대화가 기록되어 있는지, 중요한 결정이 문서로 남아 있는지, 반복 업무가 스킬로 정리되어 있는지, 실패가 다음 실행에 반영되는지. 이 질문에 답할 수 있어야 AI가 진짜 회사 안에서 일하기 시작합니다.
컴퍼니 브레인은 예쁜 노션 정리법이 아닙니다. AI 시대에 회사가 기억하고, 판단하고, 개선되는 방식입니다.
AI 에이전트를 제대로 쓰고 싶다면, 먼저 회사를 AI가 읽을 수 있게 만들어야 합니다.
AI네버슬립에서는 이런 AI·노션 업무 시스템을 실제 1인 기업과 작은 팀의 업무에 맞게 설계하는 방법을 다룹니다. 우리 회사의 지식과 반복 업무를 AI가 일할 수 있는 구조로 바꾸고 싶다면, 강의와 컨설팅에서 함께 설계해볼 수 있습니다.