주소 정규화는 표기가 제각각인 주소를 같은 모양으로 맞추는 작업이고, 주소 검증은 그 주소가 실제로 존재하는지 확인하는 작업입니다. 이름이 비슷해 함께 묶여 이야기되지만 보장하는 바가 전혀 다르므로, 둘을 구분하지 않으면 데이터 품질을 잘못 판단하게 됩니다.
주소 정규화는 무엇을 하나요?
정규화는 값을 바꾸지 않고 모양만 정리합니다. 대소문자를 통일하고, 가운뎃점이나 쉼표 같은 구분 기호를 하나로 맞추고, 도로 종류를 줄여 쓰는 관행을 반영하고, 앞뒤 공백과 중복된 띄어쓰기를 제거합니다.
이 작업의 결과는 원래 값과 같은 장소를 가리킵니다. 서로 다르게 적힌 두 주소가 같은 곳을 가리킨다는 사실을 알아내는 것이 정규화의 가장 큰 쓸모입니다. 같은 도로를 두 가지로 적어 둔 고객 목록에서 중복을 찾아내는 일이 대표적인 예입니다.
정규화는 사전과 규칙만으로 할 수 있습니다. 외부 서비스에 물어볼 필요가 없고, 같은 입력에 항상 같은 출력이 나옵니다. 그래서 여러 번 실행해도 결과가 달라지지 않습니다.
규칙을 코드에 직접 적기보다 표로 분리해 두면 나라가 늘어날 때 코드를 고치지 않아도 됩니다. 표를 두는 방식은 규칙이 왜 그렇게 정해졌는지 함께 남길 수 있다는 점에서도 유리합니다. 나중에 규칙을 의심하게 될 때 근거가 남아 있으면 확인이 훨씬 빠릅니다.
정규화 결과를 저장해 두고 재사용하는 방식도 흔합니다. 다만 규칙이 바뀌면 저장된 결과가 곧바로 낡은 값이 되므로, 어느 규칙으로 처리한 값인지 함께 기록해 두어야 합니다.
주소 검증은 무엇을 확인하나요?
검증은 그 주소가 실재하는지 확인합니다. 도로명이 실제로 있는지, 번지가 그 도로에 존재하는지, 우편번호가 그 지역에 배정되어 있는지, 나아가 그 건물이 우편물을 받는 곳인지까지 봅니다.
이 확인에는 외부 데이터가 필요합니다. 우편 당국의 주소 데이터베이스나 상용 주소 데이터가 없으면 번지 하나하나의 존재 여부는 알 수 없습니다. 그래서 검증은 정규화와 달리 비용과 응답 시간이 들고, 조회 시점의 데이터 상태에 따라 결과가 달라질 수 있습니다.
검증이 통과했다고 해서 그 주소에 사람이 사는지는 알 수 없습니다. 존재하는 건물인지, 우편물을 받을 수 있는 형태인지를 확인할 뿐입니다. 반대로 검증에 실패했다고 해서 반드시 틀린 주소인 것도 아닙니다. 새로 지은 건물이나 데이터에 아직 반영되지 않은 변경이 있을 수 있습니다.
정규화만 하면 검증은 필요 없나요?
둘은 대체 관계가 아니라 순서 관계입니다. 정규화를 먼저 하면 검증에 넘길 값의 모양이 일정해지므로, 검증 서비스가 같은 주소를 매번 다르게 해석하는 일이 줄어듭니다. 순서를 뒤집으면 같은 주소를 두 번 조회하게 되는 경우도 생깁니다.
비용을 줄여야 한다면 모든 입력을 검증하지 않고, 정규화 결과가 이미 알려진 목록에 있는 경우에만 검증을 건너뛰는 방식이 실용적입니다. 다만 이 최적화는 정규화 규칙이 바뀌면 함께 손봐야 합니다. 규칙이 바뀌면 목록의 유효성도 함께 바뀌기 때문입니다.
국가별 우편번호 형식에서 보았듯 나라마다 우편번호의 자릿수와 구성이 달라서, 정규화 단계에서 국가별 규칙을 따로 두지 않으면 뒤 단계의 검사가 엉뚱한 곳에서 실패합니다.
검증에 실패한 주소는 버려야 하나요?
버리는 대신 이유를 나눠서 남기는 편이 낫습니다. 형식이 틀린 경우는 사용자에게 고쳐 달라고 요청할 수 있지만, 조회가 실패한 경우는 잠시 뒤 다시 시도할 여지가 있습니다. 두 경우를 같은 오류로 처리하면 재시도할 수 있는 실패까지 사용자 잘못으로 돌리게 됩니다.
또 하나 중요한 것은 실패한 값을 지우지 않는 것입니다. 사용자가 입력한 원문은 남겨 두고 정규화 결과와 검증 결과를 옆에 따로 저장하면, 나중에 규칙을 고친 뒤 과거 데이터를 다시 처리할 수 있습니다.
표기가 하나로 정해지지 않는 경우
같은 장소를 가리키는 표기가 여러 개인 경우도 있습니다. 행정구역 이름이 바뀌었는데 옛 이름이 통용되거나, 도로 이름이 두 가지로 병기되는 경우가 그렇습니다. 미국 주소에서 흔한 동·호수 표기 차이도 여기에 속하며, 미국 주소 형식에서 따로 다루었습니다.
이런 경우 정규화 규칙으로 하나를 강제로 고르면 현장에서 통하지 않는 표기가 만들어질 수 있습니다. 대표 표기를 하나 정하되 원문을 함께 보관하는 방식이 안전합니다.
랜덤 주소 생성기로 검사 규칙 확인하기
랜덤 주소 생성기는 각 국가의 형식에 맞는 값을 만들어 주므로, 자기 검사 규칙이 정상 형식의 주소를 거부하지 않는지 확인하는 데 쓸 수 있습니다. 반대로 형식을 일부러 흐트러뜨린 값을 넣어, 검사가 실제로 동작하는지도 함께 볼 수 있습니다.
생성되는 주소는 소프트웨어 시험을 위한 합성 데이터입니다. 실제 배송지로 쓰거나 거주 사실을 증명하는 데에는 사용할 수 없습니다.
개발자를 위한 메모: 단계를 분리해 기록하라
- 원문, 정규화 결과, 검증 결과를 각각 다른 열에 저장합니다. 원문을 덮어쓰면 규칙 변경 후 재처리가 불가능해집니다.
- 정규화는 순수 함수로 만들어 시험하기 쉽게 하고, 외부 조회는 별도 계층으로 분리합니다. 한 함수 안에 섞으면 시험마다 외부 응답을 흉내 내야 합니다.
- 검증 실패를 형식 오류, 조회 실패, 미지원 국가로 나눠 코드로 구분합니다. 사용자에게 보여 줄 안내가 경우마다 다르기 때문입니다.
- 정규화 규칙에 국가 분기를 넣을 때는 규칙 표를 데이터로 두고, 코드에는 분기만 남깁니다. 나라가 늘어날 때 코드를 고치지 않아도 됩니다.
- 조회 결과를 잠시 저장해 두되 유효 기간을 둡니다. 주소 데이터는 바뀌므로 오래된 통과 결과를 그대로 믿으면 안 됩니다.
다음 단계
자기 코드에서 주소를 다루는 함수 목록을 적어 보고, 각 함수가 정규화인지 검증인지 표시해 보세요. 이름과 실제 역할이 어긋난 함수가 보인다면 이름을 바꾸는 것만으로도 이후 실수를 크게 줄일 수 있습니다. 실제 값으로 확인하려면 랜덤 주소 생성기에서 몇 개 국가를 생성해 자기 정규화 함수에 통과시켜 보고, 결과가 원문과 같은 장소를 가리키는지 비교해 보세요.