Book review: 리더, 절대로 바쁘지 마라

책 소개

리더 절대로 바쁘지 마라

감상

첫 인상

저자 소개를 보면 김종명님은 보증보험, 패션 업계에 리더로 일하셨고 업계에서 어떻게 일해왔는지를 알 수 있는 내용으로 각색하셨네 하는 느낌을 받았습니다.
실제 차장님, CEO 정도의 연령대의 이야기로 보고 뉘앙스를 이해해보았어요.
IT 업계쪽 리더보다는 역사가 있는 업계의 리더십 관련 서적으로 추천하면 좋을 것 같은 맛이긴 합니다.
(제가 보기엔 약간은 올드한 표현이나 상황들이 있었지만 고전을 읽는 느낌으로 읽었어요 😃)

눈치보는 리더가 성공한다, 공포의 시간을 견뎌라

책의 시작 쯤에 “눈치보는 리더가 성공한다”로 시작해서 팀원들이 어떤 상황인지, 어떤 부분에서 어려워하는지를 알고 지지해줄 수 있는 등, 리더는 살피는 사람이라고 이야기합니다.
그 외에도 팀원들이 스스로 잘할 수 있다는 것을 믿어야 팀원들이 잘 해낸다는 것과 팀의 설장을 위해 공포의 시간을 견뎌야하는 것도 좋은 이야기였습니다.

종종 리드로 일하면서 “저건 저렇게 하는게 맞을까?” 또는 “나라면…” 하는 생각을 하곤하는데,
처음에 방향성과 목표/목적을 팀원과 잘 맞추고 이후의 일은 팀원이 알아서 잘 할 수 있도록 지켜보고 장애물을 치우는 일을 하라는 이야기였습니다.

공포의 시간이라는 표현이 재미있었네요.
리더에게는 팀원을 지켜보면서 잘하고 있나? 저 방식이 괜찮나? 하는 생각도 들고 때때로 팀원들이 잘 할 수 있음에도 참지 못하고 끼어드는 경우도 있을 것이라 생각합니다.
그 공포의 시간을 잘 견디고 팀원들이 잘 나아갈 수 있도록 돕는 일을 해야한다고 이해했는데 돕는 것도 견디지 못하고 끼어드는 것이 아닐까? 싶은 생각도 들었습니다.

아무튼 팀원들의 상태, 상황을 잘 이해하고 팀의 성과를 낼 수 있는 방법은 눈치를 잘봐야한다 -> 센스가 좋아야한다 정도로 이해했습니다.

조직은 리더의 고민을 먹고 자란다 (시스템을 연구하라)

조직에서 일어나는 일들이 왜 그렇게 발생했는지, 어떤 부분을 개선하면 좋을지 등은 팀 모두가 고민하면 좋겠지만
리더가 먼저 고민을 하고 개선에 앞장서야한다는 내용입니다. 문제가 발생하면 사람에게 잘못을 이야기하기보다 시스템을 개선하고 연구해야한다는 것.

결국 조직이 어떻게 동작해야하는지, 팀의 일이 어떻게 동작해야하는지를 같이 고민하되 리더가 앞서서 고민해야한다고 이해했습니다.
이렇게 고민을 많이 할 수 있으려면 리더의 일은 팀원 업무 관심갖기, 팀의 성과 고민, 상위 조직 목표 고민/방향 맞추기 등을 많이 해야겠구나 싶습니다.
책 제목에 바쁘지마라고 했으나 실무가 많은 리더로 살아가고 있어서 현실성이 떨어진다는 생각도 드네요.
다만 바쁘게 자기 일만 하는 것은 줄이고 팀이 시너지를 낼 수 있는, 팀 에너지의 총합보다 더 큰 결과를 만들어낼 수 있는 시스템을 고민해야한다고 항상 생각은 합니다.
(행동이 생각을 따라가지 못해서 문제죠 ㅎㅎ 😂)

불평에 감사하라. 눈치보는 리더가 성공한다

