R&D 세액공제는 어떤 비용이 인정되고 어떤 비용이 빠지는가

비용을 넣기 전에 질문을 바꾼다

R&D 세액공제의 첫 질문은 "무슨 계정과목인가"가 아니다. "이 비용이 어떤 기술적 불확실성을 줄였는가"다. 개발자 급여, 서버비, 외주비, 재료비라는 이름만으로는 부족하다. 연구과제, 실험, 실패 기록, 산출물이 함께 있어야 연구인력개발비 후보가 된다.

의료기기 소프트웨어 C사는 매출 42억 원, 연구소 인력 6명, 플랫폼 고도화 프로젝트 3개를 운영했다. 회계팀은 개발자 급여 3억 원, 클라우드 사용료 4천만 원, 외주 UI 비용 5천만 원, 고객사 커스터마이징 7천만 원을 전부 후보로 묶었다. 총 4억 6천만 원이었다. 하지만 프로젝트 회의에서 "고객 납품용 수정"과 "새 알고리즘 검증"이 섞여 있다는 사실이 나왔다.

C사의 충돌: 개발팀은 연구라 하고, 영업팀은 납품이라 했다

개발팀장은 고객사 커스터마이징도 기술 난도가 있으니 연구라고 주장했다. 영업팀장은 그 작업이 계약서상 납품 범위였다고 말했다. 세무 담당자는 둘 중 하나를 고르는 대신 산출물을 보자고 했다. 신규 진단 알고리즘 성능시험, 데이터 비식별 처리 모듈, 의료기기 안정성 로그 분석은 연구과제로 남았다. 고객사 화면 색상 변경, 병원별 권한 설정, 운영 장애 대응은 납품·유지보수로 빠졌다.

이 결정으로 후보 비용은 4억 6천만 원에서 2억 8천만 원으로 줄었다. 개발자 급여는 투입률을 반영해 2억 2천만 원, 클라우드 비용은 실험 서버 로그가 있는 3천만 원, 외주 UI는 사용성 실험 프로토타입 2천만 원, 외부 검증 도구 1천만 원만 남겼다. 빠진 1억 8천만 원은 세금 절감 기회를 잃은 금액이 아니라, 사후 분쟁을 피한 금액이다.

비용별 판단 방식

인건비는 가장 크고 가장 자주 흔들린다. 직무명이 개발자라고 해서 전액 인정되는 구조가 아니다. C사는 6명 중 4명은 연구과제 투입률이 80% 이상이었고, 2명은 운영 유지보수와 고객 대응 비중이 높았다. 그래서 급여대장을 이름별로 보지 않고 과제별 시간표와 연결했다.

클라우드 비용은 서버명과 계정이 중요했다. 운영 서버와 실험 서버가 같은 계정에서 결제되면 분리가 어렵다. C사는 신규 모델 학습용 인스턴스, 성능 테스트 저장소, 운영 장애 대응 서버를 별도 태그로 나눴다. 이렇게 해야 4천만 원 중 3천만 원만 후보로 남긴 이유가 설명된다.

외주비는 계약서 제목보다 결과물이 중요하다. "UI 개발 용역"이라는 말은 너무 넓다. 사용성 테스트용 프로토타입이면 연구 후보가 될 수 있지만, 고객사 납품 화면 수정이면 제외가 자연스럽다. 외주 계약서, 검수보고서, 테스트 참여자 기록이 같은 폴더에 있어야 한다.

국세청 사전심사를 언제 쓰는가

국세청은 연구·인력개발비 세액공제 사전심사 제도를 운영한다. 금액이 크거나 비용 성격이 애매하면 이 제도를 염두에 둔 수준으로 자료를 만든다. C사는 공제 후보 2억 8천만 원 중 6천만 원이 애매했다. 이 금액은 바로 신고에 넣기보다 연구활동 설명서, 산출물, 계약서를 보완한 뒤 세무대리인과 사전심사 활용 여부를 논의했다.

