몇 주 전, 저는 새로운 프로젝트를 설정해야 했고 평소의 과정을 거쳐야 했습니다. Notion 문서를 만들고, Linear 보드를 띄우고, 팀원들을 Slack에 초대하고, 이 모든 것을 연결하기 위해 몇 가지 Zapier 자동화를 설정했습니다. 오후 대부분을 소비했습니다.

그때 깨달았습니다. 저는 사실 이 도구들 중 어떤 것을 '사용'하려고 한 것이 아니었습니다. 단지 결과물만 원했을 뿐입니다. 프로젝트가 설정된 상태를 원했습니다. 그리고 다섯 번째 Zapier 트리거와 세 번째 실패한 웹훅 사이에서, 저 자신에게 이런 생각을 하게 되었습니다. 왜 제가 이 모든 것을 연결하는 역할을 해야 하는 걸까요?

이 질문이 사실 이 글의 핵심 논지입니다. AI 에이전트는 단순히 SaaS에 추가된 새로운 기능 카테고리가 아닙니다. 그것들은 애초에 SaaS가 존재하는 '이유' 자체를 잠식하기 시작하고 있습니다.

기존 방식: 소프트웨어는 워크플로우를 임대합니다

전통적인 SaaS는 결과물(outcome)이 아니라 워크플로우(workflow)를 판매합니다. Notion에 비용을 지불하면, Notion은 당신의 생각을 담아낼 매우 좋고도 엄격한 형태를 제공합니다. HubSpot에 비용을 지불하면, CRM 형태가 주어집니다. Zapier에 비용을 지불하는 이유는 이 형태들을 어색하게 꿰매 붙이기 위해서입니다.

이 방식은 지난 20년간 잘 작동했습니다. 왜냐하면 대안은 모든 것을 직접 구축하는 것이었기 때문입니다. SaaS는 지름길이었습니다. 하지만 그 지름길에는 세금이 따랐습니다. 즉, 당신의 작업을 도구에 맞게 조정해야 했고, 두 개의 도구가 서로 소통해야 할 필요가 생길 때마다 파트타임 통합 엔지니어(integrations engineer)가 되어야 했습니다.

새로운 방식: 소프트웨어가 워크플로우를 대신 처리합니다

AI 에이전트는 그 관계 자체를 뒤집습니다.

1. 목표를 하위 작업(subtasks)으로 분해합니다
2. 실제로 작업을 수행하기 위해 도구/API를 호출합니다
3. 자체 출력을 확인하고 경로를 수정합니다(course-corrects)
4. 단순히 응답을 생성하는 것까지가 아니라, 목표가 실제로 달성될 때까지 계속 진행합니다

이러한 루프—계획(plan), 실행(act), 관찰(observe), 조정(adjust)—가 진정한 잠금 해제 지점(real unlock)입니다. 이는 검색창과 직원의 차이점입니다.

회사들이 단순히 챗봇 대신 에이전트를 구축하는 이유
**
제가 보기에 여기에는 세 가지 솔직한 이유가 있으며, 그중 모두 이타적인 것은 아닙니다.**

1. 챗봇은 빠르게 한계에 부딪힙니다(hit a ceiling fast). 자주 묻는 질문(FAQ)에 답변할 수 있는 지원용 챗봇도 좋지만, 인력 감축을 가져오지는 못합니다. 실제로 환불 처리, 데이터베이스 업데이트, 티켓 마감까지 할 수 있는 에이전트는 다릅니다. 회사들이 '작업을 설명하는 방법' 대비 '실제 작업을 수행하는 것'의 투자수익률(ROI)을 깨닫자, 더 나아가야 할 인센티브가 명확해졌습니다.

2. 인터페이스 자체가 제품이 되고 있습니다. 에이전트가 사용자를 대신하여 열 가지 다른 도구를 능숙하게 사용할 수 있다면, 가치는 특정 단일 도구의 사용자 인터페이스(UI)에서 벗어나 에이전트를 오케스트레이션하는 사람에게로 이동합니다. 만약 당신의 전체 해자(moat)가 멋진 대시보드였던 SaaS 회사라면, 이는 매우 위험한 상황입니다. 그래서 많은 회사들이 다른 누군가가 자신들 위에 구축하기 전에 스스로 에이전트 레이어를 구축하기 위해 경쟁하고 있습니다.

3. 유지율 계산법(Retention math) 자체가 완전히 바뀝니다. SaaS 가격 책정은 항상 '좌석당, 월별, 영구적'이었습니다. 에이전트는 가치 단위를 '완료된 작업(task completed)'으로 변경합니다. 이는 훨씬 가격을 매기기 어려운 것이지만, 동시에 해자를 구축하기에 훨씬 더 강력한 요소입니다—실제 작업을 완료하는 에이전트를 소유한 사람이 인터페이스를 소유한 사람보다 고객과의 관계를 소유하게 됩니다.

