QA에게 빌드 전달하기 — 무엇을 함께 보내야 리포트가 쓸모 있어지나

빌드를 넘기는 순간 리포트 품질이 결정됩니다. 빌드 식별자, 변경 요약, 알려진 이슈, 로그 회수 경로까지 — 파일과 함께 보내야 할 맥락을 정리합니다.

  • unity
  • qa
  • build

"재현이 안 됩니다"로 닫히는 티켓의 원인 중 환경 차이 항목에는 "QA가 본 빌드와 개발자가 재현하는 빌드가 다른 경우"가 있었습니다. 이 글은 그 지점 하나를 파고듭니다. 빌드를 QA에게 넘기는 순간, 파일 말고 무엇을 함께 보내야 하는지의 문제입니다.

"어느 빌드였죠?"라는 질문 자체가 실패다

개발자가 티켓을 열고 가장 먼저 확인해야 할 건 재현 절차가 아니라 어느 빌드에서 났는가입니다. 그런데 리포트에 이 정보가 없으면 개발자는 QA에게 되묻습니다. QA는 어제 받은 링크를 다시 찾아야 하고, 그 링크가 오늘 최신 빌드로 덮어써졌으면 정확히 답할 방법이 없습니다. 이 왕복은 재현까지 걸리는 시간을 늘립니다. 빌드 식별자가 리포트에 자동으로 남는 구조가 아니면, "어느 빌드였죠"라는 질문은 매 티켓마다 반복됩니다.

빌드와 함께 반드시 가야 할 것

항목없을 때있을 때
빌드 식별자QA 기억에 의존, 부정확화면에서 바로 확인
변경 요약QA가 어디를 볼지 모름이번 빌드에서 뭐가 바뀌었는지 알고 테스트
알려진 이슈 목록같은 버그 중복 리포트새 버그에만 집중
로그 위치 안내QA가 로그 위치를 다시 찾아야 함재현 실패 시에도 로그를 확인할 수 있음
로그 회수 경로로그를 찾고 보내는 일이 번거로움압축·전송 절차를 짧게 유지

빌드 식별자와 변경 요약은 QA가 "무엇을 테스트해야 하는가"를 판단하도록 돕습니다. 알려진 이슈 목록은 이미 확인된 버그의 중복 보고를 줄이는 데 도움이 됩니다. 로그 관련 두 항목은 서로 다른 문제입니다. 위치 안내는 기존 글에서 OS·플랫폼별로 정리했으니 QA에게 그 링크를 보내면 됩니다. 회수 경로는 안내만으로 해결되지 않습니다 — 로그를 찾고 압축하고 업로드하는 과정이 길수록 빠뜨리기 쉬워집니다. 절차를 줄이면 문서화만 더하는 것보다 실제 회수에 도움이 됩니다.

빌드 식별자는 화면에 있어야 한다

빌드 식별자가 문서나 배포 노트에만 있으면 QA가 리포트를 쓰는 시점에 그걸 찾아 옮겨 적어야 합니다. 이 한 단계가 자주 생략됩니다. 화면 구석에 떠 있으면 QA는 스크린샷 한 장만 찍어도 어느 빌드인지 자동으로 남습니다.

// 빌드 시점에 버전 + 커밋 해시를 심어서 화면에 노출한다
public static class BuildIdentity
{
    // PlayerSettings 의 bundleVersion 을 그대로 사용
    public static string Version => Application.version;

    // 커밋 해시는 CI 빌드 스크립트가 이 상수를 치환해서 채운다
    // (예: `git rev-parse --short HEAD` 결과를 빌드 직전에 sed 로 주입)
    public const string CommitHash = "__COMMIT_HASH__";

    public static string Label => $"{Version} ({CommitHash})";
}

#if DEVELOPMENT_BUILD || QA_BUILD
public class BuildIdentityOverlay : MonoBehaviour
{
    void OnGUI() => GUI.Label(new Rect(8, Screen.height - 24, 400, 24), BuildIdentity.Label);
}
#endif

CommitHash 같은 자리표시자를 빌드 파이프라인에서 실제 값으로 치환하는 방식이 핵심입니다. 사람이 버전 번호를 손으로 올리는 절차에 의존하면 언젠가 빠집니다. 커밋 해시까지 있으면 "같은 버전 번호인데 다른 바이너리"인 상황(핫픽스 재빌드 등)도 구분됩니다.

전달 수단은 갱신 인지가 기준이다

공유 폴더, 내부 배포 도구, 스토어 테스트 트랙 중 무엇을 쓰든 기준은 하나입니다 — QA가 새 빌드가 올라왔다는 걸 알아차릴 수 있는가. 도구마다 알림 방식과 설정이 다르므로, 새 빌드가 게시됐을 때 QA에게 버전과 변경점이 실제로 전달되는지 확인해야 합니다. 수단보다 "갱신을 놓치지 않는가"가 먼저입니다. 아무리 잘 만든 빌드도 그 사실이 QA에게 닿지 않으면, QA 입장에서는 아직 없는 빌드와 다르지 않습니다.

정리

빌드 전달은 파일을 넘기는 일이 아니라 맥락을 넘기는 일입니다. 식별자, 변경 요약, 알려진 이슈, 로그 회수 경로 — 이 넷이 빠진 빌드는 QA에게 "알아서 찾아보라"고 던지는 것과 다르지 않습니다. 이 넷을 챙기는 데 드는 시간은 길어야 몇 분이지만, 빠뜨렸을 때 되묻고 다시 찾는 왕복에 드는 시간은 그보다 훨씬 깁니다. 이 맥락이 채워진 상태에서도 놓치기 쉬운 게 Development Build 체크박스 하나입니다. 이 설정이 QA 빌드에서 실제로 뭘 켜고 끄는지는 다음 글에서 다룹니다.

저희 Rekon의 핫키 리포트에는 Unity 버전·앱 버전·씬·기기 같은 실행 맥락이 자동으로 담깁니다. 다만 이 정보가 고유한 커밋이나 재빌드까지 식별한다고 가정해서는 안 됩니다. 정확한 추적이 필요하다면 앞서 본 예시처럼 커밋 해시 등 팀의 빌드 식별자도 함께 노출하세요.