AI 에이전트 이야기는 한동안 “무엇을 만들 수 있는가”에 집중돼 있었다. 그런데 2026년 상반기 흐름은 조금 다르다. Notion은 2026년 5월 13일 Developer Platform을 공개하며 워커, 외부 에이전트, CLI, 웹훅을 한 번에 묶었고, OpenAI는 2026년 4월 22일 workspace agents를 앞세워 팀이 공유하는 장기 실행형 에이전트를 강조했다. n8n도 같은 시기 아키텍처 패턴과 인간 승인형 운영을 따로 설명하면서, 에이전트를 “어디에 두고 어떻게 통제할 것인가”를 핵심 문제로 끌어올렸다.
한국 팀 입장에서 이 변화가 중요한 이유는 단순하다. 이제는 모델 성능보다 운영 위치가 비용을 바꾼다. 팀 컨텍스트가 중요한 일, 코드와 문서처럼 길게 이어지는 일, 여러 앱을 오가는 결정적 자동화는 같은 장소에 두는 편이 오히려 비효율적일 수 있다. 그래서 지금 필요한 질문은 “어떤 툴이 제일 똑똑한가”보다 “어떤 종류의 일을 어느 허브에 둬야 재시작과 승인, 감사, 내부 링크 관리가 쉬운가”다.
왜 지금 에이전트 허브가 핵심 문제인가
처음 에이전트를 도입할 때는 챗 인터페이스만 있어도 충분해 보인다. 하지만 실제 운영으로 넘어가면 금방 다른 요구가 생긴다. 누가 승인했는지 남겨야 하고, 팀 문서와 이슈 상태를 계속 참조해야 하며, 실패했을 때 어디서 다시 시작할지도 분명해야 한다. 이 시점부터 에이전트는 대화창 안의 보조가 아니라 운영 단위가 된다.
이번 contentPlan의 핵심 주장도 여기에 맞닿아 있다. 2026년 상반기의 대표 신호들은 모두 허브 경쟁이었다. Notion은 워크스페이스를 에이전트 운영 인프라로 밀고 있고, Codex 기반 workspace agents는 공유형 장기 실행에 초점을 두며, n8n은 승인과 제어 토폴로지를 앞세운다. 즉 에이전트가 많아질수록 허브는 더 중요해진다.
Notion은 왜 워크스페이스 허브를 노리나
Notion Developer Platform의 의미는 메모 앱 확장이 아니다. 워크스페이스 안에 이미 쌓여 있는 문서, 데이터베이스, 사람의 승인 흔적, 반복 업무 구조를 에이전트가 다룰 수 있게 만드는 쪽에 가깝다. 워커와 외부 에이전트 개념이 같이 나온 것도 그래서다. 에이전트를 툴 안에 잠깐 붙이는 것이 아니라, 팀이 쓰는 컨텍스트와 같이 움직이게 하려는 시도다.
이런 구조는 특히 아래 같은 일에 강하다.
- 회의 노트, PRD, 실험 로그처럼 팀 문맥이 자주 바뀌는 작업
- 사람이 중간에 승인하거나 수정 흔적을 남겨야 하는 작업
- 외부 에이전트 결과를 다시 지식 베이스 안으로 흡수해야 하는 작업
반대로 Notion이 모든 실행 허브가 되기는 어렵다. 코드 실행, 복잡한 분기 자동화, 외부 시스템 간 결정적 동기화는 별도 레이어가 더 낫다. 그래서 Notion은 “모든 일을 직접 처리하는 엔진”보다 “팀 컨텍스트와 승인 흔적이 모이는 상위 허브”로 보는 편이 정확하다.
Workspace Agents와 Codex는 어떤 일을 맡기기 좋나
OpenAI의 workspace agents와 Codex 앱 흐름은 공유형 장기 실행 작업에 무게를 둔다. 한 번의 답변보다, 목표를 주고 여러 단계로 일을 진행하게 하며, 팀이 같은 에이전트를 공유하고 이어받을 수 있다는 점이 핵심이다. 이 구조는 문서 초안, 리서치 정리, 코드 수정 제안, 반복 점검 같은 작업에 잘 맞는다.
특히 Codex 계열을 운영 단위로 볼 때 장점은 세 가지다.
- 작업 목표와 진행 상태를 분리해 다루기 쉽다.
- 병렬 작업자처럼 여러 흐름을 동시에 굴리기 좋다.
- 결과물 생성과 검토 전 대기 상태를 구분하기 쉽다.
하지만 이 허브 역시 한계가 있다. 장기 실행과 멀티에이전트 조정에는 강해도, CRM 갱신이나 결제 후속 처리처럼 외부 앱 사이에서 결정적으로 흘러야 하는 작업은 n8n 같은 플로우 레이어가 더 안정적이다. 즉 Codex는 지식 작업과 생성 작업의 실행 허브로 강하고, 모든 시스템 통합의 중심이 되려고 할 때 복잡성이 급격히 커질 수 있다.
이 주제는 아래 후속 글에서 더 자세히 다룬다.
n8n은 어디에서 더 강한가
n8n이 강조한 에이전트 아키텍처 패턴과 인간 승인형 플레이북을 함께 보면 역할이 분명해진다. n8n의 강점은 대화 자체보다 흐름 제어다. 어떤 이벤트로 시작하는지, 실패 반경을 어디까지 둘지, 사람 승인 지점을 어디에 넣을지, 재시도와 분기를 어떻게 관리할지를 명시적으로 설계하게 만든다.
그래서 n8n은 아래 같은 영역에서 특히 강하다.
- 여러 SaaS를 넘나드는 결정적 자동화
- 외부 쓰기 액션 전에 승인 단계가 필요한 플로우
- 실패 시 재시도와 로깅이 중요한 반복 작업
반면 n8n이 팀 컨텍스트 허브 역할까지 전부 대신하려고 하면 문서 맥락과 협업 기록이 분절될 수 있다. 다시 말해 n8n은 실행 레이어와 승인 레이어에 강하고, 팀 지식 허브 역할은 Notion 같은 워크스페이스가 맡는 편이 자연스럽다.
MCP 툴 과밀은 허브 설계를 어떻게 망치나
최근 Product Hunt의 Strata와 shutup-mcp, 그리고 Hacker News 논의가 반복해서 짚는 문제는 같다. MCP의 병목은 연결 가능성보다 툴 과밀과 컨텍스트 낭비다. 도구가 많아질수록 에이전트가 더 잘하는 것이 아니라, 오히려 어떤 툴을 언제 써야 하는지 판단 비용이 커지고 작업 설명이 길어진다.
허브 설계 관점에서 보면 이 문제는 더 치명적이다. 워크스페이스 허브, 실행 허브, 자동화 허브를 나누지 않고 한곳에 모든 툴을 열어 두면 다음 현상이 생긴다.
- 승인 기준이 흐려진다.
- 에이전트가 읽기 작업에도 과도한 도구 목록을 본다.
- 실패 원인이 프롬프트인지 툴 노출인지 구분하기 어려워진다.
그래서 MCP는 많이 붙이는 것보다 작업별로 필터링해서 노출하는 편이 낫다. 툴 수를 자랑하는 구조가 아니라, 현재 단계에 필요한 도구만 보이게 하는 구조가 허브 설계를 살린다.
이 부분은 아래 후속 글에서 이어서 볼 수 있다.
우리 팀에 맞는 3계층 구조를 제안한다
실무에서는 세 계층으로 나누면 대부분의 혼선을 줄일 수 있다.
1. 컨텍스트 허브
여기에는 팀 문서, 의사결정 메모, 승인 로그, 프로젝트 상태가 쌓인다. Notion Developer Platform 같은 워크스페이스 계층이 이 역할에 가깝다.
2. 실행 허브
리서치, 문서 초안, 코드 수정, 장기 작업, 병렬 작업자 운영을 맡는다. 공유형 workspace agents와 Codex 계열이 들어가기 좋은 자리다.
3. 결정적 자동화와 품질 게이트
외부 시스템 갱신, 일정한 순서가 필요한 플로우, 승인 이후 실제 반영 작업을 맡는다. n8n과 코드 리뷰 자동화 같은 품질 게이트가 여기 들어간다.
이렇게 나누면 각 레이어가 무엇을 책임지는지가 선명해진다. 팀 지식은 워크스페이스에 남고, 생성형 장기 작업은 실행 허브가 맡고, 외부 반영은 결정적 플로우가 맡는다. 같은 에이전트라는 이름 아래 모든 일을 한 시스템에 몰아넣는 것보다 훨씬 안정적이다.
어떤 팀이 어디서 시작하면 좋을까
작은 팀이라면 처음부터 모든 계층을 정교하게 만들 필요는 없다. 대신 아래 순서가 현실적이다.
- 팀 문맥과 승인 흔적이 중요한 일부터 워크스페이스 허브에 모은다.
- 문서화, 리서치, 코드 제안처럼 길게 이어지는 작업을 공유형 실행 허브에 분리한다.
- 외부 시스템을 건드리는 자동화는 n8n 같은 플로우 레이어에서 승인형으로 시작한다.
- MCP는 단계별로 툴을 줄여 노출한다.
- 생성 레이어와 리뷰 레이어를 분리해 품질 문제를 늦게 발견하지 않게 한다.
결국 허브 설계의 목적은 기술 과시가 아니다. 팀이 에이전트를 더 오래, 더 안전하게, 더 설명 가능하게 쓰기 위한 운영 비용 절감이다. 2026년의 경쟁은 에이전트를 만들 수 있느냐가 아니라, 에이전트를 어디에 두면 사람과 시스템이 덜 피곤해지느냐다.