다시 한번 눈치보는 리더가 성공한다고 수미상관으로 마무리합니다.
책의 예시로는 사업쪽 담당자가 보는 시야에서 비판하는 내용으로 디자인 실장이 그 비판을 수용하고 반영하는 이야기가 있었습니다.
약간 허구가 있는게 다른 팀의 실장님에게 비판적인 이야기를 쉽게 할 수 있을까? 싶긴했지만 이야기 뒤에 “실장님이 피드백을 잘 듣는다”는 설정이 있지 않을까 싶긴했습니다.

비판, 피드백 등을 잘 수용하는 리더, 눈치보는 리더가 성공한다는 이야기네요.
비판을 하지 않는 조직, 피드백이 없고 소통이 없는 조직은 목표를 달성하거나 성공하기 힘들겠죠. (물론 팀 목표가 무엇이냐에 따라 다를 수 있겠지만요)

마무리

김장수의 디자인 브랜드 런칭 TF에서 일어나는 이야기로 리더가 고민하고 생각해야할 것들을 이야기 형식으로 재미있게 다뤘습니다.
바쁘지 말아야한다는 제목을 해석해보자면 자기일에만 바쁘게 살지말고 팀을 생각하는 시간을 잘 지켜야한다 정도로 볼 수 있을 것 같네요.
사실 팀 생각하는 것도 바쁜 일에 한몫을 하는 것 같기도 한데요. 어쨌든 리더, 생각할 시간 없이 바삐 살지 말고 여유 시간 잘 챙겨야한다고 해석해보며 마무리해봅니다.

NDC 발표 리뷰: NDC2019 5년차 모바일 게임 생존기

NDC 영상

NDC: 〈크루세이더 퀘스트〉 5년차 모바일 게임 생존기
Video: https://www.youtube.com/watch?v=Pi3LBWu-4Es

세션 설명:
게임이 생존하려면 무엇이 필요할까요? 게임의 생존에 도움이 되는 방법은 없을까요?
본 세션에선 이 질문에 대해 답을 시도합니다. 그리고, 이러한 답이 모바일게임 〈크루세이더 퀘스트〉의 개발 및 서비스 과정에 적용된 사례를 공유합니다.
오래된 개발 환경의 개선, 유저분들의 실망을 만회해야하는 상황, 개발 프로세스의 문제 등 다양한 이슈와 마주한 분들께 조금이라도 도움이 되는 내용이길 희망합니다.

리뷰

23년에 19년 발표 자료를 보고 리뷰하는게 뭔가 싶을 수 있지만.. 😁
라이브 서비스하는 조직의 이야기는 굉장히 귀하기에 지난번에 보고 리뷰를 남겨보고 싶었습니다

강연에서 이야기한 내용의 요약

무려 40분짜리 발표여서 요약을 한번 쓱 해보겠습니다.
아래 참고기사에서 잘 요약해준 내용도 있으니 참고해보면 좋을 것 같네요.

강연 노트

강연 목표: “더 다양한 게임이 오래도록 생존하여 서로 의사결정의 길잡이가 되어주면 좋겠다!”

  • 게임의 생존 조건, 생존 사례, 생존 전략을 다뤄봅니다
  • 넓은 범위의 생존 = 유저가 게임을 플레이할 수 있음
  • 좁은 범위의 생존 = 지속 가능성을 기준으로 손익분기점(break-even point, BEP)을 넘겨야 생존한 게임

