유튜브 링크 하나를 재사용 가능한 다운로드 항로로 바꿨다-youtube-download 스킬을 만들고, “받았다”와 “검증했다”를 분리한 과정

📝 한줄 요약

“유튜브를 다운로드하는 스킬”이라는 짧은 요청을, 특정 영상 하나를 받는 일회성 작업이 아니라 영상·오디오·자막·메타데이터를 안전하게 내려받고, 결과 파일의 상태까지 확인하는 재사용 가능한 Hermes 스킬로 바꿨다. 이번 사례에서는 실제 사용자 영상을 다운로드하지 않고, 스킬 설계와 등록, 공개 테스트 영상의 메타데이터 조회, MP4 포맷 선택 검증까지 진행했다.

바쁘시면 이것만 읽어도 됩니다:

• 출발점은 단 네 글자에 가까운 짧은 요청, “유튜브를 다운로드하는 스킬”이었다.

• 기존 미디어 스킬에는 유튜브 자막·메타데이터·업로드 흐름이 있었지만, 다운로드 자체를 독립적으로 다루는 항로는 없었다.

• 그래서 영상 하나를 받는 명령보다, 입력 종류·기본값·실패 경계·검증 방법을 먼저 설계했다.

• 기본값은 단일 영상, --no-playlist, 실용 화질 MP4, 128k MP3, 메타데이터 보존으로 정했다.

• DRM·비공개·회원 전용 콘텐츠와 접근통제를 우회하지 않도록 안전 경계를 스킬 안에 넣었다.

• 실제 파일이 생겼다고 말하려면 파일 존재만으로 부족하므로, duration·스트림·크기·SHA-256·manifest까지 확인하도록 했다.

• 테스트 영상 하나는 현재 YouTube에서 Video unavailable로 막혔고, 다른 공개 fixture로 바꿔 메타데이터 조회와 포맷 선택을 성공시켰다.

• 아직 실제 영상 다운로드를 수행한 사례는 아니다. 이 구분을 명시한 것이 이번 결과의 중요한 일부다.

🎯 이런 분들께 도움됩니다

• 유튜브 링크를 받을 때마다 같은 옵션을 다시 설명하고 같은 명령을 반복하는 사람

• 영상을 MP3, 자막, 메타데이터로 나누어 보관해야 하는 사람

• 플레이리스트가 실수로 전부 내려받아지는 일을 피하고 싶은 사람

• 다운로드가 끝났다는 메시지만 보고 파일이 완전하다고 믿기 어려운 사람

• 유튜브 영상을 전사·편집·아카이빙 파이프라인으로 넘기는 운영자

• AI에게 “이 영상 받아줘”라고 말하고도 결과 파일의 검증 방법까지 함께 정하고 싶은 비개발자

😫 문제 상황 — “유튜브를 다운로드하는 스킬”은 짧지만 범위가 넓었다

처음 요청은 아주 짧았다.

유튜브를 다운로드하는 스킬

이 문장만 보면 곧바로 다운로드 명령 하나를 만들고 끝내기 쉽다. 하지만 실제로 사용자가 다음에 말할 수 있는 요청은 서로 다르다.

• 영상 전체를 받아 달라는 요청

• 소리만 MP3로 추출해 달라는 요청

• 자막만 받아 달라는 요청

• 영상의 메타데이터만 확인해 달라는 요청

• 플레이리스트 전체를 받아 달라는 요청

• 나중에 전사할 수 있도록 원본과 정보를 함께 보관해 달라는 요청

겉으로는 모두 “유튜브 다운로드”지만, 필요한 결과와 위험이 다르다.

영상 하나를 받는 작업과 플레이리스트 전체를 받는 작업은 저장공간과 소요시간부터 다르다. MP3는 영상 다운로드가 아니라 오디오 변환이다. 자동 생성 자막은 자막 파일이지 검증된 전사본이 아니다. 메타데이터 조회는 미디어 다운로드 없이 끝나야 할 수도 있다.

따라서 문제는 “유튜브에서 파일을 가져오는 방법을 아는가”가 아니었다. 더 정확한 문제는 다음과 같았다.

사용자의 짧은 요청을 어떤 결과물로 해석하고, 어디까지 진행했을 때 실제 완료라고 말할 것인가?

