How Stripe Built Kai, its Company-Wide AI Agent, on Deep Agents

요약

Stripe의 사내 에이전트 Kai를 LangChain 쪽에서 기술한 사례 연구다. Meet Stripe's Knowledge AI Platform이 플랫폼 구조와 도입 성과를 다룬다면, 이 글은 그 아래 한 층을 더 내려가 Deep Agents가 제공한 미들웨어가 무엇이었고 그것이 개발 속도와 운영 한계에 어떻게 작용했는지를 다룬다.

핵심 주장은 두 가지다. 첫째, Deep Agents가 tool call 루프, 미들웨어 조합, 스트리밍, 상태 관리를 이미 해결해 두었기 때문에 엔지니어 한 명이 일주일 만에 Kai 초기 버전을 만들 수 있었다. 둘째, 그 결과 남은 어려운 문제는 에이전트 인프라가 아니라 1,000개가 넘는 스킬 중에서 올바른 것을 고르는 일이다.

이 글에만 있는 정량 정보가 셋 있다. 스킬 frontmatter의 1,024자 제한, 스킬이 150개를 넘으면 최신 모델의 품질이 떨어지기 시작했다는 관찰, 그리고 500개가 넘는 사내 MCP 도구 규모다. 벤더 쪽 사례 연구라 Deep Agents 채택 효과를 강조하는 관점이 들어 있다는 점을 감안하고 읽는다.

배경

Stripe에서 agentic AI 도입이 빨라지면서 여러 엔지니어링 팀이 기존 Ruby와 Java 스택 위에 각자 오케스트레이션 계층을 만들기 시작했다. 사내 인프라와의 연동 자체는 비교적 수월했지만, 프로덕션 품질의 harness를 만드는 일은 별개의 난관이었다.

문제는 연결성이 충분조건이 아니라는 데 있다. 효과적인 에이전트 시스템에는 성능, 견고한 평가, 복잡한 과제를 일관되게 처리하는 능력이 함께 필요하다. 팀들의 초기 구현은 단순한 사용 사례에서는 작동했지만 규모에서 신뢰할 만한 결과를 내려면 추가 투자가 필요했다.

2024년 말 Claude Code가 나오면서 Stripe 직원 모두가 에이전트를 만들고 싶어 했다. 그러나 비개발자에게는 터미널, 데이터 접근, 보안 구성 요소가 큰 장벽이었다. Agent Foundation 팀 EM인 Sharadh Krishnamurthy와 Staff Software Engineer인 Anupam Upadhyay는 방향을 뒤집었다. 비기술직을 개발자 도구 쪽으로 끌어오는 대신, 그들이 있는 자리로 목적에 맞게 만든 것을 가져가자는 것이다. 글은 그 질문을 "모두가 항상 켜져 있는 프로덕션 수준의 비서를 갖는다면 어떨까"로 옮긴다.

핵심 개념

Deep Agents는 LangChain이 공개한 오픈소스 agent harness다. harness는 모델을 감싸 도구, 검증, 상태를 제공하는 실행 환경을 말하고, Deep Agents는 그중에서도 tool call 루프, 미들웨어 조합, 스트리밍, 상태 관리를 기본으로 제공한다.

미들웨어는 harness의 기본 루프에 끼워 넣어 파일 접근, 샌드박스 실행, 요약 같은 기능을 더하는 교체 가능한 구성 요소다. Kai가 일주일 만에 만들어질 수 있었던 이유를 글은 이 미들웨어를 기성품으로 조합했다는 데서 찾는다.

스킬은 특정 작업 절차를 담아 에이전트에 결합하는 지침 패키지다. Deep Agents의 스킬은 에이전트가 실행할 수 있는 구조화된 모듈이고, 각 스킬이 특정 과제를 어떻게 수행하는지, 어떤 도구를 불러올지, 한 부류의 작업에 어떻게 접근할지를 담는다.

MCP는 모델이 외부 도구와 데이터 원천에 표준화된 방식으로 접근하게 하는 프로토콜이다. Stripe는 사내 도구 500개 이상을 MCP로 노출하고 있어서, 도구를 전부 컨텍스트에 올리지 않고 고르는 문제가 곧바로 생긴다.

방법

Kai가 어떤 제품인가

Kai는 전 직원이 쓸 수 있고, 대부분의 Stripe 직원이 실제로 하는 업무에 맞춰 만들어졌다. 그 업무는 데이터 종합, 브레인스토밍, 문서 초안 작성, 추세 분석, 직능 간 협업이다. 이 모든 것이 세션 기반 인터페이스 하나에서 일어나고, 그 인터페이스는 사내 데이터 웨어하우스와 Slack, Google Suite에 연결돼 있다.

