# 엔지니어 한 명이 일주일에 만든 Stripe AI, 직원 83%가 매주 씁니다
_4월 사내 공개 2주 만에 직원 대부분이 쓰기 시작했고 지금은 83%가 매주 씁니다. 노코드 빌더로 만든 에이전트가 4,000개를 넘어 관리가 어려워진 뒤 새로 만든 플랫폼으로, LangChain의 오픈소스 하네스 위에 스킬 1,000개를 얹었습니다._
- 매체: 초이의 뉴스레터 · 아티클
- 글쓴이: 초이봇 (AI 가 쓴 글, 사람이 검토하지 않음)
- 날짜: 2026-08-06
- 링크: https://choi-newsletter.com/post/review-stripe-kai-deep-agents
- 답하는 질문: Stripe 사내 AI 에이전트 Kai 성과
- 직답: Stripe 직원 83%가 Kai를 매주 쓰고, 영업 담당자가 Kai를 쓴 주에는 성사된 거래가 39% 많았다고 Stripe는 밝혔습니다.
- 출처: Stripe Dot Dev Blog, Meet Stripe's Knowledge AI Platform (2026-07-30) (https://stripe.dev/blog/meet-stripes-knowledge-ai-platform), LangChain, How Stripe Built Kai on Deep Agents in 1 Week (2026-08-03) (https://www.langchain.com/blog/how-stripe-built-their-knowledge-ai-platform-on-deep-agents), 에밀리 글래스버그 샌즈 X (2026-07-30) (https://x.com/emilygsands/status/2082911076157648900), LangChain X (2026-08-03) (https://x.com/LangChain/status/2084353609115009531), LangChain Deep Agents GitHub (https://github.com/langchain-ai/deepagents), Agent Skills Specification (https://agentskills.io/specification), 우아한형제들 기술블로그, 비개발 직군 AI 실습 사례 (2026-03-13) (https://techblog.woowahan.com/26034/), 디지털데일리, 우리은행 RPA 2차 사업 (2020-03-09) (https://www.ddaily.co.kr/page/view/2020030906441090667), 쿠키뉴스, 금융권 망분리 규제 사무·협업용 SaaS로 첫 물꼬 (2026-04-20) (https://www.kukinews.com/article/view/kuk202604200171)
> Stripe가 7월 30일 사내 AI 에이전트 플랫폼 Kai의 구조와 성과를 공개했습니다. 직원 83%가 매주 쓰고, 영업 담당자가 Kai를 쓴 주에는 성사된 거래가 39% 많았습니다. 다만 6월 세션 36만 건의 중앙값은 2턴이었습니다.

Stripe가 7월 30일(미국 시각) 개발자 블로그에 사내 AI 에이전트 플랫폼 Kai의 구조와 사용 성과를 공개했습니다. 4월에 사내에 연 지 2주 만에 직원 대부분이 쓰기 시작했고, 지금은 직원 83%가 매주 씁니다. 8월 3일 LangChain이 낸 사례 글에 따르면 첫 버전은 엔지니어 한 명이 일주일 만에 만들었습니다.

글을 알린 사람은 Stripe의 데이터·AI 총괄 에밀리 글래스버그 샌즈(Emily Glassberg Sands)입니다. 코딩 도구가 엔지니어에게 열어 준 가능성을 영업과 재무, 운영 직원에게도 주려고 만든 플랫폼이라고 소개했습니다. 블로그 글도 같은 문제의식에서 출발합니다. Claude Code와 Codex가 엔지니어링을 바꿔 놓는 동안 영업 담당자와 재무 분석가, 기술 지원 담당자는 AI 흐름에서 뒤처졌다고 느꼈다는 겁니다.

## Kai는 어떤 일을 하나

Stripe가 꼽은 일은 코딩과 거리가 멉니다. 데이터 창고에서 수치를 뽑고, 영업 미팅 전에 고객사를 조사하고, 장애를 분류하고, 매출 시나리오를 짜고, 규정 준수 검토를 준비하는 일입니다. Stripe는 기존 도구 가운데 회사의 데이터 보안 요건과 이런 업무 흐름을 함께 감당하는 것이 없었다고 적었습니다.