기존 media-generation-and-analysis 스킬을 확인하자 유튜브 자막 추출, 메타데이터 조회, 업로드와 미디어 분석 흐름은 이미 있었다. 하지만 다운로드 그 자체를 하나의 독립된 반복 절차로 묶은 스킬은 없었다.

그 상태로 두면 매번 다음 판단을 새로 해야 한다.

• 이 URL이 영상인지 플레이리스트인지

• 플레이리스트를 자동으로 확장해도 되는지

• 영상과 오디오를 어떤 형식으로 받을지

• MP3 변환이 원본 보존과 다른 작업이라는 점을 설명했는지

• .part 파일을 완성본으로 오인하지 않았는지

• 다운로드가 성공했어도 실제 duration이 맞는지

• 후속 전사 담당자에게 URL만 줄지, 검증된 파일과 hash까지 줄지

이 반복 판단을 스킬로 고정하는 것이 이번 작업의 목표가 됐다.

🌱 처음에는 “다운로드 명령 하나”면 충분하다고 생각할 수 있다

유튜브 다운로드 도구는 이미 있다. 실제 환경에도 yt-dlp가 설치돼 있었다. 그러므로 기술적으로는 명령 한 줄만 만들면 될 것처럼 보인다.

하지만 일회성 명령과 재사용 가능한 스킬은 다르다.

여기서 사용자가 재사용 가능한 스킬 생성을 선택했다.

재사용 가능한 `youtube-download` 스킬을 새로 만든다

이 선택으로 작업의 기준이 바뀌었다. 지금 영상 하나를 내려받는 것이 아니라, 앞으로 반복될 다운로드 요청의 판단 구조를 먼저 만들어야 했다.

🛠️ 사용한 도구와 자료

• Hermes Agent: 요청 범위 판독, 기존 스킬 조사, 스킬 작성·등록·검증, 사례글 작성

• Hermes Skill 시스템: 반복 가능한 절차를 SKILL.md로 저장하고 이후 요청에서 불러오는 체계

• media-generation-and-analysis: 기존 유튜브 자막·메타데이터·미디어 후속 처리의 책임 경계 확인

• yt-dlp: 유튜브 메타데이터와 미디어 획득을 담당하는 로컬 도구

• ffmpeg·ffprobe: 영상·오디오 병합, 변환, 스트림·duration 검증을 담당하는 도구

• 현재 대화의 실제 요청과 선택: 다운로드 스킬이 필요한 이유와 재사용 범위의 근거

• 공동 devlog·Chronicle: 생성 시점, 실제 산출물, 검증 결과와 한계 확인

이번 사례는 제3자 변환 사이트나 임의의 온라인 변환 API를 사용하지 않았다. 또한 API 키나 사용자의 로그인 정보를 수집하지 않았다.

이 글에서 스킬은 단순한 명령 모음이 아니다. 사용자가 어떤 요청을 했을 때 어떤 기본값을 적용하고, 어떤 경우에 멈추며, 무엇을 확인해야 완료라고 말할 수 있는지를 저장한 업무 절차다.

🔧 작업 과정

1. 기존 미디어 흐름과 새 다운로드 흐름을 분리했다

첫 작업은 새 스킬을 바로 쓰는 것이 아니라 기존 스킬을 조사하는 일이었다.

기존 미디어 흐름은 유튜브 자막을 가져와 요약하거나, 영상·오디오를 전사와 분석으로 이어 보내는 데 적합했다. 하지만 다운로드 요청만 들어왔을 때 필요한 다음 질문은 별도였다.

• 원본 미디어를 보존할 것인가

• 영상과 오디오 중 무엇을 만들 것인가

• 자막은 creator 제공인지 자동 생성인지

• playlist 범위를 어떻게 제한할 것인가

• 다운로드 후 어떤 파일을 후속 흐름에 넘길 것인가

기존 스킬을 무시하고 또 하나의 거대한 미디어 스킬을 만들면 책임이 섞인다. 반대로 너무 좁게 “yt-dlp를 실행한다”만 적으면 사용자가 실제로 필요한 판단은 남는다.

그래서 새 스킬의 역할을 다음처럼 잘랐다.

YouTube source acquisition
→ metadata preservation
→ media/subtitle output
→ final-file verification
→ downstream handoff

전사·요약·강의 정리는 이 스킬의 뒤에 남겨 두고, 이 스킬은 다운로드와 검증까지만 책임지게 했다.

