Meet Stripe's Knowledge AI Platform

3줄 요약

1. Stripe 엔지니어링 블로그가 2026년 7월 30일 사내 지식 노동용 AI 에이전트 플랫폼 Kai(Knowledge AI Platform)를 소개했다. Kai는 4월에 출시됐고, 두 주 만에 Stripe 직원 대부분이 쓰기 시작했다. 지금은 직원의 83%가 매주 Kai를 사용한다고 한다.
2. Stripe는 코딩과 달리 지식 노동은 과제마다 필요한 도구와 데이터, 산출물, 완료 기준이 모두 다르다고 판단했다. Kai는 여러 인터페이스가 같은 에이전트를 호출하게 하는 API, 도메인 팀이 자체 에이전트와 스킬을 만들고 관리하는 Agent Studio, Stripe 제품용 에이전트와 같은 보안 기반을 쓰는 실행 환경으로 구성된다.
3. 영업 담당자가 Kai를 쓴 주에는 쓰지 않은 주보다 성사된 거래가 39% 많았다고 Stripe는 밝혔다. 직원들은 Kai 덕분에 연간 25,000시간을 행정 업무 대신 매출을 만드는 업무에 쓰게 됐다. Stripe는 상태 관리, 스킬의 자기 개선 루프, 여러 사람이 함께 쓰는 협업 기능을 다음 과제로 꼽았다.

비개발 직군에게 필요했던 에이전트

코딩 에이전트는 Stripe 엔지니어링 조직의 일하는 방식을 크게 바꿨다. 그러나 영업 담당자, 재무 분석가, 기술 계정 매니저 같은 비개발 직군은 Claude Code와 Codex로 대표되는 AI 확산에서 소외감을 느꼈다고 한다. 이들에게는 데이터 웨어하우스를 조회하고, 영업 미팅 전에 고객사를 조사하고, 장애를 분류하고, 매출 시나리오를 모델링하고, 컴플라이언스 검토를 준비하는 데 쓸 도구가 필요했다. 기존 제품 가운데 Stripe의 데이터 보안 요구와 이런 업무 방식을 함께 충족할 수 있는 제품은 없었다.

Kai 웹 앱에서 행사 기획과 초대장 제작을 요청한 세션. (출처: Stripe)

Stripe가 4월에 Kai를 출시한 뒤 두 주가 지나기 전에 직원 대부분이 사용자가 됐다. 현재 주간 활성 사용자는 전 직원 가운데 83%이고, 마케팅, 영업, 고객 성공 매니저, 기술 계정 매니저로 이뤄진 GTM 조직¹은 거의 전원이 Kai를 쓴다. Kai 세션은 대부분 여러 턴으로 이뤄진다. 사용자들은 Kai로 깊이 있는 조사를 하거나, 특정한 산출물을 만들거나, 사내외에 공유하기 전에 자료를 손본다고 한다.

Stripe는 코딩과 지식 노동의 차이를 이렇게 설명했다. 코딩 과제는 변경 내용이 매번 달라도 워크플로와 도구는 거의 같다. 파일을 고치고, 테스트를 실행하고, 커밋하면 된다. 프로그래밍 언어가 달라도 작업의 형태가 균일하기 때문에 에이전트 아키텍처 하나로 잘 작동한다. 지식 노동은 사정이 정반대라고 한다. 고객사를 조사할 때와 컴플라이언스 검토를 준비할 때를 비교하면, 쓰는 도구와 데이터가 다르고 만들어야 할 산출물도 다르며, 어디까지 해야 “완료"로 볼지도 다르다.

Kai 이전에 Stripe 직원이 지식 노동에 쓸 수 있는 AI는 두 가지였다.

Stripe는 이 경험에서 지식 AI 플랫폼이 세 가지 요구를 충족해야 한다고 결론 내렸다. 전문성을 중앙화하지 않은 채로 확장해야 하고, 사용자가 일하는 도구마다 에이전트를 제공해야 하며, 코드 환경에는 원래 없는 가드레일을 강제해야 한다.

세 가지 요구

전문성을 중앙화하지 않고 확장한다

