저는 소프트웨어 엔지니어가 아닙니다.

프로그래밍, 백엔드 개발 (Backend Development), API, 프레임워크 (Frameworks), 인프라 (Infrastructure), 그리고 소프트웨어 엔지니어링 (Software Engineering)에 대해 많은 사람들이 글을 쓰는 커뮤니티인 DEV에 올리는 저의 첫 포스트를 시작하기에는 다소 이상한 방식처럼 들릴 수도 있습니다.

하지만 그것이 바로 제가 이곳에서 솔직하게 시작하고 싶었던 이유입니다.

저는 코딩을 가르치기 위해 여기 있는 척하고 싶지 않습니다. 복잡한 백엔드 아키텍처 (Backend Architecture)를 설명하거나 심도 있는 기술 튜토리얼을 작성하려는 것도 아닙니다. 저의 업무는 다르지만 연결된 영역에 있습니다. 저는 기업들이 자동화 제품을 어떻게 이해하고, 채택하며, 사용하는지를 분석합니다.

저는 BotSailor에서 시장 분석가 (Market Analyst)로 근무하고 있으며, 저의 주력 분야는 AI 자동화 (AI Automation), WhatsApp 챗봇 (Chatbots), SaaS 워크플로우 (Workflows), 고객 지원 자동화 (Customer Support Automation), 그리고 개발자가 구축한 도구들의 비즈니스 측면입니다.

그렇다면 왜 제가 DEV에 글을 쓰고 있을까요?

자동화의 미래는 기술만으로 형성되지 않을 것이기 때문입니다. 기술을 실제 기업들이 어떻게 이해하는지, 기술을 채택하는 과정에서 어디에서 어려움을 겪는지, 그리고 기술적 시스템이 어떻게 비즈니스 가치로 전환되는지에 의해서도 형성될 것입니다.

기능과 채택 사이의 간극

자동화 제품에서는 플랫폼이 할 수 있는 일과 비즈니스 사용자가 실제로 이해하는 것 사이에 종종 간극이 존재합니다.

개발자는 API 통합 (API Integration), 웹훅 (Webhook), 챗봇 흐름 (Chatbot Flow), 또는 AI 에이전트 (AI Agent)를 기술적인 기능으로 볼 수 있습니다. 하지만 비즈니스 소유자는 매우 다른 것을 볼 수 있습니다: 더 빠른 고객 응답, 더 적은 잠재 고객 놓침, 즉각적인 주문 업데이트, 더 낮은 지원 업무량, 또는 더 나은 후속 조치와 같은 것들 말입니다.

기술적 기능 (Technical Feature)	개발자가 보는 것	비즈니스 사용자가 필요로 하는 것	2026 데이터 신호	시장 분석가의 해석
API 통합 (API Integration)	시스템 간 연결성	실시간 고객/주문/지원 데이터	94%가 AI 성공을 위해 API 중심 아키텍처가 필요하다고 답함. (Salesforce)	API는 단순한 백엔드 도구가 아니라, 도입을 위한 인프라이다.
...

2026년 데이터는 왜 이러한 격차가 중요한지를 보여줍니다. Salesforce의 2026년 연결성 보고서(2026 Connectivity Report)에 따르면, IT 리더의 96%가 AI 에이전트의 성공이 원활한 데이터 통합에 달려 있다는 점에 동의하며, 94%는 AI 에이전트의 성공을 위해 IT 아키텍처가 더욱 API 중심(API-driven)으로 변해야 한다고 말합니다. 이는 API가 더 이상 단순한 백엔드 인프라가 아님을 의미합니다. API는 유용한 AI 자동화의 토대가 되고 있습니다.

하지만 도입 측면은 여전히 어렵습니다. MuleSoft의 2026년 연결성 벤치마크 보고서(2026 Connectivity Benchmark Report)에 따르면, 리더의 64%가 아키텍처의 단절로 인해 단기적인 AI 목표를 달성하는 능력에 대해 우려하고 있는 것으로 나타났습니다. 또한 조직의 54%만이 중앙 집중식 거버넌스 프레임워크(centralized governance frameworks)를 갖추고 있으며, AI 에이전트의 50%는 응집력 있는 멀티 에이전트 시스템(multi-agent systems) 외부에서 고립된 상태로 작동하고 있다는 사실도 밝혀졌습니다.

이것이 제가 기술적 기능만으로는 충분하지 않다고 믿는 이유입니다.
기업은 API가 기술적으로 인상적이기 때문에 도입하는 것이 아닙니다. 해당 API가 챗봇이 고객 정보를 수집하고, 후속 조치를 트리거하며, CRM을 동기화하고, 주문 업데이트를 전송하거나, 반복적인 지원 업무를 줄이는 데 도움이 될 때 비로소 API를 도입합니다.

