3인 규모의 카오스 엔지니어링 회사가 중견 핀테크 고객사를 위해 게임데이를 진행하고, 2주간의 프로젝트에 대해 $18,000를 청구하며, 고객사가 직접 조달하고 싶어하지 않았던 연간 $4,000 상당의 Gremlin 또는 AWS Fault Injection Simulator 라이선스도 대신 전달(패스스루)한다. 6개월 후, 창업자는 "컨설팅 수익" $22,000를 보여주는 손익계산서를 들여다보며 단순한 질문 하나에 답하지 못한다. 소프트웨어 재판매 대리인 역할을 무보수로 수행한 부분을 제외하면, 실제 엔지니어링 작업의 수익성은 얼마나 되는가?
이는 점점 더 흔해지는 문제다. 카오스 엔지니어링이 넷플릭스만의 특이한 관행에서 벗어나 엔터프라이즈 복원력 프로그램의 표준 항목으로 자리 잡으면서, 이를 중심으로 한 부티크 컨설팅 회사들이 물결처럼 생겨났다 — 복원력 감사를 수행하고, 게임데이 워크숍을 진행하며, 전담 SRE 팀을 고용하고 싶어하지 않는 고객사를 위해 자동화된 장애 주입 파이프라인을 구축하는 식이다. 엔지니어링 작업 자체는 잘 이해되어 있다. 하지만 기장(記帳)은 대개 그렇지 않은데, 이는 이런 회사들이 하나의 법인 안에서 근본적으로 다른 두 가지 사업을 운영하고 있기 때문이다. 즉, 들쭉날쭉하고 프로젝트 기반인 수익을 내는 서비스 사업과, 반복적이고 저마진이며 패스스루 성격의 현금흐름을 내는 소프트웨어 재판매 사업이다. 이 둘을 계정과목표에서 섞어 놓으면 실제로 어느 쪽이 돈을 벌고 있는지가 가려진다.
카오스 엔지니어링 회사가 다른 컨설팅 회사보다 이 문제를 더 자주 겪는 이유
일반적인 전략 컨설팅 회사는 시간 단위로 청구하면 그것으로 끝이다. 반면 카오스 엔지니어링 실무는 대개 서너 개의 서로 다른 수익원이 동시에 돌아간다.
- 복원력 감사 — 장애 주입이 실제로 이루어지기 전에 고객사의 아키텍처, 의존성 그래프, 장애 지점을 검토하는 고정 수수료 또는 시간제 프로젝트. 진단 성격의 작업으로, 보통 보고서와 우선순위가 매겨진 실험 백로그 형태로 전달된다.
- 게임데이 퍼실리테이션 — 팀이 장애 시나리오를 계획하고, 이를 스테이징 또는 프로덕션 환경에서 실행하며, 고객사의 엔지니어들이 인시던트 대응을 하도록 코칭하는 실제 라이브 이벤트. 게임데이는 시스템뿐 아니라 그 주변의 사람과 런북까지 테스트하기 때문에, 지속적인 자동화 카오스 테스트와는 가격 책정 및 범위 설정 방식이 다르다.
- 자동화 및 플랫폼 구축 — CI/CD 안에 반복 실행되는 카오스 실험을 구축하는 작업으로, 워크숍보다는 소프트웨어 엔지니어링 납품에 가까우며 마일스톤이 있는 프로젝트로 청구되는 경우가 많다.
- 툴링 재판매 또는 패스스루 — Gremlin, Harness Chaos Engineering 같은 플랫폼의 라이선스를 재판매하거나 관리해 주고, AWS Fault Injection Simulator나 Azure Chaos Studio 같은 클라우드 네이티브 서비스를 고객사를 대신해 설정해 주는 것으로, 때로는 마진을 붙이고 때로는 편의상 원가 그대로 제공한다.
이들 각각은 비용 구조가 다르고 마진 프로파일이 다르며 — 결정적으로 — 미국 기반 법인이 은행, 투자자, 혹은 스스로의 의사결정을 위해 GAAP에 준하는 장부를 준비한다면 ASC 606 하에서 수익 인식 처리 방식도 다르다. 이를 하나의 "컨설팅 수익" 계정에 몰아넣으면, 게임데이 퍼실리테이션이 80%의 마진을 내는 반면 툴링 재판매는 8% 마진에 불과해 관리 부담을 고려하면 거의 남는 게 없다는 사실을 볼 수 없게 된다.
고객사가 아니라 수익원별로 계정과목표를 구성하기
카오스 엔지니어링 컨설팅 회사가 할 수 있는 가장 효과 큰 기장 변화 하나는, 수익 계정을 고객사나 인보이스가 아니라 제공한 작업 유형별로 나누는 것이다. 전형적인 구성은 다음과 같다.
Income:Consulting:ResilienceAudits
Income:Consulting:GameDayFacilitation
Income:Consulting:AutomationBuildOut
Income:ToolingResale:Licenses
Income:ToolingResale:CloudUsagePassThrough번들 형태의 프로젝트 — 예를 들어 복원력 감사 후 게임데이가 이어지고 Gremlin 라이선스가 포함된 경우 — 를 고객사에 청구할 때, 하나의 인보이스라도 장부에서는 최소 세 개의 위 계정으로 나누어 기록해야 하며, "프로젝트 X — $22,000"라는 하나의 뭉뚱그린 항목으로 기록해서는 안 된다. Beancount 같은 복식부기 방식의 플레인 텍스트 포맷에서는, 이것이 여러 개의 포스팅을 가진 하나의 트랜잭션이 된다.
2026-07-16 * "Fintech Client Co" "Resilience audit + game day + Gremlin license"
Assets:AccountsReceivable:FintechClientCo 22000.00 USD
Income:Consulting:ResilienceAudits -6000.00 USD
Income:Consulting:GameDayFacilitation -12000.00 USD
Income:ToolingResale:Licenses -4000.00 USD이 트랜잭션 하나만 있으면, 회계사가 3월에 왜 마진이 들쭉날쭉해 보이는지 물어볼 때 기억이나 오래된 제안서로부터 재구성할 필요 없이, 언제든 서비스 라인별 실제 수익성 보고서를 뽑아볼 수 있다.
툴링 재판매의 함정: 패스스루 vs. 마크업 vs. 대리인
타사 카오스 엔지니어링 툴링 라이선스를 재판매하거나 관리해 주는 부분에서 이런 회사들의 장부와 세무 처리가 가장 자주 잘못된다. 여기에는 세 가지 뚜렷이 다른 방식이 있으며, 이들은 절대 같은 원장 계정을 공유해서는 안 된다.
- 순수 패스스루: Gremlin에 라이선스 비용으로 $4,000를 지불하고, 고객사에는 정확히 $4,000를 청구하며 마진을 붙이지 않는다. 일부 회사는 이를 총액이 아니라 순액(마진, 즉 $0)으로 기록한다. 계약서(engagement letter)상 귀사가 재판매업자가 아니라 고객사를 위한 구매 대리인으로 규정되어 있다면, 이는 ASC 606 하의 대리인-대 본인 처리 대상이 될 수 있다 — 즉 벤더 지급과 고객사 상환을 매출과 매출원가를 부풀리는 대신 상계 처리로 기록하는 것이다. 이는 중요한데, 대출 약정(코버넌트)부터 인수자가 매출 배수로 회사 가치를 평가하는 방식까지 모든 것에 영향을 미치는 최상단 매출 수치를 바꾸기 때문이다.
- 마크업 재판매: 동일한 라이선스를 $4,000에 구매해 고객사에는 $5,000를 청구하고, $1,000의 스프레드를 남긴다. 이 경우 귀사는 본인(principal)으로 행동하는 것이다 — 재화나 서비스가 고객에게 이전되기 전에 귀사가 그것을 통제한다 — 따라서 $5,000 전액을 매출로, $4,000를 매출원가로 기록해야 하며, $1,000로 순액 처리해서는 안 된다. 순액으로 기록하면 인수자나 대출기관이 별도로 보고 싶어할 매출과 매출원가 항목을 모두 과소평가하게 된다.
- 고객사가 직접 조달: 가장 깔끔한 방식 — 고객사가 자체적으로 Gremlin이나 FIS 계약을 맺고, 귀사는 그것을 관리만 해 준다. 귀사의 장부에는 아무것도 반영되지 않으며, 이 때문에 규모가 커질수록 더 많은 컨설팅 회사가 고객사에게 직접 조달을 유도하고 있다. 저마진에 현금흐름 타이밍 리스크가 있는 사업 라인 전체를 손익계산서에서 제거할 수 있기 때문이다.
어떤 방식을 쓰든, 고객사 관계별로 하나를 선택해 일관되게 적용해야 한다 — 문서화된 이유 없이 같은 벤더에 대해 고객사마다 대리인 처리와 본인 처리를 섞어 쓰는 것은, 정상적인 기장 검토를 지루하게 늘어지는 조사로 바꿔버리는 전형적인 비일관성이다.
고정 수수료 감사 vs. 마일스톤 기반 게임데이의 수익 인식
복원력 감사와 게임데이 워크숍은 보통 고정 수수료로 판매되는데, ASC 606 하에서 이는 "인보이스가 지급되는 순간 전액을 인식한다"는 뜻이 아니다. 이 기준은 수행 의무가 충족되는 시점에 수익을 인식하도록 요구하며, 이는 고객사가 귀사가 전달하는 대로 혜택을 받고 소비하는지 여부에 따라 특정 시점 또는 기간에 걸쳐 이루어진다.
- 복원력 감사가 2주짜리 프로젝트 끝에 단일 보고서 형태로 전달된다면, 이는 대개 특정 시점 인식이다. 선불로 50%를 청구했더라도 보고서가 전달되고 승인될 때까지는 매출로 잡히지 않는다. 그 보증금은 전달 시점까지 부채 계정(
Liabilities:DeferredRevenue:ResilienceAudits)에 머문다. - 여러 날에 걸친 게임데이 프로젝트가 일별 산출물 — 장애 시나리오 문서, 인시던트 타임라인, 최종 회고 — 을 갖는 경우, 고객사가 마지막에 한 번에 몰아서가 아니라 점진적으로 가치를 받고 사용하기 때문에 기간에 걸친 인식 대상이 되는 경우가 많다.
- 자동화 구축은 계약상 마일스톤(스테이징 파이프라인 가동, 프로덕션 실험 스케줄링, 대시보드 인계)이 있는 경우 마일스톤별로 인식해야 하며, 이는 프로젝트 종료 시점의 큰 결제 한 건을 기다리지 않아도 되므로 현금흐름 예측도 훨씬 쉬워진다는 부수 효과가 있다.
이를 잘못 처리하면 나중에 감사에서 골치 아픈 문제가 생기는 데 그치지 않는다 — 실시간으로 사업을 바라보는 자신의 시각 자체를 왜곡시킨다. $30,000의 보증금을 입금된 그날 매출로 기록하고 두 달 뒤에야 감사를 전달하는 회사는, 1개월 차에는 실제보다 훨씬 수익성이 좋아 보이고 3개월 차에는 훨씬 나빠 보일 것이며, 이는 다음 엔지니어를 채용할지 결정하는 데 나쁜 근거가 된다.
프로젝트 유형별 가동률과 실제 마진 추적하기
수익이 올바르게 나뉘면, 다음 단계는 그에 대응하는 비용을 매핑하는 것이다. 카오스 엔지니어링 컨설턴트는 보통 시니어 요율로 청구되므로, 다른 저마진 서비스 사업보다 여기서 인건비 배분이 더 중요하다. 각 프로젝트 유형별로 다음을 추적해야 한다.
- 직접 노동 시간을 (넓은 의미의 "컨설팅 시간"이 아니라) 해당 특정 프로젝트에 대해 추적한다 — 이는 40시간으로 산정했던 복원력 감사가 실제로는 65시간이 걸렸고 다음번에는 가격을 다시 책정해야 한다는 사실을 알려준다.
- 툴링 비용을 라이선스 구매를 유발한 특정 고객사 관계에 배분하고, 일반 소프트웨어 비용 항목에 뭉뚱그리지 않는다.
- 대면 게임데이의 출장 및 현장 비용은, 그 외에는 동일한 원격 프로젝트의 마진을 크게 바꿀 수 있다.
그 결실은 실제로 유의미한 프로젝트 유형별 마진 보고서다. 이 업계의 많은 회사들은 복원력 감사와 자동화 구축이 순수 엔지니어링 시간이기 때문에 가장 강한 마진을 내는 반면, 프리미엄 일일 요율을 받는 퍼실리테이션 게임데이는 시니어 퍼실리테이터의 시간, 출장, 사전 시나리오 설계 비용을 모두 반영하면 오히려 마진이 더 얇다는 것을 발견한다. 장부가 분리되어 있지 않으면 이는 보이지 않는다. 분리되어 있으면, 다음 잠재 고객과의 가격 협상이 간단명료해진다.
재무 기록에도 엔지니어링 규율을 적용하라
카오스 엔지니어링 실무자라면 곧바로 공감할 만한 자연스러운 유사점이 여기 있다. 이 분야 전체는 테스트해 보지 않은 시스템은 신뢰할 수 없으며, 불투명하고 점검하기 어려운 인프라는 언젠가 자신을 무너뜨릴 장애 모드를 숨긴다는 발상 위에 세워져 있다. 스프레드시트나, 요청하지도 않았는데 툴링 재판매를 컨설팅 수익과 상계해 버리는 블랙박스형 회계 SaaS 도구도 마찬가지다 — 마진이 잘못되었다는 사실은 이미 피해가 발생한 뒤에야 알게 된다. 플레인 텍스트로 작성되고 버전 관리되는 장부는, 인프라를 코드로 관리할 때 원하는 것과 마찬가지로 모든 포스팅을 점검하고, diff로 비교하고, 감사할 수 있게 해 준다. 그리고 수익원을 트랜잭션 단위에서 (나중에 기억으로 재구성하는 것이 아니라) 분리해 두는 것이야말로, 매달 하는 수익성 검토를 매달 하는 고고학 발굴 작업이 아니라 실제로 가능한 일로 만들어 준다.
재무 관리를 단순화하세요
카오스 엔지니어링 실무가 창업자 혼자 이끄는 회사에서 여러 프로젝트를 동시에 진행하는 팀으로 성장하면서, 복원력 감사 수익, 게임데이 퍼실리테이션, 툴링 재판매를 깔끔하게 분리해 두는 것이야말로 가격 책정 결정과 마진 분석을 애초에 가능하게 만드는 요소다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제력을 제공하는 플레인 텍스트 회계 서비스입니다 — 블랙박스도, 벤더 종속도 없습니다. 무료로 시작하기를 통해 개발자와 기술 컨설팅 회사들이 왜 플레인 텍스트 회계로 전환하고 있는지 확인해 보세요.