핵심 요약

  • Serval은 코딩 에이전트로 IT팀이 업무 자동화를 구축하도록 돕는다. 기존 시스템 위에 AI 기능을 얹기보다 서비스나우 같은 기업의 핵심 업무 시스템을 대체하는 것이 목표다.
  • 제품의 중심은 모델 자체가 아니라 권한 통제와 승인 절차다. 에이전트의 능력이 커질수록 기업이 그 행동을 제한하고 기록할 장치도 더 중요해진다고 본다.
  • 고객마다 다른 업무는 코드로 구현하고 여러 고객이 반복해서 만드는 자동화는 플랫폼의 기본 기능으로 흡수한다.
  • AI 비용의 가치는 토큰 소비량보다 실제로 수행한 업무로 설명해야 한다. Serval은 실행한 워크플로를 기준으로 요금을 매기려 한다.
  • 스타우치는 AI가 단일 목적의 소프트웨어를 줄일 수 있지만 기업의 핵심 기록 시스템까지 없애지는 않을 것으로 전망했다.

서비스나우를 대체하려는 출발점

AI 팟캐스트 No Priors에서 진행자 사라 궈와 일라드 길은 Serval 공동창업자 겸 CEO 제이크 스타우치(Jake Stauch)와 기업용 업무 자동화를 논의했다. 대화의 쟁점은 코딩 에이전트의 능력을 대기업이 실제로 맡길 수 있는 업무에 어떻게 활용하느냐였다.

스타우치는 이전 직장에서 IT팀에 기업용 물리 보안 제품을 판매하며 이 시장을 발견했다. 고객에게 가장 많은 돈을 쓰는 제품과 가장 싫어하는 제품을 물으면 서비스나우가 자주 등장했다고 한다. 강력하고 유연한 플랫폼이지만 새로운 자동화를 만들려면 구현 작업이 필요하고 외부 컨설턴트까지 동원해야 했다. 고객이 원하는 상태보다 6~12개월씩 뒤처지는 데다 비용도 계속 늘어난다는 불만이었다.

5~10년 유지할 대규모 입사 절차라면 초기 구축에 공을 들일 수 있다. 반면 계속 바뀌는 업무를 따라가며 자동화를 추가하려면 같은 방식이 부담이 된다. Serval은 이 간극을 코드 생성으로 줄이려 한다.

창업 초기부터 목표는 대기업이었다. 기존 제품 위에 작은 기능을 얹거나 중소기업부터 공략하는 대신 서비스나우와 직접 경쟁하기로 했다. 스타우치는 처음부터 대기업을 고객으로 정하면 제품 설계와 채용, 성장 방식까지 달라진다고 말했다.

코드 생성보다 중요한 개발과 운영 절차

Serval은 업무 자동화를 표현하는 데 코드가 적합하다고 본다. 스타우치는 화면에서 요소를 끌어다 놓는 방식이 비개발자에게는 여전히 복잡하고 개발자에게는 불필요한 추상화가 될 수 있다고 봤다. 코드를 빠르게 작성하기 어렵다는 장벽을 AI가 낮추면 다른 자동화 플랫폼을 만들 수 있다는 계산이었다.

창업 당시에는 모델의 실력이 부족했다. 초기 시연에서는 비밀번호 재설정 절차 같은 예시를 프롬프트에 많이 넣어야 했다. 이후 모델이 개선되면서 시스템끼리 기능을 호출하는 API만 있다면 자동화하지 못하는 업무 흐름을 찾기 어려워졌다고 스타우치는 말했다. 처음부터 기대한 것은 범용 소프트웨어 개발 전체보다 비밀번호 재설정이나 승인 요청처럼 절차가 명확하고 결과를 확인하기 쉬운 코드였다.

그렇다고 코딩 도구를 IT팀에 건네는 것만으로 끝나지는 않는다. Serval은 개발 환경, 운영 전 검증 환경, 실제 운영 환경을 구분하고 그 사이에 검토와 승인을 둔다. 소프트웨어를 만들고 검증해 배포하는 개발 생명주기를 다른 부서에도 적용하려는 것이다. 대형 금융기관이 새 에이전트를 도입하려면 검토와 사용자 인수 테스트를 거쳐야 한다는 점을 제품 설계에 반영했다.

