유튜브 요약 Skill 만들려다 범용 지식 구조까지 고민하게된 사연

소개

스터디를 위해 YouTube 재생목록에 저장해놓은 영상 한 편을 요약해 옵시디언에 넣는 Skill 하나를 만들려고 했는데, 옵시디언을 지식 저장소로 만들기 위한 취지를 생각해보니, 웹·뉴스·SNS·PDF·팟캐스트까지 포괄할 수 있는 계층형 지식 저장소 구조로 방향을 바꾸게 되었고, 그에 맞춰 Skill을 만들었습니다. 그 과정을 함께 합니다.

YouTube 영상 한 편에서 시작했습니다

처음 하려던 일은 이랬습니다.

AI스터디를 위해 재생목록에서 넣어놓은 영상 1개를 요약해서 Obsidian에 넣어보자. 그리고, 매일 일정시간에 재생목록에 새로 올라온 영상들을 모두 작업하자.

목표는 소박했습니다. 새로 재생목록에 저장한 영상을 찾아 자막을 요약하고, Obsidian에 저장하되 같은 영상이 두 번 들어가지 않게 막는 YouTube 전용 Skill 하나를 만들면 될 일로 봤습니다.

여기까지는 흔한 자동화 작업이었고, 범용 시스템 같은 건 염두에 없었습니다.

옵시디언에 저장할 생각을 해보니 단순하지 않았습니다

방향이 틀어진 건 저장할 곳의 성격을 다시 확인하면서였습니다.

내가 만들어가려고 하는 Obsidian 볼트(관심 있는 자료를 파일 단위로 쌓아 두는 개인 지식 저장소)는 YouTube 요약만 넣는 공간이 아니었습니다. 웹페이지, 뉴스, SNS, 팟캐스트, PDF와 문서까지 이미 여기로 모으고 있었습니다. 그러니 YouTube Skill이 자기 편한 대로 노트 형식을 정해 버리면, 출처가 하나 늘 때마다 YAML과 본문 구조가 제각각으로 갈라질 게 눈에 보였습니다. 나중에 한 볼트 안에서 이걸 서로 연결하고 검색하려는 순간부터 다루기 어려워지는 그림이었습니다.

그래서 순서를 바꿨습니다. YouTube 자동화를 만들기 전에, 어떤 출처가 들어와도 똑같이 따를 공통 노트 규격부터 정해 두기로 한 겁니다. 이 요구를 계층 구조로 구체화했습니다.

출처는 어댑터로, 형식은 공통 규격으로 나눴습니다

외부 원본
  ├─ YouTube
  ├─ 웹·뉴스
  ├─ SNS
  ├─ 팟캐스트
  └─ PDF·문서
        ↓
출처별 수집 Skill (어댑터)
        ↓
knowledge-ingestion 공통 규격
        ↓
Obsidian inbox의 Source Note
        ↓
별도 Wiki Skill이 분류·연결·개념화

역할을 이렇게 층으로 갈랐습니다.

여기서 제가 가장 크게 바꾼 생각은, YouTube를 '지식의 한 종류'가 아니라 그저 '첫 번째 수집 어댑터'로 본 것입니다. AI스터디 재생목록도 분류 태그가 아니라 '처리할 영상을 모아 둔 큐'에 가까웠습니다. 등록 순서를 곧 처리 순서로 삼기로 한 것도 이 구분에서 나왔습니다.

이렇게 두면 앞으로 웹이나 PDF 수집 어댑터를 붙여도 달라지는 건 원본을 읽어 오는 방법 하나뿐입니다. 나오는 결과물은 모두 같은 Source Note(출처 원본을 처음 읽어 표준 형식으로 저장한 최초 노트) 규격을 따르게 됩니다.

수집과 Wiki화를 나눈 이유

두 번째로 정한 건, 수집 단계와 Wiki화 단계를 한 Skill에 몰아넣지 않는 것이었습니다.

