SitePilot — 지번 하나로 끝내는 딜 스크리닝

문제

부동산 개발 딜은 초기 스크리닝에서 대부분 걸러집니다. 그런데 그 스크리닝 한 건에 드는 시간이 너무 길었습니다. 토지이용계획확인원에서 용도지역을 보고, 부동산공시가격 알리미에서 공시지가를 찾고, 세움터에서 건축물대장을 열고, 실거래가 공개시스템에서 인근 거래를 뒤지고, 그 숫자들을 엑셀에 옮겨 적어 용적률과 사업비를 계산하는 일.

물건 하나에 반나절. 매물장에 수십 건이 올라오면 검토는 시작도 못 하고 며칠이 갑니다. 정작 중요한 판단에 쓸 시간은 남지 않았습니다.

접근

흩어진 조회를 하나로 합치는 것만으로는 부족했습니다. 실무에서 진짜 필요한 건 "이 땅을 사서 지으면 얼마가 남는가"였기 때문에, 조회 결과가 그대로 사업성 계산의 입력으로 흘러 들어가야 했습니다.

설계에서 신경 쓴 것

• 서버 없는 구조. Cloudflare Pages Functions로 API 프록시를 두고, 응답은 KV에 캐싱했습니다. 공시지가는 1년, 실거래는 1개월 TTL — 갱신 주기가 다른 데이터를 같은 캐시 정책으로 묶으면 쓸데없이 API를 두드리거나 낡은 값을 보게 됩니다.
• 세금 엔진은 검증 가능하게. 실제 운용 모델의 세무 시트를 지방세법 구조 그대로 코드로 옮기고, 원본 엑셀과 값이 일치하는지 테스트로 고정했습니다. 세액은 틀리면 치명적이라 LLM에 맡길 수 없는 영역입니다.
• 합필 검토 지원. 개발 딜은 필지 하나로 끝나는 경우가 드뭅니다. 쉼표로 여러 지번을 넣으면 면적을 합산하고 공시지가를 면적가중 평균합니다.
• 팀 배포까지 고려. 일부 공공 API가 해외 IP를 막기 때문에, 포터블 Node를 동봉한 zip을 만들어 팀원이 더블클릭 한 번으로 자기 PC에서 띄울 수 있게 했습니다.

결과

지번을 넣으면 수 초 안에 규제·시세·사업성이 한 화면에 뜨고, 버튼 한 번으로 개발 CF 엑셀과 IM 초안 PPT가 떨어집니다. 스크리닝이 빨라지니 더 많은 딜을 보게 됐고, 그게 실제 성과였습니다.

돌아보며

가장 많이 배운 건 "어디까지 자동화하고 어디서 멈출 것인가"였습니다. 초기에는 전부 자동으로 채우려 했는데, 그러면 사용자가 숫자를 검증하지 않고 그대로 씁니다. 지금은 모델 추정치와 실측치를 시각적으로 구분하고, 오차를 함께 보여주고, 최종 산출물은 반드시 사람이 편집할 수 있는 엑셀·PPT로 내보냅니다.

공공 API는 문서와 실제 응답이 다른 경우가 많아, 응답을 정규화하는 계층을 따로 두고 필드가 비어 올 때의 폴백을 전부 정의해야 했습니다. 이 부분이 전체 코드의 절반 가까이 됩니다.