전자세금계산서 연동: 업무 시스템이 국세청 대신 발급대행 API에 붙는 이유

업무 시스템 이야기에서 「세금계산서도 되나요?」라는 질문은 빠지기 어렵습니다. 이 질문에는 흔히 「시스템이 국세청에 연결되나요?」라는 기대가 섞여 있습니다. 전표를 저장하는 순간 국세청에 신고까지 끝나는 그림입니다.

그런데 전자세금계산서를 붙이는 실제 연동 문서를 열어 보면 국세청 주소는 나오지 않습니다. 나오는 것은 발급대행 사업자의 API 키와 SDK 설정값입니다.

국세청에 직접 보낸다는 오해

흔한 이해는 이렇습니다. 업무 시스템이 세금계산서 데이터를 만들고, 그것을 국세청에 보내면 발급이 끝난다고 봅니다. 이 그림으로는 설명되지 않는 것이 두 가지 있습니다. 전자서명은 누가 하는지, 그리고 국세청이 받았다는 결과는 어디서 돌아오는지입니다.

전자세금계산서는 데이터 한 줄이 아니라 전자서명이 된 표준 형식의 문서입니다. 서명하고, 형식을 맞추고, 국세청에 전송하고, 결과를 받아 오는 일이 모두 필요합니다. 이 일을 업무 시스템이 전부 직접 해야 한다고 생각하면 연동이 실제보다 훨씬 커 보입니다.

국세청이 안내하는 네 가지 발급 경로

국세청의 발급 방법 안내에는 경로가 넷 있습니다.

경로	성격
홈택스·손택스	국세청이 무료로 운영하는 화면에서 직접 입력
발급대행 사업자(ASP)	국세청에 등록된 사업자가 수수료를 받고 발급과 전송을 대행
자체 ERP	회사 시스템에서 발급
전화 ARS, 세무서 대리발급	보안카드를 쓰는 예외적인 경로

표에 자체 ERP 가 있으니 「ERP 는 국세청에 직접 붙을 수 없다」는 말도 틀립니다. 경로 자체는 열려 있습니다. 다만 이 글에서 자체 ERP 경로가 요구하는 조건까지 확인하지는 않았습니다. 제가 보기에 중소 규모 업무 시스템에서 이 경로를 고를 이유는 거의 없습니다. 서명과 전송, 실패 처리까지 떠안는 대가로 얻는 것이 수수료 절감 정도이기 때문입니다.

그래서 업무 시스템이 세금계산서를 자동으로 발급한다고 할 때, 실제로 붙는 곳은 대부분 발급대행 사업자의 API 입니다.

업무 시스템과 발급대행 사업자의 역할 경계

발급대행 사업자 중 팝빌의 개발자 문서를 예로 보면 경계가 선명합니다.

업무 시스템이 하는 일은 전표를 세금계산서 형식의 값으로 바꿔 API 로 넘기는 데까지입니다. 공급자와 공급받는 자의 사업자 정보, 품목, 공급가액과 세액, 작성일자를 채웁니다. 전자서명과 국세청 전송, 전송 결과를 받아 두는 일은 팝빌이 합니다.

연동을 시작하는 절차도 이 경계를 따릅니다. 팝빌에 연동을 신청하면 담당자가 연동 방법을 안내하고, 프로그램을 만드는 쪽을 파트너로 등록한 뒤 API Key 와 테스트 환경 계정 정보를 메일로 보냅니다. 팝빌은 이 테스트 환경을 「실제 서비스와 동일한 구조로 구성된 테스트 환경」이라고 설명합니다. SDK 로 연동하면 운영 전환 이후 IsTest 설정값 하나로 테스트와 운영을 오갑니다.

인증서의 주인이 회사여야 하는 이유

발급 주체는 개발사가 아니라 세금계산서를 발급하는 회사입니다. 그래서 전자서명에 쓰는 인증서도 그 회사의 것이어야 합니다.

팝빌의 인증서 안내는 쓸 수 있는 인증서를 세 가지로 적습니다.

전자세금계산서 발행을 위해 사용가능한 공동인증서는 전자세금계산서용 인증서, 전자거래 범용인증서, 팝빌 표준 공동인증서입니다. 반면, 금융업무 또는 인터넷뱅킹 등에 사용하는 금융거래용 인증서와 타기관에서 발급하는 특수목적용 인증서는 사용이 불가합니다.

「회사 인증서가 있다」는 말만으로는 준비가 끝나지 않는 이유입니다. 같은 공동인증서라는 이름이라도 인터넷뱅킹용이면 발급에 쓸 수 없으니, 용도를 먼저 확인해야 합니다.

테스트 단계에서는 팝빌이 테스트 환경에서만 쓰는 테스트용 인증서를 제공합니다. 테스트 환경은 운영 환경과 독립적으로 구성돼 있어서, 거기 등록한 인증서는 운영에서 쓰이지 않습니다. 개발은 테스트용 인증서로 끝까지 진행할 수 있고, 회사의 실제 인증서는 운영 전환 때 필요합니다.

