ZERRO APP Production 승인 보드

아래 항목은 제품 정책 승인, 운영 반영 승인, 외부 검증을 구분한 현재 상태입니다. 2026-07-16에 여섯 개 정책 결정은 승인되었고, credential·실제 전송·실측 evidence가 필요한 항목은 계속 별도 gate로 남겨두었습니다.

기준: origin/develop@d984098e범위: Android APP production readiness문서 확인: 2026-07-16
6명시적 결정 승인
2운영 반영 승인
2외부 검증 필요
3이미 확정된 정책 묶음

이 보드를 보는 순서

결정하지 않아도 되는 항목을 승인 요청으로 오해하지 않도록 세 종류로 나눴습니다.

  1. 승인됨은 제품 정책이 정본에 기록된 상태입니다. 실제 backend/provider/store evidence는 별도로 남을 수 있습니다.
  2. 운영 반영 승인은 기술 정책이 이미 정해진 항목입니다. credential·운영자·서식·compliance 책임만 열어주면 됩니다.
  3. 외부 검증 필요는 승인 문구보다 표본·테스트 계정·환경 권한이 필요한 항목입니다.

지금 승인할 결정

제품 정책의 승인 여부와 구현·검증 gate를 분리해 표시합니다. 승인됨은 정책이 닫혔다는 뜻이며, 실제 운영 evidence까지 완료했다는 뜻은 아닙니다.

6건
승인됨P0
DG-AUTH-01

계정·회사·역할 정책

가입, 초대, 승인, 역할별 접근을 확정해야 실제 운영 계정과 권한 검증을 시작할 수 있습니다.

현재 상태
v1 one-company, 최초 구성원 company admin 승인, driver 초대, backend-owned duties 방향은 승인됐습니다. 가입·초대·복구 surface와 세부 권한 evidence가 남아 있습니다.
결정 제안
v1에서는 한 계정이 한 회사에만 속하도록 합니다. 최초 구성원은 운영 승인 후 company admin이 되고, driver는 dispatcher 또는 company admin의 초대로 가입합니다. 역할과 세부 duties는 backend claim이 소유합니다.
대표님께 확인할 한 문장
이 회사 가입·초대·승인 정책을 v1 기준으로 확정할까요?
승인·검증 후 가능한 일
가입/초대 화면, 승인 대기·거절·퇴사 상태, role/action guard, session 복구 계약을 구현할 수 있습니다.
아직 막히는 범위
APP 가입·초대·복구 및 duty 기반 권한 검증
이번 결정에서 제외
v1 multi-company 전환, self-service driver signup, 임의 role escalation
승인됨P0
DG-PUSH-01

푸시 알림의 개인정보와 전달 정책

잠금 화면에 어떤 정보를 보여줄지, 누구에게 어떤 lifecycle 알림을 보낼지 확정해야 push backend와 tap 복원을 안전하게 구현할 수 있습니다.

현재 상태
Expo Push client와 token contract skeleton이 있고, #1023에서 local/dev device token 등록·폐기·upsert 저장과 notification:register RBAC를 구현·검증했습니다. delivery·receipt/retry·tap 복원과 production credential이 남아 있습니다.
결정 제안
Expo Push를 1차 provider로 사용합니다. 잠금 화면에는 업체명·폐기물·전화번호·인계번호·주소 원문을 넣지 않고 일반 문구만 표시합니다. 자기 자신이 만든 이벤트는 기본적으로 생략하고, tap은 session 복구 → role 확인 → 상세 이동, 실패 시 해당 역할의 알림함으로 보냅니다. driver는 chat으로 deep link하지 않습니다.
대표님께 확인할 한 문장
이 개인정보 최소화·알림 수신·tap fallback 정책으로 확정할까요?
승인·검증 후 가능한 일
device token 등록/폐기, 알림 event matrix, 알림함 fallback, Android permission UX를 구현할 수 있습니다.
아직 막히는 범위
push backend delivery, receipt/retry 운영정책, tap role/session restore
이번 결정에서 제외
direct FCM/APNs 1차 도입, 잠금 화면 상세 개인정보 노출, driver chat deep link
승인됨P1
DG-REALTIME-01

실시간 연결의 첫 운영 규모

foreground STOMP를 어떤 backend topology에서 운영할지 결정해야 reconnect, replay, 장애 대응의 범위를 고정할 수 있습니다.

현재 상태
APP에는 STOMP 주입과 REST reconciliation이 있고, backend는 single-instance Spring simple broker 기준입니다.
결정 제안
초기 제한 운영은 backend single replica를 배포 정책으로 강제하고, 메시지의 정본은 DB/REST로 둡니다. 2 replica 이상 또는 무중단 요구가 생길 때 external broker와 durable replay로 승격합니다.
대표님께 확인할 한 문장
초기 운영을 single replica + DB/REST 정본으로 제한하는 데 동의할까요?
승인·검증 후 가능한 일
현재 foreground realtime과 reconnect/REST 재조회 범위를 닫고, 초기 운영의 비용과 장애 범위를 통제할 수 있습니다.
아직 막히는 범위
production broker topology, replay/idempotency, latency/SLA 기준
이번 결정에서 제외
초기부터 Kafka/Redis external broker 도입, background realtime, 무제한 수평 확장
승인됨P1
DG-HANDOFF-01

