주차장 운영 SaaS는 정산만으로 부족합니다: DevScent Parking 기준 영업 인수인계·인시던트 lifecycle 체크리스트
아파트 단지나 상업 빌딩에서 주차장 운영 시스템을 검토할 때, RFP에는 종종 요금 정산, LPR 연동, 차단기 제어만 적혀 있습니다. 실제 현장에서는 영업 단계에서 약속한 조건이 도면과 다르고, 야간에는 device 경보가 담당자에게 늦게 전달되며, 당직은 전화와 메신저를 오가며 같은 incident를 반복 확인합니다.
주차 관제 시스템을 도입한다는 것은 결제 모듈 하나를 붙이는 일이 아닙니다. 영업 컨설팅 → Blueprint 도면 → 운영 인수인계 → device incident → Discord/PWA 알림 → 당직 모바일 처리까지, 하나의 site_id로 데이터가 끊기지 않게 설계해야 합니다.
이 글은 DevScent가 설계·구현한 B2B 주차 운영 SaaS DevScent Parking 포트폴리오 사례를 기준으로, 도입 전에 먼저 점검할 체크리스트를 정리합니다. 주차 예약 앱이나 단순 정산 SaaS 비교 글이 아니라, 현장 운영 인프라 관점의 글입니다.
---
1. 왜 “정산만 있는 주차 SaaS”로는 부족한가
많은 도입 검토가 주차 요금 정산 시스템 기능 목록에서 시작합니다. 하지만 운영 책임자가 겪는 끊김은 다른 지점에서 발생합니다.
- 영업·PM이 제안서에 적은 조건과 현장 도면이 맞지 않음
- 관리사무소가 어떤 lot·unit·device가 실제로 연결됐는지 추적하기 어려움
- LPR·차단기·홈넷 경보가 콘솔·알림·당직 사이에서 누락됨
- 야간 당직이 폰 없이는 incident 상태를 확인·처리하기 어려움
B2B 주차 SaaS는 이 네 구간을 별도 엑셀·메신저·전화로 이어 붙이면, 정산 모듈이 아무리 정교해도 운영 신뢰가 쌓이지 않습니다. 먼저 물어야 할 질문은 “월 정산 리포트를 몇 종류 만들 수 있나”가 아니라, “한 site에서 영업 handoff 이후 incident가 당직 폰까지 어떻게 흐르나” 입니다.
---
2. 네 역할(페르소나)을 한 데이터 모델 위에 올리기
DevScent Parking은 포트폴리오 기준 영업·관리·현장·당직 네 페르소나의 워크플로우를 한 플랫폼으로 묶도록 설계했습니다.
| 역할 | 주로 하는 일 | 시스템에서 필요한 것 |
|---|---|---|
| 영업·PM | LEAD 상담, 제안, 계약, handoff | 프로젝트 stage·컨설팅 기록이 이후 도면·운영으로 이어짐 |
| 관리·운영 | lot·unit·device·요금 정책 관리 | 멀티테넌트 운영 콘솔, audit 추적 |
| 현장 | LPR·차단기·홈넷·데스크톱 모니터 | device status → incident 자동 발화 |
| 당직 | 야간·비상 대응 | push 알림, 본인 큐, ACK/Resolve 모바일 UX |
각 역할이 쓰는 화면은 다르지만, 같은 backend API와 같은 site_id를 공유해야 합니다. 그렇지 않으면 “콘솔에서는 해결됐는데 현장은 모른다”는 상태가 반복됩니다.
체크리스트: 도입 RFP에 역할별 화면 mockup만 있는지, 아니면 같은 tenant·lot·incident ID가 영업 handoff 이후에도 유지되는지 확인하세요.
---
3. LEAD → HANDOFF: 영업이 운영 데이터의 시작점이 되게
DevScent Parking의 핵심 흐름 중 하나는 프로젝트가 LEAD → CONSULT → PROPOSAL → CONTRACT → HANDOFF stage로 전환되며, handoff 시점에 운영이 인수할 정보가 구조화되는 것입니다.
도입 검토 시 확인할 항목:
- 영업 단계 기록이 버려지지 않고 운영 lot에 연결되는가
- handoff 이후 담당자·lot·정책이 누가 바꿨는지 audit로 남는가
- “계약은 됐는데 도면이 없다”는 공백을 시스템이 막는가
영업 컨설팅과 운영 인수인계를 분리된 툴에 두면, 주차장 인수인계 때마다 같은 질문을 다시 합니다. B2B 주차 SaaS는 영업 파이프라인 자체가 운영 마스터 데이터의 입력 채널이어야 합니다.
---
4. Blueprint 도면 → unit 트리: 현장을 코드와 맞추기
도면 설계 단계에서 흔한 실패는 “PDF 한 장”으로 끝나는 것입니다. DevScent Parking은 Blueprint Editor에서 snap 캔버스에 노드를 배치하고, snapshot 저장·seed 후 unit 트리가 자동 생성되는 흐름을 전제로 합니다.
주차 도면 설계가 시스템에 들어올 때 기대할 수 있는 것:
- 도면 변경이 버전·snapshot으로 남음
- lot·unit·device 관계가 콘솔에서 탐색 가능
- 이후 incident·시뮬레이션이 같은 unit 트리를 참조
현장 시스템(LPR·차단기·홈넷)과 클라우드 콘솔 사이에 도면-단위 매핑이 없으면, “어느 게이트에서 발생한 경보인지”를 사람이 매번 해석해야 합니다.
---
5. Device incident: 경보가 티켓이 되는 순간
주차 incident 관리에서 중요한 것은 수동 등록 UI만 있는지, device status가 자동으로 incident를 발화하는지입니다.
DevScent Parking 포트폴리오에 따르면, 예를 들어 LPR offline(severity=ERROR) 같은 상태가 CreateIncidentUseCase로 연결되고, dedup_key·audit event 패턴으로 중복·추적을 관리합니다. 운영자는 /ops 화면에서 severity·status·lot 필터로 라이브 ticker를 보고, drawer에서 ACK·Assign·Resolve·Reopen·Escalate·Close를 처리합니다.
도입 전 질문:
- device 경보와 사람이 올린 이슈가 같은 lifecycle을 타는가
- 동일 경보가 반복될 때 dedup이 되는가
- 누가 언제 ACK·Resolve 했는지 audit log가 남는가
정산 모듈만 강한 시스템은 incident가 메신저 스크린샷으로 남는 경우가 많습니다. 주차 관제 시스템의 신뢰는 “돈 계산”보다 “밤에 무슨 일이 있었고 누가 처리했는지”에서 먼저 검증됩니다.
---
6. Discord / PWA: 당직에게 가는 마지막 100m
incident가 콘솔에만 있으면 야간 당직은 PC 앞에 있어야 합니다. DevScent Parking은 Discord webhook과 support PWA(Web Push) 로 PRIMARY 담당자에게 라우팅하는 구조를 설계했습니다.
공개로 확인할 수 있는 화면:
- Atlas 콘솔 진입: parking.devscent.com/login
- support PWA: support.devscent.com — “사이트 담당자용 PWA, push 알림 수신 + 본인 큐”
영업 컨설팅부터 현장 운영까지 site_id 하나로 잇는 통합 콘솔의 진입 화면 (포트폴리오 갤러리)
현장 당직 모바일 관점 체크리스트:
- push를 받은 뒤 본인 큐만 보는가 (전체 lot 잡음 최소화)
- ACK → 출동 → Resolve가 한 incident ID로 닫히는가
- 미응답 시 escalation 정책이 정의돼 있는가 (포트폴리오: 미응답 시 ESCALATED 자동 전이 cron)
사이트 담당자용 PWA — push 알림과 인시던트 큐를 모바일에서 처리 (포트폴리오 갤러리)
---
7. 시뮬레이션·회귀팩: 운영 데이터를 오염시키지 않기
현장 연동 SaaS는 “한번 배포하면 끝”이 아닙니다. LPR·홈넷·요금 시나리오 변경이 운영 DB를 건드리지 않고 검증 가능해야 합니다.
DevScent Parking은 tenant_id = lot:N | sim:UUID | global 형태의 멀티테넌시로 prod와 sim을 격리하고, 회귀팩 시나리오로 PR마다 핵심 흐름을 검증하는 구조를 포트폴리오에 명시합니다. 이는 “24/7 무중단 보장” 같은 마케팅 문구가 아니라, 운영 안전성을 설계 단계에서 강제하는 방법입니다.
도입 검토 시:
- 시뮬레이션 tenant가 운영 데이터와 분리되는가
- 회귀 시나리오가 LPR·HOMENET·FEE 등 실제 장애 패턴을 커버하는가
- cleanup으로 sim 데이터를 일괄 삭제할 수 있는가
---
8. DevScent Parking 사례로 본 “먼저 설계할 것” 요약
| 순서 | 설계 포인트 | 왜 먼저인가 |
|---|---|---|
| 1 | site_id·tenant·lot 모델 | 영업 handoff 이후 모든 데이터의 뿌리 |
| 2 | 영업 stage → handoff | 인수인계 문서가 시스템 안에 남는지 |
| 3 | Blueprint → unit 트리 | 현장 device와 콘솔의 공통 언어 |
| 4 | device → incident 자동 발화 | 야간 경보 누락 방지 |
| 5 | Discord/PWA 라우팅 | 당직 모바일의 마지막 mile |
| 6 | ACK/Resolve·audit | 책임 추적·사후 분석 |
| 7 | sim·회귀팩 | 배포·정책 변경 시 운영 오염 방지 |
이 체크리스트는 모든 벤더·모든 LPR/차단기/홈넷과 완전 호환을 약속하는 글이 아닙니다. 공개 데모·포트폴리오·설계 문서 기준으로, 한 site에서 끊김 없이 이어지는 B2B 운영 SaaS를 어떻게 구성했는지 보여 주는 것이 목적입니다.
---
9. 한계와 MVP 범위 (정직한 경계)
이 글에서 주장하지 않는 것:
- 전국 N개 현장 도입, 상용 계약·매출 건수
- 모든 LPR·차단기·홈넷 벤더와의 보장된 호환
- 24/7 무중단·경쟁사 대비 “최고” 표현
- 특정 아파트·상업시설 명칭의 고객 실적
포트폴리오에 따르면 후속 단계로 영업 데모 모드, 정기권/valet, 다중 lot 전환, 네이티브 앱 등이 기반 위의 확장으로 정리돼 있습니다. 도입 검토 시 “지금 운영 가능한 범위”와 “로드맵”을 분리해 보는 것이 좋습니다.
---
10. 다음 단계
주차장 운영 시스템을 정산 모듈 선택이 아니라 운영 lifecycle 설계로 접근해야 한다면, 먼저 공개 자료로 흐름을 확인해 보세요.
→ DevScent Parking 포트폴리오에서 사례·갤러리·기술 흐름 보기
현장 연동 범위, incident 정책, 모바일 당직 UX까지 포함한 B2B 운영 SaaS 구축 견적이 필요하면 아래에서 범위를 정리할 수 있습니다.
AI로 만들어진 게시물입니다.