출석 시스템 설계

Design Note — 연속 출석부 길이를 7일로 정한 이유

출석부가 너무 길거나 짧으면 유저가 목표로 삼기 어렵다고 판단했습니다. 벤치마킹한 캐주얼 게임(모노폴리 고 · 코인 마스터 · 트리플 매치 등)이 대부분 7일로 설정되어 있었고, 사회적으로 1주일(7일)이 기본 생활 주기라 유저가 이해하고 적응하기 쉬울 것이라 판단해 7일로 정했습니다.

Design Note — 연속 출석 보상 운영을 Constant 값으로 관리

초기엔 운영 웹에서 출석 스케줄을 관리하려 했으나 개발을 중지했습니다. 운영 웹 구현·유지 비용이 콘텐츠 볼륨에 비해 크고, 연속 출석 보상을 자주 교체하지 않을 것이며, 월 1회 패치 때 Constant 테이블의 '기본 연속 출석부 ID' 값만 바꿔주면 보상 교체가 가능하다고 판단했기 때문입니다. 정의되지 않은 기간엔 이 기본값을 불러와 오류를 방지합니다.

Design Note — 누적 출석 보상이 10일 간격인 이유

자주 지급하면 보상으로 줄 수 있는 아이템이 금방 고갈됩니다. "월에 몇 번 보상을 지급할 것인가"를 기준으로 세웠을 때, 2번은 장기 접속 동기로 부족하고, 4번은 연속 출석 지급과 겹칠 것으로 판단해 3번(10일 · 20일 · 30일)으로 선정했습니다.

Design Note — 보상을 3개씩 그룹으로 묶은 이유

유저에게 보이는 화면은 한정적이라 모든 보상을 한 화면에 보여줄 수 없습니다. 유저가 월 단위로 보상을 인지하고 목표를 세울 수 있도록 3개(≈30일) 단위로 구분했고, 그룹별로 동일 컨셉의 코스튬을 연달아 지급하면 "세트를 다 모으는 것"이 출석 동기가 됩니다.

Design Note — 누적 출석부 길이를 뒤에 계속 늘리지 않은 이유

새 보상을 출석부 뒤에 계속 추가하는 방식은 ① 리소스 제작 속도가 업데이트 속도를 못 따라가고 ② 장기 유지 유저 일부만을 위한 업데이트가 된다는 문제가 있습니다. 현재 출석부를 다 진행한 유저에게는 동일한 보상을 반복 지급하는 방식을 도입해, 누적 보상 데이터가 없어 생기는 오류를 막고 새 리소스를 제작할 시간을 벌 수 있게 했습니다.

Design Note — 그룹 진행도가 필요한 이유

보상까지 남은 수치가 안 보이면 유저가 직관적으로 받아들이기 어렵습니다. 전체 출석일이 아니라 그룹별 진행도를 프로그레스 바로 보여줘, 출석할 때마다 바가 눈에 띄게 차서 성취감을 느끼고 '이 그룹을 다 채우는 것'을 단기 목표로 삼도록 했습니다.

Design Note — 활성화 시점에 대한 고민

출석 시스템을 언제부터 유저에게 학습시키고 보상을 지급할지 고민했습니다. 빨리 하면 초기 리텐션은 올릴 수 있지만 아직 언락되지 않은 아이템이 보상으로 지급될 수 있고, 늦게 하면 초기 리텐션을 못 올립니다. 기본 튜토리얼이 끝나고, 글러브 종류에 따라 효과가 다르다는 것을 학습했을 것으로 판단되는 트로피 점수를 활성화 시점으로 결정했습니다.

회고

출석 시스템은 기능 구현보다 "이 숫자가 왜 이 값인가"를 팀에 설득하는 게 어렵습니다. 7일 · 10일 · 3그룹 같은 값에 벤치마킹과 판단 근거를 붙여 문서화했고, 만든 뒤에도 지표 로그로 검증·개선할 수 있게 한 것이 이 설계의 핵심입니다.