실제 사례로 보는 Lecture Recap Skill Operations-YouTube 강의의 01:36:17부터 끝까지

이 문서의 목적
사용자의 한 문장 요청이 어떤 Skill에 들어가고, 어떤 자료가 만들어지고, 어느 Gate에서 PASS/FAIL을 받으며, 다음 Skill이 무엇을 인계받았는지를 실제 실행 기록에 근거해 설명한다.

0. 가장 먼저 밝힐 사실

이번 사례는 여러 서브에이전트가 전사를 나눠 수행한 사례가 아니다.

정확한 참여 내역은 다음과 같다.

따라서 이 사례를 “여러 에이전트가 병렬 전사하고 독립 검수까지 마친 완전한 multi-agent canary”라고 부르면 사실과 다르다.

정확한 표현은 다음과 같다.

한 개의 메인 에이전트가 lecture-transcription-notes 생산 Lane을 직접 실행하고, 기계적 QA를 통과시킨 뒤, 완성된 파일을 lecture-recap-library 발행 Lane으로 인계한 single-agent controlled pipeline 사례다.

이 점은 완성도가 낮다는 뜻이 아니다. 이번 원본에는 한국어 자동자막이 있었고 요청 범위도 명확했기 때문에, 별도 STT 에이전트를 부르지 않는 것이 더 빠르고 결정론적인 선택이었다. 다만 작성자와 검수자의 독립성까지 증명한 사례는 아니라는 경계를 남겨야 한다.

1. 사용자의 실제 요청

이 강의 1:36:17부터 마지막까지 해줘.
https://youtu.be/-sKSPLE_rGo

이 요청에는 다음 정보가 들어 있었다.

• 원본 형식: YouTube 영상

• 안정적인 원본 식별자: -sKSPLE_rGo

• 범위: 01:36:17부터 영상 끝까지

• 결과: 단순 전사가 아니라 Recap

• 도메인: 영상 제목과 내용상 IT/AI

• 별도 PDF·슬라이드: 제공되지 않음

• 법률·여행·요리 특수 Lane: 해당 없음

2. 왜 lecture-recap-operations가 아니라 lecture-transcription-notes로 생산을 시작했는가

강의 Skill Fleet에는 “한 요청에서 첫 번째로 선택하는 Primary Lane은 하나”라는 규칙이 있다.

이번 요청은 다음과 같이 분류됐다.

한 개의 제공된 강의 원본
+ 새 타임스탬프 전사
+ 새 IT/일반 강의 Recap
= lecture-transcription-notes 생산 Lane

반대로 사용자가 다음을 요청했다면 lecture-recap-operations가 첫 Primary Lane이 된다.

• 전체 파이프라인을 여러 전문 봇에게 나눠 맡기기

• C&B → Libro Vitae → QA → Library → Web 전체를 조율하기

• 여러 강의의 일괄 작업

• 긴 강의를 여러 증거 작업자에게 분할하기

• 전문 봇 배정과 진행 상태를 총괄 관리하기

즉, lecture-recap-operations는 모든 강의 요청에서 무조건 첫 번째로 실행되는 거대한 Skill이 아니다. 복수 Lane을 조정해야 하는 요청의 Primary Orchestrator다.

이번 생산 실행에서는 더 좁고 직접적인 lecture-transcription-notes가 Primary Lane이었다. 현재 문서는 그 실행을 나중에 lecture-recap-operations 관점으로 해부해 설명하는 문서다.

3. 한눈에 보는 실제 흐름

[사용자 요청]
    │
    ▼
G0. 요청 분류
    lecture-transcription-notes 선택
    │ PASS
    ▼
G1. 원본 신원 고정
    YouTube ID -sKSPLE_rGo / 제목 / 길이 / 날짜
    │ PASS
    ▼
G2. 기존 결과물 중복 검색
    동일 ID 기존 Recap 없음
    │ PASS
    ▼
G3. 원본 자막 확보
    YouTube 한국어 자동자막 JSON3
    │ PASS
    ▼
G4. 요청 구간 영상 확보
    --download-sections 첫 시도
    │ FAIL: 45분 구간 remux 속도가 약 1.9배속이라 600초 안에 미완료
    ▼
R4. 최소 수리
    360p 전체 영상 다운로드 → 로컬 ffmpeg 절단
    │ PASS: 2716.673초
    ▼
G5. 전사 범위 확정
    01:36:17 이후 자막 911개 추출
    │ PASS: 첫 01:36:25 / 끝 02:21:29
    ▼
G6. 화면·발화 대조
    약 5분 간격 프레임 + 자막 구간 확인
    │ PASS
    ▼
G7. 단일 최종 Recap 작성
    10초 브리프 / 19개 타임링크 / 9부 상세 정리
    │ PASS
    ▼
G8. 기계 QA
    필수 섹션·코드펜스·타임링크·전사 개수·해시
    │ PASS
    ▼
[Skill 전환 허가]
    완성 파일 + QA 값 + 고정 메타데이터
    │
    ▼
G9. lecture-recap-library 발행
    staging → hash 검증 → promote → manifest → index → receipt
    │ PASS
    ▼
[완료 상태]
    recap complete
    transcript complete
    Library published
    web not requested

4. 전체 상태표

NOT REQUESTED와 NOT RUN은 FAIL이 아니다. 그러나 PASS로 올려 적어서도 안 된다.

5. 단계별 실제 구현

단계 1. Routing — 어떤 Skill이 첫 책임자인가

입력

• YouTube URL

• 시작 시각 01:36:17

• “Recap을 해 달라”는 목표

판단

원본이 하나이고 신규 전사·Recap을 만드는 것이 즉시 목표이므로 lecture-transcription-notes를 불렀다.

Gate

한 원본 → 새 전사·Recap = 생산 Skill
복수 전문 Lane → 전체 완료 = operations Skill
완성 파일 → 등록·해시·index = library Skill

