Serval 창업자 제이크 스타우크 — AI 네이티브 ServiceNow가 다시 짓는 IT

개요

• Serval 창업자·CEO Jake Stauch 인터뷰. 회사는 AI 네이티브 ServiceNow를 표방하는 엔터프라이즈 서비스 매니지먼트 플랫폼
• 창업 2년차, 고객 100개사 (수백 명 규모 AI 네이티브 스타트업부터 수십만 명 대기업까지)
• 핵심 주제: 워크플로우+데이터베이스 프리미티브를 AI 코드젠으로 재구축, 슬롭 자동화 방지, 두 에이전트 아키텍처, 모델 선택·교체 운영, 토큰 재판매가 아닌 유닛 이코노믹스, 랩 직접 경쟁론, AI 우선 조직 설계
• Stauch는 Verkada 등 이전 회사 경험 보유, 극단적 고객 밀착형 창업자로 평가

핵심 내용

AI 네이티브 ServiceNow가 필요한 이유

• 본질은 직장에서 도움 받기: 요청하면 즉시·자동으로 해결되는 게 이상적, 티켓 배정 대기 없어야 함 -> 자동화 필수, 그 자동화의 최적 도구가 AI
• ServiceNow 창업자 추상화, 옳았단 평가: ServiceNow 창업자 Fred Luddy가 2007-2008년에 잡은 추상화(데이터베이스 위 워크플로우)는 옳았음. Remedy 등 기존 도구 대비 스텝 체인지였고 Serval도 같은 프리미티브 사용
• 자동화 구축 수개월, 항상 뒤처짐: 문제는 그 워크플로우·DB의 구축·유지에 전담 개발 리소스가 필요하고 수 주-수 개월 소요된다는 것. 비즈니스 프로세스가 빠르게 변하는 시대엔 완성 시점에 이미 요구가 달라져 자동화가 항상 뒤처짐
• IT 자산 DB 수동 갱신에 컨설턴트 개발자 동원 필요: IT 자산 DB도 수동 갱신 필요 -> 컨설턴트·내부 개발자 동원해야 하는 고통
• Serval 접근: 프리미티브는 유지하되 AI가 워크플로우를 만들고 AI가 DB를 갱신
  • 코드젠 엔진: 단계·권한·승인·로직을 자연어로 기술하면 코드로 변환, 워크플로우가 사실상 개발 시간 0으로 즉시 생성
  • DB도 어떤 소스에서 어떤 데이터를 가져올지 기술하면 수집·최신화 코드를 시스템이 생성, 수동 개입 불필요
• 핵심 명제: 자동화를 만드는 일이 수동 처리만큼, 가능하면 그보다 쉬워야 자동화가 선택됨
  • 비밀번호 리셋 예시: Google Workspace에서 버튼 클릭 vs 워크플로우 빌더에서 트리거·응답 드래그 -> 사람은 당연히 수동 처리 선택
  • 자동화 구축이 실제로 더 쉬우면 안 할 이유가 없음. 순간의 선택이 자동화 쪽으로 기울게 설계해야 함
• 슬롭 자동화 문제는 실재: 자동화가 너무 쉬우면 이번 주 20번째 비밀번호 리셋 워크플로우가 생기고, 19번째와 사실상 동일한 중복 더미 속에서 AI가 어느 것을 실행할지 혼동
• 대응: Serval 위에 기존 워크플로우 전체의 작동 방식을 맥락으로 아는 에이전트 구축
  • 새 워크플로우 요청 시 이미 같은 기능 19개 존재를 알려주고, 10개 삭제·나머지 9개 카테고리 재편·승인 단계 추가까지 제안
  • 비즈니스 요구를 제품 구현으로 번역해주는 제품 전문가 어시스턴트 역할

고객 밀착과 앱 레이어의 해자

