데스크톱 클라이언트

설치

데스크톱 클라이언트는 Windows, macOS (Apple Silicon), Linux용으로 제공되는 네이티브 애플리케이션입니다. Windows, macOS, Linux 설치 프로그램에는 uversion CLI도 함께 번들되어 바로 사용할 수 있습니다. /downloads 에서 다운로드하세요.

Windows

uVersion_x.y.z_x64-setup.exe (서명된 NSIS 설치 프로그램, 약 25 MB) 를 다운로드합니다. 실행하면 설치 프로그램은 다음을 수행합니다:

• 클라이언트를 %LOCALAPPDATA%\uVersion 에 설치 (사용자 단위, 관리자 권한 불필요)
• 설치 폴더를 사용자 PATH에 추가 (uversion.exe CLI가 여기에 번들되어 있음)
• 시작 메뉴에 바로 가기 생성
• Tauri 업데이터를 통한 자동 업데이트 활성화

Windows 대량 배포: MSI

자산 관리 도구 (Intune, SCCM, 그룹 정책 등) 로 다수의 기기에 배포하려면, NSIS 설치 프로그램 대신 MSI 를 사용하세요: uVersion_latest_x64_en-US.msi (안정적인 URL, 항상 최신 버전, 약 10 MB). 무인, 기기 단위 설치:

msiexec /i uVersion_latest_x64_en-US.msi /qn /norestart

• C:\Program Files\uVersion 에 설치합니다 (관리자 권한 필요). uversion.exe CLI는 포함되지만, 폴더는 PATH에 추가되지 않습니다: 사용자가 터미널에서 필요하다면, 배포 도구로 추가하도록 하세요.
• MSI 설치에는 자동 업데이트가 없습니다: 클라이언트는 배포된 버전에 머물고, 대량 업데이트는 다음 MSI를 재배포하여 이루어집니다. 이는 의도된 것입니다: 내장 업데이터는 관리되는 사본 옆에 사용자 단위로 두 번째 사본을 설치하게 되기 때문입니다.
• 무인 제거: msiexec /x uVersion_latest_x64_en-US.msi /qn

첫 실행 시, 각 사용자는 서버 주소를 입력하고 인증서 지문을 검증합니다. 이는 사용자마다, 기기마다 한 번씩 이루어집니다 (TLS 지문 참조).

macOS (Apple Silicon)

uVersion_x.y.z_macos-arm64.app.zip (약 32 MB, Developer ID 서명 및 Apple 공증 완료) 를 다운로드합니다. 더블 클릭하여 압축을 풀고, uVersion.app 을 /Applications 로 드래그하세요. 첫 실행 시 Gatekeeper가 공증을 자동으로 검증하며, 경고는 표시되지 않습니다.

uversion CLI는 앱 안에 번들되어 있습니다. 첫 실행 시, 클라이언트는 ~/.local/bin/uversion 으로의 심볼릭 링크를 자동으로 생성하고, ~/.zprofile 을 통해 ~/.local/bin 을 PATH에 추가합니다: 수동 작업은 필요 없습니다. 새 터미널을 열면 uversion 을 사용할 수 있습니다.

참고: Apple Silicon (M1/M2/M3/M4) 만 지원됩니다. Intel 바이너리는 없습니다.

Linux

x86_64용 형식은 AppImage 하나뿐입니다 (uVersion_x.y.z_amd64.AppImage, 약 85 MB). 이동성이 있으며, 의존성 (libwebkit2gtk, libgtk, libsoup 등) 을 번들하고 있어, 시스템 설치 없이 최근 배포판이라면 어디서나 동작합니다. 사전 요구 사항: Ubuntu 24.04 이상, Debian 13 이상, 또는 동일 세대의 배포판. 바이너리는 최신 시스템 C 라이브러리를 요구하며, AppImage는 이 하한을 낮추지 않습니다: 번들하는 것은 그래픽 환경이지 C 라이브러리가 아니기 때문입니다.

