Systems Thinker: Intuit이 따로 돌던 결제·급여·회계 에이전트를 한 플랫폼으로 다시 묶는 이유

업무별로 따로 만든 에이전트는 각자 잘 돌아도 고객이 겪는 일 전체를 이어 주지 못합니다. Intuit CEO Sasan Goodarzi는 이를 설계 실패로 보고, 데이터와 모델을 한 플랫폼에 모아 모든 에이전트가 같은 문맥을 보게 바꾸고 있습니다. 따라 하려면 에이전트를 부서별로 늘리기 전에 고객 여정 하나를 끝까지 정하고, 그 여정이 쓰는 데이터부터 한곳에 모아야 합니다.

요약

Stratechery의 Ben Thompson이 2026년 11월 5일 공개한 Intuit CEO Sasan Goodarzi 대담입니다. Intuit은 TurboTax, QuickBooks, Credit Karma, Mailchimp를 가진 회사로, 고객이 약 1억 명이고 그중 약 1,000만이 기업입니다. 대담은 Goodarzi의 경력과 회사 역사에서 시작해 회계사의 미래, 파괴적 혁신 위협, AI 시대의 사업 모델로 이어집니다. AI 이야기는 Thompson의 질문에서 열렸습니다. AI가 세부에 강하다면 큰 그림을 보는 사람(systems thinker)에게 선물이냐는 물음이었습니다. Goodarzi는 답하면서 자사가 먼저 내놓은 결제·급여·회계 에이전트 이야기를 꺼냈습니다. 에이전트마다 맡은 조각은 잘 처리했지만, 고객이 처음부터 끝까지 겪는 경험은 좋지 않았다고 했습니다.

원인은 둘이었습니다. 약 1년 전의 모델 역량이 모자랐고, 무엇보다 시스템 관점으로 설계하지 않았습니다. 에이전트는 받은 문맥과 데이터만큼만 일한다는 판단에서 Intuit은 데이터, 데이터 모델, 수집 모델, AI 모델을 한 플랫폼에 올려 회계사용 제품과 기업용 제품이 함께 쓰게 하고 있습니다. 그 위에 회계법인이 자기 SOP(표준 업무 절차서)를 올리면 결산 상당 부분을 자동화하는 기능과, 여러 고객사를 가로질러 묻는 대화형 분석을 얹었습니다. Goodarzi는 지금 회계사 업무의 약 30%가 수작업에서 자문으로 옮겨 가고 있고, 5년 뒤 회계사 수는 훨씬 줄 것이라고 봤습니다. 가격은 좌석 기준이 아니며 구독을 중심에 두고 3~5년 안에 사용량 과금을 더한다고 했습니다. 아래에서는 이 설계를 여섯 개념으로 풀고, 기업이 자기 에이전트 포트폴리오에 옮기는 방법을 붙입니다.

핵심 메커니즘

Slice Agents: 조각은 잘하지만 여정은 끊기는 에이전트

업무 하나만 맡아 그 안에서는 잘 도는 에이전트를 말합니다. 결제 에이전트는 대금을 받고, 급여 에이전트는 급여를 주고, 회계 에이전트는 거래를 분류합니다. 그런데 고객에게 이 셋은 한 흐름입니다. 급여를 주면 장부에 비용이 잡히고 현금 흐름이 바뀝니다. 이 연결이 어느 에이전트의 일도 아니면, 조각 사이의 빈칸은 고객이 직접 메웁니다. 업무가 정말 독립적이고 서로 데이터를 주고받지 않을 때만 이 구조로 충분합니다. Goodarzi가 든 예가 바로 Intuit의 첫 에이전트 묶음이었고, 그는 조각 단위 품질과 전체 경험이 따로 놀았다고 인정했습니다. 가상 예시로, 급여 에이전트가 지급을 마쳤는데 회계 에이전트가 그 비용을 다른 계정에 넣으면 대표는 두 화면을 오가며 숫자를 맞춰야 합니다.

Context and Data: 에이전트는 받은 문맥만큼 일한다

