개발과 라이브 옵스

글을 오랜만에 작성한다.

손가락 부상 이슈와 너무 바빠진 일정들 때문에 한동안 글을 작성하지 못했다.

 

나는 프로젝트 킥오프부터 라이브 옵스 경험까지 보유하고 있다.

그래서 오늘의 주제는 개발 과정에서 어떤 것이 중요하고 신경써야하는지

또한, 라이브 서비스에서는 어떤 것이 중요하고 필요한지에 대해 적어보려고 한다.

 

이 내용은 굉장히 주관적이며 결정권자의 선택과 프로젝트 방향성 및 운영 방식마다 다를 것이다.

그리고 포괄적이고 방대한 내용이기에 내가 중요하게 생각하고 실행했던 것 위주로

개발과 라이브 서비스, 각 3개씩 서술할 예정이다.

---

개발

개인적으로 [개발은 라이브를 하기 위해 나아가는 길]이라고 생각한다.

즉, 순항하는 라이브 서비스를 하기 위한 빌드 업을 쌓아가는 과정이다.

개발을 할 때는 이 프로젝트가 개발만 하고 끝낼 것이 아니기에

장기적인 라이브 서비스를 바탕으로 고민해야한다.

 

예를 들어 전투 컨텐츠를 만든다 했을 때

현재의 한정된 개발 시간 안에서 어떤 것을 우선적으로 개발하고

추후 어떤 시스템을 추가 및 연계할 수 있는지 고민하며 진행하는 것이다.

 

이러한 고민은 프로젝트를 이끄는 디렉터가 아니더라도 기획자 또한 생각을 가지고 진행해야한다.

라이브 서비스 뿐만이 아니라, 어떠한 컨텐츠나 시스템을 개발할 때는 확장성을 무조건 고려해야한다.

미래에 이것이 추가될까? 라이브 진행 중에는 어떤 것이든 추가될 수 있기에 열린 상태로 만들어야한다..

 

-  라이브를 위한 메인 코어 사이클

개발 중인 게임은 결국 장기적인 라이브 서비스를 위해 안정적인 구조가 필요하다.

그렇기에 이를 유지하려면 게임의 메인 코어 사이클이 필요하다 생각한다. 사이클의 예시를 들어보겠다.

위 사진은 스테이지 기반 게임이라고 가정하여 설계해봤다.

컨텐츠	컨텐츠 방식	유저 목표
메인 컨텐츠	스테이지 상승	스테이지 돌파
기간 반복 이벤트	반복 컨텐츠 클리어	사이드 컨텐츠 성장 재화 획득
사이드 컨텐츠	특정 목표 달성	메인 컨텐츠 재화 혹은 성장 도움

 

유저는 게임의 메인 컨텐츠인 스테이지를 더욱 높이 돌파하고 싶을 것이다.

하지만 메인 컨텐츠 성장에 도움이 되는 사이드 컨텐츠를 플레이 해야하는데

사이드 컨텐츠를 성장 시키기 위해서는 기간 반복 이벤트를 진행해야한다.

 

그렇다면 유저는 (메인 컨텐츠를 위해) 사이드 컨텐츠를 성장 시켜야 할 것이고,

기간 반복 이벤트를 진행할 것이다. 이 과정에서 과금 구조 설계를 설계하여 결제 발생 시킬 수 있다.

이는 주기적으로 반복되는 이벤트이기에 각별히 신경 쓰지 않아도 반복 결제가 발생할 것이다.

(기간 반복이기에 하드 리셋을 하며 초기화 시켜도 되고.. 이것은 게임 구조 설계에 따라 다를 것이다)

 

이어서, 사이드 컨텐츠 진행할 것이고 이 구간에 또 다른 과금 구조를 설계하여 결제를 유도할 수 있다.

단순하게 메인 컨텐츠 성장 하나만 존재하고 이곳에서 성장 및 과금 유도 설계가 아닌

여러 컨텐츠에서 성장 사이클을 만들어 다방면에서 결제를 발생시킬 수 있다.

 

이러한 구조가 라이브에 들어가서 개발이 된다면 늦을 것이다.

그렇기에 개발에서부터 차근차근 이러한 구조를 빌드업 쌓아가야 한다.