권장되는 방법은 설치 스크립트입니다. sudo 없이:

curl -fSL https://uversion.io/downloads/client/install.sh | sh

마법 같은 일은 전혀 하지 않으며, 특히 권한을 요구하는 일은 아무것도 하지 않습니다:

• root 로 실행하거나, x86_64가 아닌 아키텍처, 또는 바이너리를 실행하기에 너무 오래된 시스템에서는 실행을 거부하며, 셋 중 무엇이 문제인지 알려줍니다;
• AppImage를 ~/Applications/uVersion.AppImage 에 다운로드하고, 도착한 것이 정말 Linux 실행 파일인지 확인한 뒤 (그렇지 않으면 캡티브 포털이나 오류 페이지가 저장되어 실행 가능하게 되었다가, 나중에 이해하기 어려운 방식으로 실패하게 됩니다), 한 번의 동작으로 배치합니다. 이는 이미 사본이 실행 중이어도 안전합니다;
• 애플리케이션을 실행합니다. 바로 이 시작이 애플리케이션 메뉴 항목을 생성하므로, 그대로 두는 편이 좋습니다. 그래픽 인터페이스가 없는 원격 세션에서는, 대신 자신의 데스크톱에서 입력해야 할 정확한 명령을 표시합니다.

다운로드 페이지 에서 AppImage를 직접 다운로드하여, 실행 가능하게 만든 뒤 실행할 수도 있습니다:

chmod +x uVersion_x.y.z_amd64.AppImage
./uVersion_x.y.z_amd64.AppImage

클라이언트용 .deb 패키지는 없으며, 앞으로도 없을 것입니다: dpkg 로 설치된 패키지는 다시 dpkg 를 거쳐야만 업데이트할 수 있고, 그래서 버전마다 권한 상승이 필요합니다. 이는 관리자 권한이 없는 기기에서는 불가능합니다. AppImage는 비밀번호 없이 자신을 교체합니다. 반면 서버 는 여전히 .deb 패키지를 유지합니다.

참고: uversion CLI는 AppImage 안에 번들되어 있습니다. 첫 실행 시, 클라이언트는 바이너리를 ~/.local/bin/uversion 에 복사하고, ~/.profile 을 통해 ~/.local/bin 을 PATH에 추가합니다 (수동 작업 불필요). 애플리케이션 메뉴 항목도 첫 실행 시 생성됩니다. 같은 이유로, AppImage는 파일이지 설치가 아니기 때문입니다.

첫 실행

1. 서버 주소와 자격 증명 입력

첫 실행 시, 클라이언트는 Welcome to uVersion 이라는 제목의 로그인 페이지 를 표시합니다. Server address 필드는 완전한 URL을 요구하지 않습니다: 수정할 수 없는 https:// 접두사, 호스트, 그리고 포트 (기본값 8443) 의 세 블록으로 나뉘어 있습니다. 스킴은 고정되어 있어 클라이언트는 http:// 를 만들 수 없습니다. 호스트 칸에 완전한 주소나 host:port 를 붙여넣으면 자동으로 두 필드에 나뉘어 들어갑니다. 이어서 Username 과 Password 를 입력하고 Sign in 을 클릭하세요.

2. 서버 지문을 한 번만 검증

uVersion 서버는 기본적으로 자체 서명되므로, 특정 기기에 대한 첫 접속 시 Verify server identity 가 표시됩니다: SHA-256 지문을 관리자가 준 것과 비교한 뒤 Trust this server 를 클릭하세요. 이 질문은 서버마다 한 번만 나타나며, 만약 빨간 제목 Server identity changed 아래에서 다시 나타난다면 지문이 바뀐 것입니다: 확인 없이 수락하지 마세요. TLS 지문 참조.

접속 후, 클라이언트는 세션을 안전하게 기억합니다. uversion CLI와 에디터 플러그인 (Unreal, Rider) 은 동일한 자격 증명을 자동으로 재사용합니다: 다른 어디에서도 비밀번호를 다시 입력하지 않습니다.

