주차 앱 구축 방법: 실시간 가용성 + 결제

사용 사례와 성공 지표 정의

주차 가용성 앱은 ‘모두를 위한 것’처럼 보일 수 있지만, 성공적인 제품은 하나의 명확한 약속에서 출발합니다. 당신은 운전자가 더 빨리 공간을 찾게 도울 건가요, 더 적은 단계로 결제하게 도울 건가요, 아니면 운영자가 재고와 규정 준수를 관리하는 데 도움을 줄 건가요?

첫 릴리스는 하나의 주요 수행 과업(job-to-be-done)에 집중하고, 나머지는 이를 지원하도록 해야 합니다.

어떤 문제를 해결하나요?

대부분의 주차 제품은 다음 결과 중 하나(또는 조합)에 집중합니다:

• 더 빨리 주차 찾기: 현재 주차 가능한 위치를 보여주어 ‘크루징(빈 공간 찾아 헤매기)’을 줄입니다.
• 빠른 결제: 연석이나 게이트에서 마찰을 제거하고 신뢰할 수 있는 결제 경험을 제공합니다.
• 벌금 회피: 규칙을 명확히 하고 세션 연장을 쉽게 하며 결제를 증명합니다.
• 혼잡 완화: 도시와 운영자가 수요를 구역 전반에 분산하도록 돕습니다.

문제가 발생하는 지점을 구체적으로 적으세요. 예를 들어 “점심 시간대 시내 도로 주차”는 “예약이 가능한 공항 주차장”과는 다른 요구사항을 만듭니다.

대상은 누구인가요?

사용 사례는 주요 사용자와 지원 이해관계자를 명시해야 합니다:

• 운전자: 정확한 실시간 주차 데이터, 단순한 결제, 규정 준수에 대한 확신을 원합니다.
• 주차장/부지 운영자: 점유 현황 가시성, 요금 제어, 분쟁 감소 및 예측 가능한 정산을 원합니다.
• 도시/운영자: 활용도 개선, 정책 집행, 보고 기능을 원합니다.
• 단속 팀: 빠른 확인(번호판·구역·세션 기준)과 명확한 상태를 필요로 합니다.

주요 사용자를 정하면 UI에서 무엇이 ‘우수’인지, 어떤 데이터가 신뢰할 수 있어야 하는지를 결정하기 쉬워집니다.

일반적인 앱 유형(하나를 선택하세요)

1. 거리 주차 앱: 구역, 시간 제한, 규칙 복잡성, 단속 통합이 중요합니다.
2. 주차장 앱: 시설별 인벤토리, 출입 흐름, 영수증, 때로는 QR 또는 번호판 인식이 필요합니다.
3. 혼합 마켓플레이스: 거리 + 주차장을 결합하며 검색, 필터, (선택적으로) 예약을 추가합니다.

집중된 주차 앱 MVP는 나중에 확장할 수 있으니—첫 버전을 마치 모든 모델을 이미 지원하는 것처럼 설계하지 마세요.

약속에 맞는 성공 지표 정의

사용자 가치와 비즈니스 성과에 연결된 지표를 사용하세요:

• 주차 찾는 시간: 앱 열기부터 ‘길안내/주차 완료’까지의 중앙값(분).
• 결제 전환률: 검색/결과에서 체크아웃으로 이어지는 비율.
• 결제 성공률: 시도된 거래 중 완료된 비율(수단별 실패 모니터링).
• 유지율: 주간/월간 활성 사용자 및 구역/구역별 재방문자 수.

주차 가용성 앱이라면 정확도도 측정하세요: ‘사용 가능’이 실제 주차로 이어지는 빈도. 이런 지표는 기능과 파트너십이 확장될 때까지 제품 결정을 실무적으로 유지하게 해줍니다.

기능 선택: MVP vs 나중에 추가할 것

주차 가용성 앱은 빠르게 ‘모두를 위한 것’으로 확장될 수 있습니다. 가장 빠르게 출시(그리고 학습)하려면 운전자가 오늘 주차하고 결제하는 데 반드시 필요한 것과 나중에 유용한 것을 분리하세요.

운전자의 핵심 경로(MVP)부터 시작

주차 결제 앱의 MVP는 하나의 단순한 약속을 충족해야 합니다: 공간을 찾고, 요금을 이해하고, 문제 없이 결제한다. 우선순위:

• 지도 + 검색: 근처 시설과 구역을 명확한 핀과 필터(요금, 운영시간, 높이 제한)로 표시하세요.
• 실시간 가용성: 초기에 간단한 “공간 있음 / 제한적 / 만차” 표시면 충분한 경우가 많습니다—시각적 화려함보다 정확도가 중요합니다.
• 요금 투명성: 시간별/일별 요금, 최소금액, 최대 한도 및 추가 요금을 사용자 확정 전에 표시하세요.
• 길안내: 선택한 출입구로 원터치 길안내(Apple/Google 지도 딥링크).
• 결제 + 연장: 세션 시작, 연장, 허용 시 종료 기능.
• 영수증: 앱 내 기록 및 비용 처리를 위한 이메일 영수증.

이렇게 하면 반복 사용 가능한 신뢰할 만한 주차 앱 MVP를 만들 수 있고, 실시간 주차 데이터 품질과 결제 전환을 검증할 수 있습니다.

공급을 열어주는 운영자 기능

운영자를 성공적으로 만들지 못하면 가용성과 요금이 흐트러집니다. 운영자를 위한 ‘최소 실행 콘솔’에는 보통 다음이 포함됩니다:

• 인벤토리 관리: 구역, 주차 수, 운영시간, 제한 규칙
• 요금 규칙: 시간대별 요금, 이벤트 요금, 유예 기간, 최대 체류 시간
• 프로모션: 프로모 코드나 할인 창을 통해 채택 유도
• 보고서: 점유 추세, 수익, 상위 위치, 분쟁

초기에는 경량 웹 대시보드로 숨겨두더라도 이러한 도구는 스마트 주차 앱의 정확성을 유지하는 데 도움이 됩니다.

관리자 필요 사항(건너뛰지 마세요)

출시 첫날부터 필요한 기본 백오피스 워크플로우:

• 사용자 조회 및 지원 도구
• 환불/무효 처리 및 영수증 재전송
• 분쟁 처리 메모 및 감사 추적

나중에 추가할 만한 기능

핵심 흐름이 안정되면 다음을 고려하세요:

• 예약 (강력하지만 취소·노쇼 규칙이 필요)
• 정기권/월간 접근 권한
• EV 충전 상태 및 요금
• 발렛 핸드오프 흐름
• 빈번한 이용자를 위한 구독

불확실하다면 반복 세션을 지원하는 가장 작은 기능 집합을 출시한 뒤 실제 사용을 기반으로 확장하세요 (참고: /blog/parking-app-mvp-guide).

실시간 가용성 데이터를 어떻게 확보할지 계획

실시간 가용성은 사용자가 즉시 판단하는 기능입니다: 지도가 빈 공간을 보여주고 실제로는 없으면 신뢰가 급격히 떨어집니다. 빌드 전에 점유 신호가 어디서 올지, 얼마나 자주 새로고침할지, 불확실성을 어떻게 전달할지 결정하세요.

일반적인 신호 소스(그리고 장단점)

거리 주차의 경우 보통 여러 입력을 혼합합니다:

• 센서(지면/연석): 개별 공간별 정확성, 하지만 설치 비용이 높음.
• 카메라 + 컴퓨터 비전: 넓은 커버리지를 제공하지만 날씨, 반사, 이중주차에 취약할 수 있음.
• 미터 이벤트(시작/중단/만료): 유용한 대리 지표지만 지불 시간이 실제 점유를 항상 의미하지는 않음.
• 단속 스캔(번호판 인식): 강한 검증 신호이나 연속적이지 않을 수 있음.
• 사용자 신고: 빠르고 저렴하지만 인센티브와 사기 방지 장치 필요.

주차장/부지의 경우 점유 파악이 더 직관적인 편입니다:

• 게이트 카운터(입/출): 신뢰할 수 있는 합계, 층/구역별 세부는 적음.
• 티켓/포스 시스템: 결제와 검증을 연결함.
• 운영자/애그리게이터 API: 사용 가능하면 가장 빠른 경로.

최신성과 신뢰도: 기대치를 설정

소스별 최신성 목표를 정의하세요(예: 주차장은 30–60초마다, 도로 대리 지표는 2–5분마다). UI에는 “X분 전 업데이트”와 신호 품질·최신성·교차검증 기반의 신뢰도 점수(예: 높음/중간/낮음)를 표시하세요.