출시 후 라이브를 하다가 게임을 업데이트 하지 않아도 (수직적인 컨텐츠를 한동안 만들지 않아도)

반복적인 결제가 일어날 수 있도록 말이다. 이런 구조가 완벽히 돌아간다면 라이브 개발에 시간을 벌 수 있다.

이런 컨텐츠를 구성할 때는 미래의 개발 공수도 고려해야하는데, 많이 들지 않게해야한다.

예를 들어 데이터 추가만 하면 유저에게는 업데이트로 느껴지게끔 만들어야한다. 

 

 

-  미래를 고민한 유동적인 마일스톤

뜻은 맞지만 약간 의역되긴 했다

계획대로 되는 것은 없다. 인생도, 프로젝트도

하지만 나는 항상 팀원들에게 이런 말을 한다.

Slack에서 내가 말한 일부분 내용 발췌

 

계획이 있는 상태에서 상황 진행에 따라 유기적으로 변경되는 것과,

계획이 없는 상태에서 변경되는 것은 매우 큰 차이라고 생각한다.

계획이 없는 상태에서 급작스러운 개발 일정의 변화는 혼란만 가져올 수 있다.

 

2024년 12월 나는 2025년 상반기 업데이트 마일스톤을 계획한 후, 공지했다.

"다음에 뭐하지?"라는 생각을 하며 시간을 소비하는 것보다

정해진 계획 안에서 다음에 무엇을 할지 실무자들이 빠르게 판단할 수 있기 때문이다.

 

이 외에도 마일스톤 제작 및 공유는 단순히 우리가 [다음에 무엇을 할 것입니다]가 아니다.

우리가 어떤 목표로 향해 달려가는지, 어떤 것을 개발하고 완성본은 어떨 것인지

이러한 것들을 팀원들에게 계속해서 상기시키며 개발이 루즈해지지 않게 이끌어 낼 수 있다.

그리고 팀 리더에 대한 믿음 상승과 더불어 프로젝트의 장기 발판에 힘이 된다.

(번외로 프로젝트 현 상황과 미래를 윗 선(대표 등) 또는 타 팀에게 설명하기도 좋다)

 

앞서 말했지만 모든 것은 마음대로 되지 않고, 지표 또한 의도치 않게 흘러갈 수 있다.

그러한 일이 있다면 유동적으로 마일스톤을 바꿔줘야한다. 소프트런칭을 하고 있다고 예를 들어보자.

 

정식 출시는 3월이라는 가정 하에 1월에 업데이트를 계획 하에 진행을 하였다.

하지만 의도와 다르게 특정 지표가 떨어졌는데 계획된 2월 업데이트를 어떻게든 맞추겠다고

떨어진 지표를 무시하고 진행한다면 앞으로의 게임의 상황은 좋아지지 않을 것이다.

오히려 더 나빠질 수도 있으며, 정식 출시를 하더라도 망할 것이 분명하다.

그렇다면 기존의 마일스톤은 잠시 보류하고 게임의 개선을 우선해야한다.

계획을 빠르게 바꾸는 것이다. 마일스톤을 지키겠다고 욕심을 부리면 안된다.

결론은 청사진/큰 그림이 있는 상태에서 진행 하되,  빠른 판단을 통해 유기적으로 움직여야 한다.

 

- 우선 순위, 판단, 개발

게임을 개발하다보면 넣고싶은 것이 정말 많다. 이것도 저것도 재밌어 보이고 우리 게임에 넣고싶다.

하지만 시간은 한정적이고 인적 자원도 한정적일 것이다. 그렇다고 이러한 모든 것을 넣어보겠다고

크런치/야근을 하기에는 인생을 살아가는데 있어 우울과 건강 악화, 떨어진 사기가 뒤따른다.

 

그래서 앞서 언급한 마일스톤 기반으로 순차적인 개발이 필요하며

프로젝트를 리드하는 인원이 우선 순위와 결정을 빨리 해줘야한다.

 

자, 여기 1번과 2번이 있다.

처음 설명했던 메인 코어 사이클을 개발한다고 했을 때 개발 순서를 정해봐야 한다.