저장소 열기 / 복제

로그인해도 아무 프로젝트가 열리지 않습니다: 저장소 목록은 명시적으로 요청합니다. 같은 창이 프로젝트를 처음 복제할 때에도, 디스크에 이미 있는 워크스페이스를 다시 열 때에도 사용됩니다.

1. Open Repository 창 열기

탭이 하나도 열려 있지 않은 동안, Workspace는 No repository selected 와 Open Repository 버튼을 표시합니다. 탭이 하나 이상 생기면, 같은 화면을 탭 바의 + 로 열 수 있습니다. 이 창은 접근 가능한 저장소를 프로젝트마다 카드 하나로 나열하고, 서버에 목록을 다시 요청하는 Refresh 버튼을 제공합니다.

2. 복제하거나, 기존 워크스페이스 다시 열기

각 카드는 그 상태에 맞는 동작을 제시합니다:

• Clone: 새 워크스페이스를 만듭니다. 카드의 Workspace name 필드가 생성되는 폴더의 이름이 되며, 비워 두면 프로젝트 이름을 사용합니다. 이어지는 폴더 선택기는 상위 폴더를 묻습니다: 하위 폴더는 uVersion이 직접 만듭니다.
• Clone New: 같은 버튼으로, 이 프로젝트에 대한 워크스페이스가 이미 있으면 이름이 바뀝니다. 예를 들어 프로젝트의 두 상태를 나란히 두기 위해, 두 번째로 복제하는 것도 정당합니다.
• Open: 이 기기에 이미 복제된 워크스페이스를 다시 엽니다. 그 경로는 카드 아래에 표시됩니다. 탭이 이미 열려 있으면 대신 Switch to Open Tab 이 표시됩니다.
• Open Local Repository... (창 하단): 이미 .uversion/ 을 포함한 폴더를 가리킵니다. 예를 들어 워크스페이스를 옮긴 뒤에 사용합니다.

하단의 Download files after clone 체크박스는 기본적으로 켜져 있으며, 복제에 이어 다운로드를 시작합니다. 지금은 워크스페이스만 만들고 파일은 나중에 가져오려면 체크를 해제하세요.

3. 다운로드 따라가기

복제가 시작되자마자 창은 닫힙니다. 이는 의도된 것입니다: 전송은 몇 시간이 걸릴 수 있어 당신을 붙잡아 두어서는 안 되기 때문입니다. 진행 상황은 클라이언트 헤더에서 계속되고, 끝나면 워크스페이스 탭이 저절로 열리며, 네트워크가 끊겨도 전송이 스스로 재개되므로 아무것도 잃지 않습니다.

Workspace

워크스페이스 는 서버 저장소에 연결된 로컬 폴더입니다. 클라이언트는 여러 워크스페이스를 동시에 관리할 수 있으며, 상단의 탭 바에 표시됩니다. 각 워크스페이스는 로컬 폴더의 루트에 있는 .uversion/ 에 메타데이터를 저장합니다:

• .uversion/config.toml: 유일하게 정말로 중요한 파일입니다. [workspace] 섹션에는 워크스페이스의 소유자 (owner), 그 식별자, 이름, 그리고 last_synced_revision, 당신이 동기화된 리비전 이 담깁니다 (.last_sync 파일은 없습니다). Unreal 엔진 경로도 여기에 기억됩니다.
• .uversion/checkouts_<workspace_id>.json: 이 워크스페이스에서 당신이 보유한 잠금
• .uversion/changelists_<workspace_id>.json: 당신의 changelist, 즉 따로 보내기 위해 묶은 체크아웃 파일의 묶음입니다. 순전히 로컬이며, 서버로는 전혀 전송되지 않습니다.
• .uversion/pending_deletes_<workspace_id>.json: 전송 대기 중인 삭제
• .uversion/snapshots.json: 알려진 파일 상태로, 로컬에서 수정한 것을 찾아내는 데 쓰입니다

