2025년 10월 6일, OpenAI는 DevDay에서 Agent Builder를 공개했습니다. 상자들을 함께 드래그하여 결과물로 에이전트를 얻을 수 있는 시각적 캔버스(visual canvas)입니다. 8개월 후인 2026년 6월 3일, 이 서비스는 지원 중단(deprecated)되었습니다. 그리고 2026년 11월 30일에 완전히 종료됩니다.

누구의 잘못도 아니었습니다. OpenAI는 시각적 빌더(visual builder)가 올바른 경로가 아니라고 판단했고, 사용자들을 Agents SDK로 안내했습니다. 하지만 만약 당신이 1월에 그 캔버스 위에서 주문 처리 시스템을 구축했다면, 당신은 제품을 출시(shipping)하는 대신 여름 내내 마이그레이션(migrating)을 하며 시간을 보냈을 것입니다. 이것이 바로 "AI 에이전트를 어떻게 구축할 것인가"라는 질문에서 거의 아무도 사전에 묻지 않는 부분이며, 보통 그 시스템이 2년 후에도 여전히 작동할지를 결정짓는 부분입니다.

작동하는 에이전트를 만드는 데에는 네 가지 정직한 경로가 있습니다. 이 경로들은 무엇을 할 수 있느냐보다는 어디에서 한계(break)가 오느냐에 따라 차이가 납니다. 여기 각 경로가 실제로 어떤 비용을 발생시키는지, 그 한계점(ceiling)은 어디인지, 그리고 각각 어떤 종류의 기업에 적합한지 정리했습니다.

당신이 실제로 내리고 있는 결정

대부분의 비교는 기능(features)에서 시작합니다. 그것은 잘못된 접근입니다. 이 목록에 있는 모든 플랫폼은 API를 호출하고, 문서를 읽고, CRM에 기록할 수 있습니다. 기능 목록은 18개월 전에 이미 수렴되었습니다.

아직 수렴되지 않은 것은 다음 네 가지 질문에 대한 답입니다:

에이전트가 무엇을 건드리는가? 답장을 초안하는 에이전트는 환불을 실행하는 에이전트와는 다른 위험 등급(risk class)을 가집니다. 전자는 틀려도 비용이 들지 않지만, 후자는 틀릴 경우 이를 되돌려야 하기 때문에 두 번의 비용이 발생할 수 있습니다.

틀렸을 때 누가 책임을 지는가? 철학적인 문제가 아니라 운영적인 문제입니다. 어떤 사람이 이를 발견하며, 얼마나 빨리 발견하고, 그들은 이에 대해 무엇을 하는가입니다. 만약 답이 "고객이 불만을 제기할 때까지 아무도 모른다"라면, 플랫폼과 상관없이 그 에이전트는 준비되지 않은 것입니다.

프로세스가 얼마나 자주 바뀌는가? 일 년에 두 번 바뀌는 프로세스는 경직된 플랫폼(rigid platform)에 잘 맞습니다. 한 달에 두 번 바뀌는 프로세스는 스스로 수정할 수 없는 모든 것에 타격을 줍니다.

이것이 당신의 경쟁 우위(competitive edge)인가, 아니면 단순한 배관(plumbing)인가? 더 나은 송장 라우팅(invoice routing)만으로 시장에서 승리할 수는 없습니다. 배관은 구매하십시오. 경쟁 우위는 직접 구축하십시오.

그 네 가지 질문에 답을 내린다면 경로는 스스로 결정될 것입니다. 이 질문들을 건너뛴다면 당신은 Gartner의 통계 수치에 포함되게 될 것입니다. 해당 분석 기업은 2027년 말까지 에이전트형 AI (agentic AI) 프로젝트의 40% 이상이 취소될 것으로 예상하며, 그 세 가지 이유로 비용 상승, 불분명한 비즈니스 가치, 그리고 불충분한 리스크 통제 (risk controls)를 꼽았습니다. 이 중 어느 것도 기술적인 문제는 아닙니다. 세 가지 모두 미뤄진 의사결정의 문제입니다.

