신입 개발자의 우편번호 서비스 구축 여정
신입 개발자가 우편번호 조회 서비스(ZipKR) 구축을 시작하며 공공데이터(Public Data)의 복잡성에 직면함
주소 데이터의 도메인 지식 부족으로 컬럼 의미 분석 및 road_name 테이블 설계에 어려움을 겪음
650만 건의 주소 데이터 검색 시 LIKE 연산의 성능 한계를 경험하고 Full-Text Index 도입으로 99.5% 성능 개선 달성
주소 데이터 변경에 따른 대규모 배치 처리의 필요성을 인지하고, 이동 사유 코드를 활용한 효율적인 데이터 관리 로직 설계
JPA의 불필요한 SELECT 문 발생 문제를 Persistable 인터페이스 구현으로 해결하여 배치 처리 시간 40% 단축
공공데이터(Public Data)의 복잡성과 도메인 지식의 중요성
본문에서는 주소 공공데이터를 다루며 지번, 부번, 건축물대장 건물명 등 도메인 지식(Domain Knowledge)의 부재가 초래하는 혼란을 상세히 묘사한다.
데이터 컬럼 분석: 각 컬럼의 의미를 명확히 파악하기 위해 표 형태로 정리하는 과정을 거쳤으며, 이는 데이터베이스 설계(Database Design)의 기초가 되었다.
테이블 설계: 분석된 공공데이터를 기반으로 `road_name` 테이블을 설계했으며, UUID(UUID)를 대체키(Surrogate Key)로 사용하고 `kor_full_text`, `kor_initial_full_text` 컬럼을 추가하여 검색 편의성을 높였다.
결과적으로, 복잡한 공공데이터를 효과적으로 활용하기 위해서는 표면적인 데이터 구조 이해를 넘어선 깊이 있는 도메인 분석이 필수적임을 시사한다.
대용량 데이터 검색 성능 개선: LIKE vs Full-Text Index
650만 건의 주소 데이터를 대상으로 LIKE 연산을 사용한 검색 시 타임아웃(Timeout) 문제가 발생했으나, MySQL의 Full-Text Index 기능 도입으로 성능을 획기적으로 개선했다.
기존 방식의 한계: `LIKE '%검색어%'` 방식은 인덱스(Index)를 효율적으로 사용하지 못해 대용량 데이터셋에서 느린 성능을 보였다.
Full-Text Index 도입: 텍스트를 토큰 단위로 분해하여 역색인(Inverted Index)을 구성하는 Full-Text Index를 활용하여 검색 속도를 평균 60000ms에서 309ms로 약 99.5% 향상시켰다.
이는 단순 검색 기능 구현 시에도 적절한 인덱싱 전략이 성능에 미치는 영향을 명확히 보여주는 사례이다.
대규모 데이터 배치 처리(Batch Processing) 최적화 전략
월 160만 건 이상의 주소 데이터 변경에 대응하기 위해 배치 처리(Batch Processing) 로직을 설계했으며, JPA의 불필요한 SELECT 문을 제거하여 처리 시간을 단축했다.
데이터 변경 감지: 공공데이터의 이동 사유 코드(Change Reason Code)와 관리번호(Management Number)를 활용하여 신규, 수정, 삭제 데이터를 효율적으로 식별했다.
메모리 관리: `BATCH_SIZE`를 설정하여 일정 건수마다 flush/clear를 수행함으로써 OOM(Out Of Memory) 발생 가능성을 제어하고 메모리 사용량을 제한했다.
JPA 최적화: PK가 null이 아닐 때 발생하는 SELECT 문을 제거하기 위해 `Persistable` 인터페이스를 구현하고 `isNew()` 메서드를 커스터마이징하여, INSERT 문만 실행되도록 로직을 변경했다.
결과적으로 배치 처리 시간을 기존 627초에서 360초로 약 40% 단축하는 성과를 거두었다.
주소 데이터의 특수성과 DB 설계 고려사항
한국 주소 체계의 복잡성으로 인해 DB 설계 시 특별한 고려사항이 요구되었다.
컬럼 설계: `eup_myeon_dong`(읍면동)이나 `li`(리)와 같이 한국어 특성상 영어 번역이 어려운 부분은 원어 그대로 관리하는 방식을 채택했다. 이는 실제 서비스 운영 환경에서의 일반적인 관리 방식을 참고한 것이다.
검색용 텍스트 필드: `kor_full_text`와 `kor_initial_full_text` 컬럼을 추가하여 전체 텍스트 검색 및 초성 검색을 지원함으로써 사용자 편의성을 증대시켰다.
이러한 설계는 단순히 데이터를 저장하는 것을 넘어, 사용자 경험(User Experience)과 검색 효율성을 동시에 고려한 결과이다.