이 분리는 결과물의 종류를 명확하게 만든다. 다운로드 스킬이 전사본까지 만들어 주는 것이 아니라, 전사 담당자가 믿고 사용할 수 있는 검증된 미디어를 넘기는 것이다.

2. 기본값을 정해 실수할 여지를 줄였다

재사용 가능한 스킬은 사용자가 모든 옵션을 매번 입력해야 하면 재사용성이 떨어진다. 그렇다고 AI가 아무 기준 없이 고르면 예측할 수 없다.

그래서 사용자가 아무런 추가 조건을 주지 않았을 때의 기본값을 정했다.

여기서 가장 중요한 기본값은 --no-playlist에 해당하는 원칙이다. URL에 playlist 정보가 붙어 있다는 이유만으로 수십 개 영상을 받으면 사용자는 결과를 보고서야 실수를 알게 된다. 범위를 넓히는 동작은 사용자가 명시적으로 요청했을 때만 켜도록 했다.

고화질도 마찬가지다. 최고화질은 언제나 좋은 기본값이 아니다. 4K 영상은 저장공간과 처리시간이 커지고, 후속 전사에는 필요 이상일 수 있다. 그래서 일반 요청에는 실용적인 1080p를 우선하고, 보관용 최고화질은 별도 요청으로 분리했다.

3. 다운로드 전에 안전 경계를 먼저 넣었다

유튜브 다운로드는 기술 문제만으로 끝나지 않는다. 공개로 볼 수 있는 영상이라고 해서 자동으로 재배포할 권리가 생기는 것은 아니다.

스킬에는 다음 경계를 넣었다.

• 사용자가 다운로드·보관할 권한이 있는 콘텐츠만 대상으로 한다.

• DRM, paywall, private access, membership restriction, CAPTCHA와 같은 접근통제를 우회하지 않는다.

• 비밀번호, API 키, raw cookie, session token을 사용자에게 요구하지 않는다.

• 로그인된 브라우저 세션이 꼭 필요한 경우에도 사용자의 명시적 지시와 기존 인증 상태를 전제로 한다.

• 제3자 변환 사이트 대신 로컬 도구를 사용한다.

• private, removed, members-only와 같은 영구 차단 오류는 무한 재시도하지 않는다.

이 부분은 부가적인 법률 문구가 아니다. 스킬이 “어떻게든 파일을 만들어 내는 도구”로 변질되지 않게 하는 실행 계약이다.

기술적으로 가능하다는 이유만으로 실행하지 않는 조건을 미리 적어 두면, 이후 다른 요청에서도 같은 판단을 반복할 수 있다.

4. “다운로드 완료”의 의미를 파일 검증으로 다시 정의했다

다운로드 도구가 성공 메시지를 출력했다고 해서 결과가 완전하다고 말할 수는 없다.

• .part 파일이 남아 있을 수 있다.

• 영상과 오디오 중 하나만 받아졌을 수 있다.

• 병합 단계에서 ffmpeg가 실패했을 수 있다.

• 파일은 열리지만 마지막 구간이 잘렸을 수 있다.

• 자동 생성 자막을 creator 자막으로 잘못 부를 수 있다.

• 제목은 맞지만 다른 video ID일 수 있다.

그래서 스킬에 provenance와 검증 단계를 함께 넣었다.

이 구조를 download-manifest.json에 담도록 했다. manifest의 숫자와 hash는 추정해서 채우지 않고 실제 파일에서 읽어야 한다는 원칙도 함께 적었다.

이렇게 하면 결과 보고가 다음처럼 바뀐다.

명령이 성공했습니다.

에서

요청한 source를 확인했고,
최종 파일의 존재·duration·stream·크기·hash를 확인했으며,
다음 작업자가 사용할 metadata와 함께 인계할 수 있습니다.

로 바뀐다.

5. 영상·오디오·자막·메타데이터·플레이리스트를 분리했다

하나의 거대한 실행 모드보다 결과 종류별로 책임을 나누는 편이 실제 요청에 맞았다.

영상

일반 영상 요청에는 MP4 호환 조합을 우선하고, 실용 화질을 기본으로 했다. 최고화질 보관은 별도 모드로 분리하고, 컨테이너가 맞지 않을 때 무리하게 재인코딩하지 않도록 했다.

오디오

