Stripe Kai가 보여준 사내 AI 플랫폼 설계법

[!IMPORTANT] 한 줄 브리핑: Stripe의 사내 AI 플랫폼 Kai는 부서별 전문성과 중앙 플랫폼을 결합해 비개발자 업무를 지원한다. 핵심은 에이전트 숫자가 아니라 권한·도구·품질 기준을 함께 운영하는 구조다.
분야: IT/AI/Security

30초 요약

Stripe는 영업, 재무, 고객 성공, 규정 준수 등 비개발자 업무를 지원하는 사내 AI 플랫폼 Kai를 구축했다. Kai는 웹과 Slack 등 기존 업무 환경에서 사용할 수 있도록 설계됐다. Stripe Japan 보도자료
기존에는 직원들이 만든 에이전트가 4,000개 이상으로 늘었지만, 비슷한 프롬프트와 도구 연결이 반복되고 품질·유지보수 관리가 어려워졌다. Kai는 이 문제를 공통 실행 기반과 부서별 전문성의 결합으로 풀려는 시도다. GeekNews 정리
공개된 자료에 따르면 Kai는 1,000개 이상의 스킬과 도구를 연결하고, 권한이 있는 사용자라도 서로 무관한 고객 데이터가 한 세션에서 섞이지 않도록 격리하는 구조를 갖췄다. GeekNews 정리
Stripe가 공개한 내부 비교 결과는 영업 활동량 2배, 계약 성사 건수 39% 증가, 연간 약 25,000시간의 행정 업무 절감이다. 다만 이는 Stripe가 제시한 내부 비교 결과이므로 다른 조직에 그대로 적용되는 성과로 해석해서는 안 된다. Stripe Japan 보도자료

핵심 시사점은 “직원마다 에이전트를 하나씩 만들자”가 아니다. 반복되는 실행·보안·관찰 기능은 플랫폼으로 통합하고, 업무의 의미와 완료 기준은 해당 부서가 관리해야 한다는 운영 원칙이다.

확인된 사실

1. Kai가 해결하려 한 문제

Stripe는 코딩 업무와 지식 업무의 차이를 구분했다. 코딩 에이전트는 파일 수정, 테스트 실행, 저장·커밋처럼 비교적 공통적인 흐름을 공유한다. 반면 고객 계정 조사, 매출 시나리오 분석, 인시던트 분류, 규정 준수 검토 같은 지식 업무는 과제마다 필요한 데이터와 도구, 결과물, 완료 기준이 달라진다. GeekNews 정리

Kai 이전에는 비개발자가 노코드 에이전트 빌더를 이용하거나 코딩 에이전트를 직접 익혀야 했다. 노코드 방식은 접근성이 높았지만 유사한 프롬프트가 부서별로 중복됐고, 에이전트 수가 늘면서 모니터링과 유지보수가 어려워졌다. 코딩 에이전트는 강력할 수 있지만 비개발자의 업무 방식과 보안 요구를 바로 충족하는 선택지는 아니었다. Stripe Japan 보도자료

2. 중앙 플랫폼과 분산된 전문성의 결합

Kai는 모든 업무를 플랫폼 팀이 직접 설계하는 방식이 아니다. 청구 에스컬레이션, 매출 모델링, 법무 검토, 데이터 분석처럼 업무의 맥락과 판단 기준을 가장 잘 아는 팀이 자신의 스킬과 도구를 만들고 관리하는 구조를 지향한다. 플랫폼 팀은 공통 실행 환경과 보안 장치를 제공하고, 각 부서는 업무 전문성을 제공하는 식이다. GeekNews 정리

LangChain의 공개 설명에 따르면 Kai는 LangChain·LangGraph 스택과 Deep Agents 에이전트 하네스 위에 구축됐다. 여기서 하네스는 에이전트가 장시간 작업을 수행할 때 필요한 도구 호출, 상태 관리, 파일 처리 같은 실행 공통 기능을 묶은 기반으로 이해할 수 있다. LangChain 사례 소개

3. 여러 업무 표면에서 같은 에이전트 사용