바로 이 지점에서 시장 분석가의 관점이 유용해집니다. 기술 시스템은 반드시 실제 비즈니스 문제와 연결되어야 합니다.

AI 자동화에 구축자와 분석가 모두가 필요한 이유

AI 자동화는 특히 고객 서비스와 비즈니스 운영 분야에서 빠르게 움직이고 있습니다.

자동화 영역	구축자 (Builder)의 역할	분석가 (Analyst)의 역할	양측 모두가 중요한 이유
리드 자격 검증 (Lead Qualification)	양식(Forms), 워크플로우(Flows), API 및 라우팅 로직 구축	무엇이 가치 있는 리드인지 정의	시장 논리(Market logic)가 없다면, 시스템이 데이터를 수집할 수는 있어도 실제 구매자를 선별하는 데는 실패할 수 있음.
...

Salesforce의 2026년 서비스 연구에 따르면, 고객 서비스 전문가의 85%가 자신의 조직이 최소 한 가지 형태의 AI를 사용하고 있다고 답했으며, 66%는 조직이 AI 에이전트 (AI agents)를 사용하고 있다고 답했습니다. 이는 2025년의 39%에서 증가한 수치입니다. 더욱 중요한 점은, AI 에이전트를 사용하는 고객 서비스 조직의 70%가 60일 이내에 측정 가능한 가치를 관찰했다고 답했다는 것입니다.

이것은 기술적인 이야기처럼 들리지만, 동시에 비즈니스 도입 (Business adoption)에 관한 이야기이기도 합니다.

AI 에이전트는 리드 자격 검증을 수행하고, 고객 정보를 수집하며, 후속 조치 (Follow-ups)를 트리거하고, CRM과 연결하며, 주문 업데이트를 전송하고, 이커머스 (eCommerce) 스토어를 지원하며, 영업 및 고객 지원 전반의 팀을 보조할 수 있습니다. 하지만 이러한 워크플로우 (Workflows)가 자동으로 유용해지는 것은 아닙니다. 무엇을 자동화해야 하는지, 언제 실행되어야 하는지, 어떤 데이터가 중요한지, 그리고 어디에서 여전히 인간이 개입해야 하는지를 누군가는 정의해야 합니다.

이것이 바로 AI 자동화에 구축자와 분석가 모두가 필요한 이유입니다.
구축자는 시스템을 이해합니다.
분석가는 도입 격차 (Adoption gap)를 이해합니다.
개발자는 API 연결, 웹훅 트리거 (Webhook trigger), 챗봇 로직 또는 AI 에이전트 액션 (AI agent action)을 구축할 수 있습니다. 하지만 분석가와 비즈니스 팀은 다음과 같은 또 다른 질문들에 답하는 데 도움을 줍니다.

• 비즈니스가 실제로 해결하려는 문제는 무엇인가?
• 현재 어떤 워크플로우가 가장 많은 마찰 (Friction)을 일으키는가?
• 어떤 고객 데이터가 유용하며, 어떤 데이터가 불필요한가?
• 자동화가 신뢰를 향상시키는 지점은 어디이며, 신뢰를 손상시킬 수 있는 지점은 어디인가?
• 성공을 정의하는 지표는 무엇이어야 하는가: 응답 시간 (Response time), 전환율 (Conversion rate), 해결률 (Resolution rate), 고객 만족도 (Customer satisfaction), 또는 유지율 (Retention)인가?

이것이 중요한 이유는 도입(Adoption)이 여전히 운영 준비성(Operational readiness)에 의해 가로막혀 있기 때문입니다. Salesforce의 2026 통계 라이브러리에 따르면, 고객 서비스 리더의 59%가 데이터 준비성(Data readiness)을 AI 도입의 주요 장애물로 보고 있으며, 서비스 운영 전문가들 사이에서는 그 수치가 72%까지 올라갑니다.

따라서 저에게 AI 자동화(AI automation)는 개발자만의 주제도, 마케팅만의 주제도 아닙니다.

그것은 두 영역 사이에 위치합니다.

빌더(Builder)는 시스템이 작동하게 만듭니다.
분석가(Analyst)는 시스템이 유용하게 작동하도록 돕습니다.

비엔지니어로서의 나의 관점

시장 분석가로서, 저는 도입(Adoption) 측면에서 자동화를 바라봅니다.
기업들이 "AI 자동화"가 필요하다고 말할 때, 그들이 실제로 무엇을 원하는지 이해하려고 노력합니다. 때때로 그들은 처음부터 매우 고도화된 AI 시스템을 실제로 필요로 하는 것이 아닐 수도 있습니다. 그들은 먼저 반복적인 업무를 줄여주는 단순하고 신뢰할 수 있는 워크플로(Workflow)가 필요할 수 있습니다.

예를 들어, 한 기업이 다음과 같이 말할 수 있습니다:

"우리는 AI 챗봇이 필요합니다."

하지만 워크플로를 분석해 보면, 실제 요구사항은 다음과 같을 수 있습니다:

"우리는 WhatsApp에서 고객에게 더 빠르게 응답하고, 리드(Lead) 정보를 캡처하며, 후속 조치(Follow-up)를 보내고, 수동 지원의 압박을 줄여야 합니다."

이것은 전혀 다른 차원의 대화입니다.

기술은 여전히 중요합니다. 하지만 비즈니스 문제(Business problem)가 먼저 명확해져야 합니다.

이것이 바로 제가 DEV에서 기여하고 싶은 부분입니다. 코딩 전문가로서가 아니라, 자동화 제품이 기술적 기능(Technical features)에서 실제 비즈니스 활용으로 어떻게 넘어가는지를 연구하는 사람으로서 말입니다.

이곳에서 쓰고 싶은 글들

DEV에서 저는 개발자 인접(Developer-adjacent) 및 비즈니스 중심 관점에서 AI 자동화에 대해 쓰고 싶습니다.

제가 탐구할 계획인 주제 중 일부는 다음과 같습니다:

• 기업들이 AI 챗봇을 생각하는 방식
• 고객 커뮤니케이션에서 WhatsApp 자동화가 중요한 이유
• API 통합(API integrations)이 챗봇 플랫폼을 어떻게 더 유용하게 만드는가
• 왜 많은 자동화 도구들이 도입(Adoption) 과정에서 실패하는가
• 마케터들이 개발자가 구축한 시스템에 필요로 하는 것
• AI 에이전트(AI agents)가 고객 지원 워크플로를 어떻게 변화시키고 있는가
• SaaS 제품이 기술적 기능을 비즈니스 언어로 설명하는 방법

저의 목표는 DEV를 마케팅 채널로 만드는 것이 아닙니다.

AI 자동화의 시장 측면에서 관찰한 내용을 배우고, 기여하며, 기록하는 것이 저의 목표입니다.

만약 제가 BotSailor를 언급한다면, 그것은 기사의 주요 목적이 아니라 저의 전문적인 맥락의 일부로서 언급될 것입니다.

Substack과 DEV: 두 개의 서로 다른 공간

저는 최근 Substack 게시물인 'AI Automation Market Notes'를 통해 AI 자동화에 대한 더 긴 성찰을 쓰기 시작했습니다.

그 공간은 더 개인적이고 분석적입니다. 그곳은 AI 자동화, SaaS 시장, 고객 행동, 그리고 비즈니스 도입(Business adoption)에 관한 더 넓은 생각을 탐구하는 곳입니다.

DEV는 다를 것입니다.
이곳에서 저는 글을 더 실용적이고, 더 구조적이며, 기술적 제품을 구축하거나 관리하거나 깊이 고민하는 사람들에게 더 유용하게 만들고 싶습니다.

Substack은 제가 시장에 대해 깊이 생각하는 곳입니다.
DEV는 그러한 생각들을 빌더(Builders), 개발자, SaaS 팀, 그리고 자동화 중심의 사람들을 위해 번역하고 싶은 곳입니다.

이곳에 있는 단순한 이유

제가 DEV에 글을 쓰는 이유는 간단합니다:

AI 자동화에는 기술적 빌더(Technical builders)와 비즈니스 사용자 사이의 더 나은 대화가 필요하다고 믿기 때문입니다.

어떤 기능이 기술적으로 인상적이라고 해서 가치가 있는 것은 아닙니다. 사람들이 그것을 이해하고, 신뢰하고, 도입하며, 실제 문제를 해결하는 데 사용할 때 비로소 가치가 생깁니다.

그것이 바로 제가 쓰고 싶은 자동화의 측면입니다.

저는 소프트웨어 엔지니어가 아닙니다.
하지만 저는 자동화 제품, 시장 행동, 고객 문제, 그리고 비즈니스 도입(Business adoption)과 밀접하게 일하고 있습니다.

그리고 저는 그러한 관점 또한 대화에 포함되어야 한다고 생각합니다.

저자 노트: 저는 BotSailor의 시장 분석가(Market Analyst)로서의 관점에서 AI 자동화, 챗봇 도입, SaaS 워크플로(Workflows), 그리고 개발자가 구축한 도구의 비즈니스 측면에 대해 글을 씁니다.

AI 공개 사항: 이 기사는 ChatGPT의 도움을 받아 초안을 작성하였으며, 이후 저의 관점, 전문적인 맥락 및 주제에 대한 이해를 반영하기 위해 제가 직접 검토, 편집 및 개선하였습니다.

출처 참고: 이 기사에서 언급된 통계는 원래의 출처와 연결되어 있습니다. 저는 이를 홍보 목적이 아닌 분석을 뒷받침하기 위한 용도로 사용하였습니다.