Files 탭

워크스페이스 파일을 그 상태와 함께 트리로 봅니다. 목록을 줄이는 방법은 두 가지입니다:

• 검색 필드 (Search files... 로 표시): 경로의 일부로 필터링하며, 대소문자를 구분하지 않습니다.
• 상태 칩 (바로 아래). 클릭 가능한 카운터이며, 카운터가 0을 넘을 때만 칩이 나타납니다: 방금 동기화한 워크스페이스에서는 {n} synced 만 보이고, 나머지가 없는 것은 정상입니다. 가능한 여섯 칩은 {n} synced, {n} modified, {n} local only, {n} server only, {n} locked, {n} deleted 입니다.

검색과 칩은 결합됩니다: 먼저 검색이 범위를 좁히고, 이어서 칩이 필터링합니다. 수만 개 파일 규모의 프로젝트에서도 화면은 부드럽게 유지됩니다.

다중 선택 + 동작

동작 바는 무언가 선택되어 있을 때만 존재합니다. 선택이 비어 있는 동안에는 버튼이 하나도 없습니다: 이는 정상이며, 로딩 중인 것이 아닙니다. 파일을 선택하면 (클릭 + shift, 또는 체크박스) 선택한 개수를 앞에 붙인 바가 나타납니다 ({n} file(s) selected). 버튼은 선택 내용이 허용하는 것만 표시됩니다:

버튼	동작
History	대상 파일 또는 폴더의 이력을 엽니다.
Add	local only 파일을 추적 대상으로 둡니다. 최초 전송의 두 버튼 중 첫 번째입니다: 방금 만든 파일은 서버 측에 존재하지 않으므로 잠글 것이 없습니다.
Checkout	잠금을 획득합니다. 멱등적입니다: 이미 당신이 잠근 파일을 다시 잠가도 아무 일도 일어나지 않습니다.
Checkin	메시지 창을 연 뒤 전송합니다. 최초 전송의 두 번째 버튼이자, 이후 모든 전송의 버튼입니다.
Revert	잠금을 반납하고 서버 버전을 복원합니다. 로컬 변경 사항은 사라집니다.
Delete	파일을 삭제로 표시합니다. 삭제는 다음 checkin에 전송됩니다.
Download	선택한 파일을 서버에서 다시 다운로드합니다. 로컬에서 손상된 파일을 되찾는 데 유용합니다.

Pending 탭

현재 체크아웃되어, 당신 또는 다른 사용자에 의해 잠긴 파일. 두 섹션으로 구성됩니다:

• Your locks: checkin, revert, 또는 개별적으로 release 할 수 있습니다
• Other users' locks: 누가 잠금을 보유하는지 볼 수 있으며, Production 보드에 요청 카드 (request 배지) 를 만드는 Request release 버튼이 있습니다

관리자에게는 다른 사람의 잠금에 대한 Force unlock 버튼도 표시됩니다. 이는 보유자의 동의 없이 잠금을 release 합니다. 모든 force unlock은 감사됩니다.

History 탭

저장소의 커밋을 페이지 단위로 나열하며, 작성자, 날짜, 메시지, 변경된 파일을 함께 보여줍니다. 커밋을 클릭하면 세부 정보가 열립니다: 그 커밋의 파일 전체와 그 리비전 목록입니다.

각 커밋의 Get all 버튼으로, 그 리비전의 모든 파일의 로컬 사본을 다운로드할 수 있습니다 (안정된 상태를 되찾는 데 유용).

Production

Production 영역 (사이드바의 전용 항목) 은 저장소별 프로젝트 추적을 한데 모읍니다. Workspace는 파일 (Files, Pending, History) 에 집중합니다.

My tasks

당신에게 할당된 카드의 목록으로, 접근 가능한 모든 저장소에 걸쳐 집계됩니다.

