# 프레임 예산

> 비용은 거의 전부 프레임에 있고, 예산은 세 배 느는데 길이는 예순 배 늡니다.

- 수치: 100장 상한
- 상태: wip
- 사람이 보는 화면: https://aitryed.com/ko/built/watch/budget/
- 반대 언어: https://aitryed.com/en/built/watch/budget/index.md
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt

---

**비용이 거의 전부 «화면 캡처»에 있습니다. 그런데 예산은 세 배 느는데 영상 길이는 예순 배 늡니다.**

## 비용 구조가 아주 단순합니다

| 무엇 | 비용 |
|---|---|
| **대본**(말을 글로 옮긴 것) | 10분짜리도 **몇천 단위** — 사실상 공짜 |
| **화면 캡처** | **여기가 전부** |

숫자로 보면 이렇습니다. 캡처를 80장 뽑으면 **5~8만 단위**가 나갑니다. 대본의 **열 배 이상**입니다.

그리고 **해상도를 두 배로 올리면 장당 비용이 대략 네 배**가 됩니다.

## 그래서 상한을 걸었습니다

**총 100장, 초당 2장까지.** 그 안에서 영상 길이에 따라 나눠 씁니다.

## 여기가 문제입니다 — 「예산은 세 배, 길이는 예순 배」

상한이 왜 어려운 문제인지 여기서 나옵니다.

| | 1분 영상 | 60분 영상 |
|---|---|---|
| 길이 | 1배 | **60배** |
| 쓸 수 있는 캡처 | 조금 | **100장 (상한)** |

**길이는 예순 배가 되는데 예산은 안 늡니다.** 그러면 긴 영상일수록 **점점 성기게** 봅니다. 60분을 100장으로 보면 **36초에 한 장**입니다.

36초에 한 장이면 **대부분을 못 봅니다.**

## 「대본만 있으면 되지 않나」 — 저도 처음에 그랬습니다

대본은 싸고 캡처는 비쌉니다. 그러면 대본만 쓰면 되지 않나 싶습니다.

**안 됩니다.** 이유가 있습니다.

발표자가 화면을 가리키며 <strong>「여기 이 값을 보시면」</strong>이라고 말합니다. 대본에는 **그 문장만** 남습니다. **「여기」가 어디인지, 「이 값」이 뭔지는 안 남습니다.**

그리고 게임 영상은 더 심합니다. **말은 거의 안 하고 화면만 움직입니다.** 대본이 텅 비어 있습니다.

> **대본은 「말한 것」만 담고, 화면은 「보여 준 것」을 담습니다. 만들려면 뒤쪽이 필요합니다.**

## 그래서 긴 영상은 「잘라서」 봅니다

이게 이 도구의 답입니다.

60분을 성기게 훑는 것보다, **필요한 구간을 촘촘히 보는 게 거의 항상 낫습니다.**

구간을 지정하면 **그 안에서 예산을 다 씁니다.**

| 방식 | 결과 |
|---|---|
| 60분 전체를 100장으로 | **36초에 한 장** — 거의 못 봄 |
| **2분 15초~2분 45초만 지정** | **60장이 그 30초에**(초당 2장 — 이게 상한) — 거의 모든 동작이 잡힘 |

사진 수는 오히려 적은데 **어디에 쓰느냐로 결과가 완전히 달라집니다.**

그리고 대개 **제가 보고 싶은 건 전체가 아니라 한 장면**입니다. 「저 연출 어떻게 한 거지」 같은 것이요.

## 같은 영상을 두 번 안 봅니다

같은 대화 안에서 **후속 질문이 오면 다시 안 돌립니다.**

캡처와 대본이 **이미 눈앞에 있는데** 또 뽑는 건 **같은 비용을 두 번 내는 것**입니다.

이게 안 되어 있으면 **「아까 그 장면 다시 봐 줘」 한 마디에 전체 비용이 다시** 나갑니다.

## 해상도는 안 올립니다

기본이 낮은 해상도입니다. **두 배로 올리면 장당 비용이 네 배**가 되어, **80장이 20~30만 단위**가 됩니다.

