에이전틱 3대 구조
AI 에이전트 프레임워크 BabyAGI를 만든 요헤이 나카지마는 2026년 8월 25일 에이전틱 시스템의 구조를 세 가지로 정리했다. 교체 가능한 모델, 얇은 하네스(모델을 실제 작업에 연결하는 실행 껍데기), 모듈형 컴퍼니 브레인이다.
핵심은 지식재산과 스킬, 주요 데이터를 하네스나 개별 에이전트에 종속시키지 않는 데 있다. 이 자산들은 별도의 ‘컴퍼니 브레인’에 보관하고, 하네스는 사람과 AI가 그 자산을 활용하도록 연결하는 실행층으로만 두자는 구상이다.
비용과 효율을 좌우하는 요소도 모델만은 아니다. 기업용 생성형 AI 플랫폼 기업 Writer는 22개 과제와 6개 모델을 그대로 유지한 채 오케스트레이션 방식만 바꿨다.
| 지표 | 변화 |
|---|---|
| 과제당 비용 | 0.21달러 → 0.12달러 (41% 감소) |
| 토큰 사용량 | 38% 감소 |
| 중앙 처리시간 | 44% 감소 |
| 모델별 효율 | 33~61% 개선 |
연구진은 이러한 효과를 ‘하네스 레버리지’라고 불렀다.
Claude Code와 Codex는 각각 자사 모델에 최적화된 고성능 하네스다. 반면 OpenCode, Goose, DeepSeek Harness, Pi는 여러 공급자의 모델을 바꿔 쓸 수 있도록 설계됐다.
겉으로 드러나는 기능은 비슷해도 중요한 차이는 따로 있다. 벤더 계약 조건과 샌드박스(외부와 격리된 실행 환경) 구조, 감사 기록의 소유권이 제품마다 다르기 때문이다. 따라서 Claude, Qwen, Codex에 동일한 과제를 실행시킨 뒤 권한 설정, 도구 사용 기록, 실패 양상과 결과를 함께 비교해야 한다. 이 검증이 없으면 모델별 프롬프트가 저장소의 공통 지식에 뒤섞이고, ‘모델 교체 가능성’은 이름뿐인 원칙으로 남게 된다.
공통 기능은 기반 계층에 영구 위임하라
‘얇은 하네스’는 코드의 양이 아니라 기능과 지식이 어디에 놓여 있는지로 판단해야 한다.
Pi는 기본 도구를 읽기, 쓰기, 편집, 셸 실행으로 제한한다. 하위 에이전트와 계획 모드는 확장 기능으로 분리한다. OneMana 역시 로컬 Ollama와 클라우드 모델을 하나의 채팅, 문서, 작업 공간에 연결하되, 하네스에는 호출 단위의 인증, 승인, 감사 기능만 남긴다. 이 구조에서 에이전트는 별도의 앱이 아니라 협업 채널에 참여하는 구성원이다.
일각에서는 최고의 하네스를 ‘통제된 온톨로지(개념과 관계를 정의한 지식 체계)‘로 보고, 더 나아가 온톨로지 자체가 모델 아키텍처라고 주장한다. 이에 대해 결정론적 코드가 늘어날수록 하네스가 더는 얇다고 보기 어렵다는 반박도 나왔다. 나카지마의 답은 코드와 워크플로를 하네스에 쌓는 대신, ‘컴퍼니 브레인’이 사용하는 스킬로 옮기는 것이다.
소셜 트레이딩 플랫폼 eToro의 사례에서도 온톨로지는 단순한 데이터 저장 규격이 아니다. 에이전트가 정보를 해석하는 규칙에 가깝다. 예를 들어 동일한 고객 이탈 신호도 거래 에이전트는 포지션 위험으로, 마케팅 에이전트는 고객 유지 활동의 계기로, 준법 에이전트는 규제 노출 가능성으로 해석한다.
다만 하네스가 얇다고 해서 비용까지 낮아지는 것은 아니다. 결정론적 처리와 정책 판단을 모두 모델 호출에 맡기는 SaaS는 오히려 토큰 사용량이 늘 수 있다. 반대로 실행 계층을 무작정 비우면 통제력이 약해진다.
Stripe의 Kai는 이 문제를 계층화로 해결한다. Deep Agents 위에 보안, 인프라를 담당하는 중간 계층을 두고, 그 위에 AgentStudio의 설정 계층을 올린다. 여러 조직에 공통된 문제는 기반 하네스가 처리하고, Stripe에 고유한 문제는 Stripe가 직접 소유하는 구조다.
결국 얇은 하네스의 핵심은 기능을 없애는 데 있지 않다. 공통 기능은 기반 계층에 남기고, 조직의 지식과 워크플로는 온톨로지와 스킬로 옮기며, 고유한 정책과 책임은 해당 조직이 소유하도록 배치하는 데 있다.
프로젝트 단위를 보존하는 저장소 설계
위키도, 벡터 검색도 아니다
컴퍼니 브레인은 위키도, 벡터 검색 시스템도, 도구 목록도 아니다. 스타트업 액셀러레이터 Y Combinator의 2026년 여름 제안에서 파트너 톰 블롬필드는 이를 ‘회사가 실제로 일하는 방식을 담은, 지속적으로 갱신되는 지도’로 설명했다. 환불 처리, 가격 예외 승인, 장애 대응 같은 운영 방식을 기록하고, AI가 직접 실행할 수 있는 스킬 파일로 만드는 것이다.
제대로 작동하려면 몇 가지 조건이 필요하다. 조직 전체가 하나의 정의를 공유해야 하고, 임의의 우회 경로를 차단해야 한다. 정보는 자동으로 갱신돼야 하며, 사용자의 권한에 따라 조회 범위도 달라져야 한다. 서로 모순되는 자료를 조정하지 않은 채 한곳에 쌓기만 한다면, 컴퍼니 브레인은 결국 또 하나의 검색 저장소가 된다.
핵심은 모듈화다. 모듈은 도메인 지식의 소유권을 분명히 하는 동시에 모델 사용 비용을 줄인다. Kai에서는 100개가 넘는 팀이 1,000개 이상의 스킬을 나누어 관리한다. 사용자는 이 스킬을 기본, 직군, 개인 계층으로 나누어 필요한 만큼만 불러온다.
도구도 같은 방식으로 선택한다. 500개가 넘는 MCP 도구를 처음부터 모두 문맥에 넣지 않는다. 먼저 과제에 맞는 스킬을 고른 뒤, 그 스킬에 필요한 도구만 불러온다. 실제로 스킬 수가 150개를 넘었을 때 품질이 떨어졌기 때문이다.
업계 일각에서 강조하는 모듈성도 이 지점에서 중요하다. 업무를 모듈로 나누면 과제의 난도와 성격에 따라 로컬 모델, 저가 모델, 프론티어 모델을 선택할 수 있다. 반대로 모듈이 없으면 모든 업무에 가장 비싼 모델을 사용하면서 조직의 맥락까지 매번 처음부터 제공해야 한다.
그러나 공유 저장소는 시간이 지나면 쉽게 낡는다. 한 에이전트 개발자는 이를 막기 위해 세션마다 브리핑을 새로 작성한다. 각 주장을 저장소의 근거와 대조한 뒤에만 기록으로 남긴다. 과거의 기억을 사실로 받아들이지 않고, 다시 확인해야 할 단서로 취급하는 방식이다.
나카지마의 저장소 중심 설계도 같은 원칙을 따른다. 지속돼야 할 단위는 대화나 AI 모델이 아니라 프로젝트다. 통제된 저장소가 프로젝트의 상태와 규칙, 근거, 결정, 변경 이력, 검증 결과를 보존한다. 사용자가 보는 현재 화면은 원본 그 자체가 아니라, 이 기록을 바탕으로 만들어진 최신 투영본이다.
결국 컴퍼니 브레인의 가치는 얼마나 많은 자료를 모았는지에 달려 있지 않다. 조직의 실제 운영법을 모순 없이 정리하고, 필요한 맥락과 도구만 골라 AI가 실행하게 하며, 그 결과를 다시 검증 가능한 기록으로 남길 수 있는지가 핵심이다.
실행층과 지식층의 명확한 경계선 설정
하네스와 컴퍼니 브레인의 역할은 명확히 나눠야 한다.
하네스는 실행을 담당한다. 모델 공급자와의 연결, 도구 호출 루프, 샌드박스, 스트리밍, 호출별 인증, 승인, 감사, 문맥 압축이 여기에 속한다.
컴퍼니 브레인은 조직의 지식과 규칙을 관리한다. 엔티티와 지표의 정의, 정책, 의사결정 기록, 검증 기준, 결정론적 워크플로, 권한이 적용된 메모리, 스킬별 도구 목록을 보관한다. 예를 들어 서로 무관한 고객의 정보를 하나의 분석에 섞지 않는 것은 모델의 능력에 맡길 문제가 아니라 조직이 강제해야 할 규칙이다. 정보 접근 권한도 단순히 “이 직원이 볼 수 있는가”가 아니라 “이 과제를 수행하는 데 이 정보를 보여줘야 하는가”를 기준으로 판단해야 한다.
도구는 컴퍼니 브레인이 선택하고 하네스가 실행한다. 세션 안에서만 쓰는 메모는 하네스에 남겨도 된다. 하지만 에이전트와 프로젝트를 넘어 축적되는 학습, 출처 관리, 정보 간 모순 검사는 컴퍼니 브레인이 맡아야 한다. 지출 한도, 격리 정책, 승인 규칙도 컴퍼니 브레인에 단일 원본을 두고 하네스가 일관되게 집행한다.
온톨로지는 버전별로 관리한다. 워크플로의 진행 상태는 프로젝트에 기록해, 사람이 언제든 이어받아 검토하고 검증할 수 있게 한다.
시스템의 합격 여부는 모델을 교체한 뒤 동일한 과제를 다시 실행해 판단한다. 권한이 제대로 지켜졌는지, 도구 사용 기록이 남았는지, 실패 양상이 통제 가능한지, 산출물이 허용 범위 안에 있는지를 확인해야 한다. 결국 조직의 방어력은 분기마다 등장하는 최고 성능의 모델에서 나오지 않는다. 모델을 바꾼 뒤에도 남는 핵심 모듈과, 그 규칙을 일관되게 집행하는 얇은 실행층에서 나온다.
출처
- replaceable models + thin harness + modular company brain — X/@yoheinakajima
- I’m storing deterministic code and workflows as skills in my company brain — X/@yoheinakajima
- my current ActiveGraph-inspired modular repo-centric agent OS — X/@yoheinakajima
- Pi Coding Agent — pi.dev
- The Harness Effect — arXiv:2607.06906
- A Comparison of AI Agent Harnesses in 2026 — Winder.AI
- Meet Stripe’s Knowledge AI Platform — Stripe.dev
- How Stripe Built Kai on Deep Agents — LangChain
- Company Brain — YC RFS Summer 2026
- How to Build a Company Brain for AI Agents — Vectorize
- How eToro Built a Company Brain for 300+ AI Agents — Caura
