숏폼(Short-form) 비디오 도구들은 종종 단일 버튼처럼 보이지만, 실제 제품 경험은 작은 분산 시스템입니다. 유용한 파이프라인은 지저분한 입력(messy inputs)을 받아 스크립트로 변환하고, 미디어를 생성하며, 진행 상황을 명확하게 보고하고, 각 렌더링의 비용을 예측 가능하게 유지해야 합니다.

저는 이러한 문제를 해결하기 위해 BrainrotKit을 구축하고 있습니다. 목표는 워크플로우를 마법 버튼 뒤에 숨기는 것이 아닙니다. 목표는 각 단계가 충분히 이해할 수 있도록 만들어 크리에이터가 결과를 검토하고 다음 단계를 생성할 가치가 있는지 결정할 수 있게 하는 것입니다.

1. 브라우저가 충분히 좋을 때 브라우저에서 시작하기

PDF 파싱과 OCR(광학 문자 인식)이 항상 유료 서버를 필요로 하지는 않습니다. 브라우저는 많은 PDF에서 로컬로 텍스트를 추출할 수 있으며, OCR 라이브러리는 원본 파일을 백엔드로 전송하지 않고도 이미지 기반 메모를 처리할 수 있습니다. 이는 지연 시간(latency)을 줄이고, 저장 공간 요구 사항을 낮추며, 사용자에게 더 간단한 개인 정보 보호 스토리(privacy story)를 제공합니다.

중요한 경계는 품질입니다. 만약 브라우저가 콘텐츠를 자신 있게 추출할 수 없다면, UI가 그렇게 표시하고 더 명확한 파일을 요청해야 합니다. 좋지 않은 OCR 결과를 언어 모델에 조용히 전달하는 것은 단지 더 비싼 나쁜 결과만을 만들어낼 뿐입니다.

2. 미디어 생성과 계획을 분리하기

이미지 또는 비디오 모델이 호출되기 전에, 텍스트 모델은 간결하고 구조화된 계획(plan)을 생성해야 합니다. 유용한 중간 객체는 다음을 포함합니다:

• 한 문장짜리 후크(hook);
• 나레이션 스크립트;
• 각 비트(beat)에 대한 시각적 설명;
• 목표 지속 시간(target duration);
• 짧은 캡션과 제목.

이러한 분리는 재시도 비용을 절감합니다. 만약 이미지가 잘못되었다면, 전체 스크립트를 다시 작성하는 데 비용을 지불하기보다 이미지 프롬프트만 재생성하면 됩니다. 또한 모든 출력에 가시적인 입력(visible input)이 있기 때문에 시스템 디버깅이 더 쉬워집니다.

3. 스피너가 아닌 작업 상태 머신 사용하기

미디어 생성은 비동기적(asynchronous)입니다. 요청은 "대기열(queued)", "계획 수립(planning)", "이미지 생성 중(generating-image)", "음성 생성 중(generating-voice)", "비디오 생성 중(generating-video)", "준비 완료(ready)", 또는 "실패(failed)\

1. 텍스트 및 PDF를 위한 브라우저 측 추출(browser-side extraction);
2. 스크립트 기획을 위한 단일 텍스트 모델(one text model);
3. 단일 이미지 제공업체와 단일 비디오 제공업체(one image provider and one video provider);
4. 내구성 있는 프로젝트 및 크레딧 기록(durable project and credit records);
5. 명확한 로딩 상태 및 실패 메시지(clear loading states and failure messages);
6. 긴 생성 전에 짧은 내보내기(a short export before longer generations).

이것만으로도 사용자가 실제로 어느 부분에서 막히는지 파악하기에 충분합니다. 첫 번째 원칙은 개별 모델 호출의 성공 여부뿐만 아니라 전체 사용자 여정(user journey)을 측정하는 것입니다. 워크플로우가 이해하기 쉬울 때, 크리에이터들은 더 나은 결정을 내릴 수 있고 플랫폼은 눈에 보이지 않는 재시도(retries)에 예산을 낭비하지 않고 개선될 수 있습니다.