ASC 350-40에 따른 소프트웨어 자산화: 자본화 대 비용 처리 결정에 대한 실무 가이드

2024년 Gartner 설문 조사에 따르면 초기 단계 SaaS 창업자의 63%가 소프트웨어 개발 비용을 잘못 분류하는 것으로 나타났습니다. 이 실수는 두 가지 측면에서 비용을 발생시킵니다. 분류가 허술해 보이면 투자자들이 재무 상태를 낮게 평가하고, 실사 과정에서 감사인이 이 문제를 지적하여 자금 조달 라운드나 매각 프로세스가 수개월 지연될 수 있습니다.

소프트웨어 자본화는 단순한 회계 기술적 문제가 아닙니다. 이는 EBITDA, 대차대조표, 그리고 대출 기관, 투자자 및 인수자에게 비즈니스가 어떻게 보이는지에 직접적인 영향을 미칩니다. ASC 350-40의 규칙(및 2025년 주요 업데이트)은 어떤 비용을 즉시 손익계산서에 반영할지, 그리고 어떤 비용을 수년에 걸쳐 분산할지를 결정합니다.

이 가이드는 표준이 요구하는 사항, ASU 2025-06의 최근 개정 내용, 자본화할 수 있는 비용과 그렇지 않은 비용, 그리고 이를 올바르게 처리했을 때 재무제표에 미치는 영향을 설명합니다.

ASC 350-40의 적용 범위

ASC 350-40은 내부 사용 소프트웨어에 대한 FASB(재무회계기준위원회) 표준입니다. 이는 회사가 주요 제품으로 고객에게 판매하기 위해서가 아니라 자체 운영을 위해 구축하거나 구매하는 소프트웨어를 의미합니다. 예시는 다음과 같습니다:

• 내부 CRM, ERP, HR 또는 회계 시스템
• 클라우드 인프라 툴링 및 DevOps 플랫폼
• 고객을 위해 운영하는 SaaS 플랫폼 (고객이 설치하는 라이선스 소프트웨어가 아니라 서비스로서 액세스하는 경우)
• 내부 데이터 파이프라인, 대시보드 및 분석 도구
• 맞춤형 워크플로우 또는 백오피스 자동화

고객이 자신의 기기에 설치하는 라이선스 소프트웨어를 판매하는 경우, 이는 규칙이 다른 ASC 985-20(외부 판매용 소프트웨어)에 해당합니다. 대부분의 현대적 SaaS 기업은 고객이 호스팅된 서비스 형태로 소프트웨어를 사용하기 때문에 ASC 350-40의 적용을 받습니다.

이 표준이 답하는 핵심 질문은 다음과 같습니다: 소프트웨어 구축에 돈을 쓸 때, 그 비용을 즉시 비용으로 처리해야 할까요, 아니면 무형 자산으로 자본화하여 향후 기간에 걸쳐 상각해야 할까요?

기존의 3단계 모델 (ASU 2025-06 이전)

수십 년 동안 ASC 350-40은 단계 기반 프레임워크를 사용해 왔습니다. 2027년까지 대부분의 공시 기업에 여전히 유효한 기존 지침에 따르면, 소프트웨어 개발은 세 가지 개별 단계로 나뉩니다.

1단계: 예비 프로젝트 단계 (Preliminary Project Stage)

이 단계는 요구 사항 정의, 기술 평가, 벤더 데모 확인, 구축/구매/포기 여부 결정 등 탐색 단계입니다. 이 단계의 모든 비용은 연구 비용과 유사하게 발생 시 비용으로 처리됩니다. 그 이유는 경영진이 확약하기 전까지는 아직 확률적인 자산이 존재하지 않기 때문입니다.

여기에 포함되는 활동은 다음과 같습니다:

• 개념 정립 및 설계 대안 검토
• 벤더 데모 및 기술 평가
• 비용 대비 편익 분석 및 타당성 조사
• 접근 방식 또는 벤더의 최종 선정

2단계: 애플리케이션 개발 단계 (Application Development Stage)

자본화는 경영진이 프로젝트를 승인하고 자금을 할당하며 완료 가능성이 높을 때 시작됩니다. 이 단계는 코딩, 테스트, 구성, 통합 및 설치와 같은 실제 구축 작업을 포함합니다.

이 단계에서 자본화 가능한 비용은 다음과 같습니다:

• 개발자, QA 엔지니어 및 프로젝트 매니저의 급여 및 복리후생 (소프트웨어 코딩, 테스트 및 구성에 직접 귀속되는 시간만 해당)
• 개발 작업을 위한 외부 컨설팅 수수료
• 애플리케이션 구축에 사용된 소프트웨어 라이선스 및 도구
• 개발 과정에서 소비된 재료 및 서비스의 직접 비용
• 이자 비용 (제한적인 경우)