Kai는 별도 애플리케이션으로 사용자를 이동시키기보다 웹 앱, Slack, 기존 사내 도구에 에이전트를 연결하는 방향을 취했다. 예를 들어 재무 담당자가 예산 모델링 화면에서 관련 문서를 조사하거나 변경안을 제안받고 변경점을 요약하는 식이다. GeekNews 정리

공개 자료에는 API, AgentStudio, 실행 환경이라는 세 계층이 제시된다. LangChain의 설명은 이를 더 넓게 나눠 Deep Agents 기반 계층, Stripe 전용 에이전트 계층, 설정 계층, 사용자 인터페이스 계층으로 설명한다. 표현 방식은 다르지만 공통적으로 “모델 호출”만이 아니라 스킬 등록, 실행, 사용자 접점, 내부 시스템 연계를 하나의 운영 체계로 묶었다는 점을 보여준다. GeekNews 정리 LangChain 사례 소개

4. 공개된 도입·성과 수치

Stripe Japan의 자료는 Kai가 GTM, 즉 마케팅·영업·고객 성공 등 고객 접점 부문의 주간 사용률 83%에 이르렀다고 설명한다. 같은 자료는 도입 후 영업 활동량 2배, 계약 성사 건수 39% 증가, 연간 25,000시간의 업무 효율화를 제시한다. Stripe Japan 보도자료

다만 자료만으로는 사용률의 정확한 모집단과 측정 기간, 활동량의 정의, 성사 건수 변화에 영향을 준 다른 요인, 통제군 구성까지 확인할 수 없다. 따라서 이 수치들은 “사내 도입 효과에 대한 Stripe의 공개 주장”으로 기록하는 것이 정확하다.

실무 판단

에이전트 수보다 ‘공통 기반’이 먼저다

4,000개의 에이전트가 있다는 사실은 자동화 수요가 크다는 신호이지, 운영이 성숙했다는 뜻은 아니다. 비슷한 업무가 서로 다른 프롬프트와 권한 설정으로 구현되면 다음 문제가 생긴다.

같은 질문에 대한 결과 품질이 팀마다 달라진다.
데이터 구조나 API가 바뀔 때 여러 에이전트를 따로 수정해야 한다.
어떤 에이전트가 어떤 데이터를 조회했는지 추적하기 어렵다.
문제가 발생했을 때 프롬프트, 도구, 모델, 원천 데이터 중 원인을 좁히기 어렵다.

따라서 조직이 먼저 투자할 대상은 화려한 에이전트 카탈로그가 아니라 인증, 권한 확인, 도구 호출 기록, 실행 상태, 평가, 중단 기능이다. 업무별 스킬은 그 위에서 추가해야 한다.

중앙집중과 현업 자율성은 양자택일이 아니다

플랫폼 팀이 모든 업무를 만들면 현업 맥락이 빠지고, 현업이 모두 독립적으로 만들면 중복과 보안 편차가 커진다. Kai에서 읽을 수 있는 운영 원칙은 경계를 나누는 것이다.

중앙 플랫폼이 책임질 것: 모델 연결, 실행 환경, 사용자 인증, 데이터 접근 정책, 로그, 비용·성능 모니터링
부서가 책임질 것: 업무 목적, 사용할 원천 데이터, 결과물 형식, 완료 기준, 사람이 검토해야 하는 조건
공동으로 책임질 것: 테스트 질문 세트, 오류 처리, 변경 승인, 폐기 기준

이 구분이 있어야 “누구나 만들 수 있다”와 “아무렇게나 배포할 수 있다”를 분리할 수 있다.

성공 지표는 사용률 하나로 부족하다

주간 사용률은 확산 여부를 보여주지만 업무 품질이나 위험 감소를 보장하지 않는다. 조직에서 파일럿을 평가할 때는 최소한 다음 세 종류를 함께 측정하는 편이 낫다.

측정 영역	확인할 질문	예시 지표
채택	실제 업무 흐름에서 반복 사용되는가?	주간 활성 사용자, 재사용률
생산성	시간이 줄었는가, 아니면 검토 시간이 늘었는가?	작업 완료 시간, 수작업 단계 수
품질·위험	결과가 정확하고 권한을 지키는가?	승인 오류율, 근거 누락률, 권한 위반 차단 건수