Q. 1번과 2번 중 순차적 개발을 하기 위해서 어떤 걸 먼저 해야할까?

A. 정답은 없다

프로젝트가 어떤 지표를 보고싶고, 어떤 것을 우선순위에 삼는지에 따라 달라지기 때문이다.

단순히 당장 다음달까지 다 넣고 싶어는 욕심일 것이고 그렇기에 판단을 잘 해야한다.

내가 말하고자 하는 바는 아래와 같다.

 

전체적인 로직 흐름을 테스트 해보고 싶다면 기간 반복 이벤트와 사이드 컨텐츠

모두 사이클만 돌아갈 수 있게 일부분만 개발하여 로직을 검증해볼 수 있을 것이다.

 

특정 컨텐츠의 확실한 의도와 지표를 확인해보고 싶다면 약간 우회해서 개발 할 수 있을 것이다.

예를 들면 사이드 컨텐츠를 완전히 개발하되 기간 반복 이벤트가 없기 때문에

메인 컨텐츠와 연계할 수 있는 임시 시스템을 만들어서 유저들이 사이드 컨텐츠를 잘 참여하는가

각종 지표는 어떻게 나오는가 확인이 가능하다.

 

기준점으로 삼을 만한 가장 좋은 것은 지표다.

리텐션이든, 결제율이든, 특정 컨텐츠의 리텐션이든.. 우리가 지금 어떤 지표가 필요하고

무엇을 올려야 하는지 등과 같이 지표로 움직이는게 가장 정확하다.

PC/콘솔에서는 이를 추적하고 개선하기 쉽지 않지만, 모바일 게임은 명확하다.

 

프로젝트를 맡으면서 어떤 것을 우선 순위로 개발해야 할지 정말 머리 아프게 고민을 많이 했다.

그러면서도 중간 중간 개선해야할 것, 테스트도 해야하기 때문에 어떻게 해야할지 혼란스러웠다.

 

하지만 한정적인 일정과 인적자원을 어떻게 효율적으로 분배하고,

우리 프로젝트는 어떤 것을 봐야하는지 이를 차근 차근 정하고 개발하며 순차적으로 개발해야한다.

 

이런식으로 우리 프로젝트가 어떤 정보와 지표가 필요한지 파악하고 팀을 리딩 하는 인원은

이것의 우선 순위 정하고 결정해야 한다.

 

막무가내로 하거나 마일스톤만 지키거나 한다면 지표도 게임도 모두 잃을 것이다.

---

라이브

라이브 서비스는 결국 생존의 시작이다.

그렇기에 많은 매출 그리고 오래 살아남기가 첫번째 목표이지 않을까 싶다.

 

개발 내외적으로 보면

라이브가 오래 될 수록 마케팅 효율은 감소할 것이고 DAU는 계속해서 떨어질 것이다.

라이브를 오래 이끌어가기 위해서는 유입되는 신규 유저 수도 중요하지만

장기 리텐션과 스택 유저의 매출이 중요하다.

이는 서비스 과정에서 다양한 전략을 통해 진행할 수 있다.

 

개발 팀적으로 보면

라이브 서비스 개발은 바쁘지만 나태해질 수 있다. 무슨 역설일까?

개발은 출시라는 목표가 있기에 빠른 호흡으로 지치지 않고 달릴 수 있다.

하지만, 라이브는 지속된 업데이트를 해야하고 성과가 나지 않는다면

지치기도 쉽고 팀 분위기 자체가 루즈 해질 가능성이 높다.

 

어떻게 매출을 만들고 오래 살아남을 수 있을까?

현재 라이브 서비스를 진행 중인 내 최대 고민이라고 볼 수 있다.

그리하여 라이브 서비스를 진행할 때 개발 내외적으로

내가 주로 챙기며 진행 중인 것들을 설명해보려고 한다.

 

- 꾸준한 개선과 A/B테스트

라이브 서비스를 하다보면 무심코 계속해서 신규 컨텐츠나 시스템을 추가하기 마련이다.

유저들은 게임의 후반으로 계속 향할 것이고 이러한 유저 속도를 맞추기 위해

대부분의 게임들이 다른 곳을 신경쓰지 못하고 계속해서 후반 컨텐츠만 개발한다. 

 