사용 흐름은 다음과 같다. 사용자가 세션을 시작하고 채팅으로 상호작용하면 Kai가 산출물, 리포트, 대시보드, 문서를 만들어 대화 옆에 둔다. 대화가 이어지면 그 산출물이 함께 갱신된다. 글은 이것이 비개발자를 위한 코딩 에이전트처럼 동작한다고 표현한다.

범용 AI 비서와의 차이는 사전 적재된 맥락이다. Kai에는 도구와 스킬을 통해 Stripe 맥락이 미리 들어가 있어서, 사용자가 과제마다 자기 직무나 회사를 설명할 필요가 없다. 100개 이상 팀의 전문가가 1,000개가 넘는 스킬로 도메인 지식을 기여한다.

Deep Agents 위의 네 계층

계층을 이렇게 나눈 이득을 Sharadh는 이렇게 요약한다. "Deep Agents 계층이 Stripe답지 않은 문제를 전부 해결해 주니 우리는 Stripe다운 에이전트 문제에 집중할 수 있다. 미들웨어를 기성품으로 가져다 쓸 수 있고, 조합 가능한 스킬 패턴과 복합 백엔드가 올바른 구조를 주면서도 유연성은 충분히 남긴다."

글은 Deep Agents가 엮어 주는 요소를 처음부터 만들어 안정화하려면 몇 달이 걸린다고 적는다. 그 기간이 일주일로 줄어든 것이 이 사례의 중심 수치다.

계층을 나눈 실무 효과는 변경의 파급 범위에 나타난다. 도메인 팀이 자기 에이전트의 스킬 구성이나 페르소나를 바꿀 때 설정 계층만 건드리므로 harness를 다시 배포할 필요가 없다. 반대로 플랫폼 팀이 보안 정책이나 인프라 연동을 바꿀 때는 harness 계층만 고치면 그 위의 모든 맞춤 에이전트에 반영된다. Stripe 자신의 발표문이 말하는 Agent Studio가 바로 이 설정 계층을 사람이 쓰는 화면으로 만든 것이다.

프로덕션 투입을 가능하게 한 세 미들웨어

세 미들웨어는 각각 로컬 코딩 에이전트가 환경에서 공짜로 얻던 것을 클라우드 서비스에서 다시 만들어 준다.

filesystem 미들웨어. Kai는 로컬 프로세스가 아니라 클라우드에서 구동되는 프로덕션 서비스다. 로컬 코딩 에이전트가 당연하게 쓰는 디스크가 없다는 뜻이다. Stripe는 S3를 백엔드로 하는 가상 파일 시스템을 만들어 에이전트가 턴 사이에 파일을 컨텍스트로 읽고 쓰고 참조하게 했다.

파일 시스템이 LLM 컨텍스트에 잘 맞는 이유로 글이 드는 것은, 파일 시스템이 컨텍스트를 모델이 검사하고 갱신하고 시간에 따라 정리할 수 있는 대상으로 바꿔 준다는 점이다. 대화 이력은 모델이 고칠 수 없지만 파일은 고칠 수 있다.

샌드박스 실행 호출은 전부 sync in / sync out 패턴으로 감싼다.

그 결과 에이전트와 에이전트를 구동하는 LLM은 세션 전체 수명에 걸쳐 일관되고 지속되는 파일 환경을 경험한다. 샌드박스가 매번 새로 뜨고 사라져도 파일은 이어진다.

샌드박스 미들웨어. Kai는 두 종류의 작업을 샌드박스 환경에서 실행한다. 하나는 분석 작업으로, 데이터를 질의(query)하고 차트를 만드는 Python 코드를 쓰고 실행하는 일이다. 다른 하나는 PDF, 프레젠테이션, 구조화 문서 같은 임의 파일 형식의 처리다.

설계상 가장 중요한 결정은 샌드박스를 에이전트에게 도구로 노출하고, 에이전트 자신의 실행 환경으로 삼지 않은 것이다. 에이전트는 샌드박스 바깥에서 구동되면서 안쪽을 호출한다. 이렇게 하면 실행 경계가 깨끗하게 유지되고, LLM이 생성한 코드와 관련된 한 부류의 보안 문제를 막을 수 있다. 원문은 이 지점에서 lethal trifecta 논의를 링크한다.

