[깡통전세 위험도 분석기 #01] 전세사기 막아주는 '깡통전세 분석기' 기획부터 아키텍처 설계까지 (React 말고 Next.js를 선택한 이유)

안녕하세요! 프론트엔드 개발의 즐거움과 치열한 삽질의 기록을 공유하는 웹개발 블로거입니다.

최근 몇 년간 대한민국을 뜨겁게 달구고, 지금 이 순간에도 수많은 세입자의 피눈물을 흘리게 만드는 사회적 이슈가 있습니다. 바로 '깡통전세'와 '전세사기' 문제입니다. 저 역시 자취방을 구하러 다니면서 등기부등본을 떼어볼 때마다 "이 집에 내 피 같은 전세금을 넣어도 진짜 안전한 게 맞나?" 하는 막연한 두려움을 느꼈습니다.

그래서 생각했습니다. "명색이 웹개발자인데, 일반인들도 등기부등본의 숫자만 입력하면 내 전세금이 안전한지 10초 만에 분석해 주는 계산기를 직접 만들어보자!"

 

그렇게 시작된 저의 사이드 프로젝트가 바로 '깡통전세 및 전세사기 위험도 분석기'입니다. (현재 제 개인 웹사이트에 열심히 구축 중이며, 완벽한 테스트를 거쳐 조만간 정식 오픈할 예정입니다!)

오늘부터 총 4편에 걸쳐 이 분석기를 만들면서 겪었던 치열한 고민, 아키텍처 설계, 그리고 피 튀기는 프론트엔드 트러블 슈팅 과정을 여러분과 공유하려고 합니다. 사이드 프로젝트를 준비 중인 개발자분들이나, 부동산 관련 도메인을 다루시는 분들께 큰 도움이 되길 바랍니다. 자, 첫 번째 메이킹 로그 시작하겠습니다!

 

1. 무엇을 만들 것인가? (기획 배경과 핵심 비즈니스 로직)

시중에 나와 있는 단순한 대출 이자 계산기로는 전세사기를 막을 수 없습니다. 전세 계약을 할 때 진짜로 중요한 것은 단순히 '집값'과 '전세금'의 비교가 아니기 때문이죠. 집주인이 은행에서 먼저 빌린 돈(선순위 대출금)이 있다면, 집이 경매로 넘어갔을 때 은행이 내 전세금보다 먼저 돈을 빼가버립니다.

그래서 저는 이 분석기에 다음과 같은 4가지 핵심 비즈니스 로직을 담기로 기획했습니다.

1. 실질 부채비율(LTV) 계산: 단순 전세가율이 아니라, (전세보증금 + 선순위채권) / 매매가 * 100 이라는 실질적인 부채비율을 계산합니다.
2. 신축 빌라 무자본 갭투자 경고: 매매가와 전세가의 차이(갭)가 3,000만 원 이하인 빌라의 경우, 이른바 '동시진행 사기'일 확률이 높으므로 강력한 경고 알림을 띄웁니다.
3. HUG 보증보험 가입 판별: 전세금과 대출금의 합이 매매가의 90% 이내여야 HUG(주택도시보증공사) 보증보험 가입이 가능하다는 룰을 적용합니다.
4. 주택 유형별 경매 스트레스 테스트: 만약 이 집이 경매로 넘어간다면? 아파트는 80%, 오피스텔은 70%, 빌라는 60%에 낙찰된다는 통계를 적용해, "최악의 경우 내 보증금을 얼마 잃게 되는지" 시뮬레이션합니다.

이 핵심 숫자들만 확실하게 알아도 억울하게 전세금을 날리는 일은 99% 막을 수 있다고 확신했습니다. 기획이 끝났으니, 이제 어떤 무기(기술 스택)로 개발할지 결정해야겠죠?

 

 

2. 왜 일반 React(CRA)가 아니라 Next.js인가?

프론트엔드 개발자라면 새 프로젝트를 시작할 때 누구나 하는 고민입니다. "그냥 만만한 React(CRA/Vite)로 뚝딱 만들까?"

하지만 저는 단 1초의 망설임도 없이 Next.js를 선택했습니다. 그 이유는 이 서비스의 본질이 '유틸리티(계산기) 툴'이기 때문입니다. 이런 웹 툴은 사용자들이 구글이나 네이버에 "전세사기 계산기", "깡통전세 확인법"이라고 검색했을 때 무조건 최상단에 노출(SEO, 검색엔진 최적화)되어야만 생명력을 가집니다.

일반적인 React는 CSR(Client-Side Rendering) 방식입니다. 구글 검색 로봇(봇)이 제 사이트에 방문했을 때, 화면에 있는 HTML은 텅 비어있고 자바스크립트가 실행된 후에야 화면이 그려집니다. 로봇 입장에서는 "어? 빈 페이지네?" 하고 검색 순위에서 제 사이트를 저 멀리 날려버릴 위험이 큽니다.

하지만 Next.js는 다릅니다. 서버에서 미리 완성된 HTML을 그려서 브라우저로 보내주는 SSR(Server-Side Rendering)을 기본적으로 지원합니다. 구글 봇이 들어오자마자 꽉 찬 텍스트와 UI를 긁어갈 수 있죠.

 

 

3. 상태(State) 관리와 데이터 흐름 아키텍처 설계

계산기 로직의 핵심은 '사용자가 숫자를 입력할 때마다 실시간으로 결과가 반응해야 한다'는 것입니다. 저는 JeonseAnalyzer라는 최상위 부모 컴포넌트에서 모든 상태를 쥐고, useEffect를 통해 데이터가 변경될 때마다 결과값을 다시 계산하도록 아키텍처를 설계했습니다.

실제 제가 작성한 상태 관리 코드를 보실까요?

 

"use client";
import { useState, useEffect } from 'react';

export default function JeonseAnalyzer() {
  // 1. 사용자 입력 상태 (Input State)
  const [houseType, setHouseType] = useState<string>('apartment'); 
  const [marketPrice, setMarketPrice] = useState<string>(''); 
  const [jeonsePrice, setJeonsePrice] = useState<string>(''); 
  const [seniorLoan, setSeniorLoan] = useState<string>('0'); 

  // 2. 계산 결과 상태 (Result State)
  const [ltvRatio, setLtvRatio] = useState<number | null>(null);
  const [isHugPossible, setIsHugPossible] = useState<boolean | null>(null);
  const [lossAmount, setLossAmount] = useState<number | null>(null);
  const [isVillaGapRisk, setIsVillaGapRisk] = useState<boolean>(false);
  
  // (생략...)

 

 

이렇게 입력값(Input)과 결과값(Result)의 State를 명확하게 분리했습니다. 그리고 사용자가 입력 폼에 금액을 칠 때마다 즉각적으로 로직이 돌아가도록 useEffect의 의존성 배열(Dependency Array)에 입력 상태들을 넣어주었습니다.

 

 

 // 주요 로직 계산 (useEffect 활용)
  useEffect(() => {
    // 콤마(,)를 제거하고 숫자로 변환
    const market = parseFloat(marketPrice.replace(/,/g, ''));
    const jeonse = parseFloat(jeonsePrice.replace(/,/g, ''));
    const loan = parseFloat(seniorLoan.replace(/,/g, '')) || 0;

    if (!isNaN(market) && !isNaN(jeonse) && market > 0) {
      // 1. 실질 위험 부채비율(LTV) 계산
      const calculatedLtv = ((jeonse + loan) / market) * 100;
      setLtvRatio(parseFloat(calculatedLtv.toFixed(1)));

      // 2. 신축 빌라 업계약서/갭투자 경고
      if (houseType === 'villa' && (market - jeonse) <= 3000) {
        setIsVillaGapRisk(true);
      } else {
        setIsVillaGapRisk(false);
      }
      
      // (HUG 보증보험 및 낙찰가율 스트레스 테스트 로직 생략...)
      
    } else {
      // 입력값이 부족하면 결과 초기화
      setLtvRatio(null);
      setIsHugPossible(null);
      setLossAmount(null);
      setIsVillaGapRisk(false);
    }
  }, [marketPrice, jeonsePrice, seniorLoan, houseType]);

 

 

이 구조의 장점은 매우 직관적이라는 것입니다. 하단의 JSX 렌더링 부분에서는 오직 ltvRatio나 isVillaGapRisk 같은 결과 상태값만 쳐다보고 조건부 렌더링을 해주면 되기 때문이죠.

나중에 컴포넌트 덩치가 너무 커지면, 이 상태들과 useEffect 로직을 통째로 묶어서 useJeonseCalculator라는 커스텀 훅(Custom Hook)으로 빼내어 UI와 비즈니스 로직을 완벽하게 분리하는 리팩토링도 진행할 계획입니다.

자, 여기까지 전세사기 분석기의 기획 의도와 Next.js를 선택한 이유, 그리고 전체적인 상태 관리 뼈대를 잡는 과정까지 살펴보았습니다. 처음엔 그럴싸하게 로직을 짰다고 생각했는데, 막상 뷰(View)를 만들며 본격적인 코딩에 들어가니 프론트엔드 개발자들의 영원한 숙제가 저를 기다리고 있더군요.

 

바로 사용자가 억 단위의 숫자를 입력할 때 실시간으로 콤마(,)를 찍어주면서, 동시에 수학 계산을 위해 숫자로 변환하는 과정이었습니다. "그냥 toLocaleString() 쓰면 되는 거 아냐?" 라고 생각했다가 예상치 못한 난관에 부딪혔는데요.

다음 [메이킹로그 2편]에서는 "억 단위 숫자 입력 폼 다루기 & 금액 한글 변환 포맷터 구현기"에 대해 아주 딥(Deep)하게 다뤄보겠습니다. 다음 트러블슈팅 글도 꼭 기대해 주세요!

[깡통전세 위험도 분석기 #02] 억 단위 숫자 입력 폼 콤마(,) 찍다가 만난 Hydration 에러 완벽 해결법