데이터가 없을 때는 추측하지 마세요

명확한 폴백 정책을 가지세요:

• **“알 수 없음”**을 표시하고 “사용 가능”이라고 추정하지 마세요.
• 대안 추천(근처 주차장, 인접 블록, 오프피크 요금)을 제시하세요.
• 사용자가 급할 때 신뢰도 높은 구역만 필터할 수 있게 하세요.

이 단계의 계획은 이후 파트너십과 데이터 모델을 형성하므로 초기에 문서화하고 제품 요구사항으로 취급하세요.

통합 및 파트너십 체크리스트

주차 가용성 앱은 그 뒤에 있는 데이터와 파트너에 크게 의존합니다. 통합 전에 누가 어떤 것을 제공할 수 있고 그 데이터를 어떻게 사용할 수 있는지 명확히 하세요.

협력해야 할 가능성이 높은 주체

대부분의 스마트 주차 프로젝트는 여러 소스를 혼합 사용합니다:

• 도시/지자체(커브 규칙, 구역, 허가, 단속 신호)
• 주차 운영자(주차장/부지: 인벤토리, 요금, 운영시간, 입/출 이벤트)
• 하드웨어 벤더(센서, 게이트, LPR, 미터, 키오스크)
• 데이터 애그리게이터(여러 공급처의 실시간 주차 데이터 번들)

주차 결제 앱이라면 운영자가 POS 흐름(플레이트 결제, QR, 티켓 기반 등)을 통제하므로 특히 중요합니다.

초기 통합 시 질문 목록

이것을 사전 점검 리스트로 다루세요—답변이 MVP 범위와 일정에 영향을 미칩니다.

API 접근 및 문서화

• 안정적인 API·웹후크를 제공하나요, 아니면 배치 내보내기만 있나요?
• 샌드박스 환경과 테스트 자격증명이 있나요?

커버리지 및 최신성

• 어떤 시설/구역이 포함되어 있나요(오늘 포함 vs 계획)?
• 가용성 업데이트 빈도는 어떻게 되나요?

요청 제한, 가동시간, 지원

• 요청 제한과 호출당 비용은 어떻게 되나요?
• 가동시간·응답시간에 대한 SLA가 있나요?
• 사고/지원 프로세스 및 예상 응답 창은 어떻게 되나요?

비용 및 상업 모델

• 위치당, 거래당, 수익 공유, 고정 라이선스 중 어떤 모델인가요?
• 요금 표시, 예약 활성화, 결제 처리에 대한 추가 수수료가 있나요?

초과하지 말아야 할 계약 기본 항목

초기 파일럿이라도 서면 조건이 필요합니다—특히 실시간 주차 데이터를 재배포할 계획이라면 더더욱.

• 데이터 소유권: 파생 데이터(예측, 점유 추정치)를 누가 소유하나요?
• 재배포 권리: 앱에 표시하고 저장하며 모델 학습 등에 사용할 수 있나요?
• 프라이버시·보안: 번호판, 디바이스 ID, 결제 토큰을 누가 처리하나요?
• 변경 관리: API 변경·단종에 대한 통지 기간은?
• 책임: 가용성 오류나 요금 변경이 발생하면 누가 책임지나요?

파일럿 전략: 검증 후 확장

1–2개 지역(예: 한 주차 운영자 + 한 도로 커브 구역)으로 시작하세요. 일관된 데이터를 제공할 수 있고 결과(전환, 결제 완료, 분쟁률)를 측정할 수 있는 위치를 선택하세요. 신뢰성과 단위 경제를 검증한 뒤에는 시설별로 확장하세요.

사용자 경험 설계(흐름과 화면)

주차 앱은 처음 30초 동안 승패가 갈립니다. 사람들은 보통 이동 중이고 시간 제약이 있으며 옵션을 빠르게 비교합니다. UX는 타이핑을 최소화하고 결정 피로를 줄이며 “결제 후 바로 이동”이 자연스럽게 느껴지도록 해야 합니다.

지도 우선 흐름으로 시작하세요

대부분의 운전자에게 시각적 모델이 가장 빠릅니다. 실용적인 핵심 흐름:

검색 구역 → 옵션 보기 → 선택 → 결제 → 연장

