종합부동산웹앱 1·2·3단계 통합 설계

질의 원문

이 순서 기억하고 1, 2, 3번 진행해

앞선 대화에서 정리한 순서는 다음과 같다.

1. 파이프라인 ↔ 워치리스트 탐색 UX
2. 투자 지표 출처·시점 관리
3. 실데이터 수집 API 연결

수집 경로와 시점

• 수집시점: 2026-08-11 17:06 KST
• 수집 경로: 로컬 프로젝트 문서와 코드 확인
• 확인 파일: AGENTS.md, docs/CONTEXT_HANDOFF.md, docs/PROJECT_FILE_MAP.md,

docs/STATUS.md, docs/analysis/README.md, HISTORY.md,

src/realestate/webapp/app.py, src/realestate/webapp/watchlist.py,

src/realestate/webapp/templates/pipeline.html,

src/realestate/webapp/templates/watchlist.html,

src/realestate/webapp/static/app.js,

src/realestate/webapp/static/watchlist_logic.js

데이터 등급

설계 결과

이번 단계는 워치리스트를 단순 목록에서 "문서 기반 후보 추적 작업대"로 올리는 작업이다.

• 1단계: 파이프라인 보드에서 연결된 워치리스트 후보가 있는 문서를 바로 찾아 /watchlist?source_doc_id=...

로 이동하게 한다.

• 2단계: 현재가·전세가·예상 분담금에 출처, 수집시점, 데이터등급, 원본확인 여부를 붙인다.
• 3단계: 실제 수집기가 연결되어 있을 때만 값을 갱신하고, 없으면 503으로 실패한다.

가정

• 현재가·전세가·예상 분담금은 모두 사용자가 입력하거나 실제 수집기가 반환한 명시값만 사용한다.
• 수집기가 반환하는 메타데이터는 원본확인 여부를 포함해야 한다.
• 네이버·국토부·법원 수집기는 후속 연결 대상이며, 이번 구현에서는 가짜 값을 만들지 않는다.
• 워치리스트의 기존 JSON 구조와 파이프라인 상태 파일은 유지한다.

한계·미확인

• 이번 설계 문서만으로 실제 단지의 가격이나 분담금이 확인된 것은 아니다.
• 네이버부동산, 국토부, 법원경매 원본 호출 성공 여부는 이번 문서 작성 시점에 새로 검증하지 않았다.
• 경매·재개발 관련 수치는 원본 문서 확인 전에는 스크리닝 보조값으로만 취급해야 한다.
• metric_collector는 연결 지점이며, 실제 서비스별 인증·세션·원본검증은 별도 구현이 필요하다.

구현 계획 문서

• 설계: docs/plans/2026-08-11-watchlist-pipeline-metric-source-data-design.md
• 실행 계획: docs/plans/2026-08-11-watchlist-pipeline-metric-source-data.md