판정

PASS

단계 2. Source Identity — URL이 아니라 영상 ID를 고정

공유 URL에는 si=... 같은 일시적인 추적값이 붙을 수 있다. 이 값이 바뀌어도 같은 영상은 같은 원본이다.

따라서 다음을 안정 좌표로 사용했다.

video_id: -sKSPLE_rGo
canonical_url: https://youtu.be/-sKSPLE_rGo
requested_start: 01:36:17

yt-dlp 메타데이터에서 다음을 확인했다.

• 공식 제목

• GPTers 채널

• 강의 날짜·업로드 날짜

• 전체 길이

• 한국어 자동자막 존재

판정

PASS

단계 3. Existing-artifact Preflight — 중복 작업을 막음

새로 다운로드하거나 전사하기 전에 다음 위치에서 영상 ID를 검색했다.

• 기존 YouTube transcript 작업대

• Lecture_Recap_Library/90_manifests/library.jsonl

• LLM-Wiki_LCL

같은 ID의 검증된 기존 산출물이 없었으므로 새 생산을 허가했다.

판정

existing_verified_artifact: false
production_authorized: true

단계 4. 자막 확보 — 별도 STT보다 원본 자동자막 우선

YouTube에 한국어 자동자막이 있었기 때문에 다음 순서를 사용했다.

YouTube caption JSON3 확보
→ 요청 범위 필터
→ 안정 ID와 타임스탬프 부여
→ 원전사 보존

이 단계에서 Whisper를 돌리지 않았다. 따라서 C&B의 STT Lane도 호출하지 않았다.

왜 이것이 합리적인가

• 이미 타임스탬프가 있는 자막을 재전사하면 시간과 비용이 늘어난다.

• 새 ASR도 오인식을 만들 수 있다.

• 요청 범위의 구조와 주요 기술 용어는 영상 화면으로 보완할 수 있었다.

남은 위험

YouTube 자동자막에는 다음과 같은 오류가 있었다.

원전사에서는 오류를 삭제하지 않았다. 교정된 설명은 Recap Layer에만 적용했다.

6. 전사는 몇 개의 서브에이전트가 했는가

답: 0개

이번 전사는 다음처럼 진행되지 않았다.

구간 A → 서브에이전트 1
구간 B → 서브에이전트 2
구간 C → 서브에이전트 3
구간 D → 서브에이전트 4

실제로는 다음처럼 진행됐다.

YouTube 자동자막 JSON3 하나
→ Python 스크립트 하나가 요청 시작점 이후를 필터
→ 911개 타임스탬프 세그먼트 생성
→ 한 개의 전사 문서로 직렬화

생성한 전사 Layer

01_sources/source.ko.json3
    원본 YouTube 자동자막

02_transcript/segments_requested_range.json
    911개 안정 세그먼트

02_transcript/transcript_requested_range.md
    요청 범위 원전사 작업본

...__transcript.md
    frontmatter와 출처 정보를 갖춘 최종 타임스탬프 전사

조각 병합 검사를 했는가

여러 에이전트의 조각을 합치는 merge는 하지 않았다. 대신 단일 원본 JSON3에서 시간순으로 필터했기 때문에 다음을 검사했다.

• 첫 세그먼트 시각

• 마지막 세그먼트 시각

• 전체 세그먼트 수

• 시간순 유지

• 요청 시작점 이전 세그먼트 제외

실제 결과는 다음과 같다.

segment_count: 911
first_caption: 01:36:25
last_caption: 02:21:29
requested_range: 01:36:17–02:21:33

multi-agent였으면 무엇을 더 검사해야 하는가

여러 작업자가 각 구간을 맡았다면 다음 Gate가 추가되어야 한다.

missing segment IDs = 0
duplicate segment IDs = 0
order equality = true
overlap conflict = 0 or resolved
range boundaries = continuous

이번 사례에서는 작업자 분할 자체가 없었기 때문에 overlap·중복 merge Gate는 적용 대상이 아니었다.

7. 첫 번째 FAIL — 요청 구간 영상 절단

첫 시도

yt-dlp --download-sections "*1:36:17-"로 요청 구간만 바로 받으려 했다.

실패 원인 — 왜 45분 구간을 받는 데 10분 이상이 필요했는가

이 실패는 단순히 “인터넷이 느렸다”거나 “ffmpeg가 멈췄다”는 문제가 아니다. 다음 세 요소가 함께 작용했다.

1. YouTube가 video와 audio를 별도의 임시 URL로 제공했다.

2. ffmpeg가 선택된 약 45분 구간을 읽으면서 두 스트림을 하나의 파일로 합쳐야 했다.

3. 실제 처리 속도에 비해 실행 제한 600초가 짧았다.

1. Signed media URL이란 무엇인가

사용자가 보는 주소는 일반적인 YouTube 페이지 주소다.

https://youtu.be/-sKSPLE_rGo

하지만 이 페이지 주소 자체가 동영상 파일은 아니다. yt-dlp가 페이지 정보를 해석하면 YouTube가 일정 시간 동안만 사용할 수 있는 실제 media 주소를 돌려준다. URL 안에는 접근을 허가하는 서명값과 만료 정보가 들어가므로 이를 signed media URL이라고 부른다.

쉽게 말하면 다음과 같다.

YouTube 영상 창고에 들어가기 위한 유효기간이 있는 임시 출입증

이번 영상은 고화질 video와 audio가 분리된 형식이어서 대략 다음 두 주소가 생겼다.

임시 video URL ─┐
                 ├─ ffmpeg가 읽고 하나의 동영상 파일로 결합
임시 audio URL ─┘

여기서 signed는 오류나 보안 사고를 의미하지 않는다. YouTube가 정상적으로 발급한 임시 다운로드 주소라는 뜻이다.

