Stripe의 사내 Knowledge AI 플랫폼 Kai

TL;DR Highlight

Stripe가 비개발자용 에이전트 플랫폼 Kai를 만들어 직원 83%가 주간 사용

Who Should Read

비개발 직군용 사내 에이전트 플랫폼을 설계하며 보안과 도메인별 관리 방식을 고민하는 백엔드·플랫폼 개발자

Core Mechanics

코딩 에이전트는 비개발자에게 안 맞았다
- 코딩은 파일 수정·테스트·커밋으로 작업 모양이 비슷해서 에이전트 하나로 충분하다.
- 지식 업무는 도구·데이터·결과물·완료 기준이 모두 달라서 같은 방식이 통하지 않는다.
기존 두 방식은 둘 다 한계가 있었다
- NoCode Agent Builder로 4,000개 넘는 에이전트가 만들어졌지만 비슷한 프롬프트가 품질만 제각각이었다.
- 마이크로 에이전트가 늘면서 모니터링과 유지보수가 어려워졌다.
- 코딩 에이전트를 쓴 직원들 때문에 보안 우려와 코드 품질팀의 지원 부담이 생겼다.
Kai는 세 겹 구조로 만들었다
- 첫째는 웹앱·Slack 등 여러 화면이 같은 에이전트를 쓰게 하는 표면 독립 API다.
- 둘째는 도메인 담당자가 자기 에이전트와 스킬을 만들고 관리하는 Agent Studio다.
- 셋째는 인프라를 신경 쓰지 않아도 보안이 보장되는 실행 환경이다.
에이전트는 앱이 아니라 서비스다
- 웹앱과 Slack이 같은 API 위에 올라간 화면일 뿐이다.
- 내부 도구는 API로 Kai를 임베드하고, Chrome 확장으로 서드파티 웹 도구 안에서도 쓴다.
보안 경계는 권한 토큰이 아니라 작업 맥락이다

Community Reactions

서비스 지표는 원문 자체 보고라는 비판
- 영업 활동 2배인데 기회는 17%만 늘고 성사 거래는 39% 늘어 숫자가 수상하다는 의견이 있었다.
- 상관관계이지 인과가 아니며 휴가·병가로 활동이 줄면 툴 사용도 줄 뿐이라는 의견이 있었다.
Knowledge라는 이름값 못 한다는 반응
- 검증이나 투명성 같은 지식 관리 기능은 안 보이고 일반 에이전트 빌더에 가깝다는 의견이 있었다.
- 왜 오픈소스나 Notion 같은 기존 제품이 아니라 직접 만들었는지 설명이 없다는 의견이 있었다.
새 채널이 오히려 낫다는 현장 경험
- 고객사가 잘 관리 안 된 사내 툴보다 채팅 UI를 훨씬 선호했다는 경험이 있었다.
- 수백 개의 cshtml 뷰와 컨트롤러를 JSON 패치를 적용하는 에이전트 툴 하나로 대체 중이라는 경험이 있었다.
비슷한 방향의 사례들이 줄줄이 나왔다
- Cloudflare OS와 비슷하고 여유 있는 회사는 다 사내에서 이런 걸 만든다는 의견이 있었다.
- windmill.dev 쪽도 보안 코드 런타임, ACL, 앱 빌더가 핵심인 같은 방향이라는 의견이 있었다.

How to Apply

우리 팀 에이전트의 보안 경계 규칙 적기
- 오늘 30분 동안 서로 섞이면 안 되는 데이터 맥락 쌍을 목록으로 적어라.
- 각 쌍에 대해 권한 토큰이 아니라 작업 맥락 기준으로 세션에서 막을 조건을 한 줄씩 써라.
프롬프트 난립 현황 조사하기
- 팀별로 만든 에이전트와 프롬프트를 모아 비슷한 목적끼리 묶어라.
- 중복되는 것은 공통 스킬 하나로 합치고 담당자를 지정해라.
에이전트를 API 서비스로 분리하기
- 에이전트 로직을 웹앱 안에서 꺼내 API로 노출해라.
- Slack 봇이나 내부 도구는 그 API를 호출하는 화면으로만 만들어라.
도메인 담당자용 관리 화면 설계하기
- 스킬별 사용량과 품질 신호를 한 화면에 보여주도록 만들어라.
- 담당 도메인 팀이 플랫폼 팀에 묻지 않고 스킬을 고치게 해라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 그대로 붙여넣기 (원문의 보안 경계 아이디어를 프롬프트로 옮긴 간이 버전)

나는 사내 에이전트 플랫폼을 설계 중이다. 아래 원칙을 기준으로 우리 서비스의 위험한 시나리오를 점검해줘.
원칙: 사용자가 두 데이터 맥락에 각각 접근 권한이 있어도, 서로 무관한 두 고객 맥락의 데이터는 한 세션에서 합쳐 분석되면 안 된다. 기준은 '이 사람이 뭘 볼 수 있나'가 아니라 '이 작업이 이 맥락에서 뭘 봐도 되나'이다.

우리 서비스 설명: {{서비스 설명}}
에이전트가 쓰는 데이터 소스: {{데이터 소스 목록}}

다음을 해줘.
1. 한 세션에서 섞이면 안 되는 데이터 맥락 쌍을 5개 이내로 나열해줘.
2. 각 쌍마다 세션 시작 시 어떤 맥락을 고정할지, 툴 호출에서 무엇을 막을지 규칙으로 써줘.
3. 규칙 위반을 테스트할 시나리오 질문을 하나씩 만들어줘.

이어서 해 볼 것: 만들어진 시나리오 질문을 실제 에이전트에 던져 규칙이 지켜지는지 확인해 봐.

Terminology

에이전트 하니스LLM이 툴을 쓰며 일하도록 감싸는 실행 틀이다. 자동차로 치면 엔진 주변의 차체와 제어 장치다.

샌드박스에이전트가 코드를 돌릴 때 바깥 시스템과 분리해 두는 격리 공간이다. 아이들이 모래 놀이터 안에서만 놀게 하는 것과 비슷하다.

컨트롤 플레인실제 일을 하는 부분과 별개로 설정·모니터링·관리를 맡는 층이다. Agent Studio가 이 역할이다.

멀티테넌트 가상 파일시스템여러 사용자나 세션이 같은 시스템을 쓰되 각자 자기 파일 공간만 보게 만든 가짜 파일 저장소다.

스킬에이전트가 특정 업무를 하려고 불러 쓰는 지침과 도구 묶음이다. 직원에게 주는 업무 매뉴얼에 가깝다.