Taking on ServiceNow: Coding Agents for the Rest of Us with Serval Co-Founder and CEO Jake Stauch

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Serval은 비개발 부서도 코딩 에이전트로 업무를 자동화하도록 돕고, 승인·권한·감사 체계를 결합해 ServiceNow가 차지한 대기업 서비스 관리 시장에 도전한다.

📌 핵심 요점

1. 출발점은 기존 플랫폼의 구축 지연과 비용 부담이다. 제이크 스토치는 ServiceNow의 강력한 기능에도 구현이 원하는 상태보다 6~12개월 뒤처질 수 있다고 설명한다. Serval은 코드 생성으로 변화하는 자동화 수요에 더 빠르게 대응하려 한다. [02:13–02:34]
2. 코딩 에이전트의 사용자를 IT·인사·재무·법무로 넓힌다. 사용자가 직접 코드를 작성하거나 이해하지 않아도 자동화를 만들 수 있게 하되, 코드 확인과 개발·스테이징·운영 단계의 검토 절차를 제공한다. Catalyst는 자동화와 승인 규칙, 권한·정책 변경을 대화로 관리하는 인터페이스다. [03:57, 17:57, 26:18, 28:38]
3. 대기업에서는 생성 능력만큼 실행 권한을 통제하는 구조가 중요하다. 서비스 계정과 관리자 권한을 연결하되, 승인된 워크플로를 실행할 때 필요한 접근을 부여하고 티켓과 감사 기록을 남긴다. 스토치는 개인 권한이 엄격해질수록 이런 예외 승인 계층의 중요성이 커질 수 있다고 본다. [05:35–05:56, 14:00]
4. 자동화 도입과 확산에는 지속적인 현장 지원이 필요하다. 배포 담당자와 엔지니어가 고객의 프로세스·시스템을 이해하고 추가 자동화를 지원한다. 고객별 차이는 플랫폼 구성 요소와 코드 생성으로 수용하고, 반복되는 수요는 공통 기능으로 흡수하려 한다. [06:51–07:21, 20:00–20:45]
5. 사업의 가치는 토큰 소비보다 실제 업무 성과로 입증해야 한다. Serval은 수행한 작업을 기존 플랫폼 비용이나 인건비와 비교하고, 워크플로 실행량을 기준으로 과금하려 한다. 스토치는 개별 SaaS 도구가 통합되더라도 ERP·HR·ITSM·CRM 같은 핵심 범주는 형태와 공급자를 바꾸며 남을 가능성이 크다고 전망한다. [22:51, 24:34]

🧩 배경과 문제 정의

• Serval은 코드 생성 에이전트로 IT와 기업 내부 업무를 자동화하는 서비스 관리 플랫폼이다. 기존 강자인 ServiceNow의 높은 구축 난도, 느린 변경 속도, 지속적인 비용 상승이 출발 문제다.
• 소프트웨어 엔지니어가 없는 기업에서도 IT 부서는 시스템을 구축하고 운영한다. 코드 생성의 활용 범위를 IT·인사·재무·법무 등으로 넓히려면 비개발자도 자동화를 만들 수 있는 도구가 필요하다.
• 대기업에서는 개인의 접근 권한이 제한되고 승인·감사 절차가 복잡하다. 에이전트의 자율성과 기업의 보안·거버넌스 요구를 함께 충족하는 실행 구조가 핵심 과제다.
• AI가 코드 작성을 쉽게 해도 기업용 소프트웨어의 도입, 유지보수, 투자 대비 효과 입증은 별도 문제로 남는다.

🕒 시간순 섹션별 상세정리

1. ServiceNow의 구축 지연과 비용 부담이 대체 수요를 만든다

• Serval은 직장에서 질문하고 도움을 받는 과정과 반복 업무를 코드 생성 에이전트로 자동화한다. 스토치는 이전 직장에서 IT 고객들을 만나며 ServiceNow가 지출과 불만이 모두 큰 제품이라는 점에 주목했다. [01:18]
• ServiceNow는 강력하고 유연한 워크플로 플랫폼이지만, 아이디어마다 구현이 필요하고 외부 컨설턴트를 동원하는 경우도 많다. 원하는 상태보다 구현이 6~12개월 뒤처지는 문제가 생긴다. [02:13]

2. 코드 리뷰와 승인 체계를 비개발 부서까지 확장한다

