중요 업데이트 - 2015.3.10

 

XE 개발팀에서 새로운 공식 우편번호 모듈을 공개했네요.

 

새 모듈은 다음 API와 우체국 API를 선택할 수 있고, XE 개발팀의 공식적인 지원이 보장되니 가능하면 새 모듈을 사용하시기 바랍니다. 그러나 Postcodify 모듈이 더 좋으신 분은 계속 사용하셔도 됩니다 ^^

 

 

개요
 

얼마 전 공지사항으로 발표된 것처럼, 코어와 함께 배포되는 krzip 모듈과 연동하는 검색서버(krzip.xpressengine.com)가 2015년 4월 20일에 서비스를 중단한다고 합니다.

 

불필요한 개인정보 수집을 최소화하는 추세에 따라 회원들의 주소를 입력받지 않는 사이트라면 서비스 종료 및 모듈 교체의 영향을 받지 않겠지만, 쇼핑몰 등 주소 입력을 받는 사이트라면 매우 심각한 문제입니다. 주소 입력이 중단되어 버리면 매출에 직접적인 타격을 줄 수 있으니까요. 따라서 서비스 종료 전에 미리 대비해야 합니다.

 

그런데 1월 20일자 공지사항에서 "대체 서비스"라는 제목 아래에 제가 배포한 Postcodify 모듈을 단독 언급하는 바람에, 전혀 예상치 못하게 제가 공식적인 대체 서비스 꼴이 되어버렸습니다 ㅠㅠ

 

이것과 관련하여 코어 개발자분들에게 협의를 요청하는 메일을 보내드렸으나, 너무나 일관성있게 침묵으로 대답하시는 바람에... 아무래도 아쉬운 사람이 먼저 발품을 팔아야 하지 않을까 싶어서... 우선 그동안 댓글로 요청하신 기능들부터 손봐서 모듈을 새 버전으로 업데이트하였습니다.

 

그리고 앞으로 XE에서의 우편번호 검색 이용과 관련하여 실제 사용하시는 분들의 의견을 묻고 싶습니다. 이런 기능이 반드시 필요하다, 기존 서비스 종료 및 대체 서비스 전환 과정에서 이렇게 해주었으면 좋겠다 등등... 이렇게 의견을 모아서 제가 도와드릴 수 있는 부분은 최대한 도와드리고, 코어 개발자분들께도 사용자들의 정확한 필요를 전달할 수 있으면 좋겠습니다.

 

 

Postcodify 소개

 

우선 "대체 서비스"인 Postcodify 모듈에 대해 간단한 설명을 드리겠습니다.

 

Postcodify는 약 1년 전부터 제가 개인적으로 운영하고 있는 도로명주소 우편번호 검색 API입니다. XE뿐 아니라 어떤 웹사이트나 어플리케이션에서도 자유롭게 사용할 수 있습니다. 검색서버 구축에 필요한 프로그램과 클라이언트측 jQuery 플러그인 모두 LGPL 라이선스로 공개되어 있으므로 검색 사용량이 많은 경우에는 직접 검색서버를 구축할 수도 있습니다. (무료서버는 1일 사용량 제한이 있습니다.)

 

참고: 도로명주소 무료 API 비교표

 

작년 여름부터는 시험적으로 그누보드 플러그인과 XE 모듈을 만들어 배포하고 있습니다. XE의 경우 Postcodify 모듈은 기존의 krzip 모듈을 대체하는 형태로 설치되며, 기존 모듈과 다른 점은 아래와 같습니다.

• 더 편리한 검색 (시·도를 별도로 선택할 필요가 없음)
• 2015년 8월 시행 예정인 새우편번호(기초구역번호) 대비 완료
• 네이버·다음·구글 지도 연동
• 사서함 주소 검색 가능
• 도로명주소의 각 구성요소와 우편번호를 별도의 필드로 반환하므로 더 유연하게 활용할 수 있음
• 검색된 주소와 관련된 모든 지번과 건물명 등을 함께 표시하여, 대표지번 외의 지번주소로 검색하더라도 정확한 도로명주소를 선택할 수 있음