사용자도 하나로 가정하지 않는다. 직접 코드를 쓰는 IT 엔지니어는 내부 코드를 확인하고 개발 절차에 따라 관리할 수 있다. 코드를 보고 싶지 않은 인사·마케팅 담당자는 복잡한 업무 흐름을 설명하고 같은 코드 생성 기능을 이용할 수 있다.

에이전트가 강해질수록 권한은 더 좁아진다

개인용 에이전트를 회사에 가져와도 직원 본인의 접근 권한이 좁으면 할 수 있는 일이 적다. 반대로 관리자 수준의 권한을 자유롭게 주면 위험이 커진다. Serval은 IT팀과 연결해 필요한 권한을 쓰도록 하되 정해진 승인 절차와 기록을 거치게 한다.

예를 들어 에이전트가 특정 작업을 요청하면 접근 요청을 만들고 승인을 받은 뒤 해당 업무를 한 번 실행하는 데 필요한 권한을 일시적으로 부여한다. 요청과 승인, 실행 내역은 티켓과 감사 기록으로 남긴다. 여기서 티켓은 업무 요청과 처리 과정을 추적하는 기록이다.

스타우치는 에이전트가 강해질수록 기업이 직원의 상시 권한을 오히려 줄일 것으로 예상했다. 사람이 조금 더 많은 권한을 갖는 경우와 그 권한으로 여러 에이전트를 움직이는 경우의 피해 가능성이 다르기 때문이다. 업무에 꼭 필요한 권한만 주는 최소 권한 원칙을 강화하면 예외 요청도 늘어난다. Serval은 그 예외를 승인하고 추적하는 역할을 맡으려 한다.

스스로 문제를 찾아 해결하는 백그라운드 에이전트에도 같은 논리를 적용한다. 스타우치는 이런 에이전트를 안전하게 운영하는 방법을 아직 누구도 잘 풀지 못했다고 봤다. 그가 제시한 방식은 능력을 단계적으로 늘리는 것이다. 에이전트가 필요한 도구나 실행할 스크립트를 요청하면 사람이 범위와 조건을 정해 승인한다. 승인된 도구가 쌓일수록 더 많은 문제를 해결할 수 있다.

이 방식은 번거롭다. 그러나 스타우치는 에이전트가 임의로 코드를 작성해 모든 시스템에 행동하도록 두면 감당하기 어려운 보안 위험이 생긴다고 말했다. 기억과 사용자 선호 이해도 개선돼야 하지만 모델이 똑똑해져도 권한 문제는 남는다고 봤다.

고객별 자동화에서 공통 제품 기능을 찾는다

기업 도입에는 사람의 역할도 크다. Serval은 배포 전략 담당자와 소프트웨어 엔지니어를 고객 현장에 보내 기존 절차와 원하는 업무 방식을 파악한다. 도입 후에도 자동화할 일이 계속 생겨 지속적인 지원을 맡는 자동화 엔지니어 팀을 만들고 있다고 밝혔다.

고객별 요구에 맞춰 별도 제품 기능을 만드는 방식은 피한다. 스타우치에 따르면 고객이 요구하는 플랫폼 기능은 다른 고객도 언젠가 필요로 할 만한 경우가 많다. 고객 요구는 개발 우선순위를 바꾸지만 기능 자체는 공통 플랫폼에 들어간다.

플랫폼 안에서 구현하는 업무 흐름은 회사마다 다르다. 비밀번호 재설정이나 입·퇴사 절차조차 고객마다 상당히 다르다고 한다. 이 차이는 코드 기반 자동화로 수용한다.

반복되는 자동화는 기본 기능의 후보가 된다. 여러 고객이 서로 충돌하거나 오래된 지식 문서를 찾는 절차를 만들자 이를 제품에 넣었다. 쓰지 않는 유료 소프트웨어 라이선스를 회수하는 자동화도 같은 과정을 거쳤다.

