PRODUCT_OVERVIEW

ZIP:ON 제품 기준과 서비스 경계

Status: Current Product Baseline

이 문서는 ZIP:ON이 어떤 문제를 풀고, 어떤 기능을 우선순위로 두며, 어떤 일은 하지 않는지 정리한 제품 기준 문서입니다. 아직 모든 기능이 구현된 것은 아니며, 새 기능을 설계할 때 이 문서를 먼저 확인합니다.

과거 지표 분석과 정확 주소 위험진단 MVP 이후의 주거용 매매, 상가 창업, 임야·토지, 꼬마빌딩, 사용자 문서 업로드 분석 확장 기준은 ZIP:ON 확장형 서비스 정의를 함께 확인합니다.

Goal

ZIP:ON은 현재 매물을 보여주는 서비스가 아니라, 사용자가 입력한 지역·유형·정확 주소를 과거 지표와 공공데이터로 분석하는 서비스입니다. 지역·유형 입력에는 가격지수, 실거래가, 전세·월세 지표, 수익률, 공실률, 데이터 한계를 해석하고, 정확 주소 입력에는 물건의 법적 정체, 가격·권리·용도·입지·환경 측면의 위험 신호와 계약 전 확인사항을 정리합니다.

핵심 질문은 아래와 같습니다.

이 지역·유형·주소의 과거 지표는 무엇을 말하며,
계약 전에 무엇을 직접 확인해야 하나?

MVP에서 사용자는 홈 화면의 분석/진단 입력 폼에서 지역, 유형, 장소, 정확 주소, 보증금, 월세, 관리비, 계약 목적, 매물 설명을 입력해 ZIP:ON의 분석을 시작합니다. 이 진입점은 현재 매물 목록 검색이 아니라 과거 지표 분석과 계약 전 확인을 위한 목적 기반 입력 흐름입니다.

사용자가 지역·유형을 입력하면 ZIP:ON은 현재 매물을 보여주지 않고 과거 지표의 추세, 변동성, 데이터 한계를 해석합니다. 사용자가 정확 주소나 매물 정보를 입력하면 공공데이터와 사용자의 목적을 바탕으로 법적 정체, 가격 적정성, 보증금 위험, 용도 적합성, 입지 리스크, 추가 확인사항을 정리해야 합니다.

Service Positioning

기존 부동산 서비스는 보통 아래 질문에 답합니다.

어디에 어떤 매물이 있는가?

ZIP:ON은 아래 질문에 답합니다.

이 지역·유형의 과거 지표는 어떤 흐름인가?
내가 보고 있는 이 물건은 계약 전 무엇을 조심해야 하는가?

현재 제품 방향에서는 강남 원룸, 서울대입구역 근처, 상가 월세 같은 입력도 현재 매물 목록으로 보여주지 않습니다. ZIP:ON은 현재 매물 재고를 직접 제공하는 대신, 사용자가 이미 보고 있는 주소·지역·유형을 기준으로 과거 실거래가, 가격지수, 전세·월세 지표, 수익률, 공실률 같은 지표를 자세히 해석합니다.

따라서 ZIP:ON은 단순 매물 탐색 서비스가 아닙니다. 제품 정체성은 아래 두 표현으로 잡습니다.

부동산 거래 전 건강검진 서비스
부동산 계약 전 리스크 체크 엔진
목적 기반 공공데이터 해석 서비스
과거 지표 기반 부동산 판단 보조 서비스

Expanded Service Definition

MVP의 대표 사용자는 지역·유형의 흐름을 이해하거나 전세·월세 계약을 앞두고 정확 주소를 검토하려는 부동산 초보자입니다. 확장형 ZIP:ON은 특정 매물 유형 하나만 다루는 서비스가 아니라, 사용자의 분석 목적에 따라 기준이 달라지는 서비스입니다.

확장형 대상:

1. 전세·월세 계약을 앞둔 임차인
2. 주거용 매매를 검토하는 실거주자
3. 오피스텔·빌라·아파트 매입을 검토하는 개인
4. 상가를 얻어 창업하려는 자영업자
5. 상가 또는 건물을 매입하려는 투자자
6. 임야·토지를 싸다고 보고 있는 초보 투자자
7. 전원주택·창고·공장 부지를 찾는 사람
8. 꼬마빌딩 매입을 검토하는 개인 투자자
9. 부동산 계약 전 최소한의 리스크를 확인하고 싶은 일반 사용자

