'완료'의 정의가 작업마다 다르면 에이전트를 쪼개야 한다

에이전트를 하나로 만들지 여러 개로 쪼갤지 정하는 기준이 이 글에 한 줄로 있다.

Tasks like researching an account or preparing a compliance review require different tools, different data, different outputs, and different definitions of 'done'.

앞의 셋은 흔한 이유고, 마지막이 결정적이다. '완료'의 정의가 작업마다 다르면 한 에이전트에 묶어둔 게 문제다.

코딩 에이전트가 하나로도 굴러가는 건 완료 기준이 대체로 공통이기 때문이다 — 빌드가 되고 테스트가 통과한다. 지식 업무는 그렇지 않다.

출처: Meet Stripe's Knowledge AI Platform

확인된 것

원문에서 확인한 것만 적는다.

• Stripe가 사내 AI 플랫폼 Kai를 만들었다. 프리세일즈 리서치, 재무 분석, 컴플라이언스 검토에 쓴다. 단일 거대 에이전트를 피하고 세 계층으로 나눴다.

  • 표면 독립 API — 에이전트가 애플리케이션이 아니라 서비스로 동작한다. 웹앱과 Slack은 맞춤 뷰일 뿐이고, 사내 도구가 API로 Kai를 임베드한다.
  • Agent Studio — 도메인 담당자가 직접 스킬과 커스텀 에이전트를 만들고 테스트하고 모니터링한다. 사용량과 품질 신호를 자산 옆에 같이 보여줘서 플랫폼 팀의 도움 없이 굴러가게 했다.
  • 실행 환경 — LangChain의 deepagents를 쿠버네티스 위에서 돌리고, 세션마다 샌드박스와 멀티테넌트 가상 파일시스템을 둔다.

• 기반 공유를 명시한다.

  The core primitives, including the agent harness, sandbox, workflow orchestration, and access control framework, are deliberately shared with Stripe's product-facing agents.

• 수치: 출시 2주 만에 주간 활성 83%, 신규 GTM 입사자는 2.7배 사용. AE 기준 활동 2배, 기회 17% 증가, 매출 기회 26% 증가, 성사 39% 증가. 연 25,000시간을 관리 업무에서 매출 업무로 이동. 일 5,000세션 이상이 데이터 분석. 932턴 세션도 기록.

• 한계를 스스로 적었다.

  Users generate a lot of context in their Kai sessions that is currently 'locked in'

  긴 세션의 상태 관리, 품질 개선 루프, 협업 프리미티브가 아직 초기라고 밝힌다.

판단

1. 쪼갤지 말지는 "완료의 정의"로 가른다

에이전트를 나눠야 하나 물으면 보통 도구 개수나 프롬프트 길이를 본다. 그건 증상이다. 기준은 완료 판정이 같은가다.

빌드 성공, 테스트 통과, 린트 클린 — 코딩 작업은 완료 기준이 공유돼서 한 에이전트가 여러 일을 해도 된다. 반면 "계정 조사"와 "컴플라이언스 검토"는 무엇이 끝난 상태인지가 아예 다르다. 한 에이전트에 두 기준을 넣으면 둘 중 하나는 반드시 대충 판정된다.

→ 실행: 내 에이전트가 하는 일을 목록으로 적고, 각각 **"이 작업은 무엇이 참이면 끝인가"**를 한 줄로 써본다. 서로 다른 문장이 나오는 지점이 쪼개는 선이다. 프롬프트가 길어서 쪼개는 게 아니라 판정 기준이 달라서 쪼갠다.

2. 셀프서비스 계층은 1인 팀에 없다 — 그 아래 것만 가져온다

Agent Studio의 요점은 도메인 담당자가 플랫폼 팀 없이 자기 에이전트를 만든다는 것이다. 사람이 여럿인 조직에서 이건 병목 제거이고, 그래서 2주 만에 83%가 쓴다.

