회사들이 게임 출시 경험을 보는 이유

솔직히 요즘 게임사 채용 공고를 보면 문턱이 꽤 올라간 것 같습니다.

예전에는 "출시 경험 보유자 우대", "AI 활용 가능자 우대" 정도로 공고 맨 아래 우대사항 칸에 적혀 있던 항목들인데요. 최근에는 이게 자격요건 칸으로 올라온 공고가 하나둘 보입니다. 왜 이렇게 됐을까요. 공고를 쓰는 쪽 입장에서 생각해보는 시간을 가져보았습니다.

회사 안에서는 배울 기회가 거의 없어서

 

 

하이퍼캐주얼처럼 짧은 주기로 여러 개를 내보내는 곳이라면 입사 후에도 출시를 여러 번 겪게 될 수도 있지만, 그런 구조가 아닌 회사라면 이야기가 조금 달라집니다.

적지 않은 회사가 이미 내보낸 게임을 운영하는 데 인력의 대부분을 쓰고, 신규 타이틀을 처음부터 스토어에 올리는 일은 몇 년에 한 번 돌아옵니다. 라이브 팀에 배치되면 그 몇 년 동안 출시 과정은 멀리서 구경만 하게 되는 경우도 있고요.

게다가 출시는 생각보다 손이 많이 갑니다. 플랫폼 선정, 스토어 개발자 계정 등록, 빌드 서명과 패키징, 연령 등급 심의, 스토어 등록 정보와 스크린샷 준비, 심사 반려와 재제출, 결제 모듈 연동까지. 순수한 개발 외의 작업이 줄줄이 붙습니다.

그리고 어쩌다 한 번 오는 출시는 회사 입장에선 가장 예민한 시기이기도 합니다. 이 과정들이 한꺼번에 몰리는 구간이라 신입에게 그냥 던져두기엔 너무 중요하고, 제대로 가르치려면 선임 한 명의 시간을 통째로 가져갑니다. 물론 경험해본 신입도 결국 그 회사 방식대로 다시 배워야 하긴 할 겁니다. 그래도 채용 담당자 입장에선 한 번 겪어본 사람을 뽑는 쪽이 훨씬 마음이 놓일 겁니다.

 

출시'는 '개발'보다 훨씬 넓은 단어라서

 

 

출시를 경험한 기획자라면 이런 것들을 한 번씩 고민해봤다는 뜻입니다.

• 내가 만들 게임의 주 타겟은 누가 될지
• 핵심 재미 요소는 무엇인지, 재방문을 낼 만한 요소는 무엇인지
• 이 게임으로 어떻게 수익을 낼지, 광고는 어디에 걸지
• 유저 커뮤니티는 어디에 열지
• 문의가 들어오면 누가 언제 답할지
• 그 문의에 대응해서 업데이트는 어느 주기로 어떻게 만들지

프로그래머라면 이런 것들을 한 번씩 밟아봤다는 뜻이고요.

• 개발자 계정 등록부터 빌드 서명, 스토어 심사 반려 대응까지의 절차
• 결제·광고 SDK를 붙이면서 생기는 문제들
• 전면 광고가 들어갈 자리를 미리 비워둔 화면 설계
• 갤폴드처럼 비율이 독특한 기기, 노치와 세이프 에어리어 대응
• 3년 된 보급형에서의 프레임, 메모리, 빌드 용량
• 출시 다음 날 핫픽스를 내보낼 수 있는 버전 관리와 배포 경로

이런 내용들을 한 번씩은 고민해보았고, 하나하나를 해결하기 위해 행동으로 옮겨보았다는 뜻입니다.

 

재미있는 게임을 만드는 일과 그 게임으로 돈을 버는 일은 생각보다 다른 작업입니다. 앞쪽은 "이게 재미있나"를 묻고, 뒤쪽은 "누가 왜 이걸 다시 켜고, 어디서 비용을 회수하나"를 묻습니다. 둘 다 필요한데, 혼자 개발할 때는 대체로 앞쪽만 보게 되고요.