생존 조건 = 이용자, 개발팀, 수익

  • 이용자: 유입은 어렵고, 이탈은 쉽게 이뤄짐 / 개발팀: 프로젝트 매력도 등등.. / 수익: BM 설계 등등..
  • 게임 특징: 2019년 당시 5년차 모바일 게임. 글로벌 서비스 (23년 기준 9년차..)
  • 이용자 이탈 🔥
    • 1개월 없데이트, 업데이트한 내용 불만족, 부족한 이벤트, 반복되는 연장점검과 긴급점검, 앱 용량, 게임 정보 취득 어려움, 버그
      • Action: 장기 서비스 유지를 위해 이용자 이탈 개선을 우선순위로 개발 목표 설정
      • Result: 이탈 위험이 높은 유저 지표가 개선되었음
    • 대규모 업데이트 후 이용자 수 지속적으로 하락
      • 게임 피로도 상승, 콘텐츠에 대한 피로도가 높은 상태였음
      • Action: 이용자 수 하락 원인 개선 - 편의성 업데이트, 보상 개선
      • Result: DAU 하락세 방어
  • 개발팀 HP 경고(피로도 누적) 🔥
    • 개발팀 추가 근무량이 많아 피로 스트레스가 많았음. 실제 업무 시간 파악도 어려웠음
    • 개발 계획 변동, 일정 부족, 계약으로 인해 고정된 출시 목표, 밤샘 테스트, 서버 불안정
    • Action: 개발환경 개선 → Unity 4 → 5 업그레이드
      • 서버 최적화를 최우선 순위로 개발 일정 조정
      • 근본적인 버그 대응을 위해 엔진 버전 업데이트
    • Action: 추가근무 시간 기록, 개발 프로세스 개선 - 병목 지점 파악 후 우선순위로 개선
      • 개발 진행상황을 누구나 쉽게 알 수 있도록 시각화
      • Result: 추가 근무 시간 62% 감소. 콘텐츠 업데이트도 안정적으로 진행
  • 수익화 - 구매자 수(PU, Pay User) 감소세 🔥
    • 게임에 대한 애정 감소, 구매 동기 저하, 상품 매력 감소 등
    • Action: 좋은 보상(애정을 회복할 수 있도록 이벤트), 콜라보, 상점 UX 개선 등

생존 전략 = 포지셔닝, 병목 현상 제거, 끝맺기

  • 포지셔닝 - 어떤 게임으로 인식되고 싶은지 명확하게 정의. 우선순위를 설정하기 위해서
  • 병목 제거 - 리소스를 효과적으로 사용하기 위해서. 포스트잇 활용해서 시각화하고 개선해봄
  • 끝맺기 - 체크리스트를 정리하고 마지막까지 확인해야함. 회의 마지막에 리캡하고 공유함
  • 실무에 도입할때는 팀이 받아들일 준비가 되었을 때 실무에 적용하자
  • 모바일 게임의 생존률(좁은 범위 생존)은 40% 정도
  • 의사결정이 큰 영향을 주고 있으니 생존 조건의 적신호에서 잘 대응해나가야 한다

리뷰 소감

현재 라이브 중인 게임의 프로덕션 과정, 이슈 관리 등을 이야기하는 것이 쉽지 않았을텐데 이런 이야기를 들을 수 있게되어서 좋았던 것 같습니다.
생각해보면 다른 소프트웨어 개발도 다 마찬가지이지만 게임 개발에 있어서 많은 난관이 있는데 어떤 기준으로 해결해나갔는지 알 수 있어서 좋았습니다.

역시 서비스에서는 이탈 개선이 반드시 이뤄져야하고 개발팀의 리텐션도 중요하고 돈도 잘 벌어야하고 쉽지 않네요 😇

Product Plan vs Release Plan 글을 보고

원문

https://www.aha.io/blog/the-product-plan-vs-the-release-plan

Product Plan vs Release Plan?

제목을 번역해보면 “제품 계획 vs 출시 계획”으로 볼 수 있겠네요
처음에 이 글을 봤을 때, 두 계획이 다른 것은 이미 알고 있는데 어떻게 다른가에 대해 깊게 고민한적은 없었던 것 같습니다.

위 글에서 두 계획에 대해 정의한 것이 인상깊어 공부 겸 글 내용을 정리해보았습니다.

제품 계획은 제품의 전략적 방향을 정의하는 반면 출시 계획은 비전을 달성하는 데 필요한 작업을 정의합니다.”

두 계획 모두 중요하지만 다른 것을 정의하고 있습니다.
제품 계획은 왜(Why) 이것을 만들고 있는지, 우리는 무엇(What) 을 성취하려고 하는지 답을 줍니다.
출시 계획은 정확히 무엇(What) 을 빌드해야하는지, 언제(When) 만들 것인지, 제품 경험을 어떻게(How) 제공할 것인지를 정의합니다.