요약 미들웨어. 여러 턴이 길게 이어지는 세션에서 쌓인 컨텍스트가 성능을 떨어뜨리거나 모델 한계에 부딪히는 것을 막는 데 필수적이다. Kai는 특히 긴 다중 턴 세션을 잘 다룬다. 사용 가능한 컨텍스트를 최대한 쓰면서 비용과 균형을 맞추기 위해 deepagents 라이브러리가 제공하는 조정 항목을 활용한다. 요약 시작 임계값, 요약 담당 모델, 출력 크기 등이다.

비용 논리도 함께 적혀 있다. 대부분의 사용자가 Kai 세션을 띄엄띄엄 쓰기 때문에, 큰 컨텍스트에서 캐시 미스가 나는 것을 피하는 것이 비용 통제에 도움이 된다. 즉 요약은 품질 유지 수단인 동시에 prompt caching을 살리는 수단이다.

스킬과 도구 로딩

Stripe는 각 팀이 자기 스킬을 소유하고 유지하는 연합형 방식을 택했다.

500개가 넘는 사내 MCP 도구와 계속 늘어나는 skill library를 전부 컨텍스트에 실을 수는 없다. 그래서 Agent Skills의 allowedTools 목록이 동적 도구 로딩을 구동한다. 스킬 선택이 도구 컨텍스트를 결정하는 2단계 방식이라, 모든 도구를 미리 올리지 않는다.

이 설계의 요점은 판단을 한 번만 한다는 데 있다. 선택은 이미 관련 맥락을 갖고 있는 LLM에 맡긴다. Anupam의 표현으로는 "LLM이 어떤 스킬을 불러올지 알아내는 데 이미 노력을 쓰고 있으니, 관련 도구를 로딩하는 일도 그 판단에 기대는 것"이다.

2단계 로딩의 흐름은 다음과 같다.

도구를 고르는 두 번째 판단을 LLM에 다시 시키지 않는다는 점이 요점이다. 스킬 하나를 고르는 순간 그 스킬이 선언한 도구가 따라오므로, 500개가 넘는 도구 설명을 매번 컨텍스트에 올릴 이유가 사라진다.

일부 기초 스킬은 고정되어, 모델이 무엇을 로딩하거나 내리기로 하든 유지된다. Stripe 맥락과 정책 동작이 항상 일관되게 유지되도록 하기 위해서다. 즉 동적 로딩이 컨텍스트를 아끼는 방향으로만 작동해 필수 지침까지 떨어뜨리는 일을 막는 안전장치다.

Python 스택 전환

Stripe는 10년 넘게 Ruby와 Java를 중심으로 사내 도구, 보안 계층, 배포 지원을 쌓아 왔다. Python 네이티브 스택을 채택한다는 것은 사내 서비스 스캐폴딩을 새 언어로 다시 세운다는 뜻이고, 이는 큰 투자였다.

Kai는 그 투자 회수를 실증으로 증명했다. 엔지니어 한 명이 일주일 만에 Kai를 만들었고, Deep Agents의 기본 요소 덕에 어려운 에이전트 인프라가 이미 해결된 상태였기 때문이다. Head of AI Platform인 Chrissie는 "Kai가 Deep Agents가 맞는 길이라는 믿음을 완전히 굳혔다"고 말한다.

결과

확산 곡선

마케팅과 GTM 같은 비즈니스 직능의 사용 비율이 엔지니어링보다 높다는 점을 글은 강조한다. 이들은 Kai를 딜 준비에 쓰면서 여러 사내 소스에서 데이터를 끌어와 종합하고 쓸 수 있는 산출물을 만드는 과정이 크게 달라졌다고 말한다. 재무 조직은 데이터 분석과 대시보드 생성에 같은 정도로 유용하게 쓴다.

신규 사용자의 대부분은 팀이 설계 대상으로 삼았던 직무였다. 영업, 재무 분석, 비즈니스 운영 담당자, 즉 "AI를 쓰라"는 요구를 받았지만 자기 업무 방식에 맞는 도구를 찾지 못했던 직원들이다. Sharadh가 전하는 반응은 이렇다. "이전 것은 다가가기 어려웠다. 여러 설정을 조정해야 했다. 하지만 AI를 쓰라는 요구를 받았고 정말 노력했다. 그런데 이건 좋다. 그런 걸 전혀 할 필요가 없다."

인용된 사용자 평가는 다음 둘이다.

• "Kai는 영업 담당자에게 정말 믿기 어려울 정도다. 수만 시간이 절약될 것이다."
• "내 Stripe 커리어는 Kai 이전과 이후로 나뉜다."