확장형 사용자 입력은 주소 하나로 끝나지 않습니다. 지역, 장소, 유형, 주소, 매물 설명, 계약 목적, 거래 형태, 희망 가격, 보증금, 월세, 매매가, 관리비, 면적, 층수, 업종, 개발 목적, 보유 자료, 등기부등본, 중개대상물 확인설명서, 임대차 관련 자료, 현장 사진까지 단계적으로 받을 수 있어야 합니다. MVP에서는 먼저 지역·유형 과거 지표 분석과 정확 주소 위험진단에 필요한 입력을 홈 화면 분석/진단 입력 폼에서 수집합니다.

같은 오피스텔이라도 목적에 따라 질문이 달라집니다.

사용자 목적	먼저 볼 것
전세입자	보증금 회수 가능성, 근저당, 전세보증보험, 권리관계
월세입자	월세 적정성, 관리비, 생활 인프라, 건물 상태
매수자	매매가 적정성, 공시가격, 노후도, 향후 거래 가능성
투자자	수익률, 공실 가능성, 임대수요, 관리비, 매각 리스크

핵심 순서:

1. 사용자 입력 정제
2. 주소·좌표·법정동 코드 변환
3. 물건 정체 판별
4. 건축물·토지 기본정보 조회
5. 시세·실거래가·공시가격 조회
6. 용도지역·지적·토지규제 확인
7. 목적별 위험도 계산
8. 고정 위험 항목별 구조화 점수 산정
9. 목적별 추가 분석
10. 생활·상권·안전·환경 분석
11. 계약 전 확인사항 및 불가능 영역 안내
12. 사용자 자료 업로드 분석
13. 최종 진단 리포트 생성
14. 계약 전 체크리스트 제공

ZIP:ON은 주소를 넣자마자 실거래가부터 조회하지 않습니다. 먼저 이 물건이 아파트, 다세대주택, 다가구주택, 오피스텔, 상가, 토지, 임야, 꼬마빌딩, 근린생활시설 중 무엇인지 판별합니다. 물건의 정체가 달라지면 뒤에서 확인해야 할 데이터와 위험도 계산 방식도 달라집니다.

Core Values

1. 모르는 것을 먼저 분류한다

사용자는 본인이 무엇을 모르는지도 모를 수 있습니다.

원룸인 줄 알았는데 다가구주택일 수 있다.
상가인 줄 알았는데 내 업종이 불가능할 수 있다.
싼 땅인 줄 알았는데 개발이 어려운 임야일 수 있다.

ZIP:ON의 첫 책임은 사용자의 표현을 그대로 믿는 것이 아니라 공부상 물건 유형을 먼저 판별하는 것입니다.

2. 흩어진 공공데이터를 목적별로 해석한다

data.go.kr과 공공 API에는 데이터가 많지만, 일반 사용자는 API 이름이 아니라 아래 질문의 답을 원합니다.

이 전세 위험해?
이 상가에서 카페 가능해?
이 땅에 집 지을 수 있어?
이 건물 사면 손해일까?

ZIP:ON은 API 응답을 그대로 나열하지 않고, 사용자의 목적에 맞는 위험 문장과 확인 항목으로 바꿔야 합니다.

3. 계약 전 행동으로 연결한다

최종 결과는 단순 정보가 아니라 다음 행동이어야 합니다.

등기부등본을 확인하세요.
선순위 임차인 내역을 요청하세요.
전세보증보험 가능 여부를 확인하세요.
건축물대장을 확인하세요.
구청 인허가 부서에 문의하세요.
현장 방문 때 누수, 곰팡이, 수압을 확인하세요.

Does And Does Not

하는 것

ZIP:ON은 사용자의 목적을 먼저 묻습니다.

전세로 들어갈 건가?
월세로 살 건가?
매매해서 거주할 건가?
매매해서 투자할 건가?
상가로 창업할 건가?
건물을 사서 임대수익을 얻을 건가?
임야나 토지를 개발 목적으로 보는 건가?