「보냈다」와 「발급됐다」가 다른 지점

API 호출이 성공했다고 발급이 끝난 것은 아닙니다. 국세청 안내에 따르면 전자세금계산서는 거래 상대방의 수신함(이메일)이나 홈택스에 입력된 때 발급이 완료됩니다. 문자 통지나 링크 확인만으로는 발급 완료로 보지 않습니다.

설계에 바로 영향을 주는 대목입니다. 거래처 정보에 세금계산서를 받을 이메일이 비어 있으면, 시스템에서 발급 버튼을 눌러도 발급 완료가 되지 않습니다. 저라면 거래처를 저장할 때부터 수신 이메일을 받게 만들겠습니다. 발급 화면에서 막히는 것보다 거래처 등록 화면에서 막히는 편이 고치기 쉽습니다.

국세청 전송에도 기한이 있습니다. 발급·전송기한 안내는 발급일의 다음 날까지 국세청에 전송하도록 정합니다. 발급대행 사업자가 전송을 맡더라도, 전송이 실패한 건을 사람이 알아채지 못하면 기한은 그대로 지나갑니다.

상태가 넷으로 끝나지 않는 이유

처음 떠올리는 상태 흐름은 보통 「미발행, 발행, 전송 완료, 수정 발행」 넷입니다. 방향은 맞지만 실제 연동과는 어긋납니다.

팝빌의 상태코드 표에는 그 사이가 촘촘하게 나뉘어 있습니다.

코드	상태	뜻
300	발행완료	공급자가 발행을 마친 상태
301~303	전송전, 전송대기, 전송중	팝빌이 국세청 전송을 준비하거나 진행하는 상태
304	전송성공	국세청 신고가 정상적으로 완료된 상태
305	전송실패	국세청이 특정 사유로 신고를 반려한 상태
600	발행취소	발행완료된 세금계산서를 공급자가 취소한 상태, 국세청 전송 대상에서 제외

304 전송성공에는 국세청 결과코드 SUC001 이 대응합니다. 국세청 결과는 팝빌이 국세청에 전송한 건에서만 확인할 수 있습니다.

넷짜리 흐름에서 빠진 것은 「전송 중」과 「전송 실패」입니다. 전송 중이 없으면 발행 직후 화면이 전송 완료처럼 보이고, 전송 실패가 없으면 반려된 건이 화면 어디에도 나타나지 않습니다. 둘 다 앞 절의 전송 기한과 곧바로 이어지는 문제입니다.

모의 발행을 먼저 만들 때 지켜야 할 자리

실제 연동에는 연동 신청, API Key, 회사 인증서처럼 개발 밖에서 시간이 드는 준비가 붙습니다. 그래서 화면과 상태 흐름을 모의 발행으로 먼저 만들고 실제 연동을 나중에 끼우는 순서가 자연스럽습니다.

이 순서가 통하려면 두 가지를 처음부터 지켜야 한다고 봅니다.

하나는 발급대행 사업자를 부르는 자리를 한 곳으로 모으는 것입니다. 모의 구현도 실제 구현과 같은 입구를 쓰게 두면, 나중에 바뀌는 것은 그 입구 뒤의 구현 하나입니다. 화면 곳곳에서 모의 결과를 직접 만들어 두면 실제 연동은 끼우는 일이 아니라 다시 짜는 일이 됩니다.

다른 하나는 모의 상태에도 전송 중과 전송 실패를 넣는 것입니다. 모의 발행은 늘 성공하게 짜기 쉬워서, 그대로 두면 실패 화면은 실제 연동 때가 되어서야 필요해집니다. 모의 단계에서 일부러 실패를 내 볼 수 있게 두면 그 화면을 미리 갖게 됩니다.

수정 발행은 이 흐름의 가장 뒤에 옵니다. 반품이나 단가 정정 같은 원인이 되는 거래가 시스템에 먼저 있어야 수정 발행을 어떤 전표에 묶을지 정할 수 있습니다.

여기까지가 확인한 부분

발급 경로, 발급 완료 시점, 전송 기한은 국세청 안내로 확인했습니다. 인증서 종류, 연동 절차, 상태코드는 팝빌 개발자 문서로 확인했습니다. 다른 발급대행 사업자의 상태 체계나 절차는 이 글에서 보지 않았고, 업체마다 다를 수 있습니다.

발급대행 수수료는 적지 않았습니다. 팝빌 공개 문서에서 건당 요금을 확인하지 못했고, 계약 조건에 따라 달라지는 값이라 봅니다. 회사가 의무 발급 대상인지, 인증서와 수신 이메일을 어떻게 준비하는지는 전자세금계산서 발급 준비에 정리해 두었습니다.