Production work,
told as the decision behind it. 현업 결과물,
그 뒤의 판단으로 정리합니다.

01 What executes is an approved spec, not a conversation 실행되는 것은 대화가 아니라 승인된 명세다

The creative brief separates the user’s statements, model assumptions and missing questions before compiling a structured generation plan. Relevant image paths require review; some image-free paths permit automatic approval. The model fills parameters in an approved workflow rather than creating an arbitrary graph. 크리에이티브 브리프에서 사용자 발언·모델 추정·추가 질문을 구분한 뒤 구조화된 생성 계획으로 변환합니다. 이미지가 필요한 경로에는 검토를 두고 일부 무이미지 경로는 자동 승인을 허용합니다. LLM은 임의 그래프를 만드는 대신 승인된 워크플로우의 매개변수를 채웁니다.

"Assumptions are shown before approval, not discovered in the output." "추정값은 승인 전에 보인다. 결과물에서 발견되는 게 아니라."

02 The LLM never authors the workflow graph LLM은 워크플로우 그래프를 만들지 않는다

Let a model assemble a ComfyUI graph freely and you get nonexistent nodes, incompatible checkpoints, VRAM blowouts, and runs nobody can reproduce. So the graph is fixed to operator-qualified workflows and the model fills only declared parameter slots . That inverted the product surface too: users don't pick a workflow, they assemble a structured prompt — shots, duration, dialogue, soundscape, music, constraints — and the workflow stays an internal execution recipe. 모델이 ComfyUI 그래프를 자유롭게 조립하게 두면 존재하지 않는 노드, 호환되지 않는 체크포인트, VRAM 초과, 아무도 재현할 수 없는 실행이 나옵니다. 그래서 그래프는 운영자가 검증한 워크플로우로 고정하고, 모델은 미리 선언된 파라미터 슬롯 만 채웁니다. 이 결정은 제품 표면도 뒤집었습니다 — 사용자는 워크플로우를 고르지 않고 숏·길이·대사·환경음·음악·제약으로 이뤄진 구조화 프롬프트를 조립하며, 워크플로우는 내부 실행 레시피로 남습니다.

03 One execution boundary, swappable runtimes, immutable snapshots 실행 경계는 하나, 런타임은 교체 가능, 스냅샷은 불변

Our backend is the only execution boundary: a local ComfyUI host and a hosted runtime sit behind the same adapter contract, with identical queue/history state handling and receipt-based resume and artifact recovery. The workflow and parameters at run time are frozen as an immutable snapshot — recipes change only as a new revision — so reproduction is snapshot-based, not memory-based. Nothing that leaves the boundary carries a raw graph, provider payload, storage key, or credential. 우리 백엔드가 유일한 실행 경계입니다. 로컬 ComfyUI 호스트와 호스팅 런타임은 같은 adapter 계약 뒤에 있고, 큐·히스토리 상태 분기와 receipt 기반 재개·산출물 회수를 동일하게 처리합니다. 실행 시점의 워크플로우와 파라미터는 불변 스냅샷 으로 고정되고 레시피는 새 revision으로만 바뀌므로, 재현은 기억이 아니라 스냅샷 기준입니다. 경계 밖으로 나가는 응답에는 raw graph·provider payload·storage key·credential이 포함되지 않습니다.

04 The 15-second wall: long form is a continuity problem, not an editing one 15초의 벽 — 장편은 편집 문제가 아니라 연속성 문제다

The generation model produces about 15 seconds at a time, so a 15 / 30 / 60 / 180-second request is analyzed once per video and planned into exactly 1 / 2 / 4 / 12 segments. The decision that mattered was refusing to treat two things as one feature: reference-to-video (identity, style, motion) and frame chaining (last frame → next first frame) are a subject anchor and a time-boundary anchor, and they are verified separately. A manager step that sees the whole video at once decides per segment which references to use or omit , and a segment left with no reference is explicitly stopped rather than quietly generated from text. 생성 모델이 한 번에 만드는 길이는 약 15초입니다. 그래서 15 / 30 / 60 / 180초 요청은 영상당 한 번 분석해 정확히 1 / 2 / 4 / 12개 세그먼트로 계획합니다. 여기서 중요한 판단은 두 가지를 같은 기능으로 묶지 않은 것입니다 — reference-to-video (인물·스타일·모션 동일성)와 프레임 체이닝 (이전 마지막 프레임 → 다음 첫 프레임)은 각각 대상 앵커와 시간 경계 앵커이며, 별도로 검증합니다. 전체 영상을 한 번에 보는 관리자 단계가 세그먼트마다 어떤 참조를 쓰고 뺄지 결정하고, 참조가 하나도 남지 않은 세그먼트는 조용히 텍스트로 생성하지 않고 명시적으로 중단합니다.