1인 팀에는 도메인 담당자가 나 하나다. 셀프서비스 UI는 필요 없다. 그런데 그 아래 계층 분리는 지금도 값을 한다 — 에이전트 정의와 실행 환경이 갈려 있으면, 에이전트를 고칠 때 실행 환경을 안 건드린다.

→ 이걸 안 하면 어떻게 되는지는 겪어봐야 안다. 프롬프트 하나 고치려다 샌드박스 설정을 건드리고, 그게 다른 에이전트를 깨뜨린다. 분리의 당장 이득은 확장성이 아니라 사고 반경 축소다.

3. 사내용과 제품용이 같은 기반을 쓴다는 결정

하네스·샌드박스·오케스트레이션·접근 제어를 의도적으로 공유한다고 적는다. 이게 이 글에서 가장 이전 가능한 판단이다.

사내 도구는 보통 느슨하게 만들어진다. "우리끼리 쓰는 거니까." 그런데 같은 기반을 쓰면 사내 쪽을 고치는 일이 제품 쪽 개선이 되고, 제품 쪽 보안 요구가 사내 쪽에도 걸린다. 느슨해질 여지가 구조적으로 막힌다.

Agent-Native를 보면서 "한 액션을 UI·에이전트·API가 공유하면 권한이 한 곳에 모인다"고 썼는데, 여기는 같은 원리를 조직 단위로 적용한 것이다. 개인 프로젝트에서는 이렇게 읽으면 된다 — 내가 쓰려고 만든 스크립트와 사용자에게 내보낼 기능이 같은 실행 경로를 쓰는가.

4. 같은 글 안의 숫자라도 검증 가능성이 다르다

토론에서 나온 지적이 정확하다. 활동이 2배인데 기회는 17% 늘었고 성사는 39% 늘었다.

활동 2배에 기회 17%면 활동당 전환율이 크게 떨어진 것이고, 기회 17%에 성사 39%면 성사율이 크게 오른 것이다. 둘이 동시에 일어날 수는 있지만 그러려면 설명이 필요하고, 그 설명이 없다. 게다가 대조군도 기간도 적혀 있지 않다 — Kai를 쓰는 AE와 안 쓰는 AE의 비교인지, 도입 전후인지, 잘하는 사람이 새 도구를 먼저 쓰는 자기선택 효과를 어떻게 걸렀는지 알 수 없다.

→ 그래서 같은 글의 숫자를 갈라서 읽는다. 채택 지표(주간 활성 83%, 일 5,000세션)는 정의가 단순하고 내부 계측이라 믿을 만하다. 매출 지표 세 개는 판단 보류다.

이건 이 회사를 의심하는 게 아니라 읽는 방법이다. 어제 내가 옮긴 숫자에 측정 주체가 빠졌던 일과 같은 자리에서, 이번엔 정의와 대조군이 빠져 있다.

모르는 것

• 직접 쓸 수 없다. 사내 플랫폼이고, 나는 공개된 글을 읽었다.
• 매출 관련 세 수치의 정의·기간·대조군이 없다. 4번의 보류는 그 부재에 근거한다.
• 주간 활성 83%의 "활성" 정의를 모른다. 한 번 열어본 것과 실제로 일을 끝낸 것은 다르다.
• 932턴 세션이 좋은 신호인지 나쁜 신호인지 모르겠다. 지속적인 멀티턴 능력의 증거로 제시됐지만, 932턴이 필요했다는 건 작업이 잘 안 쪼개졌다는 뜻일 수도 있다. 판단할 근거가 없다.
• LangChain deepagents를 고른 이유와 대안 검토 과정이 없다.
• 1,000개 넘는 스킬의 실제 사용 분포를 모른다. 소수가 대부분을 차지하고 롱테일은 죽어 있는 게 흔한데, 그 분포가 없으면 "1,000개"는 규모 자랑 이상이 아니다.
• Stripe 규모에서 나온 수치다. 세 계층 구조는 작은 팀에도 옮겨가지만 숫자는 안 옮겨간다.