• 엔지니어링 조직은 코드 리뷰를 통해 경험이 적은 인력이 만든 강력한 기능도 운영 환경에 반영하기 전에 검토할 수 있다. Serval은 이와 같은 안전장치를 기업의 다른 부서에도 제공하려 한다. [03:34]
• IT 부서를 통해 인사·재무·피플·법무팀까지 코드 생성 기능을 확장하되, 추상화와 통제 장치를 두고 스테이징·승인·감사 기록을 거치게 한다. [03:57]

3. 개인 권한의 한계를 승인된 일시적 접근으로 보완한다

• 개인용 에이전트는 소비자나 중소기업에서는 유용할 수 있지만, 대기업에서는 사용자의 제한된 권한과 복잡한 승인 절차 때문에 할 수 있는 일이 크게 줄어든다. [04:52]
• Serval은 IT 부서의 서비스 계정과 관리자 권한을 연결하고, 엄격한 승인 절차와 정해진 워크플로 안에서 필요한 높은 권한을 이용하게 한다. 티켓 시스템을 통해 그 과정의 감사 기록도 남긴다. [05:35]

4. 현장 도입과 지속적인 자동화 지원에는 사람이 필요하다

• 기술의 가능성과 실제 기업 활용 사이에는 사람·프로세스·기존 업무를 이해하는 간극이 있다. Serval은 배포 전략 담당자와 소프트웨어 엔지니어를 고객 현장에 보내 구현 방법을 함께 정한다. [06:51]
• 초기 배포 후에도 고객이 원하는 추가 자동화는 계속 생긴다. 자동화 엔지니어가 자동화할 업무를 찾고, 프로세스와 시스템을 파악하며, 운영 환경에 적용하는 일을 지속적으로 지원한다. [07:21]

5. 기존 제품의 보조 계층보다 대기업 핵심 시스템 교체를 택한다

• 창업 초기부터 ServiceNow를 직접 경쟁 상대로 정하고 더 큰 기업용 소프트웨어 회사를 만들겠다는 목표를 세웠다. 대기업 핵심 시스템 교체는 사업이 성장하면서 뒤늦게 추가한 야심이 아니었다. [08:20]
• 기존 제품 위에 얇은 기능 계층을 얹는 전략은 확장에 제약이 생길 수 있고, 중소·중견기업부터 공략하는 전략도 별도의 선택이다. Serval은 더 어렵더라도 성공했을 때의 기회가 큰 대기업 시장을 택했다. [08:51]

6. 코드 중심 자동화와 모델 성능 향상에 사업을 건다

• 드래그앤드롭 워크플로 도구는 비기술 사용자에게는 복잡하고 기술 사용자에게는 불편한 추상화라는 판단이다. 코드가 자동화를 표현하는 더 나은 방식이고 AI가 작성 장벽을 낮춘다면, 기존 플랫폼보다 나은 제품을 만들 수 있다는 가설이 성립한다. [09:59]
• 창업 당시 코드 생성은 실제로 충분히 작동하지 않았다. 다만 비밀번호 재설정과 승인 처리 같은 절차적 스크립트는 정의와 검증이 쉬워, 코딩 에이전트가 이 영역에서는 빠르게 개선될 것이라고 예상했다. [11:02]

7. 모델이 강력해질수록 권한 경계와 예외 승인이 중요해진다

• 더 나은 브라우저·컴퓨터 조작과 백그라운드·개인 에이전트는 제품의 활용 범위를 넓힐 수 있다. Serval의 핵심은 자체 언어모델 개발보다 대기업이 이러한 도구를 안전하게 쓰도록 경계와 통제 장치를 제공하는 데 있다. [12:36]
• 에이전트는 조금 넓게 부여된 권한으로도 더 큰 피해를 일으킬 수 있다. 스토치는 기업이 개인 권한을 실제 업무에 꼭 필요한 최소 수준으로 줄이는 방향으로 움직일 것이라고 전망한다. [13:26]

8. 도입 담당자의 경력 성과가 기존 시스템 교체를 뒷받침한다

