현업(게임) 시스템 기획자의 실무 노트

모바일 캐릭터 수집 RPG의 길드 시스템 을 기획하고, 기획서의 테이블과 플로우를 그대로 HTML/JS 프로토타입으로 구현해 본 작업입니다. 아래 데모는 별도 서버 없이 브라우저에서 바로 동작하며, 유저 데이터를 직접 수정하면서 정렬·권한·랭킹 반영을 확인할 수 있습니다. 1. 시스템 개요 길드는 출석·기부·연구·레이드·채팅으로 구성되며, 채팅을 제외한 모든 활동에서 길드 공헌도 를 획득합니다. 누적 공헌도로 길드 레벨이 1~25까지 성장하고, 레벨에 따라 최대 인원(20→50명)과 부길드장 수(1→5명), 길드 버프가 확장됩니다. 일일 콘텐츠는 모두 UTC 00시에 초기화됩니다. 2. 등급과 권한 길드원 등급은 길드장 / 부길드장 / 길드원 3단계입니다. 이름·엠블렘·가입 조건 변경과 해산은 길드장 전용, 가입 승인·등급 변경·추방·소개글·공지·연구 오픈은 부길드장까지, 채팅은 전 등급이 사용합니다. 권한이 없는 항목은 딤드 처리하고 터치 시 안내 메시지를 출력합니다. 데모 상단의 등급 시뮬레이션으로 직접 확인할 수 있습니다. 3. 길드 리스트 · 생성 · 가입 목록은 가입 신청한 길드 > 만원이 아닌 길드 필터 > 공헌도 높은 순 > 인원 많은 순 으로 정렬합니다. 가입 방식은 신청 / 즉시 가입 / 암호 입력(전용 숫자 키패드, 4자리) 3종이며, 동시 가입 신청은 최대 3개로 제한합니다. 검색 시에는 만원 길드도 필터링하지 않고 전체 검색합니다. 길드 생성은 프레임·문양·색상 엠블렘 조합, 이름 2~10자(특수문자·중복 검증), 소개글 20자, 공지 200자로 구성됩니다. 4. 길드원 관리 (유저 리스트) 등급, 이름·UID, 레벨, 접속 정보, 누적/주간 공헌도를 표시합니다. 기본 정렬은 주간 공헌도 내림차순 > 레벨 내림차순 > 이름 오름차순 이고, 컬럼 터치로 우선 정렬과 오름/내림 토글이 가능합니다. 접속 정보는 접속 중 / N분 전 / N시간 전 / N일 N시간 전 / N일 전 포맷으로 자동...

 안녕하세요! '호랭이물어갈기획놈들' 입니다. 지난번 글에서는 어떤 서버 방식으로 설계를 하는게 제일 좋은지 알아봤다면 이번 3편에서는 길드 입장 버튼의 배치와 최적의 길드 콘텐츠 오픈 타이밍과 가입 플로우에 대해 이야기 드리려고 합니다. 바로 시작하겠습니다. 1. 길드 입장 버튼의 위치와 UI 중요도 대다수의 모바일 게임들을 보면 길드 버튼은 메인 로비에 던전, 상점, 장비 등과 같이 플레이 하는 유저들의 손가락이 아주 쉽게 닿는 곳에 포진하고 있습니다. 물론 길드 콘텐츠가 필요없는 싱글 게임의 경우엔 예외지만 모바일 MMORPG나 수집형 RPG, 전쟁 게임 같은 길드 콘텐츠가 핵심으로 자리잡은 게임들 로비 UI에는 길드 창으로 진입하는 버튼은 구석에 두거나 서랍장 버튼 안에 숨겨두어선 안됩니다. <그림 1. 라오킹 연맹 버튼 위치> 버튼 위치: 메인 로비(또는 필드 화면) 우측 하단이나 우측 상단 등 유저의 엄지손가락이 가장 쉽게 닿는 메인 HUD 영역 . <그림 2. 블루 아카이브 서클 버튼 모양> UI 강조 디자인: 길드는 유저의 장기 잔존율(리텐션)을 책임지는 핵심 엔드 콘텐츠입니다. 따라서 여러 번 뎁스(Depth)를 파고 들어가지 않도록, 메인 UI에 독립적이고 큼직하게, 눈에 확 띄는 방패나 깃발 모양의 아이콘으로 배치하여 "이 게임은 길드가 매우 중요하다" 는 것을 시각적으로 각인시켜야 합니다. 즉 여러분이 개발하는 장르의 특성에 맞게 길드 입장 버튼 모양과 UI의 위치를 잘 잡아서 유저들의 동선을 장르에 맞게 잡아주는 것이 1차적으로 중요하다고 생각합니다. 아마 시안을 가져가면 100% 확률로 상급자에게 '여기에 이 버튼을 왜 넣었는지' 설명해야 하는 순간이 옵니다.  UI 디자이너와 논의할 때도 '단순히 예쁘니까, 쓰기편하니까'라는 이유보다는, 우리 프로젝트 특성상 길드 콘텐츠가 얼마나 중요한지 명확한 근거를 대며 설득해야 합니다. 기획자라면 항상 이 부분...

  와룡전 메인 페이지 진짜 메인 페이지 만큼은 꽤나 깔끔하게 잘 뽑아줬다! 출정과 무장 열람 정도로 단출한 화면이지만 상당히 기대감이 있는 화면이었는데.. 사실 '와룡전' 이라고 하면 내가 군주가 아닌 군사가 되어 건의를 하고 내정에 장수를 배치하고 전쟁의 경우 타국이 침공을 하지 않는 이상은 원한다고 아무때나 전쟁을 진행하는 것이 아닌 군주에게 건의 후 승낙 했을 시 타국과의 전쟁이 진행되는 일반적인 그 당시 삼국지와는 다른 느낌을 주던 게임이었다. 그런 게임을 와룡전 만들어줘! 딱 이 한마디로 저런 기대감 넘치는 화면을 만들어줬으니 스스로 AI의 발전이 참 대단하구나! 란 생각을 했지만 출정 버튼을 누르자마자 모든 기대는 와르르 무너졌다. 와룡전 출정 페이지 여기까지도 진짜 기대감을 뿜뿜하며 이야 뭔 AI가 말 한마디 했다고 저렇게 만들어주냐!  진짜 엄청난 일을 내가 하고 있구나! 란 생각이 들었다. 특히 삼국지 하면 시나리오 선택하고 원하는 군주 선택하면 시작되는 페이지인데 이걸 이 녀석이 구현한 것인가?  정말 기술의 발전이 놀랍다는 생각을 하게 되는 화면이다. 그리고 아래 두 개의 전투에 잠금 표시가 있는 것을 보고  오!! 황건의 난을 시원하게 이기면 호뢰관 전투가 진행되는구나!  이런 생각을 품으며 관도 대전까지 있는 것을 보니 원소도 고르고 조조도 고를 수 있구나!  진짜 게임 회사에서 사람 쉽게 잘라내는데 거기엔 이유가 있는 법!! 그럼 난 혹시나 회사가 힘들어지거나 해고의 바람이 불어도 저렇게 단어 몇 글자 쳐도 쉽사리 게임이 나오는 시기를 생각하면 다시 한번 창업에 도전해야 하나?  이런 참 미친 생각을 잠깐이지만 했다는 것이 너무 창피할 정도로 전투 화면이 사람의 기운을 쭉 빼버렸다.  전투 화면   쌍욕을 할 뻔 했다!  아니 그냥 욕을 바로 박았다!  그럼 그렇지!!  AI는 신나게 내가 원하는 내용을 싹 다 이야기해줘야 하는데...

