앱 개발비가 모두 R&D는 아닙니다: 범위와 기록을 나누는 법
앱을 만든다는 사실만으로 개발비 전체가 연구개발비가 되는 것은 아닙니다. 기술적 불확실성을 풀기 위한 과제인지, 기존 서비스를 운영·관리·지원하기 위한 구현인지, 누가 어떤 근거로 수행했는지에 따라 검토할 지점이 달라집니다. 이 글은 세액공제 결과를 단정하는 안내가 아니라, 사업계획·외주 계약·비용 기록을 시작할 때 개발 범위를 섞지 않는 실무 기준입니다.
공식 원문 확인일: 2026년 9월 14일 · 작성: 유인어스(UINUS)
먼저 답: ‘앱을 만들었다’가 아니라 ‘어떤 문제를 어떻게 풀었는지’를 적습니다
국세청은 연구개발을 과학적 또는 기술적 진전을 이루기 위한 활동과 새로운 서비스·서비스 전달체계를 개발하는 활동으로 설명합니다. 따라서 화면을 새로 만들었는지, 외주 개발 계약이 있는지만으로 범위를 판단하기보다 개발 과제가 해결하려는 기술 문제, 가설과 검증 방법, 결과물을 구체적으로 구분하는 편이 안전합니다.
예를 들어 일반적인 회원관리 화면 추가, 내부 결재 흐름 정리, 판매·운영을 돕는 시스템 구축은 제품에 중요할 수 있습니다. 다만 그 중요성 자체가 R&D 해당성을 뜻하지는 않습니다. 국가법령정보센터에 공개된 연구·인력개발비 비용 범위는 위탁·공동 연구개발비에서 기업의 사업운영·관리·지원 활동과 관련된 시스템 개발을 위한 위탁비용을 제외한다고 적고 있습니다. 실제 개발이 어느 쪽인지, 비용이 어느 범위에 해당하는지는 계약명보다 업무 내용과 수행 기록을 함께 봐야 합니다.
구분할 질문 | R&D 검토를 위해 남길 내용 | 일반 개발·운영으로도 남길 내용 |
|---|---|---|
해결하려는 문제 | 기존 방식으로 해결되지 않은 기술적 한계와 가설 | 사용자·운영자가 불편한 업무 흐름 |
수행 방식 | 실험, 시제품, 성능 검증, 실패·변경 기록 | 요구사항, 화면·기능 목록, 배포·교육 기록 |
결과물 | 검증 결과, 기술 보고, 연구 노트 | 완료 기능, 운영 매뉴얼, 인수 기준 |
비용 연결 | 과제·수행자·증빙 간 연결 | 계약 범위, 변경 요청, 검수·지급 근거 |
이 표는 법정 서식이 아닙니다. ‘R&D’와 ‘일반 개발’ 가운데 하나를 미리 선언하는 용도가 아니라, 나중에 설명해야 할 사실을 처음부터 분리해 적기 위한 틀입니다. 한 프로젝트 안에도 기술 검증 단계와 운영 기능 구현이 함께 있을 수 있으므로, 전체 계약금액을 한 범주로 묶기보다 작업 단위와 산출물을 연결하는 편이 낫습니다.
사업계획서와 외주 계약에는 두 개의 범위를 따로 씁니다
사업계획서에는 개발 목적을 넓게 쓰기 쉽습니다. 그러나 “AI 앱 개발”, “플랫폼 고도화”처럼 큰 이름만 남으면 투자자·지원기관·개발사·세무 담당자가 같은 일을 서로 다르게 이해할 수 있습니다. 개발 범위는 최소한 제품을 출시·운영하기 위한 구현과, 기술적 불확실성을 검증하려는 과제를 분리해 써 보세요.
첫째, 일반 제품 개발 범위에는 사용자 문제, 기능 목록, 화면 또는 관리자 기능, 외부 연동, 배포·운영 책임을 적습니다. 둘째, R&D 검토가 필요한 범위에는 풀고자 하는 기술 문제, 비교할 방법, 성공·실패를 판단할 기준, 테스트 데이터·환경, 검증 결과의 보관 위치를 적습니다. 같은 사람이 두 업무를 함께 한다면 어느 기간에 어느 과제에 투입됐는지도 뒤늦게 기억에 의존하지 않도록 기록합니다.
외주 계약도 이 구분을 반영할 수 있습니다. “앱 개발 일체”라는 문장보다 요구사항 정의, 기술 검증, 시제품, 본 개발, 배포, 유지보수의 산출물과 변경 절차를 나누면 완료 여부와 비용 발생 이유를 설명하기 쉬워집니다. 계약의 완료 기준을 먼저 정하는 방법은 앱 외주개발 검수 기준: 계약 전에 완료를 정의하는 법에서 더 자세히 다룹니다.
기술 과제와 제품 범위를 한 문서에서 정리하고 싶다면 현재 단계의 준비 항목을 점검해 보세요.
비용을 넣기 전에 확인할 네 가지 증거
비용을 분류할 때는 지출 증빙만 모으기보다 그 지출이 어떤 과제 수행과 연결되는지 확인해야 합니다. 국세청의 R&D 세액공제 사전심사 안내는 이미 지출한 비용뿐 아니라 지출 예정 비용과 전체 비용 중 일부 항목도 대상이 될 수 있다고 설명하며, 연구개발보고서·연구개발비 명세서·그 밖의 관련 서류를 첨부서류로 안내합니다. 이는 모든 개발비가 인정된다는 뜻이 아니라, 활동과 비용의 연결을 설명할 자료가 중요하다는 신호로 볼 수 있습니다.
과제 정의: 어떤 기술적 문제를 검토했는지, 기존 방식의 한계와 검증 가설을 한 페이지로 남깁니다.
수행 기록: 담당자, 기간, 테스트 또는 시제품의 변경 이유와 결과를 날짜 순서로 보관합니다.
비용 연결: 인건비·외주비·재료·도구 등 각 비용이 어느 과제의 어느 작업과 관련되는지 계약서·견적서·세금계산서와 연결합니다.
운영 기능 분리: 판매, 고객관리, 내부 행정, 일반적인 운영 지원을 위한 기능은 R&D 과제와 같은 항목에 섞지 말고 별도 작업으로 관리합니다.
국세청은 연구·인력개발비 세액공제를 신청하려는 내국법인과 거주자가 연구개발 활동의 정의 부합 여부와 비용 범위를 사전에 심사해 달라고 요청할 수 있다고 안내합니다. 불확실한 경계 비용이 있거나 신고 전 판단 근거가 필요한 경우에는 실제 계약·업무 기록을 갖춰 세무 전문가와 검토하거나 공식 사전심사 제도를 확인할 수 있습니다. 개별 기업의 적용 여부는 이 글만으로 판단할 수 없습니다.
‘연구 노트’는 길게 쓰는 문서보다 추적 가능한 기록입니다
처음부터 완성된 보고서를 만들려고 하면 기록이 중단되기 쉽습니다. 과제별 폴더 하나를 만들고, 문제 정의·가설·실험 또는 구현·결과·다음 결정의 순서로 짧게 남기는 방식부터 시작해도 됩니다. 각 파일에는 과제명, 작성일, 작성자, 연결된 계약 또는 비용 증빙의 식별 정보를 적고, 변경된 이유를 덧붙이세요.
중요한 것은 성공 사례만 모으지 않는 일입니다. 예상한 성능이 나오지 않아 방법을 바꿨다면 그 사실도 기술적 판단의 맥락이 됩니다. 반대로 고객 요청에 따라 화면 문구를 바꾸거나 관리자 권한을 추가한 일은 제품 운영에 필요한 중요한 업무이더라도, 기술 검증 기록과는 분리해 두는 편이 뒤의 검토를 단순하게 합니다.
MVP에서 무엇을 먼저 만들지 정해야 한다면 MVP 개발이란? 실패 비용을 줄이는 핵심 기능 선정법도 함께 참고할 수 있습니다. 그 글이 기능 우선순위를 다룬다면, 이 글은 이미 계획한 개발을 어떤 과제·기록·비용 단위로 나눌지에 초점을 둡니다.
유인어스는 민간 사업 지원 서비스입니다. 이 글은 R&D 세액공제, 정부지원사업 선정, 투자 또는 개발 성과를 보장하지 않습니다. 적용 요건·제출 서류·비용 범위는 법령과 국세청 안내, 실제 업무 내용 및 전문가 검토를 바탕으로 결정하세요.
자주 묻는 질문
앱 개발 외주비는 모두 R&D 비용인가요?
아닙니다. 외주 계약이 있다는 사실만으로 범위를 정할 수 없습니다. 국가법령정보센터에 공개된 비용 범위에는 기업의 사업운영·관리·지원 활동과 관련된 시스템 개발을 위한 위탁비용 제외 규정이 있습니다. 실제 과제의 내용, 수행 주체, 산출물, 비용 증빙을 함께 확인해야 합니다.
기존 서비스에 AI 기능을 붙이면 R&D라고 볼 수 있나요?
기능 이름만으로 단정할 수 없습니다. 기술적 문제와 검증 과정, 실제 수행 내용, 비용 범위를 분리해 확인해야 합니다. 국세청은 연구개발을 기술적 진전 또는 새로운 서비스·전달체계 개발 활동으로 설명하지만, 개별 적용은 사실관계에 따라 달라질 수 있습니다.
연구 기록은 개발이 끝난 뒤 정리해도 되나요?
나중에 한 번에 정리하면 당시의 가설, 변경 이유, 수행자와 비용의 연결이 흐려질 수 있습니다. 과제별로 문제·수행·결과·다음 결정을 짧게라도 남기고, 계약·견적·지급 증빙과 연결해 두는 편이 좋습니다.
경계가 애매한 비용은 어떻게 확인하나요?
실제 업무와 증빙을 먼저 분리해 정리한 뒤 세무 전문가와 검토할 수 있습니다. 국세청은 지출한 비용 또는 지출 예정 비용의 연구개발 해당성과 비용 범위에 관한 사전심사 제도를 안내하므로, 필요한 경우 공식 절차와 최신 요건을 확인하세요.
앱·MVP 계획, 개발 계약, 자금 준비를 현재 사업 단계에 맞춰 정리하려면 우리 회사의 준비 항목을 확인해 보세요.