출시를 한 번 겪으면 그 두 번째 축이 설계 단계에서부터 보이기 시작합니다. 전면 광고를 어디에 끼워야 흐름이 덜 끊기는지, 튜토리얼을 어디서 끊어야 이탈이 적은지, UI를 처음부터 어느 기준으로 짜둬야 나중에 안 갈아엎는지 같은 것들이요. 안 해봤다고 부족한 게 아니라, 한 번 해보면 안목이 늘어나는 쪽에 가깝습니다.

그래서 출시 이력 한 줄은 직군별로 다른 걸 말해줍니다. 출시 경험이 있는 기획자라면 재미 요소뿐만 아니라 매출 그래프와 리뷰 평점을 읽고 다음 패치에 반영할 줄 안다는 뜻일 테고, 출시 경험이 있는 프로그래머라면 개발자 계정 등록, 버전 관리, 리젝트 대응, 광고를 염두에 둔 화면 설계, 폴드처럼 비율이 독특한 기기 대응, 저사양 기기 대응까지 한 번씩 겪어봤다는 뜻이죠.

 

다만, 출시 '만' 했다고 다 인정받는 건 아닐 수 있습니다

 

 

여기서 주의할 점이 하나 있습니다. 이력서에 스토어 링크 한 줄은 적혀 있지만, 등록만 해두고 광고는 한 번도 걸어보지 않았고, 리뷰도 읽어보지 않았고, 출시 이후 업데이트 기록이 없는 경우는 좀 생각을 해봐야 합니다.

출시 '여부'가 아니라 출시 '이후'를 묻기 때문입니다. 기획자에게는 어느 구간에서 사람들이 가장 많이 이탈했고 리뷰에서 반복되던 불만이 무엇이었으며 그래서 무엇을 바꿨는지를, 프로그래머에게는 출시 직후 올라온 크래시를 어떻게 잡았고 신규 콘텐츠를 넣을 때 기존 코드를 얼마나 뜯어야 했는지를 묻습니다. 결국 양쪽 모두 숫자든 로그든 받아보고 다음 걸 정해본 적이 있느냐는 질문입니다.

여기서 막히면 오히려 역효과가 나기도 합니다. 스스로 판단해서 한 게 아니라 출시를 누군가가 시켜서 한 번 해본 사람으로 읽힐 수 있거든요.

그래서, 하나 내보시죠

 

정리해보자면 회사가 출시 경험에서 보는 건 "게임을 만들 줄 아는가"가 아니라 "이 일을 끝까지 해본 적 있는가"에 가깝습니다.

다행히 이건 취업 전에도 증명할 수 있는 몇 안 되는 항목입니다. 구글 플레이든 스토브든 스팀이든, 플랫폼마다 조금씩 다르긴 해도 등록비와 몇 달의 시간이면 됩니다. 규모는 작아도 괜찮습니다. 플레이 타임 30분짜리 게임도 거쳐야 할 절차는 똑같이 거쳐야 스토어에 올라가니까요. 오히려 혼자 내보면 평소에 안 하던 직군의 일까지 한 번씩 건드리게 되는데, 그게 면접에서 할 이야기가 됩니다.

다만 혼자 하면 대부분 중간에서 멈춥니다. 마감을 강제해줄 사람이든 환경이든, 끝까지 밀어줄 장치를 하나 끼고 시작하시는 걸 추천드립니다. 개발 커뮤니티든 단톡방이든 학원이든 상관없습니다. 내가 어디까지 했는지, 무엇을 할 것인지 누군가에게 말해야 하는 자리면 됩니다.

만들어보고 싶었던 게임이 있었다면, 오늘 머릿속에 있는 걸 마인드맵으로 한 장 펼쳐보세요. 서서히 구체화 해나가면 됩니다.