MP3는 원본 다운로드와 다르다. 오디오를 추출하면서 재인코딩이 발생할 수 있기 때문이다. 사용자의 기본 선호인 128k MP3를 적용하되, 원본 음질 보존이 중요하면 M4A나 Opus 같은 선택지를 안내하도록 했다.

자막

자막 파일은 전사본과 구분한다. creator 제공 자막과 자동 생성 자막을 같은 품질로 말하지 않으며, 자동 자막만 있다면 그 사실을 manifest와 결과 보고에 남긴다.

메타데이터

메타데이터만 요청하면 미디어를 다운로드하지 않고 JSON을 저장한 뒤 종료한다. “정보만 확인해 달라”는 요청에 대용량 파일까지 내려받는 부작용을 막기 위해서다.

플레이리스트

플레이리스트는 명시 요청이 있을 때만 전체 범위를 허용한다. 반복 실행 시 이미 처리한 video ID를 건너뛸 수 있도록 archive 개념도 넣었다.

이렇게 나누면 “유튜브”라는 주제어가 아니라 사용자가 원하는 즉시 산출물에 맞춰 실행할 수 있다.

6. 실패한 테스트와 성공한 테스트를 분리했다

스킬을 등록한 뒤 실제 환경을 확인했다. yt-dlp는 2026.07.04 버전으로, ffmpeg는 8.0.1로 확인됐고 ffprobe도 실행 가능했다.

첫 공개 테스트 fixture는 다음 오류를 반환했다.

Video unavailable

여기서 두 가지 실수가 가능했다.

1. 테스트 URL이 실패했으니 스킬이 작동하지 않는다고 결론내리기

2. 같은 URL을 무한 재시도하며 성공한 것처럼 보고하기

둘 다 하지 않았다. 이 응답은 도구 자체의 문법 오류가 아니라 해당 테스트 영상의 현재 가용성 문제로 분리했다. 그 뒤 다른 공개 fixture를 사용해 다운로드 없는 메타데이터 조회를 다시 실행했다.

대체 테스트에서는 다음 결과를 확인했다.

• video ID: jNQXAC9IVRw

• 제목: Me at the zoo

• duration: 19초

• extractor: Youtube

• 기본 practical MP4 selector의 파일명 선택: jNQXAC9IVRw.mp4

중요한 점은 이 테스트가 실제 영상 파일을 만든 테스트가 아니라는 것이다. 메타데이터 조회와 --get-filename 포맷 선택만 수행했다. 실제 사용자 URL이 없었고, 권한을 확인할 대상도 없었기 때문에 테스트 범위를 다운로드까지 넓히지 않았다.

7. 스킬을 만들었다고 바로 “완성”이라고 하지 않았다

파일을 생성한 것만으로는 부족했다. 다음 검증을 별도로 수행했다.

• frontmatter가 파일 첫 줄에서 시작하는지

• YAML mapping으로 파싱되는지

• skill name과 description이 유효한지

• 필수 섹션이 존재하는지

• 본문 크기 제한을 넘지 않는지

• Hermes의 스킬 목록에서 enabled로 보이는지

• 실제 yt-dlp와 ffmpeg/ffprobe가 실행 가능한지

• 공개 fixture의 metadata smoke test가 통과하는지

• 기본 MP4 format selector가 실제 파일명을 반환하는지

그 결과 youtube-download 스킬은 16,010 bytes, 364 lines로 등록됐고 Hermes 목록에서 media / local / enabled 상태로 확인됐다.

✅ 결과 — 유튜브 다운로드가 “명령”에서 “검증된 인계 단위”가 됐다

전후 비교

실제 산출물과 검증 범위

시간 절감률, 다운로드 성공률, 전사 품질 향상률은 아직 측정하지 않았다. 이번 결과에서 확인한 것은 재사용 가능한 스킬 파일의 생성, 런타임 활성 상태, 도구 실행 전제, metadata smoke test와 포맷 선택이다.

실제 다운로드 성과는 사용자가 권한을 가진 URL을 제공하고, 영상·오디오·자막 중 원하는 결과를 선택한 뒤, 최종 파일의 검증 Gate까지 통과시킨 사례에서 별도로 측정해야 한다.

가장 짧은 공식

