처음 팟캐스트를 시작했을 때, 저는 오직 녹음에만 전념했습니다. 진짜 작업은 질문을 준비하고, 녹음을 하고, '음...'이나 '아...' 같은 부분을 편집하는 것이라고 생각했죠. 하지만 그건 틀렸습니다. 가장 지치는 부분은 마이크가 꺼진 아주 오랜 시간이 지난 후에 발생했어요.
그것은 행정적인 무덤이었습니다: 쇼 노트 작성하기, 인용구 뽑기, 타임스탬프 추측하기, 그리고 믿을 수 없을 만큼 지루하게 들릴 제목을 쓰려고 빈 화면을 응시하는 것이었죠. 녹음 시간 1시간당 후반 작업 서류 작업에 2시간을 쓰고 있었습니다. 이건 제 창의적인 에너지를 고갈시키고 다음 에피소드를 공개하는 것을 적극적으로 두려워하게 만들었습니다.
그래서 저는 무언가를 구축하기로 결정했습니다.
팟캐스트 후반 작업의 숨겨진 비용
팟캐스트 후반 작업의 문제는 단순히 시간이 걸린다는 것이 아닙니다. 심각한 컨텍스트 스위칭(context switching) 문제입니다. 진행자로서 당신은 창의적이고 대화적인 사고방식에 있습니다. 뇌가 즉시 세심하고 SEO를 의식하는 편집자의 역할로 전환하도록 강요받는 것은 충격적입니다.
이러한 마찰을 무시하면 비용이 누적됩니다. 첫째, 크리에이터 번아웃(creator burnout)의 위험에 처합니다. 둘째, '지루한 것들'이 할 일 목록의 맨 아래로 계속 밀려나기 때문에 발행 일정이 불규칙해집니다.
하지만 아마도 가장 큰 숨겨진 비용은 발견 가능성(discoverability)일 것입니다. 팟캐스트 플랫폼은 본질적으로 검색 엔진입니다. 제목과 설명은 SEO를 위한 주요 벡터입니다. 피곤해서 약한 제목과 한 문장짜리 설명을 대충 만들면, 당신의 에피소드는 사실상 보이지 않게 됩니다. 오디오는 완벽할지 몰라도, 메타데이터(metadata)가 뒷전이라면 아무도 재생 버튼을 누르지 않을 것입니다.
무거운 작업을 엣지로 옮기기
AI가 요약 및 형식 지정의 무거운 작업을 처리할 수 있다는 것은 알았지만, 아키텍처에 대해 신중하게 생각해야 했습니다. 처음에는 표준 서버리스 함수를 구성하여 스크립트를 처리했습니다. 작동은 했지만, 콜드 스타트(cold starts) 현상이 눈에 띄었고, 대용량 텍스트 페이로드를 중앙 서버로 주고받는 과정에서 지연 시간(latency)이 추가되었습니다. 저는 이 도구가 즉각적으로 느껴지기를 원했습니다.
이것이 저를 엣지 컴퓨팅(edge computing)으로 이끌었습니다. Cloudflare Workers를 사용하여 PodCrisp를 구축했으며, 그들의 AI 추론(inference) 기능을 활용하여 모델을 사용자에게 지리적으로 가까운 엣지에서 실행하도록 했습니다.
쇼 노트(show notes)를 생성하는 워크플로우는 간단하지만 정교한 프롬프트 엔지니어링(prompt engineering)에 크게 의존합니다. 단순히 AI에게 '이것을 요약해라'라고 요청하는 대신, 저는 특정 구조적 출력으로 강제합니다. Cloudflare Worker가 스크립트를 노트로 변환하는 파이프라인의 간소화된 모습은 다음과 같습니다:
// Show notes generation pipeline (Cloudflare Workers + AI)
export default {
async fetch(request, env) {
...
이 설정에서 워커는 JSON 페이로드를 통해 원본 스크립트를 받습니다. 우리는 이를 @cf/meta/llama-3-8b-instruct 모델에 전달합니다. 마법은 시스템 프롬프트(system prompt)에 있습니다. '요약', '핵심 요점', '타임스탬프', '자료'와 같은 마크다운 구조를 명시적으로 정의함으로써, 모델이 단순히 텍스트의 벽을 출력하는 것을 방지합니다. 또한 응답이 간결하고 집중되도록 max_tokens를 800으로 제한했습니다.
엣지 AI의 트레이드오프(trade-off)는 전용 GPU 서버에서 실행할 수 있는 거대한 파라미터 모델과 비교했을 때, 종종 고도로 최적화된 더 작은 모델을 사용한다는 것입니다. 이는 복잡한 지침을 이해하기 위해 단순히 모델의 크기에만 의존할 수 없다는 것을 의미합니다. 엄격한 프롬프트 엔지니어링으로 보상해야 합니다. 위의 코드에 있는 시스템 프롬프트는 단순한 제안이 아니라, 모델이 예측 가능하게 작동하도록 강제하는 엄격한 일련의 제약 조건입니다.
이 추론을 엣지에서 실행한다는 것은 중앙 집중식 GPU 클러스터로 돌아가는 왕복 지연 시간(round-trip latency)을 피할 수 있게 하여 사용자 경험을 훨씬 더 부드럽게 만듭니다.
실질적인 결과와 워크플로우 확장
엣지(edge)로 전환한 것은 도구의 체감 성능에 상당한 개선을 가져왔습니다. 놀라울 정도로 잘 작동했던 부분은 AI가 타임스탬프를 추정하는 능력입니다. 텍스트에 명시적인 오디오 마커가 없더라도, 모델은 대화 흐름을 기반으로 주제가 전환되는 지점을 유추하고 대략적인 타임스탬프 목록을 생성할 수 있습니다. 완벽하지는 않지만, 편집자들에게 상당한 출발점(head start)을 제공합니다.
단순히 쇼 노트(show notes)를 넘어, 저는 전체 사전 및 사후 제작 워크플로우가 도움이 필요하다는 것을 깨달았습니다. 그래서 계획 단계용 에피소드 스크립트 개요 생성기(episode script outline generator)와 에피소드 설명 작성기(episode description writer)를 포함하도록 도구 세트를 확장했습니다. 또한, 일반적인 웹 SEO가 오디오 검색(audio discovery)에 항상 완벽하게 적용되지는 않기 때문에, 팟캐스트 에피소드 페이지에 맞춰진 SEO 키워드 제안 기능도 추가했습니다.
지금 당장 한 가지 바꿀 수 있다면, 니치(niche)별 프롬프트 템플릿을 추가하는 것입니다. 실제 범죄 팟캐스트는 B2B SaaS 인터뷰와는 매우 다른 제목과 설명의 톤이 필요합니다. 현재 시스템 프롬프트에 '니치' 변수를 전달하여 어휘와 후킹 스타일(hook style)을 동적으로 조정하는 실험을 진행하고 있습니다.
완벽한 제목 만들기
쇼 노트가 초기 초점이었지만, 실제 에피소드 제목을 만드는 것 또한 또 다른 거대한 병목 현상(bottleneck)입니다. 좋은 제목은 호기심 격차(curiosity gap), 명확한 이점, 그리고 적절한 톤이 필요하며—모두 클릭베이트 영역에 넘어가지 않아야 합니다.
이를 돕기 위해, 저는 제목 생성 로직을 독립적인 무료 도구로 추출했습니다. 다음 에피소드의 여러 스타일 옵션을 얻으려면 PodCrisp Podcast Title Generator를 사용해 볼 수 있습니다. 완전히 무료이며, 로그인할 필요가 없고, 브라우저에서 바로 실행됩니다.
솔직히 말씀드리자면: 저는 PodCrisp의 개발자입니다. 제가 직접 필요해서 만들었습니다.