피드백을 설계에 반영하는 방식
비판이 아니라 업데이트다
기획자의 하루는 피드백으로 시작해서 피드백으로 끝납니다.
개발팀 미팅 : 캐릭터가 장비에 의해 능력치 성장 or 상태 이상에 의해 MaxHP가 변화한다면 CurrentHP 처리는 어떻게 하실 예정이신가요?
UI팀 미팅 : UI 조작 뎁스가 깊은 것 같아 복잡하게 느껴집니다. 또한 창 [뒤로 돌아가기] 시 내비게이션을 어느 지점에서 초기화해야 할까요? 화면 크기 비율 및 그에 따른 팝업 창 종류에 따른 규격 설정도 필요합니다.
Q/A 리포트 : 기획서 갱신 오류인가요? 아니면 의도된 상황인가요?
내부 테스트 : 이 무기를 사용 시 승리 횟수가 높은데 이 무기 효율이 좋은 건가? 아니면 이 무기를 사용하는 테스터 조작이 좋은 걸까?
이럴 듯 기획자는 기획 단계에서 구현 가능 여부를 사전에 개발팀과 논의하거나, 기획 이후 개발팀 회의에서 기획에서 놓치거나 다른 구현 방안에 대한 피드백을 받게 됩니다.
그리고 이런 피드백 속에서 스스로 느끼기에 놓쳤다고 느낀 부분이 나오면 '내가 덜 고민했구나' , '내가 뭔가 잘못 생각하고 만들었구나', '내가 부족하구나' 등의 자조 섞인 마음에 더 잘하지 못한 자신이 부끄럽게 느껴집니다.
하지만, 피드백은 비난이 아니라 더 나은 게임을 만들기 위한 재료를 다듬는 과정이란 것을 안 이후 피드백을 받는 이 시간이 즐거워진 것 같습니다.
피드백은 설계의 블라인드 스폿을 알려주는 센서
게임 데이터를 분석하는 것처럼 피드백을 분석하고 그 안에서 더 좋은 방향을 찾아야 합니다.
이탈률 급상승 → 어디서 플레이어가 막혔는지 찾아야 함
특정 아이템 사용률 0% → 밸런스 문제 또는 접근성 문제
평균 플레이 시간 감소 → 재미 요소 부족 또는 난이도 문제
을 데이터를 통해 찾는 것처럼
개발자의 "구현 어렵다" = 리소스 제약 데이터
아티스트의 "동선이 어색하다" = 사용자 경험 데이터
QA의 "여기서 막힐 수 있다" = 실제 플레이 환경 데이터
테스터의 "지루하다" = 재미 지속성 데이터
와 같은 언어로 바꾸어 내 기획이 놓치고 있던 변수를 알려주는 정보로 삼아야 합니다.
어드벤처 모드가 결합된 대전 액션
논의 내용:
대전 액션에 어드벤처 모드를 섞어 탐험하는 시스템을 설계하기 위해, 대전하는 중간에 퍼즐을 풀거나 환경이 변하는 요소를 넣어 기존 액션 게임과 차별화된 게임을 자체 엔진으로 개발하자.
에 대한 초기 개발 방향성에 쏟아지는 피드백들은
개발팀: "각 던전마다 트리거를 통해 고유한 퍼즐 로직을 발동해야 하므로 개발 시간 및 엔진 개발에 시간이 너무 오래 걸립니다."
아트팀: "던전 내부 콘셉트에 필요한 구조물 정보가 필요합니다."
QA팀: "전투하다 맵이 유동적으로 변해서 대응하기 어려울 것 같습니다 타깃에 맞는지 확인이 필요합니다.."
이에 대응해 내부에서 내린 결과물은
개발팀 피드백 해석: 고유 퍼즐 시스템 → 트리거를 이용한 발동을 기획팀에서 제어할 수 있도록 툴 제작.
아트팀 피드백 해석: 콘셉트 방향의 모호함 → 각 오브젝트 별 조작 방향 및 특징 그리고 거리 등을 세밀하게 기획.
QA팀 피드백 해석: 힌트 부족 → 고객 타겟층에 맞는 난이도 조정 및 길 찾기 시스템 도입.
이렇게 피드백을 받게 되면 피드백을 반영하기 위한 3단계 프로세스를 다음과 같이 구축할 수 있게 됩니다.
피드백 반영의 3단계 프로세스
1단계: 즉각적 반영 (Critical Fix) 명확한 오류나 치명적인 문제는 바로 수정해야 합니다.
❌ 버그: 퍼즐 완료 후 다음 단계로 진행되지 않음 → ✅ 즉시 수정
❌ 기능 충돌: 전투 중 인벤토리 열면 게임 멈춤 → ✅ 즉시 수정
❌ 흐름 단절: 튜토리얼 없이 복잡한 시스템 노출 → ✅ 즉시 수정
2단계: 재해석 반영 (Design Evolution) 표면적 문제가 아닌 본질적 의도를 파악해야 합니다.
사례 1: "이 UI 불편해요" 표면적 해석: UI 디자인 변경 본질적 해석: 정보 전달 방식의 문제 해결책: 정보 구조 재설계 + UI 개선
사례 2: "던전이 너무 어려워요" 표면적 해석: 난이도 하향 조정 본질적 해석: 학습 곡선의 문제 해결책: 점진적 난이도 상승 + 명확한 피드백 시스템
3단계: 선별적 반영 (Strategic Decision) 모든 피드백을 반영할 수는 없습니다. 우선순위를 정해야 합니다.
즉시 반영 (High Impact + Low Cost): 치명적 버그 수정, 간단한 UX 개선 등
계획적 반영 (High Impact + High Cost): 핵심 시스템 개선, 대규모 콘텐츠 수정 등
검토 후 반영 (Low Impact + Low Cost): 부가 기능 개선, 시각적 효과 추가 등
보류 (Low Impact + High Cost): 니치 한 기능 요구, 비현실적인 리소스 요구사항 등
실제 개선 결과: 던전 시스템 2.0
• 개선된 설계:
모듈화 된 퍼즐 시스템: 5가지 기본 퍼즐 타입을 조합하는 방식으로, 새로운 던전 제작 시간을 70% 단축시켰습니다.
스마트 내비게이션: 미니맵에 현재 목표를 표시하고, 중요한 지점은 시각적으로 강조했습니다.
적응형 힌트 시스템: 플레이어가 일정 시간 멈춰있으면 자동으로 힌트를 제공하고, 힌트 강도를 플레이어가 설정할 수 있게 했습니다.
던전별 특색 시스템: 각 던전마다 고유한 기믹과 환경 요소를 활용한 다양한 상호작용을 추가했습니다.
• 결과: 플레이어 만족도 40% 상승, 완주율 60% 증가.
하지만 사람의 마음이란 것이 피드백을 좋게 받아드리지 못할 수도 있습니다. 이럴 땐!
피드백을 거부하고 싶을 때의 대처법
"이 피드백이 지적하는 문제점이 정확히 뭐지?"
"내가 놓친 관점이 있나?"
"이 문제를 해결하면 전체 시스템이 어떻게 개선될까?"
피드백 수용 체크리스트
✅ 받아들여야 할 피드백: 객관적 데이터나 사실에 기반하며, 플레이어 경험 개선에 도움이 되고, 기술적 현실성을 고려하며, 구체적인 개선 방향을 제시하는 피드백.
⚠️ 신중하게 검토할 피드백: 개인적 취향에 기반하거나, 전체 방향성과 충돌하며, 비현실적인 리소스를 요구하거나, 막연한 불만만 표현하는 피드백.
"피드백을 많이 받는다는 것은 그만큼 사람들이 당신의 작업에 관심을 갖고 있다는 뜻이에요. 아무도 관심 없으면 피드백도 없죠."
무플보단 악플이 좋다고 했던가요?
관심 있다는 지표인 피드백은 내 작업의 가치를 나타내는 것이라 생각합니다.
피드백을 대하는 새로운 마음가짐
❌ "또 뭘 잘못했나?" → ✅ "어떤 부분을 개선할 수 있을까?"
❌ "왜 자꾸 문제를 찾는 거야?" → ✅ "내가 놓친 관점이 있구나"
❌ "내 기획이 완벽하지 못해서..." → ✅ "더 나은 버전으로 업데이트할 기회네"
기획자는 영원한 베타 버전
소프트웨어가 지속적으로 업데이트되듯, 기획자도 끊임없이 자신을 업데이트해야 합니다. 피드백은 패치 노트입니다. 버그를 알려주고, 새로운 기능의 필요성을 제시하며, 사용자 경험 개선점을 가르쳐줍니다.
우리는 모두 베타 버전입니다. 완벽하지 않지만, 계속 나아가고 있습니다. 피드백을 두려워하지 말고, 대신 감사합시다. 그것들이 우리를 1.0에서 2.0으로, 2.0에서 3.0으로 발전시키는 원동력이니까요.