• 지표 없이 일화 종합, 직관형 방법론: North Star 지표 없음. 일화를 수집·종합하는 직관형 — 완전 몰입이 방법론
• 창업자 본인이 전 고객 Slack에 직접 상주: 모든 고객 Slack 채널에 본인이 직접 상주, 대부분 고객이 매일 본인에게서 Slack 메시지 받음. 고객 100개사 규모에서도 유지
• Slack 상주는 고객 맥락 파악의 대체 불가 수단: 시간 낭비 아닌가 자문할 때도 있지만 무엇이 잘되고 안되는지 맥을 짚는 데 대체재 없음
• 구현속도 시대 해자는 제품에서 고객 인사이트로 이동: 구현 속도가 극도로 빨라진 시대에 스타트업 해자는 점점 고객 인사이트와 공감으로 이동. 제품 우위는 하룻밤에 복제 가능하므로 고객 인사이트의 차별적 우위가 훨씬 가치 있음
• 파운데이션 모델과의 관계 원칙: 새 모델이 나올 때 기뻐야 함. 랩·하이퍼스케일러 발표에 무력화되지 않고 오히려 좋아지는 것만 구축
• 제품 = 경계라는 관점: 모델 능력은 사실상 무한, 진짜 질문은 보안을 중시하는 대기업이 리스크 증가 없이 전사 배포에 안심할 수 있는가
  • 권한·승인·API 통합 범위 제한·가시성·감사·리포팅·로그·알림 같은 지루한 구식 엔터프라이즈 소프트웨어 요소가 곧 제품
• 아키텍처를 두 에이전트로 분리 설계: 아키텍처를 두 에이전트로 분리
  • admin agent: 관리자가 도구·스킬을 구축·발행, 승인·권한 설정 담당
  • help desk agent: 최종 사용자를 상대하며 추론 능력을 최대한 발휘하되, admin이 명시적으로 발행·승인한 도구만 사용 가능
  • 이 이중 구조 덕에 help desk agent를 마음껏 풀어놓아도 통제가 유지됨. 특정 사용자를 막는 권한·승인 게이트는 전부 admin 측에서 처리

모델 운용과 유닛 이코노믹스

• OpenAI·Anthropic 병용, 최신모델 상시실험: 현재 OpenAI와 Anthropic 모델 병용, 전 작업에 이벌 스위트 상시 가동하며 최신 모델 계속 실험
• 모델별 용도 분업 체계가 오래 안정적으로 유지: 용도별 분업이 오래 일관되게 유지됨
  • 최종 사용자 인터랙션(정확한 툴 콜링·적절한 응답): OpenAI GPT 계열이 최고 성과
  • 자동화 쪽 코드젠: Anthropic Sonnet·Opus가 최고 성과
• 신모델은 플러그앤플레이가 아님: 일부는 좋아지고 일부는 나빠짐. 나빠지는 것 상당수는 모델 탓이 아니라 구모델의 quirk에 맞춰둔 프롬프트 튜닝·인프라가 신모델에서 무의미해지는 문제
• 프로세스: 이벌은 자동화돼 있으나 조정은 수동 -> 이벌 통과 후 고객별 슬로우 롤아웃
• 업그레이드 후 다운그레이드한 사례 존재: 신모델이 더 똑똑해도 예측 불가능하게 어긋나고 가드레일이 안 먹으면, 조금 덜 똑똑해도 빠르고 예측 가능한 구모델 유지
• 비용은 후순위 전략: 먼저 마법 같은 제품, 최적화는 나중. 팀에는 돈 더 쓰고 최고 모델 쓰라고 지시
• 토큰 재판매 아니므로 특정 모델 후순위 배치 가능: 후순위가 가능한 이유 = 토큰 재판매업이 아니기 때문
  • 자동화는 한 번 생성되는 TypeScript 코드. 비밀번호 리셋 요청마다 코드를 재생성하지 않고 이미 생성된 코드를 실행만 함
  • 자동화 라이브러리가 롱테일을 커버하며 축적될수록 신규 코드젠(가장 비싼 토큰 소비) 필요가 계속 감소 -> 최적화 없이도 유닛 이코노믹스가 강함
• 예외 영역: 백그라운드·장기 실행 에이전트 (과거 티켓 전수 조사, 기기 로그 조사, 몰랐던 문제의 해결책 선제 생성). 방치하면 비용이 급증할 수 있어 이 영역은 비용을 조기에 고려할 계획

랩 직접 경쟁론과 고객 구성

