Claude Code로 1시간 만에 숏츠 생성기 만들기: 라이브 빌드에서 드러난 AI 네이티브 개발 루프

이 영상이 흥미로운 이유는 “Claude Code로 앱 하나를 빨리 만들었다” 는 데 있지 않습니다. 오히려 이미 가지고 있는 롱폼 영상과 자막을 바탕으로, 숏츠 후보를 고르고 자르고 렌더링하고 다시 고치는 과정을 Claude Code와 어떻게 협업할 수 있는지 거의 날것 그대로 보여 준다는 점이 핵심입니다. 발표자는 처음부터 “숏폼을 못 만드는 이유는 시간이 없어서” 라는 운영 병목을 제시하고, 1시간 안에 로컬 기반 숏츠 생성기를 같이 만들어 보자고 선언합니다. 그래서 이 영상은 완성품 자랑보다, 문제 정의와 실행 루프를 어떻게 에이전트에게 넘기는지 관찰하는 데 더 큰 가치가 있습니다 (근거: t=0, t=17, t=56, t=3126).

Sources

• https://www.youtube.com/watch?v=EUi09O_b7so

1) 출발점은 “롱폼+자막” 을 “숏츠 후보+렌더” 파이프라인으로 바꾸는 것이다

발표자가 처음부터 요구한 것은 꽤 구체적입니다. 이미 보유한 롱폼 영상과 그 자막 파일을 넣으면, 자막을 읽어 숏폼으로 잘릴 만한 구간을 찾고, 실제 숏츠 형태로 제작해 주는 로컬 서비스를 만들고 싶다고 설명합니다. 즉 이 영상의 목표는 “AI가 편집을 대신해 준다” 는 추상적 아이디어가 아니라, 입력이 롱폼 영상 + SRT, 출력이 업로드 가능한 숏츠 후보 인 변환 파이프라인을 만드는 것입니다 (근거: t=56, t=125, t=133, t=138).

중요한 점은 이 파이프라인이 단일 컷 하나를 뽑는 수준에서 멈추지 않는다는 점입니다. 발표자는 드래그 앤 드롭이나 로컬 경로 입력을 지원하고, 실제로 mp4까지 출력하고, 하나가 아니라 여러 개의 후보를 만들고 싶다고 요구합니다. 초반 계획에서 이미 SRT 파싱, 영상 프로세싱, FastAPI 기반 인터페이스, API 키 입력 방식 같은 운영 요소가 함께 등장하는 이유도 여기 있습니다. 처음부터 “후보 추천 -> 렌더 -> 사람이 확인” 의 흐름으로 생각하고 있기 때문입니다 (근거: t=250, t=263, t=266, t=272, t=516, t=532).

flowchart TD
    A["Long-form video"] --> B["Transcript / SRT"]
    B --> C["Candidate short segments"]
    C --> D["Why this segment?"]
    D --> E["Cut and render"]
    E --> F["Title / subtitle layout"]
    F --> G["Upload-ready shorts"]

    classDef input fill:#c5dcef,stroke:#6b9ac4,stroke-width:1px,color:#333
    classDef process fill:#c0ecd3,stroke:#67a97c,stroke-width:1px,color:#333
    classDef output fill:#fde8c0,stroke:#d9a441,stroke-width:1px,color:#333
    classDef result fill:#e0c8ef,stroke:#9b7cc2,stroke-width:1px,color:#333

    class A,B input
    class C,D,E,F process
    class G result

2) 핵심은 한 번의 프롬프트가 아니라 리서치 -> 요구사항 -> 스택 선택 대화다

