YuON 진행 상황 다운로드 — 5/31 → 6/21 (YUON 보드 기준)
작성: jini · 2026-06-20 · 6/21 갱신: DAV → YUON 보드 베이스로 재작성 + davinci #yuon 채널 추가 파악(6/14·16·18) 반영 + YUON-161 코덱스 진행 반영. 목적: 항승(BE 오너)이 3주치 진행을 한 번에 따라잡기. 내일 미팅 + 오늘 작업 진입용.
TL;DR
- 진행은 멈춰있지 않다 — 오히려 빠르게 돌았다. 5/31~6/15 사이 yuon-backend·yuon-app에서 M0·M1 마일스톤이 거의 닫혔다.
- 그런데 그 대부분을 수봉님이 끌었다 — 그리고 지금도 끌고 있다. 이관(6/14) 후 YUON 보드에서도 BE 핫스팟(
YUON-177멱등성 race·YUON-186time_boundary)과 디자인 강건화(YUON-178)를 계속 수봉님이 연다. "감이 안 잡힌다"의 정체는 진행 부재가 아니라 오너십과 실제 드라이버의 불일치다. - 오늘 하려던 auth는 이미 끝났다. 지난주 TODO의 "항승: auth 최대한"은 6/13 수봉님이 머지 완료. 오늘은 새로 짜는 것이 아니라 읽고 오너십을 회수하는 것이다. → auth 작업 정리 상세 (YUON-86 / PR #13)
- 진짜 BE 프론티어는 인프라 + 이벤트 스키마다. BE를 막는 건 G-시리즈(
YUON-161Postgres·YUON-162Run/GCS)와 CP-2(YUON-163이벤트 스키마, Urgent·아직 미동결). 그리고 6/16부터 진우님이 콕 집어 위임한 2건이 응답 대기 = 암묵적 방치가 이미 시작됐다. 단, 6/20 항승님이YUON-161을 코덱스로 잡으며 회수 첫 발을 뗐다.
보드 전환 — DAV는 동결, YUON이 라이브 (6/14 이관)
6/14 진우님이 마이그레이션을 끝내고 작업 보드를 davincicircle/DAV → yuon/YUON으로 이관했다. 넘버링이 전부 바뀌었다 — 클로드로 티켓을 읽을 때 어느 보드인지부터 확인해야 한다(진우님 6/14 명시).
그래서 이 문서는 두 층으로 읽는다:
- 5/31 → 6/14 실제 진행 = 이관 전 DAV 보드 기록 (보드 동결). 이관된 티켓엔 본문에
migrated from DAV-N주석이 남아 추적 가능. - 6/15 → 라이브 = YUON 보드. 새 작업·잔여·인프라는 전부 여기 쌓인다. 이 문서의 "남은 작업"·"오늘 액션"은 모두 YUON 번호.
소스 인벤토리 (이 문서가 합친 것)
| 소스 | 내용 | 신선도 |
|---|---|---|
yuon-wiki (execution/) |
기획·게이트·월별 태스크 정본 | 6/14 |
| yuon-backend git | BE 실제 머지 이력 | 6/13 |
| yuon-app git | FE(Flutter) 실제 머지 이력 | 6/14 |
| Linear YUON 보드 (live) | 라이브 티켓 — M0/M1 Done · 인프라·M2 open. DAV 보드는 6/14 이관 시 동결. | 6/21 |
| davinci #yuon 채널 (진우님 업데이트) | 6/14 이관 안내 · 6/16 GCP 셋업 + 위임 · 6/18 FE/BE 갭 PR | 6/18 |
| Google Docs ×6 | 3단계 전략 / Stage1·2 스펙 / 미팅 TODO ×2 / V2 방향성 | 5월~6월 |
| yuon_screens.html | 화면 프로토타입 (home/record 등) | 5/31 |
3주째 감 안 잡히던 핵심 이유 = 위 소스가 흩어진 데다 보드까지 갈렸기 때문. 이 문서가 한 장으로 모은다.
제품 골격 (변하지 않는 축)
YuON은 "언제 유저에게 가치를 주나"를 기준으로 3단계로 쪼갠다 — 기능이 아니라 가치 전달 단위.
- Stage 1 — Core (Week 1–3) · 온보딩·퀘스트·기록·일지. 게임 없이 습관 기록 앱으로 작동. 연기학원 클로즈드 베타. 핵심 Entity 7개 / API 7개. 검증 질문: 클릭커 없이도 매일 돌아오나?
- Stage 2 — Backbone (Week 4–10) · 자동사냥·골드·피드·보관함. 게임 루프 + 소속감 루프 완성. 검증 질문: 소속감 루프가 WAE를 올리나?
- Stage 3 — Shiny (Month 3+) · 강화·장비·시각효과·위클리보스. 에셋 의존 큼 → 2단계 검증 후.
전 단계 공통 원칙: 재화·RNG·타임스탬프는 서버 전용 write, 클라는 증거만 업로드. 조정 파라미터는 전부 game_config 테이블.
3주 전 미팅(V2 방향성 검토)의 핵심 긴장: 복잡성이 커졌는데 "혼자 하는 메리트·자율성"을 어디까지 지키나. → 원문
실제로 진행된 것 (5/31 → 6/14, 이관 전 DAV 보드 — 동결)
마일스톤 M0(데모 readiness) → M1(Stage-1 코어 정렬)이 약 2주 만에 거의 닫혔다. 아래 티켓 번호는 이관 전 DAV 번호다(보드 동결). 대부분 YUON으로 migrated from DAV-N 주석과 함께 이관됨.
백엔드 (yuon-backend)
| 영역 | 티켓 (DAV·이관 전) | 작성자 | 날짜 |
|---|---|---|---|
| 일일 체크인 / reward 적립·조회·배지 | DAV-31/38/39/40 | 항승 | 6/02~6/09 |
| notification·progress·review API | DAV-33~37 묶음 | 항승 | 6/09 |
| demo seed/reset + smoke runbook | DAV-60/61 | 항승 | 6/10 |
| mandala 모듈 신규 + seed | DAV-65/66 | 수봉 | 6/11 |
| X-User-Id 검증 통일 (보안) | DAV-85 | 수봉 | 6/11 |
| timezone + 로컬 04:00 경계 단일화 | DAV-86/96 | 수봉 | 6/11 |
| 8축 canonical 사전 (自 기준) | DAV-88 | 수봉 | 6/11 |
| CI pytest 게이트 | DAV-95 | 수봉 | 6/11 |
| judgment seam (quest_logs 판정 컬럼) | DAV-87/101 | 수봉 | 6/11~13 |
| quests↔mandala_cell FK | DAV-91 | 수봉 | 6/12 |
| notifications internal 인증 | DAV-89 | 수봉 | 6/12 |
| auth JWT (/auth/anonymous + refresh) | DAV-90 | 수봉 | 6/13 |
프론트 (yuon-app, Flutter)
스캐폴드(6/09)부터 디자인 시스템·온보딩·퀘스트·profiling·만다라 UI·weekly review·progress 허브·reward 위젯·auth 토큰 활성화(DAV-99)까지 — 6/9~6/14 사이 거의 전부 수봉님이 이식. 항승님은 reward 위젯(DAV-55), 데모 러너 안정화(DAV-74/102/98) 일부.
라이브 YUON 보드 — 6/15 이후에도 BE는 수봉님이 연다
이관(6/14) 후 YUON 보드에 새로 쌓인 BE/디자인 티켓도 작성·진행 주체가 수봉님이다. 즉 오너십 불일치는 DAV 시절의 과거 얘기가 아니라 지금도 진행형이다.
| 티켓 (YUON) | 내용 | 우선도 / 상태 | 작성·드라이버 |
|---|---|---|---|
| YUON-177 | 퀘스트 체크인 멱등성 race — 동시 더블탭 시 500 대신 409 보장 (BE 핫스팟) | High / Backlog | 수봉 |
| YUON-186 | time_boundary 채택 — naive 날짜경계 자체 재구현을 TZ-aware 유틸로 교체 (정합 부채) | Medium / Backlog | 수봉 |
| YUON-178 | 디자인 시스템 강건화 (다크 대비 P2 + 토큰화·a11y P4) | Medium / In Progress | 수봉 |
대비점: 항승님 명의로 In Progress인 건 6/20 잡은 YUON-161(Postgres) 하나. 이게 오너십 회수의 첫 실물 신호다.
신호 — 오너십 불일치 + 암묵적 방치
진행 자체는 건강하다. 문제는 항승님이 오너인 BE 레인을 수봉님이 밀고 있고, 그 위에 진우님이 콕 집어 위임한 인프라·리뷰가 응답 대기로 쌓이는 것. 코드 ground truth가 체감("나는 거의 못했다")과 어긋난 이유가 여기 있다.
- 이관 전: 6/11 이후 BE 커밋 14건 중 13건이 수봉님. "auth 최대한"은 수봉님이 6/13 완료(DAV-90/99).
- 이관 후: YUON BE 티켓(
YUON-177·186·178)도 수봉님이 연다.
davinci #yuon 채널 — 진우님이 항승님 앞으로 남긴 것 (6/14~6/18)
- 6/14 — 마이그레이션 완료, 이제 YUON Linear 보드로 작업. 넘버링 바뀜 주의.
- 6/16 — GCP 셋업 완료,
@yuon.ai계정 로그인. postgres 생성 같은 건 "BE 작업 중인 항승님이 직접 테스트하는 게 낫겠다"고 일부러 남겨둠 + "바쁘시면 제가 겟 해도 됩니다" 폴백을 이미 열어둠. 항승님은 "내일부터 틈날 때"로 답. - 6/18 — FE/BE 갭 분석 PR 올림(나혼렙→유온 변경이라 리뷰 필요). 클로드 디자인 출시도 확인 요청.
그래서 "내일부터"가 6/16부터 누적 중이고, 진우님이 콕 집어 위임한 2건(GCP 인프라 테스트 = YUON-161/162 · 6/18 PR 리뷰)이 응답 대기다. 암묵적 방치는 이미 시작됐다. 단, 6/20 YUON-161 코덱스 착수가 첫 회수 신호.
이건 추적 도구 문제가 아니라 역할 정의 문제다. 내일 미팅 전에 한 칸 정해야 한다 (아래 검증 질문).
남은 작업 (라이브 YUON 보드)
BE · 인프라 (항승 레인 — 우선)
| 티켓 | 내용 | 우선도 / 상태 | 비고 |
|---|---|---|---|
| YUON-161 | Cloud SQL Postgres(dev) + PITR (G-3) | Urgent / In Progress | 코덱스로 진행 중 (6/20 착수). BE 블로커. 항승님 직접 셋업 의도 |
| YUON-162 | Cloud Run hello-world + GCS 버킷 (G-4) | Urgent / Backlog | BE 블로커. 진우님 폴백("제가 겟") 열림 — 잡을지/넘길지 결정 대상 |
| YUON-163 | Tier-1 이벤트 스키마 동결 = CP-2 (DS-1) | Urgent / Backlog | BE emit 선행 블로커. 구 문서의 "CP-2 미확인" → 실제로 미동결 확정. DS 레인(진우) |
| YUON-170 | Secret Manager (JWT·LLM 키) (G-5) | Medium / Backlog | 161/162 뒤 인프라 |
| YUON-177 | 퀘스트 멱등성 race 409 보장 | High / Backlog | BE 핫스팟. 현재 수봉님 레인 |
| YUON-186 | time_boundary 정합 부채 교체 | Medium / Backlog | BE 정합. 수봉님 작성 |
| YUON-76 | judgment seam 위치를 정산 이후로 분리 (dd-2 §3 A안) | Low / Backlog | AI provider 붙일 때 — 의도적 후순위. 블로커 아님 (구 DAV-100) |
FE · APP (M1 잔여)
| 티켓 | 내용 | 우선도 / 상태 |
|---|---|---|
| YUON-92 | notification 풀버전 (quiet hours + push-token + Firebase 활성) | Medium / Backlog |
| YUON-120 / 121 / 122 | review 주간회고 · progress 성장/통계 · quest 푸시 설정 화면 짝 | Backlog |
M2 — Stage 2 착수 준비 (umbrella)
| 티켓 | 내용 | 우선도 / 상태 |
|---|---|---|
| YUON-84 | [M2][BE] S2 backbone — characters/economy/feed/trust/vault 스키마·API 표면 | Medium / Backlog |
| YUON-83 | [M2][APP+조율] S2 클라 스파이크 — 탭/게임뷰·피드·vault·에셋·계약 합의 | Medium / Backlog |
행정·법인·런치 트랙(진우님): YUON-159(Apple Developer·Urgent)·164(개인정보처리방침·High)·183(IP 귀속·High)·165(FE 화면 스펙·High)·166(Stage 2 정밀 스펙·High)·168/169 등. 코드가 아니라 8월 런치의 숨은 블로커 — 항승님 BE 레인 밖.
오늘(6/21) 항승님 액션 재정의
지난주 목표 "M1/진우님 버전 반영 + auth 최대한"은 이미 수봉님이 닫았다. 그대로 다시 하면 중복. 대신 — 오너십 회수는 이미 시작됐다(YUON-161 코덱스). 그걸 닫고 다음 칸을 정하는 게 오늘이다.
- YUON-161 끝까지 가져가기 — 코덱스로 진행 중인 Postgres 셋업을 머지까지. 실제 gcloud 프로비저닝(배포·권한)은 항승님 실행 버튼. 이게 회수 완료의 첫 증거.
- YUON-162 결정 — Cloud Run/GCS도 잡을지, 진우님 폴백("제가 겟")으로 명시적으로 넘길지. 침묵 = 암묵적 방치 지속.
- CP-2(YUON-163) 동결 푸시 — 이벤트 스키마가 안 닫히면 BE emit·9월 VRI가 막힌다. 30분짜리 레버리지. DS 레인 누가 보나 확인.
- 진우님 6/18 PR 리뷰 응답 — FE/BE 갭 분석 PR. 짧게라도 응답해 위임 2건의 "응답 대기"를 푼다.
- 오너십 회수 (읽기) — 수봉님이 만든 auth(DAV-90)·judgment seam(DAV-87)·8축 사전(DAV-88)·mandala(DAV-65) + 6/15 이후
YUON-177/186코드. 내일 미팅 "BE 현황 설명 가능" 상태가 목표.
검증 질문 (내일 미팅 전 결정할 것)
- 항승님은 BE 오너십을 다시 잡으러 가나(
YUON-161코덱스가 그 신호), 아니면 수봉님 주도를 공식화하고 다른 레인으로 옮기나? — 이 한 칸이 "따라잡기"의 방향을 정한다. - 진우님이 위임한 2건(인프라
161/162· 6/18 PR 리뷰)을 명시적으로 핸드오프할지, 범위를 줄여 쥘지("리뷰만 내가, 빌드는 수봉/진우"). 침묵 핸드오프는 미안함만 남긴다. - CP-2(
YUON-163) 동결 책임자는 누구인가? BE emit 블로커라 가장 먼저 풀려야 한다. - M2(
YUON-83/84) 착수 시점 — M1 FE 잔여(92/120/121/122) 먼저 닫고 가나?