---
title: "정식 배포까지 남은 작업 현황 보고서 (2026-06-12)"
category: "report"
document_type: "현황보고"
source_status: "generated"
knowledge_group: "00_current_state"
priority: "High"
purpose: "베타 배포·정식 배포·서비스 관리 준비까지 남은 작업을 3개 섹션으로 정리한 현황 보고서. 비개발자(사장님)가 즉시 이해할 수 있도록 평이한 한국어로 작성. 기준 로드맵: 97_260610 로드맵 문서."
read_when: ["베타배포","정식배포","잔여작업","현황","서비스관리","남은일","로드맵","할일"]
updated: "2026-06-12"
work_timestamp: "20260612_160000"
source_of_truth: "https://dallog-tools.hansbridge.co.kr/knowledge/"
---

# 정식 배포까지 남은 작업 현황 보고서

> 기준일 2026-06-12 | 달록 로드맵 가→나→다→라 기준

---

## 요약표

| 섹션 | 항목 수 | 주 담당 | 현재 상태 |
|---|:---:|---|---|
| **1. 베타 배포** | 7 | CC(코드·기획 4) + 사장님(인프라 3) | 코드 마무리 단계, 인프라 게이트 대기 |
| **2. 정식 배포** | 6 | CC + 사장님 | 베타 완료 후 착수 |
| **3. 서비스 관리 준비** | 4 | 공동 | 정식 출시 시점 전환 |

> **지금 어디쯤인가**
> 달록은 베타 배포 직전 단계입니다. 코드 작업은 대부분 끝났고, **진짜 관문은 사장님이 직접 진행해야 하는 서버 배포와 분석 도구 실가동**입니다. 이 관문을 통과하면 소수 지인·테스터를 대상으로 클로즈 베타를 열고, 그 데이터로 정식 배포의 모든 숫자를 결정합니다.

---

## 1. 베타 배포 (지금 해야 할 일)

### A. 코드·기획 작업 — CC 담당

---

**A-1. 🔴 코치 사용량 차감 버그 수정 (긴급)**
코치에게 질문하면 답변은 잘 오지만, "오늘 몇 번 썼는지 세는 기능"이 서버 오류로 작동하지 않습니다. 지금 라이브 서비스에서 무제한 사용이 가능한 상태이며, 베타 측정과 나중 유료 과금 모두 신뢰할 수 없게 됩니다. 가장 먼저 처리해야 합니다.

---

**A-2. 동의 이력 관리 구현**
누가 언제 어느 약관에 동의했는지 기록·조회하는 기능입니다. "동의한 적 없다"는 분쟁이나 정보 삭제 요청에 대응하기 위해 반드시 필요한 기록 장치입니다.

---

**A-3. 🟡 기록 입력 시간 선택기 이중 노출 수정**
운동 기록을 입력할 때 시간을 고르는 화면에서 커스텀 선택기(오전·오후 + 시·분 입력)와 기기 기본 시간 입력이 동시에 표시됩니다. 러닝·근력 양쪽 입력 화면에 공통 컴포넌트로 들어가 있어 두 화면 모두 이중 노출됩니다. 어느 쪽을 써야 할지 모호해 입력 혼란을 유발합니다. (근거: `LogEntry.tsx:71–88` — 조건 분기 없이 두 방식이 나란히 렌더링됨)

---

**A-4. 베타 측정 항목 확정 + 기간 설계**
베타에서 "무엇을, 얼마 동안, 어떻게 측정할지"를 구체적으로 정리해야 합니다. 어드민 분석 도구가 켜지면 곧바로 이 항목들을 보는 루틴이 시작됩니다. 아래 6가지 축과 4가지 검증 가설, 그리고 기간 기준이 확정되어야 합니다.

**[측정 6축]**

| 축 | 보는 것 | 알고 싶은 것 |
|---|---|---|
| 퍼널 | 가입 → 코치 첫 진입 → 첫 대화 → 5회 이상 사용 → 소진 → 플랜 열람 | 어디서 이탈하는가 |
| 리텐션 | 가입 후 1일·3일·7일 재방문율 | 코치가 "다시 오게" 만드는가 |
| 질문 유형 | 통증·식단·수면 등 10종 질문 분포 (question_type) | 사용자가 실제로 뭘 묻는가 |
| 원가 | 코칭 1회·도구 조회 1회 실비, 1인당 월 원가 | 현재 가격으로 감당되는가 |
| 저장·기억 | 저장 동의율, 기억 켠 사람의 재방문 차이 | 기억 기능이 체감 가치인가 |
| 컴플레인 | 앱 내 신고·문의(support_ticket) 내용 | 무엇이 불편하고 깨지는가 |

**[검증할 4가지 가설]**
1. 유용한가 — 리텐션·재방문으로 판단
2. 원가가 감당되는가 — 1인당 실측 후 제공량·단가 결정
3. 기억이 가치인가 — 저장 동의율·효과 측정
4. 무엇이 깨지는가 — 컴플레인·에러 로그로 버그 우선순위 결정

**[기간 기준 — 미확정, 설계 필요]**
아직 "베타를 몇 주 돌릴 것인가"가 확정되지 않았습니다. 정식으로 넘어가는 조건은 "리텐션·원가·핵심 버그 안정화 + 제공량·단가 실측 확정 + 결제 모델 확정"이며, 기간보다는 이 조건 충족이 기준입니다. 예비 가이드라인(2~4주 주간 사이클)을 확정할 필요가 있습니다.

---

### B. 인프라·배포 — 사장님 담당

---

