2026년 9월 24일, 일본은 국세 시스템을 대대적으로 교체했다. 직후부터 세무서 창구에서는 현금 수납이나 납세증명서 발급 같은 업무에 "상당한 시간"이 걸렸고, 전자신고·납부 서비스인 e-Tax 주변에서도 여러 오류와 긴급 점검이 이어졌다. 거대한 통합 시스템이 전환 직후에 불안정해지는 것 자체는, 분산 시스템이나 업무 자동화를 만져 본 사람일수록 잘 이해한다. 하지만 "깨질 수 있다는 건 안다"와 "깨졌을 때 빠져나갈 길이 충분했다"는 전혀 다른 문제다.
급하게 처리할 일이 있던 사람이 창구에서 이런 안내를 받았다고 해 보자. "시스템 전체가 불안정해서 복구 시점은 아직 모릅니다. 급하시면 직접 방문하시면 처리해 드립니다."
보통은 "그럼 가면 되겠네" 싶다.
그런데 조금만 생각해 보면 불길한 장면이 그려진다.
온라인이나 평소 방식으로 끝나지 않는 사람들이 창구로 몰린다. 직원 쪽은 시스템이 불안정해서 한 건당 처리 시간이 길어진다. 찾아오는 사람은 늘어나는데 처리 능력은 떨어진다.
"오시면 처리해 드립니다"가 "오시면 눈 깜짝할 새에 끝납니다"라는 뜻은 아니다.
결국 기한에 여유가 있다면 그냥 기다리는 편이 꽤 합리적인 선택이 된다.
그리고 속으로는 이렇게 외치고 싶어진다.
"그냥 종이로 받아라. 진짜로."
다만 종이는 마법의 백업 데이터베이스가 아니다.
1. 2026년 9월에 무슨 일이 있었나
일본 국세청은 2026년 9월 24일에 국세 시스템을 교체했다. 차세대 시스템 KSK2의 개발 콘셉트로 국세청이 예전부터 내세운 것은 다음 세 가지다.
- 서류 중심에서 데이터 중심의 사무 처리로 옮긴다
- 세목별로 따로 있던 데이터베이스와 애플리케이션을 통합한다
- 자체 OS를 쓰는 대형 컴퓨터 중심 구성에서, 범용 OS를 쓰는 오픈 시스템으로 바꾼다
즉 화면 디자인만 바꾼 것이 아니다. 데이터를 보관하는 방식, 애플리케이션 사이의 경계, 기반 인프라 자체를 한꺼번에 바꾸는 대규모 교체다.
그리고 교체 당일인 9월 24일, 국세청은 "세무서 창구의 각종 절차 지연"을 공지했다. 현금 수납이나 납세증명서 발급 등에 상당한 시간이 걸리고, e-Tax로 납세증명서를 신청해도 즉시 발급되지 않는 상태라고 설명한다. 교체 작업 자체는 끝났지만 창구 업무에 필요한 시스템 가동에 문제가 생겼다는 것이다.
같은 전환 주간에는 마이나포털(일본의 마이넘버 카드 기반 행정 포털)을 통한 로그인 오류, 인터넷뱅킹 납부 완료 표시 오류, e-Tax 일부 기능 중단, 장애 대응을 위한 긴급 점검도 있었다. e-Tax 일부 기능 중단은 9월 27일까지 해소됐다고 공지됐다.
한편 창구 지연 공지는 9월 28일 시점에도 국세청 사이트의 긴급 정보로 남아 있었다. 자세한 근본 원인은 이 시점에는 공개되지 않았다.
더 중요한 점은 예정된 점검과 장애를 섞어 보면 안 된다는 것이다. 이번 교체에서는 원래 9월 19일 0시부터 24일 8시 30분까지의 장시간 중단과, 9월 26일 하루 종일 중단이 예고되어 있었다. 거기에 전환 후의 오류와 긴급 점검이 겹쳤다.
그러니 체감상 "계속 멈춰 있는 것 아니야?" 싶은 게 자연스럽지만, 그 안에는 계획된 중단과 장애로 인한 중단이 섞여 있다.
2. 돈을 다루는 제대로 된 시스템도 깨진다. 오히려 그래서 멈추기도 한다
"세금이나 돈을 다루는 시스템이면 절대 안 멈추게 만들어야 하는 것 아닌가?"
직관적으로는 맞는 말이다.
하지만 중요한 시스템에는 가용성뿐 아니라 정합성도 있다.
예를 들어 납부 처리에서 가장 무서운 것은 화면이 5분 동안 안 열리는 정도가 아니다.
- 납부했는데 미납으로 처리된다
- 한 번의 처리가 이중으로 등록된다
- 오래된 데이터를 참조해 증명서를 발급한다
- 한쪽 시스템만 갱신되고 다른 쪽은 그대로 남는다
- 복구 후 재실행하다가 같은 처리가 한 번 더 돌아간다
이런 상태에서 "일단 계속 돌렸습니다"는 멈추는 것보다 위험할 수 있다.
구글의 SRE(사이트 신뢰성 엔지니어링) 자료에서도, 대규모 장애 때는 근본 원인을 찾기 전에 피해 확산부터 막아야 하고, 데이터 손상 가능성이 있다면 시스템을 동결하는 편이 낫다고 설명한다.
돈 관련이라서 멈추는 게 아니다.
돈 관련이기 때문에, 올바른 상태를 보장하지 못한 채 돌리느니 멈추는 판단이 필요할 때가 있다.
"재부팅은 해 보셨어요?"로 다 해결된다면, 전국 기간 시스템 운영 담당자들은 훨씬 일찍 퇴근했을 것이다.
3. 단위 테스트가 전부 통과해도, 통합하면 평범하게 터진다
통합 시스템의 골치 아픈 점은 부품 하나하나가 멀쩡해도 전체로는 깨진다는 것이다.
A 시스템은 정상.
B 시스템도 정상.
데이터베이스도 정상.
인증도 정상.
그래도 A에서 B로 넘기는 형식이 한 글자만 달라도 멈춘다.
옛 시스템에서 새 시스템으로 옮긴 데이터에 예외값이 있으면 멈춘다.
재시도 도중에 응답만 사라지면 "처리된 건지 아닌 건지" 알 수 없게 된다.
오래된 캐시, 오래된 장표, 외부 기관과의 연결, 권한, 시각, 배치 처리, 문자 인코딩, 옛 한자 표기, 장애 시 재전송. 경계가 늘어날수록 단독으로는 보이지 않던 조합이 늘어난다.
개인이 만든 작은 자동화조차 오래된 상태, 이중 실행, 누락, 외부 API 차이, 재시도의 부작용 때문에 쉽게 사고가 난다.
그걸 전국의 세무서, 여러 세목, 수납, 환급, 증명, e-Tax, 외부 기관까지 아우르는 기간 시스템에서 한다.
통합이 얼마나 힘든지 아는 사람일수록 "뭐, 전환 직후엔 뭔가 나오긴 하지" 하고 생각한다.
하지만 그게 면죄부는 아니다.
평가해야 할 것은 "장애가 단 한 건도 없었는가"만이 아니라, "장애가 났을 때 얼마나 안전하게 기능을 줄여 버텼는가"다.
4. 왜 "복구 시점을 알 수 없습니다"가 되는가
이용자 입장에서 가장 난감한 말 중 하나가 이것이다.
"복구 시기는 미정입니다."
그러나 원인을 모르는 단계에서 아무 시각이나 약속하는 것이 더 위험할 수도 있다.
중요 시스템의 복구는 서버를 다시 켠다고 끝나는 일이 아니다.
먼저 장애 범위를 가려낸다.
다음으로 데이터가 중간까지만 기록되지 않았는지 확인한다.
다시 실행해도 이중 처리가 되지 않는지 확인한다.
외부 연계 대상과 상태가 어긋나 있지 않은지 확인한다.
필요하면 이전 상태로 되돌리거나 대체 경로를 검토한다.
복구한 뒤에는 멈춰 있는 동안 쌓인 처리를 순서대로 흘려보내고 결과를 대조한다.
특히 "보내는 쪽에서는 성공으로 보이는데 받는 쪽에서는 확정되지 않은" 상태가 섞이면 골치 아프다.
아마존이 공개한 분산 시스템 설계 글에서도, 재시도를 안전하게 만들려면 멱등성, 즉 같은 요청을 다시 보내도 부작용이 중복되지 않는 설계가 중요하다고 설명한다.
복구 시점을 못 말하는 것은 담당자가 아무것도 안 하고 있다는 증거가 아니다.
어디까지 깨졌는지, 어디까지 되돌릴 수 있는지, 어디서부터 다시 시작해야 이중 처리가 안 생기는지 모르면, 정확한 예측 자체가 어렵다.
5. "급하면 창구로"는 대기 행렬 관점에서 꽤 무섭다
여기서 창구가 등장한다.
시스템 장애 중에도 "방문하시면 처리해 드립니다"라는 안내가 나올 때가 있다.
고마운 탈출구다.
하지만 대기 시간 관점에서는 꽤 위험한 조건이 갖춰진다.
평상시를 단순화해서 생각해 보자.
창구에 오는 사람의 도착량을 λ, 직원이 처리할 수 있는 양을 μ라고 하자.
장애가 나면 두 가지가 동시에 일어날 수 있다.
우선 평소라면 온라인이나 내부 처리로 끝날 사람까지 창구로 오기 때문에 λ가 늘어난다.
다음으로 직원이 시스템을 쓰기 불편해지고 건당 확인이나 수작업 입력이 늘어서 μ가 떨어진다.
수요는 늘고 공급 능력은 줄어든다.
대기 행렬에는 최악의 조합이다.
게다가 세무서 직원은 장애가 나는 순간 저절로 늘어나지 않는다.
구글의 SRE 자료에서도, 시스템은 과부하에 가까워지면 조금 느려지는 데서 끝나지 않고 대기 시간 증가와 연쇄 장애로 비선형적으로 나빠질 수 있다고 한다. 그래서 부하 제어와 기능 축소 운전이 중요하다.
"창구로 오면 처리 가능"은 "창구가 한산하다"는 뜻이 아니다.
기한에 여유가 있다면, 장애가 정점인 날에 돌격하지 않고 복구를 기다리는 것은 시간 비용을 따져 보면 충분히 합리적이다.
반대로 법정 기한이나 긴급성이 얽혀 있다면, 혼자 판단해 방치하지 말고 그 시점의 국세청·세무서 공식 안내에서 대체 수단을 확인해야 한다.
6. "종이로 해라"는 반은 맞다. 종이는 접수의 탈출구는 되지만 백업 DB는 아니다
장애를 지켜보다 보면 점점 이런 생각이 든다.
"종이로 받으면 되잖아."
이 발상이 완전히 틀린 것은 아니다.
미국 NIST의 정보 시스템 업무 연속성 계획 가이드에서도, 장애 시 대체 처리 방식으로 단기간이라면 업무 프로세스의 일부 또는 전부를 수작업으로 수행하는 방법을 든다.
즉 수작업 처리는 엄연한 연속성 확보 수단의 하나다.
다만 "종이에 쓰면 다 끝난다"는 보장은 없다.
종이로 할 수 있는 일은 예를 들면 이런 것들이다.
- 신청이나 상담을 접수했다는 사실을 남긴다
- 접수 일시를 확정한다
- 필요한 서류를 받아 둔다
- 복구 후에 처리할 순서를 만든다
- 문의 번호나 접수증을 건넨다
반면 중앙 데이터 대조, 납부 상태 확인, 과거 기록 조회, 증명서의 정확한 발급, 외부 기관과의 연계 같은 일은 기간 시스템 없이는 끝나지 않을 수 있다.
그래서 이상적인 모습은 "전부 종이로 돌아가는 것"이 아니다.
"기간 시스템이 죽어도 접수까지 죽지는 않는 것"이다.
종이는 백업 데이터베이스가 아니다.
하지만 종이 접수증은 비상구가 될 수 있다.
7. 정말 필요한 것은 "완전히 멈추지 않는 축소 운전"
장애에 강한 시스템이라고 해서 평소 기능을 100% 유지하는 것은 아니다.
오히려 중요한 기능만 남기고 간이 모드로 내려간다.
구글 SRE는 이를 단계적 기능 저하, 이른바 graceful degradation으로 다룬다. NIST도 대체 설비, 대체 거점, 수작업 처리 등을 연속성 계획의 선택지로 든다.
세무 절차에 적용한다면 이상적인 모습은 이런 형태다.
- 접수를 멈추지 않는다. 오프라인이나 종이로도 최소한의 신청 정보를 받을 수 있다.
- 접수 번호를 발급한다. "접수가 됐는지 안 됐는지 모르는" 상태를 없앤다.
- 후처리 대기열에 쌓는다. 복구 후 순서대로 다시 처리할 수 있다.
- 이중 처리를 막는다. 같은 신청을 다시 넣어도 한 건으로 취급되는 식별자를 갖는다.
- 긴급도를 나눈다. 기한이나 생활에 미치는 영향이 큰 처리를 우선한다.
- 이용자에게 상태를 보여 준다. 무엇이 멈췄고, 무엇이 쓸 수 있고, 무엇이 복구됐는지 나눠서 공개한다.
- 복구 후에 대조한다. 종이·오프라인 접수분과 운영 데이터를 맞춰 보고 누락과 이중 처리를 찾아낸다.
중요한 것은 "장애가 나도 아무 일 없이 돌아간다"는 환상이 아니다.
깨지는 방식을 설계하는 것이다.
8. 그렇다면 e-Tax는 얼마나 자주 문제를 일으키나
2026년 e-Tax 공식 공지를 보면, 1월의 납부 완료 통지 지연, 2월의 마이나포털 연계 오류와 로그인 곤란, 3월의 로그인 곤란, 7월의 마이나포털 경유 오류, 8월의 다이렉트 납부 등 이용 불가, 9월의 교체 직후 여러 오류 등 연중 여러 차례 장애 공지가 확인된다.
다만 여기서는 대충 세면 안 된다.
이것들이 전부 같은 장애는 아니다.
e-Tax 본체의 문제도 있고, 마이나포털 연계, 납부, 화면 표시, 외부 서비스 쪽 문제도 있다. 게다가 계획된 점검은 장애가 아니다.
따라서 공식 목록에서 말할 수 있는 것은 "부분적인 오류나 주변 연계 장애는 해마다 여러 번 공지된다"까지이고, "국세 시스템 전체가 툭하면 전국적으로 멈춘다"고까지는 말할 수 없다.
2026년 9월의 일이 유독 눈에 띄는 것은, 거대한 교체의 전환 주간에 긴 계획 중단과 전환 후의 여러 오류가 겹쳤기 때문이다.
9. 통합의 지옥을 알고 나면 화내는 방식이 조금 달라진다
직접 작은 자동화 시스템을 만들어 본 사람은 대형 시스템 장애를 보는 눈이 조금 달라진다.
예전 같으면
"어떻게 이런 게 멈추지?"
하고 끝났을 것이다.
한 번이라도 여러 서비스를 연결하고, 대기열을 두고, 재시도를 넣고, 상태를 저장하고, 외부 API와 연계해 보면
"아, 통합 전환이구나. 이건 지옥이겠다."
라는 감상도 섞인다.
단독으로는 전부 돌아가는데 전체로는 깨진다.
고치면 다른 경계가 깨진다.
오래된 상태가 남는다.
재시도했더니 이중이 된다.
로그를 보니 어제 정보였다.
이 작은 버전을 겪어 보기만 해도 거대한 기간 시스템의 어려움을 상상하기 쉬워진다.
하지만 이해와 평가는 별개다.
"어려우니 어쩔 수 없다"로 끝내지 말고, 다음을 봐야 한다.
- 전환 전에 부하 시험·이행 시험을 어디까지 했는가
- 장애 시 어디까지 기능을 줄여 운전할 수 있었는가
- 수작업 접수는 어디까지 제대로 작동했는가
- 상태 공지는 이용자에게 충분했는가
- 복구 후 원인과 재발 방지책을 공개하는가
- 다음 전환에서 같은 종류의 사고를 막을 수 있는가
복잡하니 사고는 날 수 있다.
복잡하기 때문에 사고 이후의 설계와 학습이 중요하다.
10. 결론 — "종이만으로 다 해라"가 아니라 "종이로라도 입구는 죽이지 마라"
세무서의 기간 시스템이 멈추면 이용자 눈에는 꽤 억울하게 느껴진다.
돈과 법적 절차를 다루는 곳이 멈춘다.
복구 시각도 모른다.
창구에 가면 된다고 해도, 아무리 봐도 붐빌 것 같다.
그래서 "그냥 종이로 해라"고 말하고 싶어진다.
이 감각 속에는 꽤 중요한 설계 요구가 들어 있다.
종이만으로 세무 시스템 전체를 대신하는 것은 현실적이지 않다.
하지만 시스템이 꺼지는 순간 접수, 기록, 우선순위 정리, 후처리 대기열까지 같이 죽을 이유도 없다.
거대 시스템에 필요한 것은 "절대 안 깨진다"는 신화가 아니다.
깨져도 최소한의 일은 남기는 것.
이중 처리 없이 되돌릴 수 있는 것.
무엇이 되고 무엇이 안 되는지 이용자에게 알리는 것.
그리고 복구 후에 멈춰 있던 일을 안전하게 되찾는 것이다.
결국 최종적인 요구는 이것이다.
"전부 종이로 해라"가 아니다.
"적어도 접수만은 종이로라도 살려라. 진짜로."
- 국세청 「세무서 창구의 각종 절차 지연에 대하여」 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - 국세청 「국세 시스템 교체에 대하여」
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - 국세청 리포트 2025 「차세대 시스템(KSK2)」
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax 「국세 시스템 교체에 따른 점검 시간에 대하여」
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax 「공지 목록」
https://www.e-tax.nta.go.jp/topics/ - e-Tax 「【해소】e-Tax 이용 불가 상황에 대하여」
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