6하 원칙으로 정리하는게 깔끔하긴 하네요.
제품 계획에는 왜 라는 프로덕트 목표 설정이 중요한 것 같고
출시 계획에는 언제 어떻게 무엇을 전달 또는 배포할 수 있을지 정의하는 것이 중요하겠네요.
Who, Where은 때에 따라 제품 계획에 들어갈 수 있을 것 같습니다. 😁

목표(Goal) 관점

제품 계획 목표: 제품의 방향성을 전달하는 것. 전략 및 비즈니스 목표를 기반으로 제품이 비즈니스 가치를 제공하는 방법을 보여줍니다.

출시 계획 목표: 제품 팀이 수행할 작업에 대해 책임을 지도록 하는 것. 작업의 세부 사항을 분명히 하고 완료해야하는 작업 단계를 강조합니다.

목표 관점에서 각 계획이 가지는 목표는 성격이 다른 것은 누구나 알 수 있겠지만 저는 상위 방향성 vs 상위 방향성이 동작하게 하는 워크플로우, 프로세스 등의 집합체 정도로 이해했습니다.
여기서 제 PM 업무를 떠올려보면 2가지 계획에 모두 기여를 해야하지만 출시 계획을 잡고 개발팀과 헉헉하느라 제품 계획에는 신경쓰지 못하는 것 같습니다. 😥

끝이 없네 끝이 없어..

매 주기마다 개발부서들과 개발한 콘텐츠 업데이트와 라이브 이슈 대응의 연속..

이니셔티브(initiative) 관점

제품 계획: 향후 6개월에서 1년 동안 주요 테마, 초점 영역 및 기능을 나타내는 이니셔티브를 제시합니다.

출시 계획 : 전략적 이니셔티브가 존재한다고 가정하고 팀에 집중하는데 중점을 둡니다.
출시 계획은 일상적인 성공을 위한 명확한 경로를 제시합니다. 출시 계획의 이니셔티브는 동기 부여, 책임에 관한 것입니다.

이 글에서 말하는 이니셔티브 개념은 목표를 달성하기 위한 액션 아이템 또는 액션 아이템들을 묶을 수 있는 계획이라고도 볼 수 있을 것 같습니다.
액션 아이템과 목표를 잘 버무린 계획의 느낌이네요.
OKR에서는 이니셔티브를 Key Result를 달성하기 위한 액션아이템, 어떻게 달성할지에 대한 것으로 정의하고 사용하는 케이스를 볼 수 있었습니다.

사실 사회에서 말하는 “이니셔티브”는 번역으로는 주도권, 주장이 되는 위치에서 이끌거나 지도할 수 있는 권리로 이야기하니 “권한”의 성격을 띄고 있습니다.
기업에서 특정 이니셔티브 그룹에 가입하면서 이야기하는 “이니셔티브”는 계획에 더 가깝습니다. 특정 문제를 해결하기 위한 그룹 정도로 이해할 수 있을 것 같네요.

청중(Audience) 관점

제품 계획: 외부 또는 내부 전략 로드맵으로 시각화할 수 있습니다. 고객을 위해 기대할 수 있는 새로운 기능 또는 개선 사항의 주요 영역을 제시합니다.

츨시 계획: 내부 제품 팀 및 기타 교차 기능 기여자를 위한 것. 향후 작업을 계획하고 해당 작업의 세부 정보를 추적하는 데 도움이 됩니다.

여기서 청중은 이 계획을 듣는 사람들을 의미하는 것 같습니다.
제품 계획은 외부에 공유하는 러프한 로드맵 이런 것으로 바꿔서 사용할 수 있는 것,
출시 계획은 내부 프로덕션 프로세스 문서, 업무 가이드가 될 것 같네요.

타임라인(Timeline) 관점