"A reference is who it is. Frame chaining is when it is. They are not the same feature." "reference는 '누구인가'이고, 프레임 체이닝은 '언제인가'다. 같은 기능이 아니다."

05 Three generation modes, one prompt IR — and a gate that only judges 세 생성 모드, 하나의 prompt IR — 그리고 판정만 하는 게이트

Text-, image-, and reference-driven generation each grew their own prompt rules, so I unified them behind a single structured prompt IR and renderer: verbatim dialogue with lip-sync and subtitle policy, ambient soundscape kept separate from non-diegetic music, length ceilings, and constraint phrasing now apply identically across all three. Multimodal image analysis records what the user declared apart from what the pixels show , and never rewrites the user's own classification. The specialist steps are not free-form agent chat — each has a fixed input, output, and write scope — and the pre-generation gate returns only PASS / REPAIR / BLOCKED with a target step and reasons. It never edits the prompt itself; a repair re-runs just the failed step, under a call ceiling. 텍스트·이미지·참조 기반 생성이 각자의 프롬프트 규칙을 갖게 되자, 하나의 구조화 prompt IR과 renderer로 통합했습니다. 대사 원문과 립싱크·자막 정책, 환경음과 비-디제틱 음악의 분리, 길이 상한, 제약 표현이 이제 세 모드에 동일하게 적용됩니다. 멀티모달 이미지 분석은 사용자가 선언한 사실 과 픽셀에서 관찰된 것 을 분리해 기록하며, 사용자가 정한 분류를 임의로 바꾸지 않습니다. 전문가 단계들은 자유로운 에이전트 대화가 아니라 입력·출력·쓰기 권한이 고정된 순서로 돌고, 생성 직전 게이트는 PASS / REPAIR / BLOCKED 와 대상 단계·근거만 반환합니다. 게이트가 프롬프트를 직접 고치지는 않으며, 보정은 실패한 단계만 호출 상한 안에서 다시 실행합니다.

"The gate judges. It does not rewrite the prompt." "게이트는 판정한다. 프롬프트를 고쳐 쓰지 않는다."

06 Experiment record and current implementation 기존 실험과 현재 구현을 구분

Earlier music-video, ad and drama trials recorded issues with musical boundaries, visual information, on-screen Hangul and voice quality. Reference features now support long-form continuity and voice consistency to a degree. The current task is evaluating model-specific output quality. The existing engineering snapshot includes 10 decision briefs, 26 dated verification records, roughly 490 backend tests and a canonical contract. One change came from review feedback: a reviewer flagged unwanted speech in a revised clip; narration mixed into the context video was prompting the model to speak, so the context now carries only picture and background audio, and the rerun's replacement clip had zero detected speech segments. That is one experiment's observation, not a fix for all speech errors. 기존 뮤직비디오·광고·드라마 실험에서는 음악 경계, 화면 정보량·한글, 목소리 등의 품질 문제를 기록했습니다. 현재는 레퍼런스 기능으로 장편 연속성과 목소리 일관성을 일정 수준 구현했으며, 모델별 결과 품질을 검토합니다. 기존 기술 기록에는 결정 브리프 10건, 날짜별 검증 기록 26건, 약 490개의 백엔드 테스트와 단일 계약 정본이 있습니다. 검토 피드백으로 바꾼 사례도 있습니다. 검토자가 수정 영상의 원치 않는 발화를 지적했고, 문맥 영상에 섞인 나레이션이 모델의 발화를 유도한 것으로 판단해 화면과 배경음만 문맥으로 넘기도록 바꿨습니다. 재실행한 교체 구간의 음성 탐지는 0건이었습니다. 해당 실험의 관찰이며 발화 오류 전체의 해결은 아닙니다.

How it connects: 연결점: Same discipline as the legal assistant below and my public PoCs — the model proposes, a deterministic layer verifies, and an explicit gate decides what ships. Here the artifact is a video instead of an answer, and the reproducible unit is an execution snapshot instead of a source reference. 아래 법률 어시스턴트, 그리고 제 공개 PoC와 같은 방식입니다 — 모델이 제안하고, 결정적 레이어가 확인하고, 명시적 게이트가 무엇을 내보낼지 결정합니다. 다만 여기서 산출물은 답변이 아니라 영상이고, 재현의 단위는 source reference가 아니라 실행 스냅샷입니다.

01 Contract-first, four independent layers Contract-first, 네 개의 독립 레이어