• 랩 직접경쟁 우려에도 스타트업 역전 역사 반복: 무한 자본·최고 인재·AGI 상대로 어떤 답도 순진하게 들리지만, 스타트업 역사는 작은 회사가 이기는 경우를 반복 증명. OpenAI·Anthropic 자체가 기존 강자를 이긴 증거
• 관건은 집중: 첫 창업 때 VC마다 Google이 하면 어쩌냐고 물었지만, 여러 분야를 동시에 아주 잘하기는 정말 어려움
• ITSM은 랩의 집중 대상으로 비합리: 최근 두어 달 Anthropic이 추가한 ARR이 ServiceNow의 지난 20년치보다 큼 -> 최정예를 수년 걸리는 이 문제에 투입할 유인 없음
• SMB 단순화만, 엔터프라이즈 복잡성은 회피: 단, SMB·미드마켓용 단순 버전 출시는 놀랍지 않을 것. 엔터프라이즈 서비스 매니지먼트의 복잡성을 마스터하는 수준의 투입은 자원 배분상 안 할 것으로 판단
• 고객 스펙트럼: AI 네이티브 로고 + 대형 엔터프라이즈. 최대 배움은 둘이 예상보다 훨씬 비슷하다는 것 — 페인포인트가 놀랍도록 유사
• 랩과의 진짜 차이는 의사결정 필요 인원 수: 진짜 차이는 의사결정에 필요한 인원 수
  • 수백 명 회사: IT 리더 1명이 온보딩·비밀번호 정책을 결정
  • 수십만 명 회사: 그 결정권자가 누군지, 존재하는지도 아무도 모름 -> 위원회의 연속, 도입의 rate-limiting step은 사람 조율
  • 랩들이 컨설팅·서비스·배포 조직을 키우는 이유도 이것
• AI 네이티브 고객이 좋아하는 점: 기술이 좋아 IT에 온 사람에게 다시 기술을 만지게 해줌
  • 상징적 사례: 낡은 ServiceNow 티켓 시스템으로 남의 Cursor 접근 권한을 발급해주며 하루를 보내던 담당자 — 남은 쿨한 AI 도구를 쓰는데 내 도구는 과거에 갇힌 대비
• 대기업 고객이 좋아하는 점: 직원 경험 자체의 변화
  • 대조직에선 티켓이 심연으로 사라져 진행 상황을 모른 채 몇 주씩 블로킹, 중복 티켓으로 혼선 가중 -> Serval이 직원으로 산다는 감각을 바꿈
• 사내 활용: 간식·사무실 요청까지 전부 Serval 강제
  • Dream Team Draft 채널: 직원이 함께 일해본 최고의 인재 LinkedIn을 올리면 Serval이 자동화 체인 실행 — 아웃바운드·너처 캠페인 편입, 어디서든 Serval이 보이게 만드는 노출 작업까지. 당장 이직 안 할 사람을 장기 게임으로 워밍

AI 네이티브 조직 운영과 CEO의 일

• 모든 부서·역할에 대해 AI가 우선 검토권을 가짐: 이 부서가 사람 없이 되는지부터 가정하고 시작, 필요성이 재확인되는 부서도 있음
• 완전히 AI로 간 사례: 솔루션스 엔지니어 0명, SDR도 0명
  • AE가 Serval로 제품 질문 즉답, 통화 중 실시간으로 덱·원페이저·배틀카드·비교표 생성 -> AE에게 더 많은 걸 기대
  • 파일럿 구현을 돕는 deployed engineer는 4명 유지
• 채용 지연으로 발견한 것: enablement는 프로덕트 마케팅 1명이 자동화 리소스로 크게 확장, RevOps도 상당 기간 무인 -> 결국 사람이 필요하지만 부서가 생각보다 작아도 됨
• 조직 문화: 친절하고 재미있고 에너지 높은 팀이 최대 채용 자산. 반면 교육·멘토십·온보딩 프로그램·명확한 커리어 패스는 없음
  • 첫날부터 생산적이어야 하고 모호함을 즐기는 사람용. 조직도가 사실상 없고 본인도 누가 직속인지 모름
• CEO 역할 변화: 초기엔 CTO가 제품을 만들고 본인은 쓸모없다고 느끼며 채용·고객 미팅에 분투 -> 이제는 본인이 바위를 미는 게 아니라 비즈니스가 본인을 끌고 감
• 여전히 깊이 관여: 영업·장기 고객 성공·리크루팅. 덜 관여하게 된 것: 제품 방향
  • 제품 방향이 forward deployed engineer를 통해 고객에게서 창발해 바로 구현되는 폐루프 — 본인 표현으로 제품 개선의 gradient descent. 일주일 만에 제품이 확 좋아짐
  • 대신 미래를 생각하는 시간이 부족해진 게 과제