• 대체 제품 도입은 담당자가 감수하는 위험만으로 설득하기 어렵다. Serval은 C레벨과 IT 리더십에 판매하고 다른 부서로 확산하면서, 전환을 이끄는 일이 담당자의 경력 성과가 되어야 한다는 입장이다. [14:52]
• Fox Corporation은 Serval을 전사적으로 도입했다. 현장에서 이전 작업을 이끈 담당자는 회사 전체 MVP 후보로 지명되고 관련 업무로 상을 받았으며, 이는 변화 주도자의 조직 내 가치를 보여주는 사례다. [15:23]

9. 개인 에이전트의 확산은 새로운 거버넌스 수요를 낳는다

• 스토치는 개인 에이전트가 이메일과 Slack처럼 업무 방식을 바꿀 수 있다고 기대한다. 각자의 에이전트가 일을 수행하고 다른 직원의 에이전트에 작업을 위임하는 모습을 예상한다. [16:19]
• 직원은 에이전트가 컴퓨터와 브라우저에서 폭넓게 행동하기를 원하지만, 기업은 커지는 사이버 보안 위험을 통제해야 한다. 이 두 요구 사이의 긴장이 새로운 기회를 만들 수 있다. [16:47]

10. 대기업용 에이전트에도 개발·검증·운영의 관문이 필요하다

• 개발 환경, 스테이징, 운영 환경을 구분하고 각 단계 사이에 검토 관문을 두는 소프트웨어 개발 생명주기가 핵심 설계 원칙이다. 분리된 브랜치에서 작업하면 다른 시스템에 영향을 주지 않고 개발할 수 있다. [17:57]
• 일부 IT 자동화는 이미 이런 절차를 따르지만, 많은 신생 AI 제품은 이를 충분히 수용하지 않는다는 지적이다. 대형 금융기관은 검토와 사용자 인수 테스트 없이 새 에이전트 기능을 운영 환경에 배포하기 어렵다. [18:17]

11. 고객별 자동화는 유연하게 만들고 반복 수요는 기본 기능으로 흡수한다

• 현장 엔지니어가 고객별 전용 제품 기능을 만드는 방식은 피한다. 고객 요청은 다른 고객에게도 필요할 기능인 경우가 많아, 공통 플랫폼의 개발 우선순위에 영향을 주는 형태로 다룬다. [20:00]
• 같은 비밀번호 재설정이나 입·퇴사 처리라도 회사별 워크플로는 크게 다르다. 이 차이는 플랫폼의 기본 구성 요소와 코드 생성으로 수용하며, Serval은 IT와 다른 부서가 자동화를 만들고 관리하는 개발 환경처럼 작동한다. [20:19]

12. 토큰 소비보다 실제 작업과 투자 대비 효과를 입증해야 한다

• 일부 CIO는 초기의 과도한 토큰 지출을 줄이려 하지만, 전체 도입은 아직 초기 단계다. 스토치는 기업들이 빠른 도입과 지출 조정을 차례로 겪더라도 총지출은 계속 크게 늘어날 것으로 예상한다. [21:53]
• 고객은 단기 조정 이후에도 지출 확대를 계획하지만 더 분명한 투자 대비 효과를 요구한다. 구매한 토큰이 어떤 가치를 만들었는지 측정하는 방법은 아직 충분히 정립되지 않았다는 판단이다. [22:18]

13. 핵심 업무 시스템은 남고 개별 SaaS 도구는 통합될 수 있다

• 내부에서 바이브 코딩으로 핵심 업무 기록 시스템을 만들려던 기업들은 구축과 유지보수 비용이 크다는 점을 발견했다. 요구가 매우 특수한 경우가 아니라면, 핵심 역량 밖의 기능은 기성 제품을 구매하는 경제성이 여전히 유효하다는 견해다. [23:43]
• 기업용 소프트웨어에는 다양한 사용 사례와 예외 처리, 지속적인 수정이 필요하다. 직접 구축하면 이를 유지할 인력을 확보하고 인건비도 부담해야 한다. [24:14]

14. IT 사용자의 기술 역량 차이를 고려해 코드 접근성을 조절한다

• 특히 대기업의 IT 부서는 시스템을 운영하고 코드를 작성하며 사실상 엔지니어링팀 역할을 맡는 경우가 있다. Serval은 이들을 전문 도구를 사용할 수 있는 사용자로 대우하면서 일부 복잡성을 줄인다. [25:55]
• 사용자가 반드시 코드를 작성하거나 생성된 코드를 이해해야 하는 것은 아니다. 다만 내부 코드를 언제든 확인하고 전체 소프트웨어 개발 생명주기에 따라 다룰 수 있는 접근성은 제공한다. [26:18]