Stripe 사용자에게 필요한 전문성은 종류가 매우 많다. 결제 청구 에스컬레이션을 분류하거나 매출 시나리오를 모델링할 줄 아는 사람은 한 부서에 속해 있지 않고, 에이전트 인프라를 만드는 팀에는 더더욱 없다. 이런 사람들은 GTM, 재무, 마케팅, 법무, 데이터 과학 등 수십 개의 전문 영역에 분산돼 있다. 영역마다 쓰는 도구와 데이터 원천, 워크플로가 다르고, 좋은 결과물의 기준도 다르다. Stripe가 운영하는 제품과 국가의 수만큼 이 복잡도가 곱해진다. Stripe는 Kai가 이 복잡도를 모델링하되 사용자에게는 드러내지 않아서, 사용자가 별다른 수고 없이 과제를 해결할 수 있어야 한다고 적었다.

사용자가 일하는 도구마다 에이전트를 제공한다

Stripe는 에이전트가 무엇을 아는지만큼 어느 도구에서 제공되는지도 중요하다고 봤다. 모든 직원이 브라우저 탭에서 일하지는 않고, 터미널에서 일하는 직원은 훨씬 더 적다. 따라서 지식 에이전트는 단일 제품으로는 부족하며, 업무에 쓰이는 어느 도구에든 내장될 수 있는 플랫폼이어야 한다.

원문은 재무팀의 사내 애플리케이션을 예로 들었다. 재무팀은 이 앱으로 Stripe 운영 예산의 복잡한 변경을 모델링한다. 에이전트는 앱의 맥락을 읽고, 관련 문서를 조사하고, 유효한 변경안을 제안하고, 변경 전후의 차이를 요약해야 한다. 사용자는 이 모든 일을 앱을 전환하지 않고 해낼 수 있어야 한다.

Stripe는 두 가지 대안을 모두 기각했다. 독립형 에이전트 제품을 만들면 사용자는 평소의 워크플로를 중단하고 새 앱을 따로 써야 한다. 인터페이스마다 에이전트 제품을 따로 만들면 유지보수가 어렵고, 여러 도구를 번갈아 쓰는 사용자는 일관된 경험을 얻지 못한다.

가드레일을 처음부터 만든다

코딩 에이전트가 일하는 환경에는 수십 년에 걸쳐 만들어진, 빠르고 검증 가능한 가드레일이 있다. 잘못된 문법은 컴파일러가 거부하고, 이전에 되던 기능이 망가지면 테스트가 알려 주며, 실수를 저질러도 git으로 되돌릴 수 있다. 지식 노동에는 이런 장치가 거의 없다.

Stripe는 사내의 핵심 불변 조건 하나를 예로 들었다.

서로 관계없는 두 고객 맥락의 데이터를 하나의 분석에서 결합해서는 안 된다.

사용자는 두 맥락 각각에 정당한 접근 권한을 가지고 있을 수 있다. 그래도 두 고객 맥락의 데이터가 한 세션에 함께 포함돼서는 안 된다. 이 때문에 Kai는 격리 기준을 정할 때 “이 사람이 인증 토큰으로 무엇에 접근할 수 있는가"를 묻지 않는다. 대신 “이 맥락에서 이 과제가 무엇을 봐도 되는가"를 묻는다. 사용자는 이런 암묵적인 가드레일이 지켜진다고 믿고 일한다. 그래서 플랫폼이 그 가드레일을 강제해야 한다고 글쓴이들은 설명했다.

Kai의 세 계층

Stripe는 이 제약들을 모놀리식 에이전트 하나로는 효과적으로 구현할 수 없다고 봤다. 그렇다고 도메인 팀마다 안전하고 성능이 좋은 에이전트 호스팅 인프라를 따로 만들게 하는 방식도 확장성이 없다. 이 문제를 풀기 위해 Stripe는 Kai를 세 계층으로 만들었다.

인터페이스에 구애받지 않는 API