라이브 초반에 발표자가 먼저 하는 일은 코드를 치는 것이 아니라, “유튜브 숏폼은 어떻게 잘 만들어야 하는가” 를 Claude에게 리서치시키고, 그 결과를 바탕으로 첫 프롬프트를 다시 생성하게 하는 일입니다. 여기서 중요한 것은 좋은 숏츠의 공통 요소를 먼저 조사한 뒤, 그 요건을 서비스 요구사항으로 번역한다는 점입니다. 발표자가 “결국 이거 다 프롬프트 만들어내는 거” 라고 말하는 맥락도 단순한 문장 꾸미기가 아니라, 문제 정의를 더 좋은 입력으로 바꾸는 작업에 가깝습니다 (근거: t=85, t=101, t=112, t=120, t=143).

그 다음 단계에서 발표자는 Claude Code를 일회성 코드 생성기가 아니라 PM이나 개발자와 티키타카하듯 다루겠다고 분명히 말합니다. 플랜 모드에서 질문을 주고받으며 제품 요구사항을 세우고, 로컬 경로 입력, 드래그 앤 드롭, Python 환경 확인, 다중 결과 출력 같은 제약을 차례로 고정합니다. 이 과정은 “먼저 세부 스펙을 대화로 잠그고, 그다음 구현에 들어간다” 는 매우 실무적인 흐름으로 보입니다 (근거: t=196, t=234, t=242, t=250, t=283, t=296).

이 대화형 설계가 실질적으로 유용한 이유는 필요한 기술 스택이 자연스럽게 드러나기 때문입니다. 발표자는 영상 편집 문제를 풀기 위해 Python, ffmpeg, Node.js, 웹 UI 같은 조합이 필요하다고 설명하고, Claude는 실제 계획에서 SRT 분석, 영상 프로세싱, FastAPI 서버와 UI 지원까지 포함한 구조를 제안합니다. 즉 설계 대화는 곧바로 실행 가능한 기술 구조로 이어집니다 (근거: t=311, t=319, t=325, t=351, t=371, t=521).

flowchart TD
    A["Research winning shorts"] --> B["Generate initial brief"]
    B --> C["Plan mode Q&A"]
    C --> D["Lock product requirements"]
    D --> E["Choose toolchain"]
    E --> F["Generate working service"]

    classDef input fill:#c5dcef,stroke:#6b9ac4,stroke-width:1px,color:#333
    classDef process fill:#c0ecd3,stroke:#67a97c,stroke-width:1px,color:#333
    classDef output fill:#fde8c0,stroke:#d9a441,stroke-width:1px,color:#333

    class A,B input
    class C,D,E process
    class F output

3) Claude Code가 실제로 맡은 일은 브라우저 테스트와 디버깅 반복이다

영상 중반부터 흥미로운 지점은 Claude Code가 단지 코드만 쓰는 것이 아니라, 이미 돌아가는 UI를 띄우고 실제로 테스트 대상처럼 다뤄진다는 점입니다. 발표자는 Claude Code가 브라우저를 직접 띄울 수 있고, 스크린샷을 찍고, 화면을 보고, 안 되는 부분을 스스로 고칠 수 있다고 설명합니다. 이것이 특별한 이유는 “테스트 스크립트를 내가 다 짜지 않아도, 에이전트가 브라우저를 만지면서 확인한다” 는 개발 감각을 보여 주기 때문입니다 (근거: t=770, t=779, t=785, t=793, t=804).

발표자는 이 장면을 설명하면서 에이전틱 코딩의 핵심은 “알아서 혼자 잘 돌아가게끔 잘 내버려 두는 것” 이라고 말합니다. 실제로 그는 업로드 대신 로컬 경로 입력을 지원하도록 방향을 바꾸고, 브라우저에서 경로 입력 탭을 추가하게 하고, 이 컴퓨터 안에서 돌고 있는 앱이 로컬 파일을 직접 읽도록 수정하게 합니다. 스스로 “결과물이 중요하다” 고 반복하는 이유도 바로 여기 있습니다. 내부 구현을 다 읽는 것보다, 에이전트가 테스트하고 패치하고 다시 실행해 결과를 개선하는 루프를 더 중요하게 보기 때문입니다 (근거: t=841, t=849, t=878, t=884, t=902, t=918, t=933).