URL을 받는다.
→ 단일 영상인지 확장 요청인지 먼저 구분한다.
→ 영상·오디오·자막·메타데이터 중 결과를 고른다.
→ 권한과 접근통제 경계를 확인한다.
→ 다운로드한다.
→ 파일·duration·stream·hash를 확인한다.
→ 검증된 경로와 manifest를 다음 작업에 넘긴다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 기능이 아니라 반복되는 판단을 스킬로 만들기
   yt-dlp를 실행하는 것만 저장하지 않고, 언제 --no-playlist를 쓰는지, 언제 멈추는지, 무엇을 검증하는지까지 저장했다.

2. 기본값을 보수적으로 정하기
   단일 영상, 실용 화질, 128k 오디오, 자막은 요청 시 다운로드로 정하면 예상하지 못한 대용량 작업을 줄일 수 있다.

3. 다운로드와 전사를 분리하기
   자막을 받는 것과 검증된 전사본을 만드는 것은 다른 결과물이다. 책임을 섞지 않으면 품질 기준도 분명해진다.

4. 완료 기준을 명령 출력보다 아래에 두기
   도구가 성공했다고 말해도 실제 파일이 완전한지는 별도로 확인한다. 결과 파일을 다시 읽는 단계가 있어야 완료 보고가 믿을 만해진다.

5. 실패한 fixture를 도구 실패로 오인하지 않기
   Video unavailable은 영구적인 콘텐츠 가용성 문제일 수 있다. 다른 공개 fixture로 문법과 실행 전제를 분리 시험하면 원인을 좁힐 수 있다.

6. 실제로 하지 않은 것을 했다고 쓰지 않기
   이번 사례는 metadata와 format selector까지 검증했을 뿐, 영상 파일을 다운로드하지 않았다. 이 경계를 결과표에 그대로 남겼다.

7. 후속 작업자가 바로 사용할 정보를 남기기
   URL만 넘기는 대신 video ID, metadata, duration, hash와 최종 경로를 함께 넘기도록 설계하면 전사·편집·보관 단계의 재확인이 줄어든다.

이렇게 하면 안 됩니다

1. 영상 URL에 playlist 정보가 붙었다는 이유만으로 전체 playlist를 자동 다운로드하지 않는다.

2. .part 파일이나 0바이트가 아닌 파일을 완성본으로 부르지 않는다.

3. MP3 추출을 원본 무손실 다운로드라고 설명하지 않는다.

4. 자동 생성 자막을 검증된 전사본처럼 다루지 않는다.

5. private·members-only·DRM 콘텐츠를 우회하려고 무한 재시도하지 않는다.

6. 사용자의 비밀번호나 raw cookie를 요구하지 않는다.

7. 제3자 변환 사이트에 URL을 넘겨 개인정보와 품질을 불필요하게 노출하지 않는다.

8. metadata 조회 테스트만 해 놓고 실제 영상 다운로드까지 완료했다고 쓰지 않는다.

9. 파일명에 들어간 제목만 보고 source identity와 무결성을 판단하지 않는다.

10. 다운로드 스킬에 전사·요약·법률 검토까지 한꺼번에 넣어 책임 경계를 흐리지 않는다.

🌍 다른 업무에 적용한다면?

강의·회의 전사 준비

강의 영상 URL을 받으면 먼저 원본 영상, 오디오 추출본, metadata, 자막의 출처를 분리해 보관할 수 있다. 이후 전사 흐름은 검증된 로컬 파일을 입력으로 사용하고, 원본 URL과 hash를 provenance로 남긴다.

이렇게 하면 “전사가 틀렸다”는 문제가 생겼을 때 전사 엔진 문제인지, 다운로드 파일이 truncated된 것인지, 자동 자막을 잘못 기준으로 삼은 것인지 구분하기 쉬워진다.

여행·현장 영상 아카이빙

여행 영상은 고화질 원본이 필요할 때와 이동 중 확인할 실용본이 필요할 때가 다르다. 원본 보관용 최고화질과 편집·검토용 1080p를 나누고, 영상 ID와 촬영 출처를 manifest에 남길 수 있다.

다만 영상의 재배포·공개 사용 권한은 별도로 확인해야 한다. 다운로드 스킬이 라이선스 판단을 대신하지는 않는다.

리서치 자료 수집

공개 강연이나 제품 발표 영상을 조사 자료로 보관할 때, 제목만 저장하는 것보다 metadata와 다운로드 시점을 함께 기록하는 편이 낫다. 나중에 영상이 삭제되거나 제목이 바뀌어도 어떤 source를 기준으로 분석했는지 추적할 수 있다.