같은 모델이라도 무엇을 보고 판단하느냐에 따라 결과가 달라집니다. Goodarzi는 에이전트가 “only as good as the context you give it”이라고 했고, 데이터도 같다고 덧붙였습니다. 여러 업무를 잇는 여정에서는 각 에이전트가 다른 에이전트가 방금 한 일을 알아야 합니다. 입력은 고객의 장부, 거래, 급여, 결제 이력이고, 처리는 이 공통 문맥을 놓고 하는 판단이며, 출력은 앞 단계와 어긋나지 않는 다음 조치입니다. 그는 모델 역량이 날마다 나아지고 있으니 결국 문맥과 설계가 승부를 가른다고 봤습니다. 업무가 짧고 한 화면 안에서 끝나면 공통 문맥은 덜 중요합니다.

One Platform: 데이터·수집 모델·AI 모델을 양쪽 고객이 함께 쓴다

Intuit의 네트워크에는 두 편이 있습니다. 회계사와, 회계사가 장부를 봐 주는 기업입니다. Goodarzi는 모든 데이터, 데이터 모델, 수집 모델, AI 모델을 하나의 플랫폼에 두고 두 편이 함께 쓰게 한다고 설명했습니다. 회계사용 Intuit Accountant Suite는 QuickBooks 고객뿐 아니라 다른 총계정원장(GL)을 쓰는 고객도 붙일 수 있는 agnostic(특정 원장에 묶이지 않는) 구조입니다. 같은 장부를 보는 두 사람이 서로 다른 데이터로 AI 답을 받으면 결론이 갈립니다. 한 플랫폼은 이 어긋남을 막고, 회계사가 기업 고객을 붙잡아 두는 망 효과도 키웁니다. 그는 고객의 65% 이상이 회계사와 연결돼 있고 이를 100%로 올리고 싶다고 했습니다. 회계사가 붙은 기업이 더 오래 남고 수익성도 높다는 이유입니다.

SOP-Driven Agentic Close: 회계법인마다 다른 결산 절차를 그대로 받는다

회계법인은 저마다 장부를 마감하는 방식이 다릅니다. 그래서 Intuit은 정해진 마감 절차를 강요하지 않고, 회계법인이 자기 SOP를 agentic books close(에이전트가 돌리는 장부 마감) 기능에 올리게 했습니다. 시스템은 그 절차를 따라 마감의 상당 부분을 자동으로 처리합니다. 사람에게 남는 일은 판단입니다. Goodarzi는 계정 분류, 대사(두 기록을 맞춰 보는 일), 수익 인식, 장부가 맞는지에 대한 최종 판단을 꼽았습니다. 그는 회계사 업무가 수작업 90%, 판단 10%에서 그 반대 방향으로 옮겨 간다고 봤지만, 언제까지라는 시점은 밝히지 않았습니다. 마감 방식이 고객사마다 거의 같다면 SOP를 받는 단계 없이 표준 절차 하나로도 됩니다.

Cross-Client Intelligence: 여러 고객사를 한 번에 묻는다

Intuit Intelligence는 Goodarzi가 Claude나 ChatGPT에 견준 대화형 화면입니다. 회계사는 고객사를 하나씩 열지 않고 고객 전체를 놓고 묻습니다. 그가 든 예는 건설업 고객 가운데 동종 대비 비용에 문제가 있는 곳이 어디냐는 질문입니다. 기업 고객은 같은 기능으로 청구서 발행과 대금 독촉을 자동화합니다. 이런 질문은 플랫폼에 여러 고객의 데이터가 같은 형태로 모여 있어야 답할 수 있습니다. Goodarzi는 이 변화로 지금 회계사 업무의 약 30%가 수작업에서 자문으로 옮겨 가고 있다고 했습니다.

Pricing: 좌석 대신 구독·거래, 그 위에 사용량 과금