경로 1: 노코드 빌더 (No-Code Builders)

Chatbase, Lindy, Relevance AI, Gumloop 및 수십 개의 다른 서비스들이 여기에 해당합니다. 문서를 업로드하고, URL을 붙여넣고, 시각적 에디터 (visual editor)를 통해 몇 가지 도구를 연결하면 그날 오후 바로 질문에 답하는 무언가를 갖게 됩니다. 고정된 진입형 요금제를 게시한 플랫폼들을 살펴보면, 첫 번째 유료 티어의 중앙값은 월 약 24달러 수준입니다.

이 경로는 한 가지 측면에서 진정으로 훌륭합니다. 즉, 누군가 실제 돈을 쓰기 전에 유스케이스 (use case)가 실제로 작동하는지 증명하는 것입니다. 저는 한 회사가 에이전트가 자신들의 접수 질문을 처리할 수 있을지 여부를 두고 3주 동안 논쟁하는 것을 지켜보았습니다. 노코드 빌더로 보낸 토요일 오후는 그 논쟁을 끝냈는데, 아무도 예상하지 못한 방향으로 결론이 났습니다. 네 가지 질문 유형 중 두 가지는 사소한 것이었습니다. 나머지 두 가지는 영구적으로 사람이 필요했습니다.

한계점은 판매 페이지에서 암시하는 것보다 더 빨리 찾아오며, 특정한 지점에서 발생합니다. 바로 플랫폼이 예상하지 못한 결정이 필요한 상황입니다. 보통 도구들을 연결할 수는 있습니다. 하지만 도구들 사이에서 어떤 일이 일어날지를 제어하는 것은 거의 불가능합니다. 에이전트가 한 시스템을 확인하고, 찾은 내용을 바탕으로 결정한 다음, 두 번째 시스템을 통해 다른 경로를 타야 할 때, 대부분의 노코드 빌더는 이를 표현할 수 없거나 너무 어색하게 표현하여 워크플로 (workflow)를 유지 관리할 수 없게 만듭니다.

두 번째 한계는 데이터입니다. 이것들은 호스팅된 서비스 (hosted services)입니다. 귀하의 고객 기록은 귀하가 통제하지 않는 인프라를 거치며, 귀하가 협상하지 않은 약관에 따라 처리됩니다. 공개적인 FAQ라면 괜찮습니다. 하지만 EU 고객의 개인 정보가 포함된 것이라면, 업로드한 후가 아니라 업로드하기 전에 약관을 읽으십시오.

적합한 경우: 에이전트가 도움이 되는지 테스트하는 기업, 또는 민감한 데이터에 접근하지 않는 소규모의 공개적인 서비스를 운영하는 경우.

두 번째 경로: 엔터프라이즈 스위트 (Enterprise Suites)

Salesforce Agentforce와 Microsoft Copilot Studio가 중요한 두 가지이며, 이들의 가격 책정 방식은 이들이 누구를 대상으로 하는지에 대해 거의 모든 것을 말해줍니다.

Agentforce는 대화당 2달러를 부과합니다. 또는 액션당 약 10센트인 20 Flex Credits를 부과합니다. 혹은 지정된 라이선스(named licence) 사용자당 월 125~150달러를 부과합니다. Copilot Studio는 Copilot Credits로 비용을 청구합니다: 25,000개들이 선불 팩이 200달러이며, 이는 개당 약 0.8센트에 해당합니다. 종량제(pay as you go) 방식으로는 개당 1센트입니다.

중간 정도의 상호작용 깊이(interaction depth)에서, Copilot Studio의 대화 비용은 약 18센트 근처에 머무는 반면, Agentforce의 대화 비용은 2달러로 고정됩니다. 이는 11배의 격차로 보이며, 모든 Microsoft 영업 자료(sales deck)는 정확히 이 비교 수치를 보여줄 것입니다.