Kai는 기본 웹 애플리케이션과 슬랙 연동을 제공하고, 두 인터페이스는 같은 API로 구동된다. 원문은 이 API를 Kai의 핵심 기본 요소로 소개했다. Stripe는 에이전트를 하나의 서비스로 규정하고, 웹 앱이나 슬랙 같은 인터페이스는 그 서비스를 용도에 맞게 보여 주는 화면으로 설명했다.

Stripe 직원 대부분은 사내에서 호스팅하는 웹 앱으로 Kai를 쓴다. 직원이 따로 설정할 인프라가 없어서, 모든 직원이 입사 첫날부터 Kai를 쓸 수 있다.

사내 도구는 어느 것이든 Kai를 내장할 수 있고, 이미 많은 도구가 Kai를 내장했다. 예를 들어 비즈니스 인텔리전스(BI) 플랫폼에서 일하는 직원은 그 앱에서 곧바로 Kai에게 질문할 수 있다. Stripe가 만든 크롬 확장 프로그램이 웹 기반 외부 도구에서도 Kai 기능을 제공하기 때문이다.

사내 애플리케이션은 API로 Kai를 내장해 모든 워크플로에서 에이전트 기능을 제공한다. (출처: Stripe)

Agent Studio

Stripe는 Agent Studio를 도메인 담당자용 컨트롤 플레인(control plane)이라고 소개했다. 각 팀은 Agent Studio에서 자기 팀의 스킬과 맞춤형 Kai 에이전트, 도구 구성을 만들고, 테스트하고, 모니터링한다. 예를 들어 GTM 팀은 자기 워크플로에 맞춘 Kai 에이전트를 직접 소유한다. 이 에이전트는 GTM 팀의 스킬을 기본으로 불러오고, 팀의 데이터 원천에 연결되며, 사용자가 기대하는 형식으로 결과를 보여 준다. Agent Studio는 에이전트와 스킬 등 각 자산의 사용량 데이터와 품질 신호도 함께 보여 준다. 도메인 담당자는 플랫폼 팀에 묻지 않고도 무엇이 잘 작동하는지 확인할 수 있다.

자산은 Stripe 전사의 영역별로 정리되고, 각 영역은 도메인 전문가가 관리한다. (출처: Stripe)

실행 환경

Stripe는 실행 환경을 플랫폼의 약속을 실제로 구현하는 계층이라고 밝혔다. 에이전트 하네스, 샌드박스, 워크플로 오케스트레이션, 접근 제어 프레임워크 같은 핵심 기본 요소는 Stripe의 제품용 에이전트와 의도적으로 공유한다. 사내 지식 업무도 외부 제품과 같은 민감한 데이터를 다루고 같은 고객을 위한 일이므로, 보안과 컴플라이언스 기준도 제품과 같아야 하기 때문이다. Stripe는 기반을 공유하면 양쪽 모두 같은 규율을 지켜야 하고, 선순환도 생긴다고 설명했다. 실행 환경을 개선하면 사내 에이전트와 제품용 에이전트가 동시에 그 혜택을 받는다.

커버 이미지로 쓴 구성도가 이 공유 구조를 보여 준다. 구성도에서 에이전트 하네스는 쿠버네티스에서 동작하며 장기 세션의 맥락과 상태를 유지한다. 하네스의 구성 요소로는 계획과 작업 조율을 맡는 워크플로 오케스트레이션, 격리된 코드 실행을 맡는 세션별 샌드박스, 가상 파일과 산출물을 보관하는 세션 작업 공간, 상황별 라우팅이 있다. 상황별 라우팅은 Stripe 데이터와 사내 시스템, 팀이 소유한 도메인 워크플로, 구글 워크스페이스와 줌 같은 외부 서비스로 구성된 1,000개 이상의 스킬과 도구 가운데 알맞은 것을 선택한다.

하네스를 만들 때 Stripe는 LangChain이 공개한 에이전트 프레임워크 deepagents를 썼다. 하네스는 쿠버네티스에서 실행되며, 세션별 보안 샌드박스와 멀티테넌트 가상 파일 시스템을 쓴다. 에이전트는 세션 동안 가상 파일 시스템에서 산출물을 만들고 반복해서 고치며, 분석과 데이터 처리에는 보안 코드 실행 샌드박스를 쓴다.