그리고 대개 **해상도를 올려서 얻는 것보다 장수를 늘려서 얻는 게 큽니다.** 흐릿해도 **동작의 순서는 보이는데**, 장수가 적으면 **동작 자체를 못 봅니다.**

> **[도판]** 왼쪽은 예산, 오른쪽은 그 예산으로 실제 몇 초에 한 장을 보게 되는지. 왼쪽이 세 배 느는 동안 오른쪽은 17분의 1이 된다.
>
> 영상 길이별 프레임 예산과 실효 프레임률. 예산은 30초 30장에서 30분 100장으로 세 배 남짓 늘지만 길이는 60배가 늘어, 실효 프레임률이 초당 1장에서 0.06장으로 무너진다.

## 여기부터는 자세한 기록입니다

이 도구의 비용 구조는 단순하다. 대본은 10분짜리라도 몇천 토큰이면 끝난다. **프레임이 전부다** — 512px 폭으로 80장이면 5~8만 토큰이고, 해상도를 1024로 올리면 장당 비용이 대략 네 배가 된다.

그래서 상한을 걸었다. **총 100장, 초당 2장.** 그 안에서 길이에 따라 예산을 배분한다.

여기서 문제가 보인다. **예산은 30장에서 100장으로 세 배 남짓 느는데, 길이는 60배가 는다.** 그래서 30분짜리를 통째로 넘기면 **18초에 한 장**을 보는 셈이 된다. 그 사이에 일어난 건 전부 대본으로만 아는 것이다.

## 대본이 있어도 프레임이 필요하다

"대본만 있으면 되지 않나"는 처음에 나도 했던 생각이다. 대본은 싸고 프레임은 비싸니까.

안 된다. **말로 안 하고 지나가는 게 너무 많다.** 화면 배치, 어떤 버튼이 어디 있는지, 그래프가 어느 방향으로 꺾이는지, 데모에서 실제로 뭐가 움직이는지 — 발표자는 "여기 보시면"이라고만 하고 넘어간다. 대본에는 "여기"라고만 남는다.

그리고 만들려고 보는 사람이 필요한 건 대개 **그 "여기"** 쪽이다. 그래서 비싼 걸 알면서도 프레임을 산다.

## 그래서 긴 영상은 잘라서 본다

긴 영상을 성기게 훑는 것보다 **필요한 구간을 촘촘히 보는 게 거의 항상 낫다.** 구간을 지정하면 그 안에서 예산을 다 쓴다 — 2:15부터 2:45까지 지정하면 60장이 그 30초에 들어간다. 초당 2장이 코드에 박힌 상한이라(`--fps` 로 더 달라고 해도 2로 깎인다) 30초 구간은 60장이 끝이다.

같은 60장인데 커버리지가 60배 차이 난다. 30분 전체에 뿌리면 30초에 한 장이고, 30초 구간에 몰면 초당 2장이다.

그래서 긴 영상을 받으면 **먼저 어디를 볼지 묻는다.** 구간을 안 정하고 태우는 토큰이 제일 아깝다. 그리고 10분이 넘어가면 경고를 찍는데, 그 경고를 그냥 넘기지 말고 답변에 같이 적게 해 뒀다 — **성기게 봤다는 사실 자체가 결과의 일부**이기 때문이다.

## 같은 영상을 두 번 안 본다

같은 세션에서 후속 질문이 오면 **다시 돌리지 않는다.** 프레임과 대본이 이미 맥락에 있는데 또 뽑는 건 같은 비용을 두 번 내는 것이다.

이게 규칙으로 적혀 있어야 하는 이유가 있다. 도구를 부르는 쪽 입장에서는 "새 질문 = 새 실행"이 자연스럽게 느껴져서, 안 적어 두면 두 번째 질문에서 8만 토큰이 또 나간다.

## 해상도는 올리지 않는다

기본이 512px 폭이다. 1024로 올리면 장당 토큰이 대략 네 배가 되므로, **80장이 20~30만 토큰**이 된다.

올릴 만한 경우는 하나뿐이다 — 화면의 작은 글자를 읽어야 할 때. 그때도 전체가 아니라 **그 구간만** 올린다. 전 구간 고해상도는 예산 설계 전체를 무의미하게 만든다.