하지만 이 비교는 그 자체로는 무용지물입니다. 왜냐하면 두 수치 모두 당신이 이미 기반이 되는 제품을 소유하고 있다고 가정하기 때문입니다. 실제로 Agentforce를 사용하려면 연간 약 60,000달러에 달하는 Service Cloud와 Data Cloud 구독이 필요합니다. Copilot Studio는 당신이 이미 Microsoft 365와 Power Platform 테넌트(tenant) 비용을 지불하고 있다고 가정합니다. 해당 테넌트를 보유하고 있다면, Copilot Studio는 시작 비용이 거의 무료에 가깝습니다. 보유하고 있지 않다면, 진입 가격은 Microsoft 스택 전체 비용이 됩니다.

이 경로에서의 진짜 거래(trade-off)는 가격이 아닙니다. 바로 거버넌스(governance)를 무료로 얻는다는 점입니다. 감사 로그(Audit logs), 권한 모델(permission models), 데이터 레지던시(data residency), 보관 정책(retention policy) 등 직접 구축하려면 수개월이 걸리는 전체 컴플라이언스 체계(compliance apparatus)가 첫날부터 제공되며, 별도의 논의 없이도 법무 부서의 요구를 충족시킵니다. 규제 대상 기업에게는 이것이 라이선스 비용보다 더 가치 있는 일입니다.

비용이 상한선이며, 그 상한선은 매우 엄격합니다. 두 플랫폼 모두 각자의 생태계 내부에서는 훌륭하지만, 생태계 외부에서는 다루기 어렵습니다. 에이전트가 귀사의 자체 구내(premises)에 있는 머신, 특정 산업용 소프트웨어, 또는 클라우드 이전 시대의 데이터베이스에 접속해야 하는 순간, 어차피 커스텀 커넥터 (custom connectors)를 직접 작성해야 하며, 플랫폼이 제공하는 비용 효율성은 사라집니다.

적합한 경우: 이미 Salesforce나 Microsoft 365 환경에서 운영 중인 기업, 에이전트의 작업이 해당 세계관 내에 머무는 경우, 그리고 컴플라이언스 (compliance) 승인이 모든 프로젝트에서 가장 느린 단계인 경우.

세 번째 경로: 에이전트 단계가 포함된 워크플로 플랫폼 (Workflow Platforms With Agent Steps)

n8n이 가장 명확한 사례이며, 제가 대화하는 대부분의 중소기업이 계획하지 않았음에도 결국 도달하게 되는 경로입니다. 커뮤니티 에디션 (Community Edition)은 무료이며 셀프 호스팅 (self-hosted) 방식이므로, 서버 비용과 모델 호출 (model calls) 비용 외에는 추가 비용이 들지 않습니다. 클라우드 스타터 (Cloud Starter)는 월 20유로에 2,500회 실행을 제공하며, 프로 (Pro)는 월 50유로에 10,000회 실행을 제공합니다.

이 방식의 사고 모델 (mental model)은 다른 두 경로와 다르며, 그것이 핵심입니다. 프로세스를 명시적인 단계가 있는 흐름 (flow)으로 그리되, 판단이 필요한 지점에만 모델을 배치합니다. 그 외의 모든 것은 결정론적 (deterministic)인 상태로 유지됩니다. 메일함을 읽는 것, 항상. 필드를 추출하는 것, 항상. 이 항목이 세 부서 중 어디에 속하는지 결정하는 것, 모델. 티켓 시스템에 기록하는 것, 항상.

이러한 구조는 이 분야 전체에서 가장 큰 신뢰성 문제를 조용히 해결합니다. 모델의 결정 과정을 충분히 길게 연결하면 수학적으로 불리해집니다. 각 단계가 95%의 확률로 정확하다면(괜찮아 보일 수 있지만), 20단계를 순차적으로 거치면 정확도는 약 36%로 떨어집니다. 신뢰성은 곱셈적 (multiplicative)이며, 직관이 예상하는 것보다 훨씬 빠르게 붕괴합니다. 3개의 모델 결정과 17개의 결정론적 단계로 구성된 흐름은, 비록 슬라이드 상에서는 둘 다 "에이전트"처럼 보일지라도, 20개의 모델 결정으로 구성된 흐름과는 근본적으로 다른 기계입니다.

