노션 커스텀 에이전트란? — 기존 AI와 결정적 차이

노션 커스텀 에이전트는 2026년 2월 24일 Notion 3.3 업데이트를 통해 정식 출시된 자율형 AI 팀원입니다. 기존 Notion AI가 “질문하면 답해주는” 반응형이었다면, 커스텀 에이전트는 트리거나 스케줄을 설정해두면 사람의 개입 없이 멀티스텝 업무를 24시간 처리합니다. 핵심은 “프롬프트가 필요 없다”는 점입니다. 한 번 설정해두면 잠든 사이에도 돌아가고 있습니다.

실제로 노션 내부에서는 2,800개의 에이전트가 상시 가동 중이며, 베타 테스터들이 만든 에이전트 수만 벌써 21,000개를 넘겼습니다. 이미 쓰는 회사 이야기가 아니라, 지금 당장 무료로 만들어볼 수 있는 기능입니다.

기존 Notion AI vs 커스텀 에이전트 — 핵심 차이

▲ 목차로 돌아가기

Notion 3.0 → 3.3 진화 타임라인 한눈에 보기

노션의 AI 기능은 빠른 속도로 진화했습니다. 2025년 9월 Notion 3.0에서 개인 에이전트 개념이 처음 등장했고, 불과 5개월 만인 2026년 2월 커스텀 에이전트가 정식 출시됩니다. 이 흐름을 이해해야 지금 어떤 기능을 써야 하는지 판단할 수 있습니다.

Notion 3.0에서는 에이전트가 “내가 시킬 때만” 작동했습니다. 그러나 3.3 커스텀 에이전트는 내가 잠들어도 알아서 일합니다. 이 차이가 생산성의 패러다임을 바꿉니다. 개인 에이전트가 ‘개인 비서’라면, 커스텀 에이전트는 ‘부서별로 배치된 전문 팀원’에 가깝습니다.

▲ 목차로 돌아가기

커스텀 에이전트 만드는 법 — 5단계 실전 가이드

노션 커스텀 에이전트 생성은 생각보다 단순합니다. 복잡한 코딩 없이 자연어 설명만으로 에이전트를 만들 수 있도록 설계되어 있습니다. Business 또는 Enterprise 플랜 워크스페이스에서 아래 순서를 따르면 됩니다.

• 1
  에이전트 생성 진입 — 노션 사이드바에서 ‘Agents’ 메뉴 클릭 → ‘+ New Agent’ 선택. 없다면 워크스페이스 플랜 확인 필요.
• 2
  역할 정의(Job Description) — 자연어로 에이전트가 할 일을 설명합니다. “매일 오전 9시에 Slack의 #feedback 채널을 모아 노션 DB에 요약 정리해줘” 같은 방식으로 작성합니다.
• 3
  소스(Sources) 연결 — 에이전트가 접근할 정보 소스를 선택합니다. 노션 페이지/DB, Slack 채널, 노션 메일, 캘린더, MCP 연동 도구(Linear, HubSpot, Figma 등) 중 필요한 것을 연결합니다.
• 4
  트리거(Trigger) / 스케줄 설정 — “특정 이벤트 발생 시 실행”할지, “매일 오전 9시처럼 정해진 시각에 실행”할지를 선택합니다. 둘 다 설정하는 것도 가능합니다.
• 5
  권한 범위 확인 후 활성화 — 에이전트가 접근·수정할 수 있는 페이지/DB 범위를 검토합니다. ‘Enable Agent’를 누르면 즉시 작동 시작. 모든 실행 이력은 로그로 남아 언제든 취소·롤백 가능합니다.

빠른 시작을 위한 공식 에이전트 템플릿

처음부터 만들기 부담스럽다면 노션이 제공하는 공식 커스텀 에이전트 템플릿을 활용하세요. ‘이메일 어시스턴트’, ‘팀 스케줄러’, ‘FigJam 프로젝트 정리’, ‘온보딩 도우미’ 등 가장 많이 쓰이는 워크플로우가 이미 세팅되어 있습니다. 템플릿을 불러온 뒤 소스와 스케줄만 조정하면 10분 이내에 첫 에이전트를 가동할 수 있습니다.