사전심사는 모든 회사가 반드시 쓰는 절차가 아니다. 다만 내부에서도 개발팀과 회계팀 의견이 갈리는 비용, 대표 인건비나 특수관계 외주비처럼 민감한 비용, 양산 직전 시제품 비용처럼 경계선에 있는 비용은 사전심사 수준의 문서가 필요하다.

상위 글과 C사 전용 체크리스트

전체 구조는 기업부설연구소, 인증, R&D 세액공제: 신청보다 사후관리가 중요한 이유에서 확인한다. C사처럼 비용 성격이 흔들리는 회사는 비용전표 원본보다 과제별 서버 로그, 깃 커밋 기록, 외주 검수보고서, 고객사 납품계약서, 개발자 월별 투입률, 실험 실패 기록을 먼저 모아야 한다. 연구소 인정 전이라면 기업부설연구소 설립 전에 연구전담 인력과 공간을 먼저 점검하는 법으로 돌아가고, 인정 후 운영이 바뀌었다면 연구소 인정 후 사후관리 실패가 세액공제 추징으로 이어지는 경우를 본다.

법인재무컨설팅에서는 C사의 비용을 "넣을 비용"과 "뺄 비용"으로만 나누지 않았다. 보완하면 살릴 수 있는 비용, 올해는 제외하고 다음 해부터 기록체계를 만들 비용, 세무상 판단이 필요한 비용으로 세 칸을 만들었다. 이 세 칸이 있으면 세액공제 회의가 감정싸움이 아니라 금액별 의사결정이 된다.

C사가 만든 제외 파일

C사는 공제 후보 파일만 만들지 않았다. 제외 파일을 따로 만들었다. 고객사별 화면 수정, 병원 계정 권한 세팅, 운영장애 복구, 납품 후 교육자료 제작을 제외 파일에 넣었다. 처음에는 개발팀이 반발했다. 기술자가 한 일인데 왜 연구가 아니냐는 감정이 있었다.

하지만 제외 파일은 책임 추궁 자료가 아니었다. 다음 해부터 연구과제와 납품업무를 분리하기 위한 기준표였다. 예를 들어 고객사 요청으로 만든 기능이라도 범용 플랫폼에 편입되는 알고리즘이면 연구 후보가 될 수 있다. 반대로 특정 병원 화면에만 쓰이는 설정이면 납품에 가깝다. C사는 이 기준을 개발 티켓 작성 단계에 넣었다. 세액공제는 결산의 문제가 아니라 업무분류 언어의 문제였다.

C사의 비용 판단 회의록 일부

C사는 개발 티켓 124개를 세 묶음으로 나눴다. 첫 묶음은 신규 진단 정확도 향상을 위한 모델 개선이었다. 두 번째 묶음은 병원별 요구사항 반영이었다. 세 번째 묶음은 서비스 장애 대응이었다. 같은 개발자가 처리했지만 비용 성격은 달랐다. 회계팀은 티켓 번호와 근무시간을 붙여 첫 묶음만 연구개발 후보로 올렸다.

가장 논쟁이 컸던 것은 클라우드 비용이었다. 운영 서버와 실험 서버가 같은 카드로 결제됐기 때문이다. C사는 다음 달부터 실험 계정을 분리하고, 모델 학습 작업에는 프로젝트 태그를 붙였다. 이미 지난 비용은 일부만 후보로 두고, 앞으로 생길 비용은 처음부터 분리하기로 했다. 세액공제는 과거를 억지로 해석하는 것보다 다음 달부터 구조를 바꾸는 쪽이 더 강하다.

C사가 다음 해부터 바꾼 개발 티켓

C사는 개발 티켓에 "공제 후보" 체크박스를 만들지 않았다. 대신 "연구가설", "고객납품", "운영장애", "내부개선" 네 가지 목적을 고르게 했다. 회계팀은 이 목적값을 보고 결산 후보를 1차로 걸렀다. 개발자는 세무 용어를 몰라도 자기 일이 어떤 목적이었는지만 고르면 됐다. 이 방식이 비용 분류를 현장 언어로 바꿨다.