[Project/4th] 지역 기반 게시글 검색 기능 개발

 프로젝트에서 지역을 기반으로 구인구직 게시글을 등록하고 검색하는 기능을 개발하게 되었다.

 

 이 기능을 개발하기 위해 설계에 많은 고민을 했고, 구현에 많은 시간을 투자하게 되었다. 그 과정을 되짚어보고 공유하고자 한다!

 

 구현을 위해 비슷하게 동네 기반의 서비스(당근마켓, 배민..)에서 이러한 기능을 어떻게 구현하는지 많이 찾아봤었다. 정확히 어떻게 구현하는지는 알 수 없었지만, 다른 사람들의 당근마켓 클론 코딩과 여러 테크 블로그를 참고하여 나름대로 프로젝트에 맞게 해당 기능을 구현할 수 있었다.

 

 

 

 

 

기능 소개

---

초기 버전 화면

 

 

구인구직 게시글 등록

• 게시글 작성 시, 구인구직의 상세 조건과 거점 지역(ex. 서울특별시 강남구 역삼동)을 입력한다.

 

구인구직 게시글 검색

• 게시글 검색 시, 거점 지역(ex. 서울특별시 강남구 역삼동)을 선택하고, 그 반경(nkm)를 선택할 수 있다.

 

 

 

 

 

 

유사 서비스 분석

---

 결국 내가 구현해야 하는 기능은 동네 기반의 중고 물품 거래 서비스인 '당근마켓'과 유사하다. 당근마켓은 GPS로 인증된 사용자의 동네 주변의 중고 게시글을 보여준다.

 

 

당근마켓 - 내 동네 설정 화면

 

 

근처 동네

 

• 동네 범위(가까운 동네~먼 동네)를 변경하면, 홈 화면에 보여지는 게시글의 범위가 달라진다.
• 동네의 범위는 가까운 동네부터 먼 동네까지 4단계로 설정할 수 있다.

• 단계 별 동네가 정해져 있다.
• 동네는 행정동을 기반으로 한다.

 

 

 

당근은 이미 4단계로 내 근처 동네가 정해져 있는 것 같다. 근처 동네가 당근에서 정한 어떠한 기준으로 미리 계산되어 따로 저장되어 있지 않을까..

 

내 프로젝트는 유저가 검색할 때마다 km를 조절해 동네의 범위를 조절해야 한다. 이 부분에서 다르다.

 

 

 

 

동네를 어떻게 다룰까?

---

1. 동네 분류 체계 : 법정동과 행정동

 우선, 전국의 모든 동네를 알아내야 한다. 우리나라에서 동네를 분류하는 방법은 크게 2가지가 있다.

 

법정동

• 법률로 지정한 고유 지명. 법적 문서에 사용한다.
• 명칭 변동이 거의 없다.

행정동

• 행정 편의를 위해 설정한 구역. 행정동마다 주민센터가 있다.
• 주민 수의 증감에 따라 수시로 설치, 폐지될 수도 있다.

 

행정동, 법정동 엑셀 파일

 

출처 : https://realty.chosun.com/site/data/html_dir/2019/12/13/2019121301421.html

 

 

 법정동과 행정동의 차이는 이름을 보면 알 수 있다. 위에 첨부된 이미지를 보면 알 수 있듯이, 예를 들어, 서울 특별시 종로구의 법정동으로 청운동, 효자동 등이 있다. 하지만, 행정동으로는 명칭이 청운효자동으로 통합되어 있다.

 

 송파구처럼 인구가 많은 법정동이라면 한 법정동에 행정동이 여러 개 생길 수도 있다. 반대로 인구가 적으면 법정동 여러개를 하나의 행정동으로 묶을 수도 있다.

 

 따라서, 어떤 분류 체계를 쓰는지에 따라 동네 분류와 근처 동네의 범위가 달라지게 된다.

 

 

 

 

 

2. 법정동 선택 이유

 이전부터 프론트엔드에서 다른 기능의 화면을 구현하면서 행정동 체계를 쓰고 있었다. 그래서 백엔드에서도 행정동 체계를 쓰기로 했다.

하지만, 행정동 체계로 구현 중에 문제가 발생했다. 결국 그래서 법정동 체계로 바꾸게 되었다.

 

 

1) 카카오맵 API 검색 과정에서 에러

 뒤에서 설명하겠지만, 엑셀로 얻게 된 모든 동네의 좌표값을 얻기 위해 카카오맵 API를 사용하게 되었다. 하지만, 엑셀 데이터와 카카오맵 상의 행정동과 명칭이 다른 경우가 있어 검색이 안 되었다.

 