전화·네이버지도·고객센터 연결 방식

외부 앱으로 넘길 연락처·주소·좌표·고객센터 URL의 소유 API와 감사 기록을 확정해야 외부 handoff를 운영 기능으로 연결할 수 있습니다.

현재 상태
네이버지도 방향과 URL allowlist, typed resolver 경계는 승인됐습니다. runtime value source와 opener/audit evidence는 아직 없습니다.
결정 제안
backend detail/config가 typed runtime value를 제공하고 APP은 단일 adapter로만 엽니다. 네이버지도 실행 실패 시 주소/연락처 복사 또는 고객센터 화면으로 fallback합니다. audit에는 actor·role·handover·action·result만 남기고 전화번호·주소·URL 원문은 기록하지 않습니다.
대표님께 확인할 한 문장
이 runtime source·fallback·redaction 정책으로 외부 handoff를 확정할까요?
승인·검증 후 가능한 일
전화, 네이버지도, 고객센터 CTA를 실제 값과 안전한 실패 상태까지 연결할 수 있습니다.
아직 막히는 범위
연락처·좌표·주소·고객센터 URL의 backend 소유 API와 audit event
이번 결정에서 제외
native 지도 SDK 도입, 임의 URL 실행, raw PII/URL 로그 저장
승인됨P0
DG-RELEASE-01

Android RC와 스토어 운영 책임

실제 배포를 시작하기 전에 Play Console, signing, rollback, version 승인 책임을 명확히 해야 합니다.

현재 상태
Android EAS project/profile과 preflight는 준비됐지만 첫 RC, Play internal track, signing/rollback/OTA 운영은 아직 열리지 않았습니다.
결정 제안
Android Internal Track을 첫 배포 경로로 사용하고, 초기 production은 OTA를 끕니다. immutable AAB와 Sentry release/source map을 남기고 staged rollout을 사용합니다. Play Console·signing·privacy/support URL·rollback 책임자를 지정한 뒤 별도 승인 PR에서 store write를 수행합니다.
대표님께 확인할 한 문장
이 Android Internal Track → staged rollout, 초기 OTA off 정책과 책임자 지정으로 진행할까요?
승인·검증 후 가능한 일
RC APK/AAB, 내부 QA, crash 관측, rollback runbook과 store 제출 순서를 고정할 수 있습니다.
아직 막히는 범위
Play Console owner, signing owner, privacy/support URL, version approver, rollback owner
이번 결정에서 제외
iOS build/store, OTA 활성화, production signing credential write
승인됨P1
DG-OFFLINE-EXIT-01

오프라인 대기 작업의 로그아웃·계정 전환 처리

운전자가 미전송 증빙을 가진 채 로그아웃하거나 계정을 바꿀 때 데이터 손실과 권한 혼선을 막아야 합니다.

현재 상태
증빙 queue의 대상·한도·순서·재시도 기준과 로그아웃/계정 전환 시 sync and exit·keep pending·cancel 선택 정책이 승인됐습니다. 실제 UI와 queue ownership evidence가 남아 있습니다.
결정 제안
미전송 작업이 있으면 로그아웃/계정 전환을 바로 완료하지 않습니다. 사용자에게 ‘동기화 후 나가기’, ‘대기 작업 보관’, ‘취소’를 명시적으로 보여주고, silent discard는 허용하지 않습니다.
대표님께 확인할 한 문장
이 세 가지 명시 선택과 silent discard 금지 정책으로 확정할까요?
승인·검증 후 가능한 일
process-death 복구, 계정 전환, queue 권한 경계를 실제 화면과 E2E로 고정할 수 있습니다.
아직 막히는 범위
logout/account switch UI, queue ownership transfer, support recovery policy
이번 결정에서 제외
백그라운드 무제한 업로드, 계정 간 queue 공유, silent discard

정책은 확정, 운영 반영 승인이 필요한 항목

기술 정책은 이미 정해졌습니다. 실제 credential, 운영자, 서식 또는 compliance wiring을 열기 위한 승인입니다.

2건
운영 승인 필요P0
DG-FILE-PROD-01

Private storage production write

파일 정책과 backend enforcement는 정해졌지만 실제 production bucket과 credential을 열어야 media/document를 운영할 수 있습니다.

현재 상태
local/Testcontainers와 S3-compatible adapter, signed read/RBAC, retention/legal hold enforcement는 준비됐습니다. production bucket/credential write는 실행하지 않았습니다.
결정 제안
private bucket, public access block, staging lifecycle, malware scan, 회사 종료 30일 export를 운영 체크리스트로 승인한 뒤 ZERRO 전용 credential로 smoke를 수행합니다. 자격 증명과 object key는 로그·PR·evidence에 남기지 않습니다.
대표님께 확인할 한 문장
이 운영 체크리스트와 별도 ZERRO bucket/credential 발급을 승인할까요?
승인·검증 후 가능한 일
채팅 첨부·운전자 증빙·문서의 production signed upload/read 검증을 시작할 수 있습니다.
아직 막히는 범위
bucket owner, credential owner, public access block, lifecycle/malware/export evidence
이번 결정에서 제외
공개 bucket, 장기 credential 공유, production secret을 코드/PR에 기록
운영 승인 필요P1
DG-DOC-PROD-01