기본 뷰를 지도 기반으로 유지하되, 명확한 핀 상태(사용 가능, 제한, 만차, 알 수 없음)를 표시하세요. 사용자가 요금이나 도보 거리로 비교하고 싶을 때를 위해 지도/목록 토글도 제공하세요.

초기에 설계해야 할 주요 화면

마찰을 줄이고 신뢰를 쌓는 화면에 집중하세요:

• 온보딩: 어떤 데이터를 사용하는지(위치, 결제)와 사용자가 얻는 이점(실시간 가용성, 영수증)을 간단히 설명
• 권한(위치): 필요할 때 요청하며, 평문 설명과 위치 거부 시 대체 경로 제공
• 검색 + 지도/목록: 빠른 필터(가격, 거리, EV, 높이 제한)를 숨기지 않고 제공
• 스팟 상세: 가격 내역, 운영시간, 규칙(최대 체류 시간, 야간 제한)과 “결제 후 어떻게 되는가?” 섹션
• 체크아웃: 저장된 결제수단, 프로모 코드(해당 시), 명확한 확인 상태

접근성 및 오류 상태는 선택 사항이 아닙니다

주차는 현실 세계 작업이므로 UI는 한눈에 읽혀야 합니다. 기본을 충족하세요:

• 읽기 쉬운 대비 및 가독성 높은 글꼴 크기
• 큰 탭 대상(특히 핀과 주요 액션)
• 명확한 오류 상태(결제 실패, 스팟 불가, 약한 신호)와 다음 단계 제시(단순 경고에 그치지 않음)

투명한 가격으로 신뢰 구축

신뢰 신호는 흐름에 자연스럽게 포함되어야 합니다. 수수료를 미리 표시하고, 환불 가능한 항목(있다면)을 설명하며, 체크아웃 중 보안 결제 표시를 보여주세요.

결제 후에는 시간, 위치, 요금 및 “주차 연장” 버튼이 포함된 간단한 영수증 뷰를 제공해 사용자가 나중에 찾느라 헤매지 않도록 하세요.

기술 스택과 고수준 아키텍처 선택

기술 스택을 선택하면 MVP를 얼마나 빨리 출시할지, 실시간 데이터를 얼마나 안정적으로 제공할지, 인앱 결제를 얼마나 안전하게 운영할지 결정됩니다.

모바일 앱: iOS, Android 또는 크로스플랫폼

• 네이티브(Swift/Kotlin): 지도 성능, 백그라운드 위치 동작, 플랫폼 고유 UX가 중요할 때 적합합니다. 코드베이스 두 개를 유지해야 하므로 비용이 더 들 수 있습니다.
• 크로스플랫폼(Flutter/React Native): UI와 비즈니스 로직을 공유해 출시 속도를 높일 수 있습니다. Apple Pay/Google Pay, 딥 링크, 고정밀 위치 같은 항목을 위해 네이티브 브리징 계획은 필요합니다.
• 일반적인 절충안: 메인 앱은 크로스플랫폼으로 개발하고 결제·위치 관련 핵심 기능은 소규모 네이티브 모듈로 처리.

초기 프로토타입을 빠르게 돌리고 싶다면 완전한 엔지니어링 파이프라인을 즉시 구축하지 않고 프로토타이핑 워크플로를 활용할 수 있습니다. 예를 들어 Koder.ai는 팀이 React 기반 웹 대시보드(운영자 콘솔)와 백엔드 서비스(Go + PostgreSQL)를 채팅으로 초안 작성하고 스냅샷/롤백으로 빠르게 반복할 수 있게 해, MVP 범위를 정하는 동안 유용합니다.

고수준 아키텍처: 핵심 서비스를 분리하세요

프로토타입에서 스마트 주차 앱으로 진화할 때 재작성 없이 확장할 수 있도록 백엔드를 모듈화하세요:

• ID 및 사용자 계정: 로그인, 차량, 저장된 결제수단
• 주차 세션 서비스: 세션 시작/종료, 연장, 영수증
• 요금 엔진: 요금표, 시간대 규칙, 상한/휴일(돈 관련 로직을 세션 코드와 분리)
• 결제 서비스: 토큰화, 환불, 차지백, PCI 준수(카드 데이터 저장 대신 Stripe/Adyen/Braintree 같은 PSP 사용)
• 알림 서비스: 만료 알림, 영수증, 예약 리마인더(푸시/SMS/이메일)

