종합 부동산 대시보드와 재개발·재건축 분석기 상태진단
질의 원문
1. 지금 언급한 재개발 대상지는 별도로 관리하고 폭넓게 관심을 가질 수 있도록 해줘. 즉 재개발 분석기 만들어줘.
2. 비슷하게 전국의 재건축 분석기 만들어줘.
3. 내가 투자 분석을 요청하는 시군구 특정 지역이나 단지 등의 별도의 카데로리
4. 구리역 하이니티 리버파크 투자분석해줘.
5. 그리고 종합 부동산 투자 대시보드로 만들어 달라고 했는데 확인해보고 어느 단계인지 파악해줘.
수집 경로와 시점
- 수집시점: 2026-08-18 09:50 KST
- 확인 파일:
src/realestate/webapp/app.py,src/realestate/webapp/templates/index.html,src/realestate/webapp/analyst.py,src/realestate/webapp/orchestrator.py,src/realestate/webapp/tools.py,src/realestate/webapp/watchlist.py,src/realestate/redevelopment/opportunities.py,src/realestate/dashboard/investment_board.py - 실행 확인:
http://127.0.0.1:8767/investment_board.html응답 200 - 미실행 확인:
http://127.0.0.1:8766/연결 거부. 웹앱 서버는 현재 떠 있지 않고, 정적 현황판만 브라우저에서 열려 있음
데이터 등급
| 항목 | 등급 | 메모 |
|---|---|---|
| 코드 구조 | 1차/로컬 원본 | 현재 작업트리 파일 직접 확인 |
| 정적 현황판 상태 | 1차/로컬 실행 | 8767 정적 서버 응답 확인 |
| 웹앱 실행 상태 | 1차/로컬 실행 | 8766 연결 거부 |
| 현황판 문서 수 | 1차/로컬 산출물 | 투자 현황판 HTML 기준 17개 보드, 98건 분석 문서 표시 |
| 분석기 완성도 | 내부 진단 | 코드·UI·수집기 연결 상태 기반 평가 |
현재 단계
현재 프로젝트는 정적 현황판 + AI 분석 워크벤치 MVP + 워치리스트/파이프라인 단계다. 사용자가 원하는 최종상은 “AI가 붙은 종합 부동산 투자 대시보드”인데, 그 방향의 핵심 부품은 들어와 있지만 아직 재개발/재건축/사용자 요청 분석이 별도 분석기로 분리되지는 않았다.
| 영역 | 현재 상태 | 단계 |
|---|---|---|
| 투자 현황판 | docs/analysis 문서를 스캔해 17개 지역·테마 보드와 98건 분석 문서를 렌더링 | 운영 |
| AI 분석 워크벤치 | 자연어 질의를 분석 목적, 원천, 한계, 결과 구조로 변환하고 일부 원천 실행 | MVP |
| 원천 실행 | 네이버 단지, 법원경매, 국토부 실거래, 건축물대장, 서울 정비사업, 전국 정비사업 등 실행 레이어 있음 | 부분 운영 |
| 워치리스트 | 후보명, 지역, 유형, 목표가, 현재가, 전세가, 예상분담금, 원천 식별자 저장 | 운영 |
| 파이프라인 | 문서 기반 후보를 관찰/조사/가격대기/진입검토 등으로 관리 | 운영 |
| 재개발 분석기 | 정비사업 랭킹 엔진과 서울/전국 수집기는 있으나 전용 화면·분류·저장 흐름은 없음 | 미완 |
| 전국 재건축 분석기 | 단일 후보 재건축 가치 엔진과 후보 스캔은 있으나 전국 아파트 전용 분석 화면은 없음 | 미완 |
| 사용자 요청 카테고리 | 지역·테마 보드와 개별 물건·단발 질의 fallback은 있으나 요청 유형별 1급 카테고리는 아님 | 부분 |
왜 현황판처럼 보였나
정적 reports/investment_board.html은 분석 기록을 모아 보는 문서 허브다. 반면 사용자가 기대한 것은 “질문하면 AI가 목적을 세우고, 수집기를 호출하고, 후보를 만들고, 후보를 계속 관리하는 관제실”이다.
지금은 두 세계가 분리돼 있다.
investment_board.html: 결과 문서와 지역 보드를 잘 보여준다.- 웹앱
/: AI 워크벤치, 워치리스트, 파이프라인, 도구 화면이 있다. - 문제: 첫 화면에서 재개발/재건축 분석기가 명확히 보이지 않고, 사용자의 요청 단지·시군구 분석도 독립 카테고리로 느껴지지 않는다.
분석기 설계안
A안: 현황판 분류 강화
- 내용:
BOARD_GROUPS에재개발 후보관리,전국 재건축,사용자 요청 분석보드를 추가한다. - 장점: 빠르고 안전하다. 기존 현황판 흐름과 잘 맞는다.
- 단점: 여전히 문서 중심이라 “분석기”라기보다 정리판에 가깝다.
B안: 재개발/재건축 각각 독립 화면
- 내용:
/redevelopment-lab,/reconstruction-lab,/requested-targets를 만든다. - 장점: 기능이 분명하고 사용자가 찾기 쉽다.
- 단점: 화면이 늘어나면 다시 복잡해질 수 있다.
C-lite 추천안: 하나의 투자 분석기 안에 3개 탭
- 내용: 첫 화면은 단순하게
재개발 찾기,재건축 찾기,지역·단지 분석,관심후보 관리네 입구만 둔다. - 장점: 사용자는 간단히 들어가고, 내부에서는 모든 원천과 문서가 연결된다.
- 단점: 탭별 데이터 계약을 정리해야 하므로 구현은 A안보다 조금 더 크다.
추천은 C-lite다. 이전에 사용자가 “심플한데 단계단계로 들어가서 모든 것을 할 수 있도록” 요청했기 때문에, 별도 페이지를 무작정 늘리는 B안보다 첫 화면을 간결하게 유지하면서 내부 탭으로 깊이를 만드는 쪽이 맞다.
재개발 분석기 v1 범위
목표: “아직 본격 상승 전이거나 초기 단계인 노후·낙후 지역”을 별도 후보군으로 저장하고 계속 추적한다.
필수 입력:
- 지역: 전국/서울/시군구/동
- 단계: 후보지, 사전검토, 추진위, 정비구역, 조합설립, 사업시행, 관리처분
- 가격 조건: 현재가, 전세가, 총투입금, 목표가
- 위험 조건: 권리산정일, 조합원 지위, 추정분담금 공개 여부, 건축물대장 이슈
호출 원천:
- 서울 정비사업 OA-22856
- 국토부 전국 도시정비사업 CSV
- 정비사업 정보몽땅
- 네이버 매물/단지
- 국토부 연립다세대 실거래
- 건축물대장
출력:
- 후보 카드: 지역, 구역명, 단계, 가격대, 총투입금, 기대논리, 원본 확인 과제
- 후보 등급: 초기진입형, 사업성형, 안정진행형, 고위험 고수익형
- 현황판 자동 분류:
재개발 후보관리+ 지역 보드 - 워치리스트 등록: 원천 식별자와 권리산정 확인 플래그 포함
전국 재건축 분석기 v1 범위
목표: 전국 아파트 단지를 노후도, 용적률 여유, 대지지분, 가격, 전세가율, 교통·일자리 재료로 스크리닝한다.
필수 입력:
- 지역: 전국/시도/시군구/동
- 가격대: 매매가, 전세가, 목표 진입가
- 물건 유형: 아파트, 연립재건축, 소규모재건축
- 조건: 30년 이상, 세대수, 현재 용적률, 역세권, 학군, 호재
호출 원천:
- 네이버 단지/매물
- 국토부 아파트 실거래
- 건축물대장
- 정비사업 공개 데이터
- KOSIS/학교/교통/일자리 보조 원천
출력:
- 단지 카드: 건축연한, 용적률 여유, 대지지분 추정, 현재가, 전세가, 총투입금
- 재건축 점수: 노후도 + 용적률 여유 + 대지지분 + 입지 + 가격 모멘텀
- 현황판 자동 분류:
전국 재건축 분석기+ 지역 보드 - 워치리스트 등록: 네이버 단지번호, 면적, 현재가 출처 포함
사용자 요청 분석 카테고리
사용자가 시군구, 특정 동, 단지, 분양권, 경매 사건, 공매 물건을 물으면 별도 요청 분석 카테고리로 축적한다.
권장 분류:
요청/시군구: 예, 구리시 수택동, 서울 도봉구요청/단지: 예, 방학신동아1, 구리역 하이니티 리버파크요청/분양권: 예, 구리역 하이니티 리버파크요청/정비구역: 예, 북가좌6, 가재울7요청/경매공매: 법원 사건번호, 온비드 물건번호
현황판에는 기존 지역 보드와 함께 사용자 요청 분석 보드를 별도로 노출하는 것이 좋다. 이렇게 하면 지역별 탐색과 사용자가 직접 시킨 분석이 서로 섞이지 않는다.
구현 순서
- 테스트 먼저 추가: 현황판에 새 보드 3종이 생기는지, 재개발/재건축 질의가 별도 분석기 타입으로 분류되는지 확인한다.
- 데이터 계약 추가:
analysis_category,target_kind,target_region,target_name을 분석 문서 메타 또는 discover 로직에 반영한다. - 현황판 보드 추가:
재개발 후보관리,전국 재건축 분석기,사용자 요청 분석을 1급 보드로 노출한다. - 웹앱 첫 화면 정리:
재개발 찾기,재건축 찾기,지역·단지 분석,관심후보 관리네 입구로 재구성한다. - API 추가:
/api/analyzers/redevelopment,/api/analyzers/reconstruction,/api/analyzers/requested-target로 입력을 분리한다. - 워치리스트 연계: 분석 결과 후보를 유형별 원천 식별자와 함께 저장한다.
- 현황판 재생성: 모든 분석 문서가 새 보드에서 보이도록
invest-board를 재실행한다.
이번 진단의 결론
현재 단계는 대시보드 60%, AI 관제실 45%, 재개발/재건축 분석기 25%다.
- 대시보드: 문서와 보드로 볼 수 있는 상태는 이미 꽤 좋다.
- AI 관제실: 질의 계획과 수집 실행은 시작됐다.
- 분석기: 엔진은 있지만 사용자가 체감하는 독립 제품 화면으로는 아직 부족하다.
다음 구현은 C-lite로 가는 것이 맞다. 즉, 화면을 더 복잡하게 늘리는 것이 아니라 투자 분석기라는 하나의 단순한 입구 안에서 재개발, 재건축, 사용자 요청 단지를 탭으로 나누는 방식이다.
가정
- 사용자는 단순 문서 목록보다 질의형 분석 실행과 후보 관리가 결합된 웹앱을 원한다.
- 현황판은 계속 문서 기반 진실 소스로 유지한다.
- 분석기는 원본 수집과 후보 저장을 연결하되, 분담금·권리산정·시세는 원본 확인 전 확정값으로 쓰지 않는다.
한계
- 이번 문서는 상태진단과 구현 방향 정리이며, 분석기 코드는 아직 변경하지 않았다.
- 기존 작업트리에 미커밋 변경이 많아, 다음 구현은 TDD로 작은 단위부터 진행해야 한다.
- 정비사업 정보몽땅 로그인/API 기반 정밀 항목은 실제 호출 가능 범위와 응답 스키마를 별도 검증해야 한다.