당신의 ML 팀이 방금 5 엔지니어-월을 들여 오픈소스 피처 스토어를 구축했습니다. 컨트롤러가 급여 명세서를 보며 팀 아무도 예상치 못한 질문을 던집니다. 그 18만 달러의 엔지니어링 시간은 이번 분기에 비용으로 잡히는 비용인가요, 아니면 대차대조표에 남는 자산인가요? 답에 따라 번 멀티플, 런웨이 계산, 그리고 자금을 조달 중이라면 재무제표가 들려주는 스토리가 달라집니다. 그리고 이는 Feast 위에 구축했는지 Tecton을 구매했는지에 따라 완전히 달라집니다.
피처 스토어는 머신러닝 피처를 훈련과 실시간 추론 모두를 위해 관리, 저장, 제공하는 인프라 계층입니다. 핵심 역할은 훈련-서빙 편향(training-serving skew)을 방지하는 것입니다. 즉, 모델이 훈련 시 사용한 것과 정확히 동일한 피처를 프로덕션에서 보도록 보장하는 것입니다. 아키텍처는 다섯 가지 구성 요소로 이루어집니다. 훈련 데이터용 오프라인 스토어, 저지연 서빙용 온라인 스토어, 값을 계산하는 피처 파이프라인, 중앙 피처 레지스트리, 그리고 서빙 API입니다. 팀이 Feast와 Tecton 중에서 선택할 때, 이는 두 가지 매우 다른 소유 모델 중에서 선택하는 것이며, 각 모델은 매우 다른 회계 처리를 낳습니다.
Feast vs. Tecton: 구축 대 구매의 트레이드오프
Feast는 선도적인 오픈소스 피처 스토어입니다. 무료로 사용할 수 있고, 자체 호스팅하며, 유연합니다. 온라인 스토어(일반적으로 Redis 또는 DynamoDB)를 직접 운영하고, 오프라인 스토어(S3, BigQuery, 또는 Snowflake)도 직접 운영하며, 모든 업그레이드, 장애 대응, 확장 결정을 책임집니다. Tecton은 완전 관리형 상용 대안으로, Uber의 Michelangelo 플랫폼을 만든 팀 구성원들이 개발했습니다. 엔터프라이즈 SaaS 계약 뒤에서 온라인 및 오프라인 서빙, 스트리밍 피처 계산, 내장 피처 모니터링을 처리합니다.
표준 비교는 다음과 같습니다.
| 요소 | Feast | Tecton |
|---|---|---|
| 라이선스 비용 | 무료 (인프라 비용만 발생) | 엔터프라이즈 SaaS 가격 |
| 온라인 서빙 | Redis, DynamoDB — 직접 운영 | 완전 관리형 |
| 오프라인 스토어 | Parquet, BigQuery, Snowflake — 직접 연결 | 관리형 |
| 스트리밍 피처 | 푸시 기반, 파이프라인 직접 구축 | 네이티브 실시간 계산 |
| 피처 모니터링 | 직접 조립하는 외부 도구 | 내장 |
| 운영 부담 | 높음 — 팀이 모든 것을 운영 | 낮음 — 공급업체 SLA |
회계와 관련된 버전의 이 표에는 행이 하나 더 있습니다. 바로 돈이 어디에 나타나는가입니다. Tecton의 경우 거의 모든 비용이 공급업체 청구서, 즉 구독 비용으로 들어옵니다. Feast의 경우 라이선스 항목은 0이고 실제 비용은 엔지니어링 인건비에 숨어 있습니다. 데이터 엔지니어가 레지스트리를 배포하고, 피처 파이프라인을 작성하고, 온라인 스토어를 튜닝하고, Feast가 제공하지 않는 모니터링을 구축하는 데 소비하는 주입니다. "라이선스 비용 제로" 오픈소스 인프라도 여전히 엔지니어링 시간에 대한 손익계산서 항목이 필요하며, 그 항목이 바로 ASC 350-40이 규율하는 대상입니다.
회계 질문: ASC 350-40이 실제로 말하는 것
미국 GAAP에서 사내 사용 소프트웨어 비용은 ASC 350-40의 적용을 받으며, 이는 소프트웨어 프로젝트의 모든 달러를 세 단계 중 하나로 분류합니다(일반적인 프레임워크는 자본화 대 비용화 결정에 관한 실무 가이드를 참조하세요):
- 예비 프로젝트 단계 — 발생 시 비용 처리. 공급업체 평가, 개념 증명 스파이크 실행, Feast와 Tecton 비교, 타당성 조사, 그리고 구축 대 구매 분석 자체. 이 모든 것이 즉시 손익계산서에 반영됩니다.
- 애플리케이션 개발 단계 — 적격 비용 자본화. 경영진이 프로젝트를 승인하고 확정한 후, 소프트웨어의 설계, 코딩, 구성, 테스트, 통합 비용은 자산으로 자본화되어 내용연수에 걸쳐 상각됩니다. 자산을 형성하는 유일한 단계입니다.
- 구현 후 및 운영 단계 — 발생 시 비용 처리. 교육, 유지보수, 버그 수정, 그리고 라이브 이후의 지속적인 운영. 나중에 추가되는 새로운 기능은 자본화를 다시 시작할 수 있지만, 유지 운영은 결코 그렇지 않습니다.
애플리케이션 개발 단계에 진입하려면 두 가지 조건이 충족되어야 합니다. 해당 권한을 가진 경영진이 프로젝트를 (암묵적 또는 명시적으로) 승인했고, 프로젝트가 완료되고 소프트웨어가 의도된 기능에 사용될 가능성이 높아야 합니다. 두 조건이 모두 충족될 때까지 모든 달러는 여전히 예비 단계 비용입니다. 나중에 프로덕션이 되는 "프로토타입"도 포함됩니다.
자본화는 적격 비용의 정의도 좁습니다. 구축 작업을 하는 개발자의 직접 급여, 복리후생과 같은 급여 관련 비용, 프로젝트에 참여하는 외부 개발자에게 지급하는 제3자 수수료는 일반적으로 적격입니다. 구 시스템으로부터의 데이터 변환, 교육, 유지보수, 일반 간접비, 관리 비용은 해당되지 않습니다. 애플리케이션 개발 기간 중에 발생하더라도 마찬가지입니다.
피처 스토어 작업을 세 단계에 매핑하기
일반적인 Feast 구축이 ASC 350-40에 어떻게 매핑되는지 살펴보겠습니다:
비용: 평가. 팀이 3주 동안 Feast와 Tecton을 벤치마킹하고, 샘플 파이프라인을 스파이크하고, 공급업체 문서를 읽습니다. 예비 단계 — 비용. 스파이크 코드가 나중에 프로덕션에서 재사용되더라도 마찬가지입니다. 단계는 코드가 무엇이 되는지가 아니라 그 당시 활동의 목적에 따라 판단됩니다.
자본화: 구축. 경영진이 Feast 결정을 승인하고 프로젝트에 자금을 지원합니다. 엔지니어는 이제 레지스트리를 배포하고, 프로덕션 피처 정의를 작성하고, 배치 및 스트리밍 파이프라인을 구축하고, 온라인 스토어를 추론 서비스와 통합하고, 통합 및 부하 테스트를 실행합니다. 이 기간 동안의 직접 엔지니어링 급여와 구현을 위한 계약자 수수료는 누가 언제 무엇을 했는지 문서화할 수 있다는 전제하에 자본화됩니다.
비용: 라이브 이후의 모든 것. 온콜 로테이션이 Redis 지연 시간을 튜닝하고, 파이프라인 버그 후 피처를 백필하고, 새 모델을 기존 파이프라인에 온보딩하고, Feast 버전을 업그레이드하고, 모니터링 대시보드를 유지 관리합니다. 구현 후 — 비용. 6개월 후에 새로운 제품 라인을 위한 스트리밍 파이프라인과 같이 진정으로 새로운 기능을 추가한다면, 그 개별적 개선은 자체 자본화 기간에 적격할 수 있습니다.
가장 흔한 실패 모드는 문서 흔적의 부재입니다. 프로젝트 단계별 실시간 시간 추적 없이 이루어진 자본화는 감사에서 살아남기 어렵습니다. 엔지니어의 시간이 피처 스토어 구축과 일상 업무에 대해 추적되지 않는다면, 감사인은 전부를 비용 처리할 것입니다. 어쨌든 그것이 맞는 답일 수도 있지만, 그것은 기본값이 아니라 결정이어야 합니다.
대신 Tecton을 구매하면 무엇이 달라지는가
관리형 피처 스토어를 구매하면 회계 그림이 뒤집힙니다. Tecton은 당신이 소유한 소프트웨어가 아니라 서비스 계약이므로, 구독료는 계약 기간에 걸쳐 인식되는 운영비입니다. 간단하고 예측 가능하며 감사에 강합니다.
미묘한 부분은 구현입니다. Tecton을 데이터 웨어하우스와 통합하고, 서빙 API를 추론에 연결하고, 피처 정의를 마이그레이션하는 등 사용 목적을 위한 SaaS 플랫폼 구성은 클라우드 컴퓨팅 지침에 따라 동일한 ASC 350-40 논리를 따릅니다. 기반 소프트웨어가 공급업체에 의해 호스팅되더라도 애플리케이션 개발 단계의 구현 비용은 자본화에 적격할 수 있습니다. 실제로 Tecton 구현은 대개 충분히 짧아서 많은 소규모 회사가 중요성 기준으로 비용 처리합니다. 그러나 통합에 6자리 수의 엔지니어링 시간이 소요된다면 동일한 단계 분석이 적용되고 동일한 문서화 기준이 유지됩니다.
자금 조달 중인 창업자를 위한 전략적 각주가 여기 있습니다. Feast 구축을 자본화하면 현재 기간 EBITDA와 매출총이익률이 개선되지만, 증가하는 상각 부담과 인수자의 실사 팀이 면밀히 검토할 자산을 대가로 치릅니다. Tecton 구독을 비용 처리하면 손익계산서가 런레이트 소진에 대해 정직해지지만 올해 수치는 더 무거워 보입니다. 어느 처리도 "더 낫지" 않습니다. 하지만 투자자는 당신이 어느 쪽을 선택했는지, 왜 그런지 물을 것이므로, 의도적으로 선택하고 그 근거를 문서화하세요.
ASU 2025-06: 단계 모델은 사라진다
3단계 프레임워크는 소프트웨어가 명확한 경계를 가진 순차적 워터폴 단계로 구축되던 1998년으로 거슬러 올라갑니다. 이는 애자일하고 반복적인 피처 스토어 작업에 잘 맞지 않습니다. 모든 스프린트가 프로덕션에 배포될 때 어느 스프린트가 "예비"입니까? FASB도 동의했습니다. 2025년 9월에 ASU 2025-06을 발표하여 단계 기반 규칙을 제거하고, 중요한 개발 불확실성이 남아 있는지에 초점을 맞춘 원칙 기반 프레임워크로 대체했습니다.
새 모델에서 자본화는 경영진이 프로젝트를 승인하고, 완료와 의도된 사용이 가능성이 높으며, 개념이 성능 요구사항, 개발 접근 방식, 또는 타당성에 대한 중요한 불확실성을 넘어섰을 때 시작됩니다. 2027년 12월 15일 이후 시작하는 회계연도에 발효되며 조기 적용이 허용됩니다. 오늘 시작하는 피처 스토어 구축의 경우 실무적 조언은 변함이 없습니다. 승인 메모를 확보하고, 구축에 대한 시간을 추적하고, 평가와 구축을 분리하십시오. 이러한 습관은 옛 단계와 새로운 원칙 모두를 충족합니다.
피처 스토어 구축을 위한 실무 플레이북
Feast, Tecton, 또는 제3의 옵션을 선택하든, 다섯 가지 관행이 회계를 깨끗하게 유지합니다:
구축 시작 전에 서면 승인을 받으십시오. CTO가 Feast 구축, 예산, 의도된 프로덕션 사용을 승인하는 이메일이 승인 기준을 충족합니다. 날짜를 기입하십시오. 감사인이 가장 먼저 요구하는 문서입니다.
첫날부터 단계별로 엔지니어링 시간을 추적하십시오. 평가 스파이크는 한 버킷에, 프로덕션 구축 작업은 다른 버킷에, 출시 후 유지보수는 세 번째 버킷에. 태그 기반 시간 추적 또는 스프린트 라벨링 모두 효과가 있습니다. 6개월 후 기억에서 분할을 재구성하는 것은 그렇지 않습니다.
직접 비용만 자본화하십시오. 구축 시간에 대한 개발자 급여와 복리후생, 그리고 구현에 연결된 계약자 청구서. 교육, 레거시 파이프라인으로부터의 데이터 마이그레이션, 간접비 배분, 온라인 스토어 운영을 위한 클라우드 인프라 청구서는 제외하십시오. 호스팅은 완성된 시스템의 운영 비용이지 구축 비용이 아닙니다.
방어할 수 있는 상각 내용연수를 선택하십시오. 사내 사용 소프트웨어는 일반적으로 3~5년에 걸쳐 정액 상각됩니다. 빠르게 변하는 오픈소스 위에 구축된 피처 스토어에서 주요 Feast 버전이 재구축을 강제할 수 있다면 짧은 쪽을 지지합니다. 자본화 메모에 근거를 문서화하십시오.
사실이 변하면 손상 검사를 하십시오. Feast 구축을 중도에 포기하고 Tecton과 계약한다면, 자본화된 자산은 손상된 것입니다. 상각하십시오. 피벗으로 피처 스토어가 지원하던 제품 라인이 죽는 경우도 마찬가지입니다. 더 이상 용도가 없는 자본화된 소프트웨어는 자산이 아닙니다.
감사 조정을 초래하는 흔한 실수
감사인이 인프라 자본화에서 발견하는 오류는 일관되게 우울할 정도입니다. 평가 단계를 자본화하는 것 — 공급업체 비교, 개념 증명, 스파이크 — 이 가장 빈번합니다. 예비 단계 작업은 아무리 유용하다고 입증되어도 결코 자본화할 수 없습니다. 개발로 위장한 유지보수를 자본화하는 것이 두 번째입니다. 서빙 지연 시간 튜닝과 피처 백필은 구축이 아니라 운영입니다. 세 번째는 메모의 부재입니다. 승인 문서, 단계 분석, 상각 근거가 없는 자본화 잔액은 일반 원칙에 따라 비용 처리됩니다. 네 번째는 환상적인 내용연수에 걸친 상각입니다. 매년 호환성을 깨는 변경을 배포하는 오픈소스 프로젝트에 붙은 인프라에 10년을 적용하는 것. 다섯 번째는 클라우드 청구서를 완전히 잊는 것입니다. 6자리 수의 연간 DynamoDB 및 컴퓨팅 런레이트를 무시하면서 급여를 조심스럽게 자본화하는 팀은 애초에 프로젝트를 정당화한 구축 대 구매 비교를 왜곡합니다.
자산이 될 수 있는 것처럼 구축을 추적하십시오
Feast 대 Tecton 결정은 보통 엔지니어링 자부심 대 공급업체 편의로 프레이밍됩니다. 이를 재무 질문으로 재구성하면 트레이드오프가 선명해집니다. Feast는 현금 보상을 상각 꼬리가 있는 자본 자산으로 전환하고, Tecton은 동일한 기능을 갱신일이 있는 깨끗한 운영비로 전환합니다. 런웨이 모델, 매출총이익률, 실사 스토리 모두 선택에 따라 달라집니다. 바로 그래서 회계가 아키텍처 검토 후의 각주가 아니라 검토 테이블의 한 자리를 차지할 자격이 있습니다.
이는 평범한 부기 규율에서 시작됩니다. 프로젝트 태그된 시간, 날짜가 있는 승인, 구축에 연결된 계약자 청구서, 그리고 감사인이 따라갈 수 있는 자본화 메모. 피처 스토어 비용이 현재 하나의 원장 계정에 미분화된 엔지니어링 급여로 있다면, 이미 자본화 옵션을 잃은 것입니다. 기록은 사후에 재구성할 수 없습니다.
재무 관리를 단순화하십시오
ML 인프라를 확장하면서 구축 대 구매 결정, 자본화된 소프트웨어, 상각 일정에 대한 명확한 재무 기록을 유지하는 것이 필수적입니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제를 제공하는 플레인 텍스트 회계를 제공합니다. 블랙박스도, 공급업체 종속도 없습니다. 무료로 시작하세요 그리고 개발자와 재무 전문가들이 왜 플레인 텍스트 회계로 전환하는지 확인하십시오.
