방송자가 편집자에게 클립 제작을 맡겨도, 자기 유튜브 채널에 무엇이 올라갈지는 직접 결정하고 싶을 수 있습니다. “편집 가능” 권한으로 업로드까지 허용하면 채널 통제도 함께 넘기게 됩니다. 반대로 업로드 요청 자체를 막으면 편집자는 완성한 파일을 서비스 밖에서 다시 전달해야 합니다.
저는 이 두 문제를 나누어 제작·직접 업로드·자동 업로드 권한과 승인 대기함을 설계했습니다. 편집 결과와 게시 결정을 같은 흐름 안에서 다루되, 결과를 만든 사람이 곧바로 게시할 수 있다고 가정하지 않는 방식입니다. 이 글의 범위는 제가 선택·조율한 권한 모델과 토큰 소유 설계이며, 코어 서비스의 주 구현은 팀원이 담당합니다. 전체 권한 검사와 업로드 연동은 완료된 운영 성과가 아닙니다.
요청한 사람과 업로드할 채널의 소유자는 다릅니다
YouTube에 영상을 올리려면 어느 채널을 대신할 자격이 있는지 확인해야 합니다. YouTube OAuth 문서는 사용자가 동의한 범위에 따라 애플리케이션이 접근하는 구조를 설명합니다. 그러나 서버가 방송자의 토큰을 보유하고 있다는 사실만으로 모든 편집자의 요청을 실행해도 되는 것은 아닙니다.
편집자에게 방송자의 OAuth 토큰을 넘기는 방식은 제외했습니다. 편집자는 자기 계정으로 로그인하고, 서버는 그 사람이 요청한 행위를 할 수 있는지 검사한 뒤 방송자가 연결한 채널 토큰으로 업로드하도록 설계했습니다. 편집자 자신의 유튜브 채널을 연결할 필요도 없습니다. 내부 행위의 주체와 외부 채널의 소유자를 따로 모델링한 결과입니다.
직접 할 수 없는 업로드를 자동으로 허용하지 않습니다
권한은 기능 버튼별로 독립된 스위치를 늘리는 대신, 행위의 종속 관계를 먼저 정했습니다. 자동 업로드를 허용하려면 직접 업로드 권한도 있어야 하며, 자동 실행의 범위를 바꾸는 템플릿 수정은 방송자에게 두기로 했습니다.
| 행위 | 필요한 권한·상태 | 결과를 보내는 곳 |
|---|---|---|
| 기본 클립 제작 | 편집 권한 | 편집 결과 |
| 직접 업로드 | 별도 직접 업로드 권한 | 방송자 채널의 업로드 경로 |
| 원클릭 자동 업로드 | 직접 업로드를 전제로 하는 상위 권한 | 허용된 자동 실행 범위 |
| 직접 업로드 권한 없는 요청 | 요청 보존, 즉시 실행하지 않음 | 방송자의 승인 대기함 |
이렇게 나누면 편집은 맡기되 게시 결정은 보류할 수 있습니다. 자동 실행이 수동 실행보다 더 넓은 권한을 얻는 모순도 피할 수 있습니다. 권한의 개수보다, 방송자가 따로 통제하고 싶어 하는 결정이 무엇인지가 설계 기준이었습니다.
요청을 막는 대신 대기 상태를 두는 비용을 택했습니다
직접 업로드 권한이 없는 편집자의 요청은 승인 대기함에 남기도록 했습니다. 방송자는 승인하거나 반려하고 편집자는 자기 요청의 상태를 확인하는 흐름입니다. 서버가 대기·승인·반려 상태를 관리해야 하는 비용은 생기지만, 결과물을 다른 도구로 옮겨 전달하는 일을 줄일 수 있습니다.
승인과 실제 전송도 별개입니다. 승인은 게시해도 된다는 내부 결정이고, 전송은 외부 API와 네트워크가 관여하는 작업입니다. 두 단계를 하나의 완료 상태로 묶으면 승인됐지만 아직 업로드되지 않은 영상이나, 전송에 실패했는데 완료로 보이는 결과를 설명하기 어렵습니다. 이 구분은 관련 서비스가 구현하고 검증해야 할 상태 전이입니다.
기본 비공개 업로드와 재개 가능한 전송을 설계했습니다
전송 도중 연결이 끊겨도 완성된 편집 결과부터 다시 만들 필요는 없습니다. 그래서 기본 비공개 업로드와 재개 가능한 전송을 설계에 넣었습니다. YouTube 재개 가능한 업로드 문서는 업로드 세션과 전송 상태로 중단된 전송을 이어 가는 절차를 설명합니다.
프로젝트에서는 외부 API 검증·할당량, 실제 토큰 수명과 실패 처리, 전송 복구를 따로 확인해야 합니다. 2026년 10월 판본에서는 권한 모델·토큰 소유·승인 흐름까지가 이 사례의 범위입니다. 실제 채널 운영, 게시 처리량, 권한 오류 감소율은 검증하지 않았으며 과거 문서의 할당량도 현재 확정 값으로 사용하지 않았습니다.
편집 협업과 채널 통제를 함께 유지하려면 거절만으로는 부족했습니다. 결과물을 보존한 채 결정을 기다릴 자리가 필요했습니다. “누가 만들 수 있는가”, “누가 게시를 결정하는가”, “누구의 토큰으로 실행하는가”를 나누고 승인 상태로 연결한 것이 이 설계의 핵심입니다.