Data/Backend/Frontend · 개인 프로젝트

SweetHome

서로 다른 공공데이터를 같은 기준으로 보는 주거 의사결정 서비스

서로 다른 주거 데이터를 믿고 비교하려면 무엇부터 맞춰야 할까?

프로젝트
SweetHome
기간
2026.06 ~ 진행 중
담당 역할
제품 경계 · Data Pipeline · Backend (1인 개발)

비교 기준

추천하기 전에, 비교 기준부터 맞췄습니다.

서로 다른 공공데이터를 행정동 기준으로 연결하고, 관측값과 데이터 없음 상태를 그대로 보여줬습니다.

01 · 원천 데이터법정동·좌표·통계

서로 다른 공간 단위로 들어온 데이터

02 · 공통 기준행정동 기준

거래·좌표·통계를 같은 기준으로 연결

03 · 비교 화면지도·두 지역 비교

추천 점수 대신 출처·결측·주의점 표시

문제 상황

이름만 조인하면 거래가 중복되고 결측이 0으로 보일 수 있었습니다.

내가 바꾼 것

데이터 계약과 품질 gate를 통과한 값만 화면에 보여줬습니다.

01 / 문제 정의

집을 고르는 기준은 여러 개인데, 데이터의 공간 단위와 의미가 서로 달랐습니다.

가격·교통·생활 환경을 여러 서비스에서 따로 확인하던 경험에서 시작했습니다.

  • 01

    집을 구할 때는 가격뿐 아니라 교통, 생활 편의, 활동 인구와 야간 환경을 함께 보지만 정보가 여러 서비스에 흩어져 있었습니다.

  • 02

    실거래는 법정동, 시설은 좌표, 일부 통계는 행정동처럼 기준이 달라 이름만 조인하면 누락과 중복이 생깁니다.

  • 03

    하나의 종합 점수는 사용자의 다른 우선순위와 데이터의 결측·표본 부족을 가립니다. 최종 선택을 대신하지 않으면서 비교 근거를 보여줄 필요가 있었습니다.

추천보다 비교 기준을 먼저 만들었습니다.

02 / 내 결정

행정동으로 통일하고, 결측과 한계를 드러내기

판단 기준

법정동 거래는 1:N 가중치로, 좌표 데이터는 공간 조인해 region_id로 통일했습니다. 종합 점수 대신 관측값·출처·주의점을 보여줬습니다.

간단 아키텍처

데이터 · 이름이 아니라 공간과 계약으로 연결

  1. 01공공데이터CSV · XLSX · 좌표 · 경계
  2. 02Region Contractregion_id · 1/n 가중치 · 공간 조인
  3. 03Quality Gatenull · 중복 · 표본 · 기준일
  4. 04Service Mart426개 행정동 비교 snapshot

사용자 · 조건에서 판단 근거까지

  1. 01내 조건예산 · 생활 우선순위
  2. 02후보 탐색지도와 지표 분포
  3. 03두 곳 비교같은 기준과 출처
  4. 04결정 리포트관측값 · 주의점 · 근거

03 / 해결 과정

행정동을 공통 계약으로 삼고, 관측값과 한계를 함께 보여줬습니다.

  1. 01

    서울 현행 행정동 코드 기반 region_id를 공통 계약으로 두고, 법정동 거래는 최신 연계 snapshot과 1/n 가중치로 연결했습니다.

  2. 02

    좌표 데이터는 경계 polygon과 공간 조인하고, 면적·거리는 투영 좌표계에서 계산한 뒤 지도 중심점만 WGS84로 변환했습니다.

  3. 03

    도메인 집계와 공간 조인을 배치에서 끝낸 뒤 품질 gate를 통과한 비교 mart만 FastAPI 시작 시 캐시에 올렸습니다.

  4. 04

    종합 점수 대신 조건 입력, 후보 탐색, 지도 확인, 두 지역 비교와 상세 리포트를 하나의 의사결정 흐름으로 연결했습니다.

구현 중 마주한 문제

법정동 거래를 단순 조인하면 거래량이 부풀려지는 문제
발생한 상황

하나의 법정동이 여러 행정동에 연결되는 관계에서 같은 실거래 행이 반복되어 거래량과 평균값이 조인 수만큼 늘어났습니다.

바꾼 부분

코드를 10자리 문자열로 정규화하고 n개 행정동과 연결되면 각 관계에 1/n 가중치를 적용했습니다. 유효 전월세 1,084,937행을 연결하고 최종 mart의 426개 region_id에서 null·중복 0건을 확인했습니다.

파일명과 좌표계 메타데이터를 그대로 신뢰할 수 없는 문제
발생한 상황

한글 파일명은 운영체제별 Unicode 표현이 달랐고, 일부 좌표 원천은 표기된 CRS와 실제 숫자 범위가 맞지 않았습니다.

바꾼 부분

원천은 필수 헤더 집합으로 판별하고 좌표 범위와 서울의 실제 위치를 함께 검증했습니다. 코드가 모순된 매매 1건은 임의 보정하지 않고 제외했습니다.

API 요청마다 같은 CSV와 파생 지표를 다시 읽는 문제
발생한 상황

동일한 비교 snapshot을 요청마다 읽고 계산하면 파일 I/O와 공간·집계 연산이 요청 수만큼 반복됩니다.

바꾼 부분

배치에서 계산을 끝내고 FastAPI lifespan에서 snapshot과 profile을 한 번 준비했습니다. 캐시 반환값은 깊은 복사본으로 전달하며 원천·파생 계산이 한 번만 실행되는지 자동화 테스트로 확인했습니다.

현재 결과

저장소 기록 기준 426개 행정동 데이터를 연결해 지도 탐색과 두 지역 비교 서비스로 구현했습니다.

데이터 계약으로 검증한 결과2026.08.27 저장소 기록 기준
426개
서울 현행 행정동
1,084,937행
유효 전월세 거래 연결
0건
최종 mart 지역 키 null·중복
426 / 426
교통 근거 제공 범위

운영 성과가 아니라 로컬 원천과 산출물의 품질 검증 결과입니다. 원천별 기준일과 최신 가용월은 서비스 메타데이터에서 따로 제공합니다.

04 / 회고

이 선택을 돌아보며.

숫자를 늘리는 것보다 값의 의미와 한계를 설명하는 일이 더 중요하다는 점을 배웠습니다.