디버깅 장면도 같은 철학을 보여 줍니다. API 키 문제나 빌링, 모델 설정 오류가 생기면 발표자는 키를 다시 만들고, 다른 모델 설정으로 바꿔 보고, 막혔을 때는 Claude에게 왜 그런 일이 발생했는지 다시 묻습니다. 여기에 더해 기다리는 동안 다른 터미널을 열어 별도 작업을 맡기고, UI 쪽 이슈와 생성 파이프라인을 병렬로 돌립니다. 30분 지점에 이미 목표의 60~70% 정도는 왔다고 판단하는 대목도, 이 반복 루프가 꽤 빠르게 진도를 당긴다는 인상을 줍니다 (근거: t=1171, t=1186, t=1213, t=1240, t=1262, t=1932, t=1992, t=2254, t=2318).

flowchart TD
    A["Working UI"] --> B["Browser test"]
    B --> C{"What failed?"}
    C -->|"API / billing"| D["Reset key or plan"]
    C -->|"Model config"| E["Change model setting"]
    C -->|"UI / local file"| F["Patch and retest"]
    D --> G["Retry generation"]
    E --> G
    F --> G
    G --> H["Check screenshot and outputs"]
    H --> I["Keep iterating"]

    classDef input fill:#c5dcef,stroke:#6b9ac4,stroke-width:1px,color:#333
    classDef decision fill:#fde8c0,stroke:#d9a441,stroke-width:1px,color:#333
    classDef process fill:#c0ecd3,stroke:#67a97c,stroke-width:1px,color:#333
    classDef result fill:#e0c8ef,stroke:#9b7cc2,stroke-width:1px,color:#333

    class A,B,H input
    class C decision
    class D,E,F,G process
    class I result

4) 좋은 숏츠 조건을 “어떤 컷이 좋은가” 가 아니라 “어떻게 렌더해야 하는가” 로 번역한다

첫 번째 후보 결과가 나오자 발표자는 곧바로 한 가지를 더 요구합니다. 단순히 구간 5개를 추천하는 것에서 끝내지 말고, 왜 이 구간이 선택되었는지를 UI에서 함께 보여 달라는 것입니다. 이 요구는 중요합니다. 좋은 숏츠는 “블랙박스 추천” 으로 끝나지 않고, 어떤 스토리 구조와 후크 요소 때문에 골랐는지를 사람이 검토할 수 있어야 하기 때문입니다. 그래서 그는 잘 되는 숏츠의 구성 요소를 다시 Requirement처럼 정리해 달라고 요청합니다 (근거: t=1282, t=1312, t=1321, t=1326, t=1353, t=1360).

실제 렌더 품질 튜닝은 더 구체적입니다. 첫 번째 결과를 확인한 뒤 그는 첫 3초 훅에서 말이 잘리면 안 된다고 강조하고, 자막이 이미 영상 안에 있다고 가정할 수 있다면 별도 오버레이를 굳이 덧씌우지 말아야 한다고 말합니다. 또 가로 원본을 세로로 만들 때 가운데만 무식하게 크롭하지 말고, 4:3 정도로 중심부를 살리고 나머지는 여백으로 처리해 영상이 덜 잘리게 하자고 제안합니다. 이 대목은 숏츠 생성기의 핵심이 단순 컷팅이 아니라, 의미 단위 보존과 레이아웃 보존이라는 점을 잘 보여 줍니다 (근거: t=1645, t=1659, t=1673, t=1684, t=1698, t=1705, t=1725, t=1740).