확산 속도를 해석할 때 눈여겨볼 것은 도입 목표를 분기 단위로 잡았는데 일주일 만에 채웠다는 점이다. 이는 수요가 이미 존재했는데 진입 장벽 때문에 막혀 있었다는 신호로 읽을 수 있다. 앞서 배경 절이 말한 "AI를 쓰라는 요구를 받았지만 자기 업무 방식에 맞는 도구를 찾지 못했던" 직원들이 그 대기 수요다.

신규 입사자는 온보딩을 빠르게 하는 데 Kai를 쓰기 시작했다. 비개발자를 위해 Kai를 만든 엔지니어링 팀도 자기 업무의 보조 도구로 쓰게 됐다. 자기 시스템에 관한 질문에 답하게 하거나, 자기 trace와 사용 데이터를 Kai로 분석해 스킬의 빈틈을 찾고 커버리지를 넓히는 식이다.

스킬 규모에서 관찰한 한계

이 글의 가장 구체적인 정량 관찰이고, Stripe 자신의 발표문에는 없는 내용이다.

1,024자와 150개를 곱하면 약 15만 자다. 즉 스킬 설명만으로 시스템 프롬프트에 그만한 분량이 쌓이는 지점에서 모델의 판단 품질이 떨어지기 시작했다는 뜻이다. 실제 스킬 수가 이미 1,000개를 넘었으므로 전량 로딩은 처음부터 불가능하고, 이것이 동적 로딩을 필수로 만든다.

글은 스킬 개수가 여전히 과제로 남아 있고 팀이 더 나은 해법을 찾는 중이라고 적는다.

한계

글이 밝힌 다음 과제는 네 가지다.

스킬 선택 항목은 이 저장소 관점에서 특히 눈여겨볼 판정이다. 현 시점에서는 순수 LLM 선택이 RAG보다 낫다는 결론인데, 이는 전체 후보를 컨텍스트에 넣을 수 있다는 전제 위에서만 성립한다. 그 전제가 깨지는 규모부터 prefilter가 필요해진다.

개인화에 대해 Sharadh는 "이 제품의 약속 자체가 조정 항목을 만질 필요가 없다는 것"이라며, 따라서 그 판단을 대신 해 주는 지능을 만드는 책임을 팀이 떠안았다고 말한다.

자료 자체의 한계는 다음과 같다.

• 벤더 쪽 사례 연구다. LangChain이 자사 Deep Agents 채택 효과를 소개하는 맥락이므로 실패한 시도나 대안 harness와의 비교는 나오지 않는다.
• "일주일"의 범위가 명시되지 않는다. 엔지니어 한 명이 일주일에 만든 것은 초기 버전이고, 그 뒤 프로덕션 harness와 Agent Studio를 세우는 데 든 노력은 이 글에 없다.
• 비용과 지연 시간 수치가 없다. 캐시 미스 회피가 비용 통제에 도움이 된다는 서술은 있지만 실제 비용은 나오지 않는다.
• 품질 저하 관찰의 측정 방법이 없다. 스킬 150개 초과에서 품질이 떨어졌다는 관찰이 어떤 eval로 측정된 것인지 밝히지 않는다.
• 본문 도식이 없다. 원문에 구조 도식이 하나도 없어 이 페이지에도 임베드할 그림이 없다. 구조 도식은 Meet Stripe's Knowledge AI Platform의 실행 환경 그림을 참고한다.

핵심 용어

관련 페이지

• Meet Stripe's Knowledge AI Platform: 같은 시스템의 Stripe 쪽 발표문. 세 계층 구조, 도입 성과 수치, 데이터 격리 규칙이 그 글에 더 자세하다
• Stripe의 사내 업무용 AI 플랫폼, Kai (GeekNews): 한국어 요약과 Hacker News 반응
• Agent Skills Overview (agentskills.io): allowedTools를 포함한 Agent Skills 규약
• Generative Skill Composition for LLM Agents: 스킬 선택과 조합 문제를 학술 쪽에서 다룬 연구
• MCP Server Architecture Patterns for LLM-Integrated Applications: 500개 규모의 MCP 도구를 다루는 구조 논의
• headroom: AI 에이전트 컨텍스트 압축 도구: 요약 미들웨어가 다루는 컨텍스트 압축 문제
• Awesome Harness Engineering: Deep Agents가 harness 변경만으로 Terminal Bench 순위를 끌어올린 사례를 담고 있다