하네스는 길고 복잡한 세션에서도 상태를 유지하도록 설계됐다. 최근 한 세션은 932턴에 도달했다고 한다. Kai의 작업 관리 기능은 대화 하나가 수백 턴, 수백 번의 도구 호출과 LLM 호출로 구성돼도 시간 초과나 컨텍스트 창 과부하가 생기지 않도록 한다. 이 기능이 중요한 까닭은 지식 노동이 단발성 질문으로 끝나는 경우가 드물기 때문이라고 한다. 지식 노동은 이전 추론 결과를 활용해 다음 추론을 하는 반복 작업이므로, 세션은 이전 작업의 맥락과 상태를 품질 저하 없이 유지해야 한다.

사용자 행동이 달라지고 있으며, 세션은 여러 턴의 대화로 깊이 협업하는 데 점점 더 많이 쓰인다. (출처: Stripe)

Stripe는 2026년 6월 한 달 동안 생긴 세션 36만 개로 이 그래프를 그렸다. 그래프에 표시된 값은 다음과 같다.

Stripe는 하네스에서 특히 흥미로운 부분으로 올바른 스킬을 고르는 방식을 꼽았다. Kai는 핵심 지표를 추적하는 BI 대시보드, 사내 실행 과제를 관리하는 프로젝트 관리 도구, 줌과 구글 워크스페이스 같은 외부 서비스까지 1,000개 이상의 스킬과 도구에 연결돼 있다. 사용자는 Kai에게 질문했을 때 Kai가 알맞은 맥락을 불러오고 알맞은 도구로 일을 끝낼 것이라고 믿을 수 있어야 한다. 이 점에서는 코딩 에이전트가 유리하다. 코딩 에이전트가 작업하는 폴더 구조에 따라 스킬과 맥락이 자연스럽게 분류되기 때문이다. Stripe는 그런 구조가 없는 상황에서 RAG와 LLM을 함께 쓰는 하이브리드 방식 등으로 이 문제를 어떻게 풀었는지 후속 글에서 설명하겠다고 예고했다.

성과

Stripe는 Kai 도입 결과를 수치로 공개했다. 글쓴이들은 GTM 조직의 신규 입사자를 “Kai 네이티브"라고 부른다. 이들은 Kai를 2.7배 더 많이 쓴다.² 같은 시기에 입사한 직원 가운데 Kai를 많이 쓰는 파워 유저가 성사시킨 거래 금액은 Kai를 적게 쓰는 직원보다 80% 많다.

영업 담당자(AE, Account Executive)의 성과는 같은 영업 담당자가 Kai를 쓴 주와 쓰지 않은 주를 비교해 측정했다.

Stripe는 Kai 덕분에 직원들이 연간 25,000시간을 행정 업무 대신 매출을 만드는 업무에 쓰게 됐다고 밝혔다.

다른 부서에서 Kai를 쓰는 방식은 다음과 같다.

• 재무와 운영 부서는 Kai로 정돈되지 않은 데이터를 분석하고, 정기 다이제스트를 만들고, 여러 곳에 분산된 맥락을 바로 쓸 수 있는 산출물로 정리한다.
• 엔지니어링 조직에서 Kai는 시스템에 대해 질문하고, 실행 요청(run request)에 필요한 조사를 하고, 로그를 분석하고, 계획 초안을 쓰고, 더 전문적인 에이전트와 스킬을 호출하는 도구가 됐다.
• 전사적으로는 매일 5,000개 이상의 세션이 데이터 분석에 쓰인다. Stripe의 설명에 따르면, 데이터 품질과 분석 계층에 관한 올바른 맥락을 Kai에 연결해 두면 Kai는 대부분의 질문에 기본값으로 정확한 답을 낸다. 이 때문에 Stripe는 Kai 하나만 개선해도 전사의 데이터 분석 품질이 함께 좋아진다고 본다.