데이터 저장소: 트랜잭션과 속도 최적화

• 관계형 DB(PostgreSQL/MySQL): 세션, 결제, 감사 기록
• 캐시(Redis): 빠른 읽기(구역 가용성 스냅샷 등)로 레이턴시 감소
• 시계열/이벤트 저장소: 센서 피드와 업데이트 수집(나중에 단속 통합이나 분석 추가 시 유용)

호스팅, 환경, 신뢰성

별도의 dev/stage/prod 환경과 자동 배포를 운영하세요.

시크릿 매니저를 사용하고(레포의 환경 파일 사용 금지), 정기 백업과 명확한 롤백 절차를 마련하세요. 실시간 주차 데이터의 경우 모니터링, 요청 제한, 점진적 저하(예: “가용성 X분 전 업데이트”)를 우선시하세요—'항상 라이브'라는 취약한 가정에 의존하지 마세요.

데이터 모델링: 스팟, 구역, 요금, 세션

주차 가용성 앱은 데이터 모델이 생명입니다. 관계를 초기에 잘 설계하면 검색, 길안내, 예약, 결제 흐름에서 실시간 데이터 일관성을 유지할 수 있습니다.

핵심 엔티티(및 관계)

나중에 확장 가능한 소규모 테이블/컬렉션으로 시작하세요:

• User → 하나 이상 Vehicle 보유
• PaymentMethodToken → 사용자별로 저장(결제 제공자에 의해 토큰화)
• Location/Zone → 논리적 영역(주차장 층, 도로 구간, 캠퍼스 부지)
• Spot/Facility → 계측된 개별 스팟 또는 용량을 가진 시설
• Rate → 구역/시설에 연결된 요금 규칙(시간창, 최대 체류시간)
• Session → 활성 유료 주차 기간(시작/종료, 상태)
• Reservation(선택적) → 세션 시작 전 재고 확보
• Receipt → 불변의 결제 증빙(항목별 내역, 세금/수수료, 제공자 ID)

Rates는 Sessions와 독립적으로 유지하세요. 세션은 결제 시 사용된 “요금 스냅샷”을 캡처해야 이후 요금 수정이 기록을 덮어쓰지 않습니다.

거짓말하지 않는 가용성 표현

스팟 및 구역 수준에서 가용성을 모델링하세요:

• current_occupancy 또는 available_count 같은 필드로 빠른 UI 제공
• ETA 기반 검색용 predicted_availability(선택 사항)
• 각 가용성 레코드에 last_update_at을 두어 앱에서 “2분 전 업데이트”처럼 표시하고 센서가 조용할 때 점진적 저하가 가능하게 함

멱등성 + 감사 추적(필수)

결제 및 세션 시작에는 idempotency_key(사용자 액션별)를 사용해 재시도나 불안정한 네트워크 상황에서 이중 청구를 방지하세요.

금융 또는 운영 관련 변경에 대해 감사 필드/이벤트를 추가하세요:

• 누가 언제 요금을 변경했는지, 무엇이 변경되었는지
• 환불, 세션 수정, 단속 관련 오버라이드

이 구조는 오늘의 스마트 주차 앱을 지원하고 향후 마이그레이션의 고통을 줄입니다.

안전한 결제 및 영수증 구축

결제는 주차 결제 앱이 신뢰를 얻거나 잃는 지점입니다. 목표는 체크아웃을 빠르고 예측 가능하며 안전하게 만드는 것이며, MVP 범위를 현실적으로 유지하는 것입니다.

사용자가 기대하는 결제 옵션

대부분의 운전자를 커버하는 기본 옵션부터 시작하세요:

• 카드(신용/체크카드)
• Apple Pay / Google Pay 같은 원터치 결제
• 재방문 사용자를 위한 저장된 결제 토큰(다시 입력할 필요 없음)

디지털 지갑은 특히 지하 주차장 등 연결이 불안할 수 있는 환경에서 전환율을 높입니다.

PCI 접근법: 다루는 범위를 최소화

PCI 준수를 위해 생 카드 정보를 직접 다루지 마세요. 결제 제공자(예: Stripe, Adyen, Braintree)를 사용하고 토큰화를 활용하세요.

실무적으로는:

• 앱은 제공업체의 SDK/UI 컴포넌트로 결제 세부 정보를 수집
• 제공업체가 토큰(또는 결제수단 ID)을 반환
• 백엔드는 그 토큰으로 결제 수행
• 원시 카드 데이터는 저장하지 않고, 고객 지원과 영수증에 필요한 메타데이터와 토큰만 저장

이 방식은 리스크를 줄이고 준수 작업을 가속화합니다.

주차에 맞춘 주요 결제 흐름

주차는 일반적인 ‘한 번 구매’ 체크아웃과 다릅니다. 다음 흐름을 초기에 설계하세요:

• 사전 승인(Pre-auth) vs. 캡처: 예상 최대 금액을 사전 승인하고 세션 종료 시 최종 금액을 캡처
• 사용량 기반 과금: 장기 체류 시(예: 매 30–60분) 주기적으로 과금
• 연장: 사용자가 새 세션을 만들지 않고 시간을 추가할 수 있도록 허용
• 초과 체류 처리: 사용자가 유료 시간을 초과하면 자동 연장(허용 시)하거나 수수료 부과 및 명확한 알림 전송

영수증, 환불, 분쟁

영수증은 자동으로 제공되어야 하며 쉽게 조회할 수 있어야 합니다. 제공 내용:

• 앱 내 영수증 기록 및 이메일 영수증
• 항목별 상세(위치, 시간, 요금, 세금/수수료, 승인 예비금 vs 최종 청구)
• 환불 도구: 무효 처리(동일일), 부분 환불, 간단한 분쟁 워크플로우

나중에 단속 통합을 계획한다면, 지원팀이 결제 기록과 실시간 가용성·단속 기록을 대조할 수 있도록 영수증과 세션 ID를 일관되게 유지하세요.

요금 규칙 및 예외 처리

요금은 주차 가용성 앱이 사용자 신뢰를 잃는 가장 흔한 지점입니다. 총액이 체크아웃에서 변경되거나—더 나쁘게는—세션 시작 후 변경되면 사용자는 속았다고 느낍니다. 요금을 1급 제품 기능으로 취급하고 사후 약식 처리를 피하세요.

모든 요금 입력 항목(및 제어자)을 정의하세요

앱을 구축하기 전에 가격을 결정하는 정확한 입력값을 문서화하세요:

• 구역/부지(운영자별로 규칙 상이)
• 시간대/요일 유형(주중 vs 이벤트 밤)
• 체류시간(시간별, 일별, 단위 청구·반올림 규칙)
• 수요 규칙(동적 요금 트리거가 있는 경우)
• 상한 및 최대 체류 시간(예: “하루 최대 $18” 또는 “2시간 제한”)

어떤 값이 시스템에서 오는지, 운영자에서 오는지, 도시 피드에서 오는지 명확히 하세요. 이 명확성은 나중에 분쟁을 예방합니다.

결제 전에 수수료를 명확히 보여주기

예약 또는 “주차 시작” 흐름에서 간단한 내역을 표시하세요:

• 기본 요금
• 세금(적용 시)
• 서비스 수수료
• 운영자 수수료(있다면)

“지금 $X가 청구됩니다” 또는 “1시간 30분 예상 합계: $X”처럼 평문을 사용하고 사용자가 기간을 조정하면 즉시 업데이트하세요.

까다로운 상황 처리

예측 가능한 예외에 대해 미리 결정하세요:

• 세션 중 요금 변경: 시작 시 요금을 고정할지, 컷오프 이후 새 요금을 적용할지, 항상 현재 요금을 적용할지 결정하고 영수증에 명시
• 유예 기간: 입/출 버퍼에 대해 무료인지, 할인인지, 단속 방지인지 명확히
• 단속 규칙: 단속 통합 시 ‘유료 만료 시간’, 번호판/스팟 식별자, 상태 전파 속도를 맞추기

요금은 재무처럼 테스트하세요(실제로 그렇습니다)

실제 시나리오와 경계 시간을 포함한 단위 테스트를 추가하세요(11:59→12:00, 서머타임 변경, 구역 전환). 주차 앱 MVP에 작은 요금 테스트 스위트만 있더라도 확장 시 발생할 지원 비용을 크게 줄일 수 있습니다. 참조 체크리스트는 /blog/pricing-test-cases에 링크하세요.