유럽에서는 국제적인 비교 수치들이 인정하는 것보다 셀프 호스팅 (Self-hosting)이 더 중요합니다. 2026년 초에 실시된 604개 독일 기업 대상의 Bitkom 설문조사에 따르면, 데이터 보호에 대한 불확실성이 AI를 전혀 사용하지 못하게 만드는 가장 많이 언급된 단일 장애물이었으며, 41%가 이를 지목했습니다. 오케스트레이션 (Orchestration)을 자체 서버에서 실행한다고 해서 그 자체로 규정 준수 (Compliance)가 되는 것은 아니지만, 프로젝트를 6주 동안 지연시키는 그 질문 자체를 제거해 줍니다.

그 대가는 로우코드 (Low-code)가 노코드 (No-code)가 아니라는 점입니다. 표현식 (Expressions), 에러 처리 (Error handling), 재시도 (Retries), 그리고 커스텀 노드 (Custom nodes)는 모두 기술적인 역량을 가진 사람에게 유리합니다. 디버깅 (Debugging)을 한 번도 해본 적 없는 사람의 손에 들린 워크플로 플랫폼은 아무도 신뢰하지 않는, 절반만 완성된 흐름들의 더미가 되어버립니다.

적합한 경우: 정의된 프로세스가 있고, 사내 또는 외부 계약을 통해 어느 정도의 기술적 역량을 보유하고 있으며, 데이터를 자체 인프라에 유지해야 할 이유가 있는 기업.

네 번째 경로: 제대로 구축하기

가장 끝단에서는 에이전트를 직접 조립합니다. 작업에 선택된 모델, 모델을 둘러싼 루프 (Loop), 실제 인터페이스로 정의된 도구 (Tools), 재시작 후에도 유지되는 메모리 (Memory), 결정과 행동 사이에 위치하는 가드레일 (Guardrails), 그리고 지난주의 변경 사항이 상황을 개선했는지 악화시켰는지 알려주는 평가 세트 (Evaluation set)가 필요합니다.

맞춤형 워크플로 에이전트 (Custom workflow agent)에 대한 업계 추정치는 25,000달러에서 100,000달러 사이이며, 멀티 에이전트 시스템 (Multi-agent systems)은 이를 훨씬 상회합니다. 이 수치들은 견적이라기보다는 규모의 차이 (Orders of magnitude)로 취급하십시오. 왜냐하면 그 범위는 해당 시스템이 얼마나 많은 시스템을 건드려야 하는지에 따라 거의 전적으로 달라지기 때문입니다.

이 경로를 통해 얻는 것은 상한선도 없고 건물주도 없는 유일한 경로입니다. 아무도 8개월 뒤에 당신의 아키텍처 (Architecture)를 폐기하지 않습니다. 아무도 당신의 대화당 요금을 재산정하지 않습니다. 프로세스가 변경되면, 당신이 에이전트를 변경하면 됩니다.

이 경로를 2년 전보다 더 저렴하게 만든 결합 조직(connective tissue)은 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)입니다. Anthropic은 이를 2024년 11월에 오픈 표준으로 출시했으며, 2025년 12월에는 Linux Foundation 산하의 Agentic AI Foundation에 이관했습니다. OpenAI, Google, Microsoft, IBM, Amazon 모두 이를 지원합니다. SDK 다운로드 수는 출시 당시 10만 건에서 2026년 3월 기준 월 9,700만 건으로 증가했습니다. 실질적으로 이는 당신이 ERP를 위해 작성한 커넥터가 당신이 지정하는 어떤 모델과도 작동함을 의미하며, 나중에 모델을 교체하는 것은 재작성이 아닌 설정 변경(configuration change)의 문제가 됩니다. 이 단 하나의 속성 덕분에 맞춤형 구축(custom building)이 더 이상 특정 벤더에 아키텍처를 거는 것을 의미하지 않게 되었습니다.