The problem isn't solved by one LLM call, so I split it into four layers — Intake, Knowledge, RAG Harness, Verification/Gate — and fixed the contracts between them before building . Each layer is developed independently against mocks; the boundary objects (Task Brief, Source Ref, Gate Decision) are the single source of truth. 이 문제는 LLM 한 번 호출로 풀리지 않습니다. 그래서 Intake / Knowledge / RAG Harness / Verification·Gate 네 레이어로 나누고, 구현보다 먼저 레이어 간 계약을 고정 했습니다. 각 레이어는 mock으로 독립 개발하고, 경계 객체(Task Brief·Source Ref·Gate Decision)가 단일 진실 공급원입니다.

02 Build the trust foundation before the features 기능보다 신뢰 기반을 먼저

I build Knowledge + Verification first — the trust foundation — before the RAG that feeds them. The core invariant: unverified text never reaches the user , and any answer mutation (e.g. redacting an unsupported claim) is re-verified before it ships. RAG보다 Knowledge·Verification을 먼저 만듭니다 — 신뢰 기반부터. 핵심 불변식: 검증되지 않은 텍스트는 사용자에게 나가지 않는다 . 답변을 바꾸는 처리(예: 근거 없는 claim 제거)는 재검증을 거친 뒤에만 나갑니다.

"Unverified text never reaches the user." "검증되지 않은 텍스트는 사용자에게 나가지 않는다."

03 The vector DB is a cache, not the truth — retrieval is ontology-aware VectorDB는 진실이 아니라 캐시다 — 검색은 ontology-aware

A common RAG trap is treating the vector store as the source of truth. Here it's only a retrieval cache — final evidence is always reloaded from an immutable source snapshot via source_ref . Retrieval is ontology-aware: it returns the smallest unit plus its path in the legal tree (article / clause / item) and reloads the surrounding context on demand, so a citation stays reproducible even if the parser or policy changes. 흔한 RAG 함정은 vector store를 진실의 원천으로 다루는 것입니다. 여기서 그것은 검색 캐시일 뿐이고, 최종 근거는 항상 불변 source snapshot 에서 source_ref 로 재로드됩니다. 검색은 ontology-aware입니다 — 법령 트리(조/항/호/목) 에서 최소 단위 + 경로를 돌려주고 상위 맥락은 필요할 때 재조회하므로, parser·정책이 바뀌어도 인용은 재현됩니다.

"The vector DB is a cache. The source snapshot is the truth." "VectorDB는 캐시다. Source Snapshot이 진실이다."

04 Schema-guided intake: the schema drives the conversation Schema-guided intake: 스키마가 대화를 주도한다

A vague non-developer request ("is this contract risky?") isn't handed straight to the RAG. The default path is deterministic — a schema registry, a validator, and a compiler decide the intake status; the LLM task classifier and slot filler sit behind opt-in flags and are allowed only to propose , against a registered task-type list and a field allowlist. The model refines, it doesn't reason ; unknown fields stay null rather than guessed; a user-confirmed slot cannot be overwritten by a later model guess; and it asks the user only for what's genuinely missing. The resulting Task Brief is itself a validated artifact, and a session that can't be resolved is parked for human review until a reviewer resolves it explicitly. 비개발자의 모호한 요청("이 계약서 위험해?")을 RAG에 바로 넘기지 않습니다. 기본 경로는 결정론 입니다 — 스키마 레지스트리·validator·compiler가 intake 상태를 결정하고, LLM task classifier와 slot filler는 opt-in 플래그 뒤에서 등록된 task type 목록과 필드 allowlist 안에서 제안만 합니다. 모델은 추론이 아니라 정제 하고, 모르는 필드는 추측하지 않고 null 로 두며, 사용자가 확정한 슬롯은 이후 모델 추정이 덮어쓸 수 없고, 정말 빠진 것만 사용자에게 묻습니다. 그렇게 만든 Task Brief 자체도 검증 대상이며, 해소되지 않는 세션은 추측 대신 human review로 보류(park) 되어 리뷰어가 명시적으로 해제할 때까지 대기합니다.

"The LLM refines the request; it doesn't reason about it. If it doesn't know, the value is null." "LLM은 요청을 정제할 뿐, 추론하지 않는다. 모르면 값은 null이다."

05 Agentic research — but the LLM only proposes Agentic 연구 — 그러나 LLM은 제안만 한다

