야구 기록 보듯 게임개발자를追적해봤더니 보이는 진짜 성장 곡선

개발자도 박스스코어가 있다

얼마 전 야구 중계를 보다가 타율보다 출루율을 먼저 확인하는 제 습관이 꽤 오래됐다는 걸 느꼈습니다. 겉으로 보이는 안타 하나보다 볼넷을 골라낸 과정, 투수와의 승부에서 버틴 공 개수, 다음 타자에게 만든 흐름이 더 궁금하더라고요. 그런데 게임개발자라는 직업도 비슷합니다. 출시작 하나, 유명 회사 이름 하나만 보면 화려해 보이지만 실제 실력은 그 뒤에 쌓인 작은 기록에서 더 잘 드러납니다.

스포츠에서 선수를 볼 때 단순 득점만 보지 않듯, 게임개발자도 완성한 게임 수만으로 판단하기 어렵습니다. 프로토타입을 몇 번 갈아엎었는지, 버그를 얼마나 빠르게 잡았는지, 유저 피드백을 다음 빌드에 어떻게 반영했는지가 중요합니다. 특히 게임은 기획, 아트, 사운드, 서버, 클라이언트, 밸런스가 한 경기장 안에서 동시에 움직이는 종목에 가깝습니다.

출시라는 1승 뒤에는 긴 시즌이 있다

스포츠 팬 입장에서 가장 익숙한 숫자는 승패입니다. 하지만 시즌을 제대로 보면 1승이 그냥 생기지 않습니다. 선발 로테이션, 불펜 소모, 부상자 관리, 원정 일정이 다 얽혀 있죠. 게임개발자에게 출시도 그렇습니다. 스팀에 게임 하나가 올라왔다고 해서 그날 갑자기 완성된 게 아닙니다. 짧게는 6개월, 길게는 3년 이상 같은 시스템을 만지고 또 만지는 시간이 있습니다.

예를 들어 인디 게임 하나를 만든다고 치면 초반 1개월은 아이디어가 넘칩니다. 근데 3개월 차부터는 진짜 기록 싸움이 시작됩니다. 하루에 고친 버그 12개, 새로 생긴 버그 9개, 테스트 유저 30명 중 18명이 같은 구간에서 이탈했다는 숫자들이 쌓입니다. 스포츠로 치면 연습경기에서 계속 같은 코스에 약점이 잡히는 셈입니다.

• 첫 10분 이탈률이 높으면 튜토리얼 설계가 흔들렸을 가능성이 큽니다.
• 반복 플레이 시간이 짧으면 보상 구조나 난이도 곡선이 약할 수 있습니다.
• 특정 스테이지 실패율이 70%를 넘으면 의도한 도전인지 불친절한 설계인지 다시 봐야 합니다.

이런 숫자는 차갑지만, 사실 꽤 인간적입니다. 유저가 어디서 멈췄는지 알려주고, 개발자가 어디를 더 설명해야 하는지 말해주니까요.

좋은 게임개발자는 기록지를 다르게 읽는다

같은 타율 0.280이라도 득점권 성적, 상대 투수 유형, 최근 15경기 흐름을 보면 느낌이 달라집니다. 게임개발자도 로그와 지표를 읽는 방식에서 차이가 납니다. 단순히 “유저가 많이 나갔다”에서 멈추면 다음 액션이 흐립니다. 반대로 “2번째 전투 직후, 보상 선택 화면에서 42%가 종료했다”까지 들어가면 이야기가 생깁니다.

솔직히 게임 개발은 감각만으로 버티기 어렵습니다. 물론 손맛, 리듬, 분위기는 중요합니다. 그런데 그 감각이 실제 플레이 데이터와 만나야 오래 갑니다. 액션 게임에서 공격 후 딜레이를 0.2초 줄였더니 재시도율이 올라간다든지, 카드 게임에서 특정 조합 승률이 58%를 넘으면서 메타가 한쪽으로 쏠린다든지 하는 순간들이 있습니다. 이건 야구에서 구속 2km가 오른 것보다 회전수와 제구 위치가 같이 바뀌었는지를 보는 감각과 닮았습니다.