직원들은 Kai 덕분에 “AI를 적극적으로 받아들일 힘이 생겼다"고 했고, “Kai가 알아서 정확하게 해내는 일에 놀랐다"고도 했다. Stripe가 가장 좋아하는 일화는 한 비개발 직원의 사례다. 이 직원은 Kai 소개 세션을 마치자마자 Kai와 함께 Asana, 슬랙, Jira의 정보를 하나로 모으는 자동화 다이제스트를 만들었다.

향후 과제

Stripe가 즐겨 쓰는 표어 가운데 “아직 이긴 게 아니다(we haven’t won yet)“가 있다. 글쓴이들은 Kai에도 이 말이 해당한다며, Kai가 아직 초기 단계이고 Stripe가 하고 싶은 일도 많다고 했다. 이들은 과제 세 가지를 꼽았다.

• 상태 관리 개선. Kai 같은 범용 에이전트는 도구 호출을 반복하고 큰 문서를 불러오므로 상태 정보가 많아진다. Stripe는 LLM에 보내는 “활성” 컨텍스트와, S3나 가상 파일 시스템 같은 상태 저장소에 두는 “확장” 컨텍스트를 계속 조정하고 있다.
• 성찰과 자기 개선. Kai가 특정 스킬이 쓰인 실행 기록(trace)을 검토하고, 개선안을 제안하고, 그 개선안을 테스트한 뒤, 스킬 소유자에게 변경 검토를 요청하는 품질 개선 루프를 만들고 있다.
• 협업 기능 강화. 사용자가 Kai 세션에서 만든 맥락은 지금은 그 세션에서만 쓸 수 있다. Stripe는 Kai가 찾아낸 내용을 여러 세션에서 공유하고, 여러 사람과 에이전트가 같은 산출물을 함께 작업할 수 있게 하려 한다.

글쓴이들은 코딩 에이전트가 소프트웨어 엔지니어에게 먼저 AI의 효용을 체감하게 했고, Kai가 같은 효용을 Stripe의 지식 노동자에게 제공했다고 정리했다. 생산성은 이미 크게 높아졌지만, 얼마나 더 높일 수 있을지는 아직 모른다고 덧붙였다.

읽으며 눈여겨본 것

나는 Kai가 격리 기준을 정할 때 쓰는 질문에 먼저 주목했다. 보통의 접근 제어는 사용자 권한을 기준으로 삼는다. 사용자 권한만 따지면, 두 고객의 데이터를 각각 볼 수 있는 직원은 두 데이터를 한 세션에서 함께 봐도 문제가 없다. Kai는 여기에 과제 단위의 제약을 하나 더 추가한다. 사람이 일할 때는 상식으로 지키던 규칙인데, 에이전트는 권한이 허용하는 데이터를 한꺼번에 불러올 수 있으므로 시스템이 그 규칙을 강제해야 한다. 코딩에서 컴파일러와 테스트가 하던 일을 지식 노동에서는 이런 규칙이 대신해야 한다고 Stripe는 판단한 것 같다.

세션 지표 그래프에서도 눈여겨볼 수치가 있다. Stripe는 Kai 세션 대부분이 여러 턴으로 이뤄진다고 설명했는데, 그래프를 보면 세션의 4분의 1 이상이 1턴으로 끝나고 턴 수 중앙값은 2다. 그런데도 Stripe는 932턴짜리 세션을 사례로 들었고, 상태 관리를 향후 과제의 첫 항목으로 꼽았다. 짧은 세션이 다수이지만, Stripe는 소수의 긴 세션도 처리할 수 있도록 하네스를 설계했다. 평균 호출 수를 평균 턴 수로 나누면, Kai는 사용자의 메시지 한 건에 답하는 동안 LLM을 네 번쯤, 도구를 다섯 번쯤 부른다.

출처

Anna Mason(테크니컬 라이터), Sharadh Krishnamurthy(Agent Foundation 팀 엔지니어링 매니저), Anupam Upadhyay(AI Platform 팀 소프트웨어 엔지니어), 「Meet Stripe’s Knowledge AI Platform」, Stripe Developers Blog, 2026년 7월 30일.

원문: https://stripe.dev/blog/meet-stripes-knowledge-ai-platform

커버와 본문의 이미지는 모두 원문에서 인용했다.