어휘는 하나, 줄은 그보다 좁게
Ember의 생성기 카탈로그 맨 위에는 화면비 목록이 있어. 항목마다 id가 있고, Ember가 프롬프트에 덧붙일 문장이 같이 붙어. 오늘 기준 어휘는 1:1, 3:2, 4:3, 16:9 네 가지야. 줄마다 자기 aspect_ratios를 따로 가질 수도 있어. ElevenLabs 줄이 그래. Ember는 모델이 밝힌 목록과 자기 어휘의 교집합을 잡고, 넷 중 하나도 안 되는 모델은 아예 줄을 안 만들어. 자기 목록이 없는 줄은 어휘 전체를 다 준다는 뜻이야.
Avatars 요청에는 aspect_ratio가 딱 하나 있어. 따로 안 적으면 1:1이고, 그게 배치 전체에 적용돼. 그러니까 배치가 생성기 셋에 16:9를 요청하면, 셋 다 16:9를 그릴 수 있어야 해.
이걸 가르쳐 준 버그
2026-09-30 당시 스튜디오는 어떤 생성기에든 모든 모양을 내밀었고, plan()은 맨 위 어휘만 확인했어. 근데 어떤 ElevenLabs 줄은 그보다 좁아. 고친 커밋이 이름까지 적어 놨어. GPT Image 1과 1.5는 1:1과 3:2만 되고, Seedream 두 줄은 3:2가 없어. 그런 줄에 16:9를 요청해도 계획은 통과했어. 배치가 생기고, 작업이 큐에 들어가고, 제출까지 됐지. 그러고는 Ember가 실행하는 순간 잡이 하나하나 실패했어. Ember의 ElevenLabs 경로는 생성할 때 그 줄의 목록을 확인하거든. 그 실패들은 전부 첫 작업이 생기기 전에 알 수 있는 거였어.
이런 파이프라인에서 피할 수 있는 실패는 대개 이렇게 생겼어. 거절에 필요한 사실은 주인이 처음부터 내놓고 있었어. 클라이언트가 주인이 답해줄 수 있는 것보다 뭉뚱그린 질문을 했을 뿐이야.
큐에 넣기 전에 이름을 대고 거절해
고친 방법은 backend/studio.py의 작은 모듈 함수 두 개야. aspect_ids는 Ember가 쓰는 두 가지 표기를 다 읽어. 줄에는 그냥 id로, 어휘에는 {id, prompt} 항목으로 들어 있거든. require_aspect는 그 줄의 목록에 없는 비율을 거절해. 메시지에는 생성기 이름, 요청한 모양, 그 생성기가 주는 모양을 다 적고. 이제 계획은 세 가지를 순서대로 확인해.
- 그 비율이 Ember 어휘에 아예 있는지. 없으면 Ember에 없는 화면비라고 거절해.
- 고른 생성기의 줄마다 그 비율을 주는지.
- 자동 경로가 고른 등급도 그 비율을 주는지.
세 번째는 이중 안전장치야. Avatars는 이미 Ember의 경로 미리보기에 비율을 넘기고, Ember는 그 비율이 없는 등급을 건너뛰어. 그래도 require_aspect가 고른 줄을 그 줄의 목록에 한 번 더 대봐. 경로 판정을 타고 잘못된 모양이 빠져나가는 일이 없게 하는 거지.
테스트는 Narrow Credits라는 이름의 줄이 1:1과 3:2만 주는 카탈로그를 만들어. 16:9 요청은 정확히 이 문장을 받아. Narrow Credits does not offer 16:9 output; it offers 1:1, 3:2. Choose one of those, or another generator. 그 생성기는 16:9를 안 주고 1:1, 3:2만 주니까 그중에 고르거나 다른 생성기를 고르라는 뜻이야. 두 번째 테스트는 같은 본문을 미리보기 경로, 제출 경로, 피파 내부 관문에 다 보내. 셋 다 같은 문장을 422로 받는지 보고, 배치 목록이 여전히 비어 있는지도 확인해. 스튜디오든 어느 두뇌든 결국 같은 함수에 닿으니까 같은 거절을 보게 돼.
선택기는 아빠의 선택을 절대 안 바꿔
웹 스튜디오는 서버가 거절하기 전에 같은 사실로 먼저 도와줘. narrowAspects는 목록이 어휘보다 좁은 생성기에 표시를 달아. 그래서 줄에 credits · 1:1, 3:2 only 같은 글이 붙어. aspectConflicts는 고른 생성기가 못 그리는 모양을 화면비 메뉴에서 전부 비활성으로 만들어. 그래도 고른 모양이 충돌할 수 있어. 아빠가 16:9를 먼저 고르고 좁은 생성기를 나중에 체크한 경우야. 그러면 경고가 그 생성기와, 그 생성기가 주는 모양을 짚어줘. 모양을 바꾸거나 생성기를 빼기 전까지 Review 버튼은 꺼진 채로 있고.
스튜디오가 절대 안 하는 일은 비율을 대신 바꾸는 거야. 16:9 자리에 3:2를 슬쩍 넣으면 썸네일이나 일기 표지용 배치가 아무 말 없이 엉뚱한 모양으로 나와. 아키텍처 문서도 한 줄로 못 박아 놨어. 고른 화면비는 스튜디오가 스스로 바꾸지 않는다고. 자동 줄은 등급이 나중에 정해지니까 자기 목록이 없어. 그래서 선택기는 이 경우를 미리 알 수 없고, 서버 검사가 맡아.
레퍼런스 이미지도 모델이 밝힌 한도까지만
생성기가 받는 레퍼런스 이미지 수에도 같은 규칙을 적용해. 2026-10-06 전까지 계획은 한도를 안 밝힌 줄에 대비책으로 10장 상한을 걸었어. 그 상한은 없어졌고, 이제 Avatars는 모델이 밝힌 한도만 써. Ember의 표현을 빌리면, 한도가 없다는 건 모르는 거지 앱 전체에 지어낸 상한이 있다는 뜻이 아니야. 오늘 Ember가 밝힌 값은 Nano Banana Pro 14, OpenAI 줄 16, 로컬 지시형 계열 10이고, Codex는 한도를 밝히지 않아. ElevenLabs는 모델마다 제각각이야.
검사는 작업마다 돌아. 작업의 입력은 그 프레임에 연결된 원본(리믹스와 재생성일 때)에 요청의 레퍼런스를 더하고 중복을 뺀 거거든. 한도를 넘으면 계획은 줄 이름, 한도, 실제 개수를 대고 거절해. 테스트는 한도를 안 밝힌 모델이면 레퍼런스 24장이 하나도 안 잘리는지 확인해. 이어서 그 모델의 한도를 14로 바꾸고, 두 숫자를 다 짚는 거절이 나오는지 봐. 리믹스엔 같은 종류의 거절이 하나 더 있어. 원본이 연결 안 된 프레임이 있으면, 리믹스하려면 그 프레임의 원본이 필요하다며 계획을 멈춰. 빠진 연결은 제출 전에 보여야 하고, 기본값으로 짐작해서 채우면 안 된다는 게 아키텍처 규칙이야.