수집 Skill은 원본을 직접 읽어 제목, 주요 주장, 정확한 용어, 사례, 한계, 그리고 각 내용이 원본 어디에서 나왔는지까지 남깁니다. 이 단계에서는 위키링크를 걸거나 최종 분류를 하거나 폴더를 옮기지 않습니다. 그건 다음 단계의 일이기 때문입니다.

그다음 Wiki Skill이 들어와 원본은 다시 열지 않고 수집 노트만 읽어 기존 지식과 연결하고 개념화합니다. 그러려면 Source Note가 짧은 요약에 그쳐선 안 되고, Wiki 단계가 원본을 다시 안 봐도 될 만큼 근거를 담고 있어야 합니다. 수집 쪽에서 근거를 넉넉히 남겨 둬야 뒷단이 원본에 매번 다시 접근하지 않아도 됩니다. 이렇게 단계를 갈라 두면 각 단계를 따로 고치고 따로 재사용하기도 편했습니다.

상상으로 구조 그림만 그리지 않고 영상 한 편을 먼저 돌려봤습니다

구조를 그려 두는 것과 그게 실제로 돌아가는 건 다른 이야기입니다. 그래서 설계에서 멈추지 않고, AI스터디 재생목록의 최신 영상 한 편을 끝까지 처리해 봤습니다. 완성된 결과를 직접 읽어 보니 앞서 내린 결정 몇 개가 실제로 맞는지 확인할 수 있었습니다.

접근 방식을 무엇으로 할 것인가. 브라우저 쿠키를 활용하는 방식은 접었습니다. 이런 비공식 방식은 쉽게 깨지고 권한 범위도 애매합니다. 대신 YouTube가 제공하는 공식 읽기 전용 OAuth로 접근 권한을 받고, 그 권한으로 YouTube Data API를 통해 재생목록 항목과 등록 시각 같은 공식 정보를 조회했습니다. 자막은 그렇게 고른 영상에서 별도로 확보했습니다. OAuth는 어디까지 접근할지를 정하는 권한 쪽이고, 실제 정보를 가져오는 건 API 호출입니다.

모르는 건 지어내지 않기. 자동 자막에서 불명확한 고유명사가 나와도 임의로 채우지 않았습니다. Source Note가 뒤 작업의 근거로 쓰이는 이상, 틀린 확신보다 '여기는 불확실하다'고 남기는 편이 낫다고 봤습니다.

완성된 Source Note를 읽으니 바꿀 것이 보였습니다

검증에서 제일 도움이 된 건, 다 만든 노트를 사람 눈으로 그냥 읽어 본 일이었습니다. 40분이 넘는 영상 한 편이 규격대로 노트가 됐지만, 읽다 보니 규격 자체를 손봐야 할 곳이 드러났습니다.

먼저 중요한 정보의 위치였습니다. 처음엔 주요 구간과 타임스탬프가 상세 본문 아래에 흩어져 있어서, 정작 영상의 그 지점으로 바로 넘어가기가 불편했습니다. 그래서 원본 정보, 핵심 키워드, 주요 구간과 타임스탬프를 노트 맨 위 콜아웃 하나로 모으도록 규격을 바꿨습니다. 여기서 핵심 키워드는 원본에서 뽑아낸 용어(source_terms)를 그대로 해시태그로 단 것이라, 같은 콜아웃 안에서 노트마다 표기가 흔들리지 않습니다.

> [!info] 원본 영상
> - 작성자·채널, 게시일, 원본 링크
>
> **주요 키워드** (source_terms 기반)
> #키워드1 #키워드2 #키워드3
>
> **주요 구간과 타임스탬프**
> - 02:15 핵심 논점이 시작되는 구간

## 한눈에 보는 요약