15. 복잡한 자동화를 대화로 만드는 Catalyst

• 사용자는 복잡한 워크플로를 드래그 앤드 드롭으로 일일이 구성하고 싶어 하지 않는다. 다양한 사용자 유형을 고려하되, 사용자의 이해력을 낮게 가정해 기능을 지나치게 단순화하기보다 플랫폼의 복잡성과 강력한 기능을 활용할 수 있게 해야 한다. [27:25]
• 초기에는 고객이 제품의 구성 요소를 이해하도록 돕고 자동화를 대신 구축하는 인력이 필요했다. Catalyst는 고객 요구를 플랫폼 구성으로 변환하고, 관리자가 자동화·승인 규칙·권한 확인·정책·시스템 변경을 대화로 관리하도록 한다. 내부가 코드 생성 기반이므로 이를 이해하는 에이전트가 제품의 주된 인터페이스가 될 수 있다. [28:38]

16. 백그라운드 에이전트의 자율성과 기업의 신뢰 문제

• 백그라운드 에이전트가 스스로 문제를 발견하고 해결하면서 기업의 권한 체계까지 준수하는 것은 큰 잠재력이 있지만, 이를 제대로 구현하는 방법은 아직 충분히 해결되지 않았다. 자율성을 높일수록 읽을 수 있는 정보와 행동 범위를 명확히 통제해야 한다. [30:16]
• 에이전트는 주어진 목표를 달성하려다 예상하지 못한 행동을 할 수 있다. 유능한 직원처럼 상위 수준의 임무만 받고 결과를 가져오는 형태가 이상적이지만, 기업에서 이를 안전하게 맡길 수 있는 방식은 아직 확립되지 않았다는 판단이다. [30:45]

17. 승인된 도구를 늘리는 방식과 장기 기억의 필요성

• 현실적인 접근은 에이전트의 능력을 단계적으로 확대하는 것이다. 에이전트가 필요한 도구 호출이나 스크립트 실행을 요청하면, 사람이 정해진 권한과 안전장치 아래 실행 결과가 명확한 워크플로를 승인한다. 승인된 도구가 쌓이면 더 많은 문제를 해결할 수 있다. [31:30]
• 이 과정에는 사람이 계속 확인해야 하는 번거로움이 있다. 그러나 에이전트가 자유롭게 코드를 작성해 모든 시스템에 행동을 취하도록 허용하면 보안 위험의 범위가 제한되지 않으므로, 가까운 시일 내 기업이 감수하기 어렵다는 평가다. [31:45]

18. AI 생산성 향상이 채용 확대와 더 큰 시장 야심으로 연결

• 팀 규모는 1월 20명에서 대화 시점 200명으로 늘었다. 향후 채용 속도도 현재보다 빨라질 것이라는 전망이다. [33:42]
• 직원 한 명이 수행할 수 있는 일이 늘어도, 일에 대한 수요·경쟁·회사의 야심이 함께 커진다는 관점이다. 생산성 향상은 더 큰 목표를 추진할 여력을 주므로 오히려 더 많은 직원을 채용하려는 이유가 된다. [34:03]

19. 고객과 직접 연결된 엔지니어에게 제품 개발을 분산

• 현장에 배치되지 않은 엔지니어도 고객 Slack 채널에 참여하며 매일 고객의 목소리를 접한다. 대부분은 적어도 주 1회 고객 통화에 참여하고, 실제로는 하루 1회 이상 참여하는 경우가 많다는 설명이다. [35:23]
• 고객과의 지속적인 접촉은 고객의 사고방식과 선호 변화, 새로 시험하는 제품을 빠르게 이해하게 한다. Serval은 별도 제품 조직 없이 엔지니어링팀에 제품 개발을 분산해, 한 달 전 요구보다 오늘과 이번 주의 요구에 신속하게 대응한다. [36:04]

20. 현장 의사결정과 기존 선택을 되돌리는 능력