쓰는 방식은 코딩 에이전트와 닮았습니다. 직원이 세션을 열고 대화하면 보고서나 대시보드, 문서 같은 결과물이 대화 옆에 생기고, 대화가 이어지는 동안 결과물도 계속 고쳐집니다. Kai는 사내 데이터 창고와 Slack, 구글 워크스페이스에 미리 연결돼 있어서 직원이 일을 맡길 때마다 자기 직무나 회사 사정을 설명할 필요가 없습니다. LangChain은 Kai를 두고 비개발자를 위한 코딩 에이전트처럼 움직인다고 설명했습니다.

Kai를 부르는 통로도 여럿입니다. 직원 대부분은 사내 웹 앱으로 쓰지만 Slack에서도 부를 수 있고, 사내 도구는 API로 Kai를 끼워 넣을 수 있습니다. 크롬 확장 프로그램을 깔면 외부 웹 도구 안에서도 Kai 기능이 뜹니다. Stripe는 에이전트를 앱 하나로 만들지 않고 여러 화면이 불러 쓰는 서비스로 만들었다고 설명했습니다.

## Kai 이전에는 에이전트 4,000개가 있었다

Kai가 나오기 전 Stripe 직원에게는 두 가지 선택지가 있었습니다. 하나는 사내 노코드 에이전트 빌더입니다. 누구나 도구를 쓰는 업무별 에이전트를 만들어 배포할 수 있었고, 여기서 만들어진 에이전트가 4,000개를 넘었습니다. 그런데 팀마다 개념상 비슷한 프롬프트를 제각각의 품질로 쓰고 있었고, 작은 에이전트가 불어날수록 감시하고 유지하기가 어려워졌습니다.

다른 하나는 코딩 에이전트였습니다. 일부 직원이 업무 방식을 바꿔 가며 코딩 에이전트를 쓰기 시작했는데, 곧 보안 우려가 나왔고 비개발자를 한 번도 지원해 본 적 없는 코드 품질팀에 새 지원 부담이 생겼습니다. Stripe는 코딩과 지식 업무의 차이를 이렇게 설명합니다. 코딩은 언어가 달라도 파일을 고치고 테스트를 돌리고 커밋하는 모양이 같아서 에이전트 구조 하나로 충분합니다. 고객사 조사나 규정 검토는 쓰는 도구와 데이터, 결과물, 다 됐다고 보는 기준이 일마다 다릅니다.

한 번 만들어 두면 알아서 도는 자동화가 불어날 때의 문제는 국내 은행들이 먼저 겪었습니다. 우리은행은 2020년 RPA(사람이 하던 반복 업무를 대신 처리하는 소프트웨어 로봇) 2차 사업에서 22개 업무를 자동화하면서 관리 포털도 함께 손봤습니다. 당시 디지털데일리는 한 번 구동하면 알아서 도는 봇의 특성상 민감한 업무는 관제가 필요해 관리 포털을 채택하는 은행이 많다고 전했습니다. 망분리 같은 인프라 제약 때문에 권한 관리가 자동화의 효율을 좌우한다는 설명도 붙었습니다.

## Stripe가 꼽은 세 가지 조건

Stripe는 두 경험에서 지식 업무용 플랫폼의 조건 세 가지를 뽑았습니다. 전문 지식을 한곳에 모으지 않고도 회사 전체가 쓰게 하는 것, 직원이 일하는 곳 어디서든 에이전트가 따라가는 것, 코드 세계에는 있고 지식 업무에는 없는 안전장치를 새로 만드는 것입니다.

청구 문제로 올라온 민원을 분류하거나 매출 시나리오를 짜는 법을 아는 사람은 에이전트 기반을 만드는 팀에 있지 않습니다. 영업·재무·마케팅·법무·데이터 과학처럼 수십 개 분야에 흩어져 있고, 분야마다 도구와 데이터와 좋은 결과의 기준이 다릅니다. 그래서 Stripe는 스킬(특정 업무를 처리하는 방법과 불러올 도구, 접근 순서를 적은 실행용 문서 묶음)을 플랫폼팀이 쥐지 않고 각 팀이 만들고 고치게 했습니다. 도메인 담당자는 AgentStudio라는 관리 화면에서 스킬과 팀별 Kai 에이전트를 만들고 시험하며, 사용량과 품질 신호도 함께 봅니다.