자본화는 소프트웨어가 실질적으로 완료되고 의도된 용도로 사용할 준비가 되었을 때(일반적으로 테스트가 완료되고 배포가 점진적이더라도 시스템이 운영 환경에 배포되었을 때) 중단됩니다.

3단계: 구현 후 단계 (Post-Implementation Stage)

운영 시작 후 발생하는 지속적인 비용은 다시 비용 처리로 전환됩니다. 교육, 유지 보수, 버그 수정 및 일상적인 지원은 모두 비용으로 처리됩니다. 예외적으로, 기존 기능을 수정하거나 유지하는 것이 아니라 새로운 기능을 추가하는 개선 사항(Enhancements)은 2단계와 동일한 기준을 사용하여 자본화할 수 있습니다.

2025년 주요 업데이트: ASU 2025-06

2025년 9월 18일, FASB는 ASC 350-40을 대폭 현대화한 ASU 2025-06을 발표했습니다. 이 업데이트는 2027년 12월 15일 이후 시작되는 연간 기간부터 의무화되며, 조기 도입이 허용됩니다.

변화는 구조적입니다. 3단계 모델이 사라졌습니다. FASB는 요구 사항이 진화하고 "단계"가 겹치거나 병렬로 실행되는 현대의 애자일 및 반복적 개발 관행에 기존 프레임워크가 맞지 않았기 때문에 프로젝트 단계에 대한 모든 참조를 명시적으로 제거했습니다.

새로운 원칙 기반 임계값

개정된 표준에 따라 다음 두 가지 조건이 모두 충족될 때만 소프트웨어 비용을 자본화합니다:

1. 경영진 승인: 경영진이 프로젝트를 승인하고 자금 지원을 확약했습니다.
2. 완료 가능성 임계값: 프로젝트가 완료되고 소프트웨어가 의도한 기능을 수행할 가능성이 높습니다(Probable).

두 번째 테스트가 실질적인 역할을 합니다. FASB는 완료 가능 여부를 평가하기 위해 **상당한 개발 불확실성(significant development uncertainty)**이라는 개념을 도입했습니다. 다음을 평가해야 합니다:

• 소프트웨어에 코딩이나 테스트를 통해 검증되지 않은 새롭거나 입증되지 않은 기능이 포함되어 있는지 여부
• 성능 요구 사항이 여전히 미정 상태이거나 대폭 수정될 가능성이 있는지 여부

상당한 불확실성이 존재하는 경우, 불확실성이 해소될 때까지 자본화를 유예해야 합니다. FASB는 요구 사항이 지속적으로 반복되는 SaaS 기업에서 이 새로운 규칙으로 인해 더 많은 소프트웨어 비용이 비용으로 처리될 것으로 예상한다고 신호를 보냈습니다.

실제적인 의미

진정으로 새로운 것(AI 에이전트 플랫폼, 새로운 자동화 엔진 등)을 구축하는 스타트업의 경우, 새로운 규정으로 인해 초기 운영 비용(OPEX) 지출이 더 많아질 수 있습니다. 잘 정의된 시스템을 개선하는 성숙한 기업의 경우 실질적인 영향은 더 적을 것입니다. 어느 쪽이든, 기계적인 단계 확인에서 판단 중심의 임계치로 이동한다는 것은 기업이 경영진의 결정, 기술적 실현 가능성 및 프로젝트 상태에 대해 더 명확한 문서화가 필요함을 의미합니다.

자산화할 수 있는 것과 없는 것: 실무 체크리스트

기존의 단계별 모델을 적용하든 새로운 원칙 중심의 테스트를 적용하든, 자산화 가능한 지출과 비용 처리해야 할 지출 사이의 경계는 본질적으로 유사합니다. 다음은 실무적인 체크리스트입니다.

일반적으로 자산화 가능

• 구축 단계 동안 개발자, 디자이너 및 QA의 직접 노무비
• 해당 직원에 대해 배분된 급여세 및 복리후생비
• 개발 작업을 위한 외부 컨설팅 및 계약업체 수수료
• 개발에 직접 소비된 소프트웨어, 도구 및 클라우드 인프라 비용
• 출시 후 새로운 기능을 개발하는 비용(역량을 실질적으로 확장하는 개선 사항)
• 데이터 변환 활동 자체가 아닌, 변환 소프트웨어(기존 데이터를 새 데이터로 마이그레이션하는 소프트웨어) 개발 비용

일반적으로 비용 처리

• 사전 조사, 업체 선정 및 실현 가능성 분석
• 새 시스템에 대한 직원 교육
• 데이터 정제, 대조 및 기록 마이그레이션
• 일상적인 유지보수, 버그 수정 및 사소한 리팩토링
• 상당한 개발 불확실성이 존재하는 기간 동안 발생한 소프트웨어 비용
• 개발과 직접 관련이 없는 일반 관리 간접비
• 마케팅, 지원 및 출시 후 고객 성공(Customer Success) 활동

