개발·검수·출시출시·배포 · 약 8분

APP DEVELOPMENT TERM

빌드·릴리스

소스코드를 실행 파일로 만들고 공개 후보로 정하는 과정

빌드는 소스코드와 자원을 실행 가능한 앱·웹 결과물로 만드는 과정이고, 릴리스는 검수한 특정 결과물을 사용자에게 제공할 공식 버전으로 정하는 과정입니다.

빌드릴리즈Release Build프로덕션 빌드

30초 이해

빌드는 실행할 결과물을 만드는 일이고 릴리스는 그 결과물을 어떤 사용자에게 언제 제공할지 정하는 일입니다

개발자가 작성한 소스코드는 그대로 앱 마켓에 올리거나 서버에서 실행할 수 없습니다. 필요한 코드와 이미지·설정을 모으고 변환해 Android App Bundle, iOS 앱 또는 웹 파일처럼 실행 가능한 결과물로 만드는 과정이 빌드입니다.

릴리스는 빌드된 결과물 중 검수를 통과한 하나를 공식 제공 대상으로 정하는 과정입니다. 실제 서버에 반영하는 배포, 마켓 심사, 일부 사용자부터 공개하는 단계적 출시가 뒤따를 수 있으므로 빌드 성공만으로 출시 완료라고 보지는 않습니다.

한 장으로 이해

소스코드가 검수 가능한 릴리스 결과물이 되는 과정

코드와 환경을 고정해 결과물을 만들고 서명·검수한 뒤 공개할 버전과 범위를 정합니다.

  1. 01

    코드·환경 고정

    포함할 기능과 설정, 외부 도구 버전을 확정합니다.

  2. 02

    빌드 생성

    소스와 자원을 실행·설치 가능한 결과물로 변환합니다.

  3. 03

    서명·검수

    운영용 인증 정보로 서명하고 실제 환경에서 확인합니다.

  4. 04

    릴리스 결정

    버전, 공개 대상·시점과 문제 발생 시 되돌릴 기준을 정합니다.

같은 코드라도 환경과 설정이 다르면 다른 결과물이 될 수 있으므로 무엇을 언제 만들고 검수했는지 추적할 수 있어야 합니다.

언제 사용하는 개념인가요?

01

테스트 앱을 전달할 때

특정 코드와 테스트 환경으로 설치 가능한 결과물을 만들어 검수자에게 제공합니다.

02

마켓·서버 출시를 준비할 때

운영 설정, 서명, 버전과 포함 기능을 고정한 릴리스 후보를 만듭니다.

03

긴급 수정과 되돌리기를 할 때

문제가 난 버전과 직전 정상 결과물을 구분해 수정본을 만들거나 이전 상태로 복구합니다.

왜 중요한가요?

  • 검수한 결과물과 공개한 결과물을 맞춥니다

    테스트하지 않은 코드나 다른 환경 설정이 실수로 운영에 들어가는 일을 줄입니다.

  • 서명과 운영 비밀값을 분리합니다

    개발용·운영용 인증 정보와 서버 주소가 빌드 종류에 맞게 사용되는지 확인할 수 있습니다.

  • 문제 버전을 추적하고 복구합니다

    어떤 코드·설정·버전이 사용자에게 제공됐는지 알아야 같은 결과를 재현하고 되돌릴 수 있습니다.

실제 상황 예시

클래스 예약 앱의 새 버전을 릴리스한다면

예약 기능 수정본을 빌드한 뒤 검수·심사·공개와 복구 흐름을 분리해 관리합니다.

릴리스 후보 확인

  • 포함 기능과 수정 내역 고정
  • 운영 서버·결제·알림 설정 확인
  • 운영용 서명과 버전 번호 적용
  • 실제 기기 핵심 예약 흐름 검수

공개와 문제 대응

  • 내부·시험·전체 공개 범위 결정
  • 마켓 심사 상태와 공개 시점 기록
  • 오류율·문의·핵심 기능 관찰
  • 직전 정상 버전과 긴급 수정 절차 준비

‘최신 빌드’ 대신 코드 식별값·버전·환경·검수 결과가 연결된 릴리스 후보 하나를 지정해야 혼선을 줄일 수 있습니다.

자주 하는 오해

빌드가 성공하면 출시할 수 있다

코드를 결과물로 만드는 데 성공한 것입니다. 기능 검수, 운영 설정, 서명, 정책과 공개 계획을 별도로 확인해야 합니다.

릴리스와 배포는 같은 말이다

릴리스는 제공할 공식 버전을 정하는 더 넓은 과정이고, 배포는 결과물을 특정 환경에 반영하는 실행 단계입니다.

개발용 앱이 되면 운영용 앱도 같다

서버 주소, 인증 정보, 최적화와 권한이 다를 수 있으므로 운영용 결과물을 별도로 빌드하고 검수해야 합니다.

우리 서비스에 적용할 때 확인하세요

  1. 1이번 결과물에 포함된 기능과 코드 상태를 식별할 수 있나요?
  2. 2개발·테스트·운영 환경의 주소와 인증 정보가 분리됐나요?
  3. 3운영용 서명 계정과 키의 소유·백업 담당이 분명한가요?
  4. 4실제 공개할 결과물 자체를 핵심 시나리오로 검수했나요?
  5. 5문제가 생기면 공개 중단·긴급 수정·이전 버전 복구 중 무엇을 하나요?

공식 참고

서비스 기준은 공식 문서에서 다시 확인하세요

다음 자료

이해한 내용을 바로 적용해보세요

변경을 식별하는 버전, 자동 검사·전달을 돕는 CI/CD와 실제 환경에 반영하는 배포를 이어서 확인하세요.

빌드 파일 이름보다 코드·환경·서명·검수 결과가 연결됐는지 확인하세요

공개할 결과물을 하나로 식별하고 되돌릴 기준까지 정하면 출시 실수를 줄일 수 있습니다.