또 하나는 지식과 운영 상태가 한 노트에 섞여 있던 문제였습니다. 사람이 볼 정보와 자동화 안에서만 쓰는 정보가 뒤엉켜 있었습니다. 그래서 원본을 다시 찾고 검색하는 데 필요한 지식만 노트에 남겼습니다. 정제한 제목과 원본 제목, 출처와 출처 식별자(source_id), URL·작성자·게시일, 원본에서 뽑아낸 용어(source_terms) 같은 것들입니다. 반대로 처리 상태나 오류, 큐 안에서의 위치처럼 운영에 쓰는 정보는 노트에서 빼 SQLite로 옮겼습니다. SQLite는 지식을 담는 곳이 아니라 처리 상태와 중복 방지를 관리하는 쪽으로 역할을 한정한 겁니다. 이렇게 하니 노트가 자동화 로그로 변질되지 않고, 나중에 노트를 다른 폴더로 옮겨도 출처 식별자 기준의 중복 방지가 그대로 유지됩니다.

파일명도 손봤습니다. 사람이 읽을 제목은 파일명에 남기고, 중복을 막기 위한 기술 식별자는 눈에 보이지 않는 쪽으로 뺐습니다. 사람에게 필요한 제목과 자동화에 필요한 식별자를 같은 자리에 둘 이유가 없었습니다.

노트 하나가 아니라 Skill 규칙을 고쳤습니다

이번에 가장 크게 남은 판단이 이 부분입니다. 눈앞의 노트 하나만 고치면, 다음 실행에서 예전 형식이 또 그대로 나옵니다.

그래서 읽으며 발견한 문제를 개별 결과물이 아니라 규칙 쪽에 반영하기로 했습니다. 공통 규격, YouTube 어댑터, 실행 어댑터, Wiki 전달 규칙, 그리고 검증기까지 손봤습니다. 검증기는 노트가 규격을 지키는지 확인하는데, 해시태그가 원본에서 뽑은 용어(source_terms)와 맞는지, 타임스탬프가 정해진 콜아웃 안에 있는지, 운영용 필드가 노트로 새어 들어오지 않았는지, 같은 출처 식별자의 노트가 중복으로 생기지 않았는지를 봅니다.

수집과 Wiki화 규칙을 흩어진 코드가 아니라 Skill 규격 쪽에 둔 덕분에, 이번에 준 피드백이 다음 실행부터 같은 기준으로 적용되도록 만들 수 있었습니다.

아직 확인할 것과 다음 단계

처음부터 범용 시스템을 통째로 설계했다면, 검증도 안 된 추상만 잔뜩 쌓였을지 모릅니다. 반대로 YouTube 전용 Skill 하나로 끝냈다면, 출처를 붙일 때마다 규칙이 제각각 갈라졌을 겁니다. 작은 실제 작업 하나로 시작한 덕에 어떤 공통 규칙이 진짜 필요한지가 손에 잡혔고, 완성된 노트를 직접 읽으면서 사람이 볼 정보와 자동화 내부 정보를 가를 수 있었습니다.

다만 영상 한 편으로 작동을 확인한 것과, 여러 출처에서 범용성이 입증된 것은 다릅니다. 자동화를 상시로 켜기 전에 남은 일이 있습니다. 이미 재생목록에 쌓여 있던 기존 항목들을 SQLite에 '과거 기준선'으로 옮겨 두는 일입니다. 이걸 안 해두면 첫 예약 실행이 기존 영상을 죄다 새 영상으로 착각해 노트를 한꺼번에 쏟아낼 수 있습니다. 예약 작업이 재시도되거나 중복 실행될 때도 같은 영상이 두 번 처리되지 않는지 확인해야 합니다.

이 확인이 끝나면 자정 자동화를 다시 켜고, 같은 계층 구조 위에 웹·뉴스·PDF 수집 어댑터를 하나씩 얹어 볼 생각입니다. 구조가 맞게 짜였다면 새 출처를 붙이는 일은 어댑터 하나 추가하는 정도로 끝나야 하는데, 그건 실제로 붙여 봐야 알 수 있는 부분입니다.

도움 받은 글

[도도치 이야기001 # 짧은 부탁을 Skill로 만들고, 실제로 써보며 고쳤습니다](https://www.gpters.org/nocode/post/dodochi-story-001-made-K7IKWM30jNrZqjS)