후반부 수정 요구는 거의 디자인 시스템 수준으로 구체화됩니다. 발표자는 각 숏폼 위에 큰 훅 타이틀을 넣고, 아래에는 서브타이틀을 두고, 타이틀은 “왜 봐야 하는지” 와 “앞으로 어떻게 전개되는지” 를 설명하는 호기심 유발 문장이어야 한다고 말합니다. 그 뒤에는 타이틀 위치를 더 아래로 옮기고, 영상은 조금 더 줌인하고, 서브타이틀은 영상 밑으로 내리고, 타이틀에는 배경색을 주고, 배경색은 전체 박스가 아니라 텍스트만 감싸도록 다시 수정합니다. 다만 영상 마지막 확인 장면에서 그는 여전히 타이틀이 중간에 사라지는 문제와 시작/끝 구간이 정말 의미 있게 잘렸는지 추가 검토가 필요하다고 말합니다. 즉 영상이 보여 주는 것은 “완벽한 자동화 완성” 이 아니라, 품질 기준을 AI에게 계속 번역해 주는 실전 튜닝 과정입니다 (근거: t=2133, t=2147, t=2161, t=2421, t=2431, t=2440, t=2451, t=2522, t=2554, t=3080, t=3097).

flowchart TD
    A["Candidate clip"] --> B["No cut words in first 3 seconds"]
    B --> C["Explain why to watch"]
    C --> D["Top hook title"]
    D --> E["Bottom subtitle"]
    E --> F["Keep more of the horizontal frame"]
    F --> G["Use padding instead of hard crop"]
    G --> H["Review rendered output"]

    classDef input fill:#c5dcef,stroke:#6b9ac4,stroke-width:1px,color:#333
    classDef process fill:#c0ecd3,stroke:#67a97c,stroke-width:1px,color:#333
    classDef output fill:#fde8c0,stroke:#d9a441,stroke-width:1px,color:#333

    class A input
    class B,C,D,E,F,G process
    class H output

5) 영상의 진짜 메시지는 결과 중심의 AI 네이티브 작업 방식이다

이 영상에서 반복해서 나오는 표현은 “결과가 중요하다” 입니다. 발표자는 추천 이유를 더 잘 보여 달라고 요구하면서도, 중간 로그를 예전처럼 꼼꼼히 읽지 않고 결과부터 본다고 말합니다. 또 엔지니어가 과정과 설계 디테일에 과도하게 빠지기 쉽지만, 이제는 코드가 매우 빨리 생성되는 시대이므로 본질은 A에서 B로 더 빨리 가게 하는 결과물이라고 비유합니다. 이것은 단순한 생산성 자랑이 아니라, 자동화 도구를 보는 판단 기준 자체가 바뀌었다는 선언에 가깝습니다 (근거: t=1382, t=1389, t=1411, t=1425, t=1440, t=1457).

동시에 그는 프롬프트를 잘 쓰는 능력을 “내가 원하는 것을 효율적으로 설명하는 능력” 으로 재정의하고, AI 네이티브 개발자의 핵심 역량 중 하나를 얼마나 빨리 멀티태스킹하고 병렬로 일을 굴릴 수 있는가라고 설명합니다. 후반부 마무리에서는 이 작업 방식을 한 문장으로 요약합니다. 프롬프트를 생성하고, 컨텍스트를 만들고, 실행시키고, 확인하고, 병렬로 작업하는 것이 전부라는 것입니다. 결국 이 영상이 설득하는 것은 특정 도구의 마법이 아니라, AI와 함께 일할 때 필요한 운영 루프의 형태입니다 (근거: t=1757, t=1765, t=1771, t=1922, t=1935, t=2838, t=2865, t=3126, t=3131).

flowchart TD
    A["Generate prompt"] --> B["Build context"]
    B --> C["Execute with agent"]
    C --> D["Verify result"]
    D --> E["Parallelize next work"]
    E --> F["Refine requirements"]
    F --> C

    classDef input fill:#c5dcef,stroke:#6b9ac4,stroke-width:1px,color:#333
    classDef process fill:#c0ecd3,stroke:#67a97c,stroke-width:1px,color:#333
    classDef result fill:#fde8c0,stroke:#d9a441,stroke-width:1px,color:#333

    class A,B input
    class C,D,E process
    class F result

실전 적용 포인트