Intuit은 좌석(사용자 수) 기준으로 받지 않습니다. 지금은 세 방식이 있습니다. Credit Karma처럼 사용자는 무료이고 제휴사가 내는 방식, 기업용 플랫폼 매출의 약 80~90%를 차지하는 구독, 세금 신고나 청구·결제처럼 건마다 받는 거래 수수료입니다. Goodarzi는 3~5년 안에 사용량 기반 과금이 작지만 커지는 몫으로 더해진다고 봤습니다. 회계사가 건설 고객에게 에이전트 기능을 써 주고 그만큼 더 받으면, Intuit도 그 사용분에서 수익을 얻는 구조입니다. 성과 기반이 아니라 사용량 기반이라고 못 박았고, 고객을 상대로 시험해 보니 성과 기반이나 토큰 기반 가격은 반기지 않았다고 했습니다. 고객이 원하는 것은 예측할 수 있는 비용이었습니다.

통념과 다른 주장

저자가 든 사례

Intuit의 첫 에이전트 묶음: 조각은 성공, 여정은 실패

• 상황: Intuit은 결제, 급여, 회계 업무에 각각 AI 에이전트를 내놨습니다.
• 한 일: 에이전트마다 자기 업무를 맡겼고, 설계는 업무별로 따로 했습니다.
• 결과: 조각 단위로는 잘 돌았지만 고객이 처음부터 끝까지 겪는 경험은 좋지 않았습니다. 원인은 약 1년 전의 모델 역량과 시스템 관점 없는 설계였습니다. 정량 수치는 원문에서 밝히지 않았습니다.
• 연결: Slice Agents, Context and Data.

Intuit Connect 발표: 회계사를 고객으로 놓고 한 플랫폼에 올린 제품

• 상황: AI가 장부 일을 바꾸면서 회계법인은 PE(사모펀드) 통합 압력 속에서 일하는 방식을 다시 짜야 했고, Intuit은 회계사를 채널이 아닌 고객으로 다시 정의했습니다.
• 한 일: 한 플랫폼 위에 Intuit Accountant Suite(회계법인의 업무·고객 관리, 다른 GL도 연결), Intuit Intelligence(여러 고객사를 묻는 대화형 분석), SOP를 받는 agentic books close, Intuit Enterprise Suite(연 매출 수억 달러대 중견기업용 AI-native ERP, 건설·제조·비영리 업종판)를 올렸습니다.
• 결과: Goodarzi는 지금 회계사 업무의 약 30%가 수작업에서 자문으로 옮겨 가고 있다고 했습니다. 중견기업 사업은 회사의 약 30%, 70억 달러 이상이며 약 30%씩 큰다고 했습니다.
• 연결: One Platform, SOP-Driven Agentic Close, Cross-Client Intelligence.

Assisted Tax: 사람의 서명을 AI로 늘린다

• 상황: 세금 시장 약 400억 달러 가운데 약 350억 달러가 사람이 대신 신고해 주는 assisted tax입니다. 경쟁자는 대부분 동네 세무 사무소입니다.
• 한 일: Intuit 플랫폼에서 약 18,000명의 CPA와 전문가가 원격으로 신고를 처리하고, AI로 이 사람의 확인(human signature)을 더 낮은 가격에 더 많이 제공합니다.
• 결과: 정량 성과는 원문에서 밝히지 않았습니다. Goodarzi는 회계법인이 대체로 6,000달러 미만 개인 신고는 맡지 않으므로 이 시장이 회계사 고객과 겹치지 않는다고 설명했습니다.
• 연결: SOP-Driven Agentic Close(사람은 판단을, AI는 반복 작업을 맡는 구조).

기술 디테일: 따로 만든 에이전트를 한 여정으로 잇는다

아래 구조, 필드명, 설정값, 기준은 실제로 돌릴 때 필요한 것을 새로 쓴 가상 예시이며 Intuit이 밝힌 구현이 아닙니다.

Context and Data를 돌리려면 고객 단위 공통 문맥 저장소부터 둡니다. 에이전트마다 따로 DB를 보게 하지 않고, 고객 ID 하나에 원장 요약, 최근 90일 이벤트 로그, 열린 작업, 적용 중인 SOP 버전을 묶습니다. 모든 에이전트는 실행 전에 이 저장소에서 읽고, 실행 뒤 결과를 이벤트로 남깁니다. 모델 호출 단위는 이벤트 하나입니다. 입력 문맥은 원장 요약과 같은 고객의 최근 이벤트 20건 안팎으로 자릅니다.

