Development Build 설정 — QA 빌드에 뭘 켜고 뭘 끄나
Unity의 Development Build와 관련 옵션을 QA 빌드에 맞게 설정하는 방법, 그리고 출시 후보 빌드에서도 확인해야 할 진단 정보를 정리합니다.
- unity
- build
- profiler
빌드를 QA에게 넘길 때 함께 가야 할 것을 정리했다면, 다음 질문은 그 빌드 자체를 어떻게 만드느냐입니다. Build Profiles(구버전에서는 Build Settings)의 Development Build를 켜면 진단용 빌드를 만들 수 있고, 추가 옵션도 선택할 수 있습니다. QA 빌드에 맞게 이 조합을 고르지 않으면, 리포트는 오는데 정작 진단에 필요한 정보는 빠져 있는 상황이 생깁니다.
Development Build가 켜거나 선택할 수 있게 하는 것들
기본 동작과 별도로 선택해야 하는 옵션을 구분해서 봐야 합니다.
| 항목 | 켜지는 조건 | 효과 |
|---|---|---|
DEVELOPMENT_BUILD 심볼 | Development Build 체크 | 조건부 컴파일로 QA 전용 코드 분기 가능 |
| 화면 워터마크 | 플랫폼·설정에 따라 표시 | 표시되는 환경에서는 빌드 종류를 구분하는 데 도움 |
| Profiler 연결 | Development Build 체크 | Unity Profiler를 빌드에 직접 붙일 수 있음 |
| Autoconnect Profiler | 체크 시 하위 옵션으로 노출 | 실행과 동시에 Profiler 자동 연결 시도 |
| Deep Profiling Support | 체크 시 하위 옵션으로 노출 | 함수 호출 단위까지 계측 — 오버헤드가 큼 |
| Script Debugging | 지원 플랫폼에서 하위 옵션으로 노출 | C# 디버거를 빌드에 attach 가능; WebGL은 미지원 |
로그와 스택트레이스가 빌드에서 구체적으로 어떻게 달라지는지는 IL2CPP·release 빌드 편에서 이미 다뤘습니다. 여기서는 반복하지 않고, 이 설정들을 QA 빌드에서 어떻게 조합할지에 집중합니다.
QA 빌드에 켤 것
Development Build는 기본으로 켭니다. Profiler 연결과 DEVELOPMENT_BUILD 심볼을 이용한 QA 전용 진단 코드가 필요할 때 유용합니다. 워터마크가 표시되는 환경이라면 스크린샷에서 빌드 종류를 구분하는 데도 도움이 됩니다. 로그와 스택트레이스의 상세 수준은 별도 설정과 빌드 환경에도 좌우됩니다.
// QA 빌드에서만 켜는 진단 오버레이 — release 빌드에서는 컴파일에서 아예 제거된다
#if DEVELOPMENT_BUILD
using UnityEngine;
using UnityEngine.SceneManagement;
public class QaDiagnosticsOverlay : MonoBehaviour
{
void OnGUI()
{
float fps = Time.unscaledDeltaTime > 0f ? 1f / Time.unscaledDeltaTime : 0f;
GUI.Label(new Rect(8, 8, 300, 20), $"FPS: {fps:F0}");
GUI.Label(new Rect(8, 28, 300, 20), $"Scene: {SceneManager.GetActiveScene().name}");
}
}
#endif
Autoconnect Profiler는 상황에 따라 결정합니다. QA 머신에서 Profiler에 자동 연결해 실시간으로 지켜볼 계획이면 켜두는 게 편합니다. 그런 계획이 없다면 굳이 켤 이유가 없습니다.
QA 빌드에서 끌 것
Deep Profiling Support는 기본으로 끕니다. 함수 호출 수준까지 계측할 수 있게 하지만 오버헤드가 큽니다. 이 설정으로 측정한 끊김은 게임 자체의 성능과 계측 비용을 구분해 해석해야 합니다. 원인 분석이 필요할 때 별도 빌드에서 의도적으로 사용하세요.
Script Debugging도 기본으로 끕니다. 디버거를 붙여야 할 때 선택하는 옵션입니다. 디버깅용 정보와 실행 환경이 달라질 수 있으므로, 디버거를 붙일 계획이 없는 일반 QA 빌드에서는 별도로 켤 필요가 없습니다.
함정 — dev build 성능은 출시 성능이 아니다
Development Build와 release 빌드는 같은 성능 조건이 아닙니다. DEVELOPMENT_BUILD 분기로 늘어난 코드 경로와 활성화한 진단 옵션이 측정값에 영향을 줄 수 있습니다. QA가 dev build에서 측정한 FPS를 "출시 성능"으로 보고하면 잘못된 결론으로 이어집니다. 프레임 드랍 자체의 원인 분류는 끊김 진단 1편과 계측 실전 편에서 다뤘습니다 — 그 계측을 dev build에서 했다면, 결과에 "dev build 기준"이라는 단서를 반드시 함께 남겨야 합니다.
릴리스 빌드로 QA를 돌려야 할 때
성능 검증이나 스토어 제출 전 최종 확인처럼 출시 그대로의 동작이 필요한 시점에는 release 빌드로 QA를 돌려야 합니다. 이때 달라지는 진단 조건도 함께 확인해야 합니다.
- 개발 빌드용 진단 설정 — 스택트레이스의 파일·줄 정보는 빌드와 심볼 설정에 따라 달라지므로 출시 후보 빌드에서 직접 확인해야 합니다
- 개발 빌드에 연결하던 Profiler 워크플로 — 같은 방식으로 계측할 수 있다고 가정하지 말고 출시 후보 빌드에서 별도로 검증해야 합니다
- 화면 워터마크 — 이를 사용해 빌드를 구분했다면, 출시 후보 빌드에는 별도의 빌드 식별자를 남겨야 합니다
DEVELOPMENT_BUILD분기 코드 전부 — QA 전용 오버레이나 진단 로그도 함께 사라집니다
진단 수단이 달라지더라도 release 빌드로 QA를 돌려야 하는 이유가 있습니다. 스트리핑이나 조건부 컴파일의 영향처럼 dev build에서는 놓칠 수 있는 문제가 이 시점에야 드러날 수 있습니다.
정리
Development Build는 스위치 하나가 아니라 스위치 묶음입니다. QA 빌드는 기본적으로 Development Build를 켜고 Deep Profiling과 Script Debugging은 끄는 조합에서 시작하되, 출시 직전에는 release 빌드로 최소 한 번은 같은 시나리오를 돌려야 합니다. 두 빌드가 서로 다른 것을 보여준다는 전제를 깔고 QA 일정을 짜는 것이 함정을 피하는 가장 확실한 방법입니다.
저희 Rekon은 Development Build 전용 코드에 의존하지 않도록 런타임 캡처를 구성했습니다. 다만 영상 캡처는 데스크톱 환경의 FFmpeg가 필요하고 모바일 빌드에서는 지원하지 않습니다. 출시 후보 빌드에 적용할 때는 대상 플랫폼에서 핫키와 저장된 캡처를 직접 확인하세요.