PR #9는 코드를 바꾸는 PR이 아니라, Yuon Stage 1에서 제품 스펙과 백엔드 구현이 서로 다른 경제 모델을 바라보고 있음을 합의 테이블 위에 올리는 문서 PR이다.
행동 완료는 즉시 화폐 지급이 아니라 DPS 상승으로 기록된다. 실제 재화는 시간이 흐르며 정산된다.
체크인 시점에 포인트와 XP를 즉시 지급하고, 조건을 만족하면 배지를 바로 획득한다.
status == completedbase_points = difficulty * 5xp_ledger, level_definitionsbadge_definitions, user_badges| 축 | 스펙 | 현재 백엔드 | 의미 |
|---|---|---|---|
| 핵심 재화 | 골드 | 포인트 + XP + 배지 | 단순 명칭 차이가 아니라 경제 구조 차이다. |
| 보상 타이밍 | DPS 상승 후 시간 경과 정산 | 체크인 직후 즉시 적립 | 행동과 보상의 심리적 거리가 달라진다. |
| 철학 리스크 | “거울”처럼 누적 변화를 보여줌 | “행동하면 즉시 당근” 구조에 가까움 | over-justification 방어선이 약해질 수 있다. |
| 구현 비용 | 백엔드 재작업 필요 | 이미 구현되어 있음 | 무엇을 정본으로 볼지 PO-BE 결정이 먼저다. |
Wiki는 DPS/자동사냥/골드 모델을 building reference로 두고 있고, 실제 backend는 포인트/XP/배지 모델을 구현하고 있다. 둘 다 나름 말이 되지만, 동시에 정본일 수는 없다.
특히 즉시 보상은 Yuon 철학이 경계한 over-justification, 즉 “내가 하고 싶어서 한다”가 “보상 받으려고 한다”로 바뀌는 위험과 직접 연결된다.
현재 백엔드 구현을 제품 결정으로 인정하고 Wiki spec과 dd-1을 재작성한다.
Wiki spec을 제품 의도로 보고 backend reward 도메인을 DPS/settle 중심으로 재정렬한다.
포인트 모델을 M0 placeholder로 두되, EconomyPolicy 같은 경계 뒤에 격리해 Stage 2에서 교체 가능하게 한다.
PR #9는 모델을 확정하려는 PR이 아니라, PO와 BE가 서로 다른 모델을 보고 있음을 드러내는 합의 창구다. 차이 자체는 실제 백엔드 코드와 Wiki 스펙을 대조했을 때 확인된다.
따라서 이 PR은 “문서가 완벽한 결론을 냈는가”보다 “논의해야 할 차이를 정확히 테이블 위에 올렸는가”로 보는 게 맞다. 그 기준에서는 approve가 자연스럽다.
확인했습니다. PR #9가 말하는 차이는 “문서 표현 차이”가 아니라, Wiki backend spec의 DPS/settle/gold 모델과 현재 backend의 point/xp/badge 모델이 서로 다른 경제 모델을 전제로 한다는 점으로 이해했습니다.
제 쪽에서도 backend reward 흐름을 대조해보니 즉시 포인트·XP·배지 지급 구조가 맞고, Wiki 스펙은 DPS/자동사냥/골드 쪽을 정본으로 두고 있어 resync가 필요해 보입니다. 이 PR은 결론을 확정하기보다 그 차이를 합의 창구로 올리는 문서라고 보고 approve합니다.