2. --download-sections는 결과 구간을 지정하지, 완성 파일을 즉시 꺼내 주지는 않는다

첫 시도에 사용한 명령의 핵심은 다음과 같다.

yt-dlp --download-sections "*1:36:17-"

이 명령은 “01:36:17부터 마지막까지를 결과 파일로 만들어라”라는 뜻이다. 요청한 구간은 다음과 같다.

전체 영상: 약 2시간 21분 34초
시작점: 01:36:17
종료점: 영상 끝
선택 구간: 약 45분 16.7초

시작점을 찾았다고 해서 45분짜리 완성 파일이 즉시 생기는 것은 아니다. ffmpeg는 선택된 구간의 video와 audio 데이터를 원격에서 읽고, 시간축을 맞추고, 새 컨테이너 파일에 차례대로 써야 한다.

01:36:17 지점으로 이동
        ↓
선택 구간의 video packet 읽기
        +
선택 구간의 audio packet 읽기
        ↓
서로 시간축 맞추기
        ↓
새 동영상 파일에 기록
        ↓
45분 구간 끝까지 처리해야 파일 완성

이번 작업은 코덱을 새로 압축하는 무거운 재인코딩이 아니라 주로 remux였다. Remux는 기존 영상·음성 데이터를 다시 인코딩하지 않고 새 컨테이너에 맞춰 결합하는 작업이다. 재인코딩보다는 가볍지만, 선택된 45분 분량의 데이터를 전송받고 기록하는 과정 자체는 여전히 필요하다.

3. 프로그램은 멈춘 것이 아니라 약 1.9배속으로 작업 중이었다

실제 ffmpeg 로그에서는 약 9분 55초가 지난 시점에 선택 구간 중 약 18분 25초까지 처리되어 있었다. 처리 속도는 약 1.86~1.9배속이었다.

실제 경과 시간: 약 9분 55초
완료한 출력 구간: 약 18분 25초
처리 속도: 약 1.9배속

즉, ffmpeg가 멈춰 있거나 같은 자리를 반복한 것이 아니라 정상적으로 파일을 만들고 있었다.

그러나 전체 선택 구간은 약 45분 16.7초였다. 1.9배속으로 처리할 경우 필요한 예상 시간은 다음과 같다.

45분 16.7초 ÷ 1.9
≈ 23분 49.8초

우리 실행 환경은 한 번의 명령을 최대 600초, 즉 10분까지만 기다리도록 설정되어 있었다.

예상 완료 시간: 약 23분 50초
허용 실행 시간: 10분
부족한 시간: 약 13분 50초

따라서 프로그램이 정상적으로 계속 작업하더라도 10분 안에는 완성 파일을 만들 수 없는 조건이었다.

4. “영상 맨 앞부터 읽었다”는 이전 설명은 왜 부정확했는가

처음에는 후반부 구간을 요청했는데도 처리가 느린 것을 보고, ffmpeg가 영상 맨 앞부터 01:36:17 지점까지 직렬로 읽고 있다고 해석했다.

하지만 당시 로그가 직접 보여 준 것은 다음 두 사실뿐이다.

• ffmpeg가 선택 구간을 약 1.9배속으로 처리하고 있었다.

• 600초 제한 안에 선택 구간 전체를 완성하지 못했다.

로그만으로 ffmpeg가 원본의 0초부터 01:36:17까지 전부 읽었다고 확정할 수는 없다. 오히려 출력 진행 시간으로 보면 선택 구간의 약 18분 25초를 실제로 처리한 상태였다.

따라서 정확한 원인은 다음과 같이 기록한다.

요청 시작점 탐색 실패가 확인된 것이 아니라, 선택된 약 45분 구간을 원격 video·audio에서 읽어 하나의 파일로 remux하는 속도가 실행 제한 600초보다 느렸다.

5. .part 파일은 무엇이며 왜 사용하지 않았는가

시간 제한으로 ffmpeg 프로세스가 종료됐을 때 완성 파일 대신 .part 파일이 남았다.

.part는 “다운로드 또는 결합이 아직 끝나지 않은 부분 파일”이라는 표시다.

완성 파일: 요청 구간의 시작부터 끝까지 존재
.part 파일: 처리된 앞부분만 있고 뒤가 없음

일부 플레이어에서 .part 파일이 재생될 수도 있지만, 다음 문제가 있다.

• 요청 구간의 끝까지 들어 있지 않다.

• 컨테이너의 종료 정보가 완성되지 않았을 수 있다.

• 프레임 추출이나 타임스탬프 검증 결과가 불안정할 수 있다.

• 이 파일을 근거로 사용하면 후반부 화면이 누락될 수 있다.

따라서 불완전한 .part 파일을 Recap의 화면 근거로 인정하지 않았다.

판정

프로세스 상태: timeout
작업 진행: 정상 진행 중이었으나 제한 시간 내 미완료
산출물 상태: incomplete .part
Gate G4: FAIL

이 FAIL은 콘텐츠가 틀렸다는 뜻이 아니라, 요청 범위 전체를 담은 검증 가능한 영상 파일이 아직 없다는 뜻이다.

최소 수리 — 왜 전체 360p 다운로드 후 로컬 절단은 성공했는가

전체 파이프라인을 처음부터 다시 시작하지 않았다. 실패 책임이 있는 “영상 구간 확보”만 다른 방식으로 수리했다.

첫 방식과 수리 방식의 차이는 다음과 같다.

실패한 첫 방식

분리된 원격 video URL ─┐
                        ├─ ffmpeg가 원격에서 읽으며 45분 구간 remux
분리된 원격 audio URL ─┘

처리 속도: 약 1.9배속
예상 시간: 약 23분 50초
실행 제한: 10분
결과: 미완료

성공한 수리 방식

음성과 영상이 이미 함께 들어 있는 저해상도 progressive 파일
        ↓