어제 배포한 v2.0에서는 기존의 팝업창 방식을 레이어 팝업으로 변경하여 모바일 기기 및 반응형 레이아웃 지원을 강화하고, 한 페이지에 여러 개의 주소 입력란을 표시할 수 있도록 했습니다. (예: 집주소, 회사주소)

 

 

 

설치하려면 기존의 krzip 모듈을 삭제하고, 새 모듈을 ./modules/krzip에 설치한 후, 반드시 관리모듈에서 캐시파일 재생성을 해주셔야 합니다. 모듈 교체후 캐시파일을 재생성하지 않으면 주소 검색창이 표시되지 않습니다.

 

그 밖의 옵션들은 관리모듈에서 변경할 수 있습니다.

 

 

 

 

데이터 포맷 관련 주의사항

 

기존의 krzip 모듈은 주소데이터 포맷이 도로명주소 표기 형식에 맞지 않고 우편번호가 별도의 필드로 구분되지 않는 문제가 있었고, Postcodify 모듈의 예전(~v1.2) 버전도 기존 모듈의 필드 순서를 따르다 보니 우편번호 필드가 마지막에 붙어서 이용하기도 불편하고 확장성을 방해하는 문제가 있었습니다.

 

그래서 v2.0에서는 반환하는 주소데이터 포맷을 우편번호/도로명주소/상세주소/참고사항 순으로 변경하였습니다. extra_vars에 들어가는 배열의 구조도 이에 따라 바뀌게 되므로, 기존의 주소데이터를 다른 모듈이나 쇼핑몰 등과 연동하시던 분들은 Postcodify 모듈의 Github 페이지에서 설명하는 포맷을 참고하셔서 충분히 테스트해 보시기 바랍니다.

 

기존 방식으로 주소를 입력한 회원이 주소를 수정하면 새 포맷으로 입력됩니다. 그러나 전환기 도중 다른 프로그램과의 일관성있는 연동을 위해 모든 회원의 주소를 새 포맷으로 일괄 변환하기를 원하시는 분은 Postcodify 모듈에서 제공하는 getKrzipStandardFormat() 메소드를 사용하여 변환 프로그램을 작성하셔도 됩니다.

 

    $oKrzipModel = getModel('krzip');
    $newFormat = $oKrzipModel->getKrzipStandardFormat($oldFormat);

 

이후 더이상의 포맷 변경은 없을 예정이나, 기본 제공하는 0~3번 필드 외에 다른 필드가 추가될 가능성은 있습니다. 예를 들어 Postcodify에는 원래 영문(도로명·지번)주소 입력 기능이 있는데, XE 모듈에서는 이 기능이 빠져 있습니다. 만약 요청이 쇄도하여 이 기능을 추가하게 된다면 4번 이후의 필드에 들어갈 수도 있습니다.

 

 

기존의 krzip 모듈을 계속 사용하는 방법

 

데이터 포맷 때문에 모듈 교체가 곤란하거나, XE 1.7.4 미만이어서 새 모듈과 호환되지 않거나 (방법이 있다고는 합니다만), 커스터마이징을 너무 많이 하셔서 기존의 krzip 모듈을 계속 사용할 수밖에 없는 상황이라면?

 

다행히, 공식 검색서버(krzip.xpressengine.com) 서비스가 중단되더라도 XE에서 사용하는 검색서버의 소스코드가 공개되어 있으므로 누구든지 이 소스를 이용하여 직접 검색서버를 운영할 수 있습니다. 관리모듈에서 고급 → 설치된 모듈 → "한국 우편번호"를 클릭한 후, 직접 운영하시는 검색서버의 주소를 입력하면 됩니다.

 