제품 계획: 장기간에 걸친 전략적 목표와 이니셔티브를 제시합니다. 소프트웨어 회사의 경우 1년이 일반적입니다.
출시 계획: 기능 배포 또는 주요 출시로 이어지는 특정 작업 단계를 추적합니다. 30, 60, 90일 단위인 경우가 많습니다.

제품 계획은 타임라인으로 보면 1년 계획 + 더 큰 차원의 계획도 있을 수 있겠다 싶습니다.
예를 들면, 게임의 핵심 재미를 정의하고 어떻게 그 재미를 더 키울 수 있을까를 계획하거나 다른 맛을 곁들이거나 하는 등의 방향 설정이 있을 것 같아요.

출시 계획은 단순히 생각하면 업데이트 주기를 말할 수 있겠습니다. 그 주기에 맞춰 필요한 일들의 타임라인을 정리하고 프로세스화 한 것을 출시 계획으로 볼 수 있겠죠.

마무리

글 마지막에는 “How do you use product plans and release plans in your work?” 라고 질문을 해주었는데 글을 읽다보니 저는 제품 계획이 잘 이뤄질 수 있도록 출시 계획을 관리하고 있었구나 싶었습니다.

Being responsible for a product plan and a release plan challenges product managers to think about every element of delivering a Complete Product Experience. It is a good way to encourage both big and small thinking.

이런 말을 글 마지막에 크게 달아뒀는데 각 계획을 정의하고 그 정의에 맞춰 일을 정리해나가는 것이 좋은 경험이 되는 것 같습니다.
어떤 게임 개발사는 패키지 형태로 한번에 빡 출시하고, 어떤 개발사는 얼리억세스부터 지속적인 업데이트를 통해 출시하고 여러 방법이 있으니 각자의 계획이 다 다르겠죠

너는 다 계획이 있구나! - 기생충

어쨌든 각자의 계획이 다 있는 것 아니겠습니까 😁

우리는 어떤 계획을 가지고 살고 있는지, 2개의 계획을 분리해서 보자면 어떻게 정의하고 있는지 생각해볼 수 있는 시간이었어서 재미있는 글이었습니다.
다른 재미있는 글들도 있으니 나중에 보고 또 공부 겸 포스트해보겠습니다.

이슈 트래커(Issue Tracker Jira)에 잘 접근하는 방법 고민 #1

방법 연구 목적

Jira에 접근해서 자신이 해야하는 일이 무엇인지 확인하기 어려워하는 분들이나 더 편하게 접근할 수 있는 방법이 있을까 하는 생각이 들었습니다. (갑자기?)
궁극적인 목적은 작업자들이 자신이 해야하는 일을 잘, 빠르고 편리하게 확인하고 일할 수 있는 것이죠.
나에게 할당된 일을 바로 알 수 있는 방법이 있다면 제일 좋을 것 같아 각 작업자의 작업 흐름, 작업 프로그램 등을 확인해봅니다.

(TMI) 이 글을 정리하게된 계기

https://youtu.be/xlV82Q-ZmAA

2021년에 OKKYCON에서 김영재님이 발표해주셨던 프로덕트 조직의 생산성 높이기 내용에 감명을 받아서 정리하게되었습니다.
(작년에 본 영상인데 왜 이제야? 라는 생각도 들지만 최근에 동료분들이 내가 어떤 일을 해야하는지에 대해 편하게 접근할 수 있다면 Jira와 친해지고 더 잘 쓸 수 있게되지 않을까했습니다. 😁)

영상에서는 “개발자가 이슈 트래커를 잘 쓴다는 기준”에 대해 다뤄주셨는데요.

  • 이슈 트래커 웹에서 적게 열어볼 수록 잘쓰는 것
  • 절대 상태를 손으로 바꾸지 않는 것 → (핵심) 커밋 메세지로 상태 변화가 가능한 것

작업

게임 개발(PUBG 기준)에 있어서 작업자 카테고리 및 작업 프로그램을 분류해보겠습니다.
일단 PUBG 개발은 Unreal Engine Editor, Perforce/Git 으로 작업하고 소스를 관리하고 있습니다.

엔지니어 Engineer

