하향 패치 강행했다가 1주일 만에 롤백한 이유 — 경영진을 설득하지 못한 기획자의 기록

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

[게임 기획 실무] AI 프롬프트로 스킬 시스템 엑셀(DB) 테이블 설계하는 방법

이미지
  어제 올린 글에서 "이력서에 단순 AI 툴 사용 가능이라고 쓰지 말고, 기획을 검증한 과정을 증명하라"라고 강조했습니다. 그러자 게시글 보셨던 지인(지망생) 분이 묻습니다. "대체 그 게임 기획 AI 프롬프트를 실무에서 어떻게 쓴다는 겁니까?" 오늘은 10년 차 이상 중소기업 시스템 파트장인 제가 실제로 AI를 협업 툴이자 시뮬레이터로 쥐어짜는 방식을 가감 없이 공개하겠습니다.  단언컨대, 저는 AI에게 "스킬 시스템 DB 구조를 만들어줘"라고 명령하고 그것을 복사해서 붙여넣는 1차원적인 접근은 절대 하지 않습니다. 1. 신입 기획자의 함정: AI에게 완성된 '기획서'를 한 번에 요구하지 마십시오 스킬 시스템 기획서를 쓴다고 가정해 봅니다.  신입이나 지망생분들이 가장 많이 하는 실수는 챗GPT를 켜자마자 이렇게 입력하는 것입니다. "MMORPG WOW 스타일의 스킬 시스템 기획서를 작성해 줘!" 이렇게 나온 텍스트는 겉보기엔 그럴싸합니다.  하지만 이건 여러분의 프로젝트 엔진이나 서버 아키텍처에는 1도 맞지 않는 '실무에서 작동하지 않는 껍데기'에 불과합니다.  기획은 소설을 쓰는 게 아닙니다.  기획자는 데이터(Data)가 클라이언트와 서버 사이에서 어떻게 굴러가는지 통제해야 합니다.  이를 고민하지 않은 결과물은 현업 개발자들에게 반려 대상 1순위가 됩니다. 👉핵심 요약:  AI에게 완성된 기획서를 통째로 요구하지 마십시오. 데이터 통제력이 결여된 기획서는 실무 포트폴리오로 사용할 수 없습니다. 2. 게임 DB 테이블 설계의 본질: 데이터의 방향성과 규칙 정립 AI에게 키보드를 두드리기 전에, 기획자 본인의 머릿속에서 먼저 '이 시스템이 우리 게임에서 어떻게 굴러갈 것인가'에 대한 확고한 뼈대가 정립되어야 합니다. 한 번 찍으면 고정되는 '트리(Tree)형' 스킬을 만들 것인가? 유저가 룬이나 보석을 박아 속성을 마음대로 ...