<div id="readability-page-1" class="page"><div aria-label="Content">
 
 
 전국 약 1080만개의 건물DB 완성
 
 
 <ul id="markdown-toc">
 <li><a href="#건물-db-만들기-전국의-모든-건물의-데이터-적재" id="markdown-toc-건물-db-만들기-전국의-모든-건물의-데이터-적재">건물 DB 만들기 (전국의 모든 건물의 데이터 적재)</a></li>
 <li><a href="#세종특별자치시-건물-데이터는-완벽했나" id="markdown-toc-세종특별자치시-건물-데이터는-완벽했나">세종특별자치시 건물 데이터는 완벽했나?</a></li>
 <li><a href="#하루에도-수십개의-건물이-생기고-철거되기도-할-텐데-건물-db-최신화-방법은" id="markdown-toc-하루에도-수십개의-건물이-생기고-철거되기도-할-텐데-건물-db-최신화-방법은">하루에도 수십개의 건물이 생기고 철거되기도 할 텐데, 건물 DB 최신화 방법은?</a></li>
 <li><a href="#전국-건물을-db화-하는-작업에서-특별히-어려웠거나-시행착오를-겪었던-점은-없었나" id="markdown-toc-전국-건물을-db화-하는-작업에서-특별히-어려웠거나-시행착오를-겪었던-점은-없었나">전국 건물을 DB화 하는 작업에서 특별히 어려웠거나, 시행착오를 겪었던 점은 없었나?</a></li>
 <li><a href="#건물-db의-미쳐버린-시너지-효과" id="markdown-toc-건물-db의-미쳐버린-시너지-효과">건물 DB의 미쳐버린 시너지 효과</a></li>
 <li><a href="#4화-미리보기" id="markdown-toc-4화-미리보기">4화 미리보기</a></li>
