이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

지난 12월, 노션 CEO Ivan Zhao가 "Steam, Steel, and Infinite Minds"라는 에세이를 공개했습니다.

강철이 도금시대를, 반도체가 디지털 시대를 열었듯이, AI가 '무한한 지성(Infinite Minds)'이라는 새로운 소재로 우리 시대를 정의하게 될 것이라는 글이었어요. 당시 저는 이 글을 읽으면서 '참 좋은 비전이다'라고만 생각했습니다.

그런데 불과 몇 달 사이에, 이 비전이 현실로 다가오고 있습니다. 여러 플랫폼들이 커스텀 에이전트 기능을 내놓기 시작했고, 노션 역시 Custom Agents를 출시하면서 워크스페이스에 쌓인 데이터 위에 에이전트를 올릴 수 있게 됐습니다. 실제로 이걸 업무에 적용하는 사람들도 나타나고 있어요.

오늘은 이 에세이의 핵심 내용을 일부 번역 및 발췌하여 소개드리고, 실제로 전 세계에서 노션 커스텀 에이전트를 어떻게 활용하고 있는지까지 함께 다뤄보려 합니다.

마지막 부분에 AI가 포함된 노션 비즈니스플랜 6개월 무료체험 링크가 있으니 끝까지 읽어주세요!

Part 1. Ivan Zhao의 에세이에서 발췌한 AI 시대의 풍경

아래는 Ivan Zhao의 에세이 "Steam, Steel, and Infinite Minds"의 핵심 내용을 번역, 발췌하여 정리한 것입니다. 원문은 노션 공식 블로그에서 확인하실 수 있습니다.

모든 시대에는 '기적의 소재'가 있었다

"모든 시대에는 그 시대를 정의하는 '기적의 소재'가 있었다. 강철이 도금시대를 만들었고, 반도체가 디지털시대를 열었다. 이제 AI라는 새로운 소재가 도착했다. Ivan은 이걸 '무한한 지성(Infinite Minds)'이라고 부른다. 역사가 가르쳐주는 게 있다면, 그 소재를 마스터한 사람이 시대를 정의한다는 것이다."

Ivan은 여기서 1850년대 피츠버그의 앤드류 카네기 이야기를 꺼냅니다.

당시 카네기는 진흙탕 거리를 뛰어다니는 전보 배달 소년에 불과했습니다. 미국인의 60%가 농부이던 시절이었죠. 하지만 카네기는 강철이라는 소재의 가능성을 일찍 알아봤고, 결국 미국 최대의 철강 제국을 세웁니다.

불과 두 세대 만에 세상은 완전히 달라졌습니다. 말이 철도로 대체됐고, 촛불이 전기로, 철이 강철로 바뀌었습니다. 강철이라는 하나의 소재가 건물의 높이를 바꾸고, 산업의 구조를 재편하고, 사람들이 일하고 사는 방식 자체를 다시 쓴 겁니다.

그 이후, 일터는 공장에서 사무실로 옮겨갔습니다. 그리고 지금, Ivan은 이렇게 말합니다.

"나는 샌프란시스코에서 수백만 지식노동자를 위한 도구를 만드는 소프트웨어 회사를 운영한다. 이 도시에서는 모두가 AGI를 이야기하지만, 20억 사무직 노동자 대부분은 아직 AI를 체감하지 못하고 있다. 곧 지식노동은 어떤 모습이 될까? 24시간 쉬지 않는 AI가 조직에 합류하면 무슨 일이 벌어질까?"

카네기 시대의 강철이 그랬듯, AI라는 새로운 소재가 지금의 지식노동을 어떻게 바꿀 것인지. Ivan은 이 질문에 대해 세 가지 스케일로 답합니다. 개인, 조직, 그리고 경제 전체.

개인: 자전거에서 자동차로

먼저 개인 스케일에서, Ivan은 자신의 공동창업자 Simon의 이야기를 합니다.