시간 추적의 문제

가장 큰 실무적 과제는 엔지니어링 시간을 배분하는 것입니다. 주당 40시간을 근무하는 시니어 엔지니어가 100% 자산화 가능한 작업만 수행할 가능성은 낮습니다. 그들은 운영 환경의 버그를 수정하고, 팀원을 멘토링하며, 스탠업 미팅에 참여하고, 기존 시스템의 풀 리퀘스트를 리뷰하기도 합니다. 근거 있는 시간 추적 방법(프로젝트별로 태그가 지정된 엔지니어링 티켓, 시간 추적 소프트웨어 또는 공식적인 배분 조사)이 없다면, 자산화 추정치는 감사의 정밀 검토를 통과하기 어려울 것입니다.

재무제표에 미치는 영향

동일한 금액을 자산화하느냐 비용 처리하느냐에 따라 재무제표는 극적으로 달라집니다.

손익계산서 영향

자산화된 비용은 지출된 기간의 손익계산서에 즉시 반영되지 않습니다. 대신 상각(일반적으로 내부 사용용 소프트웨어의 경우 3~5년에 걸쳐 정액법 적용)됩니다. 따라서 1년 차에 자산화된 100만 달러의 엔지니어링 지출은 매년 20만 달러에서 33.3만 달러의 상각비만 발생시키므로, 1년 차 영업이익은 실질적으로 더 높게 나타납니다.

이것이 바로 자산화로 인해 EBITDA가 상승하는 이유입니다. 상각비는 정의상 EBITDA에서 제외되므로, 더 많은 개발 비용을 자산화하면 해당 금액이 영업 비용(EBITDA를 감소시킴)에서 상각비(EBITDA에 영향을 주지 않음)로 이동하게 됩니다. SaaS 지표를 면밀히 분석하는 투자자들은 이러한 역학 관계를 꿰뚫어 보기 위해 "자산화된 R&D 차감 전 EBITDA"를 확인하거나 현금 기반 R&D를 사용하여 '40의 법칙(Rule of 40)'을 계산하곤 합니다.

재무상태표 영향

자산화된 소프트웨어는 종종 "자산화된 소프트웨어 개발 원가" 또는 이와 유사한 명칭의 장기 무형 자산으로 표시됩니다. 이는 다음과 같은 결과를 가져옵니다.

• 총 자산 및 자본 증가
• 이익이 자산 기반보다 더 빠르게 상승하는 경우에만 총자산이익률(ROA) 개선
• 프로젝트가 중단되거나 가치가 하락할 경우 손상 검사를 받아야 하는 자산 생성

개발 중간에 프로젝트가 중단되면 이전에 자산화된 비용을 제각(Write off)해야 하며, 이는 갑작스럽고 종종 상당한 손실을 초래합니다. 이것이 새로운 ASU 2025-06에서 '완료 가능성(Probable-to-complete)' 임계치를 매우 강조하는 이유 중 하나입니다.

현금흐름표 영향

자산화된 개발 비용은 일반적으로 영업 활동이 아닌 투자 활동으로 분류되어 영업 현금 흐름을 더 건실해 보이게 만듭니다. 정교한 투자자들은 기업을 비교할 때 이 부분을 조정하지만, 표면적인 수치는 여전히 이득을 봅니다.

기업을 곤경에 빠뜨리는 흔한 실수들

감사인과 인수자들은 동일한 오류를 반복해서 목격합니다.

승인 전 비용의 자산화

전형적인 실수는 경영진이 프로젝트를 공식적으로 승인하기 전에 지출된 엔지니어링 시간을 자산화하는 것입니다. 문서화된 승인 및 자금 지원 약속이 없다면 해당 비용은 비용으로 처리했어야 합니다. 경영진이 언제 확약을 했는지 입증할 수 있는 회의록, 이사회 승인 또는 서면 결재 서류를 반드시 갖추십시오.

프로젝트 수준의 문서 부재

규제 기관이나 감사인이 "자산화한 프로젝트를 보여달라"고 요청했을 때 일반적인 엔지니어링 지출만을 가리킨다면 실패할 것입니다. 프로젝트별 기록(범위, 승인 날짜, 예산, 상태 및 투입 시간)이 필요합니다.

모든 엔지니어링 시간을 자산화 가능으로 취급

시니어 엔지니어는 버그를 수정하고, 코드를 리뷰하고, 회의에 참석하며, 장애에 대응합니다. 이 중 어느 것도 자산화할 수 없습니다. 단순히 엔지니어링 팀의 급여에 일정 비율을 곱하는 방식의 기업은 감사를 통과하는 경우가 거의 없습니다.

