행정구역 개편 뉴스를 보고 시스템 코드를 다시 봤다
2026년 7월 1일 행정구역 개편을 앞두고 시군구 코드 변경 방식을 검토하면서, 단독 시스템이 아닌 연계 시스템 관점에서 의사결정했던 과정을 정리했다.
뉴스를 보다 보면 가끔은 그냥 지나칠 수 없는 문장이 있습니다. 이번에는 2026년 7월 1일부터 행정구역이 개편된다는 기사였습니다. 처음에는 "그렇구나" 하고 넘기려다가, 문득 제가 담당하는 시스템에도 시군구 정보를 입력하는 화면이 있다는 게 떠올랐습니다.
뉴스 한 줄이 운영 시스템의 변경 일정으로 이어질 때가 있습니다.
뉴스를 보고 시스템 목록을 다시 열었다
행정구역 개편은 생활 뉴스처럼 보이지만, 시스템 운영자 입장에서는 꽤 실무적인 이슈가 됩니다. 시군구 정보가 단순히 화면에 표시되는 값이라면 수정은 비교적 간단합니다. 하지만 그 값이 신청서, 통계, 연계 전문, 배치 처리, 기관 간 송수신 데이터에 들어가 있다면 이야기가 달라집니다.
이번 2026년 7월 1일 개편에서 제가 확인한 변화는 크게 두 가지였습니다.
인천 건은 상대적으로 범위가 명확했습니다. 하위 코드를 추가하고, 일부 코드명과 매핑 값을 정비하면 됩니다. 물론 실제 작업은 테스트와 영향도 확인이 필요하지만, 데이터 구조 자체가 크게 흔들리는 문제는 아니었습니다.
문제는 전남광주통합특별시였습니다. 기존에는 전라남도와 광주광역시가 각각 별도의 상위 행정구역이었는데, 개편 이후에는 통합특별시라는 하나의 상위 단위로 바라봐야 합니다. 이때부터는 단순히 “코드명을 바꿀까?”가 아니라 “기존 데이터를 어떤 연속성으로 볼 것인가?”의 문제가 됩니다.
먼저 개선 요청 메일을 보냈다
이런 변경은 혼자 기억하고 있다가 7월에 처리하면 늦습니다. 그래서 먼저 행정구역 개편에 따른 서비스 개선이 필요하다는 메일을 보냈습니다. 개편 적용일에 맞춰 업데이트할 수 있도록 일정과 범위를 검토해 달라는 내용이었습니다.
메일을 보낼 때는 크게 세 가지를 정리했습니다.
- 개편 시행일이 2026년 7월 1일이라는 점
- 시스템에서 시도·시군구 코드가 사용되는 화면과 기능이 있다는 점
- 코드 변경 방식에 따라 연계기관 영향도가 달라질 수 있다는 점
이후 검토 회의를 했는데, 예상대로 행정구역 DB 관리 방식에서 의사결정이 필요했습니다.
전남광주통합특별시를 완전히 새로운 코드로 추가할 것인가, 아니면 기존 전라남도·광주광역시 값을 통합특별시 기준으로 변경할 것인가?
두 가지 안이 있었다
회의에서 본 선택지는 크게 두 가지였습니다.
| 구분 | 방식 | 장점 | 주의할 점 |
|---|---|---|---|
| 1안 | 전남광주통합특별시와 하위 행정구역을 신규 코드로 추가 | 2026년 6월 30일까지의 기존 행정구역과 2026년 7월 1일 이후 행정구역을 이력성 있게 구분할 수 있습니다. | 신규 코드를 송수신하는 모든 연계 시스템도 동일한 코드 변경을 반영해야 합니다. |
| 2안 | 기존 전라남도·광주광역시 값을 전남광주통합특별시 기준으로 변경 | 기존 코드 흐름을 유지하므로 연계기관의 신규 코드 반영 부담을 줄일 수 있습니다. | 과거 데이터까지 같은 코드 체계 안에서 보이므로, 이력 표현이 필요한 화면에서는 별도 설명이 필요할 수 있습니다. |
두 안 모두 데이터 관점에서는 충분히 가능한 방법이었습니다. 1안은 이력 관리에 가깝습니다. “2026년 6월 30일까지는 전라남도 또는 광주광역시였고, 2026년 7월 1일부터는 전남광주통합특별시다”라는 흐름을 코드 자체로 남기는 방식입니다.
2안은 연속성 관리에 가깝습니다. 운영상 전라남도·광주광역시와 전남광주통합특별시를 별도 객체처럼 쪼개지 않고, 기존 코드 값을 개편 이후 명칭과 구조에 맞춰 이어서 쓰는 방식입니다.
최종 선택은 2안이었다
최종 회의에서는 2안으로 결정했습니다. 가장 큰 이유는 데이터 연계였습니다.
만약 이 시스템이 단독으로만 돌아간다면 1안도 충분히 매력적입니다. 이력성이 명확하고, 변경 전후를 코드 레벨에서 구분할 수 있기 때문입니다. 하지만 실제 운영 환경은 그렇게 단순하지 않았습니다.
현재 시스템은 여러 기관과 행정정보를 연계하고 있었습니다. 우리가 신규 코드를 추가하면 우리 시스템만 고치면 끝나는 게 아닙니다. 데이터를 보내고 받는 연계기관도 같은 코드를 알아야 하고, 그쪽 시스템도 변경 일정에 맞춰 수정되어야 합니다.
그래서 이번에는 이력성보다 연계 안정성을 우선했습니다. 기존 코드의 연속성을 유지하면 연계기관 입장에서는 새 코드를 별도로 반영하지 않아도 됩니다. 우리 쪽에서는 명칭과 구조를 개편 기준에 맞추되, 외부로 흘러가는 코드 변경 충격은 줄일 수 있습니다.
운영 시스템의 코드는 혼자 존재하지 않는다
이번 일을 보면서 다시 느낀 건, 운영 시스템의 코드는 생각보다 사회적이라는 점입니다. DB 안에서는 숫자 몇 자리, 문자 몇 자리일 뿐입니다. 하지만 그 코드가 다른 시스템과 연결되는 순간, 그 값은 약속이 됩니다.
그리고 약속은 혼자 바꿀 수 없습니다.
물론 2안이 항상 정답이라는 뜻은 아닙니다. 통계나 법정 이력, 감사 추적, 정책 효과 분석처럼 변경 전후의 구분이 중요한 시스템이라면 1안을 선택해야 할 수도 있습니다. 반대로 이번처럼 연계기관과의 호환성이 더 중요한 서비스라면, 기존 코드를 이어 쓰는 방식이 더 현실적인 선택이 될 수 있습니다.
코드 관리의 기준은 "DB에 어떻게 넣기 쉬운가"가 아니라 "그 코드가 흘러가는 모든 곳에서 어떤 의미로 해석되는가"까지 포함해야 한다는 점이었습니다.
마무리
뉴스에서 시작한 작은 메모가 시스템 개선 요청이 되고, 회의 안건이 되고, 결국 데이터 관리 방식에 대한 의사결정으로 이어졌습니다. 운영 업무에서는 이런 일이 자주 있습니다. 겉으로는 단순한 행정구역 명칭 변경처럼 보이지만, 안쪽으로 들어가면 코드, 이력, 연계, 일정, 기관 간 합의가 한꺼번에 얽혀 있습니다.
이번에는 2안을 선택했습니다. 이력성보다 연계 안정성을 우선한 결정이었습니다. 7월 1일 적용 전까지는 실제 화면, 배치, 연계 데이터, 테스트 케이스를 하나씩 확인해야 합니다.
결국 운영자의 일은 변경을 “아는 것”에서 끝나지 않는 것 같습니다. 그 변경이 시스템 안에서 어디까지 움직이는지 따라가 보고, 필요한 사람들에게 제때 알려주고, 가장 덜 흔들리는 방식으로 반영하는 것까지가 일입니다.
이 포스팅이 가치 있었나요?
여러분의 평가는 콘텐츠의 품질을 결정하는
가장 핵심적인 데이터가 됩니다.
실시간 익명 데이터로 수집되어 블로그 운영에 반영됩니다.