야근과 협업 속에서 배운 것들

가장 복잡한 시스템은 사람이었다

by 루니

Aug 5. 2025

하루가 끝나고 나면, 또 다른 하루가 시작되곤 했습니다.

밤 9시의 회의

새벽 1시의 QA 피드백

오전 3시의 긴급 수정 요청…

야근은 언제나 저보다 먼저 출근해 있었습니다.

기획서를 다시 열어보니 수많은 자책이 밀려왔습니다.

'변경된 요소가 생각처럼 구현될까?'

'요청한 디자인 목록은 왜 안 오지?'

'과연 프로그래머가 구현 가능한 구조일까?'

게임 시스템을 논리적으로 설계하는 건 그나마 괜찮았지만, 사람과 사람 사이의 시스템을 조율하는 건 완전히 다른 차원의 문제였습니다.

저는 야근보다 협업이 더 어렵다는 뼈아픈 진실을 깨달았습니다.

� 기획자는 '번역가'다: 각 팀의 언어를 조율하는 법

기획자는 지시하는 사람이 아니라, 각 팀의 언어를 해석하고 조율하는 사람입니다. 그러나 일의 시작이 기획이다 보니, 이 중요한 역할을 잊고 독단적으로 움직이는 실수를 저지르기 쉽습니다.

� 아트팀의 언어: 아트팀에 피드백할 때 가장 많이 하는 실수는 기능이 아닌 눈에 보이는 디자인에만 치중하는 것입니다. "이 느낌이 안 나와요" 같은 추상적 피드백 대신, "이 기능은 저 기능과 연결되므로 비슷한 선상에 놓아야 합니다" 혹은 "사용자의 시야가 왼쪽에서 오른쪽으로 흐르니, 중요 정보는 오른쪽에 배치하는 것이 좋겠습니다"와 같이 기능적 맥락을 기반으로 소통하는 것이 중요합니다.

� 개발팀의 언어: 개발팀과 소통할 때는 정리되지 않은 정보를 나열하는 것을 경계해야 합니다. "이 정보와 저 정보가 필요합니다", "이 정보는 이런 데이터만 나열되어 있고요"와 같은 피드백은 같은 데이터 구조로 처리할 수 있는 요소를 분리하게 만들어 최적화를 방해합니다. 기획자는 명확한 구조도를 제시하며, 데이터 연동 흐름을 함께 공유하는 것이 중요합니다. "이럴 수도 있고 저럴 수도 있다"라는 애매한 논리는 시스템에 존재할 수 없기 때문입니다.

� QA팀의 언어: QA팀의 피드백은 언제나 '만약에'를 생각하는 예리한 시선으로 들어야 합니다. 그들은 "이 재현 이슈가 기획서 갱신 오류인지 아니면 기획 내 데이터 이슈인지"와 같이 기능적인 요소 외에 '유저가 할 법한 다양한 사고'를 가장해 모든 시스템의 빈틈을 파고듭니다.

야근 속에서 제가 배운 가장 중요한 깨달음은 이것이었습니다.

"나 혼자 이해한 시스템은, 완성되지 않은 시스템이다."

� 협업은 '내려놓음'에서 시작된다

제가 완벽하다고 생각한 시스템이 누군가에게는 작업량 폭탄이 될 수 있고, 심지어 구현 불가능한 이상이 될 수도 있습니다.

주니어 시절, 저는 제가 미리 구성한 데이터 구조에 갇혀 그 시스템과 관련된 작업이 선행되지 않았냐며 동료를 향해 집요하게 몰아붙인 적이 있습니다. 동료는 그 이유를 파악하지 못해 어리둥절한 상태였는데도 말이죠.

지금 생각해보면, 제가 설계한 구조가 완벽하다는 편견에 갇혀 더 나은 방향이 있을지도 모르는 가능성을 스스로 차단했던 것입니다. 그때의 과오를 토대로 지금의 저는 이런 질문을 먼저 던지게 되었습니다.

'이게 정말 중요한 기능인가?'

'다른 방법은 없을까?'

'현 시점에 이를 대처할 요소를 우선 구현 후, 추후 고도화하는 방법은 없을까?'

'나'의 완벽함에 갇혀 '내 기획이 옳다'는 편견을 벗어던지는 순간, 더 나은 해답이 보이기 시작했습니다. 협업은 내가 옳음을 주장하는 싸움이 아니라, 모두가 함께 앞으로 나아갈 방법을 찾는 과정이라는 것을요.

� 피로가 쌓인 만큼, 신뢰도 쌓인다

작은 기획 하나가 완성되기까지 얼마나 많은 전문성의 손길이 필요한지 깨달았습니다.

� 나의 한 줄 기획: "전투를 통해 기본 아이템을 획득하고, 이를 강화하여 성장을 확장하는 구조"

� 아트팀: 아이템 등급에 따른 배경색과 외형 변화 시안을 만듭니다.

� 개발팀: 전투 모션과 아이템 능력치 랜덤 옵션을 구현하고, 데이터 구조를 연동합니다.

� QA팀: 다양한 조합, 예외 상황 등 수천 번의 테스트로 시스템을 검증합니다.

그 결과물을 플레이어는 3초 만에 경험합니다. 그 3초를 위해 우리는 수주 간 밤을 지새웠고, 그 안에서 서로 다른 전문성을 가진 사람을 믿는 법을 배웠습니다. 개발자인 저조차도 플레이가 불편한 시스템을 만들고서야, 팀원들의 감정 또한 관리해야 할 중요한 시스템이라는 것을 깨달은 것입니다.