Simon은 원래 '10배 개발자(10× programmer)'라고 불리는 사람이었는데, 요즘은 직접 코드를 거의 쓰지 않습니다. 대신 3~4개의 AI 코딩 에이전트를 동시에 오케스트라처럼 지휘합니다. 점심시간이나 잠들기 전에 작업을 큐에 넣어두면, 에이전트들이 그가 없는 동안 알아서 일합니다.

결과적으로 30~40배 엔지니어가 된 셈이죠.
 

1980년대에 스티브 잡스는 개인용 컴퓨터를 "마음의 자전거(bicycle for the mind)"라고 불렀습니다. 컴퓨터가 인간의 사고력을 증폭시켜준다는 의미였죠. 그로부터 수십 년, 인터넷이라는 고속도로까지 깔렸지만, 대부분의 지식노동은 여전히 인간이 직접 페달을 밟아야 돌아갑니다.

Ivan의 표현을 빌리면, "우리는 고속도로 위에서 자전거를 타고 있었던 셈"입니다. Simon은 AI 에이전트를 통해 비로소 그 자전거에서 내려 자동차로 갈아탄 겁니다.

그렇다면 다른 유형의 지식노동자들은 언제 '자동차'를 타게 될까요? Ivan은 두 가지 문제가 먼저 해결되어야 한다고 말합니다.

첫째는 맥락의 파편화(context fragmentation)입니다.

코딩은 IDE, 코드 저장소, 터미널 등 도구와 맥락이 한 곳에 모여 있습니다. 하지만 일반적인 지식노동은 수십 개의 도구에 흩어져 있죠. AI 에이전트가 제품 기획서를 작성하려면 슬랙 스레드, 전략 문서, 지난 분기 대시보드 지표, 그리고 누군가의 머릿속에만 있는 조직 지식까지 끌어와야 합니다.

둘째는 검증 가능성(verifiability)입니다.

코드는 테스트와 에러를 통해 검증할 수 있습니다. 모델 제작자들은 이걸 활용해서 AI의 코딩 능력을 향상시킵니다. 하지만 프로젝트가 잘 관리되고 있는지, 전략 메모가 제대로 쓰여졌는지를 어떻게 검증할까요? 그래서 아직은 인간이 루프 안에서 감독해야 합니다.

하지만 Ivan은 이게 이상적인 상태는 아니라고 말합니다. 마치 1865년 영국의 적기법(Red Flag Act)처럼요. 당시 법은 자동차가 도로를 달릴 때 앞에서 사람이 깃발을 들고 걸어가야 한다고 규정했습니다. 인간이 루프 '안에' 있는 건 그런 상태와 비슷하다는 겁니다.

진짜 목표는 인간이 루프 안에서 일일이 확인하는 게 아니라, 한 발 물러서서 전체를 감독하는 위치로 올라서는 것이죠.

조직: AI는 조직의 강철이다

Ivan은 조직 스케일의 변화를 두 가지 역사적 비유로 설명합니다.

첫 번째는 강철입니다.

19세기에 건물은 6~7층이 한계였습니다. 철은 강하지만 부서지기 쉽고 무거웠기 때문이죠. 강철이 등장하면서 더 가벼운 프레임, 더 얇은 벽이 가능해졌고, 건물은 수십 층까지 올라갈 수 있게 됐습니다.

Ivan은 'AI가 조직의 강철'이라고 말합니다. 인간의 커뮤니케이션이 더 이상 하중을 지탱하는 벽이 될 필요가 없어진다는 것이죠. 매주 2시간짜리 정렬 회의가 5분짜리 비동기 리뷰로 바뀔 수 있습니다.

두 번째 비유는 증기 엔진입니다.

산업혁명 초기, 방직 공장들은 물레방아 옆에 있었습니다. 증기 엔진이 등장했을 때 공장 주인들은 처음에 물레방아만 증기 엔진으로 교체하고 나머지는 그대로 뒀습니다. 생산성 향상은 미미했죠. 진짜 도약은 물에서 완전히 벗어나 공장 자체를 재설계했을 때 일어났습니다.