▲ 목차로 돌아가기

실무 자동화 시나리오 5가지

노션 커스텀 에이전트의 실제 가치는 “어떤 업무를 맡길 수 있느냐”에 달려 있습니다. 아래 5가지는 현재 실제 기업들이 검증한 시나리오입니다. 어느 하나라도 내 업무와 겹친다면 지금 바로 세팅해볼 가치가 있습니다.

① Q&A 에이전트 — 반복 질문을 대신 답하다

Slack에서 매일 같은 질문이 반복된다면 이것부터 만드세요. 에이전트가 노션 위키, 정책 문서, 슬랙 히스토리에 접근해 팀원 질문에 95% 이상의 정확도로 자동 응답합니다. 핀테크 기업 Ramp는 이 방식으로 운영팀 채널 모니터링 인력을 완전히 줄였습니다.

② 태스크 라우팅 에이전트 — 요청이 들어오면 자동 분류

IT 요청, CS 문의, 버그 리포트가 여러 채널로 흩어져 들어오는 팀에 최적입니다. 에이전트가 메일·Slack·폼 데이터를 받아 우선순위와 담당자를 자동 배정하고 노션 DB에 등록합니다. Remote의 IT Ops 팀은 주당 20시간을 절감하고 티켓의 25% 이상을 사람 없이 해결했습니다.

③ 상태 보고서 에이전트 — 매주 보고서가 저절로 완성

주간 스프린트 요약, 월간 OKR 보고서, 매일 오전 스탠드업 노트가 필요한 팀에 적합합니다. 에이전트가 연결된 DB와 프로젝트 페이지를 읽고, 정해진 포맷으로 보고서를 작성한 뒤 지정 채널에 자동 발송합니다. Braintrust의 VP는 이 방식으로 하루 20분씩 절약하고 있습니다.

④ 온보딩 에이전트 — 새 팀원이 합류하면 자동 가이드

신규 입사자가 워크스페이스에 추가되는 순간 트리거가 발동됩니다. 에이전트가 해당 사람의 직무에 맞춘 온보딩 플랜을 자동 생성하고, 관련 문서 링크와 초기 체크리스트를 할당합니다. 반복되는 HR 업무를 에이전트 한 개로 커버합니다.

⑤ 피드백 수집 에이전트 — 고객 목소리가 DB로 자동 정리

Slack, 메일, 폼으로 들어오는 사용자 피드백을 에이전트가 일별로 수집해 버그/개선/칭찬으로 분류하고, 해당 팀 DB에 자동 등록합니다. 제품팀은 흩어진 고객 목소리를 놓치지 않고, 개발팀은 매주 “피드백 정리”에 쓰던 시간을 되찾을 수 있습니다.

▲ 목차로 돌아가기

Slack·메일·MCP 연동 완전 정복

노션 커스텀 에이전트가 강력한 이유는 노션 내부만 다루는 게 아니기 때문입니다. Slack, 노션 메일, 노션 캘린더, 그리고 MCP(Model Context Protocol)를 통해 외부 서비스까지 연결할 수 있습니다. 연동 범위가 넓을수록 에이전트의 자동화 수준도 높아집니다.

Slack 연동 — 채널 모니터링과 자동 응답

에이전트 설정에서 ‘Slack’ 소스를 연결하면 특정 채널의 메시지를 읽고, 답변을 작성하거나 노션 DB로 옮기는 일이 가능합니다. “#general에 올라오는 IT 요청을 매일 정리해 노션 이슈 트래커에 등록해줘”처럼 자연어 하나로 자동화가 완성됩니다. 단, Slack 워크스페이스 관리자 권한이 있어야 연동이 원활합니다.

노션 메일 연동 — 받은편지함이 업무 DB로 변환