출시 후 자본화 지속

소프트웨어가 의도된 용도로 사용될 준비가 된 시점에 자본화는 중단됩니다. 그 이후의 버그 수정, 성능 최적화 및 사소한 개선 사항은 영업 비용으로 처리됩니다. 별도로 범위가 지정된 새로운 기능은 새로운 자본화 기간을 시작할 수 있지만, 정기적인 출시 후 작업은 자본화할 수 없습니다.

손상 검사 누락

자본화된 소프트웨어는 자산이며, 가치가 하락하면 자산 손상을 인식해야 합니다. 제품을 보류하거나, 기능을 종료하거나, 시스템을 근본적으로 재작성하는 경우, 이전 잔액을 재평가하고 해당 금액을 장부에서 제거(상각)해야 할 가능성이 높습니다.

방어 가능한 프로세스를 구축하는 방법

자본화가 귀사에 적합하다고 결정했다면, 정책만큼이나 프로세스가 중요합니다.

1. 소프트웨어 자본화 정책 수립. 어떤 프로젝트가 대상인지, 승인 프로세스, 내용연수 추정치 및 시간 할당 방법을 정의하십시오. CFO 또는 감사 위원회의 승인을 받으십시오.

2. 프로젝트 단위로 엔지니어링 시간 추적. 이것이 가장 기초적인 데이터입니다. Jira 레이블, 프로젝트 트래커의 커스텀 태그, 또는 공식 타임시트 중 무엇을 사용하든 "엔지니어 X가 프로젝트 Z의 자본화 가능 작업에 시간의 Y%를 소비했다"는 사실을 증명할 수 있어야 합니다.

3. 경영진 승인 문서화. 각 자본화 프로젝트에는 승인 증빙이 필요합니다. 날짜가 기입된 서면 승인, 이사회 회의록 또는 리더십이 서명한 프로젝트 헌장 등이 이에 해당합니다.

4. 중대한 불확실성을 정기적으로 재평가. 새로운 규정에 따라 기능이 여전히 새롭거나 입증되지 않았는지, 그리고 요구 사항이 안정화되고 있는지 모니터링해야 합니다. 엔지니어링 리더십과의 분기별 검토가 적절합니다.

5. 프로젝트별 상각 일정표 작성. 각 자본화된 프로젝트는 사용 준비가 된 시점부터 상각이 시작됩니다. 해당 자산의 취득 원가, 상각누계액 및 잔존 내용연수를 추적해야 합니다.

6. 프로젝트 변경 시 손상 검사 수행. 자본화된 작업을 중단하거나 실질적으로 재작성 또는 종료할 때마다 손상 분석을 수행하고 필요에 따라 감액을 기록하십시오.

이것이 부기에 중요한 이유

소프트웨어 자본화는 초기의 부기 원칙이 몇 년 후 빛을 발하는 영역 중 하나입니다. 시리즈 B 투자 유치 중에 투자자는 시산표를 확인할 것이고, 매각 과정의 인수자는 거래 내역을 분개장까지 추적할 것입니다. IRS는 귀사의 GAAP 처리 방식과 고유한 규칙이 있는 제174조 R&D 세무 처리를 비교할 수도 있습니다. 장부에서 자본화 프로젝트와 영업 비용을 분리하지 못하거나, 엔지니어링 시간을 특정 프로젝트에 연결할 수 없거나, 깨끗한 상각 일정표를 유지하지 못한다면 모든 감사와 실사 과정은 고통스러워질 것입니다.

해결책은 개념적으로 간단합니다. 깨끗한 계정 구조를 유지하고, 프로젝트 수준에서 시간을 추적하며, 모든 자본화 분개 뒤에 숨겨진 결정을 문서화하는 것입니다. 처음부터 이를 수행하면 나중에 비용이 많이 드는 정산 작업을 피할 수 있습니다.

소프트웨어 회계를 감사 준비 상태로 유지하십시오

첫 번째 내부 플랫폼을 자본화하든, 수십 개의 프로젝트에 걸쳐 상각 일정표를 운영하든, 깨끗한 재무 기록이 기초가 됩니다. Beancount.io는 모든 항목을 추적 가능하고, 모든 계정을 감사 가능하며, 모든 보고서를 재현 가능한 투명하고 버전 관리되는 장부를 제공하는 텍스트 기반 회계(Plain-text accounting)를 지원합니다. 여러 프로젝트에 걸쳐 자본화된 개발 비용을 추적하는 소프트웨어 회사에 있어, 코드처럼 읽히는 장부를 보유하는 것은 강력한 이점입니다. 무료로 시작하기를 통해 왜 개발자와 금융 전문가들이 텍스트 기반 회계로 전환하고 있는지 확인해 보세요.