Ivan의 핵심 진단은 이겁니다. '우리는 아직 물레방아를 교체하는 단계에 있다.' 기존 도구에 AI 챗봇을 붙여놓는 수준이라는 것이죠. 조직이 '잠자는 동안에도 일하는 무한한 마음'으로 운영될 때 어떤 모습일지는 아직 상상하지 못하고 있다는 겁니다.

경제: 피렌체에서 메가시티로

마지막으로 Ivan은 경제 전체의 스케일을 이야기합니다.

수백 년 전까지 도시는 사람이 걸어 다닐 수 있는 크기였습니다. 피렌체를 40분이면 걸어서 횡단할 수 있었죠. 삶의 리듬은 사람이 걸을 수 있는 거리, 목소리가 닿는 범위에 맞춰져 있었습니다.

하지만 강철 프레임이 마천루를 가능하게 했고, 증기 엔진이 철도를 움직였으며, 도시는 도쿄, 충칭, 달라스 같은 메가시티로 폭발적으로 성장했습니다. 이 도시들은 단순히 옛날 도시가 커진 버전이 아닙니다.

근본적으로 다른 삶의 방식이었죠. 더 많은 기회, 더 많은 자유, 더 많은 조합이 가능해졌습니다.

Ivan은 지식 경제도 같은 변환을 앞두고 있다고 말합니다.

오늘날 지식노동은 미국 GDP의 거의 절반을 차지하지만 대부분 여전히 사람의 손과 머리가 직접 감당할 수 있는 범위 안에서 운영됩니다. 수십 명 단위의 팀, 회의와 이메일 속도에 맞춰진 워크플로우. 지금의 지식노동은 아직 걸어서 횡단할 수 있던 시대의 도시와 비슷하다는 겁니다.

AI 에이전트가 본격적으로 가동되면, 그때 비로소 메가시티 같은 스케일이 열립니다. 더 빠르고, 더 큰 규모로. 처음에는 혼란스럽겠지만, 그만큼 가능성도 커집니다.

에세이에서 건진 핵심 인사이트 세 가지

Ivan의 긴 글에서 제가 특히 인상 깊었던 인사이트를 정리하면 이렇습니다.

첫째, AI는 도구가 아니라 '소재'다. 강철이 건물을 더 높이 올린 게 아니라 건축 자체를 재정의했듯이, AI는 기존 업무를 빠르게 하는 게 아니라 일하는 방식 자체를 바꿀 소재라는 관점입니다. 이 시각 전환이 중요합니다.

둘째, 지금은 물레방아만 증기 엔진으로 바꿔 끼운 단계다. 대부분의 AI 활용은 기존 워크플로우에 챗봇을 붙여놓는 수준입니다. 공장은 그대로인데 동력원만 바꾼 셈이죠. 진짜 변화는 워크플로우 자체를 AI 중심으로 재설계할 때 시작됩니다. 증기 엔진이 공장의 위치와 구조를 통째로 바꿨듯이요.

셋째, 맥락이 모여야 에이전트가 일한다. 코딩에서 AI가 가장 먼저 성공한 이유는 맥락이 한 곳에 모여 있기 때문입니다. 일반 지식노동에서 AI가 진짜 일하려면, 먼저 정보가 한 곳에 모여야 합니다.

세 번째 인사이트가 특히 중요합니다. 에이전트 시대의 출발점은 거창한 자동화 시스템이 아니라, 내 업무 데이터를 한 곳에 모으는 일이라는 뜻이니까요.

그런데 이 에세이가 쓰인 건 작년 12월입니다. 불과 몇 달이 지난 지금, 이미 이 비전을 현실로 만들고 있는 사람들이 있습니다. 그들이 일하는 방식을 들여다보면, Ivan이 말한 미래가 어떤 모습인지 좀 더 선명하게 그려집니다.

Part 2. 앞서가는 사람들

Ivan의 글은 비전이지만, 현실은 이미 앞서가고 있습니다.

노션 커스텀 에이전트를 통해 실제 업무 방식을 바꾼 사례 세 가지를 소개합니다.

