종합부동산웹앱 4단계 원천식별자·실데이터 갱신 설계
질의 원문
다음 단계 차례로 진행해줘.
수집 경로와 시점
- 수집시점: 2026-08-11 19:21 KST
- 확인 파일:
AGENTS.mddocs/CONTEXT_HANDOFF.mddocs/PROJECT_FILE_MAP.mddocs/STATUS.mddocs/analysis/README.mdHISTORY.mdsrc/realestate/webapp/app.pysrc/realestate/webapp/watchlist.pysrc/realestate/search/live.pysrc/realestate/analysis/complex_report.pysrc/realestate/collectors/naver_http.py
데이터 등급
| 항목 | 등급 | 설명 |
|---|---|---|
| 이번 문서의 설계 판단 | 로컬 코드·문서 기반 | 현재 저장소 구조와 사용자 작업 규칙을 기준으로 한 구현 설계 |
| 네이버 단지번호 기반 시세 갱신 | 2차/플랫폼 | 네이버부동산 시세·매물 API 경유 값. 원본 확정값으로 보지 않음 |
| 네이버 경유 실거래 중위값 | 1차/공공원본 경유 | 국토부 신고 실거래를 네이버가 전달한 값으로 보되, 직접 RTMS 원본 확인은 아님 |
| 경매·재개발 원천 식별자 | 미연결/예약 | 이번 단계에서는 저장 계약만 예약하고 실제 원본 수집은 다음 단계 |
판단
다음 단계는 워치리스트의 실데이터 갱신 API를 실제 수집기와 연결하는 것이 맞다. 그러나 후보명만으로
자동 검색하면 잘못된 단지나 평형을 선택할 가능성이 크다. 따라서 4단계는 먼저 원천 식별자
source_refs를 워치리스트 데이터 계약에 추가하고, 네이버 단지번호와 면적 기준이 있을 때만
complex_report()를 실행하는 방식으로 진행한다.
설계 결정
WatchlistItem에source_refs를 추가한다.- 허용 키는
naver_complex_no,naver_area_label,court_case_no,court_code,court_goods_no,data_go_lawd_cd로 제한한다. - 기본 웹앱 생성 시
WatchlistMetricCollector를 연결한다. naver_complex_no가 없으면 metric refresh는 503으로 실패한다.- 복수 평형 단지에서
naver_area_label이 없으면 실패한다. - 갱신 값에는 반드시
metric_sources를 붙인다. - 직접 원본을 확인하지 않은 값은
original_verified=false로 표시한다.
가정
- 현재 작업 순서는 1·2·3단계 통합 구현 이후의 4단계로 본다.
- 네이버 단지번호는 사용자가 직접 입력하거나 향후 검색 UI에서 선택해 저장한다.
- 이번 단계에서는 단지명 자동 검색을 하지 않는다.
- 실데이터 수집 실패는 정상적인 결과 중 하나로 보고, 기존 값은 유지한다.
한계
- 네이버 수집은 네트워크, TLS 지문, API 구조 변경에 따라 실패할 수 있다.
- 네이버 경유 실거래는 국토부 원본 사이트에서 직접 재확인한 값이 아니다.
- 경매 사건번호와 재개발 원천 문서 연결은 저장 계약만 예약하며, 실제 법원·정비사업 원본 연결은 별도 단계가 필요하다.
- 수집값이 없을 때 추정값으로 채우지 않는다.
다음 실행
source_refs저장소·API·UI를 TDD로 추가한다.WatchlistMetricCollector를 만들고 기존 네이버 단지 리포트 수집기에 연결한다.- metric refresh 버튼과 실패 메시지를 UI에 붙인다.
- 구현 기록을 새 분석 문서로 남기고 투자 현황판을 재생성한다.