C&B 전사·미디어 변환 인계

C&B에 전사를 맡길 때 URL만 던지는 대신, 검증된 미디어 파일과 metadata, duration, SHA-256을 함께 넘길 수 있다. C&B는 다운로드 자체보다 전사·변환에 집중하고, 타디스는 source identity와 작업 범위를 유지할 수 있다.

다른 데이터 수집 자동화

유튜브가 아니더라도 “가져왔다”와 “검증했다”를 나누는 구조는 그대로 적용된다.

• 입력 source와 scope를 먼저 고정한다.

• 기본값을 보수적으로 둔다.

• 접근권한과 금지된 우회 범위를 정한다.

• 결과 파일과 provenance를 함께 저장한다.

• 성공 메시지 대신 실제 산출물을 다시 읽는다.

🤝 배워서 남 주기

이번 사례에서 다른 사람이 바로 가져갈 수 있는 것은 youtube-download라는 이름보다 다음 네 가지 설계 원칙이다.

1. scope gate
   단일 항목인지 전체 묶음인지 먼저 확인한다. 기본값은 좁게 두고, 범위 확장은 명시 요청으로 제한한다.

2. output contract
   영상·오디오·자막·메타데이터를 서로 다른 결과로 정의한다. “다운로드”라는 말 하나로 모든 것을 묶지 않는다.

3. verification gate
   파일이 생겼는지에서 멈추지 않고 duration, stream, size, hash를 확인한다.

4. handoff contract
   후속 작업자에게 URL만 넘기지 않고 검증된 경로, source metadata, 도구 버전, duration, hash를 함께 넘긴다.

이를 더 일반화하면 다음 템플릿으로 바꿀 수 있다.

[외부 source]를 반복해서 가져오는 절차를 재사용 가능한 스킬로 만들어 주세요.
단일 항목과 전체 묶음의 범위를 분리하고, 사용자가 지정하지 않았을 때의 보수적인 기본값을 정해 주세요.
결과물 종류별로 입력·출력·실패 조건을 나누고, 접근권한·금지된 우회·credential 비노출 경계를 포함해 주세요.
성공 메시지를 믿지 말고 최종 파일·메타데이터·무결성·다음 작업 인계 정보를 실제로 확인하는 완료 Gate를 설계해 주세요.

🕊️ 누구의 어려움을 줄일 수 있나

이 사례가 줄이려는 어려움은 영상 파일을 받는 기술 자체보다, 그 주변의 반복 판단이다.

• 비개발자가 매번 품질과 형식을 다시 정해야 하는 부담

• 실수로 playlist 전체를 받아 저장공간을 소모하는 문제

• 자동 자막과 검증된 전사를 혼동하는 문제

• 다운로드가 끝났다는 메시지만 믿고 truncated 파일을 넘기는 문제

• 후속 전사 담당자가 같은 URL을 다시 조회하며 source identity를 확인하는 시간

• 접근권한이 없는 자료를 무리하게 받으려는 위험한 요청

스킬 하나가 모든 판단을 대신하는 것은 아니다. 대신 반복되는 판단을 눈에 보이는 규칙으로 만들고, 사용자가 결과를 신뢰할 수 있는 지점을 정해 준다.

🚀 앞으로의 계획

1. 사용자 권한이 확인된 실제 URL로 full-download canary 실행
   영상·MP3·자막 중 하나를 선택해 실제 최종 파일 생성, ffprobe, hash, manifest까지 한 번에 검증한다.

2. 자막 origin과 파일 연결을 더 세밀하게 기록
   creator 제공 자막과 자동 생성 자막을 manifest에서 더 명확히 구분하고, 언어별 파일과 source metadata의 연결을 강화한다.

3. playlist 배치 검증 보강
   명시적으로 승인된 playlist를 대상으로 expected item count, archive count, 개별 파일 duration을 확인하는 배치 Gate를 추가한다.

4. C&B 인계 템플릿 연결
   다운로드 manifest에서 C&B 전사 입력 카드로 바로 이어지도록 source slug, audio quality, duration, SHA-256 필드를 표준화한다.