한 명은 비개발자이면서 16개의 에이전트를 설계한 일본의 Notion 앰배서더이고, 다른 한 명은 혼자 운영하는 사이드 프로젝트에 AI 팀장을 붙인 노션의 디자이너입니다. 마지막 사례는 팀 단위 에이전트를 만든 노션의 공동 창업자 이야기입니다. 

세 가지 사례를 보면, 에이전트를 활용하는 사람들이 어떤 식으로 자신의 업무 환경을 에이전틱하게 재설계하는지가 구체적으로 드러납니다.

사례 ①

일본 Notion 앰배서더 야마다, 비개발자가 만든 에이전트 16개

일본의 Notion 공식 앰배서더 야마다는 개발자가 아닙니다. 그런데 현재 16개의 커스텀 에이전트를 실제 업무에 운용하고 있습니다.

야마다의 접근법에서 주목할 점은 에이전트를 하나 만들어서 대단한 일을 시키는 게 아니라는 겁니다. 작은 에이전트 여러 개가 각자의 역할을 맡아 톱니바퀴처럼 돌아가는 구조를 만들었습니다. 마치 한 사람이 비서 16명을 두고 있는 것과 비슷한데, 각 비서에게 아주 구체적인 업무 하나씩만 맡긴 겁니다.

그중 특히 인상적인 에이전트 세 개를 자세히 살펴보겠습니다.

🤖 디지털 뉴스쿠 (매일 아침 6시 자동 실행)

매일 아침 6시, 에이전트가 웹에서 그날의 관련 뉴스를 검색합니다. 수십 개의 기사 중 5건을 추려내고, 각각 한 줄 요약과 함께 Slack으로 발송합니다. 야마다가 출근하면 이미 오늘의 업계 동향이 정리되어 있는 겁니다.

원래 그가 직접 하던 30분짜리 아침 루틴이었습니다. 뉴스 사이트를 돌아다니며 기사를 읽고, 중요한 것을 골라 정리하는 작업이었죠. 하루 30분이면 한 달에 10시간, 1년이면 120시간입니다. 이 에이전트 하나가 1년에 120시간을 돌려준 셈입니다.

여기서 중요한 건, 에이전트가 단순히 뉴스를 긁어오는 게 아니라 '선별'한다는 점입니다. 야마다가 노션에 쌓아둔 관심 분야, 과거 업무 맥락, 클라이언트 정보 등을 기반으로 "이 사람에게 의미 있는 뉴스"를 골라냅니다. Ivan이 말한 '맥락의 통합'이 실제로 작동하는 사례죠.

🤖 마루하다카 리서처 (이메일 수신 시 자동 실행)

문의 이메일이 들어오면 에이전트가 먼저 종류를 판별합니다. 업무 의뢰인지, 영업인지, 단순 질문인지. 업무 의뢰라고 판단되면 웹에서 발신자 정보를 자동으로 조사해 한 장짜리 리포트를 만듭니다. 어떤 회사인지, 규모는 어느 정도인지, 어떤 맥락에서 연락이 왔는지.

야마다는 답장하기 전에 이미 상대방을 파악한 상태로 대화를 시작합니다.

이게 왜 대단하냐면, 프리랜서나 1인 사업자에게 이메일 트리아지(분류 작업)는 의외로 시간을 많이 잡아먹는 일이기 때문입니다. 하루에 문의 5건만 와도, 각각 발신자를 검색하고 맥락을 파악하는 데 건당 10~15분이 걸립니다. 5건이면 최소 1시간이죠. 에이전트가 이 1시간을 0으로 줄여줍니다. 게다가 영업 메일을 자동으로 걸러내기 때문에, 야마다는 진짜 중요한 의뢰에만 에너지를 집중할 수 있게 됐습니다.

🤖 프로젝트 건강진단 (매주 월요일 자동 실행)

매주 월요일 아침, 전체 프로젝트를 자동으로 진단합니다. 진행이 느린 프로젝트가 있으면 원인을 분석하고, 이번 주 먼저 손댈 항목 목록을 만들어줍니다. 월요일 아침 회의 전에 이미 우선순위가 정리되어 있는 겁니다.
 

