개발자와 싸우지 않고 설득하는 기술
"이건 구현이 안 됩니다" vs "그럼 게임이 재미없잖아요"
회의실에서 자주 듣는 대화입니다.
기획자는 재미를, 개발자는 현실을 이야기합니다. 서로 다른 언어를 쓰니 대화가 될 리 없습니다.
저의 주니어 시절에는 이런 대화의 연속이었습니다.
개발자: "이 시스템은 범용적으로 구현하기 어렵습니다. 이 시스템을 위해서 하드코딩 하라는 말씀이신가요?"
기획자: "하드 코딩을 원하지는 않습니다만, 기존 시스템과 범용적으로 하기 위해선 이미 선 구현된 구조를 개편해야 합니다. 하지만 현실적으로 그 부분이 불가능하다고 하시니…"
개발자: "그 전에 개발된 코드라 수정하면 어디서 이슈가 발생할지 모릅니다."
결과는 뻔했습니다.
개발자의 기존 방향에 맞춰 기획을 바꾸거나, 예전 방식을 고수하는 일이 반복되었습니다.
시스템 기획자인 저도 이런데, '재미'라는 추상적인 요소를 담당하는 콘텐츠 기획자들은 개발자를 설득하는 데 더 큰 어려움을 겪곤 했습니다.
하지만 콘텐츠든 시스템이든, 모두 게임의 '재미'를 위한 설계를 하는 사람이고, 기획자의 역할은 주장을 관철하는 사람이 아니라, 팀을 설득해 같은 방향으로 움직이게 하는 사람이라는 것을 깨달았습니다.
대화의 언어를 바꾸면 관계가 바뀐다
Before: 질문으로 압박하기
"왜 구현이 어려운가요?"
"다른 게임에서는 다 하는데 왜 우리만 못해요?"
"그럼 언제까지 가능한가요?"
After: 해결책을 함께 찾기
"구현 난이도를 낮추려면 어떤 대안이 있을까요?"
"이 기능의 핵심 경험을 유지하면서 다른 방식으로 접근할 방법이 있을까요?"
"개발 리소스를 고려했을 때, 어떤 순서로 구현하는 게 효율적일까요?"
같은 내용이라도 질문의 방향이 바뀌면 대화의 온도가 완전히 달라집니다.
복잡한 퀘스트 시스템 설득기
상황: RPG 게임에서 분기 퀘스트 시스템을 기획했습니다. 플레이어의 선택에 따라 스토리가 분기되고, 각각 다른 결말을 맞는 구조였죠.
개발팀의 반응: "이 시스템은 구현이 너무 복잡합니다. 분기점마다 별도의 로직을 짜야 하고, 버그 발생 가능성도 높아요. 차라리 기존의 선형 퀘스트로 가면 안 될까요?"
이렇듯 개발자는 '재미'보다 구현 이슈를 최소화하고, 최적화하는 방향으로 논의를 이끌어갑니다.
이런 반응에 "이 시스템이 없으면 게임의 차별점이 사라져요! 플레이어들이 원하는 건 선택의 재미잖아요!"라는 식으로 대응하기보다는 다음과 같이 접근해야 합니다.
1단계: 개발자의 관점 이해하기
"선택 분기 시스템에서 가장 구현이 어려운 부분이 어디인가요? 분기 로직 자체인가요, 아니면 각 분기별 콘텐츠 관리인가요?" 이런 질문을 던지면 개발자는 이렇게 답할 것입니다. "사실 분기 로직 자체는 어렵지 않아요. 문제는 각 분기가 서로 영향을 주고받을 때 발생하는 의존성 관리와 디버깅이에요." 실제로 구현이 아예 불가능한 경우는 드물기 때문이죠.
2단계: 맥락과 우선순위 설명하기
"이해했습니다. 그럼 이렇게 접근해보면 어떨까요?
전체 퀘스트 중 정말 핵심이 되는 3개 지점에만 브랜치를 적용
나머지는 선형으로 진행하되, 선택의 '느낌'은 대화 옵션으로 대체
각 분기는 완전히 독립적으로 설계해서 의존성 최소화"
3단계: 구현 순서 제안하기
"1차로는 가장 단순한 A/B 브랜치 하나만 구현해보고, 안정성을 확인한 후 점진적으로 확장하는 건 어떨까요?"
이렇게 하면 개발팀이 적극적으로 참여하기 시작합니다. 게임에서 발생하는 시너지 효과와 구현 방향을 서로 조율하고, 자신의 아이디어를 추가한 기획안이 되기 때문에 동기 부여가 강화되죠. 기획자 혼자 기획하는 것보다 더 나은 아이디어가 개발자와의 논의 과정에서 추가되기도 합니다.
"기획서대로 하면 세이브 데이터가 복잡해지는데, 플레이어별 '선택 히스토리'를 별도로 관리하면 어떨까요? 그러면 나중에 통계 분석도 쉬워지고, 개인화된 콘텐츠 추천도 가능해져요."
논리가 아닌 맥락으로 설득하라
개발자가 납득하는 설명법
❌ 재미 중심의 설명: "이 시스템은 정말 재미있어요! 플레이어들이 몇 시간씩 고민하게 될 거예요!"
✅ 구조적 맥락의 설명: "이 시스템이 없으면, 플레이 루프에서 성취감 구간이 비어버립니다. 다른 시스템들과의 연결고리가 끊어져 장기적으로는 콘텐츠 소모 속도가 빨라질 겁니다."
✅ 기술적 이점까지 포함한 설명: "이 시스템을 모듈화해서 구현하면, 다른 프로젝트에서도 재사용 가능하고, 향후 유사 기능 추가 시 개발 시간을 크게 단축할 수 있습니다."
타협은 패배가 아니라 더 나은 설계의 시작이다
실제 경험담: 실시간 PvP 시스템
원 기획: 100명이 동시에 참여하는 배틀로얄
개발팀 피드백: "서버 부하가 너무 크고, 네트워크 동기화 문제로 렉이 심할 것 같습니다."
잘못된 접근: "그럼 게임의 핵심이 사라지잖아요!"
잘된 접근: "그럼 같은 재미를 다른 방식으로 구현할 방법을 찾아보죠."
이렇게 의논하다 보면 다음과 같은 해결책이 나오기도 합니다.
100명 → 20명으로 규모 축소
대신 여러 라운드를 빠르게 진행하는 구조
각 라운드 간 연결고리를 만들어 전체적인 스케일감 확보
관전 시스템을 추가해 100명이 참여하는 '느낌' 구현
결과: 원래보다 더 안정적이고 재미있는 시스템으로 구현될 수 있는 방향이 마련됩니다.
설득의 단계별 전략
1단계: 경청과 이해
"이 기능 구현이 어려운 이유를 자세히 설명해주실 수 있나요?"
"어떤 부분에서 가장 많은 시간이 소요될 것 같나요?"
"비슷한 기능을 구현해본 경험이 있으신가요?"
2단계: 공통 목표 확인
"우리 모두 좋은 게임을 만들고 싶다는 목표는 같죠?"
"이 기능이 추구하는 핵심 경험을 다른 방식으로도 구현할 수 있을까요?"
3단계: 협력적 해결책 모색
"제약 조건 내에서 최대한 비슷한 경험을 만들려면 어떤 방법이 있을까요?"
"1차로는 간단하게 구현하고, 점진적으로 발전시켜 나가면 어떨까요?"
4단계: 구체적 액션 플랜
"그럼 이번 주까지는 프로토타입을 만들어보고, 다음 주에 검토해보면 어떨까요?"
"필요한 리소스나 지원이 있다면 알려주세요."
개발자별 설득 포인트 파악하기
시니어 개발자: 아키텍처, 유지보수성, 확장성 → "이 시스템을 어떻게 설계하면 향후 확장이 쉬울까요?"
주니어 개발자: 학습, 성장, 성취감 → "이 기능을 구현하면서 새로운 기술을 배워볼 수 있을 것 같은데요."
백엔드 개발자: 성능, 안정성, 확장성 → "서버 부하를 최소화하면서도 사용자 경험을 높일 수 있는 방법이 있을까요?"
클라이언트 개발자: 사용성, 반응성, 최적화 → "사용자가 직관적으로 이해할 수 있는 UI/UX로 구현하려면?"
피해야 할 표현과 사용해야 할 표현
• ❌ 절대 사용하면 안 되는 표현
"그냥 간단하게 만들면 안 돼요?"
"다른 게임에서는 다 하는데요?"
"이 정도도 못 만들어요?"
"기획대로 안 되면 게임이 망해요"
• ✅ 대신 사용할 표현
"어떻게 하면 구현이 더 수월해질까요?"
"다른 방법도 검토해볼 수 있을까요?"
"이런 접근은 어떠신가요?"
"함께 더 나은 방법을 찾아보죠"
설득의 최종 목표: 파트너십 구축
개발자와 싸우지 않고 설득하는 기술의 핵심은 상대를 적으로 보지 않는 것입니다. 우리는 각자 다른 전문성으로 같은 목표를 향해 가는 파트너입니다.
개발자는 코드로 현실을 구현합니다.
기획자는 구조로 경험을 설계합니다.
디자이너는 감각으로 감정을 전달합니다.
설득은 상대를 굴복시키는 기술이 아니라, 서로의 언어를 번역하는 능력입니다.
존중에서 시작되는 협업
몇 년 전, 한 시니어 개발자가 제게 말했습니다. "기획자님과 일하기 좋은 이유는, 저희가 '안 된다'고 하면 '왜 안 되는지' 먼저 물어보시기 때문이에요. 그리고 함께 해결책을 찾으려고 하시죠. 덕분에 저희도 더 적극적으로 아이디어를 내게 돼요."
그때 깨달았습니다. 진짜 설득은 논리로 이기는 것이 아니라, 신뢰로 함께 나아가는 것이라는 걸. 기획자의 설득 기술은 결국 팀워크의 기술입니다. 각자의 전문성을 존중하고, 서로의 언어를 이해하며, 공통의 목표를 향해 함께 걸어가는 것.
그 길 위에서 가장 좋은 게임들이 탄생합니다.
