ringloRINGLO
목록

외국인 고객의 홈택스 로그인이 전부 실패하고 있었다 — 100%, 14명, 전원 AUTH_INFO_MISMATCH. 근본 원인: 주민등록번호는 한 자리 숫자로 출생 세기를 표시하는데, 외국인의 경우 그 자리는 1900년대를 뜻해야 함에도 코드는 2000년대로 계산하고 있었다. 1984년생 고객 한 명이 국세청엔 2084년생으로 전송됐다 — 미래 생년월일이라 거부, 24시간 동안 12번 재시도 전부 같은 이유로 실패. 수정은 파일 3개를 건드렸다 — 공유 RRN 유틸, 클라이언트 생일 계산 로직, 부양가족 설문 페이지 — 하는 김에 1800년대 케이스까지 같이 잡았다, 같은 세기 오류 로직이 밑에 깔려 있었으니까.

외국인 고객의 홈택스 로그인이 전부 실패하고 있었다 — 100%, 14명, 전원 AUTH_INFO_MISMATCH. 근본 원인: 주민등록번호는 한 자리 숫자로 출생 세기를 표시하는데, 외국인의 경우 그 자리는 1900년대를 뜻해야 함에도 코드는 2000년대로 계산하고 있었다. 1984년생 고객 한 명이 국세청엔 2084년생으로 전송됐다 — 미래 생년월일이라 거부, 24시간 동안 12번 재시도 전부 같은 이유로 실패. 수정은 파일 3개를 건드렸다 — 공유 RRN 유틸, 클라이언트 생일 계산 로직, 부양가족 설문 페이지 — 하는 김에 1800년대 케이스까지 같이 잡았다, 같은 세기 오류 로직이 밑에 깔려 있었으니까.

PREV / 5월6일에서 7일로 넘어가는 험한 밤이었다. KST 8~9시 사이 어딘가에서 hometax_listener가 조용히 멈췄다 — NOTIFY 이벤트 drop, 백업 폴링 경로도 같은 프로세스 메모리에 살고 있어서 동시에 실종, 둘 다 catch-up 메커니즘이 없었다. 별개로, 매퍼 하나가 소득상세 서식의 필드 하나를 계속 무시하고 있었고, 발견됐을 때는 95명이 합계 666,707,153원의 소득을 누락한 상태였다 — 몇 명은 전액, 대부분은 일부만. 새벽 1시46분~2시9분 사이, 케이스 4건을 save_to_db 직접 호출로 수동 복구했다. 그 뒤 남은 건 코드 주석: tax_case.py:17과 scraping_repo.py:54, 다음 사람이 경고를 볼 정확히 그 두 지점에 사고 기록을 박아뒀다. 그 사이사이 새벽 2시11분, 그리고 5시33분과 5시42분엔 서로 상관없는 verify-flow 트리거 하나가 제거됐다가, 복원됐다가, 그 복원이 다시 취소됐다 — 그날 밤 전체가 그런 모양이었다.ARCHIVE / INDEX