PO가 Claude와 함께 DoveRunner Lab과 튜토리얼 영상 9편을 만들며 배운 것

소프트웨어 튜토리얼 영상에는 유통기한이 있습니다. 제품 화면과 메뉴는 업데이트마다 조금씩 바뀌는데, 영상은 촬영한 날의 모습에 그대로 멈춰 있기 때문입니다. 제가 맡은 제품의 YouTube 튜토리얼도 마찬가지였습니다. 회사 이름이 PallyCon에서 DoveRunner로 바뀌기 전에 만든 영상이라 화면 속 메뉴와 명령어가 지금과 달랐고, 한 편을 점검해 보니 내레이션에 나오는 사실 17개 중 9개가 이미 바뀌었거나 불완전했습니다.

보안 제품은 사정이 하나 더 있습니다. 잘 동작할수록 눈에 보이지 않는다는 점입니다. 콘텐츠 보호 기능이 제대로 작동하면 데모는 그냥 평범한 영상 재생처럼 보이고, 반대로 무언가 잘못되면 처음 써 보는 개발자는 원인을 짐작하기조차 어렵습니다.

저는 DoveRunner에서 프로덕트 오너이자 DevRel로 일하고 있으며, 지난 9월 중순부터 약 한 달 동안 이 두 문제를 함께 풀었습니다. 고객과 사내 구성원이 보안 제품을 처음 익힐 수 있는 공개 개발자 사이트 ‘DoveRunner Lab’을 만들고, 그 안에 들어갈 튜토리얼 영상을 코드로 다시 만드는 작업입니다. 코드는 거의 전부 AI 코딩 에이전트인 Claude Code가 작성했습니다. 이 글에서는 기술 스택보다는 어떤 문제를 풀려고 했는지, 그리고 AI와 함께 일하면서 무엇이 잘 되었고 무엇이 사람의 몫으로 남았는지에 대해 알아보겠습니다. 미리 말씀드리면, 결과물의 품질은 AI의 실력보다 제가 어디에 확인 지점을 두었느냐에 더 크게 좌우되었습니다.

개요

두 프로젝트는 같은 질문에서 출발했습니다. DoveRunner를 처음 접하는 사람이 혼자서 보호된 콘텐츠를 재생해 보고, 실패하면 그 이유까지 이해하려면 무엇이 필요할까요?

• 튜토리얼 영상 프로젝트: HTML로 영상을 구성하고 렌더링하는 오픈소스 프레임워크인 HyperFrames로 튜토리얼 영상을 코드로 다시 만드는 작업입니다. 2026년 9월 16일 영상 한 편짜리 개념 검증으로 시작해 지금까지 9편을 만들었고, 모두 Lab 아카데미의 레슨으로 들어가 있습니다.
• DoveRunner Lab: 보호된 영상을 재생하는 동안 보안 기능이 실제로 무엇을 하고 있는지 실시간으로 보여주는 ‘플레이그라운드’와, 제품별 입문 코스를 담은 ‘아카데미’로 구성된 사이트입니다. 영상 프로젝트보다 일주일 늦은 9월 23일 첫 커밋 후 10월 12일 lab.doverunner.com으로 공개했습니다.

영상을 유지보수 문제로 보기

오래된 영상을 새로 찍는 것만으로는 문제가 해결되지 않습니다. 콘솔 화면이나 문서가 바뀔 때마다 다시 녹화하고, 편집하고, 녹음하고, 자막을 맞춰야 하기 때문입니다. 그래서 계획서에 원칙 하나를 적어 두었습니다. “첫 번째 영상이 아니라 두 번째, 열 번째 영상을 기준으로 최적화한다.”

이에 따라 영상 한 편은 하나의 프로젝트가 되었습니다. 최신 문서와 대조한 튜토리얼 스펙과 내레이션 원고, 실제 콘솔 캡처, HTML 장면 구성이 저장소에 함께 들어 있고, 내레이션 음성과 자막, 배경 음악은 스크립트로 생성합니다. 원고 한 줄을 고치면 해당 장면의 음성과 자막만 다시 만든 뒤 영상 전체를 다시 렌더링하면 됩니다.

Claude가 맡은 일은 생각보다 넓었습니다. 원본 영상의 스크립트를 뽑아 현재 문서와 사실관계를 대조하고, 스토리보드와 내레이션 초안을 쓰고, 장면과 공용 컴포넌트를 만들고, 음성 합성과 자막 정렬 파이프라인까지 구성했습니다. 공용 컴포넌트가 쌓인 뒤로는 새 영상 프로젝트를 만든 지 하루 이틀 만에 첫 렌더링이 나오는 경우가 많았습니다. 하지만 직접 해 보니 AI에게만 맡기면 안 되는 지점도 분명했습니다.

