TIL - 까다로운 공공 데이터 API 데이터 페칭 트러블 슈팅

서론

오늘은 예전 팀 프로젝트에서 함께 일했던 가현님이 공공 데이터 API와 관련된 문제로 도움을 요청하셨습니다. API 변경으로 인해 데이터 구조가 크게 바뀌었고, 이에 따라 데이터를 효과적으로 페칭하는 데 어려움을 겪고 있었던 상황이었습니다.

문제 상황

1. 이미지 데이터 부재: 공공 데이터 API에서 이미지가 제거되어, 주제와 관련된 이미지를 가져오는 데 큰 어려움이 있었습니다. 이로 인해 네이버 검색 API를 이용해 이미지를 찾아야 했고, 전체 1300개 데이터 항목에서 이미지를 4개씩 찾아야 하다 보니 5200개의 이미지를 받아오는 작업이 필요했습니다. 네이버 API는 초당 10건 제한이 있어 전체 데이터를 받아오는 데 이론상 8~10분이 소요될 것으로 예상했고, 실제로는 10분 이상 걸렸습니다.
2. API 엔드포인트 제한: API는 페이지 단위로만 요청이 가능하고, 고유 ID로 상세 페이지를 조회할 수 있는 엔드포인트가 없었습니다. 데이터베이스에 고유한 ID가 없어 이름을 PK로 사용하려니 중복된 이름이 문제였습니다.
3. 데이터 식별자 부재: 고유한 ID가 없어서 상세 페이지 접근 시 이름이 중복되는 문제가 있었습니다.
4. 주소 데이터 형식: 원하는 대분류-소분류 형태로 주소를 구분해야 했지만, API에서는 도로명 주소만 제공되었습니다.

문제 분석 및 해결 과정

1. 이미지 문제: 네이버 검색 API를 통한 이미지 수집이 시간이 오래 걸리고 비효율적이라 일단 보류했습니다.
2. 페이지네이션 구현: Next.js에서 페이지 정보를 기억하고 필터링을 적용하여 데이터 페이지 단위로 요청하도록 구현했습니다. 페이지 정보를 기반으로 이름과 주소를 기준으로 필터링하여 필요한 데이터만을 검색할 수 있게 했습니다.
3. 복합 키 사용: 이름과 주소를 조합하여 고유 식별자를 생성하기로 했습니다. URL 구조를 /api/이름/도로명/pageNumber 형태로 설정하여 API 요청을 효율적으로 처리했습니다.
4. 데이터 가공 및 DB 저장: Supabase를 활용하여 데이터를 전처리하고 저장했습니다. 데이터를 {키: ["대분류", "소분류"]} 형태로 재구성하여 관리했습니다.

최종 해결책

• Supabase DB 활용: 공공 데이터 API에서 가져온 데이터를 가공하여 Supabase에 저장했습니다.
• 객체 구조화: 데이터를 {키: ["대분류", "소분류"]} 형태로 필터링하여 저장했습니다.
• 데이터 처리 프로세스 개선:
  • 공공 데이터 API에서 데이터를 일괄적으로 가져옴 
  • 가져온 데이터를 기반으로 네이버 API를 통해 이미지 정보 수집
  • 수집된 데이터를 가공하여 최종적으로 Supabase DB에 업데이트

배운 점

• Supabase의 다양한 메서드를 효과적으로 활용하는 방법을 배웠습니다.
• API에서 제공하는 데이터와 실제 필요 데이터 간의 불일치 상황에 대처하는 경험을 얻었습니다.
• 데이터 가공과 중간 저장소 활용의 중요성을 깊이 이해하게 되었습니다.
• 가현님이 도움을 받는 입장이라고 생각할 수 있었겠지만 겪어보지 못할 상황이여서 많은 것을 배울 수 있었고, 데이터 페칭과 처리에 대한 고민을 하면서 더욱 성장할 수 있었습니다. (ﾉ◕ヮ◕)ﾉ*:･ﾟ✧

결론

공공 API는 예상치 못한 변경과 불확실성이 따르기 때문에, 보다 신뢰할 수 있는 API를 사용하는 것이 좋다는 점을 깨달았습니다. 복합 키를 활용한 데이터 관리의 중요성을 인식했으며, 문제 해결 과정을 통해 한층 성장할 수 있었습니다.