노션 메일(Notion Mail)은 받은 편지함을 노션 워크스페이스와 직접 연결합니다. 에이전트가 들어오는 메일을 자동 분류하고, 중요 메일의 요약을 노션 페이지로 변환하며, 미팅 요청은 노션 캘린더에 자동 등록까지 합니다. 이메일을 매개로 들어오는 CS 문의, 채용 지원서, 협력 제안 등을 사람의 손을 거치지 않고 처리할 수 있습니다.

MCP 연동 — Linear·HubSpot·Figma까지 하나로

MCP(Model Context Protocol) 연동은 노션 외부 서비스까지 에이전트의 행동 범위를 확장합니다. Linear의 이슈를 노션 DB로 동기화하거나, HubSpot의 리드 데이터를 받아 제안서를 자동 작성하거나, FigJam 보드의 내용을 노션 문서로 변환하는 것이 모두 가능합니다. 현재 지원되는 MCP 연동 목록은 노션 공식 인테그레이션 페이지에서 확인할 수 있습니다.

▲ 목차로 돌아가기

요금제·무료 체험 기간 정리 (2026.05 유료 전환 주의)

노션 커스텀 에이전트는 현재 2026년 5월 3일까지 무료로 사용할 수 있습니다. 그 이후부터는 ‘Notion Credits(노션 크레딧)’ 방식으로 전환되어 에이전트가 수행한 작업 단위로 비용이 발생합니다. 지금 세팅에 투자하는 시간이 곧 비용 절감입니다.

크레딧은 “에이전트가 처리한 작업량”에 따라 차감되는 방식입니다. 한 번만 세팅해두면 반복 실행 비용은 줄일 수 있지만, 에이전트가 너무 광범위한 소스를 매일 처리하도록 설정하면 크레딧 소모가 빨라집니다. 무료 기간 동안 필요한 에이전트를 좁게 정의하고 성능을 검증해두는 것이 현명한 전략입니다.

▲ 목차로 돌아가기

에이전트가 실패하는 3가지 이유와 해결법

베타 테스터들의 경험을 보면, 노션 커스텀 에이전트가 기대한 대로 동작하지 않는 경우 대부분 동일한 원인이 있었습니다. 아래 3가지를 먼저 점검하면 90% 이상의 문제는 해결됩니다.

① 데이터 구조가 정리되지 않은 경우

에이전트는 기존 DB를 기반으로 동작합니다. 상태(Status) 값이 제각각이고 태그가 난립하며 요약 필드가 비어 있다면, 에이전트가 무엇을 기준으로 업데이트해야 할지 파악하지 못합니다. 해결법은 간단합니다. 상태는 5개 이하, 태그는 10~20개 이내, 요약은 2~3문장 규칙을 먼저 고정하세요. 이것이 에이전트 도입 전 가장 먼저 해야 할 일입니다.

② 역할 설명이 너무 광범위한 경우

“우리 팀 업무 전체를 관리해줘”처럼 범위가 넓은 지시는 오히려 에이전트의 동작을 불안정하게 만듭니다. “매주 월요일 오전 8시, Slack #project 채널에서 지난 주 업데이트를 수집해 노션 주간보고 페이지에 3줄 요약으로 추가해줘”처럼 구체적일수록 에이전트의 정확도가 높아집니다. 하나의 에이전트에 하나의 역할을 부여하는 것이 원칙입니다.

③ 권한 범위를 설정하지 않은 경우

에이전트가 접근할 수 없는 페이지에서 데이터를 가져오려 하거나, 반대로 건드리면 안 되는 페이지를 수정하는 사고가 발생할 수 있습니다. 모든 실행은 로그로 기록되므로 되돌리는 것은 가능하지만, 사전에 소스(Sources) 설정에서 에이전트가 볼 수 있는 것과 쓸 수 있는 것을 명확히 구분해두는 것이 훨씬 안전합니다. Business/Enterprise 관리자라면 “누가 에이전트를 만들 수 있는지”까지 권한 정책으로 고정해두세요.

▲ 목차로 돌아가기