Stripe의 회사 두뇌 Kai — 전사 AI의 성패는 모델 밖에서 결정된다
📺 원본 영상: Stripe built a company brain: Meet Kai
🎙️ 채널: How I AI
📅 정리 일자: 2026-09-09
⚠️ Note: 본 리포트는 영상 음성 변환 텍스트를 바탕으로 작성된 내용을 공개 전사본과 대조해 검수했다. 원본 음성을 직접 재청취하거나 화면에 표시된 차트, 코드, 슬라이드의 세부 내용을 확인하지는 않았다. STT에서 CHI 등으로 혼재한 제품명은 영상 제목과 문맥에 따라 Kai로 통일했으며, 발언자 이름은 공개 에피소드 소개에 따라 Sharadh Krishnamurthy로 교정했다. 제공된 스크린샷 목록에는 webUrl 없이 로컬 경로만 있어 이미지는 삽입하지 않았다.
개요
Stripe의 엔지니어링 매니저 Sharadh Krishnamurthy가 소개하는 Kai는 직원의 질문에 답하는 사내 챗봇을 넘어, 조직의 맥락을 이해하고 실제 업무 도구를 사용하는 회사 차원의 에이전트다. 인터뷰는 대시보드 생성 시연을 따라가면서 개인화된 맥락, 프로젝트별 실행 정책, 데이터 접근 경로, 재사용 가능한 스킬이 어떻게 연결되는지 설명한다. 이 사례에서 핵심은 특정 모델의 지능보다, 그 지능이 조직 안에서 올바른 데이터를 선택하고 적절한 권한으로 행동하도록 만드는 운영 구조에 있다.
직접 만든 이유 — AI 접근권보다 어려운 것은 회사의 일하는 방식을 담는 일이다
Sharadh에 따르면 Kai의 출발점은 직원 모두에게 AI를 제공하려는 문제의식이었다. 강력한 AI 도구가 잇따라 등장하는 상황에서 단순히 도구 하나를 더 만드는 이유는 명확하지 않았다. 그러나 여러 국가와 제품, 수많은 업무 절차가 얽힌 Stripe에서는 모델을 사용할 수 있게 하는 것만으로 문제가 해결되지 않았다. 직원마다 필요한 정보와 허용되는 행동이 다르기 때문에, AI가 회사의 업무 구조 안에서 적절하게 작동하도록 만드는 일이 더 큰 과제로 떠올랐다.
이 때문에 Kai의 자체 개발 근거는 거버넌스(Governance), 조직 맥락, 기존 인프라와의 통합으로 모인다. Sharadh는 직원이 매번 모델과 연결 도구, 데이터 접근 방식을 판단하기보다, 시스템이 해당 업무에 맞는 조건을 제공해야 한다고 설명한다. Kai는 클라우드에서 상시 실행되며 Stripe의 표준 보안 경계 안에 배치된다. 다만 인터뷰에서는 구체적인 네트워크 구성이나 인증 체계, 데이터 보존 정책까지 공개하지 않으므로, 이 설명을 특정 보안 구현이 검증되었다는 의미로 확대할 수는 없다.
자체 구축에는 내부 사용 경험을 고객 제품 개발로 연결하려는 목적도 있다. Sharadh는 Kai를 만드는 데 쓰인 기반 요소가 Stripe의 표준 인프라로 이어지고, 궁극적으로 고객을 위한 에이전트 제품에도 도움이 된다고 말한다. 진행자는 이를 자사가 만든 기술을 직접 사용하는 도그푸딩(Dogfooding)의 사례로 해석한다. 이 관점에서 Kai는 직원 생산성 도구이면서, 실제 업무의 복잡성과 실패를 통해 에이전트 기반 기술을 시험하는 사용처이기도 하다.
개인화된 맥락 — 조직도는 기본으로, 민감한 정보는 사용자가 선택한다
Kai가 기본적으로 아는 정보는 사용자의 신원과 조직도상 위치다. 여기에 현재 날짜와 시간 같은 기본 맥락이 더해지고, 연결된 프로젝트 관리 도구를 통해 목표 및 핵심 결과인 OKR, 최근 출시 관련 공유 내용, 참여 프로젝트 등을 찾아볼 수 있다. 이 구조에서는 같은 질문도 누가 물었는지에 따라 해석에 필요한 배경이 달라진다. 예컨대 특정 프로젝트에 대한 요청을 이해할 때 사용자의 소속과 참여 관계를 참고할 수 있다는 것이 Sharadh가 설명하는 개인화의 핵심이다.
그러나 조직 맥락을 이해한다는 말이 모든 개인 정보를 항상 수집한다는 뜻은 아니다. Google Drive나 Slack, 민감한 비공개 메시지에 대한 접근은 사용자가 선택할 수 있다고 설명한다. Sharadh 자신도 세션이나 날짜에 따라 접근을 켰다 끄는 사용자라고 밝힌다. 더 많은 맥락을 지속적으로 제공하는 직원도 있지만, Kai는 이러한 선택의 차이를 수용하는 방식으로 소개된다.
이 설명에서 중요한 구분은 기본 신원 정보와 선택적으로 연결하는 업무 정보 사이에 있다. 조직도상 위치를 아는 것과 개인의 비공개 대화까지 읽는 것은 다른 범위의 접근이며, 사용자는 후자의 범위를 조절할 수 있다. 인터뷰만으로는 이 정보가 매 요청에 모두 포함되는지, 필요할 때 조회되는지, 별도 저장되는지까지 알 수 없다. 따라서 Kai의 개인화를 이해할 때는 조직 맥락을 활용한다는 기능적 설명과 공개되지 않은 저장·검색 구현을 구분해야 한다.
프로젝트 — 채팅 폴더를 넘어 업무의 실행 조건을 설정한다
Kai에서 프로젝트는 대화와 파일을 모아두는 정리 기능보다 넓은 역할을 한다. Sharadh는 프로젝트를 사용자가 무엇을 하려는지 명시적으로 알려주는 강한 의도 신호이자, 해당 업무에 필요한 통제를 묶는 단위로 설명한다. 프로젝트에는 소수의 직원이 참여할 수도 있고 수백 명이 참여할 수도 있으며, 단기 과제나 지속적인 팀 업무에 맞춰 만들 수 있다. 중요한 것은 구성원의 수보다 그 안에서 어떤 도구와 스킬을 사용하고 어떤 조건으로 행동할지를 정할 수 있다는 점이다.
모델 선택도 이 경계 안에서 관리할 수 있다. 특정 업무에 고비용 모델이 필요하지 않다면 기본 모델을 정하고, 불필요하게 비싼 모델을 사용하지 않도록 설정할 수 있다는 설명이다. 이는 비용 절감만을 위한 기능이 아니라, 모델의 성능과 지연 시간, 비용 사이의 판단을 일부 담당자가 대신 수행하도록 하는 구조다. Sharadh는 이러한 선택을 매일 직접 해야 하는 사람의 수를 줄이는 것이 중요하다고 강조한다.
프로젝트는 사용할 에이전트 자체도 바꿀 수 있다. 범용 Kai 대신 별도의 API와 에이전트 실행 체계인 하네스(Harness)를 연결하면서, 같은 플랫폼 기능을 활용할 수 있다고 설명한다. 인사팀을 위한 프로젝트는 별도로 보안을 강화한 백엔드를 사용하는 사례로 언급된다. 따라서 Kai는 하나의 화면으로 보이더라도, 내부적으로는 서로 다른 업무 요구에 맞춰 여러 계층을 조합하는 플랫폼에 가깝다.
여기서 읽을 수 있는 설계적 함의는 조직의 책임 단위와 AI의 설정 단위를 맞추는 것이 중요하다는 점이다. 해당 업무를 잘 아는 담당자가 적합한 실행 조건을 정하면, 다른 직원은 매번 설정의 의미를 해석하지 않고도 일을 시작할 수 있다. 다만 프로젝트가 존재한다고 해서 내부 권한 문제가 자동으로 해결되는 것은 아니다. 인터뷰가 보여주는 것은 이러한 판단을 담을 관리 단위이며, 세부 권한 상속이나 정책 충돌 해결 방식까지는 설명하지 않는다.
대시보드 생성 — 도구, 스킬, 샌드박스가 역할을 나눈다
첫 번째 주요 시연에서 Sharadh는 Kai의 도입 현황을 보여주는 대시보드를 요청한다. 그는 사내 데이터 질의 계층인 Hubble에서 평소 사용하는 쿼리를 찾고, 그 결과를 대시보드로 만들어 달라고 지시한다. Kai는 곧바로 관련 도구와 스킬을 탐색하고, Stripe의 데이터 및 SQL 질문을 처리하는 Ask Data 스킬을 불러온다. 사용자가 내부 도구의 호출 순서를 직접 나열하는 대신, 업무 요청에 맞는 실행 지식을 시스템이 찾아 적용하는 흐름이다.
Sharadh는 도구를 실제로 수행할 수 있는 행동으로, 스킬을 관련 도구와 사용 지식을 묶어 발견하기 쉽게 만드는 수단으로 설명한다. 이 시연에서 Ask Data는 단순한 SQL 작성 지침을 넘어, 회사의 표준 데이터 도구로 질문에 답하는 경로를 안내한다. 스킬을 발견하는 기능 자체도 하네스에 제공되는 도구 중 하나다. 즉 에이전트는 업무 도구를 사용하는 것뿐 아니라, 어떤 업무 지식을 불러올지도 도구를 통해 결정한다.
코드 실행은 클라우드의 세션별 샌드박스(Sandbox)에서 이루어진다. Kai가 개인 노트북에서 실행되는 구조가 아니므로, 서로 다른 사용자의 세션이 간섭하지 않도록 실행 공간을 분리해야 한다는 설명이다. 하네스에는 데이터를 샌드박스로 보내고, 내부에서 검색이나 처리를 수행하고, 결과를 꺼내는 도구가 제공된다. 사용자는 샌드박스의 존재나 에이전트가 작성한 스크립트의 세부 내용을 몰라도 이러한 기능을 이용할 수 있다.
이 구조는 기술적 실행 능력을 비개발자의 업무에도 연결한다. 사용자는 자신이 원하는 결과를 설명하고, 에이전트는 필요한 데이터 조회와 코드 실행을 수행해 결과물을 만든다. 다만 인터뷰에는 실제 코드나 격리 기술, 실행 자원 한도에 관한 설명이 없으므로 이를 재구성할 근거는 부족하다. 확인 가능한 핵심은 세션별 실행 공간과 데이터 입출력 도구를 플랫폼 차원에서 제공한다는 점이다.
데이터 에이전트의 정확도 — SQL을 쓰기 전에 신뢰할 경로를 찾는다
진행자는 데이터 조회와 시각화가 많은 회사의 첫 내부 에이전트 사용처라며, 기존 데이터 환경을 어떻게 준비해야 하는지 묻는다. Sharadh는 Stripe가 이미 질의 계층과 데이터 플랫폼에 상당한 투자를 해왔다고 답한다. 음성에서 명시적으로 언급되는 기술은 Trino이며, 데이터 카탈로그와 데이터 품질 등급, 스키마 정보도 중요한 기반으로 제시된다. 다만 Trino에 대한 언급만으로 전체 웨어하우스의 저장 구조나 처리 구성을 특정할 수는 없다.
Kai의 데이터 접근에서 중요한 것은 기존에 검증된 경로를 먼저 활용한다는 원칙이다. 이미 만들어진 보고서나 대시보드, 공인된 분석 계층을 이용할 수 있다면 이를 우선하고, 충분하지 않을 때 데이터 카탈로그에서 적합한 데이터셋을 찾아 직접 쿼리를 구성한다. 이는 모델이 SQL을 문법적으로 잘 작성하는 문제와, 회사가 의도하는 지표를 정확히 계산하는 문제가 다르기 때문이다. Sharadh는 에이전트가 질문에 대한 답을 만들어도 올바른 테이블과 쿼리를 사용했는지는 모를 수 있다고 지적한다.
세부 탐색 순서에는 음성 설명상 차이가 있다. Sharadh는 한 대목에서 분석 계층 다음으로 표준 대시보드의 쿼리를 언급하지만, 스킬을 설명하는 부분과 진행자의 정리에서는 기존 결과물을 먼저 찾고 분석 계층을 활용하는 흐름이 강조된다. 따라서 이 인터뷰만으로 첫 두 단계의 순서를 모든 경우에 적용되는 고정 규칙으로 확정하기는 어렵다. 공통적으로 드러나는 원칙은 검증된 결과물과 분석 정의를 먼저 재사용하고, 원천 데이터에 대한 직접 탐색을 뒤로 미룬다는 것이다.
Ask Data 스킬에는 이러한 접근 방식에 대한 데이터 전문가의 판단이 담긴다. Sharadh에 따르면 데이터 과학자들이 대부분의 질문을 어떤 순서로 처리해야 하는지 정리했고, 이를 에이전트가 활용하도록 만들었다. 스킬은 모델이 없던 데이터 지식을 만들어내는 장치라기보다, 조직이 축적한 올바른 접근법을 실행 과정에 전달하는 장치다. 이는 사람이 쓰기 좋게 정리한 데이터 자산이 에이전트의 오류 가능성을 줄이는 기반이 된다는 설명으로 이어진다.
인프라 안정성 — 에이전트는 기존 장애 요인을 증폭한다
데이터 정확성과 별개로, 에이전트의 요청량을 감당하는 문제도 중요하다. 진행자는 에이전트가 확신이 없을 때 대량의 질의를 통해 답을 찾으려 할 수 있다고 지적한다. Sharadh 역시 초기 운영 과정에서 에이전트가 예상 밖으로 행동했고, 핵심 시스템을 거의 중단시킬 뻔한 상황도 있었지만 제때 발견했다고 설명한다. 기존 인프라 투자가 도움이 되었음에도 실제 문제가 발생했으며, 이를 계기로 시스템을 더 강화했다는 이야기다.
Sharadh가 강조하는 관점은 에이전트가 기존 실패 양상의 강도를 키운다는 것이다. 사람이 사용하는 환경에서 감당할 수 있었던 비효율이나 반복 요청이 자동화된 실행에서는 더 큰 부하로 나타날 수 있다는 의미로 읽힌다. 인터뷰에서는 구체적인 사고 원인이나 요청량, 복구 시간은 공개하지 않는다. 따라서 이를 특정 장애 유형으로 단정하기보다, 에이전트 도입이 기존 안정성 가정을 다시 점검하게 만들었다는 경험으로 이해하는 편이 정확하다.
이 문제와 관련해 Sharadh는 에이전트 정체성(Agentic Identity)을 언급한다. 요청이 에이전트에서 발생했다는 사실뿐 아니라, 어떤 사용 목적을 위해 실행되는지 식별해 우선순위와 부하 차단인 로드 셰딩(Load Shedding)에 활용하려는 방향이다. 다만 그는 이 문제를 아직 완전히 해결하지 못했다고 명시한다. 따라서 완성된 기능으로 소개하기보다, 운영 경험을 통해 중요성이 드러난 설계 과제로 보아야 한다.
진행자는 개발자 경험과 데이터 플랫폼에 대한 기존 투자가 AI 활용의 기반이라고 평가한다. 개발자 경험 팀과 데이터 팀을 확대하라는 조언도 하지만, 이는 진행자의 견해이며 인터뷰에서 검증한 보편적 인력 산정 공식은 아니다. 사례가 뒷받침하는 것은 사람이 일하기 좋은 환경을 만들기 위한 투자가 에이전트에도 도움이 되었다는 점이다. 동시에 그 기반 위에서도 에이전트 특유의 부하와 행동을 다루는 추가 작업이 필요했다는 사실을 놓쳐서는 안 된다.
결과물과 함께 일하기 — 한 번 생성한 대시보드를 계속 발전시킨다
Kai가 만든 첫 대시보드는 상호작용할 수 있고 관련 링크를 포함한다고 설명된다. Sharadh는 생성이 쉬워져 회의마다 대시보드를 만들어 활용한다고 말한다. 그러나 그가 더 강조하는 부분은 첫 결과물을 받은 이후다. 사용자는 기존 대시보드에 추가 분석과 구분을 요청하고, 에이전트는 같은 결과물을 수정하며 작업을 이어간다.
Sharadh는 이러한 반복 작업을 토큰 효율과 협업 경험의 관점에서 설명한다. 매번 HTML 대시보드 전체를 버리고 새로 만드는 대신, 이미 만들어진 결과물을 바탕으로 필요한 부분을 발전시킨다는 것이다. 수주에 걸쳐 수백 차례 상호작용이 이어지는 작업도 있다고 말한다. 다만 이것이 전체 대화 내용을 항상 그대로 모델에 넣는다는 뜻은 아니며, 장기 맥락 유지나 결과물 저장 방식은 공개되지 않는다.
이 방식이 겨냥하는 영역은 마지막 단계의 데이터 활용, 즉 라스트마일 데이터(Last-mile Data)다. 회사가 공통 지표를 잘 제공하더라도, 특정 회의나 업무 흐름에 필요한 가공과 표현까지 모두 표준 대시보드로 준비하기는 어렵다. Sharadh는 모든 요구에 대응하는 대시보드를 만들다 보면 수가 지나치게 늘고 품질 관리가 어려워진다고 설명한다. Kai는 공통 데이터 기반을 활용하면서도, 개인이나 팀이 필요한 작은 앱과 분석 화면을 그때그때 만들도록 돕는다.
💡 [영상 참조] 24분대에는 기존 대시보드에 추가 분석 구간을 반영한 결과를 설명한다. 음성만으로는 차트 종류, 부서별 값, 집계식의 세부 내용을 확인할 수 없으므로 원본 영상의 해당 구간을 참조해야 한다.
확산의 과정 — 작은 초기 팀 뒤에는 큰 기반 투자가 있었다
Kai의 초기 버전은 Sharadh와 동료가 약 1.5명 규모의 투입으로 2주 동안 만들었다고 설명된다. 그는 말로 필요성을 설득할 때보다 실제 작동하는 V0를 보여준 뒤 많은 질문의 답이 분명해졌다고 회고한다. 이후 시장 진출과 영업·마케팅 활동을 담당하는 GTM(Go-to-market) 조직에서 관심이 커졌고, 약 200~300명이 참여하는 파일럿으로 이어졌다. 이 다음 약 한 달의 단계에서는 투입 인원이 약 2.5~3명 수준이었다고 말한다.
전사 확산의 계기는 회사 전체를 대상으로 한 시연이었다. Sharadh에 따르면 이후 사용량이 빠르게 늘었으며, 인터뷰 시점에는 매주 1만 명 이상이 사용하고 있었다. 핵심 사용자 경험을 관리하는 팀은 여전히 10명 미만이지만, 이들이 Kai만 담당하는 것은 아니라고 설명한다. 그는 동시에 기존 인프라와 개발 도구, 다른 팀의 지원이 없었다면 이러한 규모를 감당할 수 없었을 것이라고 공을 돌린다.
| 항목 | 음성에서 언급된 규모 | 해석 시 유의점 |
|---|---|---|
| 초기 V0 개발 | 약 1.5명, 2주 | 초기 버전 구축에 관한 회고이며 전체 플랫폼 비용이 아니다 |
| 파일럿 사용자 | 약 200~300명 | 전사 공개 이전 단계의 규모다 |
| 파일럿 단계 투입 | 약 2.5~3명, 이후 약 한 달 | 초기 개발 다음 단계에 대한 대략적 설명이다 |
| 회사 내 사용 비중 | 86% 이상 | 산정 기간과 활성 사용자 기준은 명시되지 않았다 |
| 주간 사용자 | 1만 명 이상 | 인터뷰 시점의 발언이며 현재 수치로 일반화할 수 없다 |
| 핵심 경험 관리 팀 | 10명 미만 | 기존 플랫폼 조직과 지원 인력 전체를 포함하는 수치가 아니다 |
| 전체 스킬 | 약 2,000개 | 모두가 전사적으로 자주 쓰인다는 뜻은 아니다 |
위 수치는 공개 전사본의 21분대, 25~27분대, 30분대 발언과 일치해 유지했다. 원문에 [?] 표기는 없으며, 전사본 대조에서 수치 불일치는 발견되지 않았다. 다만 원본 음성을 직접 재청취한 검증은 아니다. 공개 전사본
이 수치들은 Kai의 도달 범위와 개발 속도를 보여주지만, 그 자체로 투자수익률이나 생산성 향상률을 입증하지는 않는다. 인터뷰에는 사용자당 절약 시간, 전체 운영비, 오류 감소율을 비교한 자료가 제공되지 않는다. 특히 작은 핵심 팀 규모를 독립적인 총비용으로 해석하면 이전부터 축적된 플랫폼 투자를 빠뜨리게 된다. 이 사례의 성과는 소수 인력만으로 모든 것을 새로 만들었다는 주장보다, 기존 기반을 활용해 새로운 사용자 경험을 빠르게 확장했다는 데 있다.
도구 정책 — 승인 여부를 업무의 맥락에 연결한다
프로젝트별 도구 정책(Tool Policies)을 설명할 때 Sharadh는 인사팀의 민감한 정보를 예로 든다. 에이전트가 해당 정보를 전 직원이 접근 가능한 Google 문서에 옮긴다면 문제가 되지만, 민감한 업무라는 이유로 모든 도구를 금지하는 것도 바람직하지 않다는 설명이다. 여기서 말하는 공개 범위는 문맥상 회사 구성원 전체에 대한 접근이며, 인터넷 전체 공개로 단정할 수는 없다. 핵심은 데이터가 원래의 접근 경계를 넘어 이동할 수 있다는 위험이다.
Kai는 프로젝트 안에서 특정 도구에 사람의 확인을 요구하도록 설정할 수 있다. 시연에서는 캘린더 초대 생성 요청을 통해 휴먼 인 더 루프(Human-in-the-loop) 흐름을 보여준다. 중요한 기능은 승인 창 자체보다, 업무 담당자가 어떤 행동을 민감하게 취급할지 정할 수 있다는 점이다. 같은 도구라도 그 프로젝트에서 다루는 데이터와 업무에 따라 실행 조건이 달라질 수 있다.
진행자는 이러한 구조가 개인 설정을 모든 세션에 일괄 적용하는 방식과 다르다고 해석한다. 팀이나 과제의 목적에 맞는 경계를 설정하고 여러 사용자가 함께 활용할 수 있기 때문이다. Sharadh는 모든 세션의 모든 도구에 확인을 요구하면 마찰이 커지고, 결국 사용자가 잘못된 버튼을 누를 수 있다고 지적한다. 따라서 승인 횟수를 늘리는 것만으로 안전을 확보하려 하기보다, 실제로 판단이 필요한 행동에 확인 절차를 배치하려는 설계 의도가 드러난다.
시연 중에는 도구 정책을 너무 엄격하게 설정했다는 언급도 나온다. 이는 통제가 실제 실행에 영향을 미친다는 점과 동시에, 정책을 과도하게 적용하면 정상적인 작업도 막힐 수 있음을 보여준다. 다만 인터뷰는 정책 엔진의 구현이나 정보 유출 방지 효과를 체계적으로 검증한 자료를 제공하지 않는다. 확인할 수 있는 범위는 프로젝트별로 도구 실행 조건을 정하고, 필요한 작업에 사람의 승인을 연결한다는 것이다.
스킬 생성 — 성공한 대화를 반복 가능한 업무로 바꾼다
대시보드를 원하는 형태로 다듬었다면, 다음번에도 같은 시행착오를 반복할 필요는 없다. Sharadh는 매번 토큰과 시간을 들여 같은 결과물을 다시 구성하는 대신, 현재 세션에서 배운 내용을 스킬로 묶을 수 있다고 설명한다. 스킬 생성 스킬(Skill Creator Skill)은 대화 과정과 사용자의 요구를 바탕으로 재사용 가능한 업무 지침을 만든다. 이는 대화형 실험을 반복해서 활용할 수 있는 워크플로로 전환하는 단계다.
생성된 스킬에는 설명과 사용 조건이 채워지고, 사용자는 이를 개인용으로 유지하거나 더 넓은 영역에 공유할 수 있다. 인터뷰에서는 공개된 표준 규격을 따르는 스킬로 소개하지만, 규격명이나 버전은 명시하지 않는다. 또한 초안 편집 화면을 통해 테스트와 수정, 관리를 할 수 있는 경험이 강조된다. Sharadh는 개발 환경인 IDE(Integrated Development Environment)와 비슷한 편의성을 비개발자에게도 제공하려고 투자했다고 설명한다.
시연은 모든 단계가 매끄럽게 끝나는 형태는 아니다. 이미 만들어둔 스킬이 있어 초안 내보내기 과정이 잠시 꼬이고, 이후에는 방금 만든 스킬을 자연어 요청으로 다시 찾는 흐름을 보여준다. 따라서 전체 과정이 오류 없이 자동 완성되었다고 묘사하는 것은 부정확하다. 그럼에도 사용자가 스킬 이름이나 파일 위치를 명시하지 않아도, 최신 도입 현황 대시보드를 요청하는 말에서 관련 스킬을 선택하는 동작이 설명된다.
이 기능의 의미는 업무 지식의 작성 주체를 넓힌다는 데 있다. 반복 작업의 요구를 가장 잘 아는 사람이 반드시 개발자는 아니지만, Kai에서는 누구나 자신의 작업 과정을 스킬로 만들 수 있다고 소개된다. 다만 스킬로 포장되었다는 사실만으로 업무 정확도나 실행 성공률이 보장되는 것은 아니다. 공유와 재사용가 늘어날수록 검색 품질과 유지 관리가 중요해지는 이유가 여기에 있다.
스킬 플랫폼 — 많이 만드는 것만큼 무엇을 불러올지가 중요하다
Sharadh는 코딩 에이전트와 전사 업무 에이전트의 중요한 차이로 자연스러운 작업 계층의 유무를 든다. 코딩에서는 저장소와 폴더 구조가 현재 작업과 관련된 지침을 찾는 단서가 되지만, 일반 업무는 여러 시스템에 걸쳐 진행된다. 따라서 회사 전체를 지원하는 에이전트는 현재 요청에 적합한 스킬을 별도로 탐색하고 선택해야 한다. Kai에서 스킬 패키징과 검색에 많은 투자가 들어간 이유다.
약 2,000개의 스킬이 존재하는 환경에서는 모든 스킬을 같은 수준으로 노출하는 방식이 적절하지 않다. Sharadh는 전사에서 매일 집중적으로 쓰이는 스킬이 약 50개이고, 조직의 일부에서 사용하는 스킬이 약 100~150개 더 있다고 설명한다. 두세 명이 사용하는 도구나 소규모 팀만의 작업 방식도 존중해야 한다고 덧붙인다. 사용자가 적다는 이유만으로 가치가 없다고 판단할 수는 없지만, 그 내용을 모든 업무의 공통 맥락에 넣을 필요도 없다.
Kai는 사용 현황을 수집하는 텔레메트리(Telemetry)를 통해 어떤 스킬을 일반적인 업무 흐름으로 올리고, 어떤 스킬을 더 좁은 영역으로 옮길지 판단한다고 설명한다. Sharadh는 관련 처리를 수행하는 ETL(Extract, Transform, Load) 파이프라인이 있다고 언급하지만 화면으로 보여주지는 않는다. 플랫폼이 스킬 작성자에게 개선 제안을 제공하는 기능도 소개된다. 다만 구체적인 평가 지표, 테스트 데이터, 자동 수정 범위까지는 음성으로 확인되지 않는다.
진행자가 제시하는 미사용 스킬의 폐기 절차는 구분해서 읽어야 한다. 일정 기간 호출되지 않은 스킬에 알림을 보내고, 반응이 없으면 단계적으로 보관하거나 삭제하는 방식은 다른 조직에서 관찰한 사례이자 질문이다. Sharadh는 Kai에 텔레메트리가 있고 스킬 노출 범위를 조정한다고 답하지만, 진행자가 언급한 기간과 자동 삭제 절차를 그대로 운영한다고 확인하지는 않는다. 따라서 이를 Stripe의 확정된 스킬 폐기 정책으로 옮겨 적어서는 안 된다.
이 대화에서 도출되는 핵심은 스킬의 양과 질이 서로 연결된다는 점이다. 현재 요청과 무관한 맥락을 지나치게 제공하면 적절한 행동을 선택하기 어려워진다는 것이 Sharadh의 설명이다. 그렇다고 소수 사용자의 전문 스킬을 없애야 한다는 뜻은 아니다. 전사 공통 지식과 팀·개인의 전문 지식을 적절한 범위에서 발견하도록 만드는 일이 스킬 플랫폼의 운영 과제가 된다.
남아 있는 과제 — 높은 보급률과 완성된 시스템은 다른 문제다
인터뷰 말미에 Sharadh는 Stripe가 모든 문제를 해결한 것은 아니며, 여정의 매우 초기 단계에 있다고 강조한다. 이는 앞서 공개한 높은 사용률과 모순되지 않는다. 많은 직원이 활용하는 제품도 요청의 우선순위, 부하 관리, 스킬 품질과 검색 같은 문제에서는 계속 개선이 필요할 수 있기 때문이다. 실제로 인터뷰에는 초기 인프라 사고 경험과 엄격한 정책으로 작업이 막히는 장면이 함께 등장한다.
개인적 활용 사례에서는 일정과 해야 할 일을 알려주는 보조 역할이 언급된다. Sharadh는 Kai의 스케줄 기능을 개인 비서처럼 사용하며, 기억해야 할 일을 머릿속에 모두 담아두지 않아도 되는 점을 큰 효용으로 꼽는다. 다만 이 기능은 시연하지 않았으므로, 외부 이벤트 감지 방식이나 예약 실행 구조를 구체적으로 설명할 근거는 없다. 음성에서 확인되는 것은 업무 누락을 줄이기 위한 알림과 보조 용도로 사용한다는 경험이다.
이 마지막 사례는 Kai의 가치가 복잡한 대시보드 생성에만 있지 않음을 보여준다. 일부 업무에서는 코드 실행과 분석이 중요하지만, 다른 업무에서는 필요한 순간에 할 일을 상기시키는 것이 더 유용할 수 있다. 기업용 에이전트가 담당해야 할 작업의 형태가 다양하다는 사실은 프로젝트별 설정과 서로 다른 하네스를 지원하는 설계와도 연결된다. 다만 이러한 연결은 인터뷰의 여러 설명을 종합한 해석이며, 모든 기능의 효과를 정량적으로 검증했다는 뜻은 아니다.
마무리 / 핵심 정리
Kai 사례가 보여주는 것은 전사 AI의 품질이 모델 호출 이후의 구조에 크게 의존한다는 점이다. 직원의 역할을 이해하는 맥락, 검증된 데이터에 먼저 접근하는 스킬, 코드를 실행하는 분리된 공간, 업무 목적에 따라 달라지는 도구 정책이 함께 있어야 실제 업무를 맡길 수 있다. Sharadh의 설명에서 자체 구축의 이유도 이러한 조직별 요구를 담는 데 있다. 따라서 이 사례를 모든 회사가 사내 에이전트를 직접 만들어야 한다는 결론으로 일반화하기보다, 도입하려는 제품이 자사의 업무 경계를 얼마나 잘 표현하는지 판단하는 기준으로 읽는 편이 타당하다.
스킬 플랫폼은 개인이 성공한 작업을 조직이 재사용할 수 있는 자산으로 바꾸는 역할을 한다. 그러나 공유가 시작되면 작성 기능만으로는 충분하지 않고, 적합한 스킬의 검색과 품질 개선, 노출 범위 관리가 뒤따라야 한다. 동시에 작은 핵심 팀의 빠른 실행 뒤에는 데이터 플랫폼과 개발 인프라에 대한 오랜 투자가 있었다. Kai의 성과는 이러한 기반을 재사용한 결과이며, 발언자가 인정하듯 안정성과 운영 방식은 여전히 발전 중이다.
📚 출처 및 참고
이 리포트는 인터뷰 STT를 바탕으로 기술적 설명을 재구성한 원고를 공개 전사본과 대조해 검수했으며, 광고와 본론에 직접 관계없는 잡담은 제외했다. 도입 규모와 개발 인원, 사용 경험은 인터뷰 시점의 발언으로 취급했고 현재 상태를 별도로 확인하지 않았다. 설계적 함의는 발언 내용과 구분해 서술했으며, 화면에만 있을 수 있는 수치와 코드는 보완하지 않았다.
| 구분 | 내용 |
|---|---|
| 원본 영상 | Stripe built a company brain: Meet Kai |
| 채널 | How I AI |
| 주요 발언자 | Stripe 엔지니어링 매니저 Sharadh Krishnamurthy — 공개 에피소드 소개 기준 |
| 제공된 STT 범위 | 00:00~50:17 |
| 리포트 작성 | 2026-09-09 |
| 작성 방식 | 제공된 리포트의 문맥 교정 및 공개 전사본 대조 |
| 해석 범위 | 전사된 발언에 한정하며 원본 음성 재청취, 화면 세부 정보 확인 및 비공개 구현 검증은 수행하지 않음 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었다. 정확한 발언과 시연 화면은 원본 영상을 참조해야 한다.