직원 누구나 AI agent(스스로 판단해 여러 단계의 작업을 처리하는 AI 프로그램)를 만들어 쓰게 하는 서비스는 이제 흔한 창업 아이템입니다. 그 가운데 Gumloop는 Shopify, Gusto, Instacart 같은 기업에 실제로 넓게 배포된 사례로 꼽힙니다. 이 회사의 성장 과정을 따라가 보면, 기업 고객을 얻은 결정적 요인은 AI 성능 자체보다 IT 부서가 안심하고 허용할 수 있는 통제 장치와 직원이 매일 쓰는 도구 안으로 들어가는 설계였던 것으로 보입니다.
워크플로 빌더에서 agent 플랫폼으로
Gumloop는 2024년 겨울 Y Combinator 배치(W24)에 지원할 당시 Agent Hub라는 이름이었습니다. AI agent라는 말이 널리 알려지기 전이라 부동산 중개 회사로 오해받기도 했다고 합니다.
처음 제품은 agent가 아니라 워크플로 자동화 도구였습니다. 사용자가 화면에서 노드를 이어 단계별 논리를 직접 설계하는 방식입니다. 당시 언어 모델은 작업 전체를 스스로 처리할 만큼 믿을 만하지 않았기 때문에, 정해진 순서대로 움직이는 흐름 안에 AI가 들어갈 자리를 좁게 두어 안정성과 비용을 챙겼습니다.
모델의 추론과 지시 이행 능력이 좋아지자 같은 빌더에 agent 기능을 더했습니다. 사용자가 중간 단계를 일일이 설정하지 않아도 agent가 스스로 작업을 이어 가게 되면서 사용량이 가파르게 늘었습니다. 기술 수준에 맞춰 먼저 제품을 내놓고 모델이 발전할 때 제품을 한 단계 끌어올린 셈입니다.
현재 사용자는 채팅 화면에서 agent를 만들고, 미리 준비된 연결 기능으로 업무 앱을 고릅니다. 만든 agent는 Slack이나 Microsoft Teams 안에 배치할 수 있습니다. 개발 조직을 위해서는 SDK, REST API와 MCP(Model Context Protocol, AI가 외부 도구와 데이터에 접속하는 표준 방식) 서버로 공개한 수백 개의 연동 기능을 제공합니다.
개인 사용자에서 기업 고객으로
초기 성장은 개인 개발자와 생산성 도구를 즐겨 쓰는 사용자 사이에서 일어났습니다. 두 시간짜리 Dungeons & Dragons 게임 기록을 받아 적고 요약해 참가자에게 메일로 보내는 사례가 대표적이었습니다. 신선한 쓰임새였지만 경제적 가치는 크지 않았고, 개인마다 작업이 달라 표준화하기도 어려웠습니다.
방향을 바꾼 계기는 호주의 한 헬스테크 기업이었습니다. 웹에 흩어진 연구 자료를 모아 정리하는 복잡한 작업을 Gumloop로 자동화하면서, 기업은 비용이 큰 업무 병목을 풀어 주는 도구에 훨씬 많은 돈을 낸다는 점이 드러났습니다. CEO는 첫해에 고객 발굴과 도입 지원 통화를 1,100건가량 하며 어떤 기능에 기업 사용자가 반응하는지 하나씩 확인했습니다.
첫 대형 고객 Instacart는 영업이 아니라 한 내부 사용자에게서 시작됐습니다. 이 직원이 사내 Slack 채널에서 Gumloop 사용법을 알리고 동료에게 자동화 사례를 보여 주면서 여러 부서로 쓰임이 퍼졌습니다. Gumloop는 나중에 이 직원을 초기 직원으로 채용했고, 그에게서 기업 구매 절차와 영업 방식을 배웠습니다.
Shopify 도입도 Instacart 쪽 지인의 추천에서 시작됐습니다. Shopify는 같은 주에 여러 자동화 도구를 시험해 사내에서 가장 자연스럽게 퍼지는 도구를 골랐고, 하루 만에 직원 4,000~8,000명에게 Gumloop를 열었습니다. 수천 명이 별도 교육 없이 각자 자동화를 만들어 내는 모습은 제품이 손을 잡아 주지 않아도 쓰인다는 확인이 됐습니다. 이후 Shopify는 Gumloop에 투자했습니다.
▲ 사내 추천으로 퍼진 도입
기업이 요구한 것은 기능을 막는 장치
대기업에 팔기 시작하면 요구 사항은 자동화 기능 밖으로 크게 넓어집니다. Gumloop가 갖춰야 했던 항목은 다음과 같습니다.
| 요구 사항 | 내용 |
|---|---|
| RBAC | 역할에 따라 쓸 수 있는 기능과 데이터를 나누는 접근 제어 |
| SAML SSO | 회사 계정 하나로 로그인하는 통합 인증 |
| SCIM | 사용자 계정을 자동으로 만들고 없애는 기능 |
| 감사 로그 | 누가 무엇을 실행했는지 남기고 회사 데이터 저장소로 보내는 기록 |
| 프라이빗 배포 | 고객의 클라우드 안에서 플랫폼을 운영하는 방식 |
| 자체 API 키 | 고객이 계약한 모델의 키를 직접 연결하는 기능 |
외주 인력에게는 일부 기능만 열어 주는 식의 세밀한 격리도 자주 요구됩니다. 힘들게 만든 기능을 끄거나 제한하는 장치를 만드는 일은 개발자에게 처음엔 답답했지만, 기업 도입의 필수 조건이었다고 합니다.
브라우저 자동화처럼 단순해 보이는 기능도 아래에는 큰 관리 체계가 필요합니다. IT 관리자는 접속을 허용할 웹사이트를 정하고, 허용하지 않은 동작을 막고, 실행 기록을 다시 볼 수 있어야 합니다. Gumloop는 동시에 돌아가는 세션 5,000개의 기록을 비용과 안전 측면에서 살펴볼 수 있는 세션 재생 기능까지 만들었습니다.
직원이 쓰게 만드는 설계
기업 안에서 AI 도구가 실제로 쓰이게 하는 핵심은 직원이 이미 쓰는 도구 안에 agent를 두는 것입니다. 별도 포털로 이동해야 하면 그만큼 손이 덜 갑니다. 공개 Slack 채널에서 같은 일을 하는 동료가 agent에게 질문하는 모습을 보면 다른 직원도 자연스럽게 따라 쓰게 됩니다.
빈 화면 앞에서 무엇을 만들지 몰라 막히는 문제는 템플릿과 워크숍으로 풀었습니다. 초기 템플릿이 세 개뿐이던 시절 Y Combinator 파트너에게서 최소 100개는 만들라는 조언을 듣고 템플릿 모음과 쓰임새별 안내 페이지를 갖췄습니다. 고객 팀과 여는 워크숍에서는 “마법 지팡이가 있다면 무엇을 자동화하겠습니까?“라고 묻는 것만으로 수십 가지 쓰임새가 나온다고 합니다.
가격 정책도 같은 방향으로 바꿨습니다.
- 처음에는 ChatGPT Plus를 본뜬 월 $20, $40 요금제로 시작했습니다.
- 기업이 얻는 가치가 훨씬 크다는 것을 알고 Y Combinator 배치 기간에 가격을 세 번 두 배로 올렸습니다.
- 크레딧 방식을 거쳐 지금은 token, 컴퓨팅, 외부 API 비용을 원가 그대로 청구하고 여러 모델과 도구를 엮어 실행해 주는 orchestration 수수료를 따로 받습니다.
좌석당 요금은 관리자가 사용 권한을 나눠 주게 만들어 확산을 막는다는 판단입니다. 전 직원이 쓸 수 있으면 써도 되는지 망설이는 일이 사라집니다. 비용을 투명하게 넘기면 고객이 Gumloop를 이윤을 숨기는 SaaS가 아니라 Vercel, Cloudflare 같은 인프라 업체처럼 받아들인다고 봅니다.
모델 선택권과 비용 통제
Gumloop는 Claude, OpenAI 모델, Amazon Bedrock, 기업 자체 게이트웨이를 모두 지원하며 클릭 한 번으로 모델을 바꿀 수 있게 했습니다. 스스로를 스위스 같은 중립 플랫폼으로 설명합니다. 여기에 ’agentic sovereignty’라는 개념을 더합니다. 기업이 데이터베이스, 실행 기록, 인증 정보, 연동 논리를 자기 클라우드 안에 두고 직접 소유해야 특정 모델 업체에 묶이지 않는다는 주장입니다. 모델 업체가 언젠가 API 고객과 겹치는 응용 서비스를 직접 내놓을 것이라는 전망도 이 주장의 배경입니다.
모델 선택은 비용 문제이기도 합니다. 이사회 보고용 성장 모델처럼 중요하고 복잡한 작업에는 최신 frontier 모델(가장 성능이 높은 최상위 모델)이 필요하지만, 시간당 8만 번 실행되는 고객 지원 분류 작업에는 작고 싼 모델이 맞습니다. 관리 화면에서 부서나 쓰임새별로 쓸 수 있는 모델을 정해 두지 않으면 직원은 대개 가장 비싼 모델부터 고른다는 것이 Gumloop의 경험입니다.
▲ 작업별 모델 배정과 비용 통제
아래에서 시작해 IT 부서에서 열린다
기업 도입은 보통 직원 한 명이 X나 LinkedIn에서 Gumloop를 발견하면서 시작되지만, IT 부서가 움직이지 않으면 곧 멈춥니다. API 키, 데이터베이스 접근, SSO 연동이 없으면 실제 업무 도구를 연결할 수 없어 시범 사용 자체가 의미를 잃기 때문입니다. 흩어진 AI 구독을 감사 가능한 하나의 플랫폼으로 묶을 수 있다는 점을 IT 책임자가 알게 되면 오히려 이들이 사내 도입을 이끄는 경우가 많습니다. 한 고객사 영업팀은 시범 사용 일주일 동안 직전 석 달보다 세 배 많은 매출 파이프라인을 만들었다고 합니다. 한 회사의 사례이므로 일반적인 기대치로 볼 수는 없습니다.
Shopify처럼 경영진이 AI 도입에 적극적인 곳은 빠르게 길이 열리지만, 유럽의 한 대형 헬스테크 기업처럼 조직이 경직된 곳은 IT 부서의 반대로 배포가 늦어지기도 했습니다.
Gumloop가 기업 경영진에게 내세우는 논리는 업무를 가장 잘 아는 현업 담당자가 그 업무의 agent를 직접 만들어야 한다는 것입니다. 마케팅 운영팀이 몇 주 동안 요구 사항 문서를 쓰고 외부 컨설턴트에게 큰돈을 들여 맡겼는데 절반쯤 완성된 결과물을 받는 흐름을 줄이자는 주장입니다.
작은 팀으로 크게 일하는 방식
Gumloop 스스로도 이 방식으로 일합니다. 사내 데이터 조회 agent는 모든 내부 데이터 소스에 연결돼 있어, 직원이 Slack에서 질문하면 데이터 분석가 없이도 복잡한 조회 결과를 약 20분 만에 받습니다. 영업 준비 업무, 고객 사용량 변화 알림, 2주마다 여는 교육 과정의 신청·후속 연락·시연 영상 편집도 자동으로 돌아갑니다. 핵심 엔지니어 8명이 agent에게 장시간 작업과 테스트를 맡겨 한 명이 다섯 명 몫, 모두 합쳐 40명분의 일을 한다고 합니다.
처음에는 직원 10명으로 기업 가치 $10억을 넘기겠다는 목표를 내걸었고, 시리즈 A를 마칠 때도 공동 창업자 두 명과 인턴 두 명뿐이었습니다. 그러나 기업 영업에는 지원, 보안, 연동 업무가 많아 지금은 45~50명 규모입니다. 대신 고객이 직원이 250~300명쯤 될 것이라고 짐작할 만큼의 결과를 내는지를 효율의 기준으로 삼습니다. 현재 가장 큰 제약은 모델 성능이 아니라 인지도이고, 그다음은 쌓여 있는 기능 요청을 처리할 엔지니어링 여력이라고 합니다.
투자 유치에서는 실제로 작동하는 제품 시연이 발표 자료보다 100배는 설득력이 있다고 봅니다. 업무 자동화를 내세우는 스타트업이 너무 많아 투자자가 말만으로는 믿지 않기 때문입니다. 시드 투자 이후 Nexus와 Benchmark가 주도한 투자는 발표 자료 없이 먼저 제안이 들어왔다고 합니다.
정리: 기업용 agent 도구를 만들거나 도입할 때
Gumloop의 사례에서 얻을 수 있는 교훈은 다음과 같이 정리할 수 있습니다.
- 모델이 부족할 때는 정해진 순서의 워크플로로 신뢰를 쌓고, 모델이 좋아지면 agent로 넓힙니다.
- 기업 고객을 노린다면 RBAC, SSO, SCIM, 감사 로그, 프라이빗 배포 같은 통제 장치를 핵심 기능만큼 중요하게 준비합니다.
- agent는 Slack처럼 직원이 이미 쓰는 도구 안에 두고, 공개 채널에서 서로의 사용법을 볼 수 있게 합니다.
- 템플릿을 충분히 갖추고 “무엇을 자동화하고 싶은가”를 묻는 워크숍으로 첫 쓰임새를 끌어냅니다.
- 시범 도입은 IT 부서와 함께 시작해 권한과 데이터 접근을 먼저 해결하고, 부서별로 쓸 모델을 정해 비용을 관리합니다.
- 특정 모델 업체에 묶이지 않도록 모델을 바꿔 끼울 수 있는 구조와 데이터 소유권을 확보합니다.
기업에서 agent 도입을 검토하고 있다면, 어떤 모델을 쓸지보다 현업 담당자가 직접 만들 수 있는지, IT 부서가 통제할 수 있는지를 먼저 따져 보는 것이 좋겠습니다.