ex)

엑셀 데이터 상 - 서울 중랑구 면목제3.8동

카카오 지도 상 - 서울 중랑구 면목 3.8동

 

 

 

 2) 유지보수 측면에서 유리

 행정동의 문제점은 행정적 편의를 위해 인구수로 명칭과 영역을 정하기 때문에 변동이 잦다는 것이다. 유지보수을 생각한다면 명칭 변동이 거의 없는 법정동이 유리하다.

 

 

참고) 배민에서도 지리 관리 체계를 행정동에서 법정동으로 전환했던 이야기가 있다. 행정동 문제 해결하려고 검색하다가 발견했다!

[우아한테크세미나] 행정동을 법정동으로, 배민 지리 체계 프로젝트 살펴보기

 

 

 

 

 

3. 근처 동네를 어떻게 알 수 있을까?

 우선, 법정동코드에 규칙이 있는지 살펴봤다. 근처 동네 간 코드가 유사할 것이라고 생각했기 때문이다.

 

 하지만, 법정동코드의 차이가 작다고 해서 거리가 가까운 동네는 아니다. 경기도 성남시와 의정부시는 코드의 숫자가 서로 가깝지만, 실제로 거리는 경기 남부와 북부로 엄청난 차이가 있다.

 

성남시와 의정부시의 법정동 코드

 

 

 

그렇다면, 동네 사이의 거리를 계산하여 근처 동네를 구해야 한다.

결국 거리를 계산하려면 각 동네 별 좌표를 알아야 한다.

 

 

 

 

 

동네 별 좌표 구하기

---

법정동 별 좌표값 저장 결과

 

 

1. 전체 동네 데이터 구하기

 전국의 법정동 데이터는 행정안전부 자료를 통해서 xlsx(엑셀) 파일로 얻을 수 있었다.

 

 xlsx 파일의 데이터를 가공할 수 있는 Python 라이브러리를 사용해 전국의 모든 동네의 시도코드, 시도명, 시군구명, 읍면동명을 추출해 DB에 저장했다.

 

 

자세한 과정은 아래 포스트에서 보면 된다.

https://programmingiraffe.tistory.com/184

[Project] 4번째 프로젝트 - 법정동, 좌표값 데이터 DB에 저장하기(1)

 

 

 

 

 

2. 전체 동네 좌표 구하기

 하지만, 법정동 별 좌표값은 따로 파일로 얻기 힘들었고, 있다 하더라도 하나의 좌표(위도, 경도)로 추출하기가 어려웠다.

 

 그래서 카카오맵 API를 사용하여 법정동을 지도에서 검색해 좌표(위도, 경도)로 변환하도록 했다. 이 부분 또한, 법정동 추출하는 부분과 함께 Python으로 카카오 API와 통신해서 위도, 경도 값을 가져와 DB에 저장하도록 했다.

 

 

자세한 과정은 아래 포스트에서 보면 된다.

https://programmingiraffe.tistory.com/185

[Project] 4번째 프로젝트 - 법정동, 좌표값 데이터 DB에 저장하기(2)

 

 

 

 

 

 

반경 nKm 이내 동네 검색하기

---

 사용자의 거점 지역 근처의 게시글을 검색하기 위해서 우선 거점 지역으로부터 nKm 이내에 있는 동네를 알아야 했다.

우선 고려한 방법은 다음과 같다.

 

1) DB에서 직접 거리를 계산해 검색하는 방법