영업 활동이나 계약 성사처럼 결과 지표를 보려면 비교 기간과 대상, 계절성, 담당자 구성까지 함께 기록해야 한다. 그렇지 않으면 AI의 효과와 시장 상황 또는 프로세스 변경의 효과를 구분하기 어렵다.

업무에 어떻게 쓸까

1단계: ‘반복되지만 판단은 필요한’ 업무를 고른다

처음부터 전사 지식 검색을 만들기보다 한 부서의 반복 업무 하나를 고른다. 후보는 다음 조건을 만족해야 한다.

입력과 결과물의 형태가 어느 정도 정해져 있다.
사람이 매번 여러 시스템을 오가며 조사한다.
최종 승인자는 명확하다.
잘못된 결과를 사람이 검토하고 중단할 수 있다.
데이터 접근 권한을 사용자별로 구분할 수 있다.

예를 들어 영업 전 고객 브리핑, 재무 보고서 초안, 내부 정책 문서의 관련 조항 찾기처럼 조사와 초안 작성이 중심인 업무가 초기 후보가 될 수 있다. 반대로 고객에게 자동으로 가격을 확정하거나 법적 의무를 최종 판단하는 업무는 초기 자동화 범위에서 제외하는 편이 안전하다.

2단계: 에이전트가 아니라 스킬 명세부터 작성한다

다음 템플릿을 복사해 부서 담당자와 플랫폼 담당자가 함께 작성한다.

[업무 스킬 명세]
목적:
사용자:
입력 데이터와 출처:
허용된 도구/API:
금지된 데이터와 행동:
결과물 형식:
완료의 정의:
반드시 사람이 확인할 항목:
오류·불확실성 표시 방식:
실행 중단 조건:
로그에 남길 항목:
폐기 또는 재검토 주기:

여기서 중요한 항목은 “좋은 답변”이 아니라 완료의 정의다. 예를 들어 고객 브리핑의 완료를 “요약문 생성”으로 정의하면 근거 없는 문장이 통과할 수 있다. “최근 자료 세 건 이상에 연결하고, 각 핵심 주장에 출처와 확인 시점을 표시하며, 빈 정보는 모른다고 표시한다”처럼 검증 가능한 조건으로 써야 한다.

3단계: 좁은 권한으로 실행한다

파일럿에서는 읽기 전용 데이터와 제한된 문서 저장 공간만 연결한다. 고객 데이터, 재무 데이터, 인사 데이터처럼 민감도가 다른 원천을 하나의 세션에 무제한으로 연결하지 않는다. 사용자가 시스템 접근 권한을 갖고 있다는 이유만으로 모든 업무 맥락의 데이터를 함께 보여줘도 된다는 뜻은 아니다.

실행 환경에는 다음 방어선을 둔다.

사용자 신원과 원천 시스템의 권한을 모두 확인한다.
스킬마다 허용 데이터 범위와 도구를 선언한다.
다른 고객·프로젝트·국가의 데이터가 섞이지 않도록 세션과 작업 공간을 분리한다.
외부 전송, 대량 다운로드, 원본 수정은 기본적으로 차단하거나 별도 승인을 요구한다.
결과물에 사용한 문서, 쿼리, 도구 호출, 실패 내역을 남긴다.

4단계: 2주 동안 기준선과 함께 비교한다

도입 전 1~2주 동안 같은 업무의 평균 소요 시간, 재작업 횟수, 오류 유형을 기록한다. 이후 파일럿 사용 기간에는 AI 사용 여부만 비교하지 말고 같은 담당자·같은 업무 유형·비슷한 난이도를 기준으로 본다.

중단 조건도 사전에 정한다. 예를 들어 출처 없는 핵심 사실이 일정 비율 이상 발생하거나, 권한이 없는 문서가 검색 결과에 나타나거나, 사람이 결과를 검토하는 시간이 기존보다 늘어나면 자동화를 확대하지 않고 원인을 조사한다. 성과가 좋아 보여도 보안 위반 한 건이 발견되면 해당 스킬을 즉시 비활성화하는 식의 우선순위가 필요하다.