다만, 이렇게 후반만 잡고 가다보면 분명히 게임 일부분은 썩어가는 곳이 있는데

방치되며 게임의 지표 및 미래는 갈수록 안 좋아질 수 있다.

이것을 방지하기 위해 초반부 지표 개선, A/B테스트, 특정 지표 개선 등을

업데이트 일정 사이 사이마다 끼워넣으며 의식적, 습관적으로 진행해야한다.

내가 현재 운영하고 있는 팀은 약 한 달에 한 번 대형 업데이트를 하고

2주에 한번 A/B테스트 또는 개선 업데이트를 진행한다.

 

개선과 A/B 테스트를 통해 성과가 좋아진 경우에는

단순하게 게임을 좋게 만들 뿐만 아니라 팀 분위기도 좋게 만들 수 있다.

만약 대형 업데이트를 진행했는데 결과가 좋지 않을 경우, 팀이 낙담하게 될 수 있다.

"아 이렇게까지 힘들게 개발했는데 매출도 안오르고 이번 업데이트 망했네"와 같이 사기 저하가 일어난다.

 

하지만 중간 중간 진행되는 개선과 A/B 테스트를 통해 좋은 결과들을 받게 된다면 다시금 활력이 돌 수 있다.

"오 우리 게임 희망이 있네? 수치 잘 나오는데? 더 열심히 개발해야겠다"와 같이 말이다.

포기하지 않는 것이 중요하다. 당연히 100% 잘 되지는 않지만 모수가 쌓이고 경험이 쌓여가면

확률적으로 개선 및 A/B테스트 하는 것들이 좋은 결과를 불러일으킬 것이다.

 

꾸준한 개선과 A/B테스트가 이루어지려면 아래와 같은 행동들이 필요하다.

1. 게임 개발진들이 계속해서 자신의 게임을 플레이하며 UX적으로 좋지 않은 것들 파악이 필요하다.

2. 특정 지표가 좋지 않은 것들을 데이터 추적을 통해 매일, 매주 추세를 파악해야한다.

3. 개선과 A/B테스트를 하는데 거부감을 가지지 않고 개발 습관을 가져야한다.

4. CS(메일/리뷰)와 커뮤니티 등을 통해 유저들의 숨겨진 정보 공유, 불편함, 개선점 등을 파악한다. 

 

- 계속해서 후반 컨텐츠 제작

방금 언급한 꾸준한 개선과 A/B테스트에 대비하는 내용이다.

앞 뒤가 안맞는 것 아니냐고? 아니다. 둘 다 중요하기 때문에 별개의 문제이다.

결국 게임은 시간이 갈수록 유저들도 후반으로 많이 가게 된다.

 

후반으로 쭉쭉 나아가는 유저들을 스택 유저라고 지칭하겠다.

이 스택 유저들은 신규 유저 대비 고래인 경우엔 돈을 많이 쓰지만 반면에 많이 안 쓸 가능성이 높다.

이미 높아진 스펙으로 각종 재화들을 모으며 과금을 하지 않아도 충분히 게임을 즐길 수 있다.

그렇기에 후반 컨텐츠를 밀어넣으며 이 유저들이 게임의 재화를 모으지 못하고 계속 소비하게 유도해야한다.

 

단순하게 스테이지를 계속해서 추가하여 목표를 만들어주고 뚫을 수 있게 한다던가

특별한 관리를 하지 않아도 되는 반복적이지만 수직적인 신규 컨텐츠를 추가한다던가

게임마다 다르겠지만 다양한 방법이 있을 것이다.

 

매 업데이트마다 조금이라도 이런 수직적인 후반 컨텐츠들을 계속해서 밀어넣으며

스택 유저들이 떠나가지 않고, 신규 유저들을 불러모으며 게임의 DAU를 커지게 하며

게임의 매출과 파이를 전폭적으로 증가시켜야 한다.

 

물론 개발 공수가 너무 많아지면 안된다.

라이브 서비스를 할 때는 일정과 스펙 전략을 정말 잘 세워야한다. 어디 하나가 빵꾸 날 가능성이 높다.

현재 내가 맡은 프로젝트는 이들을 붙잡기 위해 매달 스테이지 1개씩 추가하며 다른 피처들을 제작하고 있다.

