스트라이프는 2026년 4월 사내 업무용 AI 에이전트 플랫폼 Kai를 출시했다. 코딩 에이전트가 개발자의 일하는 방식을 바꾼 것과 달리, 영업·재무·법무처럼 코드를 쓰지 않는 직군은 그 변화에서 소외돼 있었다. 출시 두 주 만에 스트라이프 대부분의 직원이 Kai를 썼고, 현재는 전체 직원의 83%가 매주 사용한다. 특히 영업·마케팅·고객성공·기술 담당자로 구성된 GTM(Go-To-Market) 조직은 거의 전원이 주간 사용자다.
스트라이프가 강조하는 지점은 도구 자체가 아니라 순서다. 검색이나 챗봇 인터페이스를 먼저 고르지 않고, 실제 업무 흐름과 접근 통제 구조부터 설계한 뒤에 그 위에 에이전트를 얹었다. 이 구조를 뜯어보면 사내 AI 도입에서 무엇을 먼저 결정해야 하는지가 드러난다.
Kai 이전에는 왜 검색 도구만으로 부족했나
Kai를 만들기 전 스트라이프에는 두 가지 대안이 있었다. 하나는 누구나 도구를 연결해 특정 업무용 에이전트를 만들 수 있는 사내 빌더로, 이 방식으로 4,000개가 넘는 소형 에이전트가 만들어졌다. 문제는 팀마다 비슷한 목적의 프롬프트를 각자 다른 품질로 작성했고, 이 에이전트들이 늘어날수록 무엇이 운영되고 있는지 관리하기 어려워졌다는 점이다. 다른 대안은 코딩 에이전트를 그대로 비개발 직군에 열어 주는 방식이었다. 일부 직원이 실제로 이 방식으로 업무를 처리했지만, 코드 실행 환경이 요구하는 보안 통제가 없었고, 코드 품질팀이 비개발자를 지원해야 하는 새로운 부담까지 떠안았다.
두 시도 모두 도구는 있었지만 업무 흐름에 맞춘 구조가 없었다. 검색창에 질문을 던지는 기능만으로는 계정 조사, 매출 시나리오 모델링, 규정 준수 검토처럼 각기 다른 데이터·도구·완료 기준을 요구하는 작업을 감당하지 못한다는 뜻이다.
업무 흐름을 먼저 설계해야 하는 이유
스트라이프는 이 실패에서 세 가지 전제를 얻었다. 첫째, 전문성은 한곳에 모을 수 없다. 청구 오류를 어떻게 분류하는지, 매출 시나리오를 어떻게 모델링하는지 아는 사람은 에이전트 인프라를 만드는 팀이 아니라 GTM, 재무, 마케팅, 법무, 데이터 사이언스에 흩어져 있다. 둘째, 에이전트는 사용자가 있는 곳으로 가야 한다. 모두가 브라우저 탭이나 터미널에서 일하지 않으므로, 단일 제품이 아니라 여러 화면에 끼워 넣을 수 있는 플랫폼이 필요하다. 셋째, 코딩 에이전트가 갖는 컴파일러·테스트·버전관리 같은 안전장치가 지식 업무에는 원래 없다. 그래서 이 안전장치를 처음부터 새로 설계해야 한다.
세 번째 항목이 특히 구체적이다. 스트라이프는 한 세션 안에서 서로 무관한 두 고객의 데이터를 섞어 분석하면 안 된다는 내부 원칙을 예로 든다. 직원이 두 고객 정보에 각각 접근 권한이 있어도, 같은 작업에서 동시에 열람할 수는 없다. 이때 통제 기준은 "이 사람이 인증 토큰으로 무엇에 접근할 수 있는가"가 아니라 "이 작업이 지금 맥락에서 무엇을 봐도 되는가"다. 권한과 작업 맥락을 분리해서 판단해야 한다는 뜻이며, 이런 경계는 플랫폼이 사용자 대신 강제해야 사고를 막을 수 있다.
Kai는 실제로 어떻게 짜여 있나
스트라이프는 이 요구를 세 개 층으로 나눠 풀었다. 맨 위는 표면에 무관한 API 층이다. 대부분의 직원은 사내 웹 애플리케이션으로 Kai를 쓰지만, 실제 핵심은 이 웹앱과 Slack 통합이 함께 호출하는 API다. 사내 도구 어디든 이 API로 Kai를 끼워 넣을 수 있어서, 비즈니스 인텔리전스 플랫폼 안에서 작업하던 직원이 화면을 벗어나지 않고 Kai에게 질문할 수 있다.
중간층은 Agent Studio로, 각 도메인 팀이 자기 에이전트를 직접 만들고 운영하는 관리 화면이다. GTM 팀은 자신들의 업무에 맞춘 Kai 에이전트를 소유하며, 기본으로 자기 팀의 스킬을 불러오고 자기 데이터 소스에 연결하고 자기 팀이 원하는 형식으로 결과를 낸다. Agent Studio는 사용량과 품질 지표를 함께 보여줘서, 도메인 팀이 플랫폼 팀에 묻지 않고도 무엇이 잘 작동하는지 확인할 수 있다.
맨 아래는 실행 환경이다. 에이전트 하네스, 샌드박스, 워크플로 오케스트레이션, 접근 통제가 이 층에 있고, 이 구성 요소는 스트라이프의 제품용(고객 대면) 에이전트와 그대로 공유된다. 같은 민감한 데이터와 같은 사용자를 다루는 만큼 보안 기준도 같아야 한다는 판단이다. LangChain의 deepagents로 만든 이 하네스는 쿠버네티스 위에서 세션마다 격리된 샌드박스와 다중 테넌트 가상 파일시스템을 두고 동작하며, 하나의 대화가 최대 932턴까지 이어진 기록도 있다. 연결된 스킬과 도구는 1,000개가 넘고, 비즈니스 인텔리전스 대시보드부터 프로젝트 관리 도구, Zoom과 구글 워크스페이스 같은 외부 서비스까지 포함한다.
스트라이프가 공개한 구조도를 한국어로 옮기면 아래와 같다. Kai와 고객 대면 제품 에이전트가 같은 실행 환경 위에서 돌아가고, 그 환경 안에 세션 상태를 유지하는 에이전트 하네스와 워크플로 오케스트레이션, 세션별 샌드박스, 맥락 기반 스킬 선택이 들어 있다.
실제로 무엇이 달라졌나
GTM에 새로 입사한 직원은 처음부터 Kai를 쓰는 조건에서 업무를 배운다. 이들은 기존 직원보다 Kai를 2.7배 더 많이 쓰고, 같은 신입 집단 안에서도 Kai를 많이 쓰는 사람이 적게 쓰는 사람보다 80% 더 많은 가치를 만들어낸다. 영업 담당자(Account Executive)가 Kai를 쓴 주와 쓰지 않은 주를 같은 사람 기준으로 비교하면, 영업 활동량은 2배, 만든 영업 기회는 17% 더 많고, 매출로 이어질 기회는 26% 더 많으며, 실제 계약 성사는 39% 더 많다. 스트라이프는 이런 변화가 합쳐져 연간 2만 5,000시간을 행정 업무에서 매출을 만드는 업무로 옮겼다고 밝혔다.
재무·운영 조직에서는 지저분한 데이터를 정리하고 정기 보고서를 자동 생성하는 데 쓰이고, 엔지니어링 조직에서는 시스템 관련 질문에 답하거나 장애 조사, 로그 분석, 계획 초안 작성에 쓰인다. 스트라이프 전체에서 매일 5,000건 넘는 세션이 데이터 분석을 중심으로 이뤄진다.
Agent Studio와 실제 사용 장면
Agent Studio는 도메인 팀이 별도 개발 없이 스킬·작업·에이전트를 등록하고 관리하는 화면이다. 아래 화면에는 사내에서 실제 운영 중인 읽기 전용 검색 에이전트(internal-search), Kai 사용법을 안내하는 에이전트(kai-help)가 초안(Draft) 상태로 나열돼 있다. 코드를 다루지 않는 팀도 이 화면에서 자기 업무에 맞는 에이전트를 직접 등록한다는 뜻이다.
Kai가 다른 애플리케이션 안에 끼워 들어간 예로, 스트라이프는 내부 재무 분석 도구(Insights and Forecasting Studio)에서 매출 데이터를 시각화하며 대화로 후속 질문을 이어가는 화면을 공개했다. 사용자가 지역별 매출 추이를 보여달라고 요청하면 꺾은선 차트를 만들고, 이어서 기간을 좁히거나 분류 기준을 세그먼트로 바꿔달라는 요청에 맞춰 같은 화면 안에서 막대 차트로 다시 그린다. 화면을 벗어나 별도 챗봇 탭을 열 필요가 없다는 점이 앞서 설명한 "에이전트가 사용자에게 가야 한다"는 원칙의 실제 구현이다.
아직 풀리지 않은 문제
스트라이프는 Kai가 초기 단계라는 점을 분명히 한다. 세션이 길어질수록 도구 호출과 대용량 문서를 계속 끌어오면서 상태가 쌓이는데, LLM에 실제로 보내는 활성 컨텍스트와 S3나 가상 파일시스템에 남는 확장 컨텍스트의 균형을 계속 조정하는 중이다. 또한 특정 스킬을 쓴 세션의 기록을 되짚어 개선안을 제안하고 테스트한 뒤 스킬 소유팀에 검토를 넘기는 품질 개선 루프를 만들고 있고, 한 세션에서 만든 결과물을 다른 세션이나 다른 사람과 공유하는 기능도 아직 제한적이다. 스트라이프는 검색 인터페이스를 먼저 고르는 대신 접근 통제와 업무 흐름부터 설계한 뒤에 Kai를 얹었고, 위에서 본 미해결 과제들도 그 구조를 유지한 채로 하나씩 풀고 있다.
출처: Stripe Dot Dev Blog, Meet Stripe's Knowledge AI Platform