NestPay 선불 카드형 지갑 · 자동화 테스트 + 거래 E2E 실증 결과 · 실제 실행/DB 기준
NestPay 선불 카드형 지갑 · 운영 환경 실사용 검증 결과
문서 성격 본 결과서는 사람이 실제로 사용하며 확인한 결과를 담습니다. 검증은 개발용 대역(스텁)이 아니라 운영 환경에서 수행했으며, 본인인증·계좌 실명조회·1원 인증·송금은 실제 외부 기관과 통신한 결과입니다. 수치는 추정이 아니라 화면·응답·DB 로 확인한 값입니다.
검증 일시: [실측일] · 대상: 운영 배포본 · 백엔드 paynest-v1/apps/api(Spring Boot 3 · MyBatis · Flyway V91) · 앱 paynest-app(Flutter 3.44.8) · 관리자 apps/admin(Vanilla JS)
검증은 운영 환경에서 수행했습니다. 로컬 개발 환경은 외부 기관 연동이 개발용 대역(스텁)으로 동작해 본인인증·실명조회·1원 인증을 실증할 수 없기 때문입니다.
| 구성 | 주소 | 역할 |
|---|---|---|
| 앱 API | npwp-api.nestpay.co.kr | 회원앱·매장앱이 접속 |
| 관리자 | npwp-admin.nestpay.co.kr | 운영 화면 + 관리자 API |
| PG 연동 | npwp-pg.nestpay.co.kr | 외부 매장 시스템 전용 |
| 테스트 API | npwp-tapi.nestpay.co.kr | 배포 전 확인용 |
서버는 L4 뒤 2대 동일 구성이며 DB 를 공유합니다. 파일은 오브젝트 스토리지에 두고, 주기 작업(워커)은 한 실행을 한 서버만 소유하도록 원자적 클레임으로 중복을 막습니다.
| 항목 | 값 | 비고 |
|---|---|---|
| 표 | 72 | Flyway V91 까지 적용 |
| 트리거 | 15 | 거래·원장 삭제 금지 등 장부 보호 |
| 월 단위 분할 표 | 8 | 거래·원장 등 증가량이 큰 표 |
| 시스템 지갑 | 7 | 대외청산 · 미매칭 · 수수료수익 · 소멸 · 몰수 · 압류 · 압류소각 |
| 호출 빈도 제한 규칙 | 21 | 활성 기준 |
발주사(네스트페이) 오픈API 연동 열쇠가 운영에 등록되어 있으며, 저장 시 ENC1. 표식과 함께 암호화되어 보관됩니다. 열쇠가 등록되면 서버는 개발용 대역이 아니라 실제 연동으로 동작합니다.
운영 기동 시 안전장치(StubGuard)가 계좌 확인·본인인증이 대역 상태이면 서버 기동 자체를 막습니다. 즉 운영이 가동 중이라는 사실이 곧 실연동이라는 근거입니다.
가입부터 탈퇴까지 실제 기기에서 사람이 직접 조작하여 전 과정을 확인했습니다. 각 과정은 화면 녹화로 기록했습니다.
| # | 과정 | 확인 내용 | 판정 |
|---|---|---|---|
| 1 | 본인인증 | 이름·생년월일·휴대폰·통신사 입력 후 실제 SMS 인증번호 수신·확인 | 정상 |
| 2 | 아이디 생성 | 로그인 아이디·비밀번호 설정, 필수 약관 동의 | 정상 |
| 3 | 계좌 등록 | 예금주 실명조회 후 실제 1원 입금, 입금자명 3자리 코드 확인 | 정상 |
| 4 | 거래 비밀번호 | 6자리 PIN 등록 (확인 재입력 포함) | 정상 |
| 5 | 카드 발급 | 앱에서 즉시 발급, 디자인 선택 | 정상 |
| 6 | 충전 | 금액 입력 → 입금 계좌·입금자명 안내 → 실제 이체 후 잔액 반영 | 정상 |
| 7 | QR 결제 | 매장 QR 스캔 → PIN 인증 → 결제 완료, 잔액 즉시 차감 | 정상 |
| 8 | 선물 | 상대 지정 후 PIN 인증, 보낸 만큼 차감·받은 쪽 적립 | 정상 |
| 9 | 출금 | 등록 계좌로 신청, 선차감 후 접수 | 정상 |
| 10 | 내역 조회 | 거래 내역·월 이용명세서 | 정상 |
| 11 | 1:1 문의 | 제목·내용 등록 | 정상 |
| 12 | 회원 탈퇴 | 잔액 소멸 안내 확인 후 신청 | 정상 |
녹화 4분 57초 · 실제 iPhone · 앱 버전 1.0.4
| # | 과정 | 확인 내용 | 판정 |
|---|---|---|---|
| 1 | 대표자 본인인증 | 실제 SMS 인증번호 수신·확인. 한 대표자가 여러 매장을 낼 수 있어야 하므로 중복 허용 | 정상 |
| 2 | 사업자 정보 | 사업자등록번호·상호·개인/법인 구분, 유형별 필요 서류 안내 | 정상 |
| 3 | 계정 생성 | 로그인 아이디·비밀번호, 약관 동의 | 정상 |
| 4 | 로그인·홈 | 오늘 매출·결제 건수·정산 예정 잔액 | 정상 |
| 5 | 결제 수신 | 손님 결제가 최근 결제 목록에 즉시 표시 | 정상 |
| 6 | 정산 계좌 등록 | 예금주 실명조회 + 실제 1원 인증(입금자명 3자리 코드) | 정상 |
| 7 | 정산 신청 | 등록 계좌로 지급 신청, 지급 예정 표시 | 정상 |
| 8 | 계약 해지 | 잔여 정산금 안내 후 신청 (관리자 승인 시 확정) | 정상 |
녹화 2분 41초 · 실제 iPhone · 앱 버전 1.0.4
운영 환경에서 실제 거래를 발생시키고, 그 결과를 transactions·ledger_entries 실데이터로 확인했습니다. 기대는 요구사항과 코드 로직이며 결과는 실측값입니다.
작성 예정 아래 표는 운영 실거래 수행 후 실측값으로 채웁니다.
| # | 시나리오 | 기대 동작 | 실측 결과 | 판정 |
|---|---|---|---|---|
| E1 | 결제 승인 | 회원 잔액 선차감, 매장에 순액 적립, 수수료는 수수료수익 지갑으로 분리. 거래 시점 수수료 정책을 스냅샷으로 보존 | [실측] | [ ] |
| E2 | 결제 취소 | 전액 역분개. 매장에서 순액 회수, 수수료 반환, 회원에게 전액 복원. 사용한 로트의 유형·만료일 승계 | [실측] | [ ] |
| E3 | 선물 | 유상 포인트만 이동. 받은 쪽도 유상 로트로 적립 | [실측] | [ ] |
| E4 | 출금 | 신청 즉시 선차감(HOLD) → 발주사 송금 제출(PENDING) → 결과 통지로 확정(CONFIRMED) 또는 복원(FAILED) | [실측] | [ ] |
| E5 | 정산 | 매장 정산 잔액에서 신청. 등록된 정산 계좌로 지급 | [실측] | [ ] |
| E6 | 멱등 (중복 방지) | 같은 요청을 두 번 보내면 두 번째는 거부. 돈이 두 번 움직이지 않음 | [실측] | [ ] |
수수료 정책(검증 시점): MERCHANT_PAYMENT 3.0% · 고정액 0원 · 전 매장 공통. 회원 출금·선물·충전은 수수료 정책이 없어 0원입니다.
아래 항목은 로컬 개발 환경에서는 대역(스텁)으로만 동작하므로, 운영 환경에서만 실증이 가능합니다. 모두 실제 통신 결과입니다.
| 연동 | 확인 방법 | 판정 |
|---|---|---|
| 휴대폰 본인인증 | 실제 SMS 인증번호 수신 후 확인. 회원가입·매장 대표자 인증 양쪽에서 확인 | 정상 |
| 계좌 실명조회 | 예금주명이 본인·상호와 일치하는지 확인 | 정상 |
| 1원 인증 | 실제 1원 입금 후 입금자명에 담긴 3자리 코드 확인 | 정상 |
| 송금이체 (출금·정산) | [실측 예정] 신청 → 제출 → 결과 통지 확정 | [ ] |
| 입금 확인 (충전) | [실측 예정] 입금요청 등록 → 실제 이체 → 조회로 확정 후 적립 | [ ] |
| 현금영수증 | [실측 예정] 발행 및 취소 | [ ] |
입출금 확정 원칙 — 통지(웹훅)만으로 적립·확정하지 않고 반드시 발주사 조회로 최종 판정합니다. 통지는 신호일 뿐이며, 통지가 오지 않아도 주기 조회가 결과를 확인합니다. 응답을 받지 못한 경우에는 자동 재요청하지 않고 조회로 확인합니다(이중 송금 방지).
| 항목 | 확인 내용 | 판정 |
|---|---|---|
| 거래 인증 | 결제·선물·출금 전 6자리 PIN 또는 생체(패스키) 인증. 5회 실패 시 30분 잠금 | 확인 |
| 중복 처리 방지 | 모든 거래에 멱등키(결제·출금·선물·충전·정산 복원 등 6종)와 유니크 인덱스. 재요청은 거부 | 확인 |
| 장부 보호 | 거래·원장은 추가만 가능. 삭제·수정을 DB 트리거가 차단(트리거 15개) | 확인 |
| 호출 빈도 제한 | 로그인·결제·출금·정산·가입 등 21개 규칙 활성. 사용자 기준과 IP 기준을 분리 | 확인 |
| SQL 인젝션 | 모든 조회가 파라미터 바인딩. 문자열 치환 사용 0건 | 확인 |
| 개인정보 보호 | 카드번호·계좌번호 등은 암호화 저장, 화면에는 가려서 표시. 열람 시 접근 기록 | 확인 |
| 접속 기록 | 회원·매장·관리자 로그인 성공·실패·차단을 모두 기록(전자금융거래법 접속기록) | 확인 |
| 관리자 접근 | IP 허용 목록 + OTP 2단계 인증. 모든 조치를 감사 기록에 보존 | 확인 |
| 발주사 통신 | 요청·응답에 서명(HMAC) 적용, 원문은 암호화해 보관 | 확인 |
모든 거래는 복식부기로 기록되며, 차변 합계와 대변 합계가 항상 같아야 합니다. 이를 사람이 매번 확인하는 대신 서버가 1시간마다 자동으로 대조하고, 결과를 관리자 화면(금액 무결성)에서 볼 수 있습니다.
검사 항목: 차변·대변 합계 일치 · 지갑 잔액과 원장 누적치 일치 · 고아 원장 · 시스템 지갑 합계 · 정체된 거래 · 발송 대기 적체.
| 항목 | 결과 |
|---|---|
| 자동 검사 수행 횟수 | [실측] |
| 이상 발견 | [실측] |
| 차변 합계 = 대변 합계 | [실측] |
| 지갑 잔액 = 원장 누적치 | [실측] |
| 구분 | 현재 한계 | 후속 과제 |
|---|---|---|
| 성능·동시성 | 부하 및 동시 접속 성능 수치를 측정하지 않았습니다. | 요구사항정의서에 확정한 목표치를 기준으로 부하·동시성 시험 수행 |
| 미매칭 입금 반환 | 입금자를 특정할 수 없는 입금을 돌려주는 처리는 장부 기록까지만 되어 있고, 실제 이체가 연결되어 있지 않습니다. | 지급 수단 연결 및 반환 계좌 조회 화면 추가 |
| QR 열쇠 교체 | 매장 QR 은 하나의 열쇠로 잠급니다. 열쇠를 교체하면 이미 인쇄·부착된 QR 이 인식되지 않습니다. | 열쇠 세대 관리 도입 여부 검토 |
| 앱 배포 | [실측 예정] 스토어 심사 상태 | 승인 후 최소 지원 버전 상향 |
NestPay 산출물 · (주)페이네스트 · 작성일 [작성일] · 운영 환경 실사용 기준 · 본인인증·계좌인증·송금은 실제 외부 기관 통신 결과임