자동화를 포기하니 더 나은 모델이 왔다 — 1인 개발의 빌드 vs 바이 (2편)

1편에서 대시보드 개발을 멈추며 질문 하나가 남았다. 작업 큐와 워커를 중심으로 만든 제작 경로도 계속 필요한가? 이 글은 그 경로 대신 Claude Code와 스크립트로 영상을 만들게 된 기록이다. 전환하면서 비용 때문에 쓰기 어려웠던 대규모 언어 모델(LLM)을 활용하게 됐다. 직접 구축할 범위를 줄인 것이 모델을 선택하는 방식까지 바꿨다.

1. 문제 정의 — 파이프라인은 필요한가

초기 플랫폼은 API가 작업을 큐에 넣고 워커가 생성·조립을 수행하는 구조였다. 대시보드로 진행 상황을 확인하려 했지만 실제 연동까지 완성하지는 않았다. 설계에는 단계별 검수도 들어 있었다. 처음부터 사람이 전혀 개입하지 않는 제작이 구현돼 있었던 것은 아니다.

그 상태에서 서버 중심 경로를 계속 발전시킬 이유를 다시 따졌다. 작업을 더 자동으로 이어 붙이려면 호출 실패와 재시도, 사용량 한도, 비용을 관리해야 한다. 결과가 어긋났을 때 멈추거나 검수를 요청하는 처리도 필요하다. 기능을 만드는 시간뿐 아니라 이후 유지보수까지 내가 맡아야 했다.

API에 결제해 실제로 테스트하면서 생각이 점차 바뀌었다. 대시보드를 쓰지 않는다면 구독 도구 안에서 필요한 작업을 진행해도 되겠다는 판단이었다. 당시 내 제작 방식에 필요한 것은 여러 작업을 무인으로 처리하는 플랫폼보다, 결과를 확인하면서 다음 단계를 실행할 수 있는 도구였다.

2. 접근 — 서버 중심 자동화와 구독 도구 비교

비교한 것은 아래 두 구성이었다. 자동화 수준과 과금 방식이 반드시 묶이는 것은 아니지만, 이 프로젝트에서는 구독 도구를 활용하는 쪽으로 실행 방식도 함께 바뀌었다.

내게 가장 큰 차이는 LLM 선택이었다. API를 쓰던 때에는 비용이 부담돼 더 좋은 모델을 쓰기 어려웠다. 구독 도구를 이용하면 내 작업량을 요금제 안에서 처리할 수 있겠다고 보았다. 이는 내 사용 방식에 대한 판단이며, 구독제가 어떤 작업량에서도 더 저렴하다는 뜻은 아니다.

여기서 LLM과 영상 생성 모델의 비용을 구분해야 한다. 대본과 프롬프트를 Claude Code에서 작성해도 이미지·음성·영상 생성 API의 호출료까지 구독료에 포함되지는 않는다. 실제 제작 스크립트에도 이런 외부 호출이 남아 있다. 영상 제작 전체가 정액으로 바뀐 것으로 계산하면 비교부터 틀어진다.

또한 구독은 무제한 사용을 뜻하지 않는다. Claude Code에는 요금제별 사용 한도가 있고, Claude API 이용료는 구독과 별도다. 같은 도구라도 어떤 계정과 과금 방식으로 사용하는지 확인해야 한다.

3. 결정 — 반자동 + 구독제, 그리고 예상 못 한 보상

제작의 중심을 Claude Code와 커스텀 스킬로 옮겼다. 대본과 프롬프트를 작성하고, 생성·조립 스크립트를 실행하고, 결과를 확인하면서 다음 단계로 넘어간다. 반복 작업은 스크립트가 맡고 어떤 결과를 채택하거나 다시 만들지는 내가 판단한다.

이 전환으로 얻은 것은 비용 때문에 쓰기 어려웠던 더 좋은 LLM을 활용할 수 있게 됐다는 점이다. 호출 단가를 따지던 작업을 구독 요금제의 범위 안에서 진행하게 됐다. 자동화 범위를 줄이는 결정이 LLM을 사용하는 선택지를 넓혀 준 것이다.

다만 더 좋은 LLM을 썼다는 경험을 최종 영상 품질 향상이나 재생성 횟수 감소로 곧바로 해석할 수는 없다. 영상에는 대본·프롬프트뿐 아니라 생성 모델과 편집도 영향을 준다. 전후 품질과 재생성 횟수를 같은 기준으로 집계한 자료가 없으므로, 이 글에서 확인할 수 있는 성과는 작업 방식의 전환과 LLM 활용 범위의 변화다.

도표 크게 보기

구독 도구, 직접 만든 스크립트, 사람의 검수가 함께 남았다. 전환 뒤에도 각 부분의 비용과 관리 책임을 따로 봐야 한다.

4. 결과 — 무엇을 사고 무엇을 계속 만들 것인가

이 결정은 빌드 vs 바이, 즉 직접 구축할지 기성 도구를 이용할지의 문제였다. 내 선택은 기성 도구를 중심에 두되 제작에 필요한 코드는 계속 쓰는 조합이었다. 커스텀 스킬과 생성·조립 스크립트를 유지했고, 작업 정보를 저장하는 API와 데이터베이스도 활용했다. 앞서 만든 코드를 모두 없앤 것은 아니다.

비용 비교 역시 구독료와 API 청구액만 맞대서는 부족하다. 외부 생성 API 사용료와 실행 환경 비용을 더하고, 유지보수 시간과 결과를 확인하는 시간도 함께 봐야 한다. 이 글에는 전환 전후의 전체 지출과 작업 시간을 집계한 자료가 없다. 따라서 절감액이나 손익분기점을 수치로 제시할 수는 없다.

제작량이 커지면 사람의 확인 시간이 병목이 될 수 있다. 그러나 그 사실만으로 직접 만든 플랫폼의 단위 비용이 더 낮아지는 것은 아니다. 검수에 걸리는 시간, 실패 후 복구 비용, 구독 도구의 한도와 필요한 품질을 함께 비교해야 한다. 내가 택한 반자동 방식도 이런 조건이 달라지면 다시 평가할 대상이다.

다시 비교한다면 먼저 영상 한 편을 만드는 데 드는 외부 호출료와 사람의 개입 시간을 기록할 것이다. 이어 같은 품질 기준에서 서버 중심 경로가 그 시간을 얼마나 줄이는지 확인할 수 있다. 단순히 제작 편수가 늘었다는 이유보다, 어느 단계에서 비용이나 대기가 쌓이는지 알아야 자동화할 범위도 정할 수 있다.

5. 학습

자동화는 관리할 범위까지 포함해 선택한다. 큐와 워커가 작업을 이어 주더라도 실패 처리와 검수 설계는 남는다. 나는 구독 도구와 스크립트로 필요한 단계를 실행하는 쪽을 택했다.

과금 방식은 모델 선택에 영향을 준다. 내 경우 구독제가 더 좋은 LLM을 활용하는 계기가 됐다. 다만 제공 모델과 사용 한도, 별도 API 비용을 함께 확인해야 같은 선택을 다른 프로젝트에서도 검토할 수 있다.

직접 만들 줄 알아도 전부 만들 필요는 없다. 이미 만든 코드의 양보다 앞으로 계속 관리할 이유가 기준이다. 내 작업에서는 구독 도구를 중심에 놓고 커스텀 스킬과 스크립트로 필요한 부분을 이어 썼다.

그렇다면 각 단계에서 도구와 사람은 무엇을 맡는가? 3편에서는 Claude Code, 스크립트, 편집 도구를 연결한 반자동 제작 과정을 다룬다.