Preflight QC

Preflight QC는 전문적인 릴리스 품질 관리(QC)를 제공하는 프리미엄 추가 기능이에요. 릴리스를 제출하면 Preflight QC가 메타데이터, 발매일, 오디오, 아트워크, AI 콘텐츠, 카탈로그 식별자, 이전 배급 이력, 라이선스 서류까지 처음부터 끝까지 분석해요. 명확하고 실행 가능한 품질 리포트를 받아 보고, 지적된 사항을 원하는 속도로 수정한 뒤, 만족스러울 때 릴리스를 검토로 확정하세요.

레이블과 API 연동 개발자에게 Preflight QC는 하나의 빌딩 블록이에요. 품질 리포트를 프로그램 방식으로 가져와 자체 QA 파이프라인에 연결하고, 내부 승인 프로세스의 관문으로 삼고, 릴리스를 자동으로 검토에 확정할 수 있어요. 품질 기준은 회원님의 팀이 정하고, 분석은 Preflight QC가 맡아요.

깨끗한 상태로 도착한 릴리스는 검토를 빠르게 통과해요. Preflight QC는 제출 전에 그 상태로 만들어 줘요.

Preflight QC란

계정에서 Preflight QC를 켜면, 유통을 위해 제출한 릴리스가 검토 대기열로 곧바로 들어가지 않아요. 대신 릴리스는 검토 전 대기(“회원님의 확인 대기 중”)로 들어가고, 그동안 Preflight QC가 품질 분석을 실행해요. 분석 대상은 메타데이터, 발매일, 오디오, 아트워크, AI 콘텐츠, 카탈로그 식별자, 이전 배급 이력, 라이선스 서류예요. 그 결과가 품질 리포트이고, 이를 어떻게 활용할지는 회원님에게 달려 있어요.

자체 QA 워크플로(API). 카탈로그를 품질 분석에 통과시키고, 리포트를 프로그램 방식으로 가져와 자체 QA 파이프라인에서 처리하고, 그 결과를 내부 승인 프로세스의 관문으로 삼은 뒤, 자신의 기준을 통과한 릴리스만 검토로 확정하세요. 연동을 위한 API 사용하기를 참고하세요.
앱에서의 워크플로. 릴리스 페이지에서 리포트를 읽고, 지적된 사항을 수정한 뒤, 만족스러울 때 확정하세요.

어느 쪽이든 릴리스를 일반 검토 대기열로 옮기는 것은 확정이에요. 회원님이 승인하기 전에는 아무것도 검토에 들어가지 않아요.

Preflight QC는 검토 전에 품질 단계를 추가해요. 검토 이후의 흐름은 바뀌지 않아요. 확정하면 릴리스는 다른 릴리스와 동일한 검증 및 검토 절차를 거쳐요.

Preflight QC 사용 방법

Preflight QC는 저희 팀이 계정별로 활성화하는 프리미엄 추가 기능이에요. 회원님의 계정에서 켜려면 저희 영업 팀에 문의하시고 Preflight QC를 원한다고 알려 주세요.

활성화되면 다음에 릴리스를 유통을 위해 제출할 때 새로운 대기 및 확정 단계가 표시돼요.

Preflight QC 워크플로

Preflight QC를 켠 릴리스가 제출부터 검토까지 거치는 전체 흐름은 다음과 같아요.

1. 릴리스를 유통을 위해 제출하기

평소처럼 릴리스를 만들고 완성한 다음, 유통을 위해 제출하세요. Preflight QC가 켜져 있으면 이 동작은 릴리스를 즉시 검토 대기열에 넣지 않아요. 대신 릴리스는 검토 전 대기로 이동하고 회원님의 확인 대기 중으로 표시돼요.

2. 품질 분석이 실행됨

릴리스가 대기 중인 동안 Preflight QC가 해당 릴리스를 처음부터 끝까지 분석해요. 분석 범위는 다음과 같아요.

메타데이터: 제목, 아티스트, 크레딧, 그 밖의 릴리스 및 트랙 세부 정보
발매일: 발매일 설정과 릴리스 버전
오디오: 업로드한 오디오 파일
아트워크: 커버 이미지
AI 콘텐츠: AI 사용을 신고했는지, 그리고 저희가 감지한 AI 생성 음원이나 커버
카탈로그 식별자: ISRC가 유효한지, 그리고 해당 녹음을 다른 권리자가 이미 주장했는지
이전 배급 이력: 릴리스나 트랙이 다른 배급사를 통해 이미 스토어에 올라가 있는지
라이선스: 커버, 샘플 또는 유사한 것에 증빙 서류가 필요한 경우