(코딩 + 블루프린트 작업) Visual Studio (Visual Studio Code), Unreal Engine Editor

  • 코딩 후 Git 히스토리 정리를 위해 SourceTree, Fork, GitKraken 등 Git GUI를 사용하는 경우도 있음
  • PUBG는 소스 컨트롤 시스템을 Perforce와 Gitlab(Git)을 쓰고 있음

아티스트 Artist

(애셋 작업) Maya, 3D Max …, Unreal Engine Editor

  • 컨셉 아티스트…의 경우 어도비 포토샵 또는 일러스트레이터?
  • 어쨌든 실제 게임에 적용되는 애셋들은 언리얼 에디터 통해서 반영되어야하니 커밋 내용을 작성하고 푸시하는 곳은 언리얼 에디터? Perforce?
  • (어디가 편할지는 인터뷰와 고민이 필요합니다.)

기획자 Designer

(데이터 작업 + 블루프린트 작업 등) Excel, Unreal Engine Editor

  • 데이터 작업을 엑셀로만 하지는 않고 언리얼 에디터에서 그래프를 수정하는 등 여러 작업이 있음
  • 블루프린트에 입력해야하는 데이터, 코드에서 가져다 쓰는 데이터 등 에디터와 에디터 밖에서 작업 가능함

작업 프로그램과 Jira 연결

각 작업자분들이 작업을 하는 프로그램에서 Jira 이슈를 볼 수 있는 방법이 있는지부터 확인을 해봐야겠죠?
작업 프로그램 하나하나 관련 플러그인이 있는지 확인해보겠습니다.

작업 프로그램Jira 연결 프로그램특징/코멘트
Visual StudioVSJira⚠️ VSJira
- VS 2019에서 동작하지 않는다는 평가가 많네요. (동작하는지 확인 필요)
Visual StudioCodeStream-vs✅ CodeStream-vs
- New Relic에서 만든 플러그인으로 VS 2019 버전에서 동작 가능하고 지금도 유지보수가 이뤄지고 있는 플러그인
- 내 이슈를 확인하고 이슈를 바로 만들 수도 있습니다.
- Jira 외에도 다른 서비스 연결이 강력하네요. (슬랙, 팀즈, 트렐로 등)
Visual Studio CodeJira and Bitbucket✅ Jira and Bitbucket
- 아틀라시안에서 만든 플러그인으로 유지보수 및 여러가지 Jira 기능이 보장되어있습니다.
- 플러그인의 형태로 VS Code에 설치 후 서버 설정 및 계정 설정
- VS Code에서 바로 이슈 내용을 바로 볼 수 있습니다
- VS Code 내에서 필터를 구성해서 내가 보려는 이슈만 골라서 볼 수도 있고요
Unreal Engine EditorBug-reporter
❌ Bug tracker
❓ 언리얼 엔진 플러그인으로 있는 것을 찾기 어렵네요
- ❌ Bug-reporter 플러그인은 있는데 $30로 비용이…
- ❌ Bug Tracker 플러그인은 ₩73590… 꽤 비싸네요. 다만 Trello만 지원해서 패스.
없어서 플러그인 만들어서 써야하는 것 같습니다. (다른 회사들도 그냥 만들어쓰는걸까요..?)
Perforce(P4V)❌ / ⚠️ jira-perforce 연결
- P4V에서 바로 Jira 연결하는 플러그인은 따로 없고 커스텀 툴을 개발해서 넣어야합니다.
- HTML Tool 또는 Custom Tool을 따로 만들어서 적용해야합니다.
- 다른 서비스들에 연결은 할 수 있는데 추가로 구매하고 설정해야하는게 큰일이네요.

고민 1차 정리

일단 각 작업 프로그램별로 Jira 연결 프로그램을 확인해보았는데요.
Visual Studio쪽은 있는데 언리얼 에디터, 퍼포스 쪽은 제대로된 플러그인을 확인할 수 없었네요.