같은 오피스텔이라도 거주자는 관리비, 교통, 소음, 옵션을 보고, 전세입자는 보증금 회수, 근저당, 보증보험을 봅니다. 투자자는 수익률, 공실률, 지역 흐름을 봐야 합니다.

ZIP:ON은 물건의 법적 정체를 판별합니다.

사용자 표현: 원룸
실제 가능성: 다가구주택, 다세대주택, 오피스텔, 도시형생활주택, 근린생활시설, 고시원
 
사용자 표현: 상가
실제 가능성: 제1종 근린생활시설, 제2종 근린생활시설, 업무시설, 위반건축물 일부
 
사용자 표현: 땅
실제 가능성: 대지, 전, 답, 임야, 도로, 잡종지

물건 정체별 대표 확인 방향:

판별 결과	대표 확인 방향
다가구주택	건물 전체 선순위 임차인 보증금 확인
다세대주택	해당 호실의 등기와 전유부 확인
오피스텔	주거용 사용 가능 여부, 전세보증보험 가능성 확인
상가	업종 인허가, 용도, 배수·환기·전기용량 확인
임야·토지	도로 접면, 산지·농지 규제, 개발행위 가능성 확인
꼬마빌딩	임대수익, 공실, 권리관계, 건축물 상태 확인

ZIP:ON은 목적별 위험도와 확인 문장을 생성합니다.

전세 위험도: 높음
이유:
- 이 물건은 다가구주택으로 추정됩니다.
- 다가구주택은 건물 전체 선순위 임차인 보증금을 함께 확인해야 합니다.
- 전세보증금이 주변 매매 추정가 대비 높을 가능성이 있습니다.
- 등기부등본과 선순위 임차인 내역 확인이 필요합니다.

하지 않는 것

ZIP:ON은 아래 역할을 하지 않습니다.

• 네이버부동산, 네이버 지도, 카카오 지도처럼 매물 목록을 많이 보여주는 서비스
• 직방, 다방처럼 방 사진과 가격을 중심으로 탐색하는 서비스
• 현재 시장에 나온 매물을 자체 inventory로 보여주는 서비스
• 공인중개사를 대체하는 서비스
• 법무사나 감정평가사를 대체하는 서비스
• 등기부등본을 100% 자동 판정하는 서비스
• “무조건 계약해도 된다” 또는 “무조건 계약하지 말라”고 확정하는 판정자
• 상가, 임야, 꼬마빌딩까지 MVP에서 모두 처리하는 서비스
• 전세사기 여부를 확정하는 서비스
• 상가 창업 성공 가능성을 확정하는 서비스
• 토지 개발행위허가 가능성을 확정하는 서비스
• 실제 하자, 실제 유동인구 체감, 권리금 적정성을 확정하는 서비스

특히 등기 권리관계, 선순위 임차인, 실제 하자, 영업 가능성은 API만으로 확정하기 어렵습니다. ZIP:ON은 판정자가 아니라 사전 진단자입니다.

확장형 서비스에서도 아래 영역은 반드시 “직접 확인 필요”로 분리합니다.

소유자 실시간 확인
근저당권 말소 조건
신탁등기 세부 내용
선순위 임차인 전체 보증금
실제 누수·곰팡이·층간소음
상가 실제 매출
권리금 적정성
건물주 성향
도로 사용 권리
개발행위허가 가능성
전기·수도 인입 비용

현재 MVP 범위에서는 챗봇 UI, 대화 저장, 자유 대화형 프롬프트 생성, Spring AI 설명 보조를 제거했습니다. 대신 backend-only OpenAI/ChatGPT API는 LEASE_RENT_RISK 고정 평가 항목의 구조화 점수 산정 보조자로만 사용할 수 있습니다. ZIP:ON의 판단 경계는 공공데이터·DB·사용자 확인 상태를 기반으로 한 구조화된 위험 문장, 체크리스트, 항목별 점수이며, 최종 점수와 등급은 백엔드가 계산하고 계약 가능 여부를 확정하지 않습니다.

MVP Interface And Supporting Scope