포트폴리오도 하이라이트 영상만으로는 부족하다

게임개발자를 준비하는 사람에게 포트폴리오는 하이라이트 영상 같은 역할을 합니다. 그런데 하이라이트만 보면 멋진 장면은 보이지만 경기 운영 능력은 잘 안 보입니다. 그래서 저는 포트폴리오를 볼 때 완성 화면보다 과정 기록이 더 눈에 들어옵니다. 어떤 문제를 발견했고, 어떤 선택지를 버렸고, 최종적으로 왜 그 구조를 택했는지 적혀 있으면 신뢰도가 확 올라갑니다.

예를 들어 “전투 시스템 구현”이라고만 쓰는 것보다 “초기 공격 판정이 넓어 난이도가 낮아졌고, 히트박스를 15% 줄인 뒤 평균 클리어 시간이 4분 20초에서 5분 05초로 늘었다”라고 쓰면 훨씬 선명합니다. 이건 단순 기술 자랑이 아니라 경기 흐름을 읽었다는 증거입니다.

팀 스포츠로 보면 더 잘 보인다

게임개발자는 혼자 코딩만 하는 이미지가 강하지만, 실제 현장은 팀 스포츠에 훨씬 가깝습니다. 기획자가 전술을 짜고, 프로그래머가 움직임을 구현하고, 아티스트가 경기장의 표정을 만들고, 사운드 디자이너가 타이밍의 감정을 얹습니다. 서버 개발자는 보이지 않는 수비 라인처럼 안정성을 책임집니다.

근데 팀 스포츠에서 제일 어려운 건 각자 잘하는 것보다 같은 템포로 움직이는 일입니다. 개발에서도 마찬가지입니다. 기획서가 바뀌면 코드 구조가 흔들리고, 캐릭터 모션이 늦어지면 전투 밸런스 테스트도 밀립니다. 그래서 좋은 게임개발자는 자기 파트만 잘하는 사람이 아니라, 다른 포지션의 언어를 어느 정도 이해하는 사람에 가깝습니다.

• 클라이언트 개발자는 아트 리소스 용량과 프레임 저하를 같이 봐야 합니다.
• 기획자는 구현 비용과 테스트 시간을 감안해 우선순위를 잡아야 합니다.
• 서버 개발자는 동시 접속자 수뿐 아니라 장애 상황의 복구 흐름까지 계산해야 합니다.

스포츠에서 강팀은 스타 한 명보다 역할 분담이 정확한 팀인 경우가 많습니다. 게임 개발팀도 비슷합니다. 누가 득점했는지만큼 누가 공간을 만들었는지가 중요합니다.

숫자 뒤의 이야기를 보는 직업

게임개발자라는 키워드를 스포츠 기록처럼 따라가면 꽤 흥미롭습니다. 다운로드 수, 동시 접속자, 평균 플레이 시간, 재방문율 같은 숫자는 단순한 성적표가 아닙니다. 그 안에는 유저가 재미를 느낀 순간, 지루해진 구간, 다시 접속하게 만든 장면이 들어 있습니다.

저는 그래서 게임개발자를 볼 때 “무슨 엔진을 쓰느냐”만큼 “어떤 데이터를 보고 판단하느냐”를 중요하게 봅니다. 유니티든 언리얼이든, C#이든 C++이든 도구는 결국 경기 장비에 가깝습니다. 진짜 차이는 플레이어의 움직임을 읽고 다음 패치를 설계하는 눈에서 납니다.

스포츠가 기록만으로 완성되지 않듯 게임도 코드만으로 완성되지 않습니다. 숫자는 방향을 알려주고, 감각은 그 방향에 온도를 넣습니다. 좋은 게임개발자는 그 사이에서 계속 스윙을 고치고, 투구폼을 다듬고, 다음 경기의 승부처를 준비하는 사람처럼 보입니다. 그래서 저는 이 직업을 볼 때마다 화면 뒤에서 이어지는 긴 시즌을 떠올리게 됩니다.