Board

저장소별 칸반 보드로, 열은 설정 가능합니다 (기본값 To Do, In Progress, Review, Done). 각 카드는 우선순위 (low / normal / high / urgent), 라벨, 담당자, 마감일, 댓글, 에셋이나 커밋으로의 링크, 그리고 커버 이미지를 가집니다.

Dashboard

프로듀서의 콕핏: 프로젝트 상태 배너 (열린 블로커, 대기 중인 플레이테스트 리포트), 문제가 몰리는 구역, 이번 주 커밋, 프로젝트 용량, 그리고 마지막으로 공개된 빌드가 나열되며, 각 블록은 보드 또는 Games로 연결됩니다.

그 아래에는 캘린더 타임라인: 마일스톤, 플레이테스트 (일회성 또는 반복), 릴리스, 카드 마감일. 반복 플레이테스트는 매 발생마다 보드 카드를 자동으로 생성합니다.

Watchlist

경로 (glob 패턴) 를 감시하여, 그것을 건드리는 check-in에 대한 알림을 받습니다. 각 항목은 감시하는 경로와 따라가는 이벤트를 명시합니다.

Games

Games 영역은 프로젝트를 위해 공개된 내부 플레이테스트 빌드 를 나열합니다. 각 빌드는 버전, 구성 (DebugGame / Development / Shipping), 플랫폼 (Win64 / Mac / Linux), 크기, 릴리스 노트를 표시하며, 플랫폼에 맞춘 다운로드 버튼을 제공합니다.

이곳은 플레이테스터 의 접근 지점입니다: playtester 역할의 계정은 이 페이지만 볼 수 있고 (Workspace도 Production도 아님), 자신에게 열린 프로젝트의 빌드에만 접근합니다.

로컬 Changelist

📷 Screenshot · client-changelists

두 로컬 changelist (예를 들어 「default」와 「review」) 에 나뉜 체크아웃 파일.

체크아웃한 파일을 여러 개의 독립된 커밋으로 묶습니다. changelist는 당신의 워크스페이스에 로컬입니다 (서버로는 절대 전송되지 않음). 다음과 같은 경우에 유용합니다:

• 중요한 수정을 진행 중인 작업과 분리
• 모든 것을 섞지 않고, 여러 전송을 병행하여 준비
• WIP용 「default」 changelist와, checkin으로 나가는 「review」를 유지

Settings

클라이언트의 전역 환경설정 (%APPDATA%/uversion/uVersion/config/config.toml 에 저장):

설정	설명
Default Server address	로그인 페이지를 미리 채웁니다. 접속 때와 같은 분할: 고정된 https:// 접두사, 호스트, 포트. 비워 둘 수 있습니다.
Default Username	로그인 페이지를 미리 채웁니다.
Default Repository Path	복제 시 기본으로 제안되는 폴더.
Theme	System / Light / Dark.
Show hidden files	Files 탭에서 . 로 시작하는 파일을 표시합니다.
Auto-sync Interval (seconds)	선택 목록이 아니라 숫자 필드이며, 분이 아니라 초 로 지정합니다. 최소 0이며, 0이면 비활성화 됩니다 (자동 동기화).
Parallel Uploads	동시 업로드 수, 1부터 32까지.
Parallel Downloads	동시 다운로드 수, 1부터 32까지.
Avatar colour	인터페이스에서의 당신의 색 (보드 카드, 잠금, 활동상의 이니셜). 다른 것들과 달리, 이 설정은 서버 측에 저장됩니다: 기기에서 기기로 당신을 따라다니며 팀원들에게도 보입니다.

Unreal 패널

클라이언트가 워크스페이스에서 Unreal 프로젝트를 감지하면, Workspace의 오른쪽 위에 전용 동작 바가 나타납니다. 에디터 열기, 컴파일, 패키징을 IDE를 거치지 않고 클라이언트에서 직접 엔진에 지시합니다. 대부분의 동작은 C++ 프로젝트에만 해당합니다 (순수 Blueprint 프로젝트는 컴파일할 필요가 없습니다).