일반 파일 다운로드 방식으로 전체 영상을 로컬에 저장
        ↓
Mac의 로컬 디스크에서 01:36:17 이후만 절단
        ↓
ffprobe로 절단 파일 길이 검증

progressive 형식은 video와 audio가 하나의 파일에 함께 들어 있는 형식이다. 그래서 원격의 분리된 두 스트림을 ffmpeg가 실시간으로 맞춰 합치는 단계를 피할 수 있었다.

또한 일반 다운로드는 영상을 실제 재생하듯 1배속 또는 2배속으로 처리할 필요가 없다. 서버와 네트워크가 허용하는 파일 전송 속도로 로컬에 저장할 수 있다. 파일이 Mac에 저장된 뒤의 절단은 인터넷 상태나 signed URL 만료와 관계없이 로컬 디스크에서 수행된다.

원격에서 읽기 + 두 스트림 맞추기 + 새 파일 쓰기
보다
작은 단일 파일 다운로드 + 로컬 디스크에서 절단
이 이번 환경에서는 더 안정적이었다.

실제 수리 순서는 다음과 같다.

불완전한 .part 파일 제거
→ 360p progressive 전체 영상 다운로드
→ 로컬 ffmpeg -ss 01:36:17 절단
→ ffprobe로 길이 재검증

수리 결과

segment duration: 2716.672993 seconds
segment size: 32,133,418 bytes
Gate G4: PASS

2716.672993초는 약 45분 16.7초로 요청 범위와 일치한다. 이 길이를 다시 읽어 확인했기 때문에, 이후 프레임 추출과 Recap 검증은 불완전한 부분 파일이 아니라 완성된 로컬 절단본을 기준으로 수행했다.

이 실패에서 운영 Skill에 반영한 교훈

이 경험을 바탕으로 lecture-transcription-notes Skill에도 다음 fallback을 추가했다.

긴 후반부 구간의 --download-sections가 원격 video·audio를 ffmpeg로 remux하는 동안 실행 제한을 넘기면, timeout만으로 원본 맨 앞부터 읽었다고 추정하지 않는다. 로그의 처리 속도·출력 진행 시간·요청 구간 길이를 비교하고, 불완전한 부분 파일을 제거한 뒤 저해상도 progressive 전체 영상을 일반 다운로드한다. 이후 로컬에서 요청 구간을 절단하고 ffprobe로 실제 길이를 검증한다.

8. 화면 증거는 어떻게 검사했는가

자동자막만 읽으면 다음을 잘못 교정할 수 있다.

• 고유 도구명

• 슬라이드의 단계 수

• 화면에 나온 흐름도

• 강점·한계의 실제 표현

• 코드·워크스페이스 구조

따라서 절단 영상에서 약 5분 간격 프레임을 뽑아 contact sheet를 만들고 확인했다.

확인한 대표 화면은 다음과 같다.

1. 온톨로지 서버 — 검수 회고·산출물 인덱스 성격의 웹 문서

2. GPT/Claude의 Self Discovery 질문 화면

3. Knowledge Manager는 요약기가 아니라 지식 운영 하네스 슬라이드

4. 한 번 실행하면 거치는 8단계 슬라이드

5. 강점과 한계: 풍부한 프로토콜, 부분적인 강제 슬라이드

6. VS Code의 PRD·Wiki·구현 폴더 구조

이 Gate가 증명한 것

• 자막의 주제 전환과 실제 화면 전환이 크게 일치했다.

• Knowledge Manager의 8단계와 검수 Gate가 실제 슬라이드 내용이었다.

• 강의 후반부가 Q&A와 운영 종료 대화로 넘어가는 시점을 구분할 수 있었다.

이 Gate가 증명하지 않은 것

• 모든 프레임을 1초 단위로 검수했다는 뜻은 아니다.

• 모든 자동자막 단어가 정확하다는 뜻도 아니다.

• 화면 샘플링이 독립 QA를 대신하지는 않는다.

9. Recap은 누가 어떻게 작성했는가

작성자 수: 1명

타디스가 전체 전사와 화면 근거를 읽고 하나의 Recap을 작성했다.

여러 작업자가 각자 최종 요약을 만든 뒤 합치지 않았다. 그렇게 하면 표현·중복·우선순위가 충돌할 수 있기 때문이다.

입력

• 공식 YouTube 메타데이터

• 요청 범위 자동자막 911개

• 5분 window 텍스트

• 주요 타임스탬프 구간 원전사

• 360p 요청 구간 영상

• contact sheet 화면 근거

출력 구조

Source / 검증 정보
→ 10초 브리프
→ 핵심 문장
→ Highlight Timestamps 19개
→ 9부 시간순 상세 정리
→ 실전 인터뷰 템플릿
→ 최소 운영 파이프라인
→ 검수 Gate 체크리스트
→ 용어사전
→ 액션아이템

시간순 9부 구조

1. 보편적 지식베이스가 어려운 이유

2. Self Discovery와 Grill Me

3. Knowledge Manager는 요약기가 아니라 하네스

4. 워크스페이스 책임 계층

5. 한 번 실행하면 거치는 8단계

6. 최종 결과보다 과정 검수

7. Knowledge Manager의 강점과 한계

8. Personal Knowledge Manager 실습 과제

9. 통합 Wiki와 분리 Wiki Q&A

실질 강의와 운영 대화 분리

약 02:18:28 이후에는 연결 끊김, Zoom 호스트, 녹화 종료에 관한 운영 대화가 이어졌다.

• 원전사: 끝까지 보존

• Recap 본문: 실질 지식 내용과 운영 종료 대화를 구분

이렇게 원본 보존과 독자용 편집을 분리했다.

10. Recap QA란 무엇이며, 이번 사례에서는 어떻게 했는가

QA는 Quality Assurance, 즉 품질 보증을 뜻한다.

