조사 목적

• 언리얼 엔진으로 게임을 만들 때에 사용하는 크래시 분석 서비스는 무엇이 있는지 알아봅니다.
• 단순히 크래시 덤프를 수집하는 것에 그치지 않고 어떤 크래시가 많이 발생하고 있는지 트렌드나 특이점을 확인할 수 있는 서비스들이 있는지 찾아봅니다.

언리얼 크래시 리포터(Unreal Crash Reporter)

언리얼 엔진 크래시 분석 서비스

알아본 크래시 분석 서비스

• Sentry: https://sentry.io/welcome/
• BugSplat: https://www.bugsplat.com/
• Backtrace: https://backtrace.io/
• Raygun: https://raygun.com/
• Countly: https://countly.com/

Sentry 👍

https://sentry.io/welcome/
https://docs.sentry.io/platforms/unreal/

센트리(Sentry)는 웹 서비스, 앱 서비스에서도 많이 쓰는 이슈 관리 솔루션으로 알고 있습니다.
언리얼에서 사용하고자 할 경우에는 minidump를 직접 올리거나 크래시 리포터에 연결, 크래시 덤프를 올리는 방식인 것 같습니다.
가이드 문서를 보면 제한 사항이 있네요.

• 20MB for a compressed request → 크래시 덤프 업로드시 압축된 데이터가 20MB 이하여야 하고
• 100MB for the full crash report after decompression → 크래시 덤프 압축을 해제하면 100MB 이하여야 함

이런 제한을 참고해서 센트리를 도입해서 유의미하게 쓸 수 있는지 검토해야겠네요.
(덤프에 많은 정보를 남길 경우 센트리를 쓰지 못한다는 이야기… 😂)

플러그인이 있어서 설정은 쉬웠네요.
센트리 설정 경험기: Sentry - Uneal Engine 4.27 integration

BugSplat 👍

https://www.bugsplat.com/
https://docs.bugsplat.com/introduction/getting-started/integrations/game-development/unreal-engine

요 서비스는 언리얼 플러그인까지 있는 서비스여서 설정은 편할 것 같습니다.

센트리는 제한이 있었는데 BugSplat에도 제한 사항이… 있군요.
센트리랑 비슷하게 압축된 덤프의 사이즈가 20MB 여야합니다. 😂 (참고 링크)

1. 에디터에서 프로젝트 설정에 “크래시 리포터 포함” & “디버그 파일 포함” 설정해주기
2. DefaultEngine.ini 에 크래시를 보낼 주소를 입력해주기
   1. DataRouterUrl=”https://{database}.bugsplat.com/post/ue4/{appName}/{appVersion}”
3. 4.26 이후 버전에는 DefaultEngine.ini 파일을 아래 경로에 복사해줘야 함(폴더가 없으면 다 만들어서 넣어줘야 함)
   1. 패키지 빌드 폴더\Engine\Restricted\NoRedist\Programs\CrashReportClient\Config
4. 패키지 빌드에서 크래시 발생시키면 대시보드에서 바로 볼 수 있음

BugSplat도 Trial로 설정해보고 테스트해보았는데 가이드 문서대로 설정해볼 수 있었습니다.
BugSplat 설정 경험기: BugSplat - Uneal Engine 4.27 integration

Backtrace 👍

https://backtrace.io/
https://support.backtrace.io/hc/en-us/articles/360040106172-Unreal-Integration-Guide

백트레이스 서비스는 언리얼 엔진 설정이 가능한 솔루션이네요.
가이드 문서상 크래시 덤프 사이즈 제한은 보이지 않습니다.

요 친구도 플러그인이 있지는 않고 따로 크래시 리포터 설정에 DataRouterUrl 설정만 해주면되네요.
BugSplat과 동일하게 패키지 빌드 폴더\Engine\Restricted\NoRedist\Programs\CrashReportClient\Config 경로에 DefaultEngine.ini 가 있어야 크래시 덤프가 업로드되는 것 같습니다.

따로 플러그인은 있지 않고 단순 크래시 리포터 설정으로 가능하며 다른 크래시 분석 서비스와 비슷한 기능들을 가지고 있습니다.