{
  "event_id": "evt-20261107-0412",
  "customer_id": "biz-48213",
  "source_agent": "payroll",
  "type": "payroll.paid",
  "amount": 18450000,
  "currency": "KRW",
  "ledger_effect": {"debit": "급여", "credit": "보통예금"},
  "next_agents": ["accounting", "cashflow"],
  "sop_version": "firm-A-close-v3",
  "status": "posted"
}

Slice Agents의 빈칸은 handoff 규칙으로 메웁니다. 위 예에서 급여 지급 이벤트가 생기면 회계 에이전트가 이벤트의 ledger_effect를 그대로 받아 분개를 맞춥니다. 회계 에이전트가 다른 계정을 고르면 덮어쓰지 말고 exception 이벤트를 만들어 사람 큐로 보냅니다. 한 여정 안의 에이전트들은 같은 이벤트 스키마를 써야 하고, 스키마를 바꿀 때는 모든 에이전트의 회귀 시험을 함께 돌립니다.

SOP-Driven Agentic Close를 돌리려면 SOP를 실행 체크리스트로 바꿉니다. 회계법인이 올린 문서를 LLM이 단계 목록 JSON(step_id, action, data_source, tolerance, owner, requires_judgment)으로 뽑습니다. 같은 문서로 3회 뽑아(temperature 0) 세 번 모두 나온 단계만 초안으로 두고, 한 번만 나온 단계는 회계사 확인 표시를 붙입니다. 회계사는 체크리스트를 법인당 한 번 승인하고, 이후 매월 그대로 돌립니다. requires_judgment가 참인 단계(계정 분류 예외, 대사 불일치, 수익 인식)는 자동 확정하지 않고 항상 사람에게 보냅니다.

Cross-Client Intelligence를 돌리려면 계정 체계를 먼저 맞춥니다. 다른 GL을 쓰는 고객까지 비교하려면 각 원장의 계정을 공통 계정 체계로 매핑하는 층이 필요합니다. 동종 비교에는 업종 코드와 매출 구간이 있어야 합니다. 질문이 들어오면 권한 검사로 그 회계사가 맡은 고객만 고르고, 집계 SQL로 숫자를 뽑은 뒤 모델은 설명만 쓰게 합니다. 답에는 고객 수, 기간, 쓴 계정을 근거로 붙입니다.

평가는 에이전트별이 아니라 여정별로 합니다. 에이전트별 정확도와 함께 여정 지표 세 가지를 봅니다. 고객이 중간에 직접 손댄 횟수, 월 마감에 걸린 영업일, 마감 후 발견된 불일치 건수입니다. 에이전트별 정확도가 올라도 여정 지표가 그대로면 Slice Agents 문제가 남아 있다는 뜻입니다. 지난 마감 20건 안팎을 회귀 시험 세트로 묶어, 모델이나 SOP를 바꿀 때마다 같은 세트를 다시 돌려 세 지표를 비교합니다. Goodarzi가 말한 대로 모델 역량은 계속 바뀌므로, 모델 버전은 이벤트마다 기록해 둡니다.

Pricing에 맞추려면 실행마다 계량합니다. 에이전트 실행마다 customer_id, agent, run_type, units를 남기고, 고객에게는 월 구독에 포함된 사용량과 초과분 단가, 월 상한을 보여 줍니다. 고객이 예측 가능한 비용을 원한다는 원문 발언에 맞춘 설계입니다.