관리자를 돕는 에이전트 Catalyst는 제품 사용법을 익히는 부담을 줄이기 위해 만들었다. 요구사항을 대화로 받아 자동화를 구축하고 승인 규칙과 권한 확인, 정책 설정 등을 관리한다. 처음에는 현장 엔지니어가 고객에게 제품의 구성 요소를 설명하거나 대신 만들었지만 이제는 제품을 이해하는 에이전트가 그 접점을 맡도록 했다.

토큰 소비량보다 수행한 업무를 판다

스타우치는 고객인 최고정보책임자들이 초기의 공격적인 AI 사용에서 한발 물러나 비용 대비 성과를 따지기 시작했다고 전했다. 고객들이 장기적으로 지출을 줄이려는 것은 아니며 추가 투자를 정당화할 근거를 원한다고 말했다.

토큰, 즉 모델이 처리하는 텍스트 단위의 소비량만으로는 업무 가치를 알기 어렵다. 답변이 길거나 처리 과정이 비효율적이어도 토큰 사용량은 늘어난다. Serval이 실행한 워크플로를 기준으로 요금을 매기려는 이유다. 기존 플랫폼이나 사람의 노동으로 처리했을 일과 비교해 어떤 업무를 수행했는지 보여주려 한다.

스타우치는 기업이 AI로 소프트웨어를 직접 만들면 기존 구독형 소프트웨어가 사라진다는 전망도 같은 관점에서 봤다. 핵심 기록 시스템을 내부에서 만들려던 기업들이 구축과 유지 비용이 크다는 사실을 발견했다고 말했다. 예외 상황에 대응하고 고장 난 기능을 고치고 담당 인력을 유지해야 하기 때문이다. 요구가 매우 특수한 경우가 아니라면 핵심 역량 밖의 소프트웨어를 구매하는 선택은 여전히 유효하다고 봤다.

대신 단일 목적의 작은 제품은 줄어들 수 있다고 전망했다. 기업이 쓰는 수많은 개별 도구의 기능을 핵심 플랫폼이 흡수한다고 봤다. 전사 자원관리, 인사, IT 서비스 관리, 고객관계관리 같은 범주는 남되 이를 공급하는 주도 기업은 바뀔 수 있다고 구분했다.

빠른 제품 변화는 고객과 붙어 있는 엔지니어에게 맡긴다

스타우치는 인터뷰 당시 회사가 설립 약 2년 반 만에 200명 규모가 됐으며 그해 1월에는 20명이었다고 밝혔다. AI로 직원 한 명의 생산성이 높아졌지만 그만큼 더 큰 목표를 추구하므로 채용을 늘리려 한다고 말했다.

제품 개발에서는 별도의 제품 담당 조직을 두지 않고 엔지니어에게 결정을 분산한다. 엔지니어들은 고객의 슬랙 채널에 참여하고 대부분 적어도 주 1회 고객과 통화한다. 스타우치는 상당수가 매일 고객 통화에 참여한다고 덧붙였다. 고객이 시험하는 새 도구와 달라지는 요구를 개발자가 직접 접하게 하려는 방식이다.

그 대가로 경영진이 모든 제품 결정을 검토할 수는 없다. 고객을 이해하고 제품 판단을 내릴 수 있는 엔지니어를 채용해야 하며 잘못된 방향이면 빠르게 되돌릴 준비도 필요하다. 스타우치는 과거에 중요하게 여겼던 기능과 설계를 지우고 고객의 변화에 맞춰 다시 만드는 태도 덕분에 속도를 유지했다고 말했다.

Serval은 코딩 에이전트를 기업이 받아들일 수 있는 업무 절차로 묶으려 한다. 코드 생성이 자동화를 만드는 비용을 낮춘다면 승인·권한·검증·운영은 그 자동화를 실제 조직에서 쓰게 하는 조건이다. 스타우치가 서비스나우에 도전하며 제품의 중심에 둔 것도 이 조건들이다.