스펙이 조금 큰 컨텐츠라면 업데이트 2달 전부터 미리 물밑 작업을 시작한다.

선 기획을 마치고 아트들이 손이 빌 때 계속해서 준비 시키고, 때가 됐을 때 바로 개발이 진행 될 수 있게끔

 

- 시장 분석 및 반영

라이브 서비스를 하다보면 아이디어 고갈이 오는 시점이 된다.

게임의 수명이 2년이 넘어가거나 하면 웬만한 컨텐츠와 시스템들은 들어가 있다.

이러한 것은 단순히 2년이 넘지 않은 게임도 해당 될 수 있는 문제이다.

게임의 장르, 구조적으로 컨텐츠를 넣기 쉽지 않거나 이러한 능력이 부족할 수도 있다.

 

추가로 경쟁작들이 나올 수도 있고 그들에게 파이를 먹힐 수도 있다.

이 게임 시장에서 살아남는 것이 목적이기에 시장 분석(리서치)를 하고 이를 수용해야한다.

 

현재 나는 Data.ai를 사용하고 있는데 이를 통해 현재 글로벌 모바일 게임 시장에서

어떤 게임들이 순위권에 올라오고, 파이를 먹어가고 있는지 계속해서 확인한다.

현재 나는 미국 시장을 바라보고 운영하고 있는데

미국 쪽에서 순위를 치고 올라오는 게임들을 있는지 주기적으로 확인한다.

 

예를 들어, 맡은 게임이 캐주얼 장르에 미국 시장에 진입하거나 진입해서

라이브 서비스를 진행 중이라면 경쟁작들 또는 신규 작들을 계속해서 추적해야 한다.

 

이러한 게임들이 어떤 게임이고, 어떤 업데이트를 했는지, 그래서 얼마나 매출 순위가 올라왔는지

그렇게 시장을 리서치하다보면 눈에 띄는 특이점들이 있을 것이다.

 

신규 게임이 순위권에 치고 올라온다면 당장 그 게임을 다운 받아서 플레이 해야한다.

경쟁작들 또한 계속해서 플레이하며 대형 업데이트를 했을 때 어느정도의 순위 변화가 있는지 확인해야한다.

(물론 계속해서 하는 것은 힘들기에 우선 진득하게 하고 난다면 추후 그들의 변경점은 파악할 수 있다.)

 

그들이 무엇을, 어떻게 만들었는지 보고 특정한 컨텐츠 또는 시스템이 좋은 결과를 냈다는 것이 판단된다면

거두절미하고 그 시스템을 가공하여 우리 게임에 넣어보는 것이다.

(물론 여기서 시스템 가공을 할 때는 우리 게임에 알맞게 기획을 하여 넣어야 한다)

이렇게 하다보면 시장에서 우리 게임은 트렌디 함에 뒤쳐지지 않고 오래 생존할 수 있을 것이다.

---

마치며

이 얘기를 하다보면 정말 한도 끝도 없이 글이 길어지고 대학 논문이 될 수 있을 것 같아

내가 중요하게 생각하고, 실제로 행했던/행하는 것들 중에 핵심적인 부분을 3가지로 압축해봤다.

이 외에도 회사마다, 프로젝트마다, 사람마다 중요한 부분이 있을 것이고

노하우가 있을 것이다. 이 글은 정답은 아니고 내가 해보고 있는 시행착오 중에 하나 일 것이다.

 

지금 맡고 있는 프로젝트는 현재도 앞으로도 계속해서 고민을 하고 있지만

2024년 6월부터 시작해서 정말 많은 고민을 끝에 태어났다.

2025년 3월 말 글로벌 라이브 서비스를 시작했고 현재는 약 2달 째 진행 중이다.

내가 언급한 중요한 3가지를 정말 잘 지키며 개발을 진행 하고 있으며 유의미한 수치들을 내고 있다.

 

개발과 라이브 둘 다 해봤지만 어느 하나 쉬운 것이 없다.

남의 돈 버는거 자체가 쉽지 않지만

그럼에도 불구하고 앞으로 계속해서 고민하고, 생각하고, 앞으로 나아갈 것이다.