5. 실제 운영 지표 측정
   다운로드 성공률, 재시도율, truncated 파일 발견률, 후속 전사 단계의 재조회 감소 여부를 실제 authorized source에서 측정한다.

이번 계획은 스킬이 이미 모든 상황을 해결한다는 뜻이 아니다. 실제 파일을 만드는 canary와 반복 사용 데이터가 쌓인 뒤에야 어떤 기본값이 정말 좋은지 판단할 수 있다.

📋 재사용 가능한 프롬프트

프롬프트 1: 외부 미디어 다운로드 스킬 설계

[외부 미디어 source]를 반복해서 가져오는 재사용 가능한 Hermes 스킬을 설계해 주세요.
단일 source와 전체 묶음의 범위를 분리하고, 사용자가 옵션을 주지 않았을 때의 보수적인 기본값을 정해 주세요.
영상·오디오·자막·메타데이터처럼 결과물 종류가 다르면 각각의 출력 계약과 실패 조건을 나눠 주세요.
접근권한, DRM·private access 등 금지된 우회, credential 비노출, overwrite 방지, provenance, 최종 파일 검증 Gate를 포함해 주세요.

프롬프트 2: 유튜브 영상 다운로드 요청

다음 YouTube URL을 다운로드해 주세요.
URL: [YouTube URL]
목적: [개인 보관 / 허가된 편집 / 전사 준비 / 연구 아카이브]
결과: [실용 화질 MP4 / 최고화질 / 128k MP3 / creator 자막 / metadata only]
기본적으로 단일 영상만 처리하고 playlist 전체는 확장하지 마세요. 다운로드 전에 source metadata와 사용 범위를 확인하고, 완료 후 최종 파일의 존재·duration·video/audio stream·파일 크기·SHA-256을 검증해 주세요. 자동 생성 자막이면 그 사실을 표시하고, 접근통제가 필요한 경우 우회하지 말고 중단 사유를 보고해 주세요.

프롬프트 3: 전사·편집 담당자에게 미디어 인계

검증된 YouTube 미디어를 [전사 또는 편집 담당자]에게 넘길 준비를 해 주세요.
원본 URL, video ID, 제목, duration, 다운로드 시점, 도구 버전, 최종 파일 경로, 파일 크기, SHA-256, 자막 origin을 manifest로 정리해 주세요.
원본 파일과 변환된 MP3를 구분하고, 다운로드가 아니라 후속 전사·편집 단계에서 필요한 입력만 명확히 표시해 주세요. 실제로 확인하지 않은 값은 만들지 말고 확인 필요로 남겨 주세요.

📚 사실 근거와 해석의 한계

확인한 사실

• youtube-download user-local 스킬을 생성했다.

• 스킬 파일은 16,010 bytes, 364 lines로 확인됐다.

• Hermes 스킬 목록에서 media / local / enabled 상태를 확인했다.

• 현재 환경의 yt-dlp 버전은 2026.07.04, ffmpeg 버전은 8.0.1이었고 ffprobe도 실행 가능했다.

• 첫 smoke fixture는 Video unavailable 응답을 반환했다.

• 대체 공개 fixture jNQXAC9IVRw의 메타데이터 조회가 성공했고, 제목은 Me at the zoo, duration은 19초로 반환됐다.

• 같은 fixture에서 practical MP4 format selector의 파일명 선택 검사를 통과했다.

• 이번 사례에서는 실제 사용자 영상 파일을 다운로드하지 않았다.

아직 확인하지 않은 것

• 실제 권한이 확인된 사용자 URL의 full video download

• 실제 MP3 변환 후 duration과 codec 검증

• creator 제공 자막과 자동 생성 자막의 실제 파일별 비교

• 명시적으로 승인된 playlist의 전체 배치 처리

• 4K archival 다운로드의 저장공간·처리시간 특성

• 실제 전사 업무에서 재조회 시간이 얼마나 줄어드는지

따라서 이 글은 “유튜브 다운로드 시스템이 모든 영상에서 성공한다”는 사례가 아니다. 반복 가능한 스킬의 설계·등록·기본 검증이 완료됐고, 실제 미디어 다운로드는 권한이 확인된 다음 canary에서 별도로 검증해야 한다는 사례다.

이 구분을 지키는 것이 오히려 재사용 가능한 자동화의 출발점이다. 하지 않은 일을 했다고 기록하지 않아야 다음 실행의 신뢰 기준도 유지된다.