• Overview: 대시보드로 크래시 전체적인 현황을 볼 수 있는 뷰
• Release: 업데이트된 버전 별로 크래시 지표를 볼 수 있는 뷰
• Triage: 발생한 크래시를 테이블로 볼 수 있는 뷰. 필터를 적용해서 볼 수도 있음
• Debug: 각 크래시별 정보를 상세히 볼 수 있는 뷰

크래시 정보를 상세히 볼 수 있도록 심볼 업로드는 프로젝트 세팅 > 심볼 설정에서 할 수 있습니다.

백트레이스도 크래시 분석 서비스들과 무난히 비슷한 서비스인 것 같네요.
실제 다른 서비스와 장단점을 상세 분석해보려면 다양한 케이스로 사용해봐야할 것 같습니다.

Raygun 🤔

(⚠ 언리얼 엔진에 설정하기 쉽지 않은 서비스)

https://raygun.com/

레이건 서비스는 따로 언리얼 엔진 플러그인이 있지는 않네요.
이 서비스를 사용한다면 C++ 항목으로 구성하고 minidump(breakpad)를 업로드하는 방식으로 시도해보았는데 잘 되지 않았습니다.

1. 가이드 문서 확인 → sender.SendCrashReport(L"https://api.raygun.com/entries/breakpad?apikey=...", userCustomData, files, 0); 코드 확인 → URL로 덤프를 보낼 수 있도록 설정
2. DefaultEngine.ini 에서 [CrashReportClient], DataRouterUrl 항목에 위 URL 입력
3. 크래시 발생 후 크래시가 남는지 확인 → 확인할 수 없었음

다른 서비스에서 했던 것 처럼 크래시 업로드 URL에만 덤프를 올리면 가능할 것으로 기대했지만 잘되지 않네요.
Raygun은 웹서비스 설정이 더 편한 서비스라고 보여서 설정을 더 시도해보지는 않았습니다.

Countly ❓

(⚠ 언리얼 엔진에 설정하기 쉽지 않은 서비스)

https://countly.com/
https://countly.com/feature/crashes-errors

카운틀리는 자체 서버 구축과 클라우드 서비스를 사용할 수 있는 서비스 시스템으로 볼 수 있습니다.
자체 서버 구축: https://support.count.ly/hc/en-us/articles/360036862332-Installing-Countly-server
언리얼 엔진 크래시 분석 서비스로 사용하려면 자체 서버 구축과 클라이언트에 minidump로 업로드 설정하는 방법으로 가능하네요.

마무리

위와 같이 언리얼 엔진 게임으로 크래시 현황, 분석을 할 수 있는 5가지 정도의 서비스를 알아보았습니다.

핵심 기능은 비슷한 것 같았고 2가지 정도는 C++ 빌드로 만들어진 프로그램을 minidump를 업로드하고 그 것을 분석하는 방식을 가지고 있었네요.
대부분 앱과 웹 서비스에서 발생하는 비정상 종료, 크래시를 분석하는 데에 맞춰져있었습니다.

언리얼 엔진으로 접근성이 좋았던 것은 Sentry 정도였고 나머지는 프로젝트 설정에 따라 커스텀 설정을 해줘야하는 것들이 좀 있었습니다.

Countly의 경우에는 서버를 자체 구축할 수 있다는 점에서 크래시 덤프 파일 사이즈가 크더라도 사용할 수 있겠다 싶었습니다.
(덤프에 많은 정보를 담고자할 경우 덤프 파일이 100MB가 넘어가는 경우도 있긴하더라구요.)

Countly 설정은 클라, 크래시 분석 서비스 서버 설정까지 해야해서 나중에 한번 해보고 포스트 남겨보겠습니다. 👋

BugSplat

홈페이지: https://www.bugsplat.com/
가이드 문서: https://docs.bugsplat.com/introduction/getting-started/integrations/game-development/unreal-engine

설치, 설정 방법

가이드 문서: https://docs.bugsplat.com/introduction/getting-started/integrations/game-development/unreal-engine

설정 방법은 간단합니다.

1. 에디터에서 프로젝트 설정에 “크래시 리포터 포함” & “디버그 파일 포함” 설정해주기
2. DefaultEngine.ini 에 크래시 덤프를 보낼 주소를 입력해주기
   1. DataRouterUrl=”https://{database}.bugsplat.com/post/ue4/{appName}/{appVersion}”