MVP의 중심 가치는 현재 매물 미제공, 과거 지표 분석, 정확 주소 위험진단입니다. 다만 실제 서비스 MVP에는 아래 세 화면 축도 함께 포함합니다.

1. 분석/진단 입력 폼: 홈 화면에서 시작하는 지역·유형·정확 주소·계약 조건 입력
2. 커뮤니티: 분석/진단 이후 질문, 경험, 사례, 신고, 댓글을 다루는 사용자 상호작용
3. 관리자 페이지: 사용자, 권한, 커뮤니티 신고, 외부 API 호출 로그, 분석/진단 이력을 관리하는 운영 도구

커뮤니티와 관리자 페이지가 MVP에 포함된다는 뜻은 ZIP:ON의 첫 가치를 커뮤니티나 운영 도구로 바꾼다는 뜻이 아닙니다. 커뮤니티는 위험진단 이후의 질문과 사례를 모으는 보조 경험이고, 관리자 페이지는 ROLE_ADMIN으로 보호되는 제한된 도메인 API를 통해 운영 리스크를 관리하는 도구입니다. 관리자 페이지를 임의 SQL 실행기나 내부 DB 편집기로 설계하면 안 됩니다.

Representative Persona

MVP의 대표 페르소나는 전세·월세 계약을 앞둔 28세 사회초년생입니다.

처음으로 원룸 또는 오피스텔 전세를 구하고 있다.
네이버부동산이나 직방에서 매물을 봤지만,
이게 다가구인지 다세대인지 오피스텔인지 잘 모른다.
전세사기가 걱정되지만 등기부등본, 건축물대장,
선순위 임차인, 전세보증보험 같은 개념이 어렵다.
공인중개사 설명만 믿기에는 불안하고,
계약 전에 최소한 무엇을 확인해야 하는지 알고 싶다.

이 페르소나가 MVP에 적합한 이유는 문제가 명확하고, 공공데이터로 1차 분석 가능한 영역이 많으며, 등기부등본 업로드 기능과 결합하기 좋기 때문입니다.

Representative Scenario

사용자는 직방이나 네이버부동산에서 마음에 드는 원룸 전세 매물을 봅니다. ZIP:ON에 들어오면 매물 목록 검색보다 홈 화면의 분석/진단 입력 폼을 먼저 사용합니다.

주소: 서울시 관악구 ○○동 ○○번지
보증금: 1억 2천만 원
관리비: 8만 원
역 도보: 8분
사용자 표현: 원룸 전세

ZIP:ON에는 이렇게 입력합니다.

홈 화면 위험진단 입력
-> 전세·월세 위험진단 시작
 
이 원룸 전세 안전한가요?
주소: 서울시 관악구 ○○동 ○○번지
보증금: 1억 2천만 원
목적: 전세 거주

서비스 내부는 아래 순서로 처리해야 합니다.

1. 주소 정제
2. 법정동코드 변환
3. 건축물대장 조회
4. 물건 유형 판별
5. 다가구/다세대/오피스텔 여부 확인
6. 주변 전월세 실거래가 조회
7. 주변 매매 실거래가 조회
8. 공시가격 또는 추정 가격 확인
9. 전세가율 위험도 계산
10. 건축물 위반, 용도, 사용승인일 확인
11. 등기부등본 업로드 요청
12. 선순위 임차인 확인 필요 여부 안내
13. 계약 전 체크리스트 생성

결과 화면은 사용자가 다음 행동을 이해할 수 있어야 합니다.

진단 결과: 계약 전 추가 확인 필요
 
이 물건은 사용자가 말한 "원룸"이지만 공부상 다가구주택일 가능성이 있습니다.
다가구주택은 호실별로 소유권이 나뉘는 구조가 아니기 때문에
내 보증금만 보는 것이 아니라 건물 전체 선순위 임차인 보증금과
근저당을 함께 확인해야 합니다.
 
계약 전 반드시 확인할 것:
1. 등기부등본 갑구·을구 확인
2. 근저당권 채권최고액 확인
3. 선순위 임차인 보증금 내역 요청
4. 전세보증보험 가입 가능 여부 확인
5. 건축물대장상 위반건축물 여부 확인
6. 계약금 입금 계좌가 소유자 명의인지 확인