막히는 경우	증상	대응
에이전트마다 다른 고객 ID	같은 회사가 둘로 보임	공통 저장소 도입 전에 ID 매핑표부터 확정
handoff 이벤트 누락	급여는 나갔는데 장부에 없음	이벤트 발행을 실행 완료 조건으로 묶고, 일 1회 대사
SOP가 모호함	같은 문서에서 단계가 매번 다르게 뽑힘	일치하지 않는 단계를 회계사 질문 목록으로 전환
GL 계정 매핑 오류	동종 비교에서 한 고객만 튐	매핑 신뢰도 낮은 계정은 비교에서 빼고 표시
사용량 급증	고객 청구액이 예상을 크게 넘음	월 상한과 80% 도달 알림, 상한 초과 시 사람 승인

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할, 일정, 판정 기준은 Goodarzi의 설계 원칙을 기업 안의 에이전트 포트폴리오에 옮기기 위해 새로 짠 가상 예시입니다.

역할	맡는 일
CFO 또는 재무 운영 책임자	대상 여정 선정(예: 월 마감, 수금), 최종 판정
여정 오너 1명	여정 지도 작성, 에이전트 사이 handoff 정의, 주간 지표 보고
업무별 에이전트 담당 2~3명	결제·급여·회계 등 기존 에이전트의 입력·출력 정리
데이터 엔지니어 1~2명	고객·거래처 ID 통합, 공통 문맥 저장소, 이벤트 로그
회계·재무 실무자 2~3명	SOP 제공, 체크리스트 승인, 판단 단계 검토
구매·IT 계약 담당	벤더 과금 구조(구독·거래·사용량) 확인, 상한 조건 협상

준비물. 지금 돌고 있는 에이전트와 자동화 목록(업무, 입력 데이터, 출력, 담당자), 대상 여정의 SOP 문서, 최근 3개월 월 마감 소요일과 수작업 조정 건수, 시스템마다 다른 고객·거래처 ID 목록, 쓰고 있는 AI 벤더의 과금 조건이 필요합니다.

기간	할 일	산출물
1주	에이전트 목록 정리, 여정 하나 선정, 현재 지표 측정	에이전트 지도, 여정 기준선(마감일·수작업 건수)
2주	여정 지도에 handoff 지점 표시, 끊기는 곳 찾기	handoff 목록, 빈칸 목록
3~4주	ID 통합, 공통 이벤트 스키마, SOP 체크리스트 초안	이벤트 스키마, 승인된 체크리스트
5~6주	한 달 마감을 병행 운영(기존 방식과 나란히)	여정 지표 비교표
7주	판정 회의, 다음 여정과 과금 조건 결정	진행·보완·중단 결정서

현업에 물을 것.

1. 고객(또는 내부 사용자)이 이 업무를 끝내려면 화면이나 담당자를 몇 번 바꾸나요?
2. 지금 에이전트 A의 출력을 사람이 손으로 옮겨 에이전트 B에 넣는 곳은 어디인가요?
3. 우리 마감 절차는 문서로 있나요, 사람 머릿속에 있나요? 법인·사업부마다 다른가요?
4. 사람이 꼭 판단해야 하는 단계는 무엇이고, 그 판단의 근거는 어디에 남나요?
5. AI 비용이 매달 얼마까지면 예산 승인 없이 쓸 수 있나요?

진행 판정 기준(예시). 병행 운영에서 고객이나 실무자가 중간에 손댄 횟수가 기준선보다 50% 이상 줄고, 마감 소요일이 1일 이상 줄고, 마감 후 불일치가 늘지 않으면 다음 여정으로 넓힙니다. 에이전트별 정확도는 올랐는데 여정 지표가 그대로면 handoff와 공통 문맥을 다시 손봅니다. 불일치가 늘면 중단하고 판단 단계를 사람에게 되돌립니다.

AX 적용 제언. 국내 기업도 부서마다 에이전트를 하나씩 들이는 단계에 있습니다. Intuit의 경험은 다섯 번째 에이전트를 만들기 전에 이미 만든 넷을 여정으로 이어 보라고 말합니다. 순서는 셋입니다. 먼저 재무의 월 마감이나 영업의 수주에서 수금까지처럼 부서를 넘는 여정 하나를 고르고 handoff 지점을 그립니다. 다음으로 그 여정이 쓰는 고객·거래처 ID와 이벤트를 한곳에 모읍니다. 마지막으로 벤더 계약에서 사용량 과금이 들어오는 부분에 월 상한과 알림을 넣어 비용을 예측할 수 있게 합니다. 회계·세무 같은 전문 서비스 조직이라면 SOP를 체크리스트로 바꾸고 판단 단계를 따로 표시하는 일부터 하면 좋습니다.