분석은 보통 업로드와 트랜스코딩이 완료된 후 몇 분 이내에 끝나요. 아직 실행 중인 동안 품질 리포트는 검사가 진행 중임을 표시하며 아직 문제를 나열하지 않아요.

3. 품질 리포트 읽기

분석이 끝나면 릴리스의 품질 리포트를 열어 주의가 필요한 사항이 있는지 확인하세요. 두 곳에서 읽을 수 있어요.

퍼블릭 API를 통해(자체 QA 파이프라인용). 아래의 API 사용하기를 참고하세요.
앱 내 릴리스 페이지.

리포트는 각 문제를 명확한 제목과 무엇을 수정해야 하는지 설명하는 메시지와 함께 나열해요. 각 필드를 읽는 방법은 품질 리포트 이해하기를 참고하세요.

4. 지적된 사항 수정하기

리포트의 문제를 하나씩 처리하세요.

메타데이터 문제: 릴리스나 트랙의 세부 정보를 편집하세요.
오디오 또는 아트워크 문제: 해당 파일을 교체하세요.
피드백을 요청하는 문제: 문제의 메모 스레드에 답글을 달거나, 요청된 서류(예: 커버나 샘플의 라이선스)를 업로드하세요.

릴리스가 대기 중인 동안 편집하면 현재 리포트가 stale(오래된 상태)로 표시돼요. 지적 사항이 릴리스의 최신 상태를 더 이상 반영하지 않게 돼요. 원하는 만큼 편집한 다음, 앱의 릴리스 페이지에서 또는 연동의 경우 리프레시 엔드포인트를 통해 최신 분석을 요청하세요. 분석이 다시 실행되고 리포트가 새로운 결과로 갱신돼요. 이 과정은 필요한 만큼 반복할 수 있지만, 릴리스당 시간당 시작할 수 있는 최신 분석 횟수에는 공정 사용 한도가 있어요.

5. 릴리스 확정하기

리포트가 깨끗해지면, 또는 필요한 사항을 모두 처리했으면 릴리스를 확정하세요. 앱에서는 릴리스의 확정 버튼이고, 연동에서는 확정 엔드포인트예요.

확정하면 릴리스가 대기에서 빠져나와 일반 검토 대기열로 이동해요. 확정하려면 완료된 최신 분석이 필요해요. 마지막 실행 이후 릴리스를 편집했다면 리포트가 stale 상태이므로, 최신 분석을 요청하고 그것이 끝난 뒤에 확정하세요.

6. 일반 검토

확정 후 릴리스는 다른 릴리스와 똑같이 검토돼요. 검토 중에 어떤 일이 일어나는지, 소요 시간, 가능한 결과는 검증 및 검토를 참고하세요.

품질 리포트 이해하기

품질 리포트는 두 부분으로 이루어져 있어요. 문제 목록과, 분석 실행에 대한 작은 리포트 세부 정보 블록이에요.

문제

리포트의 각 문제는 살펴봐야 할 사항을 하나씩 설명해요. 회원님이 다루게 될 필드는 다음과 같아요.

필드	무엇을 알려주는지
제목	문제에 대한 짧고 알기 쉬운 이름.
메시지	문제가 무엇이며 어떻게 대처해야 하는지.
심각도	문제의 중요도로, 우선순위를 정하는 데 도움이 돼요.
차단(Blocking)	확정하기 전에 문제를 해결해야 하는지 여부(아래 참고).
피드백 필요	문제에 회원님의 서면 답변이나 업로드한 서류가 필요한지 여부.
맞춤 설명	제공되는 경우, 회원님의 릴리스에 고유한 추가 세부 정보.
영향받는 트랙	문제가 적용되는 트랙. 릴리스 수준의 문제는 특정 트랙을 나열하지 않아요.
증거	날짜, 중복, 사전 유통 문제에서 저희가 찾은 일치하는 릴리스로, 충돌을 직접 확인할 수 있어요(아래 참고).

차단 대 정보 제공