이 모든 것이 챗봇이 죽었다는 의미는 아닙니다. 이는 챗봇들이 학습용 바퀴(training wheels)였으며, 이제 모델 자체가 핸들바를 잡을 만큼 충분히 좋아졌기 때문에 많은 회사들이 조용히 그것들을 제거하고 있다는 의미입니다.

이는 더 이상 가설이 아닙니다.

이미 현장에서 이 모양새를 볼 수 있습니다:

• 단순히 한 줄을 자동 완성하는 것을 넘어 PR(Pull Request)을 열고, 테스트를 실행하며, 리뷰 코멘트에 응답하는 코딩 어시스턴트
• 사람이 스프레드시트를 만지지 않고도 세 개의 다른 시스템에 걸쳐 인보이스를 조정하는 Ops 에이전트
• 단순히 파란색 링크 10개를 반환하는 것이 아니라, 출처가 명확한 완성된 구조화된 보고서를 반환하는 리서치 에이전트

공통점은 'AI가 관여했다'는 것이 아닙니다. 과거에는 사람이 단계들 사이의 접착제 역할을 했지만, 이제는 다른 무언가가 그 역할을 하고 있다는 것입니다.

불편한 진실을 말씀드리자면

저는 이 트렌드가 순전히 좋은 소식이라고 생각하지 않으며, 그렇게 가장하는 것은 거짓말일 것입니다. 몇 가지 생각해 볼 만한 점들이 있습니다:

• 디버깅(Debuggability)이 더 어려워집니다. 워크플로우가 수십 개의 명시적인 Zapier 단계에 존재할 때는 어디서 문제가 발생했는지 정확히 알 수 있었습니다. 하지만 에이전트가 '스스로 해결'하게 되면, 실패의 원인이 더욱 모호해지고 신뢰는 단순한 마케팅 문구가 아니라 실제 엔지니어링 문제가 됩니다.
• 많은 직업들이 기능적으로 도구들 사이의 통합 계층(integration layer) 역할을 하고 있었습니다. 그 일은 우아하게 사라지지 않습니다. 단지 필요성이 줄어들 뿐이며, 이는 트렌드 기사의 각주가 아닌, 실제 사람들에게는 현실적인 비용입니다.
• 벤더 종속성(Vendor lock-in)이 사라지는 것이 아니라 — 단지 이동할 뿐입니다. 대시보드에 갇히는 대신, 자신의 워크플로우를 가장 잘 아는 에이전트에 갇힐 수도 있습니다. 이는 가볍지 않은, 오히려 더 깊은 형태의 종속성이라고 할 수 있습니다.

제가 이 점들을 언급하는 이유는 많은 'AI가 X를 대체한다' 콘텐츠들이 흥미로운 부분으로 곧장 넘어가고 마찰(friction)을 무시하기 때문입니다. 그 마찰이야말로 진정한 엔지니어링 문제 — 그리고 솔직히 말해, 진정한 기회 — 가 있는 곳입니다.

그렇다면 '소프트웨어'라는 카테고리는 어떻게 될까요?

제 솔직한 추측은 이렇습니다. 소프트웨어는 사라지지 않지만, 우리가 돈을 지불하는 대상이 한 단계 위로 이동할 것입니다. 지금은 앱에 대한 접근 권한을 구매합니다. 점차적으로는 결과(outcome)에 대한 접근 권한을 구매하게 될 것이고, 에이전트가 그 과정에서 어떤 앱(혹은 아무것도 없는)을 건드릴지 결정할 것입니다. 앱 자체들은 방문하는 목적지라기보다는 도구 상자의 도구 같은 존재가 되어갈 것입니다.

만약 지금 제품을 개발하고 있다면, 실질적인 교훈은 이것입니다. '어떻게 하면 우리 SaaS에 챗봇을 추가할까?'라고 묻지 마세요. 대신 '고객이 우리의 대시보드를 한 번도 열어보지 않고 에이전트에게 원하는 것을 말만 했다면, 과연 우리 제품이 여전히 그 일을 처리하고 있을까?'라고 물어보세요. 만약 솔직한 답이 '아니요'라면, 그것은 충분히 밤잠을 설칠 가치가 있는 문제입니다.

다른 분들은 이 상황이 어떻게 전개되고 있는지 궁금합니다. 에이전트 중심의 제품을 개발하고 계신가요, 아니면 여전히 기존 SaaS에 AI 기능을 붙이고 계신가요? 다양한 회사 내부에서 어떤 모습인지 진심으로 듣고 싶습니다.