app.sallim/korea-realty

아파트 단지를 이름·지역으로 검색하고 **평형별 실거래 시세**를 함께 돌려준다. "○○아파트 34평 얼마야"류 단지 질문의 1차 도구다. query·region 중 하나는 필수. **이 축의 자리(시세 도구 3종 중)**: 단지가 특정되면 **이게 기본**이다. 지역 평균 도구들(realty_region_price_stats·realty_area_price_bands)은 단지 간 편차를 뭉개므로 단지 질문에 쓰지 마라 — 같은 동 같은 평형에서 단지 평균이 24% 벌어진 실측이 있다 (동 평균 3.96억으로 답했다가 대장 단지 호가와 1억 어긋난 사고). 반대로 지역 전체의 수준·추이 질문이면 저 둘로 가라. prices_by_area가 평형별 시세다 — pyeong_exclusive(전용평)와 pyeong_supply_est(분양평 어림)를 병기하므로, 사용자가 말한 "34평"(보통 분양평)은 pyeong_supply_est로 맞춰 답하라. 단지 수준 avg_price는 전 평형이 섞인 평균이니 평수 질문에 쓰지 말 것. 층별(저층/고층/RR) 시세·프리미엄 질문은 realty_complex_pyeong_price로 — 거기 층 밴드별 집계(price_by_floor_band)가 있다(이 도구엔 층 축이 없다). 응답의 complex_key는 realty_complex_rent_by_pyeong·[유료] 단지 도구들에 그대로 넣는 키다. **단지끼리 급을 견줄 때는 price_per_exclusive_m2(전용 ㎡당 실거래 단가)를 축으로 쓰라** — 행마다 실리고, **sort='unit_price'로 그 순서대로 받을 수 있다**(백엔드에 없는 축이라 이 응답에 실린 행만 다시 세운 것이다 — sort_applied.scope 참조). 행의 scores (composite·convenience)는 걸어서 닿는 **시설의 개수**이지 선호도가 아니다(직선거리만 세어 간선도로 횡단 같은 보행 장벽을 못 본다) — 그 점수로 단지에 줄을 세워 추천하지 마라. 입지 점수는 **미검증 참고값**이다(scores_meaning.status — transit 90점 이상 86.7%). "역세권이야?"는 행의 nearest_station·subway_distance_m(직선 m)으로 답하라. 응답의 scores_meaning·unit_price_axis에 근거가 있다. **견줄 때는 조건을 맞춰라 — 두 인자가 그 수단이다.** ㎡단가는 평형이 작을수록, 준공이 새로울수록 높다(⚠️ **전국 중앙값 이야기다** — 서울은 구축이 더 비싼 동이 28.0%다). `area_band_m2=59`면 각 단지의 대표 단가가 **전용 59±3㎡ 행만으로** 다시 계산되고, `construction_year_band=2018`이면 2013~2023년 준공 단지가 비교군으로 표시된다 (in_year_band). 연식이 더 지배적이다 — 법정동 안 ρ 중앙값이 연식 +0.7298 대 평형 +0.2245라, 연식이 섞인 ㎡단가 순위는 **사실상 신축 순**이 되기 쉽다. 두 인자 모두 **가격 계산·비교군 표시에만** 걸리고 단지 검색을 거르지 않는다(못 잰 단지는 목록에 남고 값이 null + 사유다). 몇 개를 쟀고 몇 개를 못 쟀는지는 응답의 coverage가 적는다. **0.84.0부터 scores.composite는 school + convenience다**(transit을 뺐다 — 전국 실측에서 고유값의 86.8%가 90~100에 몰려 변별력이 없고, 합산에 넣으면 법정동 격자 ρ 중앙값이 0.0825→0.0654로 떨어졌다). 백엔드 원장의 옛 가중평균 값은 **composite_legacy로 병기**하니 이전 응답과 견줄 때 그쪽을 쓰라 — 두 값은 척도가 다르다(가중평균 대 단순합).…