이 에이전트의 핵심은 '진단'이 사후가 아니라 사전에 일어난다는 점입니다. 보통 프로젝트가 지연되면 사람이 뒤늦게 알아차리고, 그때부터 원인 분석을 시작합니다. 야마다의 에이전트는 매주 자동으로 전수 검사를 돌리기 때문에 문제가 커지기 전에 잡아냅니다. 노션 DB에 프로젝트 진행률, 마감일, 최근 업데이트 이력이 모두 기록되어 있으니까 에이전트가 이 데이터를 읽어서 "이 프로젝트는 3일째 업데이트가 없고, 마감까지 5일 남았다" 같은 판단을 내릴 수 있는 거죠.

야마다의 에이전트 설계 철학

야마다가 16개 에이전트를 운용하면서 강조하는 원칙은 세 단계로 요약됩니다.

정보를 한 곳에 모으고, 반복 작업을 발견하고, 에이전트에게 맡긴다.

이 순서가 중요합니다. 에이전트부터 만들려고 하면 실패합니다. 에이전트가 잘 작동하려면 데이터가 쌓인 곳이 있어야 합니다. 노션이 그 허브 역할을 하는 것이고, 그 위에 에이전트가 올라탑니다.

야마다가 비개발자라는 점도 시사하는 바가 큽니다. 코드를 한 줄도 쓰지 않고 16개의 에이전트를 만들었다는 것은, 이제 자동화의 진입장벽이 '기술력'이 아니라 '관찰력'이라는 뜻입니다. 어떤 반복이 내 하루를 잡아먹고 있는지를 알아차리는 눈이 기술보다 중요해진 겁니다.

사례 ②  

Brian Lovin, 혼자서 운영하는 사이드 프로젝트에 AI 팀장을 붙이다

Brian Lovin은 노션에서 AI 제품을 만드는 디자이너입니다. 최근 주말에 "Shiori"라는 북마크 관리 서비스를 출시했는데, 이 프로젝트를 혼자 운영하기 위해 오후 반나절 만에 커스텀 에이전트를 구성했습니다.

여기서 '반나절'이라는 시간에 주목해야 합니다. 기존에 이런 자동화 시스템을 만들려면 개발자를 고용하거나, 본인이 직접 코드를 짜야 했습니다. Zapier나 Make 같은 노코드 도구를 써도 각 워크플로우를 하나씩 설계하고 연결하는 데 며칠은 걸렸죠. Brian은 커스텀 에이전트 하나로 이 모든 걸 오후 반나절 만에 끝냈습니다.

에이전트에 연결한 것들은 이렇습니다. 이메일, 시스템 로그, Sentry 알림, Stripe 결제 데이터, 그리고 Claude Code.

이 에이전트가 실제로 하는 일을 구체적으로 풀어보면 이렇습니다.

1) 버그 리포트가 들어오면

에이전트가 과거 이메일, 시스템 로그, DB를 자동으로 조합해 원인을 먼저 진단합니다. Brian이 직접 들여다보기 전에 이미 "왜 생겼는지"가 정리되어 있습니다.

개발자가 버그를 처리하는 과정을 생각해보세요. 유저가 "이거 안 돼요"라고 이메일을 보내면, 먼저 Sentry에서 에러 로그를 확인하고, 시스템 로그에서 해당 시점의 기록을 찾고, 과거에 비슷한 이슈가 있었는지 이메일 히스토리를 뒤져야 합니다. 이 과정만 30분에서 1시간이 걸립니다.

에이전트가 이 초기 진단을 자동으로 해주면, Brian은 바로 수정 작업에 들어갈 수 있습니다. 반응 속도가 완전히 달라지는 거죠.

2) 유저 문의가 오면

과거 이메일 스레드를 기반으로 정확한 답변 초안을 작성합니다. 같은 질문에 매번 새로 답장을 쓸 필요가 없어집니다.

