크로아티아의 2026년 전자 세금계산서 규정으로 인해 PHP 개발자들은 검증 로직을 새로 만들어야 하는 상황에 직면했습니다 – 세무 당국의 Schematron 파일은 XSLT 2.0을 기반으로 하지만, 지배적인 PHP XSLT 엔진은 XSLT 1.0만 지원합니다. 그 결과, 대부분의 회계 앱은 우회 방법 없이는 62개의 필수 비즈니스 규칙 검사를 수행할 수 없으며, 인보이스가 거부될 경우 B2B 현금 흐름이 중단될 수 있습니다.
기술적 장벽이 중요한 이유
2026년 1월 1일부터 크로아티아의 모든 B2B 거래는 62개의 특정 검증 규칙을 준수하는 e-Račun 형식으로 교환되어야 합니다. 세무 당국은 이러한 규칙을 Schematron 파일로 공개하는데, 이는 본질적으로 위반 사항을 표시하는 XSLT 2.0 스타일시트입니다. 인기 있는 xsltproc와 대부분의 Composer 패키지의 기반이 되는 PHP 내장 libxslt 라이브러리는 XSLT 1.0만 구현합니다. XSLT 2.0 지원 없이는 Schematron을 적용할 수 없으므로, PHP 기반의 인보이싱 시스템은 세무 포털에서 거부되는 인보이스를 생성하거나 다른 언어 또는 서비스로 호출을 보내야만 합니다.
개발자가 선택할 수 있는 세 가지 경로
| 옵션 | 내용 | 실질적인 단점 |
|---|---|---|
| SaxonC PECL 확장 | Saxon-C 프로세서를 네이티브 PHP 확장으로 설치한 다음 Schematron을 직접 호출합니다. | 이 확장은 일반적인 Composer 워크플로우의 일부가 아니며, 서로 다른 서버에 네이티브 바이너리를 빌드하고 배포하는 과정에서 복잡성이 증가합니다. |
| 외부 검증 서비스 | XML을 웹 서비스로 전송하여 해당 서비스가 대신 Schematron을 실행하도록 합니다. | 모든 인보이스가 네트워크 지연 시간과 서비스 가용성에 의존하게 되며, 일시적인 서비스 중단 시 인보이싱 작업이 완전히 차단될 수 있습니다. |
| PHP로 규칙 재구현 | 62개의 Schematron 어설션(assertion)을 네이티브 PHP 코드로 변환합니다. | 초기 작업 노력이 필요하지만, 일단 코딩이 완료되면 검증기가 로컬에서 실행되고 모든 PHP 스택과 깔끔하게 통합되며 외부 의존성을 제거할 수 있습니다. |
단순한 구현을 방해하는 숨겨진 로직
Schematron을 단순히 번역하기만 하면 미묘한 의미론적 차이를 놓칠 수 있습니다. 규칙 HR-BR-4를 예로 들어보겠습니다: "지불 금액이 0보다 크면 지급 기한이 반드시 존재해야 합니다." Schematron은 마이너스 세금계산서(credit notes)의 경우 인보이스 금액에 -1을 곱하는 변수를 정의합니다. 원본 XML에서 마이너스 세금계산서는 양수 금액으로 표시되지만, 변수가 이를 음수로 뒤집기 때문에 "0보다 크다"는 조건이 거짓(false)이 됩니다. 만약 검증기가 어설션 텍스트만 읽는다면, 모든 마이너스 세금계산서를 거부하게 될 것입니다.
교훈은 명확합니다. 해당하는 PHP 조건을 코딩하기 전에 Schematron의 변수 정의를 반드시 읽어야 합니다. 산술 연산이나 문자열 조작이 $ 변수 뒤에 숨겨져 있는 동일한 패턴이 다른 여러 규칙에서도 나타납니다.
흔한 거부 트리거
규칙을 올바르게 코딩하더라도, 개발자들은 세무 시스템에서 치명적인 오류로 처리하는 인보이스 요소를 간과하는 경우가 많습니다.
- 운영자 정보 누락 – 모든 인보이스에는 운영자의 전체 성명과 OIB(크로아티아 개인 식별 번호)가 포함되어야 합니다. 어느 한 필드라도 비워두면 즉시 거부됩니다.
- 빈 XML 태그 –
<cbc:Note></cbc:Note>와 같은 태그는 검증기를 충돌(crash)시킬 수 있습니다. 빈 요소를 제거하거나 플레이스홀더 문자열로 채우면 문제를 해결할 수 있습니다. - 잘못된 KPD 코드 – Klasifikacija proizvoda i usluga (KPD) 코드는 최소 6자리여야 합니다. 짧은 코드는 형식이 잘못된 것으로 표시됩니다.
- 유효하지 않은 날짜 – 다른 사항이 모두 정확하더라도, 2026년 1월 1일 이전 날짜로 된 인보이스는 필수 날짜 규칙을 통과하지 못합니다.
테스트 시 주의사항
세무 당국은 개발자를 위해 샘플 e-Račun 파일을 공개합니다. 하지만 이 예시들은 여전히 2026년 규칙 세트를 통과하지 못하는 2025년 날짜와 OIB를 포함하고 있습니다. 이를 유일한 기준으로 삼으면 규정을 준수하고 있다는 착각에 빠질 수 있습니다. 공식 샘플은 파서(parser)의 정상 작동 여부를 확인하는 용도로만 사용하고, 실제 애플리케이션에서 생성된 현실적인 데이터를 바탕으로 자체적인 규칙 적용 테스트 스위트를 실행하십시오.
이미 출시된 PHP 전용 솔루션
한 개발자는 재구현 방식을 끝까지 밀고 나가, 62개의 모든 검증 규칙을 Laravel 프로젝트용 Composer 설치 가능 라이브러리로 패키징했습니다. 이 라이브러리는 Schematron이 숨기고 있는 산술 연산, 변수 범위(scoping), 예외 케이스 검사를 처리하여 인보이스가 PHP 런타임 내에서 완전히 검증될 수 있도록 합니다. XSLT 2.0과 외부 호출을 제거함으로써, 이 패키지는 규정 준수를 위한 결정론적(deterministic)이고 저지연(low-latency)인 경로를 제공합니다.
소스 코드와 사용 가이드는 저자의 공개 저장소에서 확인할 수 있습니다(원본 게시물에 링크 제공됨).
다음 주목할 사항
- 커뮤니티 주도형 PHP 검증기 – 더 많은 개발자가 재구현 방식을 채택함에 따라, 유닛 테스트 픽스처, 타 프레임워크 지원 또는 성능 최적화 기능을 추가하는 포크(forks)와 확장 기능(extensions)이 등장할 것으로 예상됩니다.
결론
크로아티아의 2026년 전자 세금계산서 의무화로 인해 PHP 개발자들은 현대적인 XSLT 2.0 Schematron과 해당 언어의 레거시 XSLT 1.0 엔진 사이의 불일치 문제에 직면하게 되었습니다. 62개의 비즈니스 규칙을 네이티브 PHP로 변환하고, 숨겨진 변수 로직을 주의 깊게 살피며, 일반적인 XML 함정을 피하는 작업은 인보이싱 프로세스를 내부에서 유지하고 네트워크 관련 오류를 방지하며, 마감 기한이 도래했을 때 회계 소프트웨어가 규정을 준수하며 원활하게 배포될 수 있도록 준비해 줍니다.