포스팅 요약 키우기 게임에서 캐릭터 레벨을 999+로 설계하면 스탯 시트가 순식간에 수십만 줄이 됩니다. 이걸 어떻게 줄이고, 개발팀에 어떻게 설득하느냐 — 그 판단 과정을 정리했습니다. 레벨 설계하다가 멘탈이 나간 날 키우기 게임을 만들고 있습니다. 키우기 장르 특성상 레벨이 일반적인 RPG처럼 99에서 끝나지 않습니다. 최소 999, 길게 보면 사실상 무한대에 가까운 확장을 전제로 설계해야 합니다. 그러다 보니 캐릭터 한 명당 스탯 시트를 짜면 1,000줄 단위 가 기본입니다. 여기에 10년 서비스를 목표로 앞뒤 버퍼까지 잡으면 캐릭터 한 명에 만 줄 . 캐릭터가 10명이면 10만 줄, 100명이면 100만 줄입니다. 고유 ID 앞자리 숫자도 만 단위로 맞춰야 하고요. 솔직히 말하면 이건 개 미친짓 입니다. 영혼의 밸런스를 잡는 프로젝트가 아닌 이상, 이 구조로 가면 기획자 혼자 엑셀 노가다에 묻힙니다. 해결책 1 — 개발팀에 구조를 먼저 제안하세요 가장 현실적인 방법은 기획자가 먼저 구조를 제안하고, 개발팀과 합의하는 겁니다. 방법은 간단합니다. 1레벨과 최종 레벨(예: 1,000레벨)의 최대 스탯만 정해두고, 레벨 1 상승 시 스탯 증가량을 최종값 ÷ 최대 레벨로 자동 계산하도록 개발에 요청합니다. 기획서에는 시작값과 끝값, 증가 공식 만 적으면 됩니다. 중간 999줄은 개발 쪽에서 코드로 처리합니다. 주니어 기획자 입장에서 이 제안을 개발팀에 설득할 때 포인트는 하나입니다. "제가 줄 별로 다 채우는 것보다, 공식으로 처리하면 밸런스 수정도 훨씬 빠릅니다." 틀린 말이 아니고, 개발팀 입장에서도 나쁘지 않은 제안입니다. 해결책 2 — BM 구조를 먼저 확인하세요 다만 이 방법이 통하지 않는 경우가 있습니다. 핵심 BM이 장비 강화나 연구 트리 같은 곳에 몰려있다면, 레벨 구간별로 스탯 분기점이 생겨야 유저가 결제 허들을 느낍니다. 이럴 때는 레벨 수를 줄이더라도 수백 단위로 압축 하...

  매출 압박과 하향 패치의 딜레마 라이브 게임(Live Ops)을 서비스하다 보면, 매출 압박에 시달리는 사업부나 경영진으로부터 아찔한 밸런싱 오더가 내려오곤 합니다. "최근 캐시 상점 패키지 수익률이 너무 낮습니다."  로그를 까보니 특정 'NPC 약탈 티켓' 의 효율이 너무 좋아서 헤비 유저들이 결제를 안 하네요.  "당장 다음 정기 점검 때 이 티켓 보상을 삭제하세요." 이런 오더가 내려오면 기획자는 선택의 기로에 섭니다.  경영진의 오더를 수용하여 공식 카페가 불타는 것을 지켜보거나, 치밀하게 수치화된 데이터로 오더의 위험성을 증명하고 시스템을 방어하거나. 저 역시 과거, 전자의 길을 택해 100% 롤백(Rollback)을 겪어야만 했던 뼈아픈 기억이 있습니다.  그날의 실패 사례와 그 이면에 숨겨진 리스크 통제 로직을 담담하게 복기해 봅니다. 공시지가식 보상의 치명적 오류 (Loss Aversion) 당시 티켓 삭제 오더를 방어하기 위해, 해당 티켓이 가진 최대 효율을 원화 가치로 환산했습니다(약 4,500원 상당).  그리고 캐시 상점의 최대 할인율을 적용해, 사라진 티켓 자리에 최대 할인율을 적용한 자원을 직접 지급하는 '등가교환'의 우회안을 올렸습니다. 하지만 회의실에서 돌아온 대답은 차가웠습니다.  "지급량이 너무 많습니다. 할인율 빼고, 시스템 기본가로 계산해서 확 줄이세요." 저는 반대했습니다.  유저가 체감하는 티켓의 가치(실거래가)가 있는데, 개발사가 임의로 정한 기본가(공시지가)로 후려치면 유저들은 강제로 철거당하는 듯한 박탈감을 느낄 것이라 경고했죠.  하지만 결과는 기획안 반려, 그리고 원안 강행이었습니다. 경영진은 유저가 원하는 타이밍에 능동적으로 보상을 얻는 '플레이 선택권' 을 뺏는 행위의 심리적 손실(Loss Aversion)을 간과했습니다.  엑셀 상의 산술적인 숫자만 맞추면 유저의 분노가 상쇄될 것이라는 치명적인 오판의 결과...