메타데이터
- 발신자: TLDR
- 원문 URL: https://stripe.dev/blog/meet-stripes-knowledge-ai-platform
- 발행일: 2026-07-31
- 카테고리: ai-llm
직역 전문
코딩 에이전트는 스트라이프(Stripe)의 엔지니어링을 완전히 바꿔놓았지만, 영업 담당자, 재무 분석가, 기술 계정 매니저 같은 비개발직군은 Claude Code나 Codex 같은 AI 물결에서 소외된 느낌을 받았습니다. 데이터 보안 요구사항과 스트라이프 특유의 업무 흐름 — 데이터 웨어하우스 조회, 영업 콜 전 계정 리서치, 인시던트 트리아지, 매출 시나리오 모델링, 컴플라이언스 검토 준비 — 을 처리할 수 있는 기존 도구는 없었습니다. 스트라이프의 지식 AI 플랫폼을 출시하면서 이 상황은 바뀌었습니다.
지난 4월 출시 후 2주 만에 스트라이프 대부분의 구성원이 Kai(스트라이프의 지식 AI 플랫폼, Stripe's Knowledge AI Platform)를 사용하기 시작했습니다. 현재는 전체 구성원의 83%가 주간 활성 사용자이며, 여기에는 마케팅, 영업, 고객 성공팀, 기술 계정 매니저 등 GTM(고투마켓) 조직 거의 전체가 포함됩니다. Kai 세션 대부분은 여러 턴(turn)을 필요로 하며, 사용자들은 내부·외부 공유 전에 심층 리서치를 하거나, 특정 산출물을 만들거나, 자산을 다듬는 작업을 진행합니다. Kai 덕분에 스트라이프의 모든 구성원은 각자의 일상 업무를 돕도록 특별히 설계된 에이전트를 갖게 되었습니다.
왜 지식 AI 플랫폼을 만들었는가
코딩 작업의 경우 구체적인 변경 내용은 다르지만, 작업 흐름과 필요한 도구는 대체로 동일합니다. 파일을 편집하고, 테스트를 실행하고, 커밋합니다. 프로그래밍 언어는 다양하지만 작업의 형태는 상당히 균일하기 때문에 단일 에이전트 아키텍처가 잘 작동합니다. 지식 노동(knowledge work)은 그 반대편 극단에 있습니다. 계정을 리서치하거나 컴플라이언스 검토를 준비하는 작업은 각기 다른 도구, 다른 데이터, 다른 산출물, 그리고 다른 "완료"의 정의를 요구합니다.
Kai 이전에는 지식 노동을 위한 두 가지 AI 옵션이 있었습니다.
- 노코드 에이전트 빌더(NoCode Agent Builder): 누구나 도구를 사용하는 워크플로우 전용 에이전트를 만들어 배포할 수 있었습니다. 이 시스템으로 4,000개가 넘는 에이전트가 만들어졌습니다. 하지만 팀들이 개념적으로는 비슷하지만 품질 편차가 큰 프롬프트를 작성하고 있다는 것을 곧 알게 되었고, 이런 마이크로 에이전트의 증식은 모니터링과 유지보수를 점점 더 어렵게 만들었습니다.
- 코딩 에이전트: 코딩 에이전트는 강력했지만 다른 종류의 리스크를 초래했습니다. 스트라이프 전체의 생산성 향상이 목표였기 때문에 일부 사용자는 자신의 워크플로우를 바꿔 코딩 에이전트를 선택했습니다. 하지만 곧 보안 우려가 불거졌고, 비개발자를 지원해본 적이 없는 코드 품질 팀에게 새로운 지원 부담이 생겼습니다.
이런 경험을 통해 지식 AI 플랫폼을 제대로 만들려면 세 가지를 올바르게 해내야 한다는 것을 깨달았습니다. 전문성을 중앙화하지 않으면서 확장하기, 사용자가 있는 곳이라면 어디든 만나기, 그리고 코드에는 존재하지 않는 가드레일을 강제하기입니다.
전문성을 중앙화하지 않으면서 확장하기
스트라이프의 사용자들을 지원하는 데 필요한 전문성의 범위는 압도적입니다. 청구 관련 에스컬레이션을 처리하거나 매출 시나리오를 모델링하는 방법을 아는 사람들은 중앙화되어 있지 않으며, 에이전트 인프라를 구축하는 팀에 속해 있지도 않습니다. 이들은 GTM, 재무, 마케팅, 법무, 데이터 사이언스 등 수십 개의 전문 영역에 흩어져 있고, 각 영역은 저마다의 도구, 데이터 소스, 워크플로우, "좋음"에 대한 판단 기준을 가지고 있습니다. 여기에 스트라이프가 운영하는 모든 제품과 국가를 곱하면 결과는 놀랄 만큼 복잡해집니다. Kai는 이 복잡성을 사용자에게 보이지 않게 모델링해서 작업이 그저 잘 되도록 만들어야 합니다.
에이전트는 돌아다닐 수 있어야 한다
에이전트가 어디에 나타나는지는 무엇을 아는지 만큼이나 중요합니다. 모두가 브라우저 탭에서 일하지 않고, 터미널에서 일하는 사람은 더 적습니다. 따라서 지식 에이전트는 단일 제품일 수 없으며, 업무가 일어나는 곳이라면 어디든 스스로를 끼워 넣을 수 있을 만큼 유연한 플랫폼이어야 합니다.
예를 들어 재무 팀이 스트라이프의 운영 예산에서 복잡한 변경 사항을 모델링하는 데 사용하는 내부 애플리케이션을 생각해봅시다. 에이전트는 사용자를 앱 밖으로 끌어내지 않고도 맥락을 읽고, 관련 문서를 리서치하고, 유효한 변경안을 제안하고, 차이점을 요약해야 합니다.
독립된 에이전트 제품을 만드는 것은 통하지 않았을 것입니다. 사용자를 자연스러운 워크플로우 밖으로 밀어내 새로운 앱으로 몰아넣게 되기 때문입니다. 각 서피스마다 별도의 에이전트 제품을 만드는 것도 통하지 않았을 것입니다. 유지보수가 어려워지고, 여러 도구를 넘나드는 사용자는 파편화된 경험을 하게 되기 때문입니다. 플랫폼은 사용자가 있는 곳으로 가야 합니다.
가드레일을 처음부터 구축하기
코딩 에이전트는 수십 년간 축적된 빠르고 검증 가능한 가드레일이 있는 환경에서 동작합니다. 컴파일러는 잘못된 문법을 거부하고, 테스트는 회귀를 잡아내며, git은 모든 실수를 되돌릴 수 있게 해줍니다. 지식 노동에는 이런 장치를 뒷받침하는 것이 거의 없습니다.
스트라이프의 핵심 불변 조건 하나를 생각해봅시다. "관련 없는 두 고객 맥락의 데이터를 하나의 분석에서 결합해서는 안 된다"는 것입니다. 사용자가 두 맥락 모두에 개별적으로는 정당한 접근 권한을 가지고 있을 수 있지만, 두 맥락이 같은 세션에 동시에 나타나서는 절대 안 됩니다. 여기서 격리 경계는 "이 사람이 인증 토큰을 기준으로 무엇에 접근할 수 있는가"가 아니라 "이 맥락이 주어졌을 때 이 작업이 무엇을 보도록 허용해야 하는가"입니다. 플랫폼은 사용자가 의존하는 이런 암묵적 가드레일을 강제해야 합니다.
Kai를 어떻게 만들었는가
단일한 거대 에이전트로는 이런 모든 제약을 효과적으로 인코딩할 수 없습니다. 그렇다고 모든 도메인 팀에게 안전하고 호스팅되며 성능 좋은 에이전트 인프라를 각자 독립적으로 구축하게 하는 것도 확장 가능하지 않습니다. 이 문제를 해결하기 위해 Kai를 세 개의 계층으로 만들었습니다.
- 동일한 에이전트에 여러 인터페이스를 제공하는 서피스 애그노스틱(surface-agnostic) API
- 도메인 오너들이 자신의 Kai 에이전트를 만들고 관리하는 AgentStudio
- 아무도 인프라를 신경 쓰지 않아도 몇 초 안에 보안을 제공하는 실행 환경(Execution environments)
서피스 애그노스틱 API
Kai는 자체 웹 애플리케이션과 Slack 통합을 갖추고 있지만, 핵심 프리미티브는 이 둘을 모두 구동하는 기반 API입니다. 에이전트는 애플리케이션이 아니라 서비스이며, 서피스들은 그 서비스를 들여다보는 맞춤형 창일 뿐입니다.
대부분의 스트라이프 구성원은 내부에 호스팅된 웹 애플리케이션을 통해 Kai와 상호작용합니다. 별도로 구축할 인프라가 없으며, 입사 첫날부터 모든 직원이 사용할 수 있습니다.
어떤 내부 도구든 Kai를 임베드할 수 있으며, 실제로 많은 도구가 그렇게 하고 있습니다. 예를 들어 비즈니스 인텔리전스 플랫폼에서 일하는 직원은 앱을 벗어나지 않고도 Kai에게 질문할 수 있습니다. 크롬 확장 프로그램이 웹 기반 서드파티 도구 내부에 Kai 기능을 노출하기 때문입니다.
AgentStudio
AgentStudio는 도메인 오너를 위한 컨트롤 플레인입니다. 팀들은 이를 사용해 자신들의 스킬, 커스텀 Kai 에이전트, 도구 선택을 만들고 테스트하고 모니터링합니다. 예를 들어 GTM 팀은 자신들의 워크플로우에 맞춰 튜닝된 Kai 에이전트를 소유합니다. 이 에이전트는 기본적으로 그들의 스킬을 불러오고, 그들의 데이터 소스에 연결되며, 사용자가 기대하는 형식으로 결과물을 제시합니다. AgentStudio는 각 자산 옆에 사용량 데이터와 품질 신호를 함께 보여주므로, 도메인 오너는 플랫폼 팀에 묻지 않고도 무엇이 잘 작동하는지 확인할 수 있습니다.
실행 환경
이 계층이 플랫폼의 약속을 실제로 구현하는 부분입니다. 에이전트 하네스, 샌드박스, 워크플로우 오케스트레이션, 접근 제어 프레임워크를 포함한 핵심 프리미티브는 스트라이프의 제품용 에이전트와 의도적으로 공유됩니다. 내부 지식 노동은 외부 제품과 동일한 민감 데이터를 다루고 동일한 사용자를 대상으로 하기 때문에, 동일한 수준의 보안과 컴플라이언스 기준이 필요합니다. 기반을 공유함으로써 규율이 강제되고, 실행 환경의 개선이 내부 에이전트와 제품 에이전트 모두에게 동시에 이익을 주는 선순환이 만들어집니다.
LangChain의 deepagents를 사용해 구축된 에이전트 하네스는 쿠버네티스 위에서 실행되며, 세션마다 보안이 적용된 샌드박스와 멀티테넌트 가상 파일 시스템을 사용합니다. 세션 안에서 에이전트는 산출물을 만들고 반복 작업하는 가상 파일 시스템을 다루며, 분석과 데이터 처리에는 보안이 적용된 코드 실행 샌드박스를 사용합니다.
Kai는 길고 복잡한 세션에 걸쳐 상태를 유지하도록 만들어졌으며, 최근 한 세션은 932턴에 도달했습니다. Kai의 심층 작업 관리 능력 덕분에 하나의 대화가 수백 개의 턴, 그리고 수백 번의 도구 호출과 LLM 호출로 이루어질 수 있으며, 시간 초과나 컨텍스트 윈도우 과부하 없이 진행됩니다. 이는 중요한 부분인데, 지식 노동은 단발성 질문인 경우가 드물기 때문입니다. 이는 스스로를 기반으로 쌓아 올리는 반복적인 추론이며, 세션은 성능 저하 없이 그 상태를 유지해야 합니다.
Kai 하네스에서 가장 흥미로운 부분 중 하나는 올바른 스킬을 선택하는 방식입니다. Kai는 핵심 지표를 추적하는 비즈니스 인텔리전스 대시보드부터 내부 실행을 조율하는 프로젝트 관리 도구, Zoom·Google Workspace 같은 서드파티 서비스에 이르기까지 다양한 내부 시스템에 걸쳐 1,000개 이상의 스킬과 도구에 연결되어 있습니다. 누구나 질문을 던지면 Kai가 올바른 맥락을 불러오고 올바른 도구를 사용해 작업을 완수할 것이라고 신뢰할 수 있습니다. 코딩 에이전트는 이 지점에서 자연스러운 이점이 있습니다. 작업하는 폴더 구조 자체가 스킬과 맥락을 위한 자연스러운 조직을 제공하기 때문입니다. 후속 포스트에서는 이런 기존 구조가 없는 상태에서 하이브리드 RAG/LLM 접근법 등을 활용해 이 문제를 어떻게 해결했는지 다룰 예정입니다.
성과
결과는 놀라웠습니다. GTM에 새로 합류한 직원들은 처음부터 Kai를 자연스럽게 사용하며(Kai-native), 2.7배 더 많이 사용하고, 같은 코호트 안에서 파워 유저는 저사용 유저보다 80% 더 많은 가치를 만들어냅니다. 영업 담당자(Account Executive)가 Kai를 사용하면, 사용하지 않은 주와 비교했을 때 같은 영업 담당자 기준으로 영업 활동이 2배, 기회 생성이 17% 증가, 매출 기회가 26% 증가, 거래 성사가 39% 더 많아집니다. 전체적으로 Kai는 연간 25,000시간을 관리 업무에서 매출 창출 업무로 전환하는 데 도움을 주었습니다.
재무·운영 부서에서 Kai는 지저분한 데이터를 분석하고, 정기 다이제스트를 생성하고, 파편화된 맥락을 사용 가능한 산출물로 바꾸는 데 도움을 주고 있습니다.
엔지니어링에서 Kai는 이제 시스템 관련 질문을 하고, 런 요청을 리서치하고, 로그를 분석하고, 계획을 초안하고, 더 전문화된 에이전트와 스킬을 호출하는 자연스러운 창구가 되었습니다.
그리고 스트라이프 전체에서 매일 5,000개 이상의 세션이 데이터 분석을 중심으로 이루어집니다. 이는 Kai를 독특한 레버리지 포인트로 만듭니다. 데이터 품질과 분석 계층에 대한 올바른 맥락을 연결함으로써 대부분의 질문에 기본적으로 정확한 응답을 보장할 수 있기 때문입니다.
스트라이프 구성원들의 직접적인 피드백도 이런 집계 수치를 뒷받침합니다. 이들은 "AI를 받아들일 힘을 얻었다"거나 "Kai가 정확히 옳은 일을 해내는 것에 놀랐다"고 말합니다. 하지만 가장 마음에 드는 일화는, Kai 소개 세션을 마치고 나온 한 비개발자가 곧바로 Asana, Slack, Jira를 하나의 자동화된 프로세스로 묶어내는 다이제스트를 함께 만들어냈다는 것입니다.
우리는 아직 이기지 못했다
스트라이프가 가장 좋아하는 문구 중 하나는 "우리는 아직 이기지 못했다(we haven't won yet)"이며, 이는 Kai에도 딱 들어맞습니다. 이 여정은 이제 막 시작한 가장 초기 단계이며, 하고 싶은 일이 훨씬 더 많이 남아 있습니다.
- 더 나은 상태 관리: Kai 같은 범용 에이전트는 반복적으로 도구를 호출하고, 큰 문서를 내려받는 등의 과정에서 많은 상태를 만들어냅니다. LLM에 전달되는 "활성(active)" 컨텍스트와 S3나 가상 파일 시스템 같은 상태 저장소에 있는 "확장(extended)" 컨텍스트를 지속적으로 튜닝하고 있습니다.
- 성찰과 자기 개선: 특정 스킬과 관련된 트레이스를 Kai가 스스로 성찰하고, 개선안을 제안하고, 테스트한 뒤 스킬 오너의 검토를 위해 변경 사항을 제출하게 하는 품질 개선 루프를 만들고 있습니다.
- 더 나은 협업 프리미티브: 사용자들은 Kai 세션에서 많은 맥락을 만들어내지만 현재는 그것이 세션 안에 "갇혀" 있습니다. 하지만 업무는 그런 식으로 이루어지지 않습니다. 사람들이 Kai가 드러낸 것을 세션 간에 공유하고, 여러 사람(그리고 에이전트들!)이 같은 산출물에서 함께 협업할 수 있도록 만들고 싶습니다.
코딩 에이전트는 소프트웨어 엔지니어들에게 AI를 가장 먼저 구체적으로 느껴지게 만들었습니다. Kai는 그와 같은 레버리지 감각을 스트라이프 전역의 지식 노동자들에게도 가져다주었습니다. 흥미로운 점은, 생산성을 상당히 개선했음에도 아직 그 한계를 모른다는 것이며, 이 지점을 계속 밀어붙이는 것이 기대됩니다.
4계층 심층 요약
1. 핵심 주장
스트라이프는 코딩 에이전트가 개발자 생산성을 바꾼 것처럼, 비개발직군(영업·재무·GTM 등)을 위한 범용 지식 노동 AI 플랫폼 Kai를 만들었다. Kai는 서피스 애그노스틱 API, 도메인 오너가 직접 관리하는 AgentStudio, 제품 에이전트와 인프라를 공유하는 실행 환경이라는 3계층 구조로, 전문성을 중앙화하지 않고도 확장하고 사용자가 있는 곳 어디서나 동작하며 코드에는 없는 가드레일을 강제한다.
2. 근거
- 코딩 작업은 도구·워크플로우가 균일해 단일 에이전트로 충분하지만, 지식 노동은 도메인마다 도구·데이터·산출물·완료 기준이 달라 단일 에이전트 아키텍처로는 부족하다.
- 기존 NoCode 에이전트 빌더(4,000개 이상 에이전트 생성)는 품질 편차와 관리 부담이 커졌고, 코딩 에이전트를 비개발자에게 그대로 쓰게 하면 보안·지원 부담이 발생했다.
- 서로 무관한 두 고객 맥락이 한 세션에 섞이면 안 된다는 것처럼, 코드의 컴파일러·테스트·git과 달리 지식 노동에는 검증 가능한 가드레일이 거의 없어 플랫폼이 이를 대신 강제해야 한다.
- 에이전트 하네스는 LangChain deepagents 기반으로 쿠버네티스 위에서 세션별 샌드박스와 멀티테넌트 가상 파일시스템을 사용하며, 제품용 에이전트 인프라와 기반을 공유해 보안 수준을 맞춘다.
- Kai는 1,000개 이상의 내부 스킬·도구에 연결되어 있고, 하나의 세션이 최대 932턴까지 상태를 유지할 수 있다.
3. 사례
- 4월 출시 2주 만에 스트라이프 대부분이 Kai를 사용했고, 현재 전체 구성원의 83%가 주간 활성 사용자이며 GTM 조직 대부분이 포함된다.
- GTM 신입 직원은 기존 직원보다 2.7배 더 Kai를 사용하며, 같은 코호트 내 파워 유저는 저사용 유저보다 80% 더 많은 가치를 창출한다.
- 영업 담당자가 Kai를 쓴 주는 그렇지 않은 주 대비 영업 활동 2배, 기회 생성 17%↑, 매출 기회 26%↑, 거래 성사 39%↑를 기록했다.
- 연간 25,000시간이 관리 업무에서 매출 창출 업무로 전환되었고, 스트라이프 전체에서 매일 5,000건 이상의 세션이 데이터 분석 중심으로 이루어진다.
4. 시사점
스타트업이나 소규모 팀에서도 "코딩 에이전트는 있는데 비개발 직군은 소외된다"는 문제는 흔하다. Kai 사례는 단일 만능 에이전트보다, 도메인별 커스텀 에이전트를 도메인 오너가 직접 관리하게 하는 거버넌스 구조(AgentStudio)와, 보안·격리 가드레일을 플랫폼 레벨에서 강제하는 설계가 실제 채택률과 매출 지표로 이어진다는 것을 보여준다. 토니처럼 여러 제품·팀을 운영하는 입장에서는, 에이전트를 "어디서든 임베드 가능한 API + 서비스"로 설계하는 방식과, 세션 상태 관리·컨텍스트 관리를 별도 계층으로 분리하는 아키텍처가 앞으로 사내 AI 도구를 설계할 때 참고할 만한 청사진이다.
핵심 요약 (20줄)
- 스트라이프가 비개발직군을 위한 지식 AI 플랫폼 Kai(Knowledge AI Platform)를 소개했다.
- 코딩 에이전트는 엔지니어링을 바꿨지만 영업·재무 등 비개발직군은 소외돼 있었다.
- Kai는 데이터 웨어하우스 조회, 영업 콜 전 리서치, 인시던트 트리아지, 매출 모델링, 컴플라이언스 검토 등을 지원한다.
- 4월 출시 2주 만에 스트라이프 대부분이 Kai를 사용하기 시작했고, 현재 83%가 주간 활성 사용자다.
- Kai 사용자 대부분은 여러 턴에 걸쳐 심층 리서치를 하거나 산출물을 다듬는다.
- 코딩 작업은 도구·워크플로우가 균일해 단일 에이전트로 충분하지만 지식 노동은 도메인마다 다 달라 그렇지 않다.
- Kai 이전에는 NoCode 에이전트 빌더(4,000개 이상 생성)와 코딩 에이전트라는 두 옵션이 있었지만 각각 한계가 있었다.
- NoCode 빌더는 품질 편차와 관리 부담을, 코딩 에이전트는 보안 우려와 지원 부담을 낳았다.
- Kai 설계의 핵심 과제는 전문성의 중앙화 없는 확장, 어디서나 동작하는 유연성, 코드에 없는 가드레일 강제였다.
- 핵심 불변 조건 예시로 "관련 없는 두 고객 맥락이 한 세션에 섞여선 안 된다"는 규칙이 있다.
- Kai는 서피스 애그노스틱 API, AgentStudio, 실행 환경의 3계층 구조로 구축됐다.
- 대부분의 스트라이프 구성원은 내부 웹 앱으로 Kai를 쓰고, 다른 내부 도구에도 API로 임베드할 수 있다.
- AgentStudio는 도메인 오너가 자신들의 Kai 에이전트, 스킬, 도구 선택을 만들고 모니터링하는 컨트롤 플레인이다.
- 실행 환경은 LangChain deepagents 기반 에이전트 하네스로, 쿠버네티스와 세션별 샌드박스, 가상 파일시스템을 사용한다.
- 실행 환경 인프라는 스트라이프의 제품용 외부 에이전트와 공유되어 동일한 보안·컴플라이언스 기준을 유지한다.
- Kai 세션은 최근 932턴까지 상태를 유지한 사례가 있으며, 1,000개 이상의 내부 스킬·도구에 연결되어 있다.
- GTM 신입은 Kai를 2.7배 더 사용하고, 파워 유저는 저사용 유저보다 80% 더 많은 가치를 만든다.
- Kai 사용 시 영업 담당자는 영업 활동 2배, 매출 기회 26%↑, 거래 성사 39%↑ 등 성과가 뚜렷하게 개선됐다.
- Kai는 연간 25,000시간을 관리 업무에서 매출 창출 업무로 전환시켰고, 매일 5,000건 이상 세션이 데이터 분석에 쓰인다.
- 스트라이프는 상태 관리, 자기 성찰형 개선 루프, 세션 간 협업 프리미티브를 향후 개선 과제로 꼽았다.