</ul>
<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/time_table.png" alt="주소정제 내재화 전체 과정">
 <figcaption>주소정제 내재화 전체 과정 (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>
2화에서는 손안대고 코풀기 설계였던 주소정제 1.0 개발 과정과 발생한 장애상황에 대한 내용이었습니다.

일단 주소정제 1.0 에서 추가적인 장애가 발생하지 않았기에 롤백없이 운영하면서 새로운 방법을 찾는 것으로 팀 내 결정이 되었습니다.

3화는 23년 8월 ~ 9월 중순까지 약 1.5개월 동안 건물 DB를 만들기 위한 과정을 설명합니다.



<h2 id="건물-db-만들기-전국의-모든-건물의-데이터-적재">건물 DB 만들기 (전국의 모든 건물의 데이터 적재)</h2>

주소정제 2.0의 가장 큰 변화는 행안부 api 를 fade out 하고, 이 기능을 직접 만드는 것이었습니다.

리서치 과정에서 행정안전부에서 관리하는 주소기반 지원 사이트 ( https://business.juso.go.kr ) 를 발견했습니다.

사실 주소정제 1.0을 설계하는 과정에서 이미 알고는 있었지만 그 당시에는 최대한 손 안대고 코 풀 생각에 모든 제공 주소 데이터를 전부 검토해보지는 않았습니다. ( 또한 그 시기 팀이 엄청 바빴음 )

일단 메뉴탭에는 공개하는 주소와 제공하는 주소 이렇게 나눠져 있는데, 대충 30개정도 되는 종류의 데이터를 제공하고 있더군요.

이 중 우리에게 필요한 데이터를 모두 담고있는 데이터는 '전자지도 다운로드' 항목에 내비게이션용 DB 데이터였습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/junja_jido.png" alt="행안부 제공 데이터">
 <figcaption>행안부 제공 데이터 (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>

다운로드를 받게되면 시/도를 기준 경기도, 강원도, 서울시, 부산시, 광주시 … .txt파일을 제공하고 그 파일안에는 1줄에 1건물씩 raw데이터가 순서대로 제공되는 것을 확인할 수 있습니다. (글씨 작음 주의, 핀치 줌 확대 권장, 어르신들은 돋보기 권장)

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/raw_address_text.png" alt="raw_address_text">
 <figcaption>건물단위 raw 데이터 (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>

각 항목은 아래 스펙의 순서대로 제공이 되는데요.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/navigation_spec.png" alt="navigation_spec">
 <figcaption>행안부 네비게이션용 DB 스펙</figcaption>
</figure>

이미지에는 표시되지 않았지만 더 아래는 위경도 정보도 포함되어 있었기 때문에 위 데이터만으로 충분히 주소정제 2.0을 설계할 수 있어보였습니다.

주소정제 1.0 설계과정에서 행안부 api 안정성을 의심하지 않았기 때문에 장애가 발생했던 것을 교훈삼아 이번에는 나름 머리를 굴리고 계획을 세워봤습니다.

<ol>
 <li>
 일단 가장 적은 건물이 존재하는 세종특별자치시를 개발기 DB에 넣어보자.
 </li>
 <li>
 운영에서 외부업체 api를 호출 했던 세종특별자치시의 모든 케이스가 개발기 DB에 존재하는지 검증하자.
 </li>
 <li>
 세종특별자치시가 완벽하다고 판단되면 나머지 전국을 DB화 하자.
 </li>
 <li>
 그 뒤 어떻게 개발할지는 일단 모르겠고, 일단 2번부터 검증하고 다음 단계는 차차 생각해보는 걸로… (2번에서 부적격 데이터로 판명나면 어차피 전부 나가리데스요)
 </li>
</ol>

세종특별자치시에는 행정부처가 모여있고 네이게이션용 테이터를 제공하는 행정안전부도 세종에 있습니다. ( 본진 지역임 ) 그래서 행정안전부의 본진 지역의 데이터에서부터 누락된 건물이 많다면 나머지 지역은 안봐도 뻔하지 않을까 생각도 있었습니다.



<h2 id="세종특별자치시-건물-데이터는-완벽했나">세종특별자치시 건물 데이터는 완벽했나?</h2>

그래… 바로 이거였어

<ul>
 <li>
 세종특별자치시의 모든 건물 데이터를 DB에 넣으니 약 56,000개의 건물 데이터가 생성
 </li>
 <li>
 운영에서 외부업체 api로 호출된 log의 세종특별자치시의 모든 주소가 개발기 DB를 통해 커버가 가능
 </li>
</ul>

가끔 몇개는 나오지 않았는데 전부 이유는 있었습니다.

예를 들면 도로명에 오타가 있거나 실제로 존재하지 않는 기본주소로 주소정제를 요청했던 것(실제 구글맵, 네이버지도, 카카오맵에도 나오지 않는 주소)들 이었고, 이를 제외하고 전부 개발기 기준으로 주소정제가 가능함을 확인했습니다.

위경도가 없는 건물이 몇개씩 보이는데?

그리고 첫 빠따를 세종특별자치시로 결정하길 잘했다는 생각이 들었는데, 세종특별자치시는 대한민국의 정부청사 및 여러 행정부처 건물이 몰려있고 그런 성격의 건물들은 정부에서 의도적으로 위경도를 제공하지 않는다는 내용도 데이터 검증 과정에서 자연스럽게 확인할 수 있었습니다. (ex. 수질관리공단, 군부대)

세종특별자치시를 시작으로 서울, 대전, 대구, 부산… 남행열차 순서로 대한민국 전국의 건물을 DB화 하는데 성공했고, 이 DB 데이터를 통해 여러 쿼리를 직접 때려보면서 아래 도로명주소 포멧의 아이템인 도로명의 특징, 건물번호와 건물이름, 그리고 건물에 동정보가 어런 룰로 관리되고 있는지를 효율적으로 파악할 수 있게 되었습니다.



<h2 id="하루에도-수십개의-건물이-생기고-철거되기도-할-텐데-건물-db-최신화-방법은">하루에도 수십개의 건물이 생기고 철거되기도 할 텐데, 건물 DB 최신화 방법은?</h2>

이 질문에서는 재미있는 일화가 하나 있습니다.

행안부 네비게이션용 DB데이터는 아래 그림과 같이, 현 시점기준 전체데이터, 월 변동, 일 변동 자료를 각각 다운로드 할수 있게 제공하고있습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/navigation_all_sync.png" alt="제공 데이터 주기">
 <figcaption>행안부 네비게이션용 DB 데이터 주기</figcaption>
</figure>

그런데 매일 일 변동자료를 다운로드하고 업데이트하고… 제가 무슨 이것만 하는 사람도 아니고…너무 귀찮지 않을까요?

마침 행안부에서는 '연계신청' 이라고 해서 데이터를 API로도 제공하고 있었습니다.

그런데 문제는 그 어디를 찾아봐도 네비게이션용 DB데이터 연계 신청은 찾을 수 없었는데요.

그래서 또 다시 1588-0061(7번 도로명주소) (평일 9-18시, 점심 12-13시)에 담당자에게 언제쯤 연계신청이 제공될지 문의를 했습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/conversation.png" alt="daily_update_result">
</figure>

너무나 감사하게도 그 담당 직원분의 도움을 받아 사이트에도 공개되지 않은 네비게이션용 DB의 일단위 동기화 api 정보를 알아낼 수 있었습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/daily_update_result.png" alt="daily_update_result">
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/gumdan.png" alt="gumdan">
</figure>

그 결과 위의 왼쪽 이미지처럼 전국의 모든 건물의 변동사항을 매일 아침 6시에 자동 업데이트를 할 수 있게 되었습니다.

오른쪽을 보시면 25년 9월 입주예정인 인천 검단의 한 아파트 단지인데요. 행안부 네이게이션 일단위 동기화를 통해 이렇게 일찍 건물관리번호가 채번되어 등록된 건물들도 볼 수 있습니다.

또한 업데이트 되는 건물들이 뭔가 지역적인 차이가 있는 것을 발견할 수 있었는데요.

또 다시 행안부 직원에게 전화를 통해 물어보니, 행정안전부는 지자체에서 직접 입력하거나, 수정된 데이터를 통합 관리를 하는 역할이고 이런 건물마다의 업데이트 여부는 모두 지자체에서 얼마나 빨리 정확하게 처리했는지 따라 다르다는 답변을 받았습니다.

참고로 담당 직원과의 통화는 23년 10월에 이루어졌고, 1년이 훌쩍 지난 블로그를 쓰고있는 현재 25년 1월에도 네비게이션용 DB데이터는 찾아 볼수 없는걸 확인했습니다.

혹시 이 글을 보고 계신다면 다른분들을 위해 빨리 업데이트 해주세요.



<h2 id="전국-건물을-db화-하는-작업에서-특별히-어려웠거나-시행착오를-겪었던-점은-없었나">전국 건물을 DB화 하는 작업에서 특별히 어려웠거나, 시행착오를 겪었던 점은 없었나?</h2>

당연히 있었습니다.

일단위 건물 DB 데이터는 zip파일로 제공이 되고, 압축을 풀면 지역별로 각각 나눠져서 건물정보를 .txt 파일로 제공합니다.

이 파일 정보를 db에 넣기 위해서는 직접 .txt파일을 멀티파트 파라미터로 받는 api를 개발하여 추가했습니다.

그냥 파일을 .csv로 변환해서 db에 그냥 import하면 되는데 왜?

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/raw_address_text.png" alt="raw_address_text">
 <figcaption>행정안전부 행정구역 코드 변경 공지시항 (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



첫번째 이유는, 위경도 좌표 문제였습니다.

위 이미지를 확대해서 보시면 중간에 위도, 경도가 GRS80 UTM-K 좌표계 형태 (983298.7131111, 1833434.014316)로 제공됩니다.

아무래도 장기적으로는 우리에게 익숙한 지리적 위경도(36…, 127…) 로 변환한 결과를 DB에 넣어 놓는게 장기적으로 정신 건강에 좋아 보였습니다.

그래서 직접 만든 api에서 각 row를 읽으면서 위경도를 변환 후 db에 issert하는 것으로 진행했습니다.

두번째 이유는, 행안부 연계방식으로 최신화를 위해서도 어차피 api는 필요했습니다.

일 단위 네이게이션용 데이터 동기화를 위해서라도 어차피 file -&gt; db 변환 로직의 개발은 어차피 필요했습니다.

겸사 겸사 전국 데이터를 DB를 직접 만든 api로 일일이 밀어 넣었습니다.

그 결과 처음 개발기 DB를 완성하는데 아마 5일 정도 소요되었습니다.

사실 컴팩트하게 명확히 필요한 데이터만 발라서 차 떼고 포 떼고 예쁘게 만들려다가, 누락된 필드가 있어서 다시 채우는 과정이 몇번 있었습니다.

이런 공공데이터 DB화 작업을 하실때는 제공되는 컬럼들을 일단 무식하게 다 넣은 후 생각해보는게 정신건강에는 좋겠다는 생각이드네요.
 

절대 안 쓸것 같은 필드도 어쩌다보니 필요해집니다.

<ul>
 <li>부산광역시 사상구 사상로 지하93-1 주소가 있는데요. 도로명 뒤에 바로 건물번호가 오는게 아니고 '지하'글자가 붙어서 오는게 정상적인 도로명주소임</li>
 <li>지하여부 ( 0:지상, 1:지하, 2:공중, 3:수상 ) 라는 값이 있는데 필요없을 줄 알았지만 나중에 이거 하나 때문에 전국 건물 지하여부 값 추가함</li>
 <li>공중, 수상은 어떤 건물인지 궁금하실 것 같아서 말씀드리면 일단 그런 건물은 현재 하나도 없습니다. 29세기쯤 되면 한개쯤 추가될 듯</li>
</ul>

노가다가 너무 고되서 제주도는 뺄까 말까 망설이긴 했습니다.

<ul>
 <li>올해 제주도 하루배송 시작했쥬?</li>
</ul>

여하튼 OMS 팀원 전체의 노가다를 통해 전국의 건물DB를 완성했고, 현재 스테이징(vpn연결 귀찮…) 기준 10,778,620개의 건물이 존재하네요.



<h2 id="건물-db의-미쳐버린-시너지-효과">건물 DB의 미쳐버린 시너지 효과</h2>

매일매일 최신화된 전국의 건물 DB은 이후 주소정제 외에도 엄청난 시너지가 있었습니다.

 
OMS 배송가능 권역 캐시 구조 개선

<ul>
 <li>OMS에서 관리하는 배송가능권역 캐시는 커머스몰의 주문트래픽을 그대로 받는데 굉장히 중요한 캐시</li>
 <li>기존에 건물관리번호의 존재를 모르던 시절에는 배송가능권역 캐시의 키를 우편번호+위경도 조합으로 특정 주소를 지칭하여 설계</li>
 <li>기존 캐시 만료 전략을 위해 우편번호 기준으로 별도의 관리가 필요했음.</li>
 <li>특정 건물들의 우편번호가 일괄로 바뀌면, 기존의 캐시는 쓰레기값이 됨</li>
 <li>건물 DB 이후 배송가능한 권역에 대한 캐시는 딱 건물관리번호 1개로 메모리 사용량도 엄청 줄었고 관리가 편해짐 (우편번호 변경과 무관하게 관리가능)</li>
</ul>



궁금한게 있으면 직접 쿼리해보면 됨

<ul>
 <li>전국의 도로명의 postfix는 '고개', '거리', '번길', '길', '로' 중에 하나로만 끝난다</li>
 <li>아래는 각 시/도 별로 존재하는 건물 수 (서울에 대한민국의 1/4 정도가 산다는데 의외로 순위가 낮음)</li>
 <li>
 <div><pre><code> 경기도	 1681847
 경상북도 1422283
 경상남도 1295205
 전라남도 1173776
 충청남도 894194
 전북특별자치도	 814203
 충청북도 628911
 서울특별시 607428
 강원특별자치도 603714
 부산광역시 391276
 대구광역시 297080
 제주특별자치도 263091
 인천광역시 258278
 광주광역시 167184
 울산광역시 165611
 대전광역시 144995
 세종특별자치시	 57093
</code></pre></div>
 </li>
 <li>시/군/구 정보는 강남구, 북구, 나주시 같이 1음절 단어외에 '수원시 영통구', '용인시 기흥구' 와 같은 2음절도 존재</li>
</ul>



컬리 하루배송지역을 건물단위로 관리

<ul>
 <li>현재 컬리의 1시간 배송서비스</li>
 <li>컬리 역삼건물인 한국타이어 빌딩만 운영 오픈하여 실제 주문분터 배달까지의 전체 flow의 안전한 테스트를 지원</li>
</ul>

건물 DB를 완성하기까지는 꽤 많은 시간과 꼼꼼함이 필요로 했는데요.

결국 완성 후에 이 건물 DB는 주소정제 외에 OMS가 관여하는 여러 부분에서 엄청 달달한 열매로 다가오는 긍정적 효과까지 있었습니다.



<h2 id="4화-미리보기">4화 미리보기</h2>

4화에서는 건물 DB를 활용하여 이제 주소정제 2.0을 설계, 개발하는 과정을 설명하는 내용이구요.

한참 열심히 개발하고 있던 중 주문결제팀의 정영권님으로부터 좀 별로인 내용의 소식이 도착했습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/refine-address-internalizatipn-3/junbook_change.png" alt="junbook_change">
 <figcaption>행정안전부 행정구역 코드 변경 공지시항</figcaption>
</figure>

시/도 단위, 특정 시/군/구 단위로 일괄 변경되는 상황을 앞두고 팀의 대응방안도 담고있습니다.

<a href="https://helloworld.kurly.com/blog/refine-address-internalization-4/">4화 슬픈예감 보러가기</a>

 </div></div>

주소정제 서비스 내재화 - 3화 ( 노가다의 달달한 열매 )

댓글