플러그인 상태 필

바의 맨 왼쪽에 있는 필은, 이 프로젝트에 대한 Unreal 플러그인의 상태를 나타냅니다. 클릭할 수 있습니다:

필	의미
Plugin <version> (초록)	플러그인이 설치되어 있고, 당신의 Unreal 버전에 대해 최신입니다.
Plugin installed (초록)	플러그인이 방금 프로젝트에 배치되었습니다.
Update ready (주황)	더 새로운 버전이 있습니다. 클라이언트가 스스로 설치하지는 않습니다: Unreal을 닫은 뒤 필을 클릭하세요.
Restart UE (주황)	Unreal 에디터가 열려 있습니다. 로드된 플러그인은 교체할 수 없습니다: 에디터를 닫고 다시 클릭하세요.
Set engine path (주황)	엔진 경로가 없습니다. 클릭하면 경로 선택기가 바로 열립니다.
Plugin n/a (주황)	이 Unreal 버전과 시스템 조합에 대해 공개된 바이너리가 없습니다.

엔진 경로

Unreal 설치 경로는 .uproject 의 EngineAssociation 으로부터 자동으로 해석됩니다 (Windows 레지스트리, LauncherInstalled.dat, 또는 소스 빌드). 이 경로는 아래의 모든 동작에 필요하며, 자동 해석은 특히 소스에서 컴파일한 엔진에서 실패합니다. 손으로 설정하는 곳은 다음과 같습니다.

1. 보조 동작 메뉴 열기

바에는 입력 필드도, Browse 버튼도, Auto-detect 버튼도 보이지 않습니다. 유일한 진입점은 Unreal 바의 맨 오른쪽에 있는 톱니바퀴 모양의 버튼 으로, 작은 셰브런을 동반하며 툴팁에는 More actions 라고 표시됩니다. 그 겉모습에는 엔진을 떠올리게 하는 것이 전혀 없으며, 그래서 찾지 못하는 것입니다.

2. Set Engine Path... 선택

Set Engine Path... 항목은 메뉴의 마지막에 있습니다. 그 부제는 현재 경로를, 없으면 Not configured 를 표시합니다: 문제가 거기에서 비롯되는지 아는 가장 빠른 방법입니다. 폴더 선택기가 열리며, 선택한 경로는 워크스페이스의 .uversion/config.toml 에 저장됩니다.

Open Editor

워크스페이스의 프로젝트에서 Unreal 에디터 (UnrealEditor) 를 실행합니다. 이 버튼은 멱등적 입니다: 에디터는 창을 표시하기까지 수십 초가 걸릴 수 있으므로 (특히 macOS / Linux), 그 사이 두 번째 클릭이 두 번째 인스턴스를 열지 않습니다. 에디터가 실행되는 동안 버튼은 「Opening…」을 표시합니다. 로컬에서 한 번도 컴파일하지 않은 C++ 프로젝트의 경우, 에디터를 여는 것은 먼저 프로젝트 파일 생성, 이어서 컴파일을 트리거합니다 (자동 동작 참조).

Compile

프로젝트를 컴파일합니다 (Unreal Build Tool). 출력은 통합 콘솔에 실시간으로 표시됩니다. C++ 프로젝트는 에디터가 열 수 있도록, 그리고 코드 변경을 반영하기 위해 컴파일되어야 합니다.

Sync 와 Status

이 두 버튼은 같은 바에 있으며, Files 탭에는 없습니다:

• Sync: 워크스페이스 전체를 서버에서 업데이트합니다. 대기 중인 파일이 있으면 그 수를 툴팁에 표시합니다. 이것이 클라이언트의 진짜 「sync」이며, 선택 분만 가져오는 Files 탭의 Download 버튼과 혼동하지 마세요.
• Status: 다른 사용자의 잠금을 포함한 서버 측 상태를 새로 고치고, Sync 버튼의 카운터를 다시 갱신합니다.