공교롭게도 게임 개발 관련 프로그램에는 Jira 연결 플러그인을 찾기 어려웠… (게임 개발과 이슈 트래커 툴은 친하지 않은 관계일까 싶기도했지만 아니겠죠..?)
물론 언리얼 에디터 쪽에 관련 플러그인이 있지만 Jira를 딱 잘 쓸 수 있게 만들어진 것은 아니어서 애매하다고 생각했습니다.

내부 동료 개발자분들은 어떻게 Jira를 사용하고 있는지, 어떤 방법으로 커밋(submit)할때 jira 이슈를 찾아서 보고 있는지 인터뷰해보고 개선 각을 봐야겠습니다.
개선 방식은 #2 포스트로 찾아올게요 😃

Perforce를 사용하는 회사, 사용자는 얼마나 될까?

시작하며: 회사에서 Perforce Helix core를 사용하면서 드는 생각들

21년에 퍼포스 기능에 대한 포스트를 한 10개 안되게 만들어보면서 회사 내에도 그렇고 외부에도 그렇고 참 자료가 없다는 것을 느낍니다.
다들 퍼포스를 알게 모르게 쓰고 있는 것일까? 아니면 내부 자료로만 정리되고 있는걸까 하기도 하구요.

이참에 퍼포스를 사용하는 곳과 검색 트렌드를 좀 확인해보고 자료가 없다면 정리해서 조금씩 만들어보고자 합니다.
(이 글에서 말하는 퍼포스는 버전 관리 프로그램인 Perforce Helix Core를 의미합니다.)

퍼포스 사용하는 회사들

저는 주로 퍼포스는 게임 개발 회사에서 사용한다고 알고 있었습니다. 에픽에서 사용하는 것으로 알고있긴해요.
(엔진 코드가 github에는 올라가 있지만 Perforce를 사용하고 있다고 들었습니다.)

퍼포스를 사용하고 있는 회사는 여기서 확인할 수 있었습니다.
https://www.perforce.com/customers

Perforce customers

Industry를 보니 당연히 게임 개발이 있고 다른 카테고리로는 이커머스, 자동차 회사, 우주항공 쪽도 있습니다.
(NASA, 포르쉐도 있네요. 😈)
각 회사에서 사용하는 프로그램은 조금씩 다르긴합니다. 각 회사에서 사용하는 프로그램을 보면,
Helix Core / Hansoft / Helix QAC 요렇게 나눠서 보여주고 있습니다.

각 프로그램에 대한 자세한 내용은 따로 다루지 않고 넘어가겠습니다.
저는 Helix Core를 어디서 얼마나 어떻게 쓰고 있는지가 궁금해서요. 😸

유비소프트(Ubisoft)

Featured Customer로 되어있는 유비소프트 케이스 스터디를 좀 보겠습니다.
https://www.perforce.com/case-studies/vcs/ubisoft

  • 2000명 이상의 개발자가 소스코드와 작업 애셋들(그래픽, 애니메이션 등)을 저장하고 있음
  • API 용이성, 유연성 / 이상적인 브랜치 방식 / 프록시 서버 효율성
  • 개발 환경
    • 개발자: 2000명
    • 파일 수: 5TB(24,070,195개 파일)
    • 변경 수: 166,642,479 리비전 (337GB 메타데이터)
  • 아티스트와 모델러는 P4V와 P4GT 그래픽 도구용 플러그인을 이용하여 작업하기도 했음
  • P4Report를 사용해서 애셋과 코드에 대한 리포트 생성을 단순화했음
    • 따로 확인해보니 p4 report 명령어는 없고 p4 files, p4 changes 등의 명령어로 정보를 관리한 것으로 보입니다
  • 개발 속도를 높이기 위해 자주 사용하는 파일 캐시를 제공하고자 Perforce Proxy(P4P) 활용
  • 많은 사내 도구가 개발되면서 소스 제어와 상호작용할 수 있는 유연한 API가 필요했음
  • API가 유연해서 유비소프트 내부 도구와 통합할 수 있어서 생산성이 향상되었음