확장형 최종 리포트는 단순 점수가 아니라 아래 구조를 가져야 합니다.

1. 물건 정체 요약
2. 사용자 목적 요약
3. 가격 적정성 요약
4. 보증금 또는 매매가 위험도
5. 건축물 위험도
6. 권리관계 확인 필요사항
7. 용도 적합성
8. 입지·생활·상권·환경 리스크
9. 직접 확인해야 하는 영역
10. 계약 전 체크리스트
11. 사용자용 진단 리포트

현재 MVP의 RentRiskDiagnosisResponse는 이 확장형 리포트의 첫 slice다. 이후 매매, 상가, 토지, 꼬마빌딩으로 확장할 때도 최종 출력은 “확정 판정”이 아니라 사용자의 계약 전 확인 행동으로 끝나야 합니다.

Product Domain Direction

기술적으로 ZIP:ON은 단순 API 호출 서비스가 아닙니다. 아래 흐름을 갖는 목적 기반 진단 엔진으로 설계해야 합니다.

User Purpose
-> Property Identification
-> Public Data Collection
-> Risk Scoring
-> Checklist Generation
-> Document Upload Analysis
-> Recommendation Report

처음부터 모든 영역을 구현하지 않습니다. 새 기능은 MVP 기준인 전세·월세 위험진단에 직접 기여하는지 먼저 확인합니다.

Decision: Product Direction

Context

부동산 서비스는 매물 탐색, 지도, 커뮤니티, 실거래 분석, 계약 위험진단 등으로 쉽게 넓어질 수 있습니다. 범위를 넓히면 서비스 정체성이 흐려지고 MVP 구현도 어려워집니다.

Options considered

1. 매물 탐색 중심 플랫폼
2. 지역·단지 정보 통합 플랫폼
3. 계약 전 목적 기반 위험진단 서비스

Decision

MVP는 계약 전 목적 기반 위험진단 서비스로 둡니다. 사용자의 첫 위험진단은 홈 화면 입력 폼에서 시작합니다. 커뮤니티와 관리자 페이지는 이 MVP를 운영 가능한 서비스로 만들기 위한 지원 범위로 함께 둡니다.

Why

제공 문서의 대표 페르소나와 문제의식이 가장 선명하게 드러나는 방향입니다. Spring Boot 학습 프로젝트 관점에서도 주소 정제, MyBatis 조회, 외부 API 연동, 위험도 계산, 체크리스트 응답 DTO, 예외 처리, 테스트까지 학습하기 좋은 축입니다.

Tradeoffs

매물 목록, 지도, 커뮤니티를 위험진단과 무관하게 먼저 크게 만들면 눈에 보이는 화면은 빠르게 늘지만, “왜 ZIP:ON을 써야 하는가”라는 제품 차별점은 약해집니다. 반대로 위험진단을 먼저 잡으면 외부 API와 데이터 해석 난이도가 높아지므로 단계별 구현이 필요합니다. 관리자 페이지는 운영상 필요하지만 사용자용 핵심 경험처럼 노출하지 않고 제한된 운영 도구로 유지합니다.

Future revisit

지역·유형 과거 지표 분석과 정확 주소 위험진단이 실제 입력과 결과 화면까지 end-to-end로 동작한 뒤, 주거용 매매, 상가 창업, 임야·토지, 꼬마빌딩 순서로 확장합니다.

Related Documents

• ZIP:ON 확장형 서비스 정의
• 과거 지표 기반 부동산 분석 MVP 범위
• 공공데이터 API 연동 전략
• ZIP:ON 성장 로드맵
• ZIP:ON API와 함수 학습 지도
• CODEX reference index

Learning Path

1. First read: 이 문서의 Service Positioning, Core Values, Does And Does Not
2. Then inspect: 과거 지표 기반 부동산 분석 MVP 범위
3. Then run: 현재 구현 상태는 README.md의 backend/frontend 실행 명령으로 확인
4. Then debug: 기능 추가 전 공공데이터 API 연동 전략의 불가능 영역 확인
5. Key concept to understand: 제품 기준이 Controller, Service, Mapper, DTO 경계를 결정한다