3. 4.26 이후 버전에는 DefaultEngine.ini 파일을 아래 경로에 복사해줘야 함(폴더가 없으면 다 만들어서 넣어줘야 함)
   1. 패키지 빌드 폴더\Engine\Restricted\NoRedist\Programs\CrashReportClient\Config
4. 패키지 빌드 폴더에서 심볼 파일 업로드(.pdb)
   1. sendpdbs 커맨드라인 프로그램을 이용해서 심볼 파일 업로드 (가이드 문서 참고)
   2. SendPdbs.exe /u {username} /p {password} /b {database} /a {appName} /v {appVersion} /s /f “.pdb;.dll;*.exe”
5. 패키지 빌드에서 크래시 발생시키면 대시보드에서 바로 볼 수 있음

설정 상세

• DefaultEngine.ini에 DataRouterUrl에는 {} 값을 실제 사용할 값으로 바꿔서 입력해야합니다
  • {database} 는 BugSplat에 설정에서 데이터베이스를 만들어서 사용할 수 있습니다
• 언리얼엔진 4.27.2 버전은 가이드 문서에 있는 아래 내용을 참고하여 추가 설정해줘야합니다
  • “For capturing crashes in packaged games in Unreal Engine 4.26 and newer, copyDefaultEngine.ini to {output directory}\Engine\Restricted\NoRedist\Programs\CrashReportClient\Config making sure to create folders that don’t exist (where{output directory} is the location of your packaged build).”
  • 이 폴더에 DefaultEngine.ini 파일이 없는 경우 BugSplat에서 크래시를 확인할 수 없었습니다

크래시 업로드 확인

프로젝트 패키지로 만들어진 바이너리 실행 후 크래시를 발생시킵니다.
저는 크래시 발생시키는 명령어 이름을 crashMe로 지어두었고 콘솔 명령어로 실행하면 아래와 같이 크래시 리포터가 뜨게됩니다.

“Send and Close”로 크래시 정보를 보내면 센트리에서 크래시 정보를 볼 수 있게됩니다.

마무리

Sentry에 이어서 BugSplat이라는 서비스에서 크래시 업로드, 크래시 대시보드 확인을 한번 해보았습니다.
BugSplat은 Sentry에 비해서 투박한 느낌이 있습니다.
Overview / Other Threads / Registers / Modules 등 각 항목별로 나눠서 보여주고 있지만 Sentry를 보고 BugSplat을 보니 뭔가 필요한 정보는 알아서 찾아서 보세요의 느낌이 강했네요.
두 서비스 모두 크래시 분석을 위한 정보들을 잘 보여주고 있는 것 같았습니다.
(엔지니어분과 같이 이런 뷰 형태는 어떤지 확인은 해봐야겠지만요 😂)

다른 크래시 분석 서비스도 다음 포스트에서 다뤄보겠습니다.

참고: Sentry - Unreal

준비 사항

⚠️ 프로젝트가 C++ 클래스를 빌드할 수 있는 상태여야 합니다.

(가이드 문서 내용) Currently, this method is available only for C++ UE projects. Blueprint projects can be converted to a C++ one by adding an empty class using the editor.
→ 현재 이 메서드는 C++ UE 프로젝트에서만 사용할 수 있습니다. 블루프린트 프로젝트는 에디터를 사용하여 빈 클래스를 추가하여 C++ 프로젝트로 변환할 수 있습니다.

C++ 클래스 빌드를 위해서는 Visual Studio 설치가 필요합니다.
관련 구성요소를 설치해야하는데 설치해야하는 것은 다음과 같습니다.

• .Net 데스크톱 개발, C++를 사용한 데스크톱 개발, 유니버설 Windows 플랫폼 개발

설치, 설정 방법

https://docs.sentry.io/platforms/unreal/
https://github.com/getsentry/sentry-unreal

설치 방법은 간단합니다.

1. Github에서 Sentry-unreal 소스를 받는다.
   1. 4.27 버전 엔진의 경우 0.5.0 버전을 받아야함.
   2. 5.0 이상 엔진의 경우 최신 버전을 사용할 수 있음 (현재는 0.7.0)
2. 받은 소스를 프로젝트 폴더/Plugins 폴더 하위에 옮긴다.
3. 프로젝트를 실행한다.
   1. 프로젝트 실행시 플러그인을 빌드하겠냐는 팝업이 실행되면 빌드한다
