Stripe의 Knowledge AI Platform을 소개합니다
TMT코딩 에이전트는 Stripe의 엔지니어링을 바꿔 놓았지만, 영업 담당자, 재무 분석가, 테크니컬 어카운트 매니저 같은 비엔지니어들은 Claude Code와 Codex가 몰고 온 AI 물결에서 소외감을 느꼈습니다. 데이터 웨어하우스 조회, 영업 미팅 전 계정 조사, 인시던트 분류, 매출 시나리오 모델링, 컴플라이언스 검토 준비처럼 Stripe에 필요한 데이터 보안 요건과 특유의 워크플로를 감당할 수 있는 기존 도구는 없었습니다. Stripe의 Knowledge AI Platform을 출시하면서 이 모든 것이 달라졌습니다.
4월 출시 후 2주 만에 Stripe 직원 대부분이 Stripe Knowledge AI Platform, 일명 Kai를 사용하고 있었습니다. 현재는 83%가 주간 활성 사용자이며, 여기에는 GTM 조직(마케팅, 영업, 고객 성공 매니저, 테크니컬 어카운트 매니저) 거의 전원이 포함됩니다. 대부분의 Kai 세션은 여러 턴에 걸쳐 이어집니다. 사용자들이 깊이 있는 조사를 하고, 특정 산출물을 만들고, 사내외에 공유하기 전에 자료를 다듬기 때문입니다. Kai 덕분에 Stripe의 모든 구성원이 자신의 일상 업무를 돕도록 특별히 만들어진 에이전트를 갖게 되었습니다.
Knowledge AI Platform을 만든 이유
코딩 작업은 바꾸려는 내용이 매번 달라도 작업을 수행하는 워크플로와 도구는 거의 그대로입니다. 파일을 고치고, 테스트를 돌리고, 커밋합니다. 프로그래밍 언어는 달라도 일의 모양새는 꽤 균일해서 단일 에이전트 아키텍처가 잘 통합니다. 지식 업무는 그 스펙트럼의 정반대 끝에 있습니다. 계정을 조사하거나 컴플라이언스 검토를 준비하는 일은 저마다 다른 도구, 다른 데이터, 다른 산출물이 필요하고, "완료"의 기준마저 다릅니다.
Kai 이전에 지식 업무용 AI 선택지는 두 가지였습니다.
- NoCode Agent Builder: 누구나 도구를 쓸 수 있는 워크플로 특화 에이전트를 만들어 배포할 수 있었습니다. 이 시스템으로 4,000개가 넘는 에이전트가 만들어졌습니다. 그러나 여러 팀이 개념적으로 비슷한 프롬프트를 제각각의 품질로 작성하고 있다는 사실이 금방 드러났고, 이런 마이크로 에이전트가 불어날수록 모니터링과 유지 관리는 점점 어려워졌습니다.
- 코딩 에이전트: 코딩 에이전트는 강력했지만 또 다른 종류의 위험을 불러왔습니다. 우리 목표는 Stripe 전 구성원의 생산성 향상이었고, 일부 사용자는 자기 워크플로를 바꿔 가며 코딩 에이전트를 택했습니다. 그러나 곧 보안 우려가 불거졌고, 비엔지니어를 지원해 본 적 없는 코드 품질 팀에는 새로운 지원 부담이 생겼습니다.
이 경험을 통해 우리는 Knowledge AI Platform을 만들려면 세 가지를 제대로 해내야 한다는 것을 깨달았습니다. 전문성을 한곳에 모으지 않고도 확장하는 것, 사용자가 일하는 곳이 어디든 그곳으로 찾아가는 것, 그리고 코드에는 존재하지 않는 가드레일을 강제하는 것입니다.
전문성을 중앙에 모으지 않고 확장하기
Stripe 사용자들을 지원하는 데 필요한 전문성의 폭은 어마어마합니다. 빌링 에스컬레이션을 분류하거나 매출 시나리오를 모델링할 줄 아는 사람들은 한곳에 모여 있지 않고, 에이전트 인프라를 만드는 팀에 있는 것은 더더욱 아닙니다. 이들은 GTM, 재무, 마케팅, 법무, 데이터 사이언스 등 수십 개의 전문 도메인에 흩어져 있고, 도메인마다 고유한 도구와 데이터 소스, 워크플로, 그리고 "잘했다"가 무엇인지에 대한 판단 기준이 따로 있습니다. 여기에 Stripe가 운영하는 모든 제품과 국가를 곱하면 그 복잡도는 놀라울 정도입니다. Kai는 이 복잡성을 보이지 않게 감싸서, 작업이 그냥 되게끔 모델링해야 합니다.
에이전트는 어디든 갈 수 있어야 한다
에이전트가 무엇을 아느냐 못지않게 어디에 나타나느냐도 중요합니다. 모두가 브라우저 탭에서 일하는 것은 아니고, 터미널에서 일하는 사람은 더 적습니다. 그러니 지식 에이전트는 단일 제품에 머물 수 없습니다. 일이 벌어지는 곳이라면 어디든 스며들 수 있을 만큼 유연한 플랫폼이어야 합니다.
예를 들어 재무 팀이 Stripe 운영 예산의 복잡한 변경을 모델링할 때 쓰는 내부 애플리케이션을 생각해 봅시다. 에이전트는 맥락을 읽고, 관련 문서를 조사하고, 유효한 변경안을 제안하고, 차이를 요약해야 합니다. 이 모든 일을 사용자를 앱 밖으로 끌어내지 않은 채 해내야 합니다.
독립형 에이전트 제품을 만드는 방식은 통하지 않았을 것입니다. 사용자를 자연스러운 워크플로에서 끌어내 새 앱으로 밀어 넣게 되기 때문입니다. 화면(surface)마다 별도의 에이전트 제품을 만드는 것도 답이 아닙니다. 유지 관리가 어렵고, 여러 도구를 오가는 사용자는 조각난 경험을 하게 됩니다. 플랫폼이 사용자가 있는 곳으로 찾아가야 합니다.
가드레일을 밑바닥부터 만들기
코딩 에이전트는 수십 년에 걸쳐 다져진, 빠르고 검증 가능한 가드레일이 있는 환경에서 동작합니다. 컴파일러는 잘못된 문법을 거부하고, 테스트는 회귀를 잡아내고, git은 모든 실수를 되돌릴 수 있게 해 줍니다. 지식 업무에는 이런 장치가 거의 없습니다.
Stripe의 핵심 불변 규칙 하나를 봅시다. "서로 무관한 두 고객 맥락의 데이터를 하나의 분석에서 합쳐서는 안 된다." 사용자가 두 맥락 각각에는 정당한 접근 권한을 갖고 있더라도, 두 맥락이 같은 세션에 함께 등장해서는 안 됩니다. 격리 경계는 "이 사람이 인증 토큰으로 무엇에 접근할 수 있는가?" 가 아니라 "이 맥락에서 이 작업이 무엇을 보도록 허용되어야 하는가?" 입니다. 사용자들이 암묵적으로 기대는 이런 가드레일을 플랫폼이 강제해야 합니다.
Kai를 만든 방법
단일 모놀리식 에이전트로는 이 모든 제약을 효과적으로 담아낼 수 없습니다. 그렇다고 모든 도메인 팀에게 안전하고 호스팅되고 성능 좋은 에이전트 인프라를 각자 만들라고 하는 것도 확장 가능한 방법이 아닙니다. 이 문제를 풀기 위해 우리는 Kai를 세 개의 계층으로 만들었습니다.
- 하나의 에이전트에 여러 인터페이스를 제공하는 화면 독립적(surface-agnostic) API
- 도메인 소유자가 자기 Kai 에이전트를 직접 만들고 관리하는 AgentStudio
- 누구도 인프라를 신경 쓰지 않고도 몇 초 만에 보안을 제공하는 실행 환경
화면 독립적 API
Kai는 잘 다듬어진 웹 애플리케이션과 Slack 연동을 기본 제공하지만, 핵심 기본 요소는 이 둘을 모두 움직이는 하부 API입니다. 에이전트는 애플리케이션이 아니라 서비스이고, 각 화면은 그 서비스를 들여다보는 맞춤 뷰일 뿐입니다.
대부분의 Stripe 직원은 사내에 호스팅된 웹 애플리케이션으로 Kai를 사용합니다. 설정할 인프라가 없어서 입사 첫날부터 모든 직원이 바로 쓸 수 있습니다.
어떤 내부 도구든 Kai를 내장할 수 있고, 실제로 많은 도구가 그렇게 하고 있습니다. 예를 들어 비즈니스 인텔리전스 플랫폼에서 일하는 직원은 쓰던 애플리케이션 안에서 바로 Kai에게 질문할 수 있습니다. Chrome 확장 프로그램이 웹 기반 서드파티 도구 안에 Kai 기능을 띄워 주기 때문입니다.
커스텀 애플리케이션이 API로 Kai를 내장해 모든 워크플로에 에이전트 경험을 가져옵니다
AgentStudio
AgentStudio는 도메인 소유자를 위한 컨트롤 플레인입니다. 각 팀은 여기서 자기 스킬, 커스텀 Kai 에이전트, 도구 선택을 만들고 테스트하고 모니터링합니다. 예를 들어 GTM 팀은 자기 워크플로에 맞춘 Kai 에이전트를 소유합니다. 이 에이전트는 팀의 스킬을 기본으로 로드하고, 팀의 데이터 소스에 연결하며, 사용자가 기대하는 형식으로 결과를 보여 줍니다. AgentStudio는 자산마다 사용량 데이터와 품질 신호를 함께 보여 주므로, 도메인 소유자는 플랫폼 팀에 묻지 않고도 무엇이 잘 되고 있는지 알 수 있습니다.
스킬은 Stripe 전반의 영역별로 정리되고, 각 영역은 도메인 전문가가 관리합니다
실행 환경
플랫폼의 약속을 현실로 만드는 계층입니다. 에이전트 하네스, 샌드박스, 워크플로 오케스트레이션, 접근 제어 프레임워크 같은 핵심 기본 요소는 의도적으로 Stripe의 고객 대상 제품 에이전트와 공유합니다. 내부 지식 업무도 외부 제품과 같은 민감한 데이터를 다루고 같은 사용자를 상대하므로, 같은 수준의 보안·컴플라이언스 기준이 필요합니다. 기반을 공유하면 규율이 생기고 선순환이 만들어집니다. 실행 환경을 개선하면 내부 에이전트와 제품 에이전트가 동시에 좋아지는 것입니다.
LangChain의 deepagents로 만든 에이전트 하네스는 세션별 보안 샌드박스와 멀티테넌트 가상 파일시스템을 갖추고 Kubernetes 위에서 돌아갑니다. 세션 안에서 에이전트는 가상 파일시스템에서 산출물을 만들고 다듬으며, 분석과 데이터 처리에는 보안 코드 실행 샌드박스를 사용합니다.
길고 복잡한 세션에서도 상태를 유지하도록 설계되어 있습니다. 최근에는 932턴까지 간 세션도 있었습니다. Kai의 깊이 있는 작업 관리 능력 덕분에 한 대화가 수백 턴, 수백 번의 도구·LLM 호출로 이어져도 타임아웃되거나 컨텍스트 윈도가 넘치지 않습니다. 이것이 중요한 이유는, 지식 업무가 단발성 질문으로 끝나는 경우는 드물기 때문입니다. 앞선 결과를 딛고 쌓아 올라가는 반복적 추론이고, 세션은 그 상태를 품질 저하 없이 붙들고 있어야 합니다.
사용자 행동이 달라지고 있으며, 세션은 점점 깊이 있는 멀티턴 협업에 쓰이고 있습니다
하네스에서 가장 흥미로운 부분 중 하나는 올바른 스킬을 고르는 방식입니다. Kai는 핵심 지표를 추적하는 비즈니스 인텔리전스 대시보드부터 내부 실행을 정리하는 프로젝트 관리 도구, Zoom·Google Workspace 같은 서드파티 서비스까지, 다양한 내부 시스템에 걸친 1,000개 이상의 스킬과 도구에 연결되어 있습니다. 누구든 질문을 던지면 Kai가 알맞은 컨텍스트를 로드하고 알맞은 도구를 써서 일을 끝낼 것이라고 믿을 수 있습니다. 이 지점에서 코딩 에이전트는 태생적으로 유리합니다. 작업하는 폴더 구조가 스킬과 컨텍스트를 자연스럽게 정리해 주기 때문입니다. 이런 기존 구조 없이 하이브리드 RAG/LLM 접근 등 여러 기법으로 이 문제를 어떻게 풀었는지는 후속 글에서 다루겠습니다.
성과
결과는 놀라웠습니다. GTM의 신입 직원들은 Kai 네이티브입니다. Kai를 2.7배 더 많이 쓰고, 같은 코호트 안에서 파워 유저는 저사용자보다 80% 더 많은 가치를 성사시킵니다. Account Executive가 Kai를 쓰는 주에는, 같은 판매자가 쓰지 않는 주와 비교해 영업 활동이 2배가 되고, 기회를 17% 더 만들고, 매출 기회를 26% 더 창출하고, 계약을 39% 더 많이 성사시킵니다. 전체로 보면 Kai는 연간 2만 5,000시간을 행정 업무에서 매출을 만드는 업무로 옮기는 데 기여했습니다.
재무와 운영 부서에서는 Kai가 지저분한 데이터를 분석하고, 정기 요약본을 만들고, 조각난 맥락을 쓸 만한 산출물로 바꾸는 일을 돕고 있습니다.
엔지니어링에서는 시스템에 관해 질문하고, 실행 요청을 위해 조사하고, 로그를 분석하고, 계획 초안을 잡고, 더 전문화된 에이전트와 스킬을 호출하는 자연스러운 창구가 되었습니다.
그리고 Stripe 전사적으로 매일 5,000개가 넘는 세션이 데이터 분석을 중심으로 돌아갑니다. 이 덕분에 Kai는 독특한 지렛대가 됩니다. 데이터 품질과 분석 계층에 관한 올바른 컨텍스트를 연결해 두면, 대부분의 질문에 기본적으로 정확한 답이 나가도록 보장할 수 있습니다.
직원들의 직접적인 피드백도 이런 수치를 뒷받침합니다. "AI를 받아들일 힘이 생겼다", "Kai가 정확히 맞게 해내는 것을 보고 깜짝 놀랐다"는 반응이 나옵니다. 그중 우리가 가장 아끼는 일화는, Kai 소개 세션을 마치고 나오자마자 Asana, Slack, Jira를 하나의 자동화 프로세스로 모으는 요약본 작업을 함께 만들어 낸 어느 비엔지니어의 이야기입니다.
아직 이긴 게 아니다
Stripe가 즐겨 쓰는 말 중 하나가 "우리는 아직 이긴 게 아니다(we haven't won yet)"인데, Kai에 꼭 맞는 말입니다. 우리는 이 여정의 가장 초입에 있고, 하고 싶은 일이 훨씬 많습니다.
- 더 나은 상태 관리: Kai 같은 범용 에이전트는 도구를 반복 호출하고 큰 문서를 내려받는 과정에서 많은 상태를 만들어 냅니다. 우리는 LLM에 보내는 "활성" 컨텍스트와, S3나 가상 파일시스템 같은 상태 저장소에 놓인 "확장" 컨텍스트를 계속 조율하고 있습니다.
- 성찰과 자기 개선: Kai가 특정 스킬이 쓰인 트레이스를 돌아보고, 개선안을 제안하고, 테스트한 뒤, 스킬 소유자가 검토할 변경안을 제출하는 품질 개선 루프를 만들고 있습니다.
- 더 나은 협업 기본 요소: 사용자들이 Kai 세션에서 만들어 내는 수많은 컨텍스트가 지금은 세션 안에 "갇혀" 있는데, 실제 일은 그렇게 돌아가지 않습니다. Kai가 찾아낸 것을 세션 너머로 공유하고, 여러 사람(그리고 에이전트!)이 같은 산출물을 함께 다듬을 수 있게 하려고 합니다.
코딩 에이전트는 소프트웨어 엔지니어에게 가장 먼저 AI를 실감 나는 것으로 만들어 줬습니다. Kai는 그와 같은 지렛대의 감각을 Stripe 전체의 지식 노동자에게 가져다주는 데 기여했습니다. 흥미로운 점은, 생산성이 크게 좋아졌는데도 그 천장이 어디인지 아직 모른다는 것입니다. 우리는 계속 한계를 밀어붙일 생각에 들떠 있습니다. 내부 생산성과 외부 에이전트를 함께 움직이는 에이전트 시스템을 만드는 일이 구미가 당기는 도전이라면, Stripe가 채용 중입니다.
저자 소개
Anna Mason
Anna Mason은 Stripe의 테크니컬 라이터로, 엔지니어링 조직 전반에 걸쳐 일하고 있습니다.
Sharadh Krishnamurthy
Sharadh Krishnamurthy는 Stripe Agent Foundation 팀의 엔지니어링 매니저입니다.
Anupam Upadhyay
Anupam Upadhyay는 Stripe AI 플랫폼 팀의 소프트웨어 엔지니어입니다.