• 소프트웨어 수명관: 20년 갈 소프트웨어가 아니라 6개월 가는 소프트웨어를 만들고 패러다임이 바뀌면 재구축. 몇 달 전 확신하던 것도 뒤집고 제품 일부 리네이밍·방식 전면 전환을 반복할 유연성 필수
• 포지셔닝: 빠르게 변하는 모델 능력과 느리게 변하는 고객 사이의 버퍼·번역 레이어
  • 고객의 비즈니스 문제에서 출발해 Serval 구현으로 매핑, 3개월 전과 달라진 방법을 교육. 최신 기술은 Serval이 알아서 처리하고 고객은 문제 정의에만 집중하게 하는 에이전트도 개발 중
• 컨트래리언 뷰: 자율성과 통제의 격차 확대
  • 개인은 자기 Claude 에이전트가 모든 것에 접근해 다 해주길 원하고, 조직(보안·IT)은 직원 에이전트의 그런 자율성을 원치 않음 — 정당한 우려
  • 컨슈머 제품은 전부 해주는 세계로, 엔터프라이즈 제품은 통제 레이어로 설계되는 긴장. 인터뷰어는 iPhone 대 Blackberry 시절 섀도 IT에 비유
  • 디폴트가 yes인 회사가 no인 회사를 크게 앞서갈 것. 다만 앞서는 회사들이 보안 사고의 대가도 먼저 치르며 학습을 이끌 것
• 현재 최대 이슈: 여전히 채용. AI가 일을 자동화한다는데 모든 AI 회사가 그 어느 때보다 채용 중
  • 남은 유일한 해자는 조직 안의 사람. 만트라는 fewer better — 부서마다 더 적게, 더 뛰어나게
  • 변화 속도가 빠를수록 민첩성이 핵심이고, 민첩성의 최적해는 최고의 인재로 이룬 최소 인원. 수천 명에게 방향 전환을 설득하는 조직은 불가능
• 남기고 싶은 유산: IT 일자리를 없앤 회사가 아니라, 반복적·소모적 업무를 걷어내 사람들이 원래 하려던 일로 돌아가게 한 회사

투자자 관점 시사점

• 앱 레이어 해자의 재정의: 제품 기능은 하룻밤에 복제 가능하다는 창업자 자신의 인정 — 실질 차별화는 고객 밀착(창업자가 100개사 Slack 상주)과 경계·통제 레이어(권한·승인·감사). AI 앱 기업 평가 시 기능 데모보다 통제 인프라와 고객 락인 구조를 봐야 함. ServiceNow 등 기존 ITSM에는 AI 네이티브 대체 리스크가 실재
• 유닛 이코노믹스 구분 프레임: 토큰 재판매형(요청마다 인퍼런스 소비) vs 코드 생성 후 재사용형(코드젠 1회, 이후 실행만). 후자는 스케일할수록 원가율 하락 — AI 앱 마진 실사 때 핵심 체크 포인트. 단 백그라운드·장기 실행 에이전트로 확장하면 비용 구조가 다시 악화될 수 있음
• 랩의 버티컬 침공 리스크 평가: Anthropic 두어 달 ARR 증가가 ServiceNow 20년치를 넘는 상황에서 랩이 복잡한 엔터프라이즈 버티컬에 최정예를 투입할 기회비용이 큼 -> 딥 버티컬 앱은 상대적 안전지대, 반면 SMB용 단순 기능은 랩·범용 에이전트에 잠식 가능
• 조직 구조가 주는 신호: SE·SDR 0명, fewer better, 인당 자동화 레버리지 극대화 — AI 네이티브 세대는 인력 수 기반 성장 프록시(헤드카운트 증가율)가 무효. 상장 SaaS의 영업·지원 인력 구조와 비교하면 마진 구조 격차가 벌어질 것

기억할 발언

• (17:02) "지난 두어 달 동안 Anthropic이 추가한 ARR이 ServiceNow가 지난 20년간 쌓은 것보다 많다. 랩이 최고 인재를 이 문제에 던질 이유가 없다"
• (36:44) "모든 직업엔 상상했던 모습과 실제 모습 사이의 격차가 있다. 우리는 당신이 생각했던 일과 실제 하는 일 사이의 그 격차를 좁혀주는 도구가 되고 싶다"