결론부터 말씀드리면
지인이 아파트 코킹 영업을 하는데, 일정 관리를 구글 캘린더 하나로만 버티고 있었습니다. 고객 전화가 오면 수첩에 받아 적고, 끊고 나서 캘린더에 수동 입력 — 이 과정이 매일 반복됐습니다. “일정 관리가 너무 어렵다”는 말 한마디를 듣고 웹앱을 하나 만들어줬습니다.
결과적으로 주소 입력 한 번에 건물 정보 조회·견적·일정 등록이 한 화면에서 끝나는 영업 업무 자동화 툴이 됐습니다. 전화를 받으면서 주소만 물어보면 3초 안에 준공연도·세대수·평형이 뜹니다.
1. 어떤 문제를 해결하려 했나
지인은 아파트 코킹(창틀 누수 방지 실리콘 작업) 영업을 하고 있습니다. 고객 전화가 오면 수첩에 주소를 받아 적고, 통화가 끝난 뒤 구글 캘린더에 일정을 수동으로 입력하는 방식으로 버티고 있었습니다. 일정이 겹치거나 빠지는 건 일상이었고, 통화 중에 건물 정보를 파악하는 건 아예 엄두를 못 냈습니다.
현장 영업에서 고객 전화를 받는 그 순간 필요한 정보는 세 가지입니다.
| 필요 정보 | 영업 판단 기준 |
|---|---|
| 준공연도 | 노후도에 따라 공사 범위·난이도 달라짐 |
| 총 세대수 | 단지 규모별 견적 단가 산정 기준 |
| 평형 | 창틀 개수 추정 근거 |
통화 중에 네이버 부동산, 국토교통부 사이트를 따로따로 뒤지는 건 현실적으로 불가능합니다. 건물 정보 조회, 견적, 일정 등록 — 이 세 가지를 한 화면에서 끝낼 수 있는 영업 업무 자동화 웹앱이 필요했습니다.
2. 어떻게 만들었나 — 구조부터 배포까지
주소 입력 하나로 건물 정보를 즉시 가져오고, 그 자리에서 일정까지 등록할 수 있는 구조를 목표로 잡았습니다. 핵심 흐름은 단순합니다.
고객 주소 입력
↓
카카오 API → 정확한 주소 + 위치 정보 추출
↓
국토부 API → 준공연도, 세대수, 구조, 층수 조회
↓
화면에 즉시 표시 + 네이버 부동산 링크 자동 생성문제는 인터넷에 올리는 과정에서 생겼습니다. 국토부 서버가 특정 클라우드 인프라에서 오는 요청을 차단해서, 중간에 우회 경로를 하나 더 만들어야 했습니다. 결국 브라우저 → 클라우드 서버 → 중계 서버 → 국토부 API 구조로 완성했습니다.
기술적으로 복잡해 보이지만 사용자 입장에서는 그냥 주소 입력하면 3초 안에 결과가 나오는 웹앱입니다.
3. 핵심 기능 목록
| 기능 | 설명 |
|---|---|
| 건물 정보 즉시 조회 | 주소 입력 → 준공연도·세대수·층수 3초 내 표시 |
| 고객·일정 관리 캘린더 | 견적(파란색) / 작업(주황색) 구분 달력 |
| 자동 평형 배지 | 전용·공용 면적 계산 → 공급면적 기준 평형 자동 표시 |
| 근처 일정 추천 | 반경 5km 이내 기존 일정 자동 추천 |
| 카카오 내비 연동 | 고객 주소 → 원클릭 내비게이션 실행 |
| 모바일 반응형 UI | 현장 스마트폰에서도 사용 가능 |
근처 일정 추천 기능은 실제로 가장 유용한 기능입니다. 새 고객 주소를 검색하면 기존 일정 중 5km 이내에 있는 현장을 자동으로 보여줍니다. “이 동네 왔을 때 옆 단지도 같이 가자” 동선 계획이 자동으로 됩니다.
4. 만들면서 막혔던 것들
실제로 작업에 쓴 시간은 일주일 정도였습니다. 가장 어려웠던 건 코딩 자체가 아니라 비용을 한 푼도 쓰지 않는 방법을 찾는 것이었습니다. NAS나 개인 서버가 있으면 훨씬 단순한 구조로 끝났겠지만, 그게 없었습니다. 서버리스 환경도 처음이라 쓸 수 있는 무료 티어가 뭔지, 어떻게 조합하는지부터 찾아야 했습니다. 국토부 API 차단 문제도 해결책이 명확하지 않아 가장 오래 붙잡은 부분이었습니다. 결국 Cloudflare Workers + Render.com 무료 플랜 조합으로 인프라 비용 제로로 완성했습니다.
고객이 아파트 이름만 말할 때
“잠실 파크리오요” — 이렇게 이름만 말하면 정확한 주소를 못 찾습니다. 주소로 먼저 찾고, 없으면 이름으로 다시 찾도록 두 단계 검색 방식을 구현했습니다.
세대수가 0으로 나오는 버그
국토부 데이터는 단지 전체가 아니라 동(棟)별로 나옵니다. 경비실이나 지하주차장 동이 먼저 나오면 세대수가 0이 뜨는 문제가 있었습니다. 전체 동의 세대수를 합산하고, 가장 높은 건물을 대표로 지정하는 방식으로 해결했습니다.
화면에 이상한 숫자가 보이는 현상
웹앱 좌측 하단에 // 1779906826 같은 숫자가 노출되는 버그가 있었습니다. 빌드 과정에서 자동으로 붙는 주석이 그대로 화면에 나온 것인데, 배포 시 자동으로 제거하도록 처리해서 해결했습니다.
5. 배포 — 지인 전용 독립 계정으로
처음부터 지인 혼자 쓸 수 있도록 독립 계정 기준으로 배포했습니다. 고객 정보와 일정 데이터가 외부와 완전히 분리되고, 사진 저장 방식도 처음 구조보다 안정적으로 잡았습니다.
6. 현재 상태 및 로드맵
완성하고 나서 가장 달라진 건 통화 방식이었습니다. 전화를 받으면서 주소만 물어보면 건물 정보가 바로 떴고, 통화가 끝나기 전에 일정까지 잡혔습니다. 수첩에 받아 적고 나중에 캘린더에 옮기던 과정이 사라졌습니다. 지인 반응은 간단했습니다. “굉장히 좋다. 효율적이다.”
쓰기 시작하고 나서 추가 요청이 들어왔습니다. 지도 보기, 일정 상세 항목, 글자 크기 조절 — 실제로 쓰는 사람이 생기니 필요한 것들이 보이기 시작했습니다. 요청이 들어올 때마다 조금씩 붙여가며 지금 구조가 됐습니다.
마치며
이 프로젝트는 반복적인 현장 업무를 자동화한 영업 업무 자동화 웹앱의 실제 구현 사례입니다. 핵심은 세 가지입니다.
- 정보 수집 자동화 — 주소 입력 한 번에 건물 정보 취합, 검색 시간 제로
- 현실적인 문제 대응 — API 차단, 데이터 오류 등 실제 부딪힌 문제를 하나씩 해결
- 동선 최적화 — 근처 일정 자동 추천으로 하루 다건 처리 효율화
현장 영업직이라면 업종에 맞게 같은 구조를 커스텀 적용할 수 있습니다. 반복되는 작업이 있다면 생각보다 단순한 구조로 자동화가 가능한 경우가 많습니다.