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 퍼포스 가이드 문서도 이것저것 있는데 아무래도 영어이기도하고 활용하기 어렵게 작성되어있기도해서 조금씩 공부하면서 포스트 해볼 것 같습니다.
가이드 문서가 부족해도 회사에서 쓰고 있는 시스템이니 생산성을 올릴 수 있는 방법도 고민해야하고 가이드 문서들도 좀 챙겨보고 그래야겠죠. ㅎㅎ
이만 생각 포스트 마치겠습니다.

게임 개발에 대한 고찰 1

게임 개발이란 뭘까?

게임 개발 PM으로 일을 하면서 게임 개발은 뭘까하는 고민을 종종합니다.
다른 IT 서비스 종류와 다른 업과도 비교해서 생각하기도 하는데요.

제가 생각하는 다른 서비스들의 개발할 때의 예상되는 고민은…

  • 보통 앱 개발이나 웹 서비스 개발은 어떤 특징을 가지고 있지?
    • 문제를 정의하고 문제에 대해 서비스로 어떻게 해결할 것인지 접근하지 않을까?
    • 문제를 해결하지만 최종적으로는 사용자에 집중하여 해결에 접근하지 않을까?
  • 이커머스(e-commerce)는 어떤 특징을 가지고 있지?
    • 구매자, 판매자를 연결해줘야겠지
    • 구매자 경험, 판매자 경험도 중요하다. 두 종류의 사용자가 겪는 문제도 해결해야겠지
    • 요즘은 물류, 배송에 대한 고민도 더 많아지지 않았을까

잠깐잠깐 생각했던 내용을 정리해본 내용이어서 정확하지 않거나 막연한 내용일 수 있습니다. :)

이런 서비스들과 비교했을 때 게임의 핵심 고민은 어떤 재미를 줄 수 있을까인 것 같습니다.

  • 내가(우리가) 좋아하는 게임 장르를 개발한다!
    • MMORPG를 만든다! 협동 콘텐츠! 스토리!
    • 나는 정통 FPS!
  • 많은 사람들이 좋아하는 게임 콘텐츠를 개발한다!
    • 요즘 뜨는 게임 장르는 배틀로얄이니 이거랑 성장 요소를 끼워볼까?

게임 개발은 어떤 문제를 해결한다, 페인 포인트(Pain Point)를 해결한다 보다
재미있는 콘텐츠를 만드는 것이 중요하다고 생각합니다.
다만 그런 재미는 콘텐츠의 완성도 뿐만 아니라 사용자들의 게임플레이 성향, 취향 등에 따라 달라질 수 있다고 생각해요.

이런 고민을 하다가 얼핏 생각해보니 게임에서의 **”재미”**는 요식업이랑 **”맛”**이랑 비슷한 느낌이 있었습니다.
그러다가 한번 비슷한 요소들을 묶어서 그려보자는 생각이 들어서 아래와 같은 그래프를 그려보게되었어요.
(영화는 게임과 콘텐츠 산업 구조가 비슷하지 않을까해서 같이 넣어보았습니다.)

생각1: 게임, 음식점(요식업)과 영화랑 비교해볼까?

음식점-게임-영화

게임, 음식점, 영화 각각 비슷한 특징은 각 열(row)에 배치해보았습니다.
게임에서 버그가 발생하는 거랑 음식점에서 벌레(위생)가 나오는 것은 둘 다 치명적인 문제로 같은 층에 배치해보았습니다. 😸
(나름 재미있다고 생각한 포인트인데 쓰고 보니 별로 재미없네요 🐛 재미없으면 버그야…)

제가 생각하는 각 카테고리의 핵심은 음식점은 맛, 게임&영화는 재미로 정리해볼 수 있었습니다.
음식점을 맛이 아닌 다른 이유(사장님과의 친분, 가게 인테리어)로 갈 수 있지만
사람들이 자주 찾아오고, 단골이 생기고 다른 사람들에게도 추천할 수 있으려면 음식점은 음식의 맛이 중요하다고 보았습니다.

게임도 마찬가지로 다른 요소가 뛰어나더라도 재미가 없다면 지속될 수 없다고 생각합니다.
다른 요소들이 뒷받침해서 게임의 재미가 돋보일 수 있도록 도울 수는 있겠지만 핵심은 재미가 있어야죠.

여기서 영화는 게임, 음식점과 조금 다른 카테고리인 것 같아 점선으로 분리해두었습니다.
영화는 게임에서의 알파 테스트나 음식점에서의 신메뉴 테스트 등을 못하지 않을까? 하는 생각과
실제 사용자에게 가기 전까지의 비용이 많이 든다는 점이 다른 것 같았습니다.

지금 추가로 찾아보니까 영화 시사회 중 기술 시사회가 어느정도 알파 테스트까지는 아니더라도 베타 테스트까지는 역할을 하는 이벤트가 아닐까 싶네요.
다만 기술 시사회도 이미 어느정도 완성된 영상을 보여주는 것이라 얼리엑세스 같은 느낌에 더 가깝겠네요.
영화 프로덕션에 대한 내용은 아래 링크에서 더 보실 수 있습니다.

물론 게임도 실 사용자에게 가기 전까지 많은 비용이 들긴 합니다만..
게임은 영화에 비해 사용자 피드백을 받고 지속적으로 개선할 수 있는 형태이지 않을까 싶었습니다.
(예전에는 패키지 게임/CD 게임은 판매 후 패치하기 어려운 시기가 있었지만 지금은 아니니까요. 😸)

음식점도 임대하고 가게를 임대하는 데에 있어서 비용이 적지 않게 들어가지만
음식점을 오픈하고 메뉴를 바꿀 수도 있는 것이고 손님 피드백을 받아서 개선해나갈 수 있다고 보았습니다.
요즘은 공유 오피스처럼 주방도 공유 주방이 생기고 있는 시대라 초기 비용에 대한 부담도 줄일 수 있는 시대이기도 하니까요.

생각2: 게임은 흥행 산업일까?

사실 게임이 흥행 산업이라는 이야기를 많이 들어서 영화와 슬쩍 비교해본 것이긴 합니다.
(흥행이라는 말 자체가 “대중을 상대로 하여 연극·영화·서커스·쇼 등의 볼거리를 영리 목적의 사업으로서 공연하거나 상영하는 일.”이라 어원은 영화에서 비롯되었다고 볼 수 있겠네요.)

재미라는 것 자체가 “이거 재미있다더라”, “같이 보자(하자)” 등이 연결되어서 흥행이 될 수도 있고
유명한 크리에이터, 스트리머들이 좋은 리뷰를 하더라도 흥행이 부스트 될 수 있는 것 같습니다.
(장기적인 흥행 부스트가 될지는 스트리머의 인지도 및 관계, 협력에 따라 달라질 수 있겠죠)

계속 흥행을 유지하려면, 게임을 즐기는 다양한 유저들이 지속적으로 재미를 느낄 수 있도록 핵심 재미와 다양한 맛을 골고루 줘야 한다고 생각합니다.
마블(Marvel) 처럼 마블 시네마틱 유니버스를 통해 다양한 캐릭터에 대한 서사와 세계관을 보여주는 것처럼 팬들이 꾸준히 찾고 즐길 수 있는 콘텐츠를 만들어가야 하지 않을까 싶습니다.

음식점의 경우에는 다양한 손님을 만족시키기 위해 신메뉴를 개발해야겠지만 기존의 맛을 찾는 손님들도 더 맛있게 먹을 수 있는 방법을 고민해야하는 측면에서 약간 결이 다른 것 같기도하네요.

결국 어떤 곳이든 흥행을 하더라도 지속하려면 팬(Fan)이 남아서 또는 팬을 남겨서 핵심 요쇼를 계속 즐길 수 있도록 해야겠죠.

생각 마무리

엔지니어로 소프트웨어(앱, 웹서비스)를 개발하다가 처음 게임 개발에 개발 PM으로 와서 처음으로 게임 개발과 관련한 글을 써보는 것 같네요. 사실 게임 개발을 하고 계신 분들 중 은둔 고수 시니어분들이 많아서 이런 생각을 정리해서 글을 써본다는 것 자체가 뭐랄까 코끼리의 코만 만져보고 “코끼리는 뱀 같은 동물이다”는 사람이 될까 싶기도 합니다. 😇

그래도 나름 이런 생각을 하면서 우린 어떤 업계에서 살고 있을까 하는 고민도 해볼 수 있어서 재미있었습니다.
다음 고민, 공부로는 “게임 개발 알파, 베타 테스트는 뭘까”를 정리해볼까 합니다. 😏

제 생각에 정정이 필요한 내용이나 첨언이 필요한 내용이 있다면 편하게 댓글로 남겨주세요!
읽어주셔서 감사합니다. 😸