차단 문제는 릴리스를 검토로 확정하기 전에 해결해야 해요. 설명대로 수정하고 최신 분석을 실행하면 리포트에서 사라져요.
정보 제공 문제는 살펴볼 만한 점을 알리기 위한 것이지만, 확정을 막지는 않아요. 검토한 뒤 준비되면 확정하세요.

피드백이 필요한 문제

일부 문제는 편집만으로는 해결되지 않아요. 서면 설명이나 증빙 서류(예: 커버나 샘플의 라이선스)처럼 회원님으로부터 무언가가 필요해요. 이런 문제는 피드백 필요로 표시돼요. 해결하려면 확정하기 전에 문제의 메모 스레드에 답글을 달거나 요청된 서류를 업로드하세요.

문제에 담긴 증거

일부 문제에는 추측 없이 플래그를 확인할 수 있도록 증거가 포함돼요. 저희가 회원님의 릴리스와 대조한 기존 릴리스예요. 날짜, 중복, 사전 유통 문제에서 볼 수 있어요. 각 일치 항목은 일치한 트랙의 제목과 아티스트, 해당 릴리스 제목, 발매일, ISRC와 함께, 그 릴리스가 서비스 중인 스토어로의 링크, 그리고 영향받는 회원님의 트랙을 보여줘요. 트랙당 최대 3개의 일치 항목이 표시돼요. 어떻게 대응할지 결정하기 전에, 증거를 사용해 충돌이 실제인지(예: 회원님 자신이 이전에 업로드한 것인지)를 확인하세요.

리포트 세부 정보

문제와 함께, 리포트에는 분석 실행에 대한 몇 가지 세부 정보가 포함돼요.

필드	무엇을 알려주는지
generated_at	현재 리포트가 생성된 시각. 첫 분석이 아직 실행 중인 동안에는 비어 있어요.
checks_in_progress	분석이 아직 실행 중인 동안에는 `true`. 끝날 때까지 문제 목록은 비어 있어요.
stale	마지막으로 완료된 분석 이후 릴리스(또는 그 트랙 중 하나)를 편집하면 `true`가 되며, 지적 사항이 현재 상태를 더 이상 반영하지 않아요. 어떤 편집이든 해당돼요. 리포트를 갱신하려면 최신 분석을 요청하세요.
hold	릴리스가 현재 검토 전 대기 상태인지 여부.
review_status	릴리스의 현재 검토 상태.
release_status	검토 전용 상태와 함께 표시되는, 릴리스 자체의 전반적인 상태.
profile	이 릴리스에 적용된 품질 프로파일로, 그 이름과 버전을 포함해요.

연동을 위한 API 사용하기

LabelGrid 퍼블릭 API 위에 개발하는 경우, Preflight QC를 자체 파이프라인에 연결할 수 있어요. 각 릴리스를 품질 분석에 통과시키고, 리포트를 자체 QA 워크플로로 가져오고, 내부 승인 프로세스의 관문으로 삼고, 자신의 도구에서 검토로 확정하세요. Preflight QC는 이를 위한 세 개의 엔드포인트를 제공하며, 모두 퍼블릭 API의 나머지 부분과 동일한 Bearer 토큰 인증을 사용해요. 완전하고 항상 최신인 요청 및 응답 스키마는 API 레퍼런스를 참고하세요.

Webhook: 리포트가 준비되면 알림 받기

결과를 폴링하는 대신, 리포트가 준비되는 순간 LabelGrid가 알려주도록 할 수 있어요. release.preflight.report_ready webhook 이벤트를 구독하세요. 이 이벤트는 Preflight QC가 검토 전 대기 상태인 릴리스의 분석을 마치는 즉시 발생하며, 회원님이 요청한 재분석이 완료될 때마다도 발생해요. 분석 주기당 정확히 하나의 이벤트를 받아요.

LabelGrid의 다른 릴리스 webhook 이벤트를 구독하는 것과 동일한 방법으로, 앱의 webhook 설정에서 또는 API를 통해 구독하세요. 각 이벤트는 실행 결과의 간결한 요약을 담고 있으며, 문제 자체는 절대 담지 않아요.

릴리스 식별자: release_id, label_id, release_cat, release_title.
generated_at: 이 리포트가 생성된 시각. 리포트 자체의 generated_at과 일치해요.
profile: 카운트를 계산한 기준이 된 품질 프로파일로, {name, version} 형식이에요.
counts: blocking, informational, requires_feedback 합계. requires_feedback 카운트는 다른 두 개와 겹쳐요.