강의 Recap에서 QA는 단순히 맞춤법이나 문장이 매끄러운지만 보는 일이 아니다.

Recap QA란 완성된 강의 Recap이 원본 강의를 빠뜨리거나 왜곡하지 않았는지, 요청한 범위를 지켰는지, 독자가 실제로 믿고 사용할 수 있는 상태인지 검사하는 품질검수 과정이다.

요리로 비유하면

전사·화면 분석·Recap 작성 = 요리
Recap QA = 손님에게 내기 전 최종 검사

요리를 검사할 때 단순히 접시가 예쁜지만 보지 않는다.

• 주문한 음식이 맞는가?

• 재료가 빠지지 않았는가?

• 조리 순서가 잘못되지 않았는가?

• 먹어도 되는 상태인가?

• 다른 손님의 음식과 바뀌지 않았는가?

Recap QA도 같은 방식으로 다음을 검사한다.

요청한 강의와 범위가 맞는가
원본 발언과 설명이 일치하는가
중요한 내용이 빠지지 않았는가
강의 순서가 뒤바뀌지 않았는가
자동자막 오류를 잘못 확정하지 않았는가
타임스탬프가 실제 원본 위치를 가리키는가
문서와 발행 파일이 기술적으로 정상인가

1. 요청 범위 QA

이번 사용자의 요청 범위는 다음과 같았다.

01:36:17부터 영상 마지막까지

따라서 다음을 검사했다.

• 01:36:17 이전 내용을 Recap의 중심 내용으로 섞지 않았는가?

• 영상 마지막 부분까지 전사가 이어지는가?

• 마지막 Q&A와 운영 종료 대화까지 확인했는가?

• 절단 영상 길이가 요청 범위와 일치하는가?

실제 확인값은 다음과 같다.

절단 영상 길이: 약 45분 16.7초
첫 자막: 01:36:25
마지막 자막: 02:21:29
자막 세그먼트: 911개

요청 시작점과 첫 자막 사이에 약 8초 차이가 있는 것은 해당 순간에 자막 발화가 시작되지 않았기 때문이다. 전사를 임의로 01:36:17에 맞춰 만들어 넣지 않았다.

2. 원본 근거 QA

Recap에 적힌 설명이 실제 강사의 발언과 화면에 근거하는지 확인했다.

예를 들어 Recap에 다음과 같은 문장이 있다.

Knowledge Manager는 단순 요약기가 아니라 지식 운영 하네스다.

이 문장을 검사할 때는 다음을 확인한다.

• 강사가 실제로 그런 취지로 말했는가?

• 화면 슬라이드에도 같은 개념이 제시되었는가?

• 연결한 타임스탬프가 해당 설명 근처를 가리키는가?

• 작성자의 해석을 강사의 직접 주장처럼 바꾸지 않았는가?

이처럼 Recap의 주장과 원본 증거를 연결하는 검사를 Grounding QA라고 할 수 있다.

3. Coverage QA — 중요한 내용이 빠지지 않았는가

강의의 실제 흐름은 대략 다음과 같았다.

보편적 지식베이스의 어려움
→ Self Discovery와 Grill Me
→ Knowledge Manager 개념
→ 워크스페이스 책임 계층
→ 8단계 실행 파이프라인
→ 과정 검수 Gate
→ 강점과 한계
→ 실습 과제
→ 통합 Wiki와 분리 Wiki Q&A

QA에서는 다음과 같은 누락을 찾는다.

• 핵심 주장 누락

• 실제 사례 누락

• 시연·실습 과제 누락

• 강사의 주의사항 누락

• Q&A 누락

• 화면에만 나온 중요한 구조 누락

이번 Recap에서는 이 흐름을 9부 구조로 만들어 Coverage를 확인했다.

4. 순서 QA — 강의의 교육적 흐름이 보존됐는가

내용이 모두 들어 있어도 순서가 크게 바뀌면 강사의 설명 방식이 달라질 수 있다.

원본:
문제 제기 → 해결 방법 → 구현 구조 → 한계 → 실습

잘못된 재배열:
실습 결과 → 문제 제기 → 구현 구조 → 해결 방법

따라서 Recap의 9부 구조가 원본 강의의 주제 전환 순서를 따르는지 확인했다.

주제별 재구성이 필요한 경우에는 원래 강의 순서와 편집자가 새로 묶은 설명을 구분해야 한다. 이번 Recap은 기본적으로 시간순을 유지했다.

5. 자동자막 교정 QA

YouTube 자동자막에는 기술 용어 오인식이 있었다.

교정 기준은 다음과 같다.

화면 또는 문맥으로 확인됨
→ Recap에서 교정

확인되지 않음
→ 불확실성 표시 또는 원전사 표현 보존

확실하지 않은 인명·저장소 이름을 그럴듯하게 추측해 확정하지 않는 것도 QA의 일부다.

6. 타임스탬프 QA

Recap에는 원본으로 바로 이동하는 타임링크 19개가 들어 있다.

QA에서는 다음을 본다.

• 원본 영상 ID가 -sKSPLE_rGo로 일치하는가?

• 링크의 시각이 요청 범위 안에 있는가?

• 링크를 열었을 때 설명한 주제 근처로 이동하는가?

• 서로 다른 설명에 같은 잘못된 시각을 반복하지 않았는가?

타임스탬프는 장식이 아니라 독자가 Recap의 주장을 원본에서 확인할 수 있게 하는 증거 좌표다.

7. 문서 구조 QA

컴퓨터가 결정론적으로 검사하기 좋은 부분이다.

• frontmatter가 있는가?

• 필수 섹션이 모두 존재하는가?

• Markdown 코드 블록이 모두 닫혔는가?

• 타임링크가 존재하는가?

• 전사 타임스탬프 수가 맞는가?

• 빈 파일이나 비정상적으로 짧은 파일이 아닌가?