원문 사례

항목	내용
원문	Stratechery, 2026.11.5 공개, Ben Thompson 진행 대담
화자	Sasan Goodarzi, 2004년 Intuit 합류, 2019년 CEO 취임, 이전 Siemens·Honeywell
대담 순서	경력(generalist) → Intuit 역사 → TurboTax·Credit Karma → 회계사의 미래 → 파괴적 혁신 → Mailchimp → AI 시대 사업 모델
첫 에이전트	결제·급여·회계 에이전트, 조각 단위는 잘했으나 처음부터 끝까지의 경험은 부족
원인	약 1년 전 모델 역량, 시스템 관점 없는 설계
플랫폼	데이터·데이터 모델·수집 모델·AI 모델을 한 플랫폼에, 회계사와 기업이 공유
신제품	Intuit Accountant Suite(GL agnostic), Intuit Intelligence, agentic books close(SOP 업로드), Intuit Enterprise Suite
회계사	고객 65% 이상 회계사 연결(목표 100%), 업무 약 30% 자문으로 이동 중, 5년 뒤 훨씬 적어짐, AI에 전력하지 않으면 2~3년 안에 밀려남
규모	고객 약 1억(기업 약 1,000만), 중견기업 사업 회사의 약 30%·70억 달러 이상·약 30% 성장, Credit Karma 월 활성 약 4,500만
세금	세금 시장 약 400억 달러 중 assisted tax 약 350억 달러, 플랫폼 CPA·전문가 약 18,000명
가격	좌석 기준 아님, 구독(기업 플랫폼의 약 80~90%), 거래 수수료, 사용자 무료·제휴사 부담, 3~5년 안에 사용량 과금 추가(성과 기반 아님)
LLM 연동	ChatGPT(OpenAI), Anthropic 등과 연동, LLM이 부르는 headless 금융 기능 지향

핵심 개념

General ledger(GL)

회사의 모든 거래를 계정별로 모아 둔 총계정원장입니다. QuickBooks, NetSuite 같은 회계 소프트웨어의 중심 데이터입니다.

Books close

한 달이나 분기 끝에 거래를 빠짐없이 기록하고 계정을 맞춰 장부를 확정하는 마감 작업입니다.

Assisted tax

납세자가 직접 신고하지 않고 세무 전문가가 대신 준비·신고해 주는 시장입니다.

Human signature

전문가가 결과를 확인하고 책임지는 일입니다. Goodarzi는 AI로 이 확인을 더 싸게 더 많이 제공한다고 말했습니다.

Headless

자기 화면 없이 다른 시스템(여기서는 LLM)이 불러 쓰는 기능으로 존재하는 방식입니다.

AI-native ERP

처음부터 AI 기능을 전제로 설계한 전사 자원 관리 시스템입니다. Intuit은 Enterprise Suite를 이렇게 부릅니다.

PE consolidation

사모펀드가 중소 회계법인을 사들여 묶는 흐름입니다. Goodarzi는 AI 이전부터 있었고 AI로 빨라진다고 봤습니다.

내 메모

TODO: 내 생각 추가

원문은 Stratechery의 「An Interview With Intuit CEO Sasan Goodarzi About Accounting and AI」(Ben Thompson, 2026.11.5)입니다. 대담 본문은 공개 페이지에서 읽었고, 회원 전용 팟캐스트 판은 쓰지 않았습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 Goodarzi의 발언을 AX Review가 다시 정리했으며 수치는 모두 그의 발언 기준입니다. GL, books close, headless, PE consolidation 등의 뜻풀이는 일반적인 정의로 보탰습니다. 공통 문맥 저장소, 이벤트 JSON, SOP 체크리스트 방식, 여정 평가 지표, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 대담 전문은 원문 페이지에서 볼 수 있습니다.