5단계: 재사용 가능한 공통 기능을 추출한다

첫 파일럿이 끝나면 스킬 자체보다 반복된 기반 기능을 찾는다. 인증, 문서 검색, 표 형식 출력, 근거 표시, 파일 생성, 승인 요청, 로그 수집이 여러 업무에서 반복된다면 이를 공통 컴포넌트로 만든다. 반대로 업무의 전문 판단 기준은 공통 프롬프트로 억지로 합치지 말고 부서별 설정으로 남긴다.

실행 체크리스트

시작 전

업무의 담당자, 최종 승인자, 데이터 소유자를 지정했는가?
완료의 정의를 결과물과 검증 조건으로 작성했는가?
입력 데이터의 출처와 최신성 기준을 정했는가?
읽기·쓰기·외부 전송 권한을 분리했는가?
기존 처리 시간과 오류율을 기준선으로 측정했는가?

파일럿 중

모든 도구 호출과 사용 데이터의 출처를 기록하는가?
불확실한 답변과 근거 누락을 사용자에게 표시하는가?
고객·프로젝트·지역별 데이터가 세션에서 격리되는가?
사람이 승인하기 전 외부 발송이나 원본 변경을 막는가?
정상 사례뿐 아니라 권한 없음, 빈 데이터, 잘못된 입력을 테스트했는가?

확대 전

생산성 향상과 검토 부담을 함께 측정했는가?
다른 팀이 재사용할 공통 기능과 부서에 남길 전문 규칙을 구분했는가?
모델·프롬프트·데이터 변경 시 재평가 절차가 있는가?
소유자가 사라져도 스킬을 유지할 문서와 대체 담당자가 있는가?
성과가 낮거나 위험이 커질 때 폐기할 기준을 정했는가?

한계와 주의점

첫째, 입력 자료에서 확인되는 Kai의 성과 수치는 Stripe가 공개한 내부 비교 또는 보도자료의 주장이다. 비교군, 측정 기간, 활동량과 계약 성사의 산식, 다른 영업 정책이나 시장 요인의 영향은 제공된 자료만으로 검증할 수 없다. 따라서 이를 일반적인 ROI로 환산하거나 다른 기업의 예상 성과로 단정해서는 안 된다. Stripe Japan 보도자료

둘째, 공개 자료는 Kai의 개념적 계층과 일부 실행 구성은 설명하지만, 각 데이터 소스의 접근 제어 구현, 모델 선택 기준, 프롬프트 평가 방식, 장애 대응 절차, 비용 구조의 세부사항까지 공개하지 않는다. 특히 “권한을 지킨다”는 설명만으로 세션 격리와 행 단위 데이터 보안이 충분히 구현됐다고 판단해서는 안 된다. 실제 도입 전에는 로그 샘플, 권한 테스트, 데이터 보존 정책, 관리자 접근 범위를 별도로 확인해야 한다. GeekNews 정리

셋째, LangChain의 사례 설명과 KuCoin의 요약 자료는 Kai가 Deep Agents 및 LangChain·LangGraph 기반으로 구축됐다는 점과 1,000개 이상의 스킬을 언급하지만, 특정 프레임워크를 선택하면 같은 결과가 자동으로 재현된다는 의미는 아니다. LangChain 사례 소개 KuCoin 요약

마지막으로 “비개발자도 사용하기 쉬운 플랫폼”과 “비개발자가 무검토로 민감한 업무를 자동 실행하는 플랫폼”은 다르다. 조직이 참고할 부분은 Kai의 이름이나 특정 기술 스택보다, 공통 실행 기반·부서별 전문성·권한 격리·성과 측정을 한 운영 모델 안에 넣은 방식이다. 이 네 요소 중 하나라도 빠지면 에이전트가 늘어날수록 편리함보다 중복, 데이터 혼합, 책임 공백이 먼저 커질 수 있다.