• 줄 수·바이트·SHA-256을 읽을 수 있는가?

이번 사례에서는 qa_recap.py가 다음을 검사했다.

Recap 기계 검사

• frontmatter 존재

• 필수 섹션 6종 존재

• 코드 fence 짝수 여부

• YouTube 타임링크 수

• 줄 수·바이트 수

• SHA-256

Transcript 기계 검사

• frontmatter 존재

• 타임스탬프 행 개수

• 첫·끝 타임스탬프

• 줄 수·바이트 수

• SHA-256

실제 결과

recap:
  lines: 586
  bytes: 28,332
  required_sections: all true
  timestamp_links: 19
  code_fence_balance: true

transcript:
  lines: 934
  bytes: 47,278
  timed_lines: 911
  first: 01:36:25
  last: 02:21:29

Recap QA의 네 가지 층

① 기계적 QA

프로그램으로 명확히 검사할 수 있는 항목이다.

파일 존재
필수 섹션 존재
자막 911개
타임링크 19개
코드 블록 정상
첫·마지막 타임스탬프
SHA-256 계산

장점은 같은 기준을 반복 적용할 수 있고 숫자·파일 오류를 빠르게 잡는다는 것이다.

그러나 프로그램만으로 강사의 미묘한 취지를 왜곡했는지, 설명이 정말 이해하기 쉬운지까지 완전히 판정할 수는 없다.

② 내용·의미 QA

사람이나 LLM이 원본과 Recap을 비교하는 검사다.

강사의 주장과 일치하는가
중요한 설명이 누락되지 않았는가
교육 순서가 보존됐는가
과장하거나 추측한 표현이 없는가
화면과 발언이 일치하는가

이번 사례에서는 타디스가 Recap의 앞·중간·끝을 다시 읽으며 다음을 확인했다.

• source 정보가 맞는지

• 8단계 파이프라인이 강의 발화와 일치하는지

• Gate 설명이 자막 근거를 넘어서 과장되지 않았는지

• 실전 템플릿이 강의의 의도와 연결되는지

• 끝부분 Q&A가 빠지지 않았는지

③ 독립 QA

Recap을 작성하지 않은 별도의 검수자가 보호된 원본에서 기대 내용을 다시 구성하고 Recap과 비교하는 방식이다.

최종 작성자
→ Recap 작성

별도 QA 에이전트
→ 보호된 원본에서 기대 Coverage 재구성
→ Recap과 비교
→ PASS 또는 FAIL

작성자가 자기 결과물을 다시 보면 자신의 해석과 누락을 그대로 지나칠 수 있다. 시험 답안을 작성한 학생과 채점자를 분리하는 것과 같은 이유다.

이번 사례에서는 별도 QA 에이전트를 호출하지 않았다. 타디스가 작성과 Readback을 모두 수행했다.

따라서 다음처럼 기록한다.

mechanical_QA: PASS
main-agent_readback: PASS
independent_QA_agent: NOT RUN

NOT RUN은 실패가 아니지만 독립 QA를 통과했다는 뜻도 아니다.

④ 발행 QA

Recap 내용이 올바르더라도 Library에 복사·등록하는 과정에서 다른 파일이 선택되거나 index가 빠질 수 있다.

그래서 발행 뒤에는 다음을 검사했다.

• 목적지 파일이 실제로 존재하는가?

• 원본과 Library 사본의 SHA-256이 같은가?

• Manifest에 등록됐는가?

• 00_INDEX.md에 정확한 링크가 생겼는가?

• Receipt가 promoted 상태인가?

• unresolved assets가 0인가?

• 임시 staging 파일이 제거됐는가?

이것은 Recap 내용 자체의 품질검사라기보다, 검증된 Recap이 손상 없이 다음 저장소로 전달됐는지 확인하는 전달·발행 QA다.

이번 사례의 QA 상태표

이번 사례를 정확히 표현하는 문장

타디스가 Recap을 작성한 뒤 기계적 QA와 원본 Readback을 수행했고, Library 발행 QA까지 통과했다. 그러나 작성자와 분리된 별도의 독립 QA 에이전트는 호출하지 않았다.

이번 산출물은 요청 범위 생산·기계 검수·Library 발행에는 PASS했지만, Fleet의 최고 수준 Shadow Canary가 요구하는 “독립 QA까지 포함한 동일-artifact 비퇴행성 증명”을 수행한 것은 아니다.

한 문장 정의

Recap QA란 요약문이 보기 좋게 작성됐는지만 보는 것이 아니라, 요청 범위·원본 발언·화면·순서·누락·타임스탬프·문서 구조·발행 결과까지 확인하여 이 Recap을 믿고 사용해도 되는지 판정하는 과정이다.

11. 다음 Skill은 무엇을 인계받았는가

lecture-transcription-notes 생산 Lane에서 Recap과 전사가 완성된 뒤에야 lecture-recap-library를 불렀다.

Library Skill에 넘긴 것은 “대충 완성된 것 같은 문서”가 아니라 다음과 같은 고정 패킷이었다.

artifact path
artifact type
human title
domain
course
lecture coordinate
producer
source SHA-256
bytes
originating QA values
linked assets decision

Recap 인계값

artifact_type: recap
course: ai-workspace-governance
lecture: 2026-07-29-claude-code-codex-review-harness
source_sha256: 78691ff166130bf990d869fc2e4572c5ccc345c01021c84a0aa60a4e5fd9fa71
bytes: 28332
linked_assets: none

Transcript 인계값

artifact_type: transcript
course: ai-workspace-governance
lecture: 2026-07-29-claude-code-codex-review-harness
source_sha256: ee9fba450037744ee2855450d60712acbca9f557e54874703a23f610c68ac7c4
bytes: 47278
linked_assets: none

Library Skill은 내용을 다시 쓰지 않았다. 책임은 발행에 한정됐다.