검색서버를 직접 운영하기 부담스럽다면 Postcodify에서 제공하는 검색서버를 사용하셔도 됩니다. Postcodify는 원래 자체 데이터 포맷을 사용하지만, XE의 krzip 모듈을 사용하여 검색 요청을 보내면 자동으로 krzip 모듈에 맞는 포맷으로 데이터를 변환하여 전송해 줍니다. (에뮬레이션이라고 부르는 기능입니다. 그누보드도 에뮬레이션하고 있습니다 ^^)

• 우편번호 검사 서버 이름 : api.poesis.kr
• 우편번호 검사 서버 경로 : /post/search.php

에뮬레이션 기능의 특징과 한계에 대해서는 Postcodify 매뉴얼의 해당 페이지를 참고해 주세요.

 

 

맺는말

 

XE와 함께 국내 오픈소스 CMS의 쌍벽을 이루고 있는 그누보드에서도 2014년 초부터 도로명주소 우편번호 검색 서비스를 제공하다가 11월 초에 접은 일이 있습니다. 그러나 그누보드는 무작정 서비스 종료를 선언한 것이 아니라, 기존의 모듈(그누보드에는 모듈이라는 개념이 희박하긴 합니다만)을 Daum 우편번호 서비스로 전환하는 소스를 직접 제작하여 2개월 전부터 배포하였고, 그래서 그누보드를 꼬박꼬박 업데이트한 사용자들은 별 문제 없이 대체 서비스로 전환할 수 있었습니다.

 

그럼에도 불구하고 제때 업데이트하지 못해 발을 동동 구르는 웹마스터들이 상당히 많았습니다. 이 무렵 제가 Postcodify에 에뮬레이션 기능을 추가하여 그누보드 사용자들이 쉽게 전환할 수 있도록 도왔는데, 10월 말에서 11월 초 사이 500개 이상의 도메인이 이 기능을 사용해 급히 Postcodify로 전환하였습니다. 미리 업데이트한 사이트, 우편번호 검색 서비스 종료 후에야 부랴부랴 업데이트한 사이트까지 포함하면... 당시 발등에 불이 떨어진 사이트 숫자가 최소한 1천 개는 될 것으로 보입니다. (정확한 숫자는 그누보드 운영자님이 아시겠죠. 그누보드는 영카트라는 쇼핑몰 솔루션과 많이 연동하기 때문에, 쇼핑몰에서 많이 사용하여 주소검색의 중요성이 더욱 높았는지도 모릅니다.)

 

많은 사용자들의 의존하는 서비스 운영을 종료할 때는 충분한 준비 기간을 갖고, 전환 과정을 적극적으로 지원해야 합니다. 작년 이맘때쯤 CDN 서비스 종료 때는 굳이 버전업을 하지 않더라도 관리모듈에서 설정 하나만 바꾸면 대응이 가능했으니 그나마 쉬웠죠. 아무리 코어 개발자분들이 Postcodify 모듈을 절대적으로 신뢰하신다고 해도 (캄사^^) 해당모듈 제작자에게 장기간 지원가능 여부를 확인조차 하지 않고 수많은 일반 사용자들에게 무작정 "서비스 종료하니까 이걸로 바꾸셈" ... 이건 좀 아닌 것 같습니다.

 

오픈소스 개발자 입장에서는 개선된 버전을 내놓으면 빨리빨리 업데이트해 주기를 바라는 것이 당연하고, 무료로 운영하던 서비스를 종료하게 되더라도 "아, 어려웠겠구나" 하고 이해해 주기를 기대하는 것이 자연스러운 건지도 모릅니다. 그러나 현실은 그렇지 않습니다. 대부분의 웹마스터들은 시간도 부족하고 기술도 부족하고 대규모 업데이트는 꿈도 꾸지 못하죠. 이런 분들의 입장에선 위에서 링크한 공지글은 무성의하고 무책임하게 보일 수도 있습니다.

 

마치 대기업에서 보도자료 돌리듯이 툭 던져놓기만 하는 공지가 아니라, 커뮤니티의 필요에 좀더 적극적으로 반응하는 XE가 되었으면 좋겠습니다.