• 내레이션 승인 게이트: 승인 표시가 없으면 음성 합성 스크립트가 실행되지 않도록 만들었고, 원고가 바뀌면 승인이 다시 풀리기 때문에, 제가 확인하지 않은 원고로는 음성이 만들어지지 않습니다. 실제 음성이 예상보다 길게 나와 첫 영상이 72초에서 90초로 늘어났을 때도, 승인한 원고를 줄이는 대신 장면을 늘리는 쪽을 선택했습니다.
• 눈대중으로 그린 강조 박스: 화면의 특정 버튼에 강조 박스를 그리는 작업에서 Claude는 좌표를 추정했고, 박스가 엉뚱한 입력 칸을 가리키는 일이 반복되었습니다. 결국 이미지에서 실제 요소의 경계를 측정하는 도구를 만들고, “강조 박스 좌표는 눈대중으로 정하지 않는다”는 규칙을 프로젝트 지침에 넣었습니다.
• 자동 검사와 실제 품질의 차이: 자동 검사는 모두 통과했는데 명령어 상자가 화면 밖으로 넘치거나, 어두운 배경에 맞지 않는 로고가 들어간 경우가 있었습니다. 지금은 렌더링 전에 장면별 스냅샷을 한 장에 모아 사람이 직접 보는 단계를 반드시 거칩니다.
• 발음: 음성 합성 엔진이 도메인 주소의 점을 읽지 않거나 브랜드 이름을 엉뚱하게 발음하는 경우가 있었습니다. 처음에는 원고에 발음을 풀어 썼는데 그 표기가 자막에도 그대로 나왔습니다. 그래서 자막은 그대로 두고 음성 입력만 바꾸는 발음 사전을 따로 두었습니다. 예를 들어 CMAF는 음성 엔진에만 “See-maff”로 넘겨 읽도록 했습니다.

보이지 않는 보안을 보이게 만들기

Lab은 원페이저와 단계별 개발 계획부터 쓰고 시작했습니다. 저는 개발자가 아니라 프로덕트 오너이기 때문에, 제가 직접 통제할 수 있는 것은 범위와 판단이라고 보았습니다. 그래서 세션마다 “편집하기 전에 먼저 계획을 제안한다”는 규칙을 두고, Claude가 내놓은 계획에서 범위를 넘는 부분을 잘라낸 뒤에 작업을 시작했습니다. 한 단계는 Claude 구독 요금제의 사용량 한도가 초기화되기 전, 즉 한 번의 작업 시간 안에 끝나도록 나눴고, AWS 콘솔 작업이나 실제 기기 테스트처럼 사람만 할 수 있는 일은 세션 밖으로 뺐습니다.

세션이 끝날 때마다 Claude는 현재 상태와 다음 할 일을 ‘HANDOFF.md’에, 버전별 이력을 ‘WORKLOG.md’에 남기고, 되돌리기 어려운 결정은 ‘아키텍처 결정 기록’(Architecture Decision Record, 이하 ADR)으로 남깁니다. 새 세션의 Claude는 이전 대화를 기억하지 못하기 때문에, 이 문서가 없으면 세션마다 제가 맥락을 처음부터 다시 설명해야 합니다. 대신 Claude가 세션을 시작할 때 HANDOFF.md부터 읽고 지난 작업을 이어갑니다. 공개 시점까지 쌓인 ADR은 27개입니다.

가장 기억에 남는 순간은 Claude가 확신을 갖고 틀렸을 때입니다. Safari에서 FairPlay 재생이 실패하자 Claude는 처음에 오픈소스 플레이어의 버그라고 판단했고, 이어서 클라이언트 버그 네 개를 고친 뒤에는 FairPlay 인증서 등록이 빠진 것이 원인이라는 결론을 ADR로 남겼습니다. 하지만 같은 사이트 ID로 기존 개발자 도구인 DevConsole에서 발급한 토큰은 Safari에서 정상적으로 재생되었고, 제가 그 사실을 확인해 주자 결론이 무너졌습니다. 공식 샘플 코드와 요청을 하나하나 비교해 보니, 라이선스 요청 본문의 인코딩 방식과 인증서를 전달하는 형식이 샘플과 달랐던 것이 진짜 원인이었습니다. AI의 추론이 아무리 그럴듯해도, 실제로 동작하는 사례 하나가 더 강한 근거였습니다. 비슷하게, 다른 팀에 버그로 보고하려던 현상이 알고 보니 오래된 CDN 캐시 때문이었던 적도 있습니다.