한국자산관리공사 **온비드 공매** 물건을 지역·용도·재산구분·감정가로 조회한다. 법원경매가 아니다. 공매는 국세징수법(압류재산)·국유재산법·공유재산법에 따른 처분이고 주관은 캠코다 — 아래 '이 축의 자리'와 응답의 `not_court_auction`을 반드시 함께 전하라. **이 축의 자리** — 공매 축은 도구가 둘뿐이다. 물건을 찾고 회차별 최저가 일정을 보는 것이 이 도구, "보통 감정가의 몇 %에 낙찰되나"는 realty_onbid_sale_rate다. **법원경매를 물었다면 여기가 아니라 realty_search_auctions**이고, 사건번호에 '타경'이 들어 있으면 그쪽이다. 사용자가 그냥 "경매"라고만 했으면 **어느 쪽인지 되물어라** — 둘을 합쳐 세거나 섞어 평균내면 그 답은 틀린다. **행이 물건이 아니다.** 원장의 한 행은 물건이 아니라 **공매조건(회차)**이다 — 한 물건이 1~10회차 입찰 일정을 미리 갖고 회차마다 최저입찰가가 내려간다(실측: 물건당 3.51행). 이 도구는 **물건 단위로 접어서** 돌려준다: `rounds_total`(전체 회차)·`rounds_remaining` (마감 전 회차)·`next_round`(다음 입찰 회차의 기간과 최저입찰가)·`last_round`(마지막 예정 회차 = 더 안 팔리면 도달하는 바닥값). 응답의 `condition_rows`가 접기 전 행 수다 — **행 수를 물건 수로 인용하지 마라**(71% 과대). ⚠️ **최저입찰가 '비공개'** — 원문이 숫자가 아니라 '비공개'인 회차가 있다(529행). 그 회차의 금액은 **null**이지 0이 아니다. `min_bid_undisclosed_rounds`가 그 수이고, 평균·최저값 계산에서 빠져 있다. ⚠️ **압류재산 주소는 번지가 가려진다** — 결과 원장 기준 압류재산의 61.7%가 '강원특별자치도 춘천시 ***********' 꼴이다. 물건 목록 쪽은 번지까지 나오지만 (실측 마스킹 0건), 같은 물건을 결과에서 다시 찾을 때는 시군구까지만 유효하다. ⚠️ **시도 표기를 우리가 손봤다** — 원천에 '전남광주통합특별시' 같은 통합 표기가 7,757행 있어 시군구로 분해해 `sido`에 넣었다. 손보기 전 원문은 `sido_source`, 분해 근거는 `sido_basis`('as_is' = 원문 그대로 / 'split_by_sgg' = 시군구로 갈랐다)에 있다. 권리분석·감정평가서·공고 원문은 이 원장에 없다. 공매의 권리 인수 규칙은 법원경매와 다르므로 realty_policy_rules(민사집행법 기준)의 답을 여기에 옮기지 마라.

소액임차인 최우선변제의 **금액표를 고르는 도구**다 — 판정기가 아니다. "최우선변제금 얼마까지 나와요?"에 현행표를 읊으면 틀린다. 적용되는 표는 **최선순위 담보물권을 취득한 날이 속한 시행령 판**이고(부칙 경과조치), 2008-08-21 이후 7개 판이 서로 다르다. 2015년 근저당이 붙은 서울 주택이면 지금 경매라도 2014-01-01 판 (9,500만원 이하 / 3,200만원)으로 잰다 — 현행표(1억6,500 / 5,500)를 쓰면 소액임차인이 아닌 사람을 소액임차인이라 답하게 된다. 경계를 지켜라: ① **범위에 든다 ≠ 받는다.** 경매개시결정등기 전 대항요건·배당요구종기까지 배당요구·주택가액 1/2 한도·다수 임차인 안분·임차권등기 후 임차인 제외가 전부 남아 있다 (응답 `not_a_conclusion`). ② `security_right_date`가 없으면 **표를 고르지 않는다** — 현행표를 기본값으로 주는 순간 이 도구가 막으려던 오답이 된다. **그렇다고 날짜를 지어내지도 마라**(2026-08-22 제보: 사용자가 연도만 줬는데 클라이언트가 `2019-01-01`을 생성했다). 연도만 안다면 `security_right_year`에 그 연도만 넣어라 — 그 해 전체가 한 판 안이면 서버가 날짜 없이 답하며 **"연도로 판을 골랐다"를 응답에 명시**하고, 판이 갈리는 해면 표를 고르지 않고 등기 접수일을 되묻는다. ③ 시 안에서 동에 따라 과밀억제권역이 갈리는 곳(인천·남양주·시흥)은 구간을 **안 고르고** 별표 원문을 낸다. ④ **주택만**이다 — 상가는 상가건물임대차보호법으로 금액표가 다르다. ⑤ 배당액 계산· 말소기준권리 판정·인수 여부는 하지 않는다. 규칙 전체와 갈림길은 realty_policy_rules(topic=auction_rights)가 진실원이다.