비용은 이제 당신이 운영 시스템(operational system)을 소유하게 된다는 점입니다. 이는 모니터링이 필요하고, 이를 이해하는 사람이 필요하며, 첫 달에는 아무도 상상하지 못했던 예외 케이스(edge cases)가 4개월 차에 나타날 것입니다.

적합한 경우: 진정으로 당신의 소유인 프로세스, 어떤 플랫폼도 알지 못하는 시스템을 건드리는 경우, 당신의 통제를 벗어날 수 없는 데이터를 다루는 경우, 또는 제품에 충분히 밀접하여 임대해서는 안 되는 경우.

네 가지 경로의 나란한 비교

왜 대부분의 이러한 프로젝트가 실패하는가

두 가지 수치가 이를 솔직하게 보여줍니다. MIT의 Project NANDA는 2025년 8월, 생성형 AI 파일럿의 95%가 손익(profit and loss)에 측정 가능한 기여를 하지 못했다는 사실을 발견했습니다. Gartner는 에이전트 프로젝트의 40% 이상이 2027년 말까지 취소 목록에 오를 것으로 예상합니다.

이를 종합해 보면, 그리고 제가 실무에서 목격하는 바에 비추어 볼 때, 패턴은 에이전트가 작동하지 않는 것이 아닙니다. 문제는 기업들이 병목 현상 (bottleneck)이 전혀 아니었던 프로세스를 선택한다는 점입니다. 사람이 일주일에 20분 정도 소요하는 작업을 자동화하면, 작동하는 에이전트는 만들어지지만 측정 가능한 결과는 나오지 않습니다. 그 20분은 다른 곳으로 흘러가 버리고 아무도 눈치채지 못하며, 예산 검토 (budget review) 시점이 되면 해당 프로젝트는 내세울 만한 성과가 없게 됩니다.

그에 대한 대응책은 그리 화려하지 않습니다. 누군가가 눈에 띄게 허덕이고 있는 프로세스를 선택하십시오. 손을 대기 전에 먼저 측정하십시오. 지루한 중간 과정 (boring middle)을 자동화하고, 판단 (judgement calls)이 필요한 부분은 그대로 두십시오. 그러면 검토 시에 나오는 수치는 실제 수치가 될 것입니다.

이와 함께 기억할 만한 독일의 데이터가 하나 있습니다. 2026년 3월에 발표된 Salesforce와 Deutscher Mittelstands-Bund 지수에 따르면, 이미 AI 에이전트를 사용 중인 독일 중견 기업은 16.6%로, 1년 전 8.7%에서 증가했습니다. 두 배가 된 것입니다. 하지만 Bitkom 설문 조사에 참여한 기업 중 AI 전략 (AI strategy)을 아예 가지고 있는 기업은 21%에 불과했습니다. 배포 (deployment)와 전략 사이의 이 격차가 바로 프로젝트가 취소되는 정확한 원인입니다.

우리가 접근하는 방식

우리는 AI 시스템 작업의 일부로 에이전트를 구축하며, 그 프로세스는 초기 단계에서 의도적으로 지루하게 진행됩니다.

첫째, 우리는 프로세스 다이어그램 (process diagram)이 아니라, 현재 그 일을 수행하는 사람과 함께 실제 작업 (task)을 살펴봅니다. 그들이 생각 없이 처리하는 예외 사항 (exceptions)까지 포함하여 작업을 살펴봅니다. 왜냐하면 그 예외 사항들이 바로 2주 차에 데모 에이전트 (demo agents)를 망가뜨리는 원인이기 때문입니다.

그다음에는 범위를 엄격하게 설정합니다. 하나의 작업, 명확한 경계, 정의된 입력값 (inputs)과 출력값 (outputs)이 필요합니다. 모든 것을 하려고 시도하는 에이전트는 아무도 디버깅 (debug)할 수 없고 아무도 신뢰할 수 없는 존재가 되어버립니다.