여기도 오래동안 게임을 개발한 곳이어서 개발자 수, 파일 수가 어마어마하네요.
퍼포스를 사용한 이유는 브랜치 방식도 방식인데 내부 개발 도구와 API 연동도 몫을 했나봅니다.
내부 생산성을 위해 툴 개발 및 시스템 구축했다는 것이 인상깊었습니다.

CD Projekt Red

다른 게임사인 CD Projekt Red 포스트도 한번 보겠습니다.
https://www.perforce.com/case-studies/vcs/cd-projekt-red

위쳐 개발하면서 사용했던 이야기를 써두었네요. (사이버펑크 개발할때도 썼겠죠 😸)

  • 개발환경
    • 개발자: 450명 이상
    • 데이터베이스 크기: 205GB
    • 저장소 크기: 10TB
    • 파일 수: 1500만개
  • 매일 최대 50-60GB 대용량 데이터 작업 진행
    • 큰 파일을 작업하고 동기화하는데에 적합하다고 보고 있음
  • 빌드 자동화: Helix Core와 빌드 시스템을 통합하여 변경 사항을 모니터링하고 테스트, 컴파일함
    • 수정된 내역이 포함된 빌드가 완료되면 버그를 자동으로 닫음

앞서 보았던 유비소프트보다는 개발자 수가 적지만 저장소 크기와 파일 수는 꽤나 큽니다.
파일수에 비해 저장소 크기가 큰 것을 보니 글에 있는 내용대로 파일이 큰 작업들을 다 저장소에 올리는 것으로 보입니다.
작업물에 대한 공유를 모두 퍼포스를 통해서 하는 것 같네요.
(다른 클라우드 서비스보다 퍼포스를 사용하는게 아닐까 싶기도하구요.)

그외의 회사들

Helix Core 외에 다른 게임 회사들은 어떤 것을 쓰고 있나 보았습니다.

  • EA, Capcom은 Hansoft를 이용해서 작업을 관리하고 있는 것 같습니다
  • Epic Games는 Helix Core를 사용하고 있긴하지만 따로 포스트를 올리지는 않았네요
  • 영상으로 사례를 올린 곳은 영상의 길이가 짧아서 딱히 알 수 있는 것이 별로 없었습니다

구글 검색 트렌드

퍼포스에서 소개한 회사의 이야기는 들어보았으니 구글에서 사용자들이 얼마나 검색하는지를 알아보겠습니다.
Perforce, SVN, Git으로 확인해보니..

Git이 압도적이어서 Perforce가 아예 바닥에 있어서 보이지를 않네요. Perforce만 두고 기간을 늘려서 보겠습니다.

2000년 초반까지만해도 꽤 많은 검색량이 있었는데 2010년들어서는 많이 떨어졌네요.
나라별로는 세인트헬레나, 대한민국, 이스라엘, 중국, 캐나다, 미국 순으로 많이 검색했네요.

검색량만 봤을때, 지금은 대부분의 회사에서는 소스관리 프로그램 Git을 주로 쓰는 것 같고
Perforce는 게임 개발 회사에서는 몇몇 큰 회사에서 쓰고 있는 것 같습니다.

생각 마무리

어디 퍼포스 쓰는 회사 얼마나 되는지 살짝 맛을 보았습니다. 아무래도 게임 개발에 있어서 큰 애셋 파일들의 동기화가 시간이 걸리는데 그것에 대한 강점이 있고 작업물의 통합에도 편리함이 있으니 사용하는 것 같습니다.
슬쩍 확인해보니 국내 게임 회사들도 꽤나 쓰고 있는 것 같네요. (N사, S사, P사 등)
https://www.perforce.com/support/self-service-resources/documentation 퍼포스 가이드 문서도 이것저것 있는데 아무래도 영어이기도하고 활용하기 어렵게 작성되어있기도해서 조금씩 공부하면서 포스트 해볼 것 같습니다.
가이드 문서가 부족해도 회사에서 쓰고 있는 시스템이니 생산성을 올릴 수 있는 방법도 고민해야하고 가이드 문서들도 좀 챙겨보고 그래야겠죠. ㅎㅎ
이만 생각 포스트 마치겠습니다.