1인 사이드 프로젝트에서 CS는 가장 시간을 많이 잡아먹으면서도 가장 하기 싫은 일 중 하나입니다. 특히 같은 질문이 반복될 때, 매번 처음부터 답변을 쓰는 건 정신적 에너지 소모가 큽니다. 에이전트가 과거 이메일 맥락을 학습해서 초안을 만들어주면, Brian은 확인 후 전송만 하면 됩니다. 답변의 일관성도 올라가고, 응답 시간도 줄어듭니다.

3) 결제 데이터를 보다가 이탈 징후가 감지되면

해당 유저에게 먼저 연락하는 이메일 초안을 준비합니다. 유저가 이탈하기 전에 선제적으로 대응합니다.

이건 보통 전담 CS팀이나 데이터 분석가가 있어야 가능한 일입니다. Stripe 결제 데이터에서 이탈 패턴(결제 실패, 사용량 급감, 구독 취소 시도 등)을 모니터링하고, 해당 유저에게 맞춤형 리텐션 이메일을 보내는 건 스타트업에서도 시리즈 A 이후에나 갖출 수 있는 체계죠. Brian은 에이전트 하나로 이 기능을 혼자 운영하고 있습니다.

4) 기능 요청이 들어오면

누가 요청했는지, 그 유저가 서비스를 어떻게 쓰고 있는지까지 파악해 DB에 자동으로 정리합니다. 흩어지던 피드백이 구조화된 데이터가 됩니다.

기능 요청은 보통 이메일, 트위터 DM, 깃허브 이슈 등 여러 채널로 흩어져서 들어옵니다. 이걸 하나하나 DB에 정리하는 건 귀찮은 일이고, 그래서 대부분의 1인 운영자는 피드백 관리를 포기합니다. Brian의 에이전트는 이 과정을 자동화함으로써 유저의 목소리가 데이터로 쌓이는 구조를 만들었습니다.

나중에 다음 기능을 정할 때 "이 기능을 몇 명이 요청했고, 그들의 사용 패턴은 이렇다"는 근거 기반 의사결정이 가능해집니다.

5) 버그나 기능 요청이 접수되면

백그라운드에서 Claude Code를 실행해 코드 수정 요청(PR)까지 자동으로 만들어냅니다.

여기가 가장 놀라운 부분입니다. 에이전트가 단순히 정보를 정리하는 수준을 넘어서, 실제 코드를 수정하는 단계까지 간 겁니다. 물론 Brian이 최종 검토를 하겠지만, PR 초안이 자동으로 만들어진다는 건 개발 사이클이 근본적으로 빨라진다는 뜻입니다.

가장 인상적인 부분은 Brian이 Workers 코드를 한 줄도 직접 쓰지 않았다는 점입니다. Workers README 링크를 붙이고, 마이크에 원하는 결과를 말했더니 에이전트가 완성되었다고 합니다.

Brian의 사례가 보여주는 것

Brian은 사실상 에이전트를 통해 혼자서 CS 담당자, 데이터 분석가, 주니어 개발자, PM을 동시에 두고 있는 셈입니다.

혼자 사이드 프로젝트를 운영하거나, 소규모 팀에서 CS와 개발을 동시에 감당하고 있다면 이 구조가 특히 와닿을 겁니다. 각각의 전문 인력을 두지 않아도 그에 준하는 환경을 만들 수 있다는 이야기니까요.

Ivan이 에세이에서 말한 "30~40배 엔지니어"가 개발 영역에 국한된 이야기가 아니라는 걸 Brian이 보여주고 있습니다.

에이전트를 잘 설계하면 CS, 분석, 개발, 제품 관리까지 한 사람이 커버할 수 있는 범위가 몇 배로 확장되는 거죠.

사례 ③

노션 공동창업자 Simon, 노션 팀 전체가 쓰는 피드백 에이전트

야마다는 개인 생산성을, Brian은 1인 프로젝트 운영을 에이전트로 풀었습니다.

세 번째 사례는 스케일이 다릅니다. 노션 공동창업자 Simon Last가 직접 만든 Notion Feedback Router는 회사 전체가 사용하는 팀 단위 에이전트입니다.

