사실 이 글을 쓰게 된 계기가 좀 특별해요. 지난달에 참석한 게임 개발 세미나에서 한 선배 기획자가 했던 말이 계속 머릿속에 맴돌았거든요. "기획의 성공은 결국 의도를 얼마나 명확하게 전달하느냐에 달려있다"라는 그 한 마디가요. 그때 문득 제가 신입 시절을 떠올리게 되더라고요. 첫 프로젝트에서 기획서 하나 때문에 개발팀과 3일간 실랑이를 벌였던 기억이 생생해요. 그때는 정말 억울했는데, 지금 생각해 보니 제가 의도를 제대로 전달하지 못했던 거였어요. 그래서 오늘은 제가 10년간 현업에서 부딪히며 깨달은 것들을 정리해 볼까 합니다. 성공하는 기획자가 되려면 정말 중요한 3가지 - 명확한 의도 전달, 진짜 협업하는 방법, 그리고 실패를 다음 성공의 재료로 만드는 법에 대해서요.
1. 의도 전달 - 이게 진짜 어려워요
왜 이게 이렇게 중요한데?
아직도 생생한 기억이 하나 있어요. 제가 3년 차였을 때 담당했던 모바일 RPG 프로젝트에서 일어난 일이에요. 제가 "사용자 친화적인 인벤토리 시스템을 만들어주세요"라고 기획서에 써놨거든요. 결과는? 개발자 A 씨는 "도대체 사용자 친화적이 뭔 말인지 모르겠다"며 답답해했고, UI 디자이너 B 씨는 "콘셉트가 너무 애매해서 어떤 방향으로 작업해야 할지 감이 안 온다"라고 하더라고요. 그때 깨달았어요. 내가 머릿속에서 그리는 그림과 팀원들이 이해하는 내용이 완전히 다르다는 걸요. 이런 일이 반복되면:
- 각자 다른 방향으로 작업하게 되고
- 수정 작업이 계속 반복되면서
- 일정은 늘어지고 팀 분위기도 안 좋아지고
- 결국 퀄리티까지 떨어지더라고요
그럼 어떻게 해야 할까요?
5 W1 H... 뻔하지만 진짜 효과적이에요
처음엔 저도 "이런 기본적인 걸 굳이?"라고 생각했는데, 막상 해보니까 놀랍더라고요.
- Why: 왜 이 기능이 필요한가? (사용자 불편함 해결, 매출 증대 등)
- What: 구체적으로 무엇을 만들 것인가?
- Who: 누가 이걸 쓸 건가? (신규 유저? 기존 유저?)
- When: 언제까지? (현실적인 일정인지도 중요해요)
- Where: 어디에 들어갈 건가?
- How: 어떤 방식으로? (기술적 제약사항도 포함)
수치로 말하는 습관
요즘엔 이런 식으로 써요:
- 애매한 표현: "로딩 속도를 개선한다"
- 명확한 표현: "현재 5초 걸리는 로딩을 3초로 줄인다"
이렇게 하니까 개발팀에서도 "아, 이 정도면 가능하다" 또는 "이건 좀 무리다"라고 바로 피드백을 줘요.
그림으로 보여주는 게 최고
말로는 한계가 있어요. 그래서 저는 항상:
- 간단한 플로우차트 그리기
- 와이어프레임 대충이라도 스케치
- 비슷한 게임 캡처해서 "이런 느낌"이라고 보여주기
- 프로토타입 툴로 대략적인 움직임 구현
시간은 좀 걸리지만, 나중에 수정할 시간 생각하면 훨씬 효율적이에요.
2. 협업 - 1+1=3 만들기 (쉽지 않지만)
현실은 이래요...
솔직히 말하면 협업이 제일 어려워요. 제가 작년에 담당했던 프로젝트 얘기를 해드릴게요.
- 저는 "사용자 경험이 제일 중요하다"
- 개발팀은 "개발 일정 맞추는 게 우선이다"
- 디자인팀은 "비주얼 임팩트가 있어야 한다"
- 사업팀은 "수익성을 고려해야 한다"
각자 다 맞는 말이에요. 하지만 프로젝트 중반까지도 방향을 못 잡고 있더라고요. 정말 답답했어요.
그래서 이렇게 해봤어요
주 2회 짧은 동기화 미팅
30분씩만 해요. 길면 집중력도 떨어지고 다들 부담스러워해요.
- 각자 뭐 하고 있는지 간단히 공유
- 막힌 부분이나 고민 있으면 털어놓기
- 우선순위 바뀐 게 있으면 바로바로 조정
공통 목표 정하기... 이게 핵심이에요
프로젝트 시작할 때 모든 팀원이 동의하는 하나의 목표를 정해요. 예를 들어 "DAU 10만 달성"이라고 하면, 나중에 의견이 갈릴 때 "이게 DAU 증가에 도움이 되나?"를 기준으로 판단하죠. 개인 KPI도 이 목표랑 연결시키려고 노력해요. 그래야 진짜 한 방향으로 갈 수 있어요.
역할 분담 명확히 하기
RACI 매트릭스... 처음엔 복잡해 보이지만 한 번 해보면 정말 깔끔해요.
- R (Responsible): 실제 작업하는 사람
- A (Accountable): 최종 책임지는 사람
- C (Consulted): 의견을 물어봐야 하는 사람
- I (Informed): 결과를 알려줘야 하는 사람
특히 의견 충돌 났을 때 누가 최종 결정하는지 미리 정해두는 게 중요해요.
3. 실패를 성공으로 바꾸는 법 - 진짜 어려운 일
아직도 아픈 기억...
2년 전에 담당했던 모바일 퍼즐 게임이 있어요. 출시 첫 달 매출이 목표의 30%밖에 안 됐어요. 그때 정말 절망적이었죠. 6개월간 밤낮으로 작업했는데... 처음엔 그냥 "운이 없었다", "시장 상황이 안 좋았다"라고 생각했어요. 근데 팀장님이 "이걸 그냥 넘어가면 안 된다"라고 하시면서 체계적으로 분석해 보자고 하더라고요.
그때 찾아낸 진짜 문제들:
- 타깃 유저를 너무 막연하게 설정했음 (20-30대 여성... 이게 뭔 의미인지)
- 경쟁 게임 분석을 대충 했음 (킬링 포인트를 못 찾았음)
- 마케팅에서 어필한 포인트와 실제 게임이 달랐음
이 분석 결과를 바탕으로 다음 프로젝트에서는 150% 목표 달성했어요. 그때 깨달았죠. 실패가 끝이 아니라 시작일 수 있다는 걸요.
실패를 자산으로 만드는 나만의 방법
프로젝트 끝나면 무조건 회고
팀원들이 "또 회고야?"라고 하지만, 이게 진짜 중요해요.
- Keep: 다음에도 계속할 것들
- Problem: 문제였던 부분들 (솔직하게!)
- Try: 다음엔 이렇게 해보자
실패 분석 템플릿 만들기
저는 개인적으로 이런 양식을 써요:
- 5 Why 기법으로 원인 파고들기 (왜? 왜? 왜? 계속 물어보기)
- 수치로 영향도 측정하기 (감정적 평가 말고)
- 구체적인 개선안 도출하기 (막연한 계획 말고)
- 체크리스트 만들어서 다음에 실수 안 하기
개인 실패 노트 쓰기
매주 금요일마다 작은 실패들도 기록해요. "이번 주에 뭘 잘못했나?", "왜 그랬을까?", "다음엔 어떻게 하지?"
처음엔 우울했는데, 나중에 보니까 패턴이 보이더라고요. 저는 주로 일정을 너무 타이트하게 잡는 경향이 있다는 걸 발견했어요.
실무에서 바로 쓸 수 있는 체크리스트
의도 전달 체크포인트
- [ ] 5 W1 H 다 들어갔나? (빠진 거 없나?)
- [ ] 숫자로 표현할 수 있는 건 숫자로 했나?
- [ ] 개발자가 읽어도 이해할 수 있을까?
- [ ] 그림이나 참고 자료 첨부했나?
- [ ] 애매한 표현 없나? ("적절히", "대충", "잘" 같은 단어들)
협업 체크포인트
- [ ] 프로젝트 목표에 모두 동의했나?
- [ ] 누가 뭘 하는지 명확한가?
- [ ] 정기 미팅 일정 잡혔나?
- [ ] 의견 충돌 시 해결 방법 정했나?
- [ ] 각자 KPI가 팀 목표와 연결되나?
경험 활용 체크포인트
- [ ] 프로젝트 회고 했나?
- [ ] 실패 원인 구체적으로 분석했나?
- [ ] 다음 프로젝트에 반영할 수 있나?
- [ ] 팀원들과 경험 공유했나?
- [ ] 개인 학습 내용 정리했나?
마무리하며...
사실 이 글을 쓰면서도 "내가 이런 걸 말할 자격이 있나?"라는 생각이 들었어요. 아직도 실수 많이 하고, 완벽하지 않거든요. 하지만 10년 동안 현장에서 부딪히며 깨달은 건, 성공하는 기획자가 되는 데 특별한 비법은 없다는 거예요. 그냥 기본을 충실히 하는 것. 명확하게 전달하고, 진짜 협업하고, 실패에서 배우는 것이 전부더라고요. 이 세 가지는 따로 놀지 않아요. 의도를 명확히 전달하면 협업이 쉬워지고, 좋은 협업 경험은 다음 프로젝트에서 더 나은 의도 설정에 도움이 되죠. 이런 선순환이 만들어지면... 그때부터 진짜 성장이 시작되는 것 같아요. 물론 이것도 제 경험이고, 회사나 프로젝트마다 다를 수 있어요. 하지만 혹시 비슷한 고민을 하고 있는 기획자분들에게 조금이라도 도움이 되었으면 좋겠어요. 오늘부터 당신의 프로젝트에서 이 세 가지 한 번 점검해 보세요. 작은 변화가 정말 큰 차이를 만들 거예요. 저도 아직 배우는 중이니까, 함께 성장해요!
