소프트웨어 엔지니어링 매니저에게 프로젝트가 언제 "시작"됐는지 물으면 스프린트 번호로 답할 것이다. 같은 질문을 회계 담당자에게 던지면, 1998년부터 사내용 소프트웨어를 규율해 온 회계 규정 아래에서는 요구사항이 확정되기 전까지는 아무도 코드를 작성하지 않는다고 가정하는 경직된 3단계 체크리스트에서 답이 나와야 했다. 지난 10년간 소프트웨어를 출시해 본 사람이라면 더 이상 그런 식으로 돌아가지 않는다는 것을 알고 있다. 그리고 2025년 9월, FASB도 마침내 이를 인정했다.
회계기준업데이트(ASU) 2025-06호, 무형자산—영업권 및 기타—내부용 소프트웨어(하위주제 350-40): 내부용 소프트웨어 회계처리에 대한 목표 개선은 기존의 단계 기반 테스트를 완전히 폐기하고, 이를 하나의 판단 기반 질문으로 대체한다. 바로 이 소프트웨어가 실제로 완성되어 의도한 기능을 수행할 개연성이 있는가 하는 질문이다. 사내에서 소프트웨어를 개발하는 모든 기업, 특히 기존 규정이 애초에 염두에 두지 않았던 애자일 조직에 있어, 이는 개발 비용이 손익계산서에서 대차대조표로 이동하는 시점과 그 규모를 변화시킨다.
문제: 워터폴 개발을 위한 1998년 규정집
ASU 2025-06이 대체하는 지침인 ASC 350-40(원래 SOP 98-1)은 '소프트웨어 개발'이 선형적인 워터폴 프로세스를 의미하던 시절에 작성됐다. 이 지침은 모든 사내용 소프트웨어 프로젝트를 순차적인 3단계로 구분했다.
- 예비 프로젝트 단계 — 개념 구상, 대안 평가, 공급업체 선정. 이 단계의 모든 항목은 발생 즉시 비용으로 처리된다.
- 애플리케이션 개발 단계 — 실제 코딩, 구성, 테스트. 이 단계의 비용은 자본화된다.
- 구현 후 단계 — 교육 및 유지보수. 다시 비용으로 처리된다.
이 프레임워크는 팀이 3개월에 걸쳐 요구사항 문서를 작성하고 승인을 받은 뒤 개발을 시작하는 경우라면 잘 작동한다. 하지만 팀이 2주 단위 스프린트를 운영하며 점진적으로 릴리스를 출시하고 매 회고마다 범위를 수정하는 순간 이 프레임워크는 무너진다. 애자일 환경에서 '예비'와 '애플리케이션 개발'은 순차적인 단계가 아니라 서로 뒤섞여 있으며, 때로는 같은 스프린트 안에서 동시에 일어난다. 기업과 감사인들은 특정 2주짜리 스프린트가 실제로 어느 단계에 속하는지를 두고 수년간 논쟁을 벌여 왔고, 솔직한 답은 흔히 '둘 다 조금씩 해당한다, 추정치일 뿐이다'였다. FASB가 직접 진행한 의견 수렴에서도 이해관계자들은 이 부분을 GAAP 중에서 일관되게 적용하기가 실무적으로 가장 고통스러운 항목 중 하나로 꾸준히 지적했다.
해법: 세 단계가 아닌 하나의 테스트
ASU 2025-06은 기존 프로젝트 단계에 대한 모든 언급을 제거한다. 그 대신 단일한 '완료 개연성(probable-to-complete)' 인식 기준을 설정한다. 새 지침에 따르면, 기업은 다음 두 가지가 동시에 충족될 때 비로소 사내용 소프트웨어 비용을 자본화한다.
- 경영진이 프로젝트에 대한 자금 지원을 승인하고 확약했다. 이는 새로운 개념이 아니다. 기존 지침에도 존재했지만, 이제는 단계 분석 속에 묻혀 있던 것과 달리 단 두 개뿐인 게이팅 조건 중 하나로서 더 큰 역할을 한다.
- 프로젝트가 완료되어 소프트웨어가 의도된 기능을 수행하는 데 사용될 개연성이 있다. 이것이 진정으로 새로운 부분이며, 판단이 개입되는 지점이다.
두 번째 기준을 충족하려면 중대한 개발 불확실성이 여전히 존재하는지를 평가해야 한다. FASB는 그러한 불확실성의 주요 원인으로 두 가지를 지목한다.
- 검증되지 않은 기술 또는 새로운 기능 — 설계 문서나 명세서가 아니라 실제로 작동하는 증거로서, 실제 코딩과 테스트를 통해 아직 실현 가능성이 입증되지 않은 것.
- 정의되지 않았거나 아직도 계속 바뀌는 성능 요구사항 — 이 기준서는 이를 '기업이 소프트웨어가 수행하기를 원하는 것, 예를 들어 기능이나 특징'으로 정의한다. 팀이 제품이 무엇을 해야 하는지를 두고 여전히 실질적으로 논쟁 중이라면, 그 불확실성은 아직 해소되지 않은 것이다.
실무적으로 이는 자본화 시점이 이제 달력상의 단계가 아니라 실현 가능성의 증거를 따라간다는 뜻이다. 기술적으로 새로운 기능을 본격적으로 구축하기로 확정하기 전 두 스프린트 동안 스파이크(탐색 작업)를 진행하는 팀이 있다면, 그 스파이크 스프린트는 비용으로 처리될 것이다. 애초에 그것을 구축할 수 있는지에 대한 불확실성 자체가 아직 해소되지 않았기 때문이다. 스파이크가 실현 가능성을 입증하고 경영진이 전체 구축에 예산을 확약하는 순간, '완료 개연성' 기준이 충족되어 이후의 개발 비용은 애자일 의식(ceremony)과 무관하게 자본화된다.
FASB가 자본화에는 큰 변화가 없을 것이라고 말하는 이유 — SaaS는 예외
FASB 스스로의 예상에 따르면, 대부분의 온프레미스 또는 라이선스 기반 사내용 소프트웨어의 경우 이번 개정이 자본화 결과를 극적으로 바꾸지는 않을 것이다. 기업들은 실제 코딩이 시작되면 이미 자본화를 하고 있었으며, 새 테스트도 단계 라벨링 작업만 빠졌을 뿐 대체로 비슷한 지점에 도달한다.
SaaS나 클라우드 방식으로 제공되도록 개발된 소프트웨어는 이야기가 다르다. FASB는 이러한 프로젝트의 자본화가 감소할 것이라고 명시적으로 예상한다. 그 이유는 다음과 같다. SaaS 제품은 본질적으로 지속적으로 만들어지고 재구축되며, 상당한 기술적·제품적 불확실성이 개발 일정 후반부까지, 때로는 기능 출시 직전까지 남아 있다. 완료 개연성 테스트하에서는 이러한 지속적인 불확실성으로 인해 많은 SaaS 개발 비용이 기존 단계 모델이 암시했던 시점보다 훨씬 늦게까지 자본화 기준을 통과하지 못하게 된다. 그 순효과로, SaaS 제품의 엔지니어링 인건비 중 더 많은 부분이 다년간 상각되는 자산이 아니라 당기 R&D 비용으로 계상된다. 이는 실제 코드가 단 한 줄도 바뀌기 전이라도 SaaS 기업이 보고하는 EBITDA와 자산 기반에 유의미한 변화를 가져온다.
구체적인 예시: 두 팀, 두 가지 결과
직원 40명 규모의 SaaS 기업이 자사 제품에 AI 기반 예측 모듈을 구축하기로 결정했다고 가정해 보자. 동일한 8개월짜리 구축 프로젝트를 기존 규정과 새 규정이 어떻게 다르게 취급하는지 살펴보자.
기존 단계 모델에서는 재무팀이 선을 그으려 했을 것이다. 처음 6주간의 요구사항 수집과 공급업체 평가는 '예비 단계'(비용 처리)였고, 킥오프 회의 이후의 모든 것은 '애플리케이션 개발 단계'(자본화)였다. 하지만 실제로는 엔지니어링 팀이 그 후 두 달을 들여 선택한 예측 방식이 프로덕션 규모의 데이터에서 허용 가능한 정확도를 낼 수 있는지 알아보기 위한 탐색적 스파이크를 진행했다. 기존 규정의 문구를 그대로 따르면, '단계'가 전환된 이상 그 스파이크 스프린트들도 형식적으로는 킥오프 회의 이후에 일어났다는 이유로 대개 함께 자본화되곤 했다.
ASU 2025-06에서는 재무팀이 대신 이렇게 묻는다. 이 기능이 완료되어 의도대로 작동할 개연성이 언제부터 생겼는가? 처음 두 달 동안 정확도 접근 방식이 아직 검증되지 않은 상태였다면 — 팀이 세 가지 서로 다른 모델링 방식을 테스트하며 어느 것도 기준을 통과할지 알 수 없었다면 — 그 전체 탐색 기간은 달력상 어느 '단계'에 속하는지와 무관하게 비용으로 처리된다. 자본화는 팀이 검증된 방식을 선택하고 경영진이 그 구축에 예산을 확약한 이후에야 시작되며, 이 예시에서는 그 시점이 2개월 차가 아니라 3개월 차가 될 수도 있다. 그 결과 자본화 자산은 더 작아지고 당기 R&D 비용은 더 커지며 — 무엇보다 중요한 것은 — 이 숫자가 사후에 붙여진 단계 라벨이 아니라 구체적이고 문서화된 의사결정 시점에 근거하기 때문에 CFO가 감사에서 실제로 방어할 수 있는 숫자가 된다는 점이다.
이것이 바로 FASB가 SaaS 업계 전반에 걸쳐 기대하는 변화다. '킥오프 콜 이후에 일어난 일이라서 애플리케이션 개발이라고 불렀다'는 식의 설명은 줄고, '기술적 리스크가 해소된 스프린트를 정확히 짚어낼 수 있다'는 식의 설명이 늘어나는 것이다.
시행일과 전환
ASU 2025-06은 상장기업과 비상장기업을 포함한 모든 기업에 대해 2027년 12월 15일 이후 시작되는 연차 보고 기간과 그 안의 중간 기간부터 시행된다. 기준서가 공표된 이후라면 어떤 기업이든 중간 기간이나 연차 기간에 조기 도입할 수 있다.
기업은 세 가지 전환 방식 중 하나를 선택해 이번 개정을 적용할 수 있다. 시행일 이후 발생한 신규 소프트웨어 비용에만 전진적으로 적용하는 방식, 도입 연도 개시일 이후 발생한 비용에 전진적으로 적용하는 방식, 또는 표시된 모든 기간에 소급 적용하는 방식이다. 이 유연성은 중요하다. 규정이 시행될 때 대규모 플랫폼 재작성 작업을 한창 진행 중인 기업이라도 소급 적용 방식을 선택하지 않는 한 수년치 자본화 비용 이력을 되돌릴 필요가 없다.
중소 규모 소프트웨어 기업이 지금 해야 할 일
2027년 12월은 아직 먼 이야기처럼 들리지만, 실무적인 준비 작업은 막판 분기에 몰아서 할 일이 아니다. 특히 전담 기술회계 기능 없이 소규모 재무팀을 운영하는 기업이라면 더욱 그렇다.
'완료 개연성' 판단은 사후가 아니라 실시간으로 기록하기 시작하라. 기존 단계 모델은 기계적이어서 몇 달 뒤에도 스프린트 날짜를 보고 프로젝트가 어느 단계에 있었는지 재구성할 수 있었다. 새 테스트는 언제 기술적 불확실성이 해소되었는가를 묻는데, 이는 사후에 재구성하기가 훨씬 어려운 판단이다. 지금부터 가벼운 습관을 만들어라. 엔지니어링 리더십과 재무팀이 어떤 기능이 기술적 스파이크를 통과하고 구축이 확정됐다는 데 합의하면 그 날짜를 기록하라. 이 기록이 곧 자본화 시작일이자 감사 대응 근거가 된다.
아직 하지 않았다면, 시간 추적이나 프로젝트 코드에서 '탐색' 작업과 '확정된 구축' 작업을 분리하라. Jira 에픽 플래그든, 별도의 코스트센터 코드든, 아니면 시간 추적 도구의 태그 라벨이든 상관없다. 어떤 기능이 스파이크/프로토타입에서 확정된 개발로 전환된 시점에 대한 깔끔한 데이터 추적 기록이 있으면, 감사 중에 기억에 의존해 재구성하려는 것보다 새 기준을 적용하는 일이 훨씬 덜 고통스러워진다.
하나를 선택하기 전에 두 가지 전환 옵션을 모두 모델링해 보라. 만약 회사가 기존 단계별 프레임워크 아래에서 SaaS 개발 비용을 공격적으로 자본화해 왔다면, 소급 적용 시 그 비용들이 마치 처음부터 비용 처리된 것처럼 재분류되면서 기존에 자본화된 자산에 대한 일회성 손상차손이 발생할 수 있다. 전진적 접근 방식은 이러한 재작성을 피할 수 있지만, 도입 이후 새 프로젝트가 시작되기 전까지는 손익계산서에 새로운 방법론이 반영되지 않는다는 뜻이다. 감사위원회가 이를 요구하기 전에 두 방식 모두에 대해 수치를 계산해 보라.
특히 SaaS 기업이라면 감사인과 일찍 상의하라. FASB 스스로 SaaS 개발에 대한 자본화 감소를 예상하고 있는 만큼, 감사인들은 기존 규정하의 단계 분류를 심사했던 것보다 완료 개연성 판단을 더 면밀히 검토할 가능성이 높다. 이는 정확히 그 판단이 더 주관적이기 때문이다. 그 판단을 위한 문서화되고 실시간으로 기록된 프레임워크를 갖추고 2028년 감사에 임하는 기업은, 사후에 이를 재구성하려는 기업보다 훨씬 수월한 대화를 나눌 수 있을 것이다.
깔끔한 장부는 판단을 방어하기 쉽게 만든다
모든 회계 판단 — 그리고 '완료 개연성'은 명백히 하나의 판단이다 — 은 그 뒤에 있는 기록만큼만 방어할 수 있다. 만약 계정과목표가 이미 프로젝트별로 R&D 지출을 구분하고 있고, 원장 항목이 뿔뿔이 흩어진 스프레드시트가 아니라 버전 관리되고 감사 가능한 형태로 존재한다면, ASU 2025-06과 같은 기준을 적용하는 일은 Slack 대화 기록에서 히스토리를 재구성하는 대신 기존 데이터에 태그를 붙이는 문제가 된다. Beancount.io의 플레인텍스트 회계는 기본적으로 그런 투명하고 git으로 버전 관리되는 원장을 제공한다. 모든 항목은 추적 가능하고, 모든 변경은 검토 가능하며, 특정 공급업체에 종속되지 않는다. 무료로 시작하기를 통해 감사인이든, 인수자든, 다음번 FASB 업데이트든 어떤 질문에도 견딜 수 있는 장부를 만들어 보라.