노션 내부에는 'all product feedback chatter'라는 Slack 채널이 있습니다. 누구나 버그나 제품 피드백을 올릴 수 있는 일종의 포괄 채널이죠.

문제는 이 채널을 딱히 아무도 '소유'하지 않는다는 점이었습니다. 피드백이 올라와도 담당 팀이 누군지 몰라서 묻히거나, 아무도 답하지 않는 일이 반복됐습니다. 회사가 커지고 팀이 늘어날수록 이 문제는 더 심해졌죠.

Simon이 만든 피드백 라우터는 이 채널의 모든 메시지를 감지합니다. 메시지가 올라오면, 에이전트가 어떤 팀의 소관인지를 판단해서 해당 팀의 Slack 채널에 자동으로 크로스포스트하고, 필요하면 버그 티켓까지 생성합니다.

여기서 정말 흥미로운 건 라우팅 규칙을 사람이 쓰지 않았다는 점입니다.

Simon은 에이전트에게 빈 노션 페이지를 하나 주고, "이 페이지를 너의 메모리로 써라"고 지시했습니다.

처음에 에이전트는 규칙이 없으니 "이 피드백을 어디로 보내야 할지 모르겠다"고 답합니다. 그러면 사람이 "이건 이 팀 채널로 보내"라고 알려주면, 에이전트가 스스로 라우팅 규칙 페이지를 업데이트합니다. 마치 신입 사원이 첫 주에 배우듯이요.

몇 달이 지나자 이 페이지에는 사람이 한 번도 통독한 적 없는 방대한 규칙이 쌓였지만, 중요한 건, 사람이 아니라 에이전트 스스로가 이 규칙을 관리한다는 점입니다. 덕분에 피드백이 더 이상 묻히지 않습니다.

이 사례가 앞의 두 사례와 근본적으로 다른 점은, 개인이 아니라 조직 전체를 위한 에이전트라는 겁니다.

야마다와 Brian의 에이전트가 '나를 위한 비서'였다면, Simon의 피드백 라우터는 '팀을 위한 교통 경찰'에 가깝습니다.

누구도 소유하지 않던 문제를, 에이전트가 대신 소유하게 된 거죠.

마치며

이들 사례의 공통점은 하나입니다.

기술이 아니라 어떤 반복 작업을 먼저 발견하느냐에서 출발했다는 것입니다.

Ivan이 말한 대로, 우리는 아직 물레방아 단계에 있을지 모릅니다. 하지만 시작점은 거창한 자동화 시스템이 아닙니다.

하루가 멀다 하고 새로운 도구가 쏟아지고, 누군가는 말 한마디로 서비스를 뚝딱 만들었다는 이야기가 들려옵니다. 그런 소식을 볼 때마다 나만 뒤처지는 것 같은 기분이 들기도 하죠.

위의 사례들이 공통적으로 말해주는 건 하나입니다. 이들 중 누구도 처음부터 "시스템을 만들겠다"고 시작하지 않았습니다. 자동화의 시작은 기술이 아니라 관찰입니다.

"내가 매일 반복하고 있는 이 30분, 이걸 에이전트에게 맡길 수 있지 않을까?"

이 질문 하나가 출발점입니다.

AI기능이 포함된 노션을 6개월 동안 무료로 이용하실 수 있는 구독자 특별 혜택을 준비했습니다. :)

노션코리아의 지원을 받아, AI 기능이 포함된 노션을 6개월 동안 무료로 이용하실 수 있는 구독자 특별 혜택을 준비했습니다. 무려 비즈니스 플랜입니다. (직원 수 100명 미만의 기업 계정을 보유하신 분에 한해서입니다. 노션에 유료로 결제한 이력이 없는 도메인을 보유하신 분은 혜택 적용이 가능하십니다.)

👉 노션 스타트업 프로그램 신청하기

다음 주 화요일 오후 8시에는, '빌더 조쉬' 유튜브 채널에서 노션다움님과 함께 '커스텀 에이전트'를 실전적으로 다루어보는 특별 라이브가 준비되어 있습니다. 

[단톡방] 에서 대기해주세요. 기대해주세요!