청약 경쟁률과 **실제 당첨 가점 커트라인**을 낸다 — "나 가점 52점인데 당첨될까?"의 정량 근거. 가점 자체를 모르는 사용자는 realty_subscription_score(무주택·부양가족·가입기간 선언 → 배점표 적용)로 먼저 점수를 만들어 my_score로 넘겨라. **비어 있으면 왜 비었는지부터 읽어라(2026-08-20 축 신설).** 이 축의 원천은 주 1회 전량 수집 이라 "아직 공표가 안 됐다"와 "공표는 됐는데 우리가 아직 안 걷었다"가 똑같이 빈 배열로 보인다 — 실측(공고 2026000323)에서 청약홈엔 1순위 경쟁률 4.33·12.90·15.55가 이미 공표됐는데 우리 응답은 by_house_type=[]였다. `freshness_verdict.verdict`가 그 둘을 가른다(아래 큰따옴표는 **필드가 아니라 그 필드의 값**이다): "not_yet_published"(접수가 안 끝났다 — 없는 게 정상) · "not_yet_collected"(**우리 미수집이다. 절대 '경쟁률이 없다'고 답하지 말고 check_url로 안내하라**) · "unknown"(못 가른다) · "not_published" · "collected". 대조 재료인 접수 종료일은 announcement.rcept_endde·freshness_verdict.apply_end에 있다. result_status의 뜻은 응답의 `result_status_legend`가 정본이다(`special_only`는 일반공급 결과가 아직인데 특별공급 신청현황만 온 상태 — '결과 없음'이 아니다). **없는 공고는 '미발표'가 아니다(2026-09-08, T-2026W37-81).** house_manage_no가 경쟁률 원장에도 분양 공고 원장에도 없으면 `error` 응답(`result` 값 "not_found")으로 거절하고 벤치마크를 내지 않는다 — 종전엔 어떤 번호를 넣어도 "not_published"+"아직 발표되지 않았다"가 나가 오타·가상 번호가 '접수 전 공고'로 둔갑했다. 원장 조회 자체가 실패하면(404 아닌 오류· 시간 초과) 그것도 "not_published"가 아니라 거절 응답이다 — 거절에는 정상 응답에 **없는** `error`·`result` 두 키가 붙고 그 값이 "lookup_failed"다. **여기서 백틱은 필드 이름이고 큰따옴표는 값이다** — "lookup_failed"·"not_found"라는 이름의 키는 어느 응답에도 없다(찾지 마라). 지역 벤치마크만 필요하면 house_manage_no 없이 region·sigungu로 부르라. **지역별 경쟁률의 분모는 추정하지 말고 `allocated_households_rank1_local`을 써라 (2026-08-21 신설).** 공표 경쟁률은 (그 지역구분 신청 ÷ 배정 세대수)라 분모를 되돌릴 수 있고, 해당지역 1순위 행의 98.3%에서 그 분모가 정수 하나로 특정된다(전수 실측). 되찾지 못한 행은 그 값이 null이고 `allocated_households_basis.range`에 구간만 있다 — 그때는 세대수로 단정하지 마라. 공고 원문 비율로 만든 `regional_priority. estimated_allocation.est_*`는 **실측이 있는 행에서 쓰면 안 된다**(실측과 어긋나면 `estimate_superseded`가 붙는다 — 실측 2026000323 084.9165A: 추정 47 vs 실측 78세대). 두 가지 경로를 자동으로 고른다: 1) 결과가 발표된 공고 → 그 단지의 주택형별 1순위 해당지역 경쟁률·당첨 최저/평균/최고 가점. 2) 아직 접수 전이라 결과가 없는 단지 → 같은 지역 최근 공고들의 실제 커트라인 분포 (regional_benchmark…

민영주택 일반공급 청약 가점(만점 84)을 배점표로 계산한다. 민영주택 일반공급 가점제 점수(만점 84)를 **선언된 값**에 배점표를 적용해 계산한다 — 무주택기간 32 + 부양가족 35 + 통장 가입기간 17. "내 청약 가점 몇 점이야?"의 자리다. 경계를 지켜라: ① 세 입력 전부 **선언**이다 — 기산점·부양가족 인정은 등본·혼인관계 사실판단이라 서버가 판정하지 않고, 응답 traps(오기입=부적격 당첨 취소 사유)를 반드시 함께 전하라. ② 산출 점수는 realty_subscription_odds의 my_score로 넘겨 당첨 커트라인과 비교하는 것이 다음 수다. ③ 배점표 원문·기산 규칙은 realty_policy_rules(topic=subscription_account)가 진실원이다.

시군구마다 앞으로 들어올 아파트와 늘어나는 세대를 같은 창으로 나눠 수급을 판정한다. "○○ 공급 과잉이야?", "세종 대전 서울 경기 수급", "어디가 입주 대비 수요가 많아?"류 질문의 자리 — 입주(청약홈 공고, 향후 N개월)를 연 단위로 환산해 최근 12개월 세대 증가로 나눈 **비율**과 판정(과잉 >1.5 · 공급 우위 1~1.5 · 균형 0.5~1 · 부족 <0.5 · 세대 감소 중)을 주고, 같은 행에 교차검증 신호(순이동·매매 거래량 증감·전세/월세 증감과 월세 비중·1순위 경쟁률· 낙찰가율·미분양)를 싣는다. 판정과 신호가 엇갈리면 `conflict`에 적는다. **결론에 반드시 옮길 것**: · 입주는 **하한**이다 — 정비사업 조합원분이 공고에 없어 서울처럼 재건축 비중이 큰 곳은 '부족'이 실제보다 과장된다. `meta.disclosures`를 그대로 전하라. · `permit_pipeline_households`(사업승인 기준)는 **입주에 더하지 마라**(이중계상). · `denominator_unstable=true`면 비율이 분모 탓에 흔들린다 — 배수를 단정하지 마라. · 판정 구간은 **우리 규칙**이지 공식 기준이 아니다. 호가 매물·비아파트는 데이터에 없다. · 지표마다 기준 시점이 다르다 — `meta.series_as_of`로 밝혀라.

아직 공고가 안 난 예정 공급을 사업계획승인 기준으로 본다. **아직 분양 공고가 안 난** 예정 공급을 사업계획승인 기준으로 본다 — "지금 넣을까, 다음 걸 기다릴까", "이 동네 앞으로 입주 폭탄 있나"류 질문의 자리. 청약홈(realty_presale·realty_move_in_supply)은 **모집공고일에야** 등록되므로 공고 전 물량이 구조적으로 안 보인다. 이 도구의 원천은 주택법 **사업계획승인**이라 공고 2~3년 전 단계가 잡힌다: 사업명·세대수·승인일·착공예정일·사용검사 예정일(=예상 입주). 재당첨 제한(분양가상한제 단지는 10년)·전매제한이 걸린 결정에서는 **대안 정보가 없으면 "지금 아니면 끝"이라는 잘못된 압박**이 생긴다 — 청약 상담이면 이 도구를 함께 불러라. 두 축을 **더하지 마라**(이중계상) — 이미 공고가 난 단지도 승인 목록에 남아 있다. **이미 모집공고가 난 사업**은 블록 표기가 겹치면 행에 `announced_notice`가 붙는다 — 그 행은 '다음 분양'이 아니라 realty_presale·realty_subscription_odds의 영역이다. 표식이 없어도 기공고일 수 있다(meta.announced_cross_check 참조). 승인 전(지구계획·공모) 물량은 여기에도 없으니 이 값도 하한이다(`interpretation`). **층수 축(2026-08-20 신설 · 3차 수집=동별개요)**: `max_floor`는 사업계획승인 시점의 **계획** 층수다(변경승인으로 움직인다 — 준공 확정층수가 아니다). 값이 비면 **'저층'으로 읽지 말고 미상으로 읽어라.** 최저층·출처·부재사유는 **3차 수집이 붙은 회차에만** 함께 실린다 — `min_floor`가 있으면 그 사업에 **실제로 그 층수의 동이 있다**는 뜻이라 저층 선호(고소공포)·고층 조망 상담의 근거가 되고, `max_floor_source`가 있으면 그 층수를 어디서 가져왔는지, `max_floor_absent_reason`이 있으면 왜 비었는지를 말해 준다. **독스트링은 고정값이라 지금 원장 상태를 말할 수 없다** — 2026-08-20~09-07에는 이 안내만 먼저 나가고 필드를 만드는 백엔드 절반이 20일간 안 붙어 있었다(T-2026W33-68). 그러니 **이번 회차에 무엇이 실렸는지는 응답의 `meta.floor_axis`를 보라.** 그 문구는 응답을 보고 갈린다 — 거기서 "없다"고 하면 정말 없는 것이니 찾지 마라. `business_body`(사업주체·시공사)는 미준공 구간에서 **구조적으로 빈다** — 준공 후 등록되는 원장에만 있어 3차로도 안 메워진다.

답이 틀렸을 때 신고하거나(kind='결함'), **원문 질문을 넘겨 축을 확인받는다**(kind='질문기록'). **결함**: 사용자가 "그거 틀렸다", "이상하다", "숫자가 안 맞는다"고 하면 **먼저 이 도구를 호출한 뒤** 정정 답변을 하라. 신고는 서버 운영자에게 전달되어 실제 수정에 쓰인다. 사용자가 지적하지 않았는데 추측으로 부르지는 말 것. **질문기록**: 사용자의 원문 질문을 그대로 넘기면 서버가 **그 자리에서 라우팅을 돌려준다** (응답의 `routing`) — 어느 축·어느 도구로 가야 하는지, 그 축의 라우팅 규칙, **우리 데이터 밖이면 그 사실과 대신 볼 곳**, 지역명이 모호하면 후보까지. 판정은 결정론이라 같은 질문이면 같은 답이 나오고, **못 고르면 `axis: null`과 사유를 준다**(추측으로 채우지 않는다). 직전 호출 기록과 대조해 **엉뚱한 축을 부르고 있으면 그것도 알려 준다** — 이건 모델이 적은 기억이 아니라 서버가 가진 호출 기록이라, 도구를 스무 번 부르며 헤매는 것을 앞에서 끊는다. 같은 호출이 기록도 한다: 이 서버는 클라이언트가 이미 도구 호출로 번역한 뒤를 보므로 **사용자의 원문 질문을 볼 수 없고**, 우리가 무엇을 못 담고 있는지는 그 원문으로만 알 수 있다(질문은행·로드맵의 원천). **개인 식별 조합은 반드시 일반형으로 바꿔서** 넣는다. 두 종류가 한 도구인 이유: 무인증 공개 서버라 쓰기 표면을 하나로 묶어 상한을 함께 건다 (CLAUDE.md 규칙 2). 시간당 상한도 공유한다. **이 도구는 일일 조회 한도(quota) 밖이다** — 다른 도구가 `quota_exceeded`로 막혀도 신고는 접수된다(2026-08-18 수리). 한도를 다 쓴 사람의 신고가 못 오면 우리는 우리가 못 본 것을 영영 모른다. 남용 방지는 시간당 상한(전체 60건·발신자당 20건)이 진다.

법원경매 물건을 자연어 문장으로 검색한다(경매 전용 — 청약·시세는 다른 도구다). 법원경매 물건을 자연어로 검색한다. **경매 전용** — 청약·분양 공고는 realty_presale, 분양가 적정성은 realty_presale_vs_market, 시세 통계는 realty_region_price_stats. 지역·물건종류·유찰횟수·감정가를 질의에서 뽑아 필터링한다. 예: "서울 강남구 아파트", "유찰 2회 이상인 경기도 오피스텔", "서울 아파트 감정가 5억 이하". 이 파서는 최소 어댑터라 못 쓰는 축(면적·기일·층 등)이 있다. 못 쓴 조건은 응답의 `unapplied_conditions`에 적히므로, 그게 비어 있지 않으면 결과 범위를 좁게 오인하지 말고 `realty_search_auctions`로 조건을 직접 지정해 다시 조회하라. 각 결과의 id는 이어서 fetch(id)에 그대로 넣으면 상세를 볼 수 있다. **이 축의 자리** — 경매 검색은 둘이고 입력 형태로 갈린다. 사용자의 말을 문장 그대로 넘길 때가 이 도구(`search`)이고, 지역·종류·감정가·유찰횟수를 **값으로 이미 알 때**는 `realty_search_auctions`다(면적·기일·층 등 이 파서가 못 쓰는 축도 거기서 지정한다). 상세는 `fetch`로 이어간다 — 여기 나온 id를 그대로 넣으면 된다.