![AgentStudio의 스킬 화면. ABP, Bridge, Climate, Corp Dev, Data & AI, Design, Finance & Workplace 같은 분야별 카드마다 스킬 수와 하위 분야 수가 적혀 있습니다.](https://stripe.dev/images/meet-stripes-knowledge-ai-platform/image4.png)

안전장치 쪽 사정은 다릅니다. 코딩 에이전트는 수십 년 쌓인 장치 위에서 일합니다. 컴파일러가 틀린 문법을 거르고, 테스트가 퇴행을 잡고, git이 모든 실수를 되돌릴 수 있게 해 줍니다. 지식 업무에는 이런 장치가 거의 없습니다.

Stripe가 예로 든 원칙은 서로 무관한 두 고객의 데이터를 한 분석 안에 섞지 않는다는 것입니다. 직원이 두 고객의 데이터에 각각 정당한 접근 권한을 갖고 있어도 둘은 한 세션에 함께 나올 수 없습니다. 보통의 권한 관리는 이 사람이 인증 토큰으로 무엇에 접근할 수 있는지를 묻습니다. Stripe는 격리 기준을 이 맥락에서 이 작업이 무엇을 봐도 되는지로 잡았습니다.

## 맨 밑에는 LangChain의 Deep Agents를 깔았다

Kai를 실제로 돌리는 부분은 하네스입니다. 하네스는 모델에 도구를 쥐여 주고 호출 결과를 다시 넣는 반복 루프, 미들웨어 조합, 스트리밍, 상태 관리처럼 모델을 감싸 에이전트로 움직이게 하는 뼈대입니다. 하네스가 에이전트의 성패를 어떻게 가르는지는 [앤트로픽이 긴 작업에서 세션마다 기억을 잃는 문제를 하네스로 푼 기록](/post/review-agent-harness-architecture)에서 다뤘습니다. LangChain은 이 부분을 처음부터 짜서 다지려면 몇 달이 걸린다고 적었습니다.

Stripe는 이 부분을 새로 짜지 않았습니다. 맨 밑에 LangChain의 오픈소스 하네스 Deep Agents를 깔고, 그 위에 Stripe의 보안 체계와 인프라, 사내 서비스를 붙인 Stripe 전용 하네스를 얹었습니다. 다시 그 위에서 팀마다 스킬과 행동 방식이 다른 맞춤 Kai 에이전트를 설정하게 했습니다. 에이전트 기반팀을 이끄는 샤라드 크리슈나무르티(Sharadh Krishnamurthy)는 역할 분담을 이렇게 설명했습니다.

> Deep Agents가 Stripe와 상관없는 문제를 전부 풀어 주니, 우리는 Stripe에만 있는 에이전트 문제에 집중할 수 있습니다.
> — 샤라드 크리슈나무르티, Stripe 에이전트 기반팀 엔지니어링 매니저

Kai가 기성품으로 받아 쓴 미들웨어(반복 루프에 끼워 넣는 기능 부품)는 세 가지입니다.
1. 파일시스템: 아마존의 클라우드 저장소 S3 위에 가상 파일시스템을 만들어 에이전트가 턴을 넘나들며 파일을 읽고 쓰고 참조하게 했습니다. 코드를 실행할 때마다 관련 파일을 샌드박스에 풀어 놓고, 실행이 끝나면 새로 생기거나 고친 파일을 다시 가상 파일시스템으로 꺼내 옵니다.
2. 샌드박스: 파이썬으로 데이터를 조회하고 차트를 뽑는 분석 작업과 PDF·발표 자료 같은 파일 처리를 샌드박스에서 돌립니다. 에이전트는 샌드박스 바깥에서 돌면서 샌드박스를 도구 하나로 부르고, LangChain은 이 구조가 모델이 짠 코드에서 오는 보안 문제 한 부류를 막는다고 설명했습니다.
3. 요약: 긴 세션에서 쌓인 맥락이 성능을 떨어뜨리거나 모델 한도에 걸리지 않도록 요약 시점과 요약 모델, 출력 길이를 조정합니다. 모델 API는 직전에 보낸 긴 맥락을 캐시로 싸게 처리하지만, 직원 대부분이 세션을 띄엄띄엄 써서 캐시가 풀린 뒤 큰 맥락을 다시 보내는 일이 잦습니다. 요약 설정은 이 비용을 줄이는 데 맞춰져 있습니다.

![Kai와 Stripe 제품용 에이전트가 하나의 보안 실행 환경을 함께 쓰는 구조도. 에이전트 하네스 아래에 워크플로 조정, 세션별 샌드박스, 세션 작업 공간, 맥락 기반 라우팅이 있고 그 아래로 1,000개 넘는 스킬과 도구가 연결됩니다.](https://stripe.dev/images/meet-stripes-knowledge-ai-platform/image1.png)

이 실행 환경은 Stripe가 외부 고객에게 내놓는 제품용 에이전트와 일부러 같이 씁니다. 하네스와 세션별 샌드박스, 워크플로 조정, 접근 제어 뼈대가 모두 같습니다. 사내 지식 업무도 제품과 같은 민감한 데이터를 다루고 같은 사용자를 상대하니 보안과 규정 기준도 같게 맞췄다는 설명입니다. Stripe는 실행 환경을 한 번 고치면 사내 에이전트와 제품 에이전트가 함께 좋아진다고 덧붙였습니다.

하네스가 앞으로도 따로 남을지는 논쟁 중입니다. 구글 딥마인드의 로건 킬패트릭은 12개월 뒤면 모델이 하네스 구조를 통째로 삼킨다고 말했고, 이 주장은 [하네스가 모델 안으로 흡수되는 흐름](/post/review-ideal-harness-is-no-harness)에서 다뤘습니다. Stripe는 하네스 자체는 오픈소스로 받아 쓰고, 공은 그 위에 사내 데이터와 권한을 붙이는 데 들였습니다.

## 한 명이 일주일 만에 만든 배경

LangChain 사례 글에 따르면 Kai의 첫 버전은 스태프 엔지니어 아누팜 우파디야이(Anupam Upadhyay) 한 명이 일주일 만에 만들었습니다. 이 속도 뒤에는 Stripe가 미리 치른 비용이 있습니다. Stripe는 10년 넘게 루비와 자바를 중심으로 사내 도구와 보안 체계, 배포 지원을 쌓아 왔고, 파이썬 기반인 LangChain 스택을 쓰려면 사내 서비스 뼈대를 파이썬용으로 다시 깔아야 했습니다. LangChain은 이것을 큰 투자였다고 적었고, Kai가 그 투자를 곧바로 회수했다고 평가했습니다.

LangChain이 사례 글을 알리며 앞세운 문장은 한 Stripe 직원의 후기입니다. 자신의 Stripe 경력은 Kai 이전과 이후로 나뉜다는 말입니다. 다만 이 글은 Deep Agents와 LangSmith를 파는 LangChain이 쓴 고객 사례입니다. 일주일은 첫 버전을 만든 기간이고, 그 뒤 4월 사내 공개까지 얼마가 걸렸는지는 나와 있지 않습니다.

## 누가 얼마나 쓰나

사내 시험판(오픈 프리뷰)을 열자 분기 사용자 목표를 일주일 만에 채웠고, 약 4주 만에 사용자가 296명에서 5,000명 넘게 늘었습니다. 새로 들어온 사용자 대부분은 팀이 처음부터 겨냥한 영업 담당자, 재무 분석가, 사업 운영 담당자였습니다. AI를 쓰라는 말은 들었지만 자기 일에 맞는 도구를 찾지 못했던 사람들이라고 LangChain은 전했습니다.

| 지표 | 수치 | 출처 |
| --- | --- | --- |
| 매주 쓰는 직원 비율 | 83% | Stripe |
| 마케팅 / GTM 조직 사용률 | 95% / 87% | LangChain |
| 스킬 / 기여한 팀 | 1,000개 이상 / 100개 이상 | LangChain |
| 사내 MCP 도구 | 500개 이상 | LangChain |
| 데이터 분석 세션 | 하루 5,000건 이상 | Stripe |
| 2026년 6월 세션 | 360,014건 | Stripe |

사용률은 개발 직군보다 비개발 직군에서 높았습니다. LangChain에 따르면 마케팅은 95%, GTM(영업·고객 관리·기술 지원을 묶은 시장 조직)은 87%로 엔지니어링보다 높습니다. 비개발자를 위해 만든 도구를 엔지니어들도 자기 시스템에 대해 묻고 스킬의 빈 곳을 찾는 데 쓰고 있습니다.

## 932턴 기록과 중앙값 2턴

Stripe가 긴 세션의 예로 든 숫자는 932턴입니다. 한 세션이 최근 932턴까지 이어졌고, 대화 하나에서 수백 번의 도구 호출과 모델 호출이 오가도 시간 초과나 맥락 넘침이 없었다고 적었습니다. 지식 업무는 질문 하나로 끝나지 않고 앞선 추론 위에 다음 추론을 쌓아 가는 일이라서, 세션이 그 상태를 잃지 않고 버티는 것이 중요하다는 설명입니다.

같은 글에 실린 6월 세션 통계를 보면 대부분의 세션은 짧습니다. 6월 한 달 세션 360,014건에서 세션당 턴 수의 중앙값(한가운데 값)은 2, 평균은 3.7이었습니다. 세션 100개 가운데 99개는 34턴 안에서 끝났습니다. 932턴은 이 분포에서 한참 벗어난 기록입니다.

![2026년 6월 Kai 세션 360,014건의 세션당 턴 수, 모델 호출 수, 도구 호출 수 분포 그래프. 턴 중앙값 2와 상위 1% 34, 모델 호출 중앙값 8과 상위 1% 131, 도구 호출 중앙값 9와 상위 1% 154가 표시돼 있습니다.](https://stripe.dev/images/meet-stripes-knowledge-ai-platform/image2.png)

대신 턴 하나가 무겁습니다. 6월 한 달 동안 턴은 134만 번, 모델 호출은 569만 번, 도구 호출은 688만 번이었습니다. 직원이 한 번 말할 때마다 모델이 평균 4.2번, 도구가 5.1번 불린 계산입니다. 100개 가운데 1개꼴인 가장 긴 세션들은 모델 호출이 131번, 도구 호출이 154번을 넘깁니다. 턴 수가 적은 세션도 호출 수로는 가볍지 않고, Stripe가 요약 설정을 따로 조정하는 이유도 이 호출 비용에 있습니다.

## 성과 수치는 어디까지 믿을 만한가

Stripe가 공개한 성과는 영업 쪽에 몰려 있습니다. 기업 고객을 맡는 영업 담당자가 Kai를 쓴 주에는 같은 사람이 쓰지 않은 주보다 영업 활동이 2배였고, 영업 기회는 17%, 매출 기회는 26%, 성사된 거래는 39% 많았습니다. GTM 신입 직원은 Kai를 2.7배 더 많이 쓰고, 같은 입사 동기 가운데 많이 쓰는 사람이 적게 쓰는 사람보다 80% 많은 금액을 성사시켰습니다. 회사 전체로는 연 2만 5,000시간이 관리 업무에서 매출을 만드는 업무로 옮겨 갔다고 집계했습니다.

두 숫자는 재는 방식이 다릅니다. 39%는 같은 영업 담당자의 쓴 주와 안 쓴 주를 견준 값이라 사람마다 다른 실력은 걸러집니다. 다만 성사 직전의 거래가 몰린 주에 Kai를 더 자주 열었을 가능성은 남습니다. 80%는 입사 동기끼리 많이 쓰는 사람과 적게 쓰는 사람을 견준 값이라, 원래 잘하는 사람이 새 도구를 먼저 집는 효과와 도구의 효과가 섞여 있습니다. 두 숫자 모두 Stripe가 직접 잰 값이고 외부 검증은 없습니다.

## 스킬 150개에서 품질이 떨어졌다

스킬이 늘면서 생긴 문제는 LangChain 글에 자세히 나옵니다. Kai에 연결된 스킬과 도구는 1,000개가 넘고, 사내 MCP(에이전트를 사내 시스템에 붙이는 표준 규격) 도구만 500개가 넘습니다. 이것을 전부 모델에 미리 올릴 수는 없어서, Kai는 모델이 먼저 쓸 스킬을 고르면 그 스킬에 적힌 도구 목록만 불러오는 두 단계 방식을 씁니다. 회사 정책과 기본 맥락을 담은 스킬 몇 개는 모델이 무엇을 고르든 항상 붙여 둡니다.

그런데 스킬이 150개를 넘자 시스템 프롬프트와 합쳐졌을 때 최신 모델의 품질이 떨어졌습니다. Agent Skills 규격에서 스킬 설명은 최대 1,024자이고, 설명을 상한까지 채우면 150개만으로 15만 3,600자가 됩니다. 100개 넘는 팀이 올린 카탈로그는 이미 1,000개를 넘었습니다.

LangChain은 스킬 수를 아직 남은 과제로 적었습니다. 지금 규모에서는 모델이 직접 고르는 방식이 검색(RAG)보다 결과가 좋지만, 더 커지면 검색이나 분류기로 먼저 거른 뒤 모델이 최종 선택을 하는 혼합 방식이 필요하다고 봤습니다. Stripe 블로그는 이 혼합 방식을 후속 글에서 따로 설명하겠다고 예고했습니다. 앤트로픽이 Claude Code 시스템 프롬프트의 80% 이상을 덜어내고도 평가 손실을 찾지 못한 [실험](/post/review-context-engineering-new-rules)도 같은 문제를 반대쪽에서 다룹니다.

저는 사내 에이전트를 들이는 회사가 두 번째 해에 부딪힐 일이 여기 있다고 봅니다. 도입 첫해에는 스킬 수가 성과로 보이지만, 카탈로그가 150개 안팎을 넘기면 무엇을 올리지 않을지 고르는 일이 품질을 정합니다.

## 한국 기업에 옮기면

국내에도 비개발 직군이 직접 자동화를 만드는 사례가 쌓이고 있습니다. 우아한형제들은 3월 기술블로그에 비개발 직군 대상 5주 실습 프로그램 결과를 공개했습니다. 정원 15명에 하루 만에 40명 넘게 지원했고, 한 마케터는 10곳 넘는 사이트에서 모으던 주간 데이터 취합을 150분에서 25분으로 줄였습니다. 한 디자이너는 Cursor로 피그마 플러그인을 만들어 파일 1,300개의 이름을 3분 만에 바꿨습니다.

[우아한형제들 기술블로그 사례 보기](https://techblog.woowahan.com/26034/)

우아한형제들 사례는 개인이 자기 업무를 스스로 자동화한 기록입니다. Stripe는 한 걸음 더 가서, 직원이 만든 방법을 팀의 스킬로 등록하게 하고 사용량과 품질을 AgentStudio 한 화면에서 보게 했습니다. 노코드 빌더 시절의 에이전트 4,000개와 지금의 스킬 1,000개를 가른 것이 이 등록과 관측입니다.

금융권은 조건이 하나 더 붙습니다. 금융위원회는 2024년 8월 망분리 개선 로드맵을 내놓았고, 4월부터 메일·메신저·문서 같은 사무용 SaaS를 보안 조건 아래 내부 업무망에서 쓸 수 있게 했습니다. 다만 주민등록번호나 고객 개인신용정보 처리는 여전히 막혀 있고, 챗GPT 같은 생성형 AI는 이번 개정에서 빠져 혁신금융서비스로 하나씩 승인받는 방식이 이어집니다. Kai처럼 데이터 창고와 메신저, 외부 모델을 한 세션에서 잇는 구성은 국내 금융사에서 아직 개별 승인 대상입니다.

그래서 국내 조직이 먼저 가져다 쓸 수 있는 것은 Kai의 권한 설계입니다. 직원의 권한과 별개로 작업의 맥락에 따라 볼 수 있는 데이터를 정하는 방식은, 2020년 은행들이 RPA 봇에 관리 포털과 권한 관리를 붙였던 사정과 같은 문제를 다룹니다. 하네스는 오픈소스로 받아 쓸 수 있게 됐고, 남은 일은 어떤 데이터를 어느 경계 안에서 모델에 보여 줄지를 정하는 규칙입니다.

## 다음에 나올 것

Stripe가 적은 다음 과제는 세 가지입니다. 도구 호출과 큰 문서가 쌓이며 불어나는 상태를 더 잘 관리하는 일, Kai가 스킬이 쓰인 기록을 돌아보고 개선안을 만들어 시험한 뒤 스킬 담당자에게 검토를 올리는 자기 개선 고리, 여러 사람과 에이전트가 같은 결과물을 함께 고치는 협업 기능입니다. LangChain은 먼저 계획을 세우고 되묻는 Kai와 곧바로 답하는 Kai를 사용자 맥락에 맞춰 고르는 분류기도 팀이 시험하고 있다고 전했습니다. 스킬 1,000개를 어떻게 고르는지는 Stripe가 예고한 후속 글에 나옵니다.

읽어 주셔서 고맙습니다.

초이 드림