The New CFO: Figma 재무팀은 업무 도구를 직접 만들고, 인수 실사에선 대상 제품을 재현해 본다
Figma CFO Praveer Melwani는 a16z 대담에서 재무 담당자들이 Codex, ChatGPT 에이전트, Figma Make로 채권 회수, 출장·경비 분석, 인수 실사 도구를 직접 만든다고 밝혔습니다. 실사에서는 대상 제품을 바이브 코딩으로 재현해 기술 해자를 가늠합니다. 핵심 원장은 사고 워크플로만 만들며, 만든 도구는 네 가지 질문으로 제품화 여부를 가립니다.
Figma 재무팀은 IT에 티켓을 내고 기다리지 않습니다. 업무에 가장 가까운 담당자가 AI 도구로 자기 도구를 직접 만들고, 인수 실사에서는 대상 제품을 바이브 코딩으로 다시 만들어 보며 기술의 깊이를 잽니다. 따라 하려면 사는 것과 만드는 것의 경계, 데이터 연결, 개인 도구를 제품으로 올리는 기준을 먼저 정해야 합니다.
요약
a16z 파트너 Seema Amble과 Ivan Makarov가 Figma CFO Praveer Melwani와 약 50분 동안 AI 시대의 재무 조직을 이야기했습니다. Melwani는 Figma에 합류했을 때 제품 지표와 Stripe 매출을 잇는 SQL을 손으로 썼습니다. 모두가 믿는 숫자 한 벌을 얻으려고 수백 줄짜리 쿼리와 엑셀 매크로를 돌렸습니다. 지금은 재무 담당자들이 Codex, skill을 붙인 ChatGPT 에이전트, Figma Make(자연어로 앱을 만드는 Figma 도구)로 업무 도구를 직접 만듭니다. 그는 CFO의 일을 숫자를 막아 세우는 traffic cop(교통 정리 담당)에서 사업을 움직이는 리더로 옮겨 가는 일로 봅니다.
대담에 나온 도구는 세 팀에서 나왔습니다. 채권·회수 담당은 청구서 추적, 수금, NetSuite 대사(장부와 실제 입금을 맞추는 일)를 자체 시스템으로 다시 짜 DSO(매출채권 회수 기간)를 줄이는 데 시간을 돌렸습니다. 기업개발팀은 인수 후보의 제품을 바이브 코딩으로 재현할 수 있는지를 실사 항목으로 삼았습니다. 기업재무팀은 세 곳에 흩어진 출장·경비 데이터를 묶어 정책 변경안을 냈습니다. 원칙은 두 가지입니다. 틀리면 안 되는 핵심 기록 시스템은 사고, 워크플로 자동화는 만듭니다. 만든 도구 가운데 오래 쓸 것은 새로 온 CIO 조직이 제품으로 다듬습니다. 아래에서 다섯 가지 작동 원리와 세 사례를 보고, 따라 할 때 필요한 기술·현업 디테일을 붙입니다.
핵심 메커니즘
Owner, Not Ticket Filer: 업무 담당자가 도구의 주인이 된다
Melwani는 재무를 요청서를 내는 쪽이 아니라 주인으로 봅니다. 도구는 그 프로세스를 매일 다루는 담당자가 만듭니다. 담당자는 규칙과 예외를 이미 알고 있어서 요건을 설명하고 기다리는 단계가 줄어듭니다. 쓰는 도구는 팀마다 다릅니다. 기업개발은 Codex를, 채권·회수는 skill을 붙인 ChatGPT 에이전트를 썼습니다. Figma Make로 화면을 만들기도 합니다. 반복이 잦고 담당자가 결과를 바로 검증할 수 있는 일에 맞습니다. 여러 팀이 같은 숫자를 봐야 하는 공식 지표는 담당자마다 따로 만들면 숫자가 갈라지므로 맞지 않습니다. 가상 예시로, 매주 같은 엑셀 세 개를 합치는 담당자라면 그 합치기 작업이 첫 도구 후보입니다.
Build vs Buy: 핵심 원장은 사고 워크플로는 만든다
Melwani가 그은 선은 단순합니다. System of Record(회사의 공식 기록이 저장되는 핵심 시스템)처럼 틀리면 안 되는 것은 삽니다. 그 위에서 데이터를 옮기고 맞추고 정리하는 워크플로 자동화는 직접 만듭니다. 만드는 쪽은 틀려도 되돌릴 수 있어서 담당자가 고쳐 가며 키웁니다. 사는 쪽은 감사와 결산이 기대는 곳이라 실험 대상이 아닙니다. 그는 감사인이 믿을 수준의 출력을 요구하는 핵심 시스템은 기준이 아주 높고 감사인과의 대화가 더 필요하다고 봤습니다. 이 구분이 없으면 담당자가 만든 도구가 원장에 직접 쓰기 시작해 통제가 무너집니다.
Data Plumbing: 어려움의 대부분은 데이터를 제자리에 모으는 일
Melwani는 도구를 만들 때 어려움의 약 95%가 데이터를 제자리에 모으는 일이라고 했습니다. Figma 재무가 다루는 데이터는 NetSuite, Salesforce, Stripe, Ramp 같은 여러 시스템에 흩어져 있습니다. 모델은 빠진 가정을 채워 주지만 연결은 대신해 주지 않습니다. 그래서 그는 출장·경비 분석처럼 방향을 보는 일에는 완벽한 정확도를 요구하지 않았습니다. AI가 맞춘 거래 매칭도 방향이 맞는 결과로 봤고 확정된 결과로 쓰지 않았습니다. 방향을 볼 분석인지 장부에 남길 결과인지를 먼저 정하면, 같은 데이터로도 요구 정확도와 검증 강도가 달라집니다.
Vibe-Code Diligence: 실사에서 대상 제품을 다시 만들어 본다
기업개발팀은 인수 후보를 볼 때 그 제품을 바이브 코딩(자연어 지시로 AI가 코드를 짜게 하는 방식)으로 재현할 수 있는지를 실사 항목으로 씁니다. 쉽게 다시 만들 수 있으면 기술 해자가 얕은 것입니다. 막히는 지점이 있다면 그곳이 그 회사의 깊이입니다. 재무가 모든 판단을 제품팀에 넘기지 않고 스스로 기술을 가늠하게 되고, 제품 조직과 이야기할 때 신뢰도 높아졌다고 합니다. 같은 팀은 Melwani, CEO Dylan Field, CRO 등 리더마다 투자 메모를 어떻게 읽을지 흉내 내는 skill을 만들어 메모를 미리 점검합니다. 실제 검토 전에 빈틈과 나올 질문을 먼저 찾는 용도입니다. 재현 기간과 판정 기준은 대담 요약에 나오지 않습니다.
Productization Gate: 개인 도구를 제품으로 올릴지 묻는 네 질문
Melwani는 Figma가 도구보다 빨리 커 버린 어수선한 중간 단계에 있다고 봅니다. 아래에서 만든 도구가 중앙 시스템 조직이 다듬는 속도보다 빨리 늘어납니다. 그래서 Coinbase 출신 CIO를 영입했고 녹화 하루 전에 합류했습니다. CIO 조직은 제품 관리처럼 움직여 아래에서 잘 되는 것을 찾고 그 위에 공통 기반을 놓는 역할입니다. 제품화 판단은 네 가지 질문으로 합니다. 상류 데이터가 바뀌면 알아채는가, 제대로 된 곳에 호스팅되는가, 만든 사람이 떠나도 살아남는가, 다른 사람도 필요로 하는가입니다. 네 질문을 넘지 못한 도구는 개인 도구로 남습니다.
통념과 다른 주장
흔히 이렇게 봅니다재무가 쓸 자동화와 분석 도구는 요건을 정리해 IT나 데이터팀에 맡겨야 품질이 선다.
Melwani는 이렇게 봅니다프로세스에 가장 가까운 재무 담당자가 직접 만들고, 여러 사람이 쓸 도구만 CIO 조직이 제품으로 다듬습니다.
근거채권·회수, 기업개발, 기업재무 담당자가 각자 도구를 만들어 운영하고 있습니다. 핵심 원장은 사서 쓰고 만드는 대상은 워크플로로 한정해 위험을 묶었습니다.
흔히 이렇게 봅니다AI가 모델링을 대신하면 엑셀 작업과 손으로 만드는 재무 모델은 사라진다.
Melwani는 이렇게 봅니다직접 모델을 만지며 쌓는 직관은 여전히 필요하고 AI는 그 위에서 큰 모델의 민감한 변수를 찾는 데 씁니다.
근거그는 엑셀을 자신이 가장 편하게 쓰는 언어로 부르고, 탭 20개짜리 모델을 AI에 넣어 결과를 크게 움직이는 입력을 찾습니다. 재무 부사장 채용 과제도 공개 자료로 모델을 만들게 한 뒤 구조와 핵심 입력을 이해하는지 묻습니다.
저자가 든 사례
채권·회수: 청구에서 대사까지 자체 시스템으로
- 상황: 청구서 추적, 수금, NetSuite 대사가 여러 시스템에 걸쳐 손으로 돌아갔습니다.
- 한 일: 채권·회수 담당이 이 흐름 전체를 Figma의 다른 시스템과 연결된 자체 시스템으로 다시 짰습니다. skill을 붙인 ChatGPT 에이전트를 썼고, 이어서 여러 데이터를 엮어 신용 점검도 새로 만들었습니다.
- 결과: 남은 시간을 DSO를 줄이는 일에 돌렸습니다. 줄어든 시간과 DSO 변화 수치는 대담 요약에서 밝히지 않았습니다.
- 연결: Owner, Not Ticket Filer, Build vs Buy.
기업개발: 실사에서 대상 제품 재현
- 상황: 인수 후보의 기술이 얼마나 깊은지 재무가 직접 판단하기 어려웠습니다.
- 한 일: 대상 제품을 바이브 코딩으로 재현해 보는 것을 실사 점검 항목으로 넣었고 Codex를 씁니다. 리더별 관점을 흉내 내는 skill로 투자 메모를 미리 점검합니다.
- 결과: 재무가 기술 해자를 스스로 가늠하고 경영진 검토 전에 빈틈을 메웁니다. 대상 기업과 재현 결과는 밝히지 않았습니다.
- 연결: Vibe-Code Diligence.
기업재무: 세 곳의 출장·경비 데이터 묶기
- 상황: 계획 수립에 쓸 출장·경비 데이터가 세 곳에 흩어져 있었습니다.
- 한 일: 세 출처를 fuzzy matching(이름·날짜처럼 정확히 같지 않은 값을 비슷한 정도로 짝짓는 방법)으로 묶어 실제 출장과 근처 직원이 사무실에 들른 경우를 갈랐습니다.
- 결과: 정책 변경안과 시각화를 만들었습니다. Melwani는 완벽한 정확도가 아니라 방향이 맞는 결과를 원했습니다.
- 연결: Data Plumbing.
기술 디테일: 재무 담당자가 만든 도구를 안전하게 돌리려면
아래 필드명, 설정값, 구성은 대담에 없는 실행 제안이며 가상 예시입니다.
대사 도구는 규칙 먼저, LLM은 남은 건에만 씁니다(채권·회수 사례, Build vs Buy). 금액, 청구서 번호, 고객 ID가 정확히 맞는 건은 코드로 처리합니다. 남은 건만 LLM에 넘겨 후보 2~3개와 근거를 받습니다. 원장 쓰기는 담당자 승인 뒤에만 엽니다. 에이전트에는 NetSuite 읽기 권한만 줍니다. 모델은 사내에서 승인한 하나로 고정하고 버전을 로그에 남깁니다. 출력은 아래처럼 구조화해 받고 temperature는 0으로 둡니다.
{
"payment_id": "PMT-2026-11-0412",
"candidates": [
{"invoice_id": "INV-88213", "score": 0.82, "reason": "금액 일치, 고객명 표기 차이"},
{"invoice_id": "INV-88190", "score": 0.41, "reason": "금액 일부 일치, 날짜 14일 차이"}
],
"result_type": "directional",
"needs_review": true,
"data_snapshot_at": "2026-11-08T09:00:00"
}결과에 directional과 auditable 꼬리표를 붙입니다(Data Plumbing). result_type이 directional이면 정책 검토나 계획용으로만 쓰고, 장부·공시에 들어가는 값은 auditable 경로(규칙 매칭, 담당자 승인, 변경 이력)를 거친 것만 씁니다. 출장·경비 같은 fuzzy matching 결과에는 매칭률과 임계값(예: 유사도 0.85 이상만 자동 매칭)을 함께 표시해 읽는 사람이 정밀도를 알게 합니다.
재현 실사는 시간을 정하고 점수표로 남깁니다(Vibe-Code Diligence). 한 사람이 Codex나 Claude Code 같은 코딩 에이전트로 최대 2일 안에 대상 제품의 핵심 기능 5개를 재현해 봅니다. 기능마다 0점(재현 안 됨), 3점(겉모습만 됨), 5점(대부분 됨)으로 매기고 막힌 이유를 데이터, 네트워크 효과, 자체 모델, 통합·규제 가운데서 고릅니다. 공개 화면과 문서만 쓰고 대상의 비공개 코드나 자료는 넣지 않습니다. 결과는 투자 메모 부록 한 장으로 붙입니다.
| 점수 | 뜻 | 메모에 쓰는 말 |
|---|---|---|
| 0 | 2일 안에 핵심 기능 재현 실패 | 막힌 이유가 곧 해자 후보 |
| 3 | 화면·흐름은 되나 품질·규모가 안 됨 | 데이터·운영 노하우 확인 필요 |
| 5 | 대부분 재현 | 기술 외 가치(고객·팀·데이터) 근거 필요 |
리더 관점 skill은 질문만 내게 합니다(Vibe-Code Diligence). 리더마다 지난 투자 메모에 단 코멘트 20~30개를 모아 관점을 정리하고, 출력은 questions, missing_evidence, risk_flags 세 필드로 제한합니다. 결론이나 찬반은 내지 않게 해야 실제 리더의 판단과 섞이지 않습니다. 같은 메모를 3회 돌려 2회 이상 나온 질문만 남기면 실행마다 달라지는 잡음이 줄어듭니다.
제품화 심사는 네 질문을 필드로 만듭니다(Productization Gate). 도구 카탈로그에 owner, upstream_sources, hosting, backup_owner, users, writes_to_ledger를 둡니다. backup_owner가 비었거나 hosting이 개인 환경이면 제품화 후보에서 뺍니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 원천 시스템 필드 변경 | 대사 도구가 조용히 틀린 값을 냄 | 상류 스키마 변경 감지, 매칭률 급락 시 경고 |
| 같은 지표를 담당자마다 따로 계산 | 회의마다 숫자가 다름 | 공식 지표는 한 정의만 두고 도구는 그 값을 읽기만 |
| 만든 사람 퇴사 | 아무도 못 고치는 도구 | backup_owner 필수, 90일 미사용 도구 보관 |
| AI가 만든 문서 범람 | 읽을 자료가 너무 많아짐 | AI 작성물 표시 규칙, 요약 한 쪽 원칙 |
현업 실행 디테일: 누가, 언제, 무엇을
대담은 담당자가 만들고, 기업개발이 실사에 쓰고, CIO 조직이 다듬는다고 전합니다. 아래 역할, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| CFO 또는 재무 리더 | 사는 것과 만드는 것의 경계 확정, 시범 범위 승인, 판정 |
| 업무 담당자 2~3명(채권, 경비, 결산) | 반복 업무 기록, 도구 제작과 병행 운영 |
| 기업개발 담당 1명 | 재현 실사 1건 시범, 리더 관점 skill 작성 |
| CIO·IT | 데이터 읽기 권한, 원장 쓰기 통제, 제품화 심사 |
| 내부통제·감사 | directional과 auditable 경계 검토 |
준비물. 담당자별로 매주 반복하는 작업 목록과 걸리는 시간, 쓰는 시스템과 파일, 최근 3개월 대사 예외 건, 최근 투자 메모 2~3건과 리더 코멘트, 출장·경비 원천 데이터가 필요합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 반복 업무 기록, 산다·만든다 경계 문서화, 데이터 권한 정리 | 도구 후보 목록, 시간 기준선 |
| 3~4주 | 담당자별 도구 1개 제작, 재현 실사 1건 | 도구 3개, 재현 점수표 |
| 5~7주 | 기존 방식과 병행 운영, 제품화 네 질문 심사 | 절감 시간, 오류 건수, 제품화 후보 |
| 8주 | 판정 회의 | 확대·보완·중단 결정 |
담당자에게 물을 것.
- 매주 같은 순서로 반복하는 일은 무엇이고 몇 시간이 드나요?
- 그 일에서 숫자를 맞추려고 여는 시스템과 파일은 몇 개인가요?
- 결과가 틀리면 누가 언제 알아채나요?
- 이 결과는 방향만 보면 되나요, 장부에 남나요?
- 내가 휴가를 가도 이 도구를 다른 사람이 돌릴 수 있나요?
진행 판정 기준(예시). 병행 운영에서 담당자별 반복 업무 시간이 30% 이상 줄고 auditable 경로의 오류가 기존보다 늘지 않으면 다른 팀으로 넓힙니다. 시간은 줄었는데 오류가 늘면 규칙 매칭 범위를 넓히고 3주 더 봅니다. 도구가 한 사람만 쓰는 상태로 남으면 제품화하지 않고 개인 도구로 둡니다.
AX 적용 제언. 재무 AX를 큰 플랫폼 도입부터 시작하지 말고 담당자 서너 명의 반복 업무에서 시작하는 편이 빠릅니다. 순서는 경계 긋기, 데이터 연결, 담당자 제작, 제품화 심사입니다. 핵심 원장 위에 읽기 전용 데이터 계층을 먼저 열어야 담당자가 안전하게 만들 수 있습니다. 인수 검토가 잦은 지주사나 투자 조직에는 재현 실사가 빨리 효과를 냅니다. 한 건만 해 봐도 제품팀 의견에 기대던 기술 평가를 재무가 스스로 점검하게 됩니다. 스폰서는 CFO가 맡고, CIO 조직은 처음부터 제품화 심사자로 들어와야 도구가 늘어도 통제가 섭니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | a16z Show 대담, 약 50분, 진행 Seema Amble·Ivan Makarov(a16z) |
| 화자 | Praveer Melwani, Figma CFO |
| 이전 방식 | 제품 지표와 Stripe 매출을 잇는 수백 줄 SQL, 엑셀 매크로 |
| 쓰는 도구 | Codex, skill을 붙인 ChatGPT 에이전트, Figma Make |
| 채권·회수 | 청구서 추적·수금·NetSuite 대사를 자체 시스템으로 재구축, DSO 단축에 집중, 신용 점검 재구축 |
| 기업개발 | 대상 제품 바이브 코딩 재현을 실사 점검 항목으로, 리더별 관점 skill로 투자 메모 사전 점검 |
| 기업재무 | 세 곳의 출장·경비 데이터를 fuzzy matching으로 묶어 정책 변경안과 시각화 |
| 데이터 | 어려움의 약 95%는 데이터를 제자리에 모으는 일 |
| 사고 만드는 기준 | 핵심 기록 시스템은 구매, 워크플로 자동화는 직접 제작 |
| 제품화 | Coinbase 출신 CIO 합류, 상류 의존성·호스팅·만든 사람 부재·수요 네 질문 |
| 통제 | 감사인이 믿을 수준의 출력은 높은 기준, AI 작성물 표시 내부 정책 |
| 채용 | 지적 호기심, 데이터 이해, 구조화된 소통. 재무 부사장 채용 과제로 공개 자료 모델링 |
| 인력 | 복잡도가 그대로면 인력이 줄겠지만 신제품·인수로 복잡도가 커지는 중 |
핵심 개념
- DSO
- Days Sales Outstanding. 매출을 올린 뒤 현금을 받기까지 걸리는 평균 일수입니다. 짧을수록 현금이 빨리 돕니다.
- Reconciliation(대사)
- 장부의 기록과 은행 입금이나 다른 시스템의 기록을 서로 맞춰 차이를 찾는 일입니다.
- NetSuite
- Oracle의 클라우드 ERP로, 회계 원장과 청구·수금을 관리합니다. Figma 재무 데이터의 한 축으로 나옵니다.
- Vibe coding
- 사람이 자연어로 원하는 것을 말하고 AI가 코드를 짜게 하는 개발 방식입니다.
- Figma Make
- 자연어 설명으로 동작하는 앱이나 화면을 만드는 Figma의 AI 기능입니다.
- Codex
- OpenAI의 코딩 에이전트입니다. 여기서는 기업개발팀이 제품 재현에 썼습니다.
- Moat(해자)
- 경쟁자가 쉽게 따라오지 못하게 막는 기술·데이터·고객 기반 같은 방어 요소입니다.
- T&E
- Travel and Expense. 출장비와 업무 경비를 묶어 부르는 말입니다.
내 메모
TODO: 내 생각 추가
원문은 a16z Show 에피소드 「The New CFO: How AI Is Rewriting the Finance Function」(Figma CFO Praveer Melwani, 2026.11)입니다. 에피소드 페이지를 직접 열지 못해 StartupHub.ai의 대담 기사(2026.11.5), BigGo Finance의 에피소드 요약과 녹취 발췌, a16z X 게시물의 소개문으로 내용을 확인했고 자료끼리 어긋나는 세부(이름 표기, 시간 단축 수치, 다른 회사 사례의 화자와 수치)는 넣지 않았습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 대담 내용을 AX Review가 다시 정리했습니다. 대사 흐름, JSON 예시, 재현 실사 점수표, 리더 관점 skill 설계, 제품화 필드, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 대담에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 대화는 원문 에피소드에서 들을 수 있습니다.