반입·처리 문서의 운영 서식과 보관

PDF renderer와 immutable version 기반은 있으므로, 실제 운영 서식과 발급 시점·history 권한을 승인해야 문서를 고객에게 제공할 수 있습니다.

현재 상태
zerro-pdf-v1 renderer와 private generated object, version/hash persistence가 있습니다. 최종 한글 서식·글꼴, correction history access, after-commit 발급과 Android 저장/공유 증거가 남았습니다.
결정 제안
v1은 서명·직인 없이 운영하고, 정정은 새 version과 사유를 남깁니다. 일반 사용자는 최신본만, 참여 company_admin/ops는 history를 봅니다. 최종 한글 서식·글꼴과 운영/컴플라이언스 승인자를 확정한 뒤 Android save/share를 검증합니다.
대표님께 확인할 한 문장
이 v1 문서 서식·version/history 권한과 운영 승인 절차로 진행할까요?
승인·검증 후 가능한 일
반입확인서·처리확인서를 실제 발급하고, 저장/공유 권한과 정정 이력을 검증할 수 있습니다.
아직 막히는 범위
최종 template/font, 발급 transaction boundary, history approver, Android evidence
이번 결정에서 제외
v1 서명·직인, 무기한 덮어쓰기, 권한 없는 history 공유

승인보다 외부 표본·권한이 필요한 항목

결정안을 다시 고르는 단계가 아니라, 실제 계정·표본·환경에서 통과 여부를 확인하는 단계입니다.

2건
외부 검증 필요P1
DG-OCR-01

한글 OCR 대표 표본 검증

Google Cloud Vision 방향과 acceptance rule은 정해졌지만, 실제 문서 표본에서 정확도가 기준을 넘는지 확인해야 합니다.

현재 상태
backend OcrAcceptancePolicy가 required field·confidence·weight relation의 needs_review 경계를 고정했습니다. 현재 runtime은 deterministic fake OCR이며 production GCV adapter/credential은 없습니다.
결정 제안
추가 정책 결정보다 먼저 50장 이상, 5개 이상 양식, 양식당 10장 이상, challenging 표본 20% 이상으로 benchmark를 실행합니다. gross/tare exact 97% 이상, vehicle/time 95% 이상, required recall 95% 이상을 목표로 하고, 미달·confidence <0.90·불일치는 needs_review로 보냅니다.
대표님께 확인할 한 문장
결정할 항목은 없습니다. 표본·GCV credential·redacted 결과를 제공해 검증을 진행할까요?
승인·검증 후 가능한 일
실제 provider 도입 여부와 수동 보정 UX를 근거 기반으로 결정할 수 있습니다.
아직 막히는 범위
대표 표본, GCV credential, redacted benchmark report, driver/processor 실측
이번 결정에서 제외
문서만으로 production 정확도 선언, OCR 결과의 자동 domain mutation
외부 검증 필요P1
DG-OLBARO-01

올바로 HALF MODE 실측

protocol mapping과 local lifecycle은 있어도, 실제 테스트 계정에서 예약·확정·재시도·중복 오류를 확인해야 운영 연동을 주장할 수 있습니다.

현재 상태
Open API 분석과 local queue/worker 경계는 있으나 테스트 계정과 HALF MODE 실측 evidence가 없습니다.
결정 제안
테스트 계정에서 role별 happy/error/replay ledger를 먼저 확보합니다. HALF MODE mapping은 공단 확인 또는 실제 응답으로 검증한 뒤에만 확정하고, T200/T300/T400 재시도·중복·수동 복구 결과를 redacted evidence로 남깁니다.
대표님께 확인할 한 문장
결정할 항목은 없습니다. 테스트 계정과 HALF MODE 접근 권한을 제공해 실측을 진행할까요?
승인·검증 후 가능한 일
올바로 신고/미신고 승격 시점과 실패 복구 정책을 실제 응답에 근거해 정할 수 있습니다.
아직 막히는 범위
test account owner, credential rotation, HALF MODE access, redacted replay ledger
이번 결정에서 제외
production 제출, 실계정 credential 저장, mapping을 응답 확인 없이 단정

다시 결정하지 않아도 되는 것

아래 정책은 이미 owner decision 또는 backend enforcement까지 반영되어 있습니다.

정본 문서

Decision Register
기술 결정과 남은 gate의 정본 Mobile Release Strategy
APP production decision gate와 release 기준 Current Progress
현재 구현 상태와 다음 우선순위 Provider Adapter Contract
파일·문서·OCR·외부 provider 경계 Realtime / Push Contract
foreground realtime과 Expo Push 계약 Push Notification Matrix
Google Sheet 기반 역할별 lifecycle 알림 matrix