완성 source
→ 00_inbox staging
→ staged hash 확인
→ 최종 목적지 복사
→ manifest 행 추가
→ 00_INDEX.md 재생성
→ receipt 저장
→ staging 제거
→ destination hash 재확인

12. Library Gate의 PASS 조건

발행 명령이 성공했다는 stdout만으로 완료라고 하지 않았다.

다음을 다시 읽었다.

• 목적지 파일 존재

• source와 destination SHA-256 일치

• manifest에 intake ID 2건 존재

• receipt status: promoted

• unresolved assets 0

• 00_INDEX.md에 정확한 링크 존재

• 00_inbox의 staging 제거

실제 Receipt

Recap:
  intake_id: 20260803-175558-3bbdfe0f
  status: promoted

Transcript:
  intake_id: 20260803-175608-6348c97e
  status: promoted

최종 Library 좌표

Lecture_Recap_Library/
└── ai-workspace-governance/
    └── 2026-07-29-claude-code-codex-review-harness/
        ├── ...__recap.md
        └── ...__transcript.md

13. PASS가 났다고 자동으로 다음 모든 공정을 실행하는가

아니다. 기술적으로 잘 만들어졌다는 판정과 다음 장소로 내보낼 권한은 다른 상태다.

어린이에게 설명하면 다음과 같다.

시험에서 100점을 받은 종이와 학교 밖으로 나가도 된다는 허가증은 서로 다른 종이다.

이번 사례의 상태는 다음과 같다.

Recap built: PASS
Mechanical QA: PASS
Library publication: REQUESTED BY WORKFLOW AND PASS
Web publication: NOT REQUESTED
Independent multi-agent QA: NOT RUN

Library PASS가 웹 배포 허가를 뜻하지 않는다. 그래서 보호형 웹 미러는 이번 요청에서 갱신하지 않았다.

14. FAIL이 나면 전체를 처음부터 다시 하는가

원칙적으로 아니다. 가장 작은 실패 책임으로 되돌린다.

실제 FAIL은 영상 구간 확보에서 발생했다. 전사와 Recap을 모두 폐기하지 않고, 영상 확보 단계만 다른 방식으로 수리한 뒤 같은 Gate를 다시 통과했다.

15. 실제 구현과 이상적인 Full Operations의 차이

Full Operations가 필요한 조건

다음과 같은 경우에는 이번보다 더 강한 구조를 쓴다.

• 3~4시간 이상 장시간 영상

• 자동자막이 없거나 품질이 매우 낮음

• 여러 발표자와 겹치는 발화

• PDF·슬라이드·채팅·참고문헌을 모두 정렬해야 함

• 법률·세무처럼 공식 권위 검증이 필요함

• 기존 Golden Recap과 품질 비교가 필요함

• 웹 공개 전 독립 QA가 필수임

16. 다음에 전사를 여러 서브에이전트로 나눈다면

예를 들어 4시간 강의를 4개 evidence lane으로 나누면 다음처럼 한다.

보호 원본 + 고정 해시
        │
        ├── Worker A: 00:00–01:00
        ├── Worker B: 01:00–02:00
        ├── Worker C: 02:00–03:00
        └── Worker D: 03:00–04:00

각 Worker는 최종 Recap을 쓰지 않는다. 다음만 제출한다.

segment IDs
핵심 발화
예시·질문·시연
화면·교재 좌표
용어 교정 후보
불확실성
누락 후보

그 다음 결정론적 merge가 검사한다.

모든 기대 segment ID가 있는가
중복 segment ID가 없는가
순서가 같은가
경계 overlap이 정책대로 처리됐는가
원본 범위가 연속적인가

하나의 Master Composer가 이 evidence package를 받아 최종 Recap 하나를 만든다. 마지막에 별도의 QA Agent가 composer가 보지 못한 보호 원본에서 Coverage를 재구성해 PASS/FAIL을 낸다.

네 명의 Worker가 네 개의 최종 요약을 쓰는 구조가 아니다.
네 명은 증거를 만들고, 한 명만 최종 이야기를 쓴다.

17. 이번 사례의 품질을 어떻게 평가해야 하는가

강점

• 안정적인 YouTube ID와 요청 범위를 고정했다.

• 원 자동자막을 삭제하지 않고 별도 Layer로 보존했다.

• 실패한 부분 다운로드를 완성으로 오인하지 않았다.

• 로컬 절단 영상으로 요청 범위를 실제 검증했다.

• 자막 911개와 첫·끝 좌표를 기계적으로 확인했다.

• 화면 프레임으로 주요 기술 용어와 단계 구조를 교차확인했다.

• 한 명의 작성자가 중복 없는 시간순 Recap을 만들었다.

• 19개 원본 타임링크를 넣었다.

• Library source·destination·manifest·receipt·index를 모두 재검증했다.

• 실행 중 발견한 함정을 생산 Skill에 즉시 반영했다.

한계

• 별도 STT 엔진으로 자막 정확도를 전수 대조하지 않았다.

• 화면은 약 5분 간격 중심으로 검토했으며 모든 프레임을 검사한 것은 아니다.

• 작성자와 QA가 같은 메인 에이전트였다.

• 별도의 Libro Vitae 최종 작성자와 독립 QA Agent를 호출하지 않았다.

• 기존 Golden Recap과 동일-artifact 비퇴행성 비교를 수행하지 않았다.

• 웹 렌더링·모바일 QA는 요청 범위 밖이었다.

정확한 결론

요청된 구간 Recap 생산: PASS
타임스탬프 전사 생산: PASS
기계적 QA: PASS
Library 발행: PASS
독립 multi-agent QA: NOT RUN
Web release: NOT REQUESTED
Full fleet golden canary: NOT CLAIMED

18. 공정별 인계 문장 예시

Source Intake → Transcript