**B-1. DB 마이그레이션 적용**
데이터베이스(사용자 정보와 기록을 보관하는 곳)에 최신 구조 변경사항을 반영하는 작업입니다. 개발 코드가 아무리 준비돼도, 이 작업을 해야 실제 서버에 반영됩니다. (마이그레이션 = 데이터베이스 구조를 새 버전으로 업그레이드하는 절차)

---

**B-2. 워커 재배포 (코치 서버·운영 분석 서버)**
코치 AI 처리 서버(chat-proxy)와 운영 분석 서버(admin-analytics) 두 개를 최신 버전으로 다시 올리는 작업입니다. 코드는 준비됐고, Cloudflare(서버 호스팅 서비스) 대시보드에서 사장님이 직접 배포해야 합니다. (워커 = Cloudflare에서 실행되는 서버 프로그램)

---

**B-3. 어드민 애널리틱스 실가동 — 베타의 핵심 관문**
운영자 분석 화면(누가 얼마나 쓰는지, 비용이 얼마인지 한눈에 보는 곳)을 실제로 작동시키는 작업입니다. 서버에 비밀 설정값(service_role 시크릿·환경변수)을 등록해야 합니다. **이게 안 되면 베타를 열어도 아무것도 측정할 수 없어 베타의 의미가 없어집니다.** (환경변수 = 서버가 읽어야 할 비밀번호·설정 값)

---

## 2. 정식 배포 (베타 이후 준비)

> 베타 실측 데이터가 나오면 착수합니다. 사전 정의된 체크리스트를 순서대로 진행합니다.

---

**2-1. 수익모델 최종 확정**
베타에서 1인당 실제 비용이 얼마나 나왔는지 재고 나서, 유료 플랜 가격과 하루 제공량을 최종 숫자로 굳힙니다. "감"이 아닌 실제 측정값으로 결정합니다. 충전식 가격 정책 설계서는 이미 완성돼 있습니다.

---

**2-2. 결제 PG 실연동 (포트원·토스페이먼츠)**
실제 카드 결제·환불·충전금 지급이 가능하도록 결제 대행사를 연결하는 작업입니다. 충전식 결제 내부 흐름은 이미 모두 준비됐고, PG 실계약·최종 연결만 남아 있습니다. (PG = 결제 대행사, 카드사와 서비스 사이에서 결제를 처리해 주는 회사)

---

**2-3. 약관·동의 시스템 최종 점검**
이용약관·개인정보처리방침·건강정보 동의서를 법령 기준(개인정보보호위 표준 가이드)에 맞게 최종 점검합니다. 변호사 없이 표준 가이드 기반으로 진행합니다. 정식 법무 자문은 수익화 이후로 미룹니다.

---

**2-4. 테스트↔정식 환경 분리**
버그를 고칠 때 테스트 서버에서 먼저 확인하고, 이상이 없으면 실서비스에 적용하는 이중 구조를 인프라로 구축합니다. 지금은 수정하면 바로 실서비스에 반영됩니다. (CF Pages 환경 분리 = Cloudflare에 개발·운영 서버를 따로 운영하는 구조)

---

**2-5. 스토어 정식 등록**
안드로이드 앱을 구글 플레이스토어에 정식으로 제출·심사하고, 카카오 소셜 로그인 화면에 "달록" 이름이 제대로 뜨도록 카카오 비즈앱 검수를 완료합니다. (Capacitor = 웹 코드를 스마트폰 앱으로 변환하는 도구)

---

**2-6. 보안·부하 점검**
사용자가 늘어날 때 서버가 버티는지, 개인 데이터가 외부로 새나가지 않는지 점검합니다. 저장·기억 기능이 추가되면서 다루는 데이터가 늘었으므로, 데이터 접근 권한(RLS) 전수 재확인이 필요합니다. (RLS = 사용자가 자기 데이터만 볼 수 있게 막는 데이터베이스 보안 설정)

---

## 3. 서비스 관리 준비 (정식 출시 이후)

> 정식 배포와 동시에 "개발 프로젝트"에서 "운영 서비스"로 성격이 전환됩니다.

---

**3-1. 어드민 애널리틱스 상시 모니터링 일상화**
사용자 수·코칭 비용·이탈률 등 핵심 지표를 매일·매주 보는 운영 루틴을 정착시킵니다. 분석 도구는 이미 만들어져 있습니다. 지표를 보고 "지금 서비스가 괜찮은가"를 판단하는 것이 운영의 시작입니다.

---

**3-2. 고객 문의·컴플레인 처리 체계 정착**
사용자가 앱 내 "문의·신고" 화면에서 접수한 내용을 확인 → 원인 분석 → 수정 → 결과 안내로 이어지는 처리 흐름을 일상 업무로 만드는 것입니다. 앱 내 신고 기능(support_ticket)은 이미 작동합니다.

---

**3-3. 패치 파이프라인 안정화 (수정 이중 확인 구조)**
버그 수정·기능 개선 시 테스트 서버에서 검증 후 실서비스에 반영하는 사이클이 안정적으로 돌도록 합니다. "테스트→정식" 패치 경로가 굳어야 이후 개선이 위험 없이 진행됩니다.

---

**3-4. 팩토핀 재착수 해금 — 달록 운영 자동화 목표선**
달록이 "사람 손 없이 스스로 돌아가는 서비스 상태"가 되면, 너무 오래 멈춰 있던 팩토핀 프로젝트를 다시 시작할 수 있습니다. 달록 운영 자동화(모니터링·패치·컴플레인 처리 사이클)를 완성하는 것 자체가 팩토핀 복귀의 조건입니다.

---

## 현 위치 한 줄

코드는 베타 직전까지 왔다. **지금 관문은 사장님 인프라 배포(B-1~B-3)다.** 그게 열리면 클로즈 베타 → 실측 → 정식의 문이 열린다.