Answer generation is a multi-agent research loop — query planning, claim extraction, evidence linking, semantic verification, revision — with a gate that can send work back ( retrieve_more / revise / ask_user ) or, when the grounding budget is exhausted, park it for human review . The division of labor is strict: the LLM proposes candidates, the verification layer confirms grounding claim-by-claim, and the gate decides what ships. 답변 생성은 멀티 에이전트 연구 루프입니다 — query planning, claim extraction, evidence linking, semantic verification, revision — 그리고 작업을 되돌리거나( retrieve_more / revise / ask_user ), grounding 예산이 소진되면 human review로 보류 하는 gate가 있습니다. 역할 분담은 엄격합니다: LLM은 후보를 제안하고, 검증 레이어가 claim 단위로 grounding을 확인하며, gate가 무엇을 내보낼지 결정합니다.

06 Verified the same way I verify everything 내가 모든 걸 검증하는 방식 그대로

I hold this private work to the same bar as my open PoCs, and keep the same separated trails: dated verification records (each a conditional verdict, guarded both ways so a fix can't bring the bug back or start flagging valid cases), daily working logs , a single canonical contract file held in place by drift-lock tests that fail the moment the spec and the code diverge — including an exact-drift guard between the committed OpenAPI document and the running service's own schema. This MVP has accumulated development records across its layers: 177 dated verification records across ~2 months of daily logs, on a suite that reached 1,119 tests in the integrated repository. AI does the work; the verification decides whether it is real. 이 비공개 작업도 공개 PoC와 같은 기준으로, 같은 분리된 자취를 남깁니다 — 변경마다의 날짜별 검증 기록 (조건을 명시한 판정 + 양방향 회귀 가드 — 버그 재발과 정상 케이스 오탐 양쪽을 막음), 일일 워킹로그 , 명세와 코드가 어긋나는 순간 실패하는 drift-lock 테스트로 고정한 단일 정본 계약 파일, 그리고 커밋된 OpenAPI 문서와 실행 중인 서비스의 스키마 사이 exact-drift 가드. MVP의 여러 레이어에 걸쳐 개발 기록을 남겼습니다 — 약 2개월치 일일 로그에 걸친 날짜별 검증 기록 177건 , 통합 저장소 기준 1,119개 까지 늘어난 테스트 스위트. AI가 일하고, 검증이 그것이 진짜인지 결정합니다.

How it connects: 연결점: This is the production-scale version of the same idea behind my public PoCs — AI proposes, deterministic verification confirms, a human-aware gate decides. 이것은 제 공개 PoC와 같은 사상의 실무 규모 버전입니다 — AI는 제안하고, 결정론적 검증이 확인하며, 사람을 고려한 gate가 결정합니다.

07 The verification core shipped as its own repo — and the wheel is not the contract 검증 Core를 독립 저장소로 분리 — 그리고 wheel은 계약이 아니다

Once the verification boundary held, I extracted it into a standalone repository whose only supported cross-service interface is a versioned private HTTP API: a candidate goes in, a verified package comes out. The Python wheel and package facade are explicitly not an SDK boundary, so no consumer can quietly couple to internals. Ownership is drawn the same way — the calling service owns authoritative storage and the commit decision; the core returns a verified package and a recommended caller action, and never commits on the caller's behalf. A published compatibility matrix between the testbed and the core API version acts as a release gate (independent release or rollback only while the published HTTP/schema versions stay compatible), structural regressions ban cross-package imports so the boundary can't erode by convenience, and the extracted repo was proven by rebuilding it from a publication manifest in a clean environment — wheel install, checkout-free liveness/readiness, image build, and a contract fingerprint. 검증 경계가 안정되자 Core를 독립 저장소로 분리했고, 다른 서비스가 쓸 수 있는 유일한 지원 인터페이스는 버전이 붙은 private HTTP API 하나입니다 — candidate가 들어가고 verified package가 나옵니다. Python wheel과 package facade는 SDK 경계가 아니라고 명시해, consumer가 내부 구현에 조용히 결합할 수 없게 했습니다. 소유권도 같은 방식으로 그었습니다 — authoritative storage와 commit 결정은 호출하는 서비스가 소유하고, Core는 검증된 package와 권고 action만 돌려줄 뿐 caller를 대신해 커밋하지 않습니다. testbed와 Core API 버전 사이의 호환성 매트릭스 가 릴리스 게이트로 동작하고(공개된 HTTP·schema 버전이 호환되는 동안에만 독립 릴리스·롤백 허용), 구조 회귀 테스트가 package 간 import를 금지해 편의로 경계가 무너지지 않게 했습니다. 분리된 저장소는 publication manifest로 clean 환경에서 다시 조립해 증명했습니다 — wheel 설치, checkout 없이 liveness/readiness, image 빌드, 계약 fingerprint까지.

"The wheel is not the contract. The published HTTP version is." "wheel은 계약이 아니다. 공개된 HTTP 버전이 계약이다."