카운트를 보고 대응이 필요한지 판단한 다음, 자세한 내용은 리포트 본문을 가져와 확인하세요. 권장 연동 패턴은 다음과 같아요.

release.preflight.report_ready를 구독하세요.
각 이벤트가 발생하면 품질 리포트 가져오기를 호출해 전체 문제를 읽으세요.
수정 후 재실행: 대기 중인 릴리스를 편집한 뒤 리프레시 엔드포인트를 호출해 최신 분석을 시작하세요. 완료되면 webhook이 다시 발생해요.
릴리스가 회원님의 기준을 통과하면 자신의 도구에서 판단하고 확정하세요.

전체 페이로드 레퍼런스와 webhook 동작 방식(서명, 재시도, 엔벨로프)은 Webhooks를 참고하세요.

품질 리포트 가져오기

GET /api/public/releases/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

릴리스의 현재 품질 리포트를 반환해요. 응답에는 다음이 포함돼요.

issues[]: 문제당 한 개의 항목이며, 각각 id, code(안정적인 문자열, 문제 코드 다루기 참고), title, message, status, severity, is_blocking, requires_feedback, custom_description, affected_tracks를 포함해요. 날짜, 중복, 사전 유통 문제에서는 항목에 evidence 배열도 포함돼요(아래 참고).
report: generated_at, checks_in_progress, stale, hold, review_status, release_status, profile(name과 version을 가진 객체). stale은 마지막으로 완료된 분석 이후 릴리스나 그 트랙 중 하나가 편집되면 true가 돼요. 확정하기 전에 리프레시 엔드포인트로 분석을 다시 실행하세요.

분석이 아직 실행 중인 동안 리포트는 빈 issues 목록과 함께 checks_in_progress: true를 반환해요. webhook을 사용하고 싶지 않다면, generated_at이 설정될 때까지 이 엔드포인트를 폴링하세요. 보통 업로드와 트랜스코딩이 끝난 후 몇 분이면 설정돼요. 그런 다음 문제를 읽으세요. 대신 리포트가 준비되는 순간 알림을 받으려면 리포트 준비 완료 webhook을 사용하세요.

분석이 끝난 후의 응답 예시:

{
  "issues": [
    {
      "id": "12345",
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "status": "confirmed",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456],
      "evidence": [
        {
          "affected_track_id": 456,
          "track_title": "Matched track title",
          "artist": "Matched artist",
          "release_title": "Matched release",
          "release_date": "2024-03-01",
          "isrc": "USRC12345678",
          "store_url": "https://…"
        }
      ]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "stale": false,
    "hold": true,
    "review_status": "…",
    "release_status": "…",
    "profile": { "name": "quality_report", "version": 2 }
  }
}

각 evidence 항목은 회원님의 릴리스와 일치한 기존 릴리스 하나를 설명해요. affected_track_id(일치가 적용되는 회원님의 트랙), 일치한 track_title, artist, release_title, release_date, isrc, 그리고 일치 항목이 서비스 중인 스토어 페이지를 가리키는 store_url을 포함해요. 트랙당 최대 3개의 일치 항목이 나열되며, 이 키는 위의 문제 종류에만 존재해요.

릴리스를 검토로 확정하기

POST /api/public/releases/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

릴리스를 대기에서 빼내 일반 검토 대기열로 옮겨요. 앱의 확정 버튼에 해당하는 API예요.

확정하려면 완료된 최신 분석이 필요해요. 처리해야 할 충돌은 두 가지예요.

409 checks_in_progress: 분석이 아직 실행 중이에요. 리포트 준비 완료 webhook을 기다리거나(또는 generated_at이 설정될 때까지 폴링하고) 그런 다음 다시 시도하세요.
409 checks_stale: 마지막으로 완료된 분석 이후 릴리스가 편집되었어요(report.stale이 true). 리프레시 엔드포인트를 호출하고, 최신 리포트를 기다린 뒤 확정을 다시 시도하세요.

문제 코드 다루기

품질 리포트 위에 로직을 구축한다면 문제의 code를 기준으로 삼으세요.