PASS. YouTube ID -sKSPLE_rGo와 한국어 자동자막 JSON3를 고정했다.
요청 범위는 01:36:17–02:21:33이며, 다음 공정은 이 원본만 사용한다.

Transcript → Evidence

PASS. 요청 범위 자막은 911개이며 첫 시각은 01:36:25,
마지막 시각은 02:21:29다. 원전사와 구조화 세그먼트를 함께 인계한다.

Evidence → Composer

PASS. 주요 화면 전환과 자막 주제가 대조되었다.
불확실한 인명·저장소명은 단정하지 말고, 확정된 용어만 교정한다.

Composer → QA

PASS 후보. Recap에는 19개 원본 타임링크와 9부 상세 정리가 있다.
QA는 필수 섹션, 타임링크, 전사 개수, 첫·끝 좌표, 해시를 검사한다.

QA → Library

PASS. Recap과 Transcript의 path·bytes·SHA-256을 고정했다.
Library는 내용을 수정하지 말고 동일 파일을 staging·promote·index한다.

Library → 종료

PASS. source와 destination hash가 일치하고 receipt는 promoted다.
Web은 요청되지 않았으므로 NOT REQUESTED 상태로 종료한다.

19. 재사용 가능한 Operations 체크리스트

Routing

• 사용자의 즉시 목표가 생산·법률·여행·발행·전체 조율 중 무엇인지 분류했다.

• 첫 Primary Lecture Skill은 하나만 선택했다.

• 실제로 호출하지 않은 전문 봇을 참여자로 적지 않았다.

Source

• 안정적인 원본 ID를 고정했다.

• 추적 query를 새 원본으로 오인하지 않았다.

• 기존 verified 산출물을 먼저 검색했다.

• 원본·자막·영상 해시를 기록했다.

Transcript

• raw와 clean/final Layer를 분리했다.

• 범위 시작·끝을 확인했다.

• segment count와 시간순을 검사했다.

• 여러 worker를 썼다면 missing=0·duplicate=0·order equality를 검사했다.

• worker 수를 실제 호출 수 그대로 보고했다.

Evidence

• 주요 화면·슬라이드·코드와 발화를 대조했다.

• 불확실한 용어를 단정하지 않았다.

• 운영 대화와 실질 강의 내용을 구분했다.

Composer

• 최종 Recap 작성자는 한 명이다.

• worker notes를 competing final summaries로 만들지 않았다.

• 시간순·예시·질문·실습·Q&A를 보존했다.

QA

• 필수 섹션과 범위를 기계적으로 검사했다.

• 사람 readback과 독립 QA를 구분했다.

• PASS·FAIL·NOT RUN·NOT REQUESTED를 분리했다.

• FAIL은 가장 작은 책임 단계로 반환했다.

Publication

• source path·bytes·SHA-256이 고정되었다.

• publisher가 내용을 다시 쓰지 않았다.

• destination·manifest·receipt·index를 다시 읽었다.

• Library와 Web 상태를 분리했다.

20. 마지막 한 장 요약

┌──────────────────────────────────────────────────────────────────┐
│ 사용자: YouTube 강의 01:36:17부터 끝까지 Recap                  │
└──────────────────────────────┬───────────────────────────────────┘
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ Primary 생산 Skill: lecture-transcription-notes                  │
│ 이유: 한 개 원본 → 신규 전사·일반 IT Recap                      │
└───────────────┬──────────────────────────────────────────────────┘
                ▼
┌────────────────────┐  FAIL  ┌────────────────────────────────────┐
│ 요청 구간 직접 DL │ ─────▶ │ 360p 전체 DL → 로컬 절단 → PASS  │
└────────────────────┘        └──────────────────┬─────────────────┘
                                                ▼
┌──────────────────────────────────────────────────────────────────┐
│ 전사: 서브에이전트 0명                                           │
│ YouTube JSON3 → 911개 segment → 1개 타임스탬프 전사             │
└──────────────────────────────┬───────────────────────────────────┘
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ 증거 대조: 5분 간격 프레임 + 상세 자막 구간                     │
└──────────────────────────────┬───────────────────────────────────┘
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ Final Writer 1명: 타디스                                         │
│ 19개 타임링크 + 9부 상세 Recap + 실전 템플릿                    │
└──────────────────────────────┬───────────────────────────────────┘
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ QA: 기계 PASS + 타디스 readback PASS                             │
│ 독립 QA Agent: NOT RUN                                           │
└──────────────────────────────┬───────────────────────────────────┘
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ 다음 Skill: lecture-recap-library                                │
│ staging → hash → promote → manifest → receipt → index            │
└──────────────────────────────┬───────────────────────────────────┘
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ 최종 상태                                                        │
│ Recap PASS / Transcript PASS / Library PASS                      │
│ Web NOT REQUESTED / Full multi-agent canary NOT CLAIMED          │
└──────────────────────────────────────────────────────────────────┘

결론

이번 사례의 핵심은 “많은 에이전트를 불렀다”가 아니다.

필요하지 않은 전문 에이전트는 부르지 않고, 한 개의 생산 Skill이 원본과 요청 범위를 고정해 Recap을 완성한 뒤, PASS 증거가 생겼을 때만 발행 Skill로 넘어갔다. 중간에 영상 구간 확보가 실패했을 때는 전체 공정을 다시 시작하지 않고 그 단계만 최소 수리했다.

따라서 이 사례에서 Skill Operations는 다음 네 가지로 구현됐다.

1. 첫 책임 Skill을 하나만 선택한다.

2. 각 공정은 파일·좌표·해시 같은 실제 산출물을 남긴다.

3. PASS 전에는 다음 Skill로 넘기지 않는다.

4. 호출하지 않은 에이전트와 실행하지 않은 QA를 실행한 것처럼 말하지 않는다.

이것이 실제 작업 기록에 맞는 가장 정확한 설명이다.