4. 이후 문서 가이드를 참고하여 설정한다
   1. https://docs.sentry.io/platforms/unreal/#configure

설정 상세

• Project Settings > 프로젝트-패키징 > 패키징 > 크래시 리포터 포함에 체크해줍니다.
• Project Settings > Plugins > Sentry 에서 DSN 값을 설정해줍니다.
  • 가이드 문서에서 Text 블록에 있는 텍스트를 클릭하면 현재 생성해둔 프로젝트들의 DSN 값을 골라서 볼 수 있습니다.
• DSN 설정 후 하단에 있는 Crash Reporter Endpoint도 설정해줍니다.
  • 크래시 리포터를 통해 크래시 덤프 업로드하는 곳을 설정해주는 것입니다.

DSN, Crash Reporter Endpoint URL은 Sentry 웹페이지에서 프로젝트 > 프로젝트 설정 > SDK SETUP - Client Keys(DSN)에 있습니다

설정 후 크래시 테스트

저는 크래시 테스트를 위해 기본 프로젝트 생성 후 아래와 같이 진행했습니다.

1. 기본 프로젝트 생성
2. 파일 > 새로운 C++ 클래스 추가 > Game Mode Base 선택 > Game Mode 클래스(ex. MyGameModeBase class) 추가
3. MyGameModeBase에 콘솔 명령어 함수 작성
4. 에디터에서 월드 세팅 > Game Mode > 게임 모드 오버라이드에서 MyGameModeBase 설정
5. 컴파일 후 프로젝트 패키지하여 프로그램 실행 테스트

코드

크래시 센트리 업로드 확인

프로젝트 패키지로 만들어진 바이너리 실행 후 크래시를 발생시킵니다.
저는 크래시 발생시키는 명령어 이름을 crashMe로 지어두었고 콘솔 명령어로 실행하면 아래와 같이 크래시 리포터가 뜨게됩니다.

“Send and Close”로 크래시 정보를 보내면 센트리에서 크래시 정보를 볼 수 있게됩니다.

마무리

이번 포스트에서는 간단히 센트리-언리얼 엔진 설정을 다뤄봤는데 글은 간단했지만..
실제로 크래시를 일으키기 위해 어떻게 해야할지 여러가지 난관이 있었네요.
(언리얼 엔진 에디터에서 처음 빌드해보고 Visual Studio로 연결하는 것도 처음이다보니 좀 걸렸습니다. 😅)
다음 포스트에는 다른 크래시 분석 툴을 설정해보고 포스트 남겨보겠습니다. 감사합니다. 🙏

설치중 에러 참고

ERROR: Could not find NetFxSDK install dir; this will prevent SwarmInterface from installing. Install a version of .NET Framework SDK at 4.6.0 or higher.

• Visual Studio에서 빌드에 필요한 컴포넌트가 설치되어 있지 않아 발생하는 문제.
• .Net 데스크톱 개발, C++를 사용한 데스크톱 개발, 유니버설 Windows 플랫폼 개발 설치

Plugin build fail

• 플러그인이 소스코드만 포함되어있는 상태라면 Visual Studio 설치가 필요합니다.
• Visual Studio를 설치해주세요.

인풋랙(Input lag)?

https://en.wikipedia.org/wiki/Input_lag

인풋랙은 말 그대로 인풋(마우스, 키보드 등) → 연산장치(컴퓨터) → 디스플레이(모니터)까지 사용자의 인풋에 따른 디스플레이까지의 지연을 의미합니다.
인풋랙이라고 부르긴하지만 시스템 지연 시간으로 볼 수 있어요.

이번 포스트에서는 게임에서 주로 느끼는 인풋랙에 대해서만 다뤄보겠습니다.
(주로 인풋랙에 민감하게 반응하는 영역이 게임이기 때문에)

중간에 인풋랙을 찾다가 디스플레이 랙(Display Lag)으로 잘못 빠졌었는데 Latency(지연 시간, 응답 속도) 측면에서 완전히 분리할 수는 없지만 인풋랙과는 다른 영역이었네요.
디스플레이 랙 = 디스플레이 장치(예: 모니터, TV)에서 입력 신호를 받아 처리하여 화면에 표시되는 시간
참고: https://en.wikipedia.org/wiki/Display_lag