code는 안정적인 문자열이에요. 슬러그 형식(예: audio.trailing-silence)으로, 시스템에서 코드를 매핑하고 그 위에 로직을 구축해도 안전해요.
제목과 메시지는 사람이 읽는 문구예요. 시간이 지나면서 다듬어질 수 있으니, 로직을 텍스트에 의존하지 말고 표시 용도로만 사용하세요.
새로운 코드가 추가될 수 있어요. Preflight QC의 범위가 확장되면서 새 코드가 등장해요. 인식할 수 없는 코드는 일반적으로 처리하세요. 실패하는 대신 응답의 title과 message를 그대로 표시하면 돼요.
중요한 코드는 리포트가 알려줘요. 릴리스를 Preflight QC에 통과시키다 보면, 회원님의 카탈로그와 관련된 코드가 자신의 품질 리포트에 자연스럽게 나타나요.
분석이 다루는 범위. 문제는 다음 카테고리로 나뉘어요: 릴리스 및 트랙 메타데이터, 릴리스 날짜와 버전, 오디오 품질, 아트워크, AI 콘텐츠, 카탈로그 식별자, 이전 배급 이력, 라이선스 및 서류.

문제 카탈로그

자체 QA 워크플로를 구축할 때 문제를 매핑하려면, 전체 카탈로그를 프로그램 방식으로 가져오세요.

GET /api/public/issue-definitions
Authorization: Bearer YOUR_API_TOKEN

품질 리포트에 나타날 수 있는 모든 문제를 안정적인 문자열 코드를 키로 반환하며, 각 항목에는 제목, 메시지 템플릿, 심각도, 차단 플래그, requires_feedback, 그리고 그 카테고리(type)가 포함돼요. 응답에는 카탈로그를 계산한 기준이 된 품질 프로파일도 {name, version} 형식으로 포함돼요. 이 엔드포인트는 Preflight QC 추가 기능이 있는 계정만 사용할 수 있어요.

자주 묻는 질문

분석이 아직 실행 중이면 어떻게 되나요?

리포트는 아직 문제가 나열되지 않은 채로 checks_in_progress: true를 표시해요. 제출 직후에는 정상이에요. 업로드와 트랜스코딩이 끝난 후 몇 분 기다렸다가 다시 확인하세요. 앱에서는 리포트가 자동으로 갱신돼요. API에서는 준비되는 순간 알림을 받도록 리포트 준비 완료 webhook을 구독하거나, generated_at이 설정될 때까지 폴링할 수 있어요.

대기 중에 릴리스를 편집할 수 있나요?

네, 원하는 만큼 자유롭게 편집하세요. 검토 전 대기에 있는 릴리스는 계속 완전히 편집할 수 있어요. 편집은 그것만으로는 검사를 다시 실행하지 않고, 현재 리포트를 stale로 표시해요. 변경을 마쳤으면 최신 분석을 요청해(앱의 릴리스 페이지에서 또는 연동의 경우 리프레시 엔드포인트) 대기에서 나가지 않고 갱신된 결과를 볼 수 있어요. 확정할 수 있으려면 최신 분석이 완료되어야 해요.

확정한 후에는 어떻게 되나요?

릴리스가 대기에서 나와 일반 검토 대기열에 들어가고, 다른 릴리스와 똑같이 검토돼요. 검토가 어떻게 진행되는지, 얼마나 걸리는지, 가능한 결과는 검증 및 검토를 참고하세요.

릴리스를 초안으로 되돌릴 수 있나요?

네. 릴리스가 검토 전 대기에 있고 아직 확정하지 않은 동안에는 검토에 들어간 것이 아니므로, 계속 편집하거나 초안으로 남겨 두었다가 나중에 다시 볼 수 있어요. 릴리스는 회원님이 확정할 때만 검토 대기열에 들어가요.

확정하기 전에 모든 문제를 수정해야 하나요?

확정할 수 있게 되기 전에 차단 문제는 해결해야 해요. 정보 제공 문제는 확정을 막지 않지만 살펴볼 가치가 있어요. 검토 전에 가능한 한 많이 정리해 두는 것이 승인으로 가는 가장 빠른 길이에요.

Preflight QC에 대해 궁금한 점이 있으신가요? 저희 팀에 문의하세요. 기꺼이 도와드릴게요.

아직 LabelGrid를 사용하지 않으세요?

방금 읽으신 내용은 모두 저희 플랫폼에서 이용하실 수 있어요.

LabelGrid로 할 수 있는 일 보기 →