More actions 메뉴

더 드문 동작들은 바 오른쪽의 톱니바퀴 모양 버튼 뒤에 모여 있습니다 (위 스크린샷):

• Generate Project Files: IDE의 프로젝트 파일 (Visual Studio, Rider) 을 다시 생성합니다. 소스 파일을 추가하거나 삭제한 뒤, 또는 복제 후에 유용합니다.
• Publish Editor Binaries: 컴파일한 뒤, 최신 코드 커밋에 대응하는 에디터 바이너리를 공개합니다. 팀원들은 각자 재컴파일하는 대신 sync에서 이를 가져옵니다. Linux에서는 제공되지 않습니다.
• Force Sync: 로컬 파일을 덮어쓰며 다시 다운로드합니다. 메뉴에서 빨간색으로 표시되고, overwrites local 표시가 붙으며, 확인을 동반합니다. 잃어도 되는 워크스페이스에만 한정하세요.
• Set Engine Path...: 위에서 설명한 엔진 경로 설정.

Package

버튼의 이름은 Package 입니다. 「Package Game」은 그 툴팁에 지나지 않으며, 엔진 경로가 없을 때는 Set Engine Path first 로 바뀌고 버튼은 비활성화됩니다. RunUAT BuildCookRun 을 통해 게임을 패키징하고, 결과를 워크스페이스 루트의 Packages/{config}/ 에 보관합니다. 세 가지 구성 중에서 고를 수 있습니다:

구성	용도
DebugGame	디버그 빌드 (완전한 심볼, 최적화 없음).
Development	개발 빌드 (기본값): 최적화되어 있지만 개발 도구 포함.
Shipping	배포 빌드: 최적화됨, 개발 도구 없음.

Packages/ 폴더는 기본적으로 무시됩니다 (.uversionignore): 패키징된 것들은 버전 관리되지 않고, Publish Build 를 통해 배포됩니다.

Publish Build

패키징된 빌드를 내부 플레이테스트 버전 으로 공개합니다. 그것은 클라이언트의 Games 페이지에서 당신의 팀이 다운로드할 수 있게 됩니다 (playtester 역할, 또는 빌드 접근이 부여된 경우). 클라이언트는 Packages/{config}/ 를 스캔하여 파일을 전송하고 (서버 측에서 중복 제거) 이어서 매니페스트를 기록합니다.

Open project folder

워크스페이스 폴더를 시스템 파일 탐색기에서 엽니다 (Windows 탐색기, Finder, 또는 Linux에서는 xdg-open).

Stop

진행 중인 모든 빌드를 깔끔하게 중단합니다: 컴파일 과 패키징. 버튼은 중단된 빌드의 수를 표시합니다 (백그라운드에서 시작된 자동 컴파일이 함께 집계될 수 있습니다).

자동 동작

버튼 외에도, C++ 프로젝트가 항상 최신이며 컴파일 가능한 상태로 유지되도록, 클라이언트는 특정 Unreal 동작을 스스로 트리거합니다:

• check-in 전: 코드 파일이 변경되었다면, 프로젝트가 먼저 컴파일됩니다. 컴파일이 실패하면 check-in이 차단됩니다 (컴파일되지 않는 코드는 제출하지 않습니다).
• sync 후: sync가 코드를 다운로드했다면, 클라이언트는 프로젝트 파일을 다시 생성한 뒤 재컴파일합니다.
• 복제 후 첫 실행 (C++ 프로젝트): 에디터를 열 수 있게 되기 전에, 프로젝트 파일 생성 이어서 컴파일이 이루어집니다.

이 자동 빌드들은 엔진 잠금 (Unreal Build Tool -WaitMutex) 위에서 직렬화됩니다: 서로를 거부하지 않고 차례로 이어집니다. Stop 버튼은 이들도 중단합니다.