반대로 사람만 할 수 있는 일도 분명했습니다. 자동화된 브라우저에는 Widevine 모듈이 없어서 DRM 재생 테스트는 전부 제가 실제 브라우저로 해야 했고, 이 제약도 ADR로 남겼습니다. 인증이 필요한 콘솔 화면 캡처, 라이선스 토큰 입력, 다른 팀이 관리하는 DNS 설정 요청도 모두 제 몫이었습니다.

두 프로젝트가 만나는 지점

두 프로젝트는 서로를 검증하는 관계가 되었습니다. 튜토리얼 영상은 DoveRunner의 패키징, DRM, 포렌식 워터마킹으로 보호되어 Lab에서 재생되기 때문에, 영상 한 편을 공개할 때마다 제품 전체 흐름을 처음부터 끝까지 한 번씩 거치게 됩니다.

영상을 만들면서 Claude가 AWS와 DoveRunner 콘솔에서 실제 설정을 따라가다 보니, 문서와 실제 동작이 다른 부분도 계속 드러났습니다. 설치 가이드에서 빠진 의존성이나, 실제 서비스의 제한값과 다르게 적힌 설정값 같은 것들입니다. 영상 9편을 만드는 동안 이렇게 모은 문서 개선 항목이 54개였고, 제가 검토해 채택한 항목은 문서 수정으로 이어가고 있습니다.

또한 Lab을 만들면서 문서 사이트와의 역할도 다시 나눴습니다. Diátaxis 프레임워크를 기준으로 튜토리얼은 Lab이, 하우투와 레퍼런스는 문서가 맡도록 정리했고, 기존 문서의 Multi-DRM 퀵스타트는 Lab 코스로 옮겼습니다. 같은 내용을 두 곳에서 따로 관리하다가 서로 어긋나는 문제를 줄이기 위해서입니다.

AI와 일하며 정리한 역할 분담

한 달 동안의 작업을 돌아보면 역할은 대략 아래와 같이 나뉘었습니다.

구분	제가 한 일	Claude가 한 일
방향	무엇을 만들고 무엇을 뺄지 결정	계획과 대안 제안
내용	내레이션과 기술 내용 승인	문서 대조, 원고와 스토리보드 초안
구현	범위 조정, 결과물 검수	코드, 장면, 도구, 인프라의 대부분
검증	실제 브라우저와 기기 테스트, 렌더링 영상 시청	자동 검사, 원인 분석, 수정
기록	결정 확인	HANDOFF, WORKLOG, ADR 작성

마치며

처음 원페이저에는 1단계 개발에 엔지니어 1~2명이 6~8주 걸릴 것으로 적었습니다. 실제로는 제가 Claude Code와 함께 첫 커밋부터 공개까지 약 3주가 걸렸습니다. 다만 일부 단계는 출시 이후로 미뤘기 때문에 정확히 같은 범위를 비교한 숫자는 아닙니다.

이번 작업에서 AI 코딩 에이전트는 개발 속도를 크게 바꿨지만, 품질은 여전히 사람이 어디에 확인 지점을 두느냐에 달려 있었습니다. 내레이션 승인 게이트, 스냅샷 확인, 실제 브라우저 테스트처럼 사람이 반드시 보는 지점을 구조로 만들어 둔 곳에서는, AI가 틀리더라도 그 오류가 사용자에게 닿기 전에 잡혔습니다. 반대로 FairPlay 사례처럼 사람의 확인이 뒤늦게 들어간 곳에서는, AI의 그럴듯한 결론이 이미 ADR로 기록된 뒤에야 바로잡을 수 있었습니다.

Lab은 이제 막 공개했기 때문에, 개발자가 처음 보호된 콘텐츠를 재생하기까지 걸리는 시간이 실제로 얼마나 줄어드는지는 더 지켜보아야 할 것 같습니다. 다음 단계로는 모바일 레퍼런스 앱을 준비하고 있습니다.

이상으로 DoveRunner Lab과 튜토리얼 영상을 AI와 함께 만들며 겪은 과정에 대해서 알아보았습니다. DRM과 포렌식 워터마킹이 실제로 어떻게 동작하는지 직접 확인해 보고 싶으시다면 DoveRunner Lab을 방문해 보시기 바랍니다.