• 롱폼 영상을 숏폼으로 바꾸는 자동화는 “모델 하나 연결” 보다 입력 형식, 후보 수, 렌더 출력, 검토 방식 을 먼저 고정할 때 훨씬 빨리 진도가 납니다 (근거: t=125, t=250, t=266).
• 에이전트에게 처음부터 완벽한 요구사항을 주려고 하기보다, 리서치 결과를 받아 초기 프롬프트를 다시 생성하고 플랜 모드에서 요구사항을 잠그는 편이 현실적입니다 (근거: t=85, t=120, t=234, t=242).
• 브라우저를 직접 띄워 테스트하고, 스크린샷을 보고, 로컬 경로 처리나 UI 버그를 고치게 하는 흐름은 AI 코딩 도구의 체감 가치를 크게 끌어올립니다 (근거: t=779, t=793, t=902, t=933).
• 숏츠 품질에서 가장 중요한 것은 화려한 자막 효과보다 첫 3초 훅, 말이 잘리지 않는 구간 경계, 세로 포맷으로 바꿀 때의 시야 보존 같은 기본 규칙입니다 (근거: t=1673, t=1684, t=1705, t=1725).
• 이 영상의 가장 큰 교훈은 더 긴 프롬프트가 아니라, 프롬프트 생성 -> 컨텍스트 구축 -> 실행 -> 검증 -> 병렬 작업이라는 운영 루프를 몸에 익히는 데 있습니다 (근거: t=1762, t=1935, t=2838, t=3126).

핵심 요약

• 이 영상의 목표는 단순한 편집 보조가 아니라 롱폼 영상 + 자막 -> 숏츠 후보 추천 -> 렌더링 까지를 연결하는 로컬 생성기를 빠르게 조립하는 것입니다 (근거: t=56, t=138, t=521).
• 발표자는 Claude Code를 한 번의 프롬프트에 답하는 도구보다, 요구사항을 같이 정리하고 계획을 짜고 구현을 밀어붙이는 협업 파트너처럼 사용합니다 (근거: t=196, t=283, t=299).
• 영상에서 드러난 실전 가치는 브라우저 테스트, 로컬 파일 처리, API/모델 디버깅을 사람 대신 상당 부분 떠맡기는 에이전틱 루프에 있습니다 (근거: t=779, t=1213, t=2254).
• 숏츠 생성 품질은 컷 추천보다도 훅, 자막 위치, 크롭 방식, 타이틀 스타일 같은 출력 제약을 얼마나 구체적으로 번역하느냐에 더 크게 좌우됩니다 (근거: t=1321, t=1673, t=2421).
• 최종 메시지는 도구 자체보다 작업 방식에 있습니다. 프롬프트, 컨텍스트, 실행, 검증, 병렬화의 루프를 굴릴 수 있으면 개인 제작자의 자동화 속도는 크게 올라갑니다 (근거: t=1757, t=1932, t=3128).

결론

이 영상은 “Claude Code로 1시간 만에 다 끝냈다” 는 성공담보다, 30분쯤 지나자 이미 원하는 결과의 60~70% 정도는 나왔고 남은 시간은 출력 품질과 버그를 다듬는 데 썼다는 현실적인 개발 기록으로 보는 편이 더 정확합니다. 마지막 확인에서도 타이틀이 중간에 사라지는 문제나 시작/끝 구간의 의미 보존 같은 숙제가 남아 있었기 때문입니다 (근거: t=1992, t=1997, t=3080, t=3097).

그래서 이 영상을 보고 바로 가져갈 만한 교훈은 “더 좋은 프롬프트를 찾자” 보다, 내가 원하는 결과를 더 잘 설명하고, 필요한 컨텍스트를 더 빨리 만들고, 실행과 검증을 병렬로 굴리는 루프를 익히자는 데 있습니다. 숏츠 생성기라는 결과물 자체도 흥미롭지만, 더 큰 가치는 그 결과를 만들어 내는 AI 네이티브 작업 방식이 어떻게 굴러가는지 보여 준다는 점에 있습니다 (근거: t=1762, t=1773, t=2838, t=3126).