2) Geocoding 관련 API를 사용(https://nominatim.org/)

 

 

 편하게 구현하기 위해서 처음에는 API를 사용했는데, 수행 시간이 12초로 엄청 오래 걸려서 직접 DB에서 계산을 하기로 했다!

 

 

 

1. 쿼리로 거리 계산하기

MySQL 쿼리 중에 두 좌표 사이의 거리를 계산하는 함수가 있다. 

ST_DISTANCE_SPHERE(POINT(lng1, lat1), POINT(lng2, lat2))

경도, 위도로 된 두 POINT를 넣어주면 된다. 

 

 

@Query(
            value = "SELECT address_code " +
                    "FROM address " +
                    "WHERE ST_Distance_Sphere(POINT(:lng, :lat), POINT(lng, lat)) <= :distance * 1000 ",
            nativeQuery = true
    )
    List<String> getNearbyAddressCode(@Param("lat") double lat,
                                      @Param("lng") double lng,
                                      @Param("distance") Integer distance);

 

 

근처 동네를 검색하는 데만 20ms의 시간이 소요되었다.

 

 

 

 

 

캐시를 사용해 최적화

---

 하지만 매번 게시글 검색 요청이 들어올 때마다 DB에서 쿼리로 근처 동네를 검색해야 한다. 매번 근처 동네를 계산하는 것은 비효율적인 작업이다. 트래픽이 커서 요청이 많아지게 된다면, 매번 근처 동네를 검색하는 것은 추가적인 부담이 될 것이다.

 

그래서 캐싱을 하기로 했다.

 

 

로컬 캐시 vs Redis 캐시

 캐싱을 하는 데, 스프링 서버 내의 로컬 캐시를 쓰거나 외부에서 Redis와 같은 캐시를 쓸 수 있다. 이 기능을 최적화하는 데, 로컬 캐시를 쓰기로 했다.

 

• 외부에 따로 Redis를 구성하는 것은 추가적인 관리와 비용이 들기 때문이다.
• 근처 동네 데이터를 다른 서버에 공유할 필요가 없다.
• 데이터의 크기가 작아서 서버 메모리로도 충분히 처리가 가능하다.

 

 

 

구현

초기화 시, 각 법정동 코드와 반경별로 근처 동네를 계산하여 로컬 캐시에 저장하도록 했다.

@Component
@RequiredArgsConstructor
public class AddressCacheInitializer {
    private final AddressRepository addressRepository;
    private final CacheManager cacheManager;

    @PostConstruct
    public void initializeCache() {
        List<Address> addressList = addressRepository.findAll(); // DB에서 법정동 데이터 가져오기

        Cache cache = cacheManager.getCache("nearbyAddresses"); // 캐시 가져오기

        for (Address address : addressList) {
            for (int km = 1; km <= 5; km++) {
                List<String> nearbyAddresses = calculateNearby(address, addressList, km);
                String cacheKey = address.getAddressCode() + "-" + km; // 캐시 키 설정
                cache.put(cacheKey, nearbyAddresses); // 캐시에 저장
            }
        }
    }

    @Cacheable(value = "nearbyAddresses", key = "#addressCode + '-' + #km")
    public List<String> getNearbyAddresses(String addressCode, int km) {
        throw new IllegalStateException("Data should be preloaded into the cache.");
    }

    private List<String> calculateNearby(Address current, List<Address> allAddresses, double maxDistance) {
        double latDiff = maxDistance / 6371.0 * (180 / Math.PI);
        double lonDiff = maxDistance / (6371.0 * Math.cos(Math.toRadians(current.getLat()))) * (180 / Math.PI); // 경도 범위

        double minLat = current.getLat() - latDiff;
        double maxLat = current.getLat() + latDiff;
        double minLon = current.getLng() - lonDiff;
        double maxLon = current.getLng() + lonDiff;

        return allAddresses.stream()
                .filter(other -> !other.getAddressCode().equals(current.getAddressCode()))
                .filter(other -> other.getLat() >= minLat && other.getLat() <= maxLat)
                .filter(other -> other.getLng() >= minLon && other.getLng() <= maxLon)
                .filter(other -> calculateDistance(current, other) <= maxDistance) // 최종 거리 확인
                .map(Address::getAddressCode)
                .collect(Collectors.toList());
    }

    private double calculateDistance(Address a, Address b) {
        final double EARTH_RADIUS = 6371.0;
        double latDistance = Math.toRadians(b.getLat() - a.getLat());
        double lonDistance = Math.toRadians(b.getLng() - a.getLng());
        double haversine = Math.sin(latDistance / 2) * Math.sin(latDistance / 2)
                + Math.cos(Math.toRadians(a.getLat())) * Math.cos(Math.toRadians(b.getLng()))
                * Math.sin(lonDistance / 2) * Math.sin(lonDistance / 2);
        return 2 * Math.atan2(Math.sqrt(haversine), Math.sqrt(1 - haversine)) * EARTH_RADIUS;
    }
}

 

• initializeCache() : 어플리캐이션 시작 시 초기화 작업이 이루어지게 된다. 근처 동네를 계산해  `법정동코드-거리` key로 하여 로컬 캐시에 저장한다.
• getNearbyAddresses(String addressCode, int km) : 법정동 코드와 반경에 해당하는 근처 동네를 로컬 캐시에서 검색해 반환한다.

 

 

 

 

 

결과

어플리캐이션이 시작될 때, 5033개 법정동의 근처 동네 데이터가 들어갔다.

 

캐싱을 적용하니 근처 동네를 검색하는 데, 약 0.1ms 시간이 소요되었다.