카드 태깅했는데 출입 이력에 모르는 사람이 — 앞자리 0 소실 장애
신고는 이렇게 왔다
“출입 이력에 카드번호가 이상하게 찍혀요. 10자리인데 해당 번호로 등록된 인원이 없어요.”
처음엔 단순 오입력이나 미등록 카드 문제라고 생각했다. 근데 실제로 문은 열렸다. 출입 이력이 발생했는데, 그 카드번호가 시스템에 없는 번호라는 게 문제였다.
시스템 구조 먼저
이 이슈를 이해하려면 출입통제 시스템 구조를 알아야 한다.
1
2
3
4
5
6
7
8
9
카드리더 (현장 단말)
↓
컨트롤러 모듈
↓
엑세스 컨트롤러
↓
출입통제 서버 (Windows/MSSQL)
↓
상위 통합 관제 시스템 (Unix/DB)
카드를 태깅하면 카드리더가 읽고, 컨트롤러에서 1차 권한 비교를 한다. 컨트롤러에 정보가 없으면 서버와 2차 비교를 수행한다. 그 결과와 이력이 상위 통합 관제 시스템까지 올라간다.
출입증 번호는 최대 12자리인데, 시스템마다 실제 사용하는 자릿수가 달랐다.
추적은 역순으로
보안 인프라 장애는 항상 데이터가 도달하는 역순으로 추적한다.
증상이 상위 시스템에서 발견됐으니, 위에서부터 아래로 쫓아 내려갔다.
1단계: 통합 관제 시스템 DB 확인
이력 테이블 조회. 카드번호 컬럼에 10자리 값이 들어있다. 원래 12자리여야 하는 번호인데 앞자리 2개가 없다.
1
2
3
SELECT PASS_NO, ACCESS_TIME, DOOR_ID
FROM ACCESS_LOG
WHERE PASS_NO = '1234567890' -- 10자리
조회 결과는 있는데, 이 번호로 등록된 인원 없음.
2단계: 통합 관제 시스템 수신 데이터 확인
상위 시스템이 하위에서 받은 원본 데이터 확인. 여기서도 10자리로 이미 들어오고 있었다.
→ 상위 시스템 문제가 아님. 올라오기 전에 이미 잘려있었다.
3단계: 출입통제 서버 송신 데이터 확인
출입통제 서버가 상위 시스템으로 보내는 데이터 확인. 역시 10자리.
→ 출입통제 서버가 이미 잘린 값을 보내고 있었다.
4단계: 출입통제 서버 DB 확인 (MSSQL)
여기서 발견했다.
1
2
SELECT PASS_NO FROM ACCESS_HISTORY WHERE ...
-- 결과: 1234567890 (10자리)
컨트롤러에서 서버로 전달됐을 때 이미 10자리로 저장돼 있었다.
5단계: 컨트롤러 송신 데이터 확인
컨트롤러와 서버 간 통신은 카드리더 제조사 SDK를 통해 이루어진다. SDK 통신 로그를 확인했더니 — 여기선 001234567890 12자리가 그대로 살아있었다.
→ 컨트롤러는 정상이다. 문제는 서버가 데이터를 DB에 적재하는 과정에서 발생했다.
원인
카드리더 통신 방식이 변경됐다.
기존 방식: 구형 저주파
변경 방식: 신형 고주파 (13.56MHz 계열)
주파수 변경과 함께 카드번호 처리 방식도 바뀌었다. 기존엔 16진수로 처리되던 카드번호가 10진수로 변환되면서, 00으로 시작하는 번호들이 문제가 생겼다.
1
001234567890 → 10진수 해석 → 1234567890
컨트롤러는 정상적으로 12자리를 송신했지만, 출입통제 서버가 DB에 저장할 때 앞자리 00을 숫자로 처리해버렸다. MSSQL 컬럼이 숫자형 타입이라 00이 그냥 제거된 것이다.
1
2
컨트롤러 송신: "001234567890" ← 정상
DB 저장: 1234567890 ← 앞자리 0 소실
해결
10진수 변환은 불가피했다. 방식 자체를 되돌릴 수 없는 상황.
출입통제 서버의 DB 적재 로직을 수정했다. 핵심은 카드번호 컬럼을 문자열로 처리하는 것이었다. 숫자형에서 문자형(CHAR/VARCHAR)으로 변경하거나, 저장 전 앞자리 0을 패딩하는 로직을 추가하는 방식이다.
1
2
3
4
5
-- 기존: INT 또는 NUMERIC 타입
-- 변경: CHAR(12) 또는 VARCHAR(12)
-- 혹은 저장 전 패딩 처리
SET @PASS_NO = RIGHT('000000000000' + @INPUT, 12)
변경 후 동일한 카드로 태깅 테스트 — 001234567890 12자리가 정상 저장됐고, 상위 시스템에서도 올바른 인원으로 조회됐다.
뭘 놓쳤나
펌웨어/하드웨어 변경이 들어올 때 데이터 타입까지 영향을 주는지 검토가 빠졌다.
1
통신 방식 변경 → 번호 처리 방식 변경 → DB 컬럼 타입과 충돌
이 체인을 변경 전에 검토했어야 했는데, 하드웨어 변경이 소프트웨어 레이어까지 영향을 준다는 걸 과소평가했다.
물리 장비 교체나 펌웨어 업그레이드가 들어올 때는 데이터 포맷 변경 여부를 반드시 확인해야 한다는 교훈이었다.
한 줄 요약
하드웨어 변경이 DB 타입 설계까지 영향을 준다. 앞자리 0은 숫자가 아니라 문자다.