코딩 에이전트는 Stripe의 엔지니어링을 변화시켰지만, 영업 담당자, 재무 분석가, 기술 계정 매니저(TAM) 등 비엔지니어들은 Claude Code와 Codex가 이끄는 AI 물결에서 소외되었다고 느꼈습니다. Stripe에 필요한 데이터 보안 요구사항과 특정 워크플로우(데이터 웨어하우스 쿼리, 영업 콜 전 계정 조사, 인시던트 트리아지, 수익 시나리오 모델링, 컴플라이언스 검토 준비)를 처리할 수 있는 기존 도구는 없었습니다. 그러던 중 Stripe의 지식 AI 에이전트(Kai)를 출시하면서 모든 것이 바뀌었습니다.
GIF
4월 출시 후 2주 만에 Stripe 직원 대부분이 Kai라고도 알려진 Stripe의 Knowledge AI Platform을 사용하기 시작했습니다. 현재 83%가 주간 활성 사용자이며, 여기에는 GTM(마케팅, 영업, 고객 성공 매니저, 기술 계정 매니저)의 거의 전원이 포함됩니다. 대부분의 Kai 세션은 많은 턴(turn)을 필요로 합니다. 사용자는 심층 조사를 수행하고, 특정 산출물을 만들거나, 내부 또는 외부에 공유하기 전에 자산을 다듬습니다. Kai를 통해 Stripe의 모든 직원은 일상 업무를 돕기 위해 특별히 구축된 에이전트를 갖게 되었습니다.
Knowledge AI Platform을 구축한 이유
코딩 작업의 경우 구체적인 변경 사항은 다양하지만, 작업을 수행하는 데 필요한 워크플로우와 도구는 거의 동일합니다. 파일을 편집하고, 테스트를 실행하고, 커밋합니다. 프로그래밍 언어는 다양하지만 작업의 형태는 상당히 균일하기 때문에 단일 에이전트 아키텍처가 잘 작동합니다. 지식 작업은 그 반대편에 있습니다. 계정 조사나 컴플라이언스 검토 준비와 같은 작업은 서로 다른 도구, 서로 다른 데이터, 서로 다른 출력, 그리고 서로 다른 '완료'의 정의를 요구합니다.
Kai 이전에는 지식 작업을 위한 두 가지 AI 옵션이 있었습니다:
- NoCode Agent Builder: 누구나 도구를 사용할 수 있는 워크플로우별 에이전트를 구축하고 배포할 수 있었습니다. 이 시스템을 사용하여 4,000개 이상의 에이전트가 구축되었습니다. 그러나 곧 팀들이 개념적으로 유사한 프롬프트를 품질 수준은 제각각으로 작성하고 있다는 것을 발견했고, 이러한 마이크로 에이전트의 급증을 모니터링하고 유지 관리하기가 점점 더 어려워진다는 것을 알게 되었습니다.
- 코딩 에이전트: 코딩 에이전트는 강력했지만 다른 종류의 위험을 도입했습니다. Stripe 전체의 생산성 향상을 목표로 했기 때문에, 일부 사용자는 워크플로우를 변경하여 코딩 에이전트를 선택했습니다. 그러나 곧 보안 문제가 대두되었고, 이전에 비엔지니어를 지원한 적이 없었던 코드 품질 팀에 새로운 지원 부담이 생겼습니다.
이러한 경험을 통해 우리는 지식 AI 플랫폼을 구축하려면 세 가지를 제대로 해야 한다는 것을 깨달았습니다. 즉, 전문성을 중앙화하지 않고 확장하고, 사용자가 일하는 곳 어디에서나 만나고, 코드에는 존재하지 않는 가드레일을 강제하는 것입니다.
전문성을 중앙화하지 않고 확장하기
Stripe 사용자를 지원하는 데 필요한 전문성의 범위는 어마어마합니다. 결제 에스컬레이션을 트리아지하거나 수익 시나리오를 모델링하는 방법을 아는 사람들은 한곳에 모여 있지 않으며, 에이전트 인프라를 구축하는 팀에도 당연히 없습니다. 그들은 GTM, Finance, Marketing, Legal, Data Science 등 수십 개의 전문 도메인에 분산되어 있으며, 각 도메인은 고유한 도구, 데이터 소스, 워크플로우, 그리고 '좋은 결과'에 대한 기준을 가지고 있습니다. 여기에 Stripe가 운영하는 모든 제품과 국가를 곱하면 결과는 놀라울 정도로 복잡해집니다. Kai는 이러한 복잡성을 사용자가 인지하지 못하도록 모델링하여 작업이 그냥 작동하도록 해야 합니다.
에이전트는 사용자를 찾아가야 합니다
에이전트가 무엇을 아는지만큼이나 에이전트가 어디에 표시되는지도 중요합니다. 모든 사람이 브라우저 탭에서 일하는 것은 아니며, 터미널에서 일하는 사람은 더욱 적습니다. 따라서 지식 에이전트는 단일 제품일 수 없습니다. 작업이 발생하는 모든 곳에 임베드될 수 있을 만큼 유연한 플랫폼이어야 합니다.
예를 들어, Finance 팀이 Stripe 운영 예산의 복잡한 변경을 모델링하는 데 사용하는 내부 애플리케이션을 생각해 보겠습니다. 에이전트는 사용자를 앱 밖으로 끌어내지 않고도 컨텍스트를 읽고, 관련 문서를 조사하고, 유효한 변경 사항을 제안하고, 차이점을 요약해야 합니다.
독립형 에이전트 제품을 구축하는 것은 효과가 없습니다. 사용자를 자연스러운 워크플로우에서 강제로 끌어내어 새로운 앱으로 이동시키게 될 것이기 때문입니다. 각 표면(surface)에 대해 별도의 에이전트 제품을 구축하는 것도 효과가 없습니다. 유지 관리가 어렵고, 여러 도구를 사용하는 사용자는 분절된 경험을 하게 될 것입니다. 플랫폼은 사용자가 있는 곳에서 만나야 합니다.
가드레일을 처음부터 구축하기
코딩 에이전트는 수십 년간 축적된 빠르고 검증 가능한 가드레일이 있는 환경에서 작동합니다. 컴파일러는 잘못된 구문을 거부하고, 테스트는 회귀를 발견하며, git은 모든 실수를 되돌릴 수 있게 합니다. 지식 작업에는 이러한 구조를 지원하는 도구가 거의 없습니다.
Stripe의 핵심 불변 조건(invariant)을 생각해 보겠습니다: "서로 관련 없는 두 고객 컨텍스트의 데이터를 단일 분석에 결합해서는 안 된다"는 것입니다. 사용자가 두 컨텍스트 각각에 대해 합법적인 접근 권한을 가지고 있을 수 있지만, 두 컨텍스트가 동일한 세션에 나타날 수는 없습니다. 격리 경계는 "이 사람이 권한 토큰을 기반으로 무엇에 접근할 수 있는가"가 아니라 "이 컨텍스트에서 이 작업이 무엇을 볼 수 있도록 허용되어야 하는가"입니다. 플랫폼은 사용자가 의존하는 이러한 암묵적 가드레일을 강제해야 합니다.
Kai를 구축한 방법
단일 모놀리식 에이전트로는 이러한 모든 제약 조건을 효과적으로 인코딩할 수 없습니다. 또한 모든 도메인 팀이 각자 보안, 호스팅, 성능을 갖춘 에이전트 인프라를 독립적으로 구축하도록 하는 것도 확장 가능한 방식이 아닙니다. 이 문제를 해결하기 위해 Kai를 세 개의 레이어로 구축했습니다:
- 표면에 구애받지 않는 API(Surface-agnostic APIs): 동일한 에이전트에 여러 인터페이스를 제공합니다
- AgentStudio: 도메인 소유자가 자신의 Kai 에이전트를 구축하고 관리합니다
- 실행 환경: 누구도 인프라에 대해 생각할 필요 없이 몇 초 만에 보안을 제공합니다
표면에 구애받지 않는 API
Kai는 명확한 설계 철학을 가진 웹 애플리케이션과 Slack 통합을 제공하지만, 핵심 기본 요소는 이 둘을 모두 구동하는 기본 API입니다. 에이전트는 애플리케이션이 아니라 서비스이며, 표면(surface)은 단순히 그 서비스를 바라보는 맞춤형 뷰입니다.
대부분의 Stripe 직원은 내부 호스팅 웹 애플리케이션을 통해 Kai와 상호작용합니다. 설정할 인프라가 없으며, 입사 첫날부터 모든 직원이 사용할 수 있습니다.
모든 내부 도구에 Kai를 임베드할 수도 있으며, 많은 도구가 이미 이렇게 하고 있습니다. 예를 들어 비즈니스 인텔리전스 플랫폼에서 작업하는 직원은 기존 애플리케이션 안에서 Kai에게 질문할 수 있습니다. Chrome 확장 프로그램이 웹 기반 타사 도구 내부에 Kai 기능을 표시하기 때문입니다.
커스텀 애플리케이션은 API를 통해 Kai를 임베드하여 모든 워크플로우에 에이전트 경험을 제공합니다
AgentStudio
AgentStudio는 도메인 소유자를 위한 컨트롤 플레인입니다. 팀은 AgentStudio를 사용하여 스킬, 커스텀 Kai 에이전트, 도구 선택을 구축, 테스트, 모니터링합니다. 예를 들어 GTM 팀은 자체 워크플로우에 맞게 조정된 Kai 에이전트를 보유합니다. 기본적으로 해당 팀의 스킬을 로드하고, 해당 팀의 데이터 소스에 연결하며, 사용자가 기대하는 형식으로 출력을 제공합니다. AgentStudio는 각 에셋과 함께 사용 데이터와 품질 신호를 표시하므로 도메인 소유자는 플랫폼 팀에 문의하지 않고도 무엇이 효과가 있는지 확인할 수 있습니다.
스킬은 Stripe 전반의 영역별로 구성되며 도메인 전문가가 관리합니다
실행 환경
이 레이어가 플랫폼의 약속을 현실로 만듭니다. 에이전트 하네스(harness), 샌드박스, 워크플로우 오케스트레이션, 접근 제어 프레임워크를 포함한 핵심 기본 요소는 의도적으로 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는 연간 25,000시간을 행정 업무에서 매출 창출 업무로 전환하는 데 기여했습니다.
금융 및 운영 분야에서 Kai는 Stripe 직원이 정리되지 않은 데이터를 분석하고, 정기 다이제스트를 생성하며, 단편화된 컨텍스트를 유용한 산출물로 전환하는 것을 돕고 있습니다.
엔지니어링 분야에서 Kai는 이제 시스템 질문, 실행 요청(run request) 조사, 로그 분석, 계획 초안 작성, 더 전문화된 에이전트와 스킬 호출을 위한 자연스러운 도구가 되었습니다.
또한 Stripe 전반에서 매일 5,000개 이상의 세션이 데이터 분석을 중심으로 이루어집니다. 이는 Kai를 독특한 레버리지 포인트로 만들어 줍니다. 데이터 품질과 분석 레이어에 대한 올바른 컨텍스트를 연결함으로써 대부분의 질문에 대해 기본적으로 정확한 응답을 보장할 수 있습니다.
Stripe 직원들의 직접적인 피드백도 이러한 수치를 뒷받침합니다. 그들은 "AI를 받아들이도록 힘을 얻었다"고 느끼고 "Kai가 정확하게 해내는 것에 놀랐다"고 보고합니다. 하지만 우리가 가장 좋아하는 일화는 Kai 소개 세션을 마치고 즉시 Asana, Slack, Jira를 하나의 자동화된 프로세스로 통합하는 다이제스트를 협업하여 만든 비엔지니어의 이야기입니다.
아직 승리하지 못했습니다
Stripe에서 우리가 가장 좋아하는 표어 중 하나는 "우리는 아직 승리하지 못했습니다(we haven't won yet)"이며, 이는 Kai에 그대로 적용됩니다. 우리는 이 여정의 초기 단계에 있으며, 하고 싶은 일이 훨씬 더 많습니다:
- 더 나은 상태 관리: Kai와 같은 범용 에이전트는 도구 호출을 반복하고, 대용량 문서를 가져오는 등의 과정에서 많은 상태를 생성합니다. 우리는 LLM에 전송되는 '활성' 컨텍스트와 S3 또는 가상 파일시스템과 같은 상태 저장소에 있는 '확장' 컨텍스트를 지속적으로 튜닝하고 있습니다.
- 반성과 자기 개선: Kai가 스킬과 관련된 트레이스를 반성하고, 개선 사항을 제안하고, 테스트하고, 스킬 소유자가 검토할 수 있도록 변경 사항을 제출하는 품질 개선 루프를 구축 중입니다.
- 더 나은 협업 기본 요소: 사용자는 Kai 세션에서 현재 '잠겨 있는' 많은 컨텍스트를 생성하지만, 실제 작업은 그런 방식으로 이루어지지 않습니다. 우리는 사람들이 Kai가 세션 전반에 걸쳐 표시하는 내용을 공유하고, 여러 사람(그리고 에이전트!)이 동일한 산출물에서 협업할 수 있도록 하고 싶습니다.
코딩 에이전트는 먼저 소프트웨어 엔지니어에게 AI를 실감나게 만들었습니다. Kai는 Stripe 전반의 지식 근로자에게 동일한 레버리지 감각을 제공하는 데 기여했습니다. 생산성을 상당히 개선했지만 아직 한계를 모르기 때문에 흥미롭습니다. 그리고 우리는 계속해서 한계를 넓혀나가는 것에 기대하고 있습니다. 내부 생산성과 외부 에이전트를 모두 구동하는 에이전틱 시스템 구축이 당신에게 흥미로운 도전으로 들린다면, 우리는 채용 중입니다.