인풋랙 깊게 살펴보기

엔비디아에서 좋은 글, 좋은 영상이 있어서 들고왔습니다.
(엔비디아 Reflex에 대한 소개가 있긴하지만요 😅)

• https://www.youtube.com/watch?v=h69JR51pZbU
• https://www.nvidia.com/en-us/geforce/guides/system-latency-optimization-guide/

게임에서 인풋랙은 많은 요소들이 영향을 준다고 볼 수 있습니다. 적당히 풀어서 정리해볼게요.

• 주변기기 지연 - 인풋 기기의 폴링 레이트(Polling Rate)에 맞춰 컴퓨터에서 신호 처리가 되는데 그 처리에서 지연 시간이 있습니다. (USB 신호 처리, CPU 처리 등)
• PC 지연 - 입력을 받고 PC에서 처리되는 동안 발생하는 지연
  • CPU - 게임 내에서 일어나는 애니메이션, 물리 엔진 연산 등에 사용되는 시간
  • Render Queue - CPU 연산 뒤 렌더링을 위해 렌더링 명령들을 Queue에 적재하고 대기하는 시간
  • GPU - Render Queue에 있는 명령들을 렌더링하는 시간
• 디스플레이 지연 - PC로 부터 받은 신호들을 보이도록 처리하는 시간

우리가 게임에서 말하는 인풋랙은 이렇게 크게 3가지 지연 시간을 합해서 계산해볼 수 있습니다.
물론 네트워크를 이용한 멀티플레이 게임의 경우, 네트워크 레이턴시도 포함해서 봐야하지만 그건 PC 지연에 포함한다고 가정하고 넘어가겠습니다

게임과 인풋랙

주로 인풋랙에 영향을 많이 받는 게임은 FPS(Shooter), 격투 게임, 리듬 게임이 작은 지연에도 큰 영향을 받는 게임 장르로 볼 수 있습니다.

• FPS, Shooter: 인풋랙에 따라 상대방을 조준, 사격하는데에 있어서 인풋랙의 영향을 받습니다.
  • 추가로 네트워크 레이턴시도 추가되어 흔히 이야기하는 핑(ping) 차이가 발생하기도 합니다
  • 핑이 높으면 피커스 어드벤티지(Peeker’s advantage) 현상이 더 크게 발생할 수 있습니다
    • 피커스 어드벤티지: 네트워크 지연, 차이 등에 따른 공격자가 상대를 먼저 인지할 수 있는 이득을 보는 것
    • (참고) 피커스 어드벤티지, 발로란트 포스트
• 격투 게임: 인풋랙에 따라 콤보를 넣을 수 있느냐, 상대의 공격을 인식해서 방어, 회피할 수 있냐가 달라지기에 크게 영향을 받는다고 볼 수 있습니다.
  • 한 사례로 콘솔 기기와 PC 설정 환경 차이로 인해 인풋렉의 차이가 발생해서 PC로 대회를 열 수 밖에 없었다는 사례도 있었네요. (스트리트파이터5 참고 사례, 참고 사례 링크2)
• 리듬 게임: 인풋랙에 따라 노트를 정확하게 맞출 수 있냐 없냐가 달라지니 크게 영향을 받는다고 볼 수 있습니다.
  • 게임이 얼마나 세세하게 판정하냐에 따라 영향도는 달라질 수는 있지만 게임 자체 이슈, 모니터, 컨트롤러의 지연 요소에 따라 인풋랙이 크게 발생할 수 있습니다

인풋랙 측정 방법

퀘이사존: 모니터 인풋랙은 무엇이고, 어떻게 측정할까? https://quasarzone.com/bbs/qn_report/views/113059

상세한 내용은 퀘이사존에서 자세히 설명해주고 있어서 위 글을 참고해보시면 좋을 것 같습니다.

요약해보면 마우스 입력 → 화면 반응까지 시간을 LDAT(Latency Display Analysis Tool)이라는 장치를 이용해서 측정합니다.
LDAT이 없을때는 화면 반응을 카메라를 이용해서 촬영, 측정했다고 하네요. 🤩

인풋랙 개선 방법

엔비디아 글에서 여러가지 인풋랙 개선 방법들이 있어 간단히 남겨보겠습니다.

