본문으로 건너뛰기

승인

조건부 라이선스(LGPL, MPL, EPL, CDDL)를 보유한 컴포넌트는 승인 워크플로우를 트리거합니다. 빌드는 진행되지만 충분한 권한을 가진 검토자가 처리할 때까지 컴포넌트는 Approvals 페이지에 등장합니다.

대상 독자

승인을 요청하는 엔지니어; 요청을 처리하는 법무·컴플라이언스 검토자 및 team_admin 이상 멤버.

상태 머신​

대기 (Pending) ──► 검토 중 (Under Review) ──► 승인 (Approved)
                                       └────► 반려 (Rejected)
상태설정 주체의미
대기자동, 조건부 라이선스 컴포넌트 첫 탐지 시.검토자 배정 대기.
검토 중검토자(team_admin 이상).검토자가 요청을 받아 조사 중.
승인검토자.명시된 의무사항을 따른다는 전제로 컴포넌트 사용 승인.
반려검토자.컴포넌트 제거 권장; 결정은 감사용으로 기록. 반려 결정 caveat 참고 — v0.10.0 에서 빌드 게이트는 반려 결정에 자동으로 차단되지 않습니다.

전환은 감사 로그에 기록됩니다.

승인 큐​

사이드바 → Approvals. 필터: 상태(status)와 requested_at 기반의 날짜 범위.

각 행 표시:

  • 컴포넌트 (Component) — 컴포넌트 표시 이름과 두 번째 monospace 줄의 package URL(purl). 행의 기본 컴포넌트 이름을 해석하지 못한 경우 컴포넌트 UUID 앞 8 자로 폴백합니다.
  • 프로젝트 (Project) — 요청이 적용되는 프로젝트. 프로젝트 이름과 함께 /projects/{id} 로 가는 click-through 링크로 렌더링됩니다(같은 컴포넌트가 여러 프로젝트에 등장하면 프로젝트당 한 행). 이름이 사용 불가능한 경우 프로젝트 UUID 앞부분으로 폴백합니다. 링크는 클릭 전파를 중단하므로 프로젝트를 여는 동작이 행의 드로어를 함께 열지는 않습니다.
  • 상태 (Status) — 대기 / 검토 중 / 승인 / 반려.
  • 요청자 (Requested by) — 요청을 생성한 사용자(또는 시스템).
  • 요청 시각 (Requested at) — 요청 타임스탬프.
  • 동작 (Actions) — 본인 역할에 맞는 처리 컨트롤(드로어 진입 등).

목록 엔드포인트는 컴포넌트·프로젝트 표시 필드를 두 번의 batched IN(...) 조회로 해석합니다(ComponentApproval 모델은 의도적으로 도메인을 가로지르는 관계를 보유하지 않음). 따라서 수백 행짜리 큐도 한 번의 round-trip 으로 렌더됩니다.

/approvals 대기열 — Pending / Under Review / Approved / Rejected 상태 배지, 컴포넌트 식별자, 프로젝트, 요청자(actor), 행별 Actions 컬럼이 있는 표

승인 요청​

스캔 파이프라인이 새로운 조건부 라이선스 컴포넌트를 탐지하면 대기 요청이 자동 생성됩니다. 수동 작업 불필요.

스캔이 실행되기 전에 요청을 시드해야 하는 클라이언트(예: 아직 푸시하지 않은 PR에서 의존성 추가)를 위해 포털은 POST /v1/approvals 엔드포인트를 노출합니다. 이를 위한 UI 폼은 이연되었습니다 — 로드맵 참고.

요청 처리​

  1. 행을 클릭해 드로어 열기.
  2. Start Review 클릭 — 상태가 검토 중으로 전환되며 검토자 필드가 본인으로 설정.
  3. 라이선스 조건과 포털이 나열한 의무사항 검토.
  4. Approve 또는 Reject. 둘 다 선택 사항인 결정 노트(decision_note, 2000자 이하)를 입력받습니다. 노트는 감사용으로 승인 행에 저장됩니다.

승인 드로어 — Pending 상태와 Start Review / Reject 결정 버튼

대기 상태에서는 검토를 거치지 않고도 Reject를 직접 사용할 수 있습니다 — 명백히 잘못된 요청을 빠르게 처리할 때 유용합니다.

성공적인 처리:

  • 해당 프로젝트의 컴포넌트에 대한 결정을 잠금.
  • 결정을 감사 로그에 기록.
  • 다음 스캔에서 프로젝트 리스크 점수 갱신.
  • (알림 트리거 활성화 시) 요청자와 팀에게 이메일 발송.

반려(Rejected) 결정​

경고