• 제품 변화 속도가 경영진 자신도 따라가기 어려울 만큼 빠르므로, 고객을 이해하고 제품 관점에서 판단하는 엔지니어가 필요하다. 모든 제품 결정을 경영진에게 올릴 수 없기 때문에 현장에 상당한 의사결정 권한을 맡겨야 한다. [37:01]
• 빠르게 움직이려면 잘못된 방향의 변경을 되돌리고, 제품의 근본이라고 여겼던 선택도 수정할 수 있어야 한다. 고객의 관점이 달라졌다는 근거가 들어오면 기존 구상을 포기하고 방향을 바꾸는 유연성이 필요하다. [37:20]

🧾 결론

• Serval의 전략은 코드 생성의 접근성을 높이면서 대기업의 승인·감사·운영 요건까지 제품에 포함하는 것이다. ServiceNow 교체라는 목표는 창업 초기부터 정한 방향이다.
• 모델 성능이 좋아져도 업무 설계, 권한 통제, 검증, 유지보수는 계속 필요하다. 인터뷰는 이 실행 구조를 기업용 에이전트의 핵심 가치로 제시한다.
• 비개발자에게 자동화 도구를 제공하려면 대화형 인터페이스와 함께 필요할 때 코드를 확인하고 검토할 수 있는 접근성도 갖춰야 한다.
• 높은 자율성을 가진 백그라운드 에이전트의 안전한 운영 방식은 아직 해결 과제다. 당장은 사람이 승인한 도구와 워크플로를 단계적으로 확대하는 접근이 제시된다.

📈 투자·시사 포인트

• 경쟁력의 평가 범위가 넓어진다. 기업용 에이전트 업체를 볼 때 코드 생성 능력과 함께 권한 관리, 감사 기록, 검토 환경, 기존 시스템 연동 능력을 확인필요가 있다.
• 현장 지원 비용도 사업성에 포함해야 한다. 고객별 프로세스를 이해하는 인력이 지속적으로 필요하므로, 자동화 확대가 지원 부담과 어떤 관계를 갖는지 확인해야 한다. 인터뷰에는 이를 판단할 수익성 수치가 없다.
• 과금 단위와 고객 성과의 연결이 중요하다. 워크플로 실행량 과금이 실제 비용 절감과 연결되는지, 실패·재작업까지 포함해 고객이 가치를 인정하는지가 관건이다.
• SaaS 통합 전망은 범주별로 구분해야 한다. 스토치의 관점에서는 개별 도구가 핵심 플랫폼에 흡수될 수 있지만 핵심 업무 시스템에 대한 수요는 지속된다. 이를 모든 SaaS의 소멸 전망으로 확대하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• ServiceNow의 구축 지연과 비용 부담, Serval의 자동화 성능에 관한 설명은 창업자의 경험과 주장에 기반한다. 대표성 있는 고객 비교나 독립적인 성능 검증 결과는 제공되지 않았다.
• API가 있는 워크플로에서 자동화 실패 요청을 찾기 어려워졌다는 설명만으로 운영 안정성이나 보안성을 판단할 수 없다. 실패율, 예외 처리, 승인 오류와 복구 성능은 확인이 필요하다.
• Fox Corporation의 전사 도입 사례는 제시되지만 도입 기간, 비용 절감액, 갱신 조건은 없다. 워크플로 실행량 과금도 지향하는 방식으로 설명되므로 실제 적용 범위를 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 비밀번호 재설정·접근 승인·입퇴사 처리 중 반복 업무를 선정하고 현재 처리 시간, 인력 투입, 오류·재작업을 기록한다.
• 시범 자동화별로 필요한 최소 권한, 승인 담당자, 접근 허용 시점, 감사 기록과 실패 시 복구 절차를 정의한다.
• 개발·스테이징·운영 환경을 분리하고 코드 검토와 사용자 인수 테스트를 거쳐 운영에 반영한다.
• 기존 플랫폼 비용과 현장 지원·유지보수 비용을 포함해 자동화 전후의 총비용과 실제 완료 업무를 비교한다.

❓ 열린 질문

• 승인과 검토를 유지하면서도 비개발 사용자가 체감하는 자동화 속도를 얼마나 높일 수 있을까?
• 고객별 업무 차이를 수용하는 현장 지원과 공통 플랫폼 개발은 규모가 커져도 효율적으로 병행될 수 있을까?
• 워크플로의 복잡도와 성공 여부가 다른 상황에서 실행량 과금은 고객이 얻는 가치와 얼마나 일치할까?