https://www.nvidia.com/en-us/geforce/guides/system-latency-optimization-guide/

1. Turn on NVIDIA Reflex (게임 설정): 게임에서 Reflex 기능 On
2. Turn on Ultra Low Latency Mode (엔비디아 설정): Low Latency를 Ultra로 설정
3. Turn on Exclusive Fullscreen (게임 설정): 게임에서 “전체화면” 설정
4. Turn off VSYNC (엔비디아 설정): Vsync 기능 off
5. Turn on “Game Mode” in Windows(OS 설정)
6. 설정 > 게임 > 게임 모드 >게임모드 On 설정
7. Overclocking (PC 하드웨어 설정): CPU, GPU, Ram 오버클럭
8. Consider Faster Hardware: 하드웨어 업그레이드 😂
9. Reduce settings (게임 설정):
10. 하위 옵션으로 반응성을 올려라
11. Enable your maximum refresh rate: 디스플레이의 주사율을 최대로 설정
12. Turn on G-SYNC Esports mode (엔비디아 설정)
13. Turn on some overdrive: 모니터에서 오버드라이드 모드 설정

마무리

요렇게 인풋랙에 대해서 짧게 알아보았는데요. 정리해보고나니 일상적으로 게임에서 이야기하는 인풋랙은 시스템 레이턴시(시스템 지연 시간) 정도로 볼 수 있을 것 같습니다.

인풋랙은 워낙 많은 요소들이 영향을 주는 것이다 보니 하나만으로는 개선이 어렵고 이것저것 다 최적화해야하는 느낌이네요.

개인의 입장에서는 하드웨어 업그레이드, 게임 설정으로 개선할 수 있고
게임 입장에서는 게임 최적화, 하드웨어 기능 호환 등을 지원하는 것이 개선 방법이 될 수 있겠습니다.

참고

• https://quasarzone.com/bbs/qn_hardware/views/474933
  • 원문: https://videocardz.com/newz/nvidia-reviewer-kit-ldatpcat-will-make-gpu-testing-more-accurate
• Nvidia
  • What is System Latency: https://www.youtube.com/watch?v=h69JR51pZbU
  • https://www.nvidia.com/en-us/geforce/guides/system-latency-optimization-guide/

Perforce stream: Task stream

예전 포스트에서 스트림을 살펴보았는데요. Perforce(P4V) Stream(스트림)
각 스트림 타입별 내용을 한번 정리해보고자 합니다. 😃
이번 포스트에서는 Task stream, 태스크 스트림을 공부해보겠습니다.

가이드 문서: Working with task streams

참고: 스트림 유형(Stream types)

• Mainline: 최상위 스트림으로 메인 브랜치로 볼 수 있습니다.
• Release: 안정적인 소스 상태로 관리하기 위한 스트림으로 주로 안정적인 릴리스를 준비하기 위해 사용하는 스트림입니다.
• Development: 개발이 이뤄지는 피쳐 스트림입니다.
• Task: 작은 단위의 작업을 할 때 사용할 수 있는 특수한 스트림입니다. 자세한 내용은 링크를 참고하세요.
• Virtual: 특정 인원에게 제한된 뷰를 제공하기 위한 스트림입니다. 자세한 내용은 링크를 참고하세요.

Task stream overview(요약)

먼저 가이드 문서에 있는 내용들을 요약해보겠습니다.

• 태스크 스트림은 버그 수정이나 작은 기능 개발과 같이 제한된 작업에 적합합니다.
• 태스크 스트림은 브랜치의 총 파일 수에 비해 적은 수의 파일에 영향을 주는 가벼운 브랜치입니다.
• 태스크 스트림은 대개 일시적인 경우가 많으며 변경 사항이 통합되면 삭제되거나 언로드됩니다.
• 태스크 스트림은 리포지토리 메타데이터의 양을 최소한으로 유지하여 Helix Core Server 성능에 도움이 될 수 있습니다.
• ⭐각 태스크 스트림에는 고유한 이름이 필요하며, 이 이름은 태스크 스트림이 삭제된 후에도 재사용할 수 없습니다.
  • 따라서 사이트에 사용자-날짜-작업 번호와 같은 명명 규칙이 있는지 관리자에게 문의하세요.
  • 여기서 작업 번호는 이슈 추적 애플리케이션에서 식별자 또는 ‘작업(job)’을 나타냅니다.