Rejected 로 표시된 승인은 v0.10.0 에서 해당 컴포넌트를 빌드 게이트의 forbidden 로 자동 재분류하지 않습니다 — 게이트는 라이선스의 forbidden 단계만 평가합니다 (apps/backend/services/policy_gate.py 참고). 반려 결정은 승인 행과 감사 로그에 증거로 기록되지만, v0.10.0 에서는 CI 를 차단하지 않습니다: 후속 스캔은 컴포넌트를 여전히 conditional 로 분류하고 빌드는 진행됩니다. 반려 시 forbidden 으로 승격되는 promotion-on-rejection ( 로드맵) 이 적용되기 전까지는 의사결정을 도구 외부에서 강제하세요 — 예: 프로젝트에 추적 이슈를 열고 코드 리뷰에서 의존성을 제거.

프로젝트 간 승인​

같은 컴포넌트가 여러 프로젝트에 등장하면 각 프로젝트가 별도 대기 요청을 받습니다. 포털은 다음 이유로 결정을 자동 전파하지 않습니다.

  • 프로젝트마다 배포 모델이 다를 수 있음(폐쇄 SaaS vs. 출고 바이너리).
  • 같은 라이선스라도 링크 모델에 따라 의무사항이 다름(LGPL static vs. dynamic).

결정을 전역 적용하려면 각 프로젝트의 요청을 명시적으로 표시하고 사유에 원래 결정을 참조하세요.

외부 검토 시스템 통합​

포털은 Webhook을 통해 승인 요청을 외부 시스템(예: Jira)에 게시할 수 있습니다. admin 알림 참고 — 승인 요청 트리거가 같은 이벤트를 이메일·Slack·Teams·outbound HTTP POST로 연결합니다.

전형적 흐름:

  1. 스캔 파이프라인이 대기 요청 생성 → 포털이 Jira automation에 POST.
  2. Jira가 티켓을 생성하고 법무 검토자 배정.
  3. 검토자가 포털에서 처리; 포털이 결정을 Jira로 POST; Jira가 티켓 종료.

정상 동작 확인​

요청 처리 후:

  1. 상태 배지가 즉시 갱신.

  1. 감사 로그가 target_table=component_approvals&action=update를 previous_status, new_status, decision_note와 함께 diff에 담아 기록.

    SELECT count(*) FROM audit_logs
     WHERE target_table = 'component_approvals'
       AND action = 'update'
       AND diff ? 'previous_status'
       AND diff ? 'new_status'
       AND created_at > now() - interval '1 hour';

  1. 원래 요청자(있다면)가 팀의 알림 설정에 따라 알림 수신.

    SELECT count(*) FROM notifications
     WHERE kind = 'approval_state_changed';
  1. 참고: v0.10.0 에서 반려 결정은 다음 스캔의 빌드 게이트에서 컴포넌트를 forbidden 으로 자동 승격하지 않습니다 — 수동 후속 조치는 반려 결정 caveat 참고.

트러블슈팅​

조건부 라이선스 컴포넌트가 있는데 승인 큐가 비어 있음​

요청이 이미 처리되었을 수 있습니다(승인·반려). 기본 큐 뷰는 대기·검토 중으로 필터됩니다. 상태 필터를 All로 전환하세요.

요청에 대해 Start Review를 누를 수 없음​

프로젝트 소속 팀에서 team_admin 이상이 필요합니다. 팀 admin에게 위임을 요청하거나 프로젝트의 소속 팀을 변경하세요.

반려 결정이 다음 CI 빌드를 차단하지 않음​

현재 릴리스의 의도된 동작입니다 — 반려 결정 caveat 참고. 빌드 게이트는 forbidden 라이선스 단계만 평가하며, 승인 결정은 컴포넌트의 라이선스 카테고리로 역전파되지 않습니다. 빌드를 차단하려면 의존성을 제거하거나 분류기 사전 패치 경로(Operator 전용)를 통해 해당 라이선스를 forbidden 으로 승격하세요.

승인 결정이 다음 스캔에서도 경고로 표시됨​

상태 배지는 즉시 갱신되지만, 프로젝트 리스크 점수와 conditional 경고 표시는 새 스캔이 완료된 뒤에만 갱신됩니다. 결정 시점에 스캔이 이미 실행 중이었다면 그 스캔은 이전 상태를 반영합니다. 새 스캔을 트리거하세요.

로드맵​

매뉴얼이 이전에 약속했으나 v0.10.0에 포함되지 않은 항목.

  • 큐 툴바의 프로젝트 / 라이선스 / 컴포넌트 / 요청자 필터 — 예정. 현재는 상태와 날짜 범위만 노출.
  • 큐 행의 라이선스 / 검토자 / 사유 컬럼 — 예정. 현재는 드로어 안에서만 노출됩니다.
  • "New request" UI 폼(프로젝트 / purl / 사유) — 예정. 현재 수동 요청 시드는 POST /v1/approvals 엔드포인트뿐입니다.
  • team_admin 검토자를 위한 다중 선택 일괄 결정 — 예정.

함께 보기​