Tecton 인보이스에는 하나의 숫자가 적혀 있고, AWS 청구서는 나머지를 조용히 짊어지고 있으며, 어느 문서도 스스로를 피처 서빙의 전체 비용이라고 부르지 않습니다. 이 분리가 함정입니다. Tecton은 소비를 기준으로 가격을 책정합니다. 즉 Tecton이 실행하는 파이프라인의 컴퓨트 크레딧에 더해, 그 파이프라인이 고객님의 자체 계정 안에서 소비하는 클라우드 리소스까지 포함됩니다. 따라서 Tecton으로부터 받는 인보이스는 언제나 전체 지출의 일부일 뿐입니다. 장부에 인보이스만 기록하고 거기서 멈춘다면, 매출원가는 과소계상되고, 매출총이익률은 과대계상되며, 그 마진을 토대로 내리는 모든 가격 결정은 결코 완전하지 않았던 숫자 위에 세워지게 됩니다.
이 글에서는 Tecton이 실제로 어떻게 과금하고 청구하는지, 프로덕션 피처 서빙이 왜 매출원가에 속하는지, 선불 크레딧과 소비 약정을 어떻게 처리해야 하는지, 그리고 월말에 모든 금액이 올바른 계정에 안착하도록 전체를 어떻게 조정(reconciliation)하는지 설명합니다.
Tecton의 과금 방식: 좌석이 아닌 피처 뷰
Tecton은 머신러닝을 위한 관리형 피처 플랫폼입니다. 데이터에 대한 변환을 피처 뷰로 정의하면, Tecton이 배치 또는 스트리밍 파이프라인에서 이를 계산하고 그 결과를 모델에 서빙합니다. 대규모 학습 검색을 위한 오프라인 저장소와, 실시간 추론 중 저지연 검색을 위한 온라인 저장소가 있습니다. 셀 단위 라이선스를 세는 방식은 없습니다. 피처를 계산하고, 저장하고, 서빙하는 동안 플랫폼이 소비하는 것에 대해 비용을 지불합니다.
이 소비는 두 곳에서 청구되는 두 개의 버킷으로 나뉘며, 이것이 가장 먼저 체득해야 할 점입니다.
첫 번째 버킷은 Tecton 크레딧입니다. 이는 Tecton이 고객을 대신해 관리하는 컴퓨트를 포함합니다. 스트림 피처 뷰를 위한 Spark 스트리밍 컴퓨트 크레딧, 배치 피처 뷰를 위한 Spark 배치 컴퓨트 크레딧이 여기에 해당합니다. 플랫폼 사용량이 크레딧으로 환산되고, 그 크레딧이 Tecton 인보이스에 나타납니다.
두 번째 버킷은 인프라 자체이며, 고객님의 자체 클라우드 계정을 통해 청구됩니다. Tecton은 고객의 AWS 또는 GCP 환경 안에서 컴퓨트 및 스토리지 리소스를 관리하므로, 온라인 저장소 읽기·쓰기, Spark 클러스터 컴퓨트, 온라인 저장소 스토리지, S3 스토리지가 모두 Tecton이 아닌 고객의 클라우드 청구서에 잡힙니다. 한 채널로 프로비저닝하고 다른 채널로 조정하는 팀은 언제나 격차를 발견하게 됩니다. 피처 뷰의 진정한 비용은 두 버킷의 합이라는 점을 한 번 결정하고, 월말 추출이 Tecton 인보이스와 클라우드 청구서의 태그된 항목 모두를 포함하도록 하십시오.
스트림과 배치 피처 뷰는 서로 다르게 소비한다
비용 구성 요소는 피처 뷰 유형에 따라 다르며, 어떤 유형을 운영하는지 알면 어떤 항목을 주시해야 하는지 알 수 있습니다.
스트림 피처 뷰는 온라인 저장소 읽기·쓰기, Spark 스트림 클러스터 컴퓨트, Tecton Spark 스트리밍 컴퓨트 크레딧, S3 스토리지, 온라인 저장소 스토리지를 수반합니다. 배치 피처 뷰는 유사한 목록을 수반합니다. 온라인 저장소 읽기·쓰기, Spark 작업 클러스터 컴퓨트, Tecton Spark 배치 컴퓨트 크레딧, S3 스토리지가 그것이며, 여기서 스트리밍 특유의 요소는 빠집니다.
청구서를 움직이는 파라미터는 ML 엔지니어가 매일 내리는 설계 선택입니다. 연속 스트림 처리는 체크포인트와 쓰기를 간격 기반 처리보다 훨씬 자주 수행하므로 비용이 더 듭니다. 집계 윈도가 클수록 컴퓨트가 더 필요합니다. 늦게 도착하는 데이터를 위한 더 긴 워터마크는 메모리 요구량을 높입니다. 클러스터 구성은 모든 작업에 직접 가격을 매깁니다. 데이터 컴팩션은 스토리지 비용을 줄이고 읽기 성능을 개선합니다. 이 중 어느 것도 재무 설정이 아니라 재무적 결과를 낳는 엔지니어링 설정입니다. 그래서 이 플랫폼의 회계는 어떤 피처 뷰가 존재하고 무엇에 맞춰 튜닝되었는지에 관한 두 팀 간의 대화에서 시작됩니다.
비용 계층 구조는 돈이 어디로 가는지 알려준다
Tecton 자체의 안내는 비용 영향을 높은 것에서 낮은 것으로 순위를 매기며, 이 순서는 예상치 못한 비용이 어디서 나올지 예측해 주므로 외워둘 가치가 있습니다.
온라인 저장소 운영이 최상위에 있습니다. 온라인 저장소에 대한 쓰기는 일반적으로 가장 높은 인프라 비용이며, 특히 백필(새롭거나 변경된 피처 뷰를 위해 과거 피처를 재계산하는 것) 중이나 연속 스트림 처리 시에 그렇습니다. 백필은 계획된 급증입니다. 며칠 또는 몇 주 분량의 과거 계산과 대량의 쓰기가 하나의 기간에 압축되는 것입니다. 재무팀에 이 사실이 미리 알려지지 않으면, 그것이 발생한 달은 투자가 아니라 비용 초과처럼 보입니다.
컴퓨트 리소스가 두 번째입니다. 스트림 및 배치 처리를 위한 Spark 클러스터 비용으로, 구성과 워크로드에 따라 달라집니다. 스토리지가 세 번째입니다. 온라인 저장소 스토리지와 읽기, 그리고 S3로, 일반적으로 컴퓨트와 쓰기보다 영향이 낮습니다.
실질적인 결과는 청구서가 콘솔에 로그인하는 사람 수가 아니라 쓰기와 컴퓨트 이벤트에 의해 결정된다는 것입니다. 여기서 용량 계획이란 백필, 처리 모드, 집계 윈도를 관리하는 것이지 인원을 관리하는 것이 아닙니다.
프로덕션 피처 서빙이 매출원가인 이유
US GAAP에 따르면, SaaS 회사의 매출원가(매출원가 — cost of revenue)는 고객이 비용을 지불하는 서비스를 제공하는 직접 비용을 포함합니다. 호스팅 인프라, 클라우드 컴퓨트 및 스토리지, 제품에 내장된 서드파티 소프트웨어, 그리고 사용량에 따라 확장되는 그 밖의 모든 것이 여기에 해당합니다. 프로덕션 ML 제품을 위한 피처 서빙은 이 기준을 쉽게 통과합니다. 사기 탐지 모델이 거래를 채점하거나, 추천 엔진이 피드를 정렬하거나, 가격 책정 모델이 요율을 제시할 때, 온라인 저장소 읽기와 그 피처를 최신 상태로 유지하는 파이프라인은 그 뒤의 애플리케이션 서버만큼이나 직접적인 서비스 제공 비용입니다.
이 분류가 중요한 이유는 매출총이익률로 직결되기 때문입니다. 매출총이익률은 투자자, 대출기관, 인수자가 제품 경제성이 성립하는지 판단하는 데 쓰는 숫자입니다. 서빙 비용을 손익계산서의 영업비용 아래에 두면 매출총이익률이 부풀려지고 확장 스토리가 가려집니다. 실사팀은 어차피 고객의 총계정원장을 표준 SaaS 매출원가 정의에 맞춰 재매핑할 것입니다. 처음부터 올바르게 분류하면 고객 자신의 대시보드가 외부인이 계산할 것과 같은 이야기를 하게 됩니다.
그러나 모든 Tecton 지출이 매출원가에 속하는 것은 아닙니다. 이 분리는 벤더가 아니라 용도를 따릅니다.
- 프로덕션 서빙은 매출원가입니다. 실시간 추론을 위한 온라인 저장소 읽기·쓰기, 프로덕션 피처를 최신 상태로 유지하는 스트리밍 및 배치 파이프라인, 그 뒤의 스토리지가 모두 고객 대면 서비스를 제공합니다.
- 실험과 스테이징은 영업비용입니다. 개발용 피처 뷰, 오프라인 실험, 스테이징 환경은 서비스 제공이 아니라 연구개발을 지원합니다. 연구개발비로 기록하십시오.
- 학습 전용 작업은 판단이 필요합니다. 다음 모델 버전을 학습시키기 위해서만 존재하는 오프라인 피처 계산은 서비스 제공보다는 연구개발에 가깝습니다. 실시간 서빙을 위해 온라인 저장소에 공급되는 동일한 파이프라인은 매출원가입니다. 하나의 피처 뷰가 둘 다 수행할 때는 방어 가능한 배분 기준으로 배분하십시오. 환경별로 태그된 클라우드 지출이 대부분의 팀이 가진 가장 깔끔한 기준입니다.
Tecton은 컴퓨트 인스턴스와 온라인 저장소 리소스에 피처 뷰별로 태그를 붙이므로, 배분 데이터는 고객의 클라우드 비용 탐색기에 존재합니다. 회계 작업은 매핑을 한 번 결정하는 것입니다. 어떤 피처 뷰가 프로덕션을 서빙하고 어떤 것이 실험을 서빙하는지를 정하고, 매 결산마다 다시 논쟁하지 않고 매달 적용하는 것입니다.
Tecton을 구매하는 것은 비용이고, 동등한 것을 구축하는 것은 자본화될 수 있다
올바르게 처리할 가치가 있는 분류가 하나 더 있습니다. Tecton을 구매하는 팀은 위에서 설명한 대로 소비를 비용 처리하지만, 오픈소스 소프트웨어 위에 자체 피처 저장소를 구축하는 팀은 대신 자본화 문제에 직면합니다. 자체 운영을 위해 개발된 내부 사용 소프트웨어는 프로젝트가 예비 단계를 통과하면 자본화 요건을 충족할 수 있으며, 이는 엔지니어링 급여와 인프라를 기간 비용이 아닌 상각 자산으로 전환합니다.
어느 처리도 선택적인 색깔이 아닙니다. Tecton을 운영한다면, 플랫폼을 구축한 것처럼 인보이스를 자본화하지 마십시오. 자체 구축 저장소에서 Tecton으로 마이그레이션한다면, 기존 자본화 자산은 계속 상각되는 동안 새로운 소비는 매출원가에 잡힙니다. 서로 다른 두 항목, 서로 다른 두 이야기이며, 둘 다 동시에 옳습니다.
선불 크레딧과 약정은 먼저 자산이고, 나중에 비용이다
소비 기반 플랫폼은 흔히 선불 크레딧이나 연간 지출 약정을 판매하며, 둘 다 수익·비용 대응 원칙(matching principle)을 따릅니다. 대금 지급은 자산으로 기록하고, 혜택이 소비됨에 따라 비용 처리합니다. 공급업체에 미리 송금한 금액은 아직 어떤 비용도 아닙니다. 크레딧이 프로덕션 서빙에 사용되면 매출원가가 되고, 실험에 사용되면 연구개발비가 되며, 사용되지 않고 만료되면 손실이 됩니다.
실무적으로 이는 하나가 아닌 세 개의 분개를 의미합니다. 크레딧을 구매하면 선불 자산을 차변에 기입하고 현금을 대변에 기입합니다. 매달 실제로 소비된 만큼 잔액을 차감합니다. 프로덕션 소비는 매출원가로, 스테이징 소비는 연구개발비로 처리합니다. 크레딧에 만료일이 있다면 달력에 표시하십시오. 만료된 잔액은 실제 손실이며, 내년 정리 작업 중에 발견할 것이 아니라 계획된 손상차손으로 처리할 자격이 있습니다.
최소 구매(take-or-pay) 약정은 그 위에 발생주의 계상을 추가합니다. 계약이 분기 최소 지출을 약정했다면, 실제 소비와 최소치 중 큰 금액을 지불해야 합니다. 기간 말에 소비가 약정에 미치지 못하면, 어차피 지불할 부족분을 발생주의로 계상하십시오. 인보이스는 나중에 도착하겠지만, 부채는 대차대조표일 현재 존재하며 결산은 이를 반영해야 합니다.
월말 조정: 두 장의 청구서, 하나의 진실
Tecton은 청구 가능한 사용량 로그를 게시합니다. 플랫폼 사용과 그것이 크레딧으로 환산되는 방식에 관한 상세 CSV 기록으로, 사용 후 대략 하루 이틀 뒤에 고객의 자체 객체 스토리지에 저장됩니다. 태그된 클라우드 지출과 결합하면, 이 로그가 조정 작업이 의지하는 계량기 판독값입니다. 월간 프로세스를 세 소스, 즉 사용량 로그, Tecton 인보이스, 클라우드 청구서를 서로 대조하는 것으로 취급하십시오.
실행 가능한 결산 체크리스트는 다음과 같습니다.
- 한 달 전체의 사용량 로그를 추출합니다. 모든 프로덕션 피처 뷰의 크레딧과 모든 실험의 크레딧이 존재하는지, 마지막 이틀까지 포함되었는지 확인합니다. 로그 지연 때문에 매월 1일에 실행하는 결산은 데이터가 누락됩니다. 로그를 기다리든지, 아니면 실행률(run-rate)을 기준으로 마지막 며칠을 발생주의로 계상하고 다음 달에 정산하십시오.
- 미청구된 Tecton 부분을 발생주의로 계상합니다. 대부분의 소비 기반 청구처럼, 인보이스는 해당 기간이 지난 뒤에 도착합니다. 해당 월의 예상 크레딧을 환경별 분할에 따라 매출원가와 연구개발비로 발생주의 계상하고, 인보이스가 도착하면 이를 역분개하고 정산하십시오.
- 태그된 클라우드 지출을 추출합니다. 같은 기간의 피처 뷰 태그로 클라우드 비용 탐색기를 필터링합니다. 이것이 두 번째 버킷입니다. Spark 클러스터, 온라인 저장소 운영, 스토리지가 여기에 해당하며, 마찬가지로 프로덕션과 스테이징을 분할해야 합니다.
- 로그와 인보이스, 클라우드 청구서를 조정합니다. 사용량 로그는 Tecton 인보이스와 일치해야 하고, 태그된 클라우드 항목은 같은 방향으로 움직여야 합니다. 백필이 있는 달은 둘 다 급증합니다. 로그와 괴리되는 인보이스는 갱신 시점이 아니라 지금 제기해야 할 청구 질문입니다.
- 선불금과 약정을 차감합니다. 소비된 크레딧을 선불 자산에서 비용 처리하고, 약정 부족분이 있으면 발생주의로 계상하며, 잔여 잔액이 만료 전에 여전히 사용 가능해 보이는지 확인합니다.
가장 흔한 실패는 3단계입니다. Tecton 인보이스를 꼼꼼히 조정하면서도 클라우드 측 지출은 포괄적인 호스팅 항목 아래 더 큰 인프라 청구서 속에 숨어 있는 경우입니다. 클라우드 명세서에 하나로 합쳐진 컴퓨트 항목만 보인다면, 다른 무엇보다 먼저 태깅을 고치십시오. 태그되지 않은 지출은 배분할 수 없고, 배분되지 않은 지출은 언제나 잘못된 곳에 안착합니다.
장부에 기록된 구체적인 한 달
ML 플랫폼이 1월에 프로덕션 서빙에 대해 $40,000, 실험에 대해 $8,000의 Tecton 크레딧을 소비하고, 태그된 클라우드 지출 $12,000(프로덕션 $9,500, 스테이징 $2,500)이 발생했다고 가정합니다. 또한 분기 초에 $100,000의 크레딧을 선불로 지급했습니다. 1월 장부는 다음과 같습니다.
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:Tecton-Credits USD
2026-01-01 open Expenses:CostOfSales:Feature-Serving USD
2026-01-01 open Expenses:Research:ML-Experimentation USD
2026-01-01 open Liabilities:Accrued:Tecton USD
2026-01-01 open Liabilities:Accrued:Cloud USD
2026-01-05 * "Tecton" "Prepay Q1 consumption credits"
Assets:Prepaid:Tecton-Credits 100000.00 USD
Assets:Cash:Operating -100000.00 USD
2026-01-31 * "Tecton" "January credit consumption, prod serving plus experimentation"
Expenses:CostOfSales:Feature-Serving 40000.00 USD
Expenses:Research:ML-Experimentation 8000.00 USD
Assets:Prepaid:Tecton-Credits -48000.00 USD
2026-01-31 * "Cloud" "January tagged feature-platform infra, prod plus staging"
Expenses:CostOfSales:Feature-Serving 9500.00 USD
Expenses:Research:ML-Experimentation 2500.00 USD
Liabilities:Accrued:Cloud -12000.00 USD이 패턴은 일반화됩니다. 선불금은 자산이고, 소비는 환경별로 비용으로 이동시키며, 클라우드 측은 별도로 청구되므로 별도로 발생주의 계상합니다. 팀이 장부를 평문으로 유지한다면, 문서의 비용 추적 패턴이 피처 뷰별 분할로 자연스럽게 확장되며, 대시보드 뷰는 프로덕션 대 스테이징 추세를 매달 눈에 보이게 해줍니다.
마진을 잘못 표시하는 실수
소비 기반으로 청구되는 ML 인프라를 운영하는 팀에서 네 가지 오류가 반복적으로 나타납니다. 각각은 예방하기는 저렴하고, 재무제표 재작성을 거치며 되돌리기는 비쌉니다.
Tecton 인보이스를 전체 비용으로 기록하기. 인보이스는 하나의 버킷입니다. 매달 클라우드 측 컴퓨트, 온라인 저장소 운영, 스토리지가 비슷한 규모의 두 번째 버킷을 추가하며, 이를 누락하면 매출원가가 대략 절반 정도 과소계상됩니다. 둘 다 조정하든지, 아니면 둘 다 보고하지 마십시오.
선불금을 지급 시점에 비용 처리하기. $100,000의 크레딧 구매는 송금이 나가는 달의 $100,000 비용이 아닙니다. 크레딧이 소진됨에 따라 비용으로 전환되는 자산입니다. 지급 시점에 비용 처리하면 분기 초에 비용이 몰리고, 이후 달의 진정한 비용이 고갈되며, 소비 추세를 읽을 수 없게 됩니다.
스테이징을 매출원가로 분류하기. 실험용 피처 뷰, 모델 연구를 위한 오프라인 백필, 스테이징 환경은 연구개발비입니다. 이를 서빙 비용에 섞으면 매출원가가 과대계상되고, 고객에게 닿지도 않은 작업 때문에 매출총이익률이 불이익을 받습니다. 피처 뷰 태그는 바로 이 분할을 정직하게 유지하기 위해 존재합니다. 사용하십시오.
발생주의 계상을 건너뛰기. 소비는 후불로 청구되고, 사용량 로그는 하루 이틀 지연되며, 클라우드 청구서는 더 늦게 도착합니다. 발생주의 계상 없이 결산하면 부분적인 한 달을 완전한 한 달로 기록하게 되고, 누락된 날들은 다음 달에 정체불명의 차이로 나타납니다. 실행률을 기준으로 발생주의 계상한 뒤, 문서가 도착하면 정산하십시오.
이번 달의 마지막 유용한 단계는 사소합니다. 클라우드 비용 탐색기를 열고, 피처 뷰 태그로 필터링하고, 거기서 보이는 숫자가 장부에 있는 숫자인지 확인하십시오. 둘이 한 번도 만난 적이 없다면, 방금 이 글이 메우기 위해 쓰인 격차를 발견한 것입니다.