다른 스트림들과 다른 태스크 스트림의 예외 사항

• 태스크 스트림에는 상위(부모) 스트림이 필요하지 않습니다.
  • 따라서 스트림 depot에서 작업하지 않는 사용자도 태스크 스트림을 만들 수 있습니다.
  • 태스크 스트림은 스트림 저장소에 있어야 하지만, 해당 저장소는 태스크 스트림의 보류 장소일 뿐입니다.
  • 사용할 스트림 보관소에 대한 정보는 관리자나 프로젝트 리드에게 문의하세요.
  • 자세한 내용은 상위 스트림 없이 태스크 스트림 만들기를 참조하세요.
• 상위 스트림은 다른 depot에 있을 수 있습니다.
  • 태스크 스트림은 삭제되거나 언로드될 때까지 디포에 빠르게 누적될 수 있습니다.
  • 프로젝트 보관함을 태스크 스트림으로 어수선하게 만들지 않으려면 관리자나 프로젝트 리더가 특정 스트림 보관함을 태스크 스트림의 전용 보관 장소로 설정할 수 있습니다.
  • 이 경우, 태스크 스트림 저장소에 스트림을 프로젝트 저장소에 있는 상위 스트림의 하위 스트림으로 만들면 됩니다.
  • 태스크 스트림이 다른 디포에 있더라도 부모 디포의 스트림 그래프 보기에 스트림이 표시되는 것을 볼 수 있습니다.
  • 자세한 내용은 다른 저장소에 태스크 스트림 만들기를 참조하세요.
• 태스크 스트림은 자식 스트림을 가질 수 없습니다.
  • 태스크 스트림은 상위 스트림을 다시 지정할 수 없습니다.
  • 하지만 태스크 스트림을 일반 스트림으로 변환하면 해당 일반 스트림에 상위 스트림을 다시 지정할 수 있습니다.

💡 태스크 스트림이 다른 스트림과 다른점 💡
P4V나 가이드 문서를 확인해보니 태스크 스트림만 unload 할 수 있네요.
mainline, development, release 스트림은 삭제만 가능하고 Virtual 스트림은 다른 유형의 스트림이니 제외하고 나면 태스크 스트림만 가능합니다.
스트림이 많을수록 서버 성능에 영향이 있을 수 있으니 사용하지 않는 스트림의 정보를 unload하고 데이터를 로딩하지 않는 형태로 서버 성능을 관리할 수 있는 형태인 것 같네요.
추가로 Unload할 수 있는 것은 워크스페이스인데 퍼포스 서버 쪽에서 관리하는 데이터를 unload해서 서버 성능 관리를 좀 해야하나 봅니다.
(저희도 workspace, stream 전체 현황 검토해서 정리가 필요하겠네요 ㅎㅎ 😂)

정리

정리해보면, 태스크 스트림은 작은 작업, 버그 수정 등을 위한 피쳐 브랜치로 사용할 수 있는 스트림이라고 할 수 있네요.
다른 스트림들에 비해 스위칭 속도가 더 빠르거나 그런 것은 아닌 것 같지만 어떻게 스트림을 생성했냐에 따라 다를 수 있을 것 같습니다.
(스트림 생성시 부모 스트림의 데이터를 그대로 사용하는 설정 등..?)

가이드 문서와 다른 메뉴얼들만 보았을때는 퍼포스 서버 성능 관리를 위한 기능 같아서 작업자들 입장에서 어떤 것들이 좋은지는 더 살펴봐야겠네요.
실제로 스트림간 스위치 성능이 다른지 확인해보고 추가 내용으로 포스트해보겠습니다.

다른 Perforce 가이드 문서들

• P4V 소개 - 기본 개념 및 Cheat Sheet
• Perforce Client(P4V) basics
• Perforce(P4V) bookmark(북마크)
• Perforce(P4V) Revision Graph(리비전 그래프) 기능
• Perforce(P4V) Search(검색) 기능
• Perforce(P4V) Workspace(작업공간) 관리
• Perforce(P4V) Stream(스트림)
• Perforce Stream, task stream / 태스크 스트림
• Perforce(P4V) Time lapse 기능