프론티어와 싸우는 제품은 다음 릴리스에 죽는다.
프론티어를 더 좋게 만드는 제품은 모델이 좋아질수록 같이 좋아진다.

어제 아침, 제 노션에는 아홉 칸짜리 기능 목록이 있었습니다. 스케줄 관리, 아침 브리핑, 웹 리서치, 개발 밑작업, 채널 연동, MCP 허브, 인텐트 라우터, 자유 대화, 라벨링·분류. 로컬 8B 모델 하나로 굴러가는 개인 AI 비서의 요구사항이었습니다.

저녁에 같은 목록을 다시 열었을 때는 여덟 칸에 취소선이 그어져 있었습니다. 남은 것은 라벨링·분류 하나. 삭제는 여덟 개를 진행했고 단 하나만 유지했습니다. 삭제 분은 전부 상용 AI에 위임했습니다.

기능을 지웠는데 제품은 강해졌다고 저는 판단했습니다. 그 판단이 왜 성립하는지가 오늘 글의 주제입니다. 프로젝트 이름은 ProjectDavid(이하 David), 옵시디언 호환 볼트를 스스로 정리하는 로컬 사서입니다.

1. 출발은 만능 비서였다 (The Wishlist)

로컬 8B 하나로 전부.
다만 맨손 출발은 아니었다.

제약 조건부터 적습니다. 로컬 8B(파라미터 80억) 단일 모델, VRAM(그래픽 메모리) 8GB. 클라우드 API 없이 이 안에서 아홉 개 기능이 전부 돌아야 한다는 것이 첫 스펙이었습니다.

밑천은 있었습니다. 이전 파이프라인에서 검증하고 온 원칙 네 개입니다.

1. 해석은 LLM - 실행은 결정론
2. 측정 우선 - 코드보다 측정값을 먼저 만든다
3. 사람 개입은 없애지 않고, 가볍게 만든다
4. 프롬프트에는 지시만 - 내용은 데이터로

원칙 1이 이 프로젝트의 척추입니다. LLM에게 전부 맡기면 비결정이 전 구간에 퍼집니다. 같은 문서를 여러 번 처리하면 다른 결과가 나오고, 자유 산문 출력은 파이프라인으로 검토할 수 없고, 계산과 조립까지 맡기면 확인 없이 조용히 틀립니다. 지난 글의 표현을 빌리면, 모델 출력을 그대로 내보내는 것은 제품이 아니라 데모입니다.

그래서 해석과 실행을 가릅니다. 비결정은 필드 추출 한 칸에 격리하고, 실행은 결정론 코드가 잡아 같은 입력에는 같은 출력이 나오게 하고, 출력은 고정 폼이라 파이프라인 검토가 성립합니다. 뒤에 나올 채점 배터리(모델을 채점할 문제집)의 전제입니다. 비결정을 어디에 둘 것인가. 그 판단이 데모와 제품을 가릅니다.

작업 형식도 하루 종일 같았습니다. 아이디어(사람) → 검증(AI) → 수정 → 재검증 → 결정. 이 루프로 일곱 라운드를 돌았고, 아래는 그중 판이 바뀐 라운드들입니다.

2. 8B는 조건부로 성립한다 (Breaking Points)

약점은 프롬프트로 달래는 게 아니라,
설계에서 도려낸다

첫 질문은 단순했습니다. 이 아홉 개, 일반 사양(8B)으로 되는가.

검증의 답은 "가능, 단 조건부"였습니다. 활성 파라미터 4B급 모델로 제품이 성립하는 것은 이전 파이프라인에서 실측해둔 터라, 8B는 크기 면에서 여유가 있습니다. 문제는 크기가 아니라 종목입니다. 일반 사양(8B)이 구조적으로 깨지는 지점 세 개는 설계 단계에서 원천 차단해야 했습니다.

일반 사양(8B)이 깨지는 지점 회피 구조

세 행의 수법은 같습니다. 약점을 달래는 게 아니라 도려내는 것. 모델이 작을수록, 데이터 배치가 똑똑해야 합니다.

3. 격차는 없애는 게 아니라 옮긴다 (Gap Transformation)

위험한 건 확인이 뜨는 쪽이 아니라,
확인 없이 조용히 틀리는 쪽이다

성립한다는 답을 받고, 격차를 세 번 찔렀습니다.

"Haiku보다 아래지?" — 맞다. 모든 면에서.

"그럼 라우팅은 8B가 낫다는 건가?" — 아니다. 일을 쉽게 깎아, 격차가 안 드러나게 한 것.

"내 요청 처리엔 문제없다는 건가?" — 없다. 격차를 옮겨놨으니까.

두 번째 답의 정정이 이 라운드의 수확입니다. 격차는 라우팅에서 사라지는 게 아닙니다. 라우팅이라는 과제가 충분히 쉬워서, 격차가 제품 품질로 전이되지 않을 뿐입니다. 그래서 격차는 없애는 대상이 아니라 옮기는 대상이 됩니다.

• 해석 격차 → 확인 횟수로 (마찰)
• 문장 격차 → 밋밋함으로 (미감)
• 에이전틱 격차 → 옮길 곳 없음. 해당 기능 금지

품질 지표도 여기서 나왔습니다. 오실행 0 + 확인율 상한. 라운드 넷을 지나며 v1 아키텍처가 확정됐습니다. 사용자 의도 분류 + 결정론 파이프라인 + 확인 카드 + 저장 3층. 추출 필드 설계와 채점 세팅, 모델 검증까지 이날 진행했습니다. 모델 선정전은 실측 숫자와 함께 따로 한 편으로 쓰겠습니다.

여기까지가 하루의 대부분이었습니다. 그리고 다섯 번째 라운드에서, 이 설계의 대부분이 지워집니다.

4. 축소가 아니라 논지의 완성이다 (The Pivot)

버린 것은 상용 AI가 더 잘하는 것.
남긴 것은 구조적으로 못 하는 것

이번에는 제가 제안을 냈습니다.

"비서의 역할을 축소하고 싶다. 리서치·자료 정리·바이브코딩은 상용 AI로 하면 된다. 상용 AI가 일할 수 있는 상태를 만드는 것이 핵심이다."

근거는 실사용 관찰이었습니다. 직접 써보니, Claude도 ChatGPT도 분류는 힘들어하더라는 것.

검증의 답은 예상 밖이었습니다. 축소가 아니라 논지의 완성이라는 것. 상용 AI가 분류에 약한 이유는 지능이 아니라 구조에 있고, 그 구조는 셋입니다.

첫째, 기억이 세션마다 리셋됩니다. 분류 기준을 매번 재발명합니다. 어제 세운 규칙의 연속성이 없습니다.

둘째, 태그 어휘가 발산합니다. #ai, #AI, #인공지능이 한 볼트 안에서 공존합니다. 정규화의 주체가 없으면 어휘는 반드시 갈라집니다.

셋째, 컨텍스트 비용이 누적됩니다. 일관성을 지키려면 폴더 전체를 매번 다시 읽어야 하는데, 그 비용은 문서 수에 비례해 늘어납니다.

셋을 접으면 공식이 나옵니다.

분류의 품질 = 일관성.
일관성 = 리셋되지 않는 상태 + 결정론.

상용 AI가 구조적으로 못 갖는 것이고, 로컬 상주 데몬이 기본으로 갖는 것입니다.

5. 삭제 8, 유지 1 (The Verdict)

판정 축은 현재 성능이 아니라 구조.
구조 비교는 다음 릴리스에 뒤집히지 않는다

판정 기준이 그래서 이렇게 섰습니다.

• 상용 AI가 더 잘하는 기능 → 전부 삭제
• 상용 AI가 구조적으로 못 하는 기능 → 유지

이 기준으로 아홉 칸을 채점한 결과가 서두의 취소선입니다. 스케줄과 브리핑은 상용 AI의 예약 작업이, 리서치는 웹 검색이 더 잘합니다. 라우터와 자유 대화는 상용 AI 그 자체입니다. 여덟 개가 지워졌고, 오전 내내 세운 라우터와 확인 카드도 같은 판정으로 함께 지워졌습니다. 매몰비용보다 판정이 앞섭니다.

살아남은 것은 라벨링·분류 하나. 아홉 개 중 상용 AI 위임이 성립하지 않는 유일한 항목입니다. 확인 카드는 죽었지만 그 패턴은 리뷰 큐로 생존했습니다. 확신 못 하면 조용히 틀리는 대신 리뷰 큐에 쌓아둡니다.

역할 분담은 이렇게 확정됐습니다.

역할 담당

글을 쓰는 AI가 아니라, 꽂아두는 AI입니다.

LLM 위키가 된 것입니다.

6. 여기까지는 전부 연역이다 (The Honest Brake)

연역은 반박할 데이터가 없다.
아름다운 논리일수록 위험하다

정직하게 적어둡니다. 여기까지는 전부 연역입니다. 코드 0줄, 처리한 문서 0건.

그래서 다음 글부터는 숫자로 말하겠습니다. 오분류 0. 리뷰 큐로 넘긴 것은 실패가 아니고, 큐 없이 틀린 확정만 실패로 셉니다. 같은 파일 3번이면 3번 같은 결과(재현성 100%). 그리고 리뷰 큐 상한. 검토 대기함이 넘치면 그것도 실패입니다. 기준에 못 미치면, 미달한 숫자를 그대로 공개하겠습니다.

마치며: 다음은 게이트다

David는 게이트 단위로 만듭니다. 결정 로그, 배터리 숫자, 게이트 데모와 전 과정을 공개하고, 저장소는 MIT 라이선스로 엽니다.

서두의 문장으로 돌아옵니다. 프론티어와 싸우는 제품은 다음 릴리스에 죽습니다. 프론티어를 더 좋게 만드는 제품은 모델이 좋아질수록 같이 좋아집니다. David가 서려는 자리는 후자입니다.

다음 글은 이날의 나머지 절반입니다. 검증은 역방향으로도 작동했습니다. AI가 낸 설계에서 원칙 위반 세 건을 검출한 기록. 템플릿 속 개인 데이터, 공개될 뻔한 테스트 케이스, 그리고 출처 하나짜리 '표준'.

인프런 강의를 만들고 있습니다.
총 18편, 편당 5~25분
문제는 촬영이 아니라 검수였습니다.

편집본 하나를 QA하려면 최소 두 번은 정주행해야 합니다.

딜리버리(말 끊김, 톤 점프)
편집 요소(강조 표시가 발화와 맞는지)
페이싱(처음 보는 사람이 따라올 수 있는지)

이것들을 다 봐야 하니까요.

편당 5분~25분, 18편이면 검수 두번만 돌아도 최소 10시간 이상입니다.

게다가 제작자는 자기 영상의 이음새 위치를 전부 알고 있어서,

객관적인 "처음 보는 눈"이 구조적으로 불가능합니다.

그래서 영상 이해 AI에게 그 눈을 맡겨봤습니다.

TwelveLabs의 영상 이해 모델을 쓰는 Jockey로 검수 파이프라인을 만들었고,

한 달간 굴리면서 이 도구를 어디까지 믿어도 되는지 실측했습니다.

결론부터: 방향 탐지는 놀랍도록 유효하고, 세부 판독은 반드시 사람이 확정해야 합니다.

그 사이 어딘가에서 AI가 없는 자막을 있다고 판독한 사건이 있었는데 그 얘기도 나눠볼까 합니다.

파이프라인 구조

흐름은 단순합니다.

1. 원본 분석: 촬영 원본을 지식 저장소에 등록하고, 딜리버리 품질·용어 갭·편집 개입 지점을 타임스탬프로 뽑게 한다.
2. 편집 지시서 생성: 분석 결과를 구간 성격별 편집 규칙(판단 발화는 보존, 확인 구간은 점프컷 등)으로 정규화한다.
3. 편집본 QA: 편집 완료본을 다시 등록하고, 출시 전 최종 검수를 돌린다.

프롬프트에서 중요했던 건 페르소나와 금지어였습니다.

"객관적이고 비판적인 평가자"
"칭찬보다 결함 발견이 목적"
"확신 없는 판독은 '판독 불확실'로 표기"

이걸 안 넣으면 영상 AI도 텍스트 LLM처럼 좋은 말부터 합니다.

여기까지는 순조로웠고

원본 분석은 실제로 유용했습니다.

"02:00~03:00 구간 정적 화면, 이탈 위험",

"용어 X가 설명 없이 통과" 같은 지적이 타임스탬프와 함께 나왔습니다.

스스로 검수를 했을 때와 상당수가 겹쳤습니다.

사건: 없는 자막이 보인다

편집본 QA를 처음 돌린 날이었습니다.

결과가 이상했습니다.

• "전사형 자막이 확인되며, 낭독감 해소에 유효함", 자막을 넣은 적이 없습니다.
• "화면 강조 표시(A)가 약하거나 확인되지 않음", 빨간 박스를 아홉 개 넣었습니다.

있는 걸 없다고 하고, 없는 걸 있다고 하는 정반대 오판독.

한쪽만 틀렸으면 우연이라 치겠는데 둘 다 뒤집혔으니,

도구 신뢰도 자체를 의심해야 하는 상황이었습니다.

원인 후보를 좁혀보니 파일 쪽이 수상했습니다.

그날 업로드한 파일이 원본 5분 30초짜리의 편집본이라기엔 1분 16초로 너무 짧았던 겁니다.

익스포트가 잘렸거나 다른 파일이 올라간 상태에서,

AI가 잘린 앞부분(빨간 박스 등장 전 구간)만 보고 전체를 판정했고,

화면 속 앱 UI의 텍스트를 편집 자막으로 오인했다는 것이 유력한 가설이었습니다.

디버깅: 정답을 숨긴 관찰 테스트

가설 검증을 위해 온전한 파일을 다시 올리고, 이번엔 평가가 아니라 관찰을 시켰습니다.

핵심적으로 정답을 숨겼습니다.

"빨간 박스를 넣었는데 보이냐"고 물으면 확증 편향으로 "보인다"가 나올 수 있으니까요.

프롬프트 요지는 이랬습니다:

이번 과제는 평가가 아니라 정밀 관찰 서술이다.
화면에 실제로 보이는 것만 타임스탬프와 함께 서술하라.
편집으로 추가된 자막이 존재하는지, 화면 속 앱 UI 텍스트와 구분해서 답하라.
각 항목에서 안 보이면 '없음'이라고 명확히 답하라.
확신이 없으면 '판독 불확실'로 표기하라.

결과: 빨간 박스 아홉 개를 타임스탬프와 대상까지 전부 특정했고, 추가 자막은 "없음"으로 답했습니다.

실물과 일치하였고 오판독은 도구의 항상적 결함이 아니라 손상된 입력 + 평가형 프롬프트의 합작이었다는 게 확인됐습니다.

이 사건이 준 교훈이 있습니다.

입력 무결성 체크를 파이프라인 첫 단계로 둬야한다는 것입니다.

등록된 영상의 duration을 원본과 대조하는 것만으로 이 사고는 예방됩니다.

판독 신뢰도가 의심되면 평가 프롬프트가 아니라 관찰 프롬프트로 교정 테스트를 해야한다는 것 또한 배웠습니다.

"어때?"가 아니라 "뭐가 보여?"로 AI의 행위를 구체화했습니다.

정답을 가지고 있는 쪽이 정답을 숨기고 물어보는 것이 캘리브레이션의 기본이라는 것을 잊고 있었습니다.

실측된 신뢰 지도

한 달 운용으로 확정한 Jockey(TwelveLabs)의 신뢰 범위입니다.

제 사용례(한국어 강의 영상, 화면 녹화 + 내레이션) 기준이니 일반화는 조심스럽게 봐주세요.

신뢰 가능:

• 내용 및 구조 분석 (섹션 흐름, 설명 없이 지나간 용어, 정적 구간 위치)
• 딜리버리 평가 (말 끊김, 톤 변화 구간, 부분 재녹음 접합부가 티 나는지 판정한 게 실제로 유용했음)
• 편집 요소의 존재 여부 (온전한 파일 한정)

조건부:

• 타임스탬프 정밀도 (±수 초 오차, 구간 특정용으로는 충분)
• 전 구간 커버리지 (표본 기반이라 100% 열거는 안 됨, 정밀 관찰 지시로 밀도를 올릴 수는 있음)

불신:

• 한글 화면 문구 전사.
  "검증"을 "김충"으로, "시키려고"를 "시킴려고"로 읽었습니다.
  있는지는 검출하지만 내용은 틀리는 패턴이라, 오탈자 검수는 한번 더 진행해야 합니다.
• BGM 검출.
  클로징에 BGM을 깔았는데 세 편 연속 "오디오 확인 없음"으로 나왔습니다.
  발화 중심 모델의 한계로 보입니다.
• 다중 영상 환경에서의 귀속.
  같은 저장소에 비슷한 강의 영상이 여러 개 있으니,
  A 영상의 섹션 카드를 B 영상 분석에 귀속시키는 교차 오염이 발생했습니다.
  "반드시 이 영상만 대상으로 하라"는 명시로 완화는 되지만 완전히 개선되지는 않았습니다.

검증: 사람과 비교해봤을 때

파이프라인의 최종 시험은 사람과의 대조였습니다.

별도로 타겟 사용자(비개발 실무자) 콜드뷰어 테스트를 돌렸는데

AI가 선행 지적했던 항목들(화면 어디를 봐야 할지 모름, 오프닝 요약 부재, 트랜지션 이질감, 슬라이드 체류 부족)이

사람 피드백과 독립적으로 상당 부분 일치했습니다.

서로를 모르는 두 검수자가 같은 곳을 가리킨 셈이라

이 시점부터 AI 지적의 방향은 믿기로 했습니다.

재미있었던 건 마지막 QA였습니다.

슬라이드 체류 시간을 0.5초씩 늘린 수정본을, 수정 사실을 알리지 않고 재검수시켰습니다.

이전 검수마다 나오던 슬라이드가 빠르다는 지적이 이번엔 나오지 않았습니다.

사전 정보 없는 눈이 수정을 자연 통과시킨 것입니다.

블라인드 테스트가 성립한다는 뜻이고,

이게 되고나니 이 도구는 의견 내는 조수에서 재현 가능한 QA 장비가 돼버렸습니다.

정리

• 영상 AI 검수의 효용은 정답이 아니라 사람이 봐야 할 곳입니다.
  10시간짜리 정주행이 해당 지점만 확인하는 몇십 분의 시간으로 줄었습니다.
• 신뢰는 스펙시트가 아니라 실측으로 만들어야 합니다.
  내용과 방향은 신뢰, 존재 여부는 조건부로, 전사와 BGM 그리고 다중 영상 환경 또한 불신.
• 오판독을 만나면 버리지 말고 디버깅해야합니다.
  입력 무결성부터 체크
  평가가 아니라 관찰로 테스트
  도구의 한계선을 아는 도구가 제일 쓸모 있는 도구입니다.
• 그리고 확정은 끝까지 사람이 해야합니다.
  AI는 여기 이상함까지만 나오고 출시 가능은 눈으로 확인해야 했습니다.

이 파이프라인으로 검수한 강의는 10월에 인프런에 엽니다.
검수 대상이었던 강의가 하필 "AI 산출물을 검수하는 법"을 가르치는 강의라는 게 만들면서 제일 마음에 들었던 재귀 구조입니다.

이 검수 파이프라인을 통해 만들고 있는 것은 AI 산출물을 검수하는 법을 가르치는 강의입니다.
노션과 클로드 데스크톱만으로 기획하고, 디자인하고, 코딩해서
실제 동작하는 웹 앱 하나(흩어진 자료를 모아 분류하는 LLM 위키)를 완성하는 과정 전체를 보여주는 강의입니다.

AI가 틀리는 장면과 그걸 잡아내는 과정까지 자르지 않고 강의에 녹여냈습니다.

이 글에서 한 일을 강의 안에서도 똑같이 합니다.

10월에 인프런에서 엽니다. 먼저 소식 받아보실 분은 구글 폼에 남겨주세요.

지난 글에서 기획자와 PM이 바이브 코딩에 특히 유리하다고 작성했습니다.

요구사항 정의
스코프 관리
리뷰와 피드백

본체가 되는 능력을 이미 갖고 있으니까요.

그런데 한 가지를 짚고 넘어가야 합니다.

여러분이 가장 자신 있는 기술인 기획서 작성은 AI 앞에서 습관 하나를 바꿔야 합니다.

개발자는 되묻고, AI는 채운다

기획서를 개발자에게 넘겼을 때를 떠올려보세요.

문서에 빈칸이 있으면 어떻게 되던가요.

"파일 용량 제한은 없나요?"
"이름 겹치면 덮어써요, 아니면 막아요?"
"실패하면 유저한테 뭐라고 보여줘요?"

질문이 돌아옵니다. 귀찮았겠지만, 그 질문들이 사실 안전망이었습니다.

여러분의 빈칸을 사람이 막아주고 있었던 것입니다.

십수 년 일하며 우리가 "기획서는 어차피 대화로 완성된다"고 배운 이유죠.

AI는 다릅니다.

AI는 되묻는 대신 홀로 채웁니다.

빈칸을 만나면 멈추지 않고, 가장 그럴듯한 값으로 메꿔서 완성된 결과물을 가져옵니다.

문제는 그 "그럴듯한 값"이 여러분의 의도가 아니라 확률이라는 것입니다.

그리고 결과물이 워낙 매끈해서, 뭐가 채워졌는지 티가 안 난다는 것은 부가적으로 따라오는 이슈입니다.

빈칸이 질문으로 돌아오면 사고를 막을 수 있습니다.

반대로 빈칸이 소리 없이 채워지면, 사고가 나도 사고인 줄 모릅니다.

실제로 겪은 일

강의를 만들면서 AI에게 파일 업로드 기능을 시킨 적이 있습니다.

요구사항을 꽤 자세히 적었다고 생각했습니다.

드래그 앤 드롭으로 올리고,

지원 안 하는 확장자는 거르고,

용량 제한도 걸고.

AI는 깔끔하게 만들어왔습니다.

화면도 예뻤고,

거부 처리도 잘 됐습니다.

그런데 작업 브리핑을 읽다가 한 문장이 걸렸습니다

"이 단계는 서버 왕복 없이 전부 클라이언트 안에서 처리됩니다."

풀어 쓰면 업로드한 파일을 브라우저가 들고만 있고, 어디에도 저장하지 않는다는 뜻이었습니다.

제 기획서에 "파일을 어디에 저장한다"가 없었던 겁니다.

개발자였다면 "이거 저장은 어디로 가요?"라고 물었을 빈칸을

AI는 "일단 안 저장하는 걸로" 채워서 완성해온 것입니다.

겉보기엔 멀쩡히 동작하는 화면과 함께 말입니다.

빈칸은 제 것이었습니다. AI는 시킨 대로 시킨 만큼만 했습니다.

그래서 기획 습관을 이렇게 바꿉니다

이 차이를 알고 나면 고칠 것은 하나입니다.

사람에게 넘길 때는 넘어갔던 것을 AI에게 넘길 때는 기획 단계에서 꼼꼼하게 닫아야 합니다.

제가 AI를 사용하는 방법은 거창하지 않습니다.

작업서를 전달하기 전에 한번 더 검토할 뿐입니다.

"실패하면?"

이 기능이 안 됐을 때 어떻게 할지. (AI 호출이 실패하면? 파일이 너무 크면?)

"중복되면?"

같은 처리를 두 번 하면 어떻게 할지. (같은 이름의 파일이 또 올라오면?)

"끝나면?"

이 기능이 "됐다"의 기준을 적었나. (파일 10개를 올리면 목록에 뜬다)

특히 마지막 질문은 있느냐 없느냐가 검수 가능 여부를 가릅니다.

이건 새로운 기술이 아닙니다.

시니어 기획자들이 주니어 기획서를 리뷰할 때 하는 바로 그 질문들이에요.

예외 처리, 엣지 케이스, 완료 조건. 여러분이 이미 아는 개념입니다.

달라진 것은 하나입니다.

이 질문을 대신 해주던 개발자가 이제 없다는 것.

그 역할이 여러분 안으로 들어와야 합니다.

그리고 한 가지 더. 다 못 닫아도 괜찮습니다.

저도 저장 위치를 놓쳤으니까요.

대신 결과물을 받으면 검토 단계에서 "내가 안 적은 걸 얘가 뭘로 채웠지?"를 찾습니다.

빈칸을 미리 다 막는 게 아니라,

뭘로 채워졌는지 추적 가능한 상태를 유지하는 겁니다.

그게 안 되는 순간부터가 진짜 사고입니다.

정리

• 개발자는 기획서의 빈칸을 질문으로 돌려주고, AI는 그럴듯한 것으로 채워서 돌려줍니다.
• 그래서 AI에게 넘기는 기획서는 "실패하면 / 중복되면 / 끝나면" 세 질문을 스스로 통과해야 합니다.
• 이건 새 기술이 아니라, 여러분이 리뷰 때 이미 쓰던 질문의 방향을 자기 문서로 돌리는 일입니다.

지난 글의 결론에 한 줄을 보태며 마칩니다.

기획자와 PM은 바이브 코딩의 적임자가 맞습니다.

되물어주는 사람이 사라진 자리에서, 스스로 되묻는 습관까지 갖추면 말입니다.

이 생각이 맞는지 확인하려고, 직접 강의를 만들고 있습니다.

노션과 클로드 데스크톱만으로 기획하고, 디자인하고, 코딩해서

실제 동작하는 웹 앱 하나(흩어진 자료를 모아 분류하는 LLM 위키)를 완성하는 과정 전체를 보여주는 강의입니다.

AI가 제 빈칸을 뭘로 채웠는지 찾아내고 바로잡는 장면까지 자르지 않고 강의에 녹여냈습니다.

10월에 인프런에서 엽니다. 먼저 소식 받아보실 분은 구글 폼에 남겨주세요.

바이브 코딩 이야기가
나올 때마다 반복되는 문구가 있습니다.
"이제 누구나 만들 수 있다."

저는 이 말이 반만 맞다고 생각합니다. 그리고 반만 맞는 말은 아무도 움직이지 못합니다.

"누구나"는 곧 "내가 어떻게 하는데?"로 읽히니까요.

14년간 개발자로 지내오며 기획자, PM, 아티스트와 일해온 사람으로서, 더 정확한 문장을 제안하고 싶습니다.

"누구나"가 아니라, 기획자와 PM이 특히 잘할 수밖에 없습니다. 개발자보다 유리한 지점이 있습니다.

AI에게 일 시키기 = 여러분이 매일 하는 일

AI로 뭔가를 만드는 과정을 뜯어보면 이렇게 됩니다.

뭘 만들지 정의하고,

범위를 자르고,

나온 결과물을 검토해서 다시 시키는 반복.

이걸 실무자의 언어로 다시 쓰면:

요구사항 정의
스코프 관리
리뷰와 피드백

여러분이 매일 하는 일입니다.

개발자에게 기획서를 넘기고,

"이번 스프린트엔 여기까지만"을 정하고,

나온 빌드를 보고 "의도랑 다른데요"를 짚어내는 일 말입니다.

바이브 코딩은 이 상대가 개발자에서 AI로 바뀐 것뿐입니다.

오히려 AI는 밤에도 일하고, 기분이 상하지 않고, 다시 시켜도 한숨을 쉬지 않죠.

실제로 제가 강의를 만들면서 AI와 주고받은 결정들은 전부 이런 것들이었습니다.

"이 작업 단위가 다른 것들에 비해 너무 뚱뚱하다, 쪼개자."
"이 기능은 이번 범위에서 빼자."
"네가 정리한 계획, 사용자 흐름이 통째로 빠져 있는데?"

코딩 지식으로 내린 결정이 하나도 없습니다.

전부 기획 판단입니다.

그리고 이 판단이 결과물의 품질을 갈랐습니다.

코딩이요? 코딩은 AI가 합니다. 그게 바이브 코딩의 정의입니다.

그런데 왜 다들 막히는가

여기까지 읽으면 반문이 나올 겁니다.

"그렇게 쉬우면 왜 내 주변 사람들은 다 하다가 포기했는데?"

제가 비개발 직군 지인들을 관찰하며 확인한 병목은 두 개였습니다.

그리고 둘 다 능력의 문제가 아니었습니다.

먼저 말씀드릴 것은 도구입니다.

바이브 코딩 자료 대부분이 검은 터미널 화면과 마크다운 문서에서 시작합니다.

내용을 배우기 전에 도구에서 이탈하는 거죠. 그런데 이건 우회로가 있습니다.

저는 거의 모든 작업을 노션과 클로드 데스크톱 안에서 진행합니다.

이미 쓰고 있는 도구 두 개만으로도 전체 사이클이 돌아갑니다.

도구 문제는 사실 문제가 아니었던 겁니다.

다음 병목이 진짜입니다. "키워드"

아는 단어만큼만 시킬 수 있다

두 사람이 같은 화면을 만들려고 합니다.

파일을 끌어오면 화면 전체가 살짝 어두워지면서 "여기 놓으세요"가 뜨는,

요즘 흔한 그 업로드 화면이요.

A는 이렇게 시킵니다.

"파일을 끌고 오면 화면이 어두워지고 아무 데나 놓아도 올라가게 해줘."

B는 이렇게 시킵니다.

"창 전체를 드롭존으로 하고, 드래그 진입 시 딤드 처리해줘."

둘 다 같은 걸 원했지만,

결과물의 정확도는 다르게 나옵니다.

B가 코딩을 더 잘해서가 아닙니다.

드롭존과 딤드

그 화면을 부르는 단어를 사용했을 뿐입니다.

AI에게 일을 시킬 때의 냉정한 규칙은 아는 단어만큼만 시킬 수 있다는 것입니다.

머릿속 그림이 아무리 선명해도, 그걸 입력하는 명칭을 모르면 AI와 나 사이에서 뭉개집니다.

반대로 명칭을 정확히 입력하는 순간, AI는 놀랄 만큼 정확해집니다.

이게 기획자와 PM에게 남은 마지막 한 조각입니다.

능력이 아니라 키워드입니다.

키워드는 학습이 아니라 온보딩이다

"결국 뭘 배우긴 해야 하네"라고 느끼실 수 있는데 정확히 말씀드리고 싶습니다.

개발을 배우는 것이 아닙니다.

문법도, 자료구조도 없습니다.

필요한 건 단어 수십 개입니다.

드롭존, 딤드, LNB 같은 쉬운 것들부터

포트, 라우터 같은 기술적인 부분들까지

여러분들이 이미 경험해본 일입니다.

게임 개발을 처음 마주쳤을 때 밸런싱, 빌드, QA라는 단어를 익혔고,

이직할 때마다도 그 팀의 용어를 익혔을 것입니다.

새 직무를 배운 게 아니라 새 팀에 온보딩한 거죠.

개발 키워드도 정확히 그 급의 과제입니다.

낯선 직무가 아니라 낯선 팀.

그리고 여러분은 온보딩을 십수 번 해본 사람들입니다.

모르는 키워드가 나오면 어떻게 하냐고요?

그 자리에서 AI에게 물으면 됩니다.

실제로 저는 강의를 만들다가 학생분들이 모를 것 같은 용어가 나와 작업을 멈추고 클로드에게 물었습니다.

"이게 뭐야? 비개발자도 알아듣게 설명해줘."

설명을 확인하고, 내가 아는 것에 대입해 본 다음, 그 다음에 결정합니다.

키워드 사전을 외우고 시작하는 게 아니라, 현장에서 한 개씩 채우면서 갑니다.

온보딩이란 원래 그렇게 하는 거니까요.

정리

• 바이브 코딩의 본체는 요구사항 정의, 스코프 관리, 검토와 피드백입니다. 이것은 기획자와 PM이 이미 가진 능력입니다.
• 코딩은 AI가 합니다.
• 남은 건 키워드 수십 개이고, 그건 새 직무 학습이 아니라 새 팀 온보딩 수준의 과제입니다.

그래서 "누구나 할 수 있다"는 말을 이렇게 고쳐 쓰고 싶습니다.

여러분이 특히 잘할 일인데, 아직 그 팀의 단어를 못 배웠을 뿐이라고요.

이 생각이 맞는지 확인하려고, 직접 강의를 만들고 있습니다.

노션과 클로드 데스크톱만으로 기획하고, 디자인하고, 코딩해서

실제 동작하는 웹 앱 하나(흩어진 자료를 모아 분류하는 LLM 위키)를 완성하는 과정 전체를 보여주는 강의입니다.

모르는 키워드가 나올 때마다 멈춰서 묻고 넘어가는 장면까지 자르지 않았습니다.

10월에 인프런에서 엽니다. 먼저 소식 받아보실 분은 구글 폼에 남겨주세요.

임베딩은 진위를 가리지 않고,
유사도를 잽니다.
검수는 검색 뒤가 아니라,
저장 앞에 세웠습니다.

영상을 만드는 이야기는 지난 편에서 일단락 됐습니다. raw 영상 아홉 개가 4분 만에 내레이션 붙은 숏폼이 되는 파이프라인이었습니다. 이제 상담 봇을 제작할 차례입니다.

"다른 강아지랑 잘 지내나요?"

입양 문의입니다. 영상은 관심을 만들고, 관심은 질문이 됩니다. 질문에 답하려면 그 강아지에 대한 기록이 필요하고, 기록을 담을 저장소가 필요합니다. 그래서 2부의 첫 작업은 봇이 아니라 DB입니다. 이번 편은 Postgres + pgvector + bge-m3로 로컬 RAG 저장소를 설정하고, 영상 아홉 개를 인제스트 해서 위 질문에 타임스탬프 붙은 관찰 기록이 검색되기까지의 기록입니다.

python -m rag.cli search tori "다른 강아지랑 잘 지내나요?" --card

RAG를 붙이면 환각이 해결되지 않을까?

이번 함정은 그 기대 자체에 있습니다. RAG의 약속은 "문서에 근거하여 답한다"입니다. 그런데 이 약속에는 전제가 하나 숨어 있습니다. 문서가 사실이어야 한다. 이 시스템의 문서는 사람이 쓴 글이 아니라 기계가 영상을 보고 적은 텍스트입니다. 캡션, 행동 서술, 그리고 그것들을 묶은 요약이죠. LLM이 지어낸 문장이 DB에 한 번 들어가면 검색은 그 문장을 성실하게 찾아주고, 봇은 자신 있게 인용합니다. 임베딩 점수가 아무리 높아도 그건 질문과 비슷하다는 뜻이지, 사실이라는 뜻은 아닙니다.

그래서 이번 편의 규칙은 검색 튜닝이 아니라 저장 규칙입니다.

문장의 출처로 저장 위치를 정한다.
LLM이 문장을 만드는 곳은 한 곳이고,
그 문장은 검수를 통과해야 저장된다.

20. 출처로 저장 위치를 정한다 - 스키마 설계

구축 자체는 별 것 없었습니다. Postgres는 이미 설치해두었고, pgvector를 얹어 CREATE EXTENSION vector 한 줄을 호출했습니다. 임베딩은 Ollama의 bge-m3를 사용했습니다. "잘 지내나요?"라는 한국어 질문과 한국어 관찰 기록을 같은 벡터 공간에 놓아야 하다보니 다국어 임베딩이 필요해서 선택했습니다. 클라이언트는 기존 venv의 psycopg2와 ollama 그대로라 추가 파이썬 의존성 0으로 로컬 스택은 1부에서 세운 그대로입니다. 구성은 schema.sql, db.py, embed.py, ingest.py, retrieve.py, cli.py(init / card / ingest / search)입니다. 단위 테스트 11개도 추가되었습니다.

추가적인 설계가 들어간 곳은 스키마입니다. 발단은 사소한 질문이었습니다.

"할루시네이션이 걱정되니 텍스트에 LLM 저작이 얼마나 섞였는지, 비율을 메타데이터로 넣을까?"

출처를 연속값 컬럼으로 기록하자는 발상인데, 구상 끝에 결정을 바꿨습니다. 인제스트하는 시점에 코드는 이 텍스트가 어디서 왔는지 이미 알고 있습니다. 그 사실을 컬럼에 다시 적는 건 군더더기고, 비율이라는 연속값은 "이 문장을 믿어도 되는가"라는 이진 질문에 답하지 못합니다. 대신 출처로 저장 위치를 구분했습니다.

L2는 코드가 조립합니다. 행동 서술에는 인용 타임스탬프를 붙이고(신뢰도 0.7 이상, 비uncertain 구간 중 최고 신뢰도), 확정된 장면 태그를 합칩니다. 6편에서는 필드의 소유권으로 갈랐다면, 이번에는 문장의 저자로 가른 셈입니다.

노출도 통제했습니다. 카드 필드는 3단 가시성이라 구조 위치 같은 스태프 정보는 검색에 나오지 않고, 민감한 필드는 순화본만 노출됩니다. e2e에서 게이팅이 그대로 작동하는 것까지 확인했습니다.

21. LLM의 문장은 검수를 통과해야 저장된다 - L1 요약

L1은 강아지 한 마리의 관찰 전체를 묶은 요약입니다. "활발하고 다른 개들과 잘 어울립니다" 같은. 상담 봇 입장에서 가장 쓰기 좋은 텍스트지만, 동시에 이 저장소에서 유일하게 LLM이 지어낼 수 있는 텍스트입니다. 그래서 저장 전에 관문을 세웠습니다.

절차는 이렇습니다. Gemma가 요약을 쓰고(temperature 0.2, 프롬프트는 지시만 — 6편의 규칙 그대로) → 요약을 주장 단위로 분해 > 주장마다 관찰 기록과 대조 > 근거 없는 주장은 증거 범위로 제한해 재작성 > 그래도 근거 미달이면 드롭. 요약이 통째로 비어도 시스템은 무너지지 않습니다. L2와 카드가 남으니까요. 요약은 편의성을 위한 것이지 진실의 원천이 아닙니다. 위층이 무너져도 아래층이 받치는 안전한 저하 구조입니다.

검수 기능은 새로 만들지 않았습니다. 자막 사실 검수에 쓰던 기능(주장 분해, 근거 대조)을 파이프라인에서 그대로 import 했습니다.

판정 단위는 한 번 나눴습니다. 자막 검수는 all-fit입니다. 블록에 들어간 모든 소스가 주장을 받쳐야 통과합니다. 하지만 L1은 강아지 전체의 요약이라 **기록이 하나라도 맞다면 근거(any-fit)**로 정했습니다. "다른 강아지와 잘 논다"는 주장은 아홉 영상 중에서 한 영상에서만 특정 되어도 성립하니까요.

그리고 e2e에서 이 관문이 실제로 발동했습니다.

• "고양이와 서로 마주 보고 앉아 있음", 사교성의 근거로 미달 판정.
• "움직임 없이 정지해 있는 상태", 안정성의 근거로 미달 판정.

둘 다 그럴듯합니다. 마주 보고 앉아 있으면 사교적인 것 같고, 정지해 있으면 안정적인 것 같죠. 검수 기능은 그 동의어 경계에서 보수 쪽으로 판정했고, 두 문장은 증거 범위로 재작성된 뒤에야 통과했습니다. 정밀도를 우선하였기에 설계 의도는 그대로였습니다. 입양 문의에 답하는 시스템에서 "그럴듯한데 근거 없는 말"은 가장 비싼 오류입니다.

22. 신뢰 경계는 DB 앞까지 - 게이트와 멱등

저장 규칙만큼 중요한 것이 게이트입니다.

첫째, re-ID 게이트. 잡에 재식별 미확정(foster_uncertain)이 남아 있으면 인제스트 자체를 거부합니다. 1부에서 재식별을 카드 한 장, 탭 한 번으로 확정하게 만들었는데, 그 신뢰 경계가 DB 입구까지 연장된 겁니다. 누구의 것인지 확정되지 않은 관찰은 그 강아지의 기록이 될 수 없습니다. "일단 넣고 나중에 지우자"는 없습니다. 지우는 걸 잊는 날이 오니까요.

둘째, 재인제스트 멱등. video_id는 소스 파일명입니다. 같은 영상을 다른 잡에서 다시 인제스트하면 중복이 아니라 갱신입니다. 영상 분석은 업서트, L2는 그 영상의 청크를 지우고 재삽입, L1은 그 강아지 전체를 재생성합니다. 실측으로 확인했습니다. 같은 잡을 두 번 인제스트한 전후 행 수가 동일합니다. 유저 요청 원문은 저장하지 않아서 요청에서 유래하는 데이터는 자동 장면 태그가 유일하고, 그것도 set 병합이라 누적되지 않습니다.

한계도 적어두겠습니다. 파일명이 곧 정체성이라, 다른 푸티지가 같은 파일명으로 오면 중복이 아니라 덮어쓰기가 됩니다. 영상이 본격적으로 누적되는 운영 전에 콘텐츠 해시 같은 정체성 강화가 필요합니다. 나중에 구현할 수 있도록 남겨뒀습니다.

셋째, 재집계는 DB 기반. L1 재생성은 잡 디렉토리가 아니라 DB에 쌓인 영상 분석을 읽습니다. 잡 폴더를 정리해도 요약은 다시 만들 수 있고, 영상이 쌓일수록 요약이 두꺼워집니다. 임시 산출물과 축적 데이터의 경계를 여기서 그었습니다.

23. "모른다"는 분포에서 나온다 - 검색 스모크

인제스트 결과는 영상 9개 → L2 18청크, L1 4청크. 여기에 질문 네 종류를 던졌습니다.

• 사교성 질문("다른 강아지랑 잘 지내나요?") > 놀이 장면 관찰 2건이 타임스탬프와 함께 상위(0.56~0.57), 활동성 요약이 뒤따름.
• 고양이 질문 > 고양이 관찰 기록이 1위.
• 산책 질문 > 장면 태그가 합류된 산책 영상들.
• 그리고 개인기 질문, 기록에 없는 것. 최고 점수 0.44로 낮게 깔렸습니다.

네 번째가 이번 스모크의 핵심입니다. 있는 것을 찾는 것은 임베딩의 기본기지만, 없는 것을 물었을 때 점수가 낮게 깔리는 분포여야 상담 봇이 임계값 하나로 관찰 기록이 없다고 답할 수 있습니다. 봇의 정직함은 화법에서 나오는 것이 아니라 이러한 분포에서 나옵니다. 아는 것과 모르는 것 사이에 점수 간격이 있어야 모른다는 것을 구현할 수 있게 됩니다.

테스트는 11개가 추가됐습니다. RAG는 파이프라인의 산출물을 읽기만 하는 별도 컴포넌트로 구축하였습니다.

다만 시리즈의 기준으로 보면 스모크는 스모크입니다. 검색 품질도 골든셋으로 채점하는 일이고, 질문과 정답 쌍을 손으로 만들어 bge-m3의 검색을 점수화하는 일은 아직 하지 않았습니다. 관찰 서술이 장면 단위라서 다견 영상의 무리 행동("여러 마리가 뒤엉켜 놀음")이 개체 귀속 없이 남는 것도 한계입니다.

맺음말

DB 하나를 설정하는 데 하루가 걸렸고, 규칙은 네 개였습니다.

• 출처를 고정합니다. 카드는 사람, L2는 관찰 원문, L1만 LLM — 저작 텍스트는 DB 밖.
• LLM의 문장은 검수를 통과해야 저장됩니다. 주장 분해 > 기록 대조 > 재작성 1회 > 드롭. e2e에서 실제로 두 건을 잡았습니다.
• 신뢰 경계는 DB 앞까지입니다. 재식별 미확정이면 인제스트 거부, 재인제스트는 멱등.
• "모른다"는 분포로 준비합니다. 무관 질문이 0.44로 깔리는 간격이 상담 봇 정직함의 재료입니다.

시리즈의 문장에 하나를 보탭니다. 골든셋으로 채점하고, 측정할 수 있는 것은 측정에게 맡기고, 구조의 주인을 하나로 세우고, 빠르게 만들 때조차 자부터 검증한다. 그리고 DB에 넣기 전에, 출처부터 고정한다.

다음 편은 이 저장소 위에 서는 상담 봇입니다. 검색된 기록을 어떤 화법으로 인용할지, 카드·요약·관찰 원문에 각각 다른 말투를 줄지, 그리고 점수가 임계 아래일 때 "모른다"를 어떻게 말하게 할지. 저장이 정직해졌으니, 이제 다음을 구현하면 됩니다.

이전글

관련글

raw 폰 영상 아홉 개와 요청 한 문단.
약 4분 뒤, 내레이션이 붙은 세로 숏폼 하나.
그 사이의 모든 판단을 맥 한 대 안에서, 이 결과물이 나오게 됐습니다.

이 글은 그 파이프라인을 만든 7편의 기록에 대한 요약입니다.

"유기견 입양에 AI를 붙였다"가 가리는 것

보통은 이렇게 떠올립니다. 모델에 영상을 던지면, 알아서 편집되고, 그럴듯한 게 나온다. 데모 하나는 그럭저럭 나옵니다. 틀린 말은 아닙니다.

하지만 그 출발점은 정작 중요한 두 질문을 가립니다.

• 내일 똑같이 다시 뽑을 수 있는가? (재현)
• AI가 지어낸 것과 사람이 정한 것이 섞이지 않는가? (신뢰)

단순한 LLM 데모는 이 둘에 답하지 않습니다. 이 시리즈는 이 두 질문에 답하려고 내린 결정들의 기록입니다.

한 문단으로

• LLM은 레시피만 씁니다. 실행은 코드가 합니다. 그래서 LLM이 환각을 뱉어도 실행 단계에서 격리됩니다. (temperature 0 + 스키마 강제 + 허용셋 밖 라벨은 거부)
• 모델은 갈아끼우는 부품, 골든셋은 그 부품을 채점하는 기준입니다. 눈으로 하는 데모 비교 대신, 정답을 손으로 계산해 대조하는 단위테스트 130여 개 위에서 결정을 내렸습니다. 실제로 당연히 먹힐 것이라고 여겼던 개선안들이 골든셋 채점에서 두 번이나 기각 당했습니다.
• 가능한 많은 것을 외부 API가 아니라 맥 한 대 안에 둡니다. 데이터가 매 호출마다 밖으로 나가지 않고, 호출 비용이 없고, 통제권이 제 손에 남습니다.
• 자동화가 못 믿는 딱 그 지점에만 사람을 남깁니다. 재식별은 90%를 자동으로 하고, 애매한 나머지는 카드 한 장·탭 한 번(영상당 1.75탭 실측)으로 끝냅니다. "AI가 다 한다"보다 정직하고, 실제로 더 잘 작동했습니다.

이건 강아지 영상 이야기가 아닙니다

도메인은 강아지였지만, 만든 것은 신뢰할 수 있는 로컬 AI 파이프라인을 세우는 방법론입니다. 골든셋으로 채점하는 법, LLM과 코드의 권한을 가르는 법, 환각을 격리하는 법, 빠르게 만들 때조차 결과 동일성부터 지키는 법. 이 규칙들은 영상 도메인에 묶여 있지 않습니다. 입력이 픽셀이든 문서든 로그든, 옮겨 붙습니다.

그래서 이 글은 두 부류를 위한 것입니다. 데모가 아니라 내일도 똑같이 도는 시스템을 만들어야 하는 사람. 그리고 no-code 위에서 뭔가 만들었는데 왜 두 번째 입력에서는 안 되는지 답답한 사람.

7편 링크

1. 맥 로컬 LLM 구축, 무엇을 내 손 안에 두고, 무엇만 밖에 맡길 것인가. 노트북 한 대에 세운 환경.
2. 로컬 LLM 아키텍처, 왜 로컬인지, 왜 이 구성인지. 선택의 이유.
3. YOLO11 해상도 함정, 정답지부터 만들고 모델을 붙인다. 해상도를 올렸더니 오히려 나빠진 이야기.
4. 결정론적 AI 파이프라인 설계, 같은 입력이면 같은 출력. 창작만 예외로 두되, 그 창작에도 가드를 건다.
5. 로컬 TTS로 타임라인 컨트롤, 대본을 음성으로, 음성을 영상 타임라인에 맞추기.
6. LLM은 지시만, 프롬프트에 내용을 넣으면 출력으로 샌다. 같은 문제를 네 번 고치고 얻은 규칙.
7. 스레드보다 자원, 8분을 4분으로. 가장 큰 배수는 멀티스레딩이 아니라, 놀고 있던 GPU를 깨운 한 줄에서 나왔습니다.

정직하게 남겨둘 것

이 검증들은 서로 다른 다섯 개의 영상으로 만든 골든셋에서 이뤄졌습니다. 도메인은 하나, 혼자서 진행했습니다. 그래서 이 기록은 이 방법이 모든 곳에서 최고라는 것이 아닙니다. 이 방법이면 만든 것을 믿을 수 있고, 부품을 갈아끼워도 기준이 흔들리지 않는다는 것입니다. 방법론의 엄밀함이지, 규모의 검증은 아닙니다. 그 경계를 넘는 건 다음 도메인의 몫입니다.

이전글

관련글

파이프라인을 빠르게 만드는 첫 질문은
"스레드를 몇 개 띄울까?"가 아니라
"어떤 자원이 어디서 놀고 있나?"입니다.

 

"느리면 그냥 멀티스레딩 돌리면 되는 거 아냐?"

 

이번 함정은 그 직관이 절반만 맞다는 데 있습니다. 스레드를 늘려도 공유 자원 앞에서는 줄만 서기 때문에 안 빨라지는 구간이 있습니다. 스레드와 무관하게 놀고 있던 자원(GPU)도 있습니다. 심지어 빨라졌는지 판정하는 것조차 같은 코드 실행에도 실행 속도가 2배 차이가 될 수 있는 함정이 있습니다. 이번 최적화로 자동 영상 편집에 8분 걸리던 파이프라인을 4분으로 줄였는데 결론부터 말하면 가장 큰 배수는 멀티스레딩이 아닌 한 줄 수정에서 나왔습니다.

 

스레드보다 먼저 자원의 지도를 그린다.
겹칠 수 있는 것만 겹치고,
결과는 완전히 동일해야 한다.

 

이번 편은 실사용 병목 3구간(전처리+검출, 관찰 프로필, 동작 판정)의 속도 최적화 기록입니다. 원칙은 하나로 요약됩니다. 단계 간 직렬은 유지하고, 단계 안에서만 병렬화한다. 파이프라인의 순서와 게이트 구조는 건드리지 않았습니다.

 

---

16. 스레드보단 자원을 살펴보자 - 다섯 개의 자원

병렬화를 시작하기 전에 파이프라인이 쓰는 자원부터 그렸습니다. 다섯입니다. Ollama(Gemma, GPU), MLX(TTS, GPU), MPS(YOLO, GPU), ffmpeg(CPU 서브프로세스), OpenCV / Torch(CPU). 지도를 그리고 나니 제일 중요한 사실이 보였습니다. Ollama는 서버가 요청을 직렬로 처리하는 공유 자원입니다. 클라이언트에서 스레드를 아무리 늘려도 서버 앞에서 줄만 섭니다.

 

그래서 이번 최적화의 이득은 전부 한 곳에서 나왔습니다. Ollama 작업과 비-Ollama 작업을 겹치는 것. LLM이 크롭 하나를 판정하는 동안 CPU는 다음 영상의 모션 곡선을 계산하고, ffmpeg는 다음 영상을 정규화합니다. LLM을 빠르게 만든 게 아니라, LLM이 일하는 동안 다른 자원이 놀지 않게 만든 겁니다.

 

병렬화에도 안전을 위한 규칙을 먼저 세웠습니다. 병렬 구간은 meta파일을 만지지 않고 쓰기는 오케스트레이터가 루프 밖에서 한 번, 판정 로직은 입력이 전부 모인 뒤의 직렬 흐름 그대로 두고, 완료 순서는 비결정이어도 조립은 인덱스로 고정합니다. 그리고 합격 기준은 속도가 아니라 결과 동일성입니다. 빨라졌는데 결과가 달라졌다면 그건 최적화가 아니라 버그니까요.

---

17. 최대 병목은 병렬화가 아니었다 - 놀고 있는 GPU

전처리(ffmpeg)와 검출(YOLO)을 파이프라이닝했습니다. 영상 i를 검출하는 동안 영상 i+1을 정규화하는 구조는 교과서적인 이종 자원 오버랩입니다. 그런데 체감이 없다는 피드백이 왔습니다.

 

구간별 비중을 실측해 보니 범인은 따로 있었습니다. 검출 모델이 내내 CPU로 돌고 있었습니다. Mac에서 이 라이브러리의 디바이스 자동 선택은 GPU가 아니라 CPU였습니다. Apple GPU(MPS)를 쓰려면 명시해야 했습니다. 그래서 한 줄을 고쳤습니다. 157.9초 → 45.4초, 3.5배. 이번 최적화 전체에서 가장 큰 배수가 스레드 하나 없이 나왔습니다.

 

물론 검증은 시리즈의 규칙대로입니다. 골든셋 5영상을 GPU로 재검출해 재채점하여 박스 수, 트랙 수, miss/IDF1을 포함한 모든 지표가 소수 4자리까지 완전 동일했고, 게이트 판정도 그대로였습니다(예외 처리된 나쁜 footage의 FAIL까지 똑같이). 디바이스가 바뀌어도 자는 휘지 않았다는 확인입니다.

 

비슷한 사례가 하나 더 있었습니다. 모션 곡선이 프레임마다 랜덤 시크로 영상을 읽고 있었는데 랜덤 시크는 매번 키프레임부터 다시 디코드했습니다. 순차 읽기로 바꾸자 영상별로 4.6 -> 0.8초, 11.9 -> 1.7초, 약 6배. 이것도 병렬화가 아니라 직렬 최적화입니다. 교훈을 한 문장으로 정리하자면, [구조를 바꾸기 전에, 자원이 제대로 쓰이고 있는지부터 확인하라.] 였습니다.

---

18. 겹치기의 산수 - 비용을 서로의 뒤에 숨긴다

자원 지도가 그려지고 GPU를 활용한 뒤에야 오버랩이 값을 하기 시작했습니다. 세 구간입니다.

• 전처리 || 검출 — ffmpeg(CPU)가 다음 영상을 정규화하는 동안 YOLO(GPU)로 현재 영상을 검출했습니다. 전처리 비용이 검출 뒤에 숨어, 준비 구간이 50.7초에서 17.1초(3배)로 줄었습니다.
• 관찰 프로필 — 영상마다 캡션(Ollama, 직렬)과 센서 4축(오디오, 배경, 장소, 휘도, CPU)을 뽑는데 센서를 영상 간 병렬로 팬아웃시켰고 총시간이 캡션 합 + 센서 합에서 max(캡션 합, 센서 합)으로 바뀌면서 센서 비용을 통째로 은닉시켰습니다.
• 동작 판정 — 모션 계산(CPU)을 팬아웃하고 LLM 판정만 직렬로 했습니다. 모션의 비용이 판정 뒤로 숨었습니다.

스레드가 들어오면서 따라오는 숙제도 처리했습니다. 모델 지연 로딩 3곳에 이중 확인 락(같은 모델을 두 번 로드해 메모리가 2배가 되는 사고 방지), 병렬 워커는 영상별 산출물 파일만 쓰기, 임시파일명에 인덱스 포함. 기존 테스트 102개는 전부 그대로 통과하였고 CLI와 같은 인터페이스는 하나도 안 바뀌었습니다. 병렬화는 전부 내부 구조입니다.

---

19. 단순 측정을 믿지 마라 - 분산부터 통제

마지막 함정은 측정 그 자체였습니다. 동작 판정 구간을 같은 입력으로 세 번 돌렸더니 28.1초, 22.9초, 14.3초. 같은 코드가 2배 차이 났습니다. Ollama 응답 시간의 분산이 구간 전체를 지배해서 한 번씩 재는 A / B 비교가 무의미해졌습니다.

 

실제로 두 번 속았습니다. 새 코드의 첫 실행이 옛 코드보다 느리게 나왔는데(9.7초 vs 10.7초) 첫 실행에 모델 로드와 Ollama 웜업이 섞여 있었습니다. 웜 상태로 다시 재니 7.8초(−20%)가 나왔습니다. 또 한 번은 22.9초(구코드)에서 28.1초(신코드)로 느려졌나 싶었는데 재실행에서 14.3초. 실행할 때마다 측정 결과가 달랐습니다.

 

그래서 판정 방법을 갈랐습니다. 결정론 구간(모션 곡선, 검출)은 조건을 맞춘 단발 A / B로 숫자를 재고, LLM이 섞인 구간은 단순 측정 대신 출력 동일성과 구조적 은닉(직렬 합이 max로 바뀌었다는 산수)으로만 판단합니다. 시리즈 첫 편에서 "자가 휘어 있으면 측정이 무의미하다"고 했는데, 마지막 편에서 하나 더 보탭니다. 분산을 통제하지 않은 단순 측정도 휜 자입니다.

---

맺음말

자동 영상 편집 1회 라이프사이클 기준, 총 8분이 4분이 됐습니다.

• 자원 지도를 먼저 그려 공유 자원(Ollama)과 겹칠 수 있는 자원을 가르고,
• 최대 배수(3.5배)는 스레드가 아니라 놀고 있던 GPU를 깨운 한 줄에서 얻고,
• 오버랩으로 전처리, 센서, 모션의 비용을 LLM 작업 뒤에 숨기고,
• 단순 측정의 분산을 통제해, 빨라졌다는 느낌 자체를 측정답게 만들었습니다.

그리고 이 모든 변경의 합격 기준은 속도가 아니라 결과 동일성이었습니다. 골든셋 지표 소수 4자리까지.

 

남은 부분도 있습니다. Ollama 서버 자체의 동시성, TTS와 렌더의 파이프라이닝. 하지만 raw 폰 영상 아홉 개와 요청 한 문단이 4분 만에 내레이션 붙은 숏폼이 되는 지금, 개발기로서의 이야기는 여기서 일단락하려 합니다. 골든셋으로 채점하고, 측정할 수 있는 것은 측정에게 맡기고, 소리도 채점하고, 구조의 주인을 하나로 세우고, 빠르게 만들 때조차 자부터 검증한다. 이 시리즈가 남긴 문장들입니다.

---

이 글에서 다룬 고정 함수 분류층은 ProjectDavid의 일부입니다.

전체를 바닥부터 만드는 과정은 강의 3부작으로 정리하고 있고, 10월에 오픈 예정입니다.

→ 오픈 알림 받기

---

다음글

이전글

관련글

요청이 짧다고 영상까지 짧아지면 안 됩니다.
빈칸은 LLM의 저작으로 채우고,
채워진 칸은 아무도 건드리지 않습니다.

우선 작업 결과부터 보고가겠습니다.

프롬프트

우리 토리 소개 영상 만들어줘

(애견카페 장면을 집에서 쉬는 장면으로 오해한 할루시네이션이 포함됨)

프롬프트

우리 토리 소개 영상 만들어줘 뛰어노는 모습 좀 나오다가 산책하고 밤에도 달리고 마지막에 하이파이브로 끝나면 딱이겠다

'소개 영상 만들어줘' 한 줄이면 알아서 잘 나와야 하는 것 아냐?

이번 함정은 파이프라인이 아니라 요청 쪽에 있었습니다. 한 줄 요청에는 구조 정보가 없습니다. 몇 블록으로, 어떤 순서로, 자막은 뭐라고, 아무것도 없죠. 지난 편까지의 파이프라인은 이 요청에 성실하게 답했습니다. 기본값 블록 하나, 소스당 한 컷씩 26초. 하지만 "소개 영상 만들어줘"라는 요청에는 소개 영상이 아니라 영상의 나열이 나왔습니다. 번역할 문장이 없으면 번역기는 구성을 못 합니다.

유저가 정하지 않은 것만 LLM이 저작하고,
유저가 정한 것은 LLM이 마음대로 건드리지 않는다.

잠시 배경 하나를 설명드리면 지난 편 이후 남았던 수동 단계 둘은 자동화로 풀었습니다. 영상마다 기계가 "무엇이 찍혔는지" 적어두는 관찰 프로필, 그리고 강아지 사진 몇 장으로 여러 마리 중 주인공을 확정하는 프레임 앵커. 덕분에 영상과 사진만 넣으면 결과가 나옵니다. 이번 편은 고정 형태의 파이프라인을 잘 만드는 파이프라인으로 다듬은 기록입니다. 한 줄 요청을 구성으로 바꾸는 저작 모드. 요청 디테일 천차만별에 대응하는 소유권 원칙. 그리고 실사용이 낸 숙제들. 결론부터 말하면 이번 구간에서 같은 문제를 네 번 고치고 나서야 규칙 하나를 얻었습니다. 프롬프트에는 지시만 적는다. 내용은 금지.

12. 한 줄 요청을 구성으로 - 저작 모드

편집의 구조가 요청에 없다면 어떻게 만들어야 할까요. 소재와 목적. 무엇이 찍혀 있는지(관찰 프로필)와 무엇을 원하는지(요청의 느낌)를 알면 구성은 만들 수 있습니다. 그래서 번역기 앞에 LLM을 다시 세웠습니다. 간단한 요청이 들어오면 LLM이 요청 원문과 영상별 관찰 프로필, 그리고 소재 길이를 보고 블록을 직접 구성합니다. 어떤 영상을 어떤 순서로, 몇 초씩, 자막은 뭐라고 할지 말이죠.

소재 길이를 입력에 넣은 건 실측 때문입니다. 길이를 모르는 LLM의 저작은 2.3초짜리 영상을 인트로와 엔딩 두 블록에 배치하는 실수를 했습니다. LLM에게도 재료의 속성은 알려줘야 합니다.

재미있는 결정 하나가 있습니다. LLM의 저작은 이 파이프라인 전체에서 유일하게 의도된 비결정입니다. 지금까지 "같은 입력 = 같은 출력"을 그렇게 지켜놓았지만 저작은 정답이 없는 주관 축이기 때문입니다. 같은 요청에서 매번 다른 구성이 나와도 되고, 마음에 안 들면 다시 뽑으면 됩니다(빠른 재추첨 옵션 추가). 결정론은 정답이 있는 곳의 규칙이지, 창작을 막으면 안되니까요.

다만 창작에도 결정론은 붙습니다. 작가가 지어낸 소재 이름은 실제 목록과 대조해 환각을 제거하고, 블록 길이와 개수는 Clamp하고, 배속은 [요청이 명시한 경우만]이라는 가드를 유지합니다. 실측 샘플로 "문틈 사이로 빼꼼! 우리 토리 등장!" 같은 자막이 나왔는데, 해당 영상의 관찰 프로필에 실제로 문틈 장면이 기록돼 있었습니다. 창작이되, 근거 있는 창작입니다.

13. 소유권은 이진, 빈칸은 Gradient - 요청 디테일 대응

실제 요청은 한 줄만 오지 않습니다. "소개 영상 만들어줘"부터, "뛰어노는 모습 나오다가 산책하고 밤에 달리고 하이파이브로 끝" 같은 스케치, 블록별 초와 자막까지 박은 풀 스펙까지. 디테일이 천차만별입니다. 처음엔 [요청이 얼마나 구조적인가]를 점수로 재려 했습니다. 잘못된 접근이었습니다. 구조는 결국 하나로 귀결돼야 합니다. 유저가 뼈대를 줬으면 구조는 유저 것이고, 안 줬으면 LLM이 저작합니다. Gradient인 건 구조가 아니라 빈 필드의 수입니다.

병합은 결정론입니다. LLM의 저작에서 유저가 명시한 필드는 아예 읽지 않습니다. "덮어쓰지 않도록 주의한다"가 아니라 읽는 코드 자체가 없는 구조적 불변입니다. 대본 스킵, 복창 사고와 같은 문제들이 재발하지 않도록 원천 차단한 겁니다.

텍스트는 한 단계 더 엄격합니다. 요청에 자막 지시가 하나라도 있으면 자막은 통째로 유저의 소유입니다. LLM은 빈 블록의 자막조차 채우지 않습니다. 절반의 자막을 유저가 썼는데 나머지 절반을 LLM이 채우면 유저의 의도가 사라질 수 있습니다. 덤으로 잠재돼있던 버그도 하나 잡았습니다. [자막 없이]라는 요청에 [자막]이라는 단어가 포함돼 있어서 오히려 자막을 채우던 것입니다. 부정 표현이 긍정 표현보다 우선한다는 원칙으로 수정했습니다.

14. 프롬프트에는 지시만 - 같은 문제만 네 번

이번 구간에서 제일 어려웠던 문제였습니다. 자막에 요청 전문을 그대로 발화하는 사고가 났습니다("…만들어줘"까지 통째로). 1차 수정은 결정론으로 필터링 했습니다. 출력에서 요청 문자열을 지우는 필터였습니다. 그런데 이건 단순히 표면적으로 문제를 지웠습니다. 실질적 문제는 프롬프트에 있었는데 말입니다. "요청의 말투를 그대로 살려서"라는 지시가 사실상 인용의 원인이었던 겁니다. 프롬프트를 "요청은 지시문이고, 자막은 시청자에게 말하는 새 문장"으로 고치자 4회 배터리에서 복창 0건(수정 전 2/4)으로 수정되었습니다.

같은 문제가 또 발생했습니다. 요청에 없는 캠페인성 문구가 자막에 붙어 나왔는데 추적해 보니 프롬프트에 박아둔 페르소나(~홍보 영상 편집기)가 요청에 없는 목적을 주입하고 있었습니다. 프롬프트 6곳을 전부 중립적인 "강아지 영상"으로 고쳤습니다. 목적과 톤은 요청에서만 옵니다.

패턴을 정리하면 네 번 모두 같은 문제였습니다. 코드나 프롬프트에 박힌 내용(어휘, 예시 문구, 프레이밍)이 출력으로 샌 것입니다. 그래서 규칙을 정리했습니다. 프롬프트에는 지시만, 내용은 금지. 결정론은 폐기하지 않고 가드로 강등했습니다.

15. 실사용이 낸 숙제들 - 폴리싱과 권한

실사용 데모를 돌리며 자잘한 숙제들이 쏟아졌습니다. 영상이 12.2초로 짧게 나오고(LLM이 길이 필드를 안 적는 습성. 스키마에서 필수로 강제), 0.8초짜리 컷이 화면에서 번쩍하고 지나가고(표시 하한 1.5초 규칙 추가), 제목과 자막이 한 자리에 겹쳐 찍혔습니다. 자막 겹침은 8방위 텍스트 영역 시스템으로 풀었습니다. 상단, 하단, 좌우의 네 구석에 텍스트 자리를 정의하였고, 상단 행은 AI 표시 배지를 침범하지 않게 그 아래에서 시작하며, 긴 자막은 자동 개행합니다. 위치와 표시 타이밍도 소유권 원칙 그대로 유지했습니다. 유저가 명시하면("왼쪽 아래에 자막") 번역기가 받아 적고, 아니면 LLM의 연출 재량입니다.

인프라 쪽에서는 무서운 버그를 하나 잡았습니다. 전처리 산출물이 깨졌을 때 파일이 존재한다는 이유로 재사용되면서 깨진 캐시가 계속 사용되는 버그였습니다. 영상 하나의 분석이 통째로 증발했습니다. 재사용 조건에 내용 검증을 추가했습니다. TTS에서도 하나, 첫 구절 앞에 "흠" 하는 발성이 붙은 걸 Whisper 왕복과 파형으로 문제를 파악하고 해당 구절만 재합성해 지웠습니다.

마지막이 이번 편의 하이라이트입니다. 사진으로 지정한 주인공이 안 나오는 장면이 렌더에 들어왔습니다. 고양이만 걸어다니는 복도 컷이었죠. 문제를 추적하니 LLM이 소스를 직접 지정하면서 시스템이 이를 확실한 선택으로 취급해 Uncertain 구간임에도 영상으로 들어왔습니다. LLM의 선택은 영상 단위일 뿐인데 그것이 주인공이 없는 구간을 선택해버렸습니다. Uncertain 구간이 영상 단위 선택을 타고 그대로 들어온 겁니다.

수정은 권한의 분리였습니다. 유저의 프롬프트는 "그 장면을 원한다"는 보증이라 Uncertain 면제 + 소스 예약을 다 받지만, LLM의 지정은 "그 영상이 어울릴 것 같다"는 판단일 뿐이라 예약만 받았습니다. 여기에 프레임 앵커에 있는 확정된 주인공 박스로 실제 존재하는 구간인지 교차해서 클립을 뽑게 했습니다. 재렌더에서 고양이 컷은 사라졌고 모든 클립에 주인공이 있는 걸 프레임 단위로 확인했습니다.

맺음말

여기까지로 파이프라인이 나오는 것을 넘어 만드는 쪽까지 넘어왔습니다.

• 저작 모드는 한 줄 요청에서 소재와 목적을 근거로 구성을 창작하고(파이프라인 유일의 의도된 비결정),
• 소유권 원칙은 구조를 하나로 귀결시켜 유저가 정한 필드는 LLM의 저작이 아예 간섭하지 못하게 하고,
• 프롬프트는 같은 문제 네 번 끝에 [지시만, 내용 금지]로 확립하고,
• 권한 분리는 유저의 보증과 LLM 저작의 보증에 다른 크기의 권한을 줬습니다.

시리즈의 문장들이 이번 편에서 하나 더 늘었습니다. 정답지로 채점하고, 측정할 수 있는 건 측정에게 맡기고, 소리도 채점하고. 이것에 더해 이번엔 하나의 구조로 귀결시켜라. 구조든 텍스트든 권한이든 구조가 나뉘어지니 문제가 많아졌습니다.

남은 것은 저작 품질의 평가입니다. 구성이 좋은지는 골든셋으로 채점할 수 없는 주관 축이라, 지금은 재추첨 복권이 UX의 전부입니다. 저작 결과를 고객이 미리 보고 고르는 카드 UI, 그리고 이 파이프라인을 제품으로 감싸는 일. 다음 편에서 이어가겠습니다.

다음글

이전글

관련글

목소리를 얹는 순간,
화면이 음성에 맞춰 늘어나고,
타임라인은 음성이 컨트롤합니다.

 

우선 작업 결과부터 보고 가겠습니다.

프롬프트

우리 토리 소개 영상 만들자. 먼저 토리가 가만히 있는 장면 하나를 가지고 토리 얼굴을 천천히 클로즈업으로 5초 보여주고 아래에 텍스트로 우리 토리를 소개합니다를 띄워주면서 읽어줘. 그 다음 애견카페에서 뛰어 노는 모습 10초 편집해서 아래에 텍스트로 똥꼬발랄한 우리 토리 띄워주고 마찬가지로 읽어줘. 그 다음에는 산책하고 비오는 날 뛰고 밤에 달리는 신나게 뛰어노는 모습을 10초 보여주면서 산책도 좋아하는 우리 토리를 아래에 텍스트로 띄워주면서 읽어줘. 그리고 마지막으로 하이파이브 하는 장면으로 우리 예쁜 토리입니다 텍스트를 아래에 띄우고 읽어주면서 끝내줘.

 

"TTS면 대본 넣고 음성 뽑아서 영상 위에 깔면 끝 아냐?"

 

이번 함정은 세 겹입니다. 어떤 TTS가 좋은지는 누가 판정하는가. 어느 문장이 몇 초에 시작해야 화면과 맞는가(싱크). 그리고 TTS가 이름을 엉뚱하게 읽으면 누가 알아차리는가(검증). 셋 다 [깔면 끝]이라는 명제에는 없는 문제들입니다.

 

목소리는 귀로 채점하고,
경계는 산수로 박고,
결과는 기계로 듣는다.

 

영상 작업을 1차로 마무리 짓고, 건너뛴 다섯번째 단계(TTS 내레이션)로 돌아왔습니다. 이번 편은 그 다섯번째 단계의 구현, 편집 / 내레이션 두 모드의 자동 판정, 그리고 2×2 통합 테스트까지 다룹니다. 결론부터 말하면 이번에도 채점이 직관을 뒤집었습니다. 1라운드에서 탈락시킬 뻔했던 엔진이 최종 승자가 됐거든요.

---

8. 귀에도 정답지를 - 골든이어셋 2라운드

TTS의 선택은 취향 문제처럼 보였습니다. 하지만 채점 문제로 바꿨습니다. 시리즈 첫 편의 골든셋을 소리로 옮긴 골든이어셋 — 함정 문장 10개를 고정해두고, 후보 엔진 3개가 합성한 음성을 블라인드로 들었습니다. 사람 귀(톤)와 기계(Whisper로 되읽혀 글자 오류율 측정), 그리고 속도(RTF)로 채점합니다.

 

1라운드에서 사고가 났습니다. 유력 후보였던 Qwen3-TTS가 날짜와 숫자를 뭉개 읽어 기계 채점에서 탈락권이었습니다. 그런데 숫자 읽기는 어차피 한국어 정규화 전처리기(7.2 -> 칠 점 이)가 파이프라인에서 제거할 축이었습니다. 실전에는 존재하지 않는 조건으로 채점하고 있었던 겁니다. 정규화된 입력으로 2라운드를 다시 돌리자 세 엔진 모두 만점, 승부는 톤 청취로 갈렸고 Qwen3-TTS가 이겼습니다. 톤 지시(발랄하게, 차분하게)가 되는 유일한 엔진이라는 점도 컸습니다.

 

첫 편에서 "자가 휘어 있으면 측정이 무의미하다"고 적었는데, 이번에 하나 더 배웠습니다. 채점 조건도 검증 대상이었습니다. 실전에 없는 조건으로 후보를 떨어뜨리면 그건 측정이 아니라 오심입니다.

 

목소리는 9종을 들어보고 하나로 정했고, 규칙도 하나 세웠습니다. 한 영상 안에서 내레이터는 바뀌지 않는다. 블록마다 분위기가 달라져야 하면 목소리를 바꾸는 게 아니라 톤 지시로 조절합니다. 중간에 내레이터가 바뀌는 건 연출이 아니라 편집 사고라고 생각했습니다.

---

9. 싱크는 측정이 아니라 산수 - 구절별 합성

가장 걱정했던 건 싱크였습니다. 대본 한 문단을 통째로 합성하면 두 번째 문장이 몇 초에 시작하는지 알아내기 위해 음성을 역으로 분석(forced alignment)해야 합니다. 측정이 하나 늘고, 오차도 따라옵니다.

 

그런데 발상을 바꾸면 이 문제는 사라집니다. 대본은 이미 LLM이 구절 단위로 분해해 줍니다. 그러면 구절별로 따로 합성해서 구절 사이를 무음으로 채워 조립하면 됩니다. 각 구절이 몇 초에 시작하는지는 측정할 대상이 아니라 우리가 정하는 파라미터가 됩니다. 실측 결과, 발화 시작이 블록 경계 0초, 5초, 15초, 25초에 오차 0으로 박혔습니다. 각 구절의 실제 길이를 재서 다음 경계를 다시 계산하는 산수라 누적 오차도 없습니다.

 

그리고 구절마다 합성 결과를 캐시하니 대본에서 문장 하나만 고치면 그 구절만 다시 합성합니다(나머지는 캐시에서 0.09초). 그리고 영상이 구절보다 짧으면 화면을 늘려서 맞춥니다. 내레이션이 타임라인을 컨트롤 하는 원칙의 구현입니다.

 

남는 문제가 검증입니다. TTS는 아주 가끔 이름을 엉뚱하게 읽습니다(실측: "토리"를 "프린"으로). 빈도가 낮아서 사람이 매번 다 들어볼 수는 없습니다. 그래서 합성 직후 Whisper로 되읽혀 원문과 대조하는 왕복 게이트를 달았습니다. 불일치하면 한 번 재합성합니다. 만든 쪽이 스스로 검사하는 채점기의 TTS판입니다.

---

10. 번역가의 실수 일곱 가지 - 검열이 아니라 복구

내레이션 모드에서 LLM의 번역 출력은 훨씬 길고 복잡해집니다. 그러자 실측에서 실패가 일곱 종류나 연쇄로 터졌습니다. 응답이 중간에 잘리고, 같은 문장을 무한 복창하고, 대본 전체를 한 블록에 삼키고, 요청에 없는 키워드를 전 블록에 입히고, [5초]나 [클로즈업] 같은 명시 지시를 놓치고…

 

고치면서 패턴이 보였습니다. 생성 사고(잘림과 복창)는 파라미터로 잡지만 구조적인 해법은 결국 하나였습니다. 호출을 잘게 쪼개 출력을 소형화 할 것. 대본 문장 추출과 문장별 속성 판정을 분리하고, 문장당 한 번씩 물어 선택지 위주로만 답하게 했습니다. 지난 편 오지선다와 같은 느낌입니다. 그리고 대본 텍스트 자체는 LLM 응답에서 받지 않고 파이썬이 직접 꽂습니다. LLM이 대본을 변형할 통로를 아예 없앤 겁니다.

 

[5초]나 [클로즈업] 같은 리터럴 누락은 결정론으로 복구했습니다. 요청 원문에서 해당 표현과 가장 가까운 문장에 귀속시키는 규칙입니다. "텍스트로 띄워줘"를 놓치면 내레이션 문장을 자막으로 쓰는 폴백도 달았습니다. 사용자가 명시한 것을 복구하는 방향이었습니다.

 

반대 사례가 하나 있었습니다. "소개 영상 만들자"라는 목적 문장을 제목 지정으로 오독해 화면에 제목을 박는 문제. 처음엔 결정론 가드(제목 키워드가 없으면 소거)를 검토했다가 기각했습니다. 의미 판단을 문자열 검열로 대신하면 고객이 프롬프트 작성법을 배워야 작동하는 명령어 체계가 됩니다. 자연어로 말하면 된다는 존재 이유를 배반하는 거죠. 이건 프롬프트 보강으로 풀었고, 테스트 배터리 7/7을 통과했습니다.

 

경계선을 정리하면 이렇습니다. 사용자 프롬프트의 복구와 쓰레기 차단은 결정론, 의미 해석은 프롬프트. 지난 편이 "LLM에게 모션을 맡기지 마라"였다면, 이번 편은 "결정론에게 의미 검열을 맡기지 마라"입니다. 경계선은 양쪽으로 지켜야 합니다.

---

11. 두 모드, 한 기계 - 2×2로 증명

이제 편집-Only(모드 A)과 편집 + 내레이션(모드 B)이 공존합니다. 어느 것인지는 누가 정할까요. 2단 판정입니다. 명시 표현이 있으면 결정론으로 확정하고, 없으면 LLM에게 2지선다 확률로 판정합니다. 동작 판별에서 검증한 레시피의 재사용입니다.

 

구조도 하나로 합쳤습니다. 편집 블록에 내레이션 필드 하나를 확장해 두 모드가 같은 편집 프로세스와 렌더 프로세스를 활용합니다. 내레이션 모드에서는 문장이 곧 블록입니다. 덧붙여 시청자에게 알리는 표시도 넣었습니다. 우상단에 [AI 편집] 배지가 상시로 뜨고, 음성이 있으면 [내레이션: AI 음성]이 한 줄 더 붙습니다.

 

마지막 검증은 같은 요청을 자막과 읽기의 유무로 가른 2×2 매트릭스입니다.

 

자막	읽기	모드	판정결과
O	O	편집 + 내레이션 (확신 1.00)	27.6초, 자막+음성, 발화가 블록 경계 정각
O	X	편집-Only (확신 1.00)	26.5초, 자막만, 무음
X	O	내레이션-Only (확신 1.00)	26.5초, 음성만 — 자막 폴백이 정확히 침묵
X	X	편집-Only (확신 1.00)	26.5초, 화면 텍스트 0

판정 4/4, 부작동 0. 특히 세 번째 줄이 마음에 듭니다. 자막 폴백이 있는데도 "자막 없이"라는 요청에서 자막을 제외했다는 것. 폴백이 명시 요청의 복구 장치이지, 시키지 않은 일을 하는 장치가 아니라는 증거니까요.

 

---

맺음말

여기까지로 두 모드가 모두 세팅되었습니다.

• TTS 선택은 취향이 아니라 골든이어셋 채점으로 정하고,
• 싱크는 측정 대신 구절별 합성 + 무음 조립의 산수로 박고,
• 번역의 실수는 명시된 것의 복구는 결정론, 의미 해석은 프롬프트로 갈라 고치고,
• 두 모드를 한 기계에 태워 2×2 매트릭스로 증명했습니다.

시리즈를 관통하는 문장이 하나로 모입니다. 감각을 믿지 말고 정답지로, LLM의 확신을 믿지 말고 측정으로, 그리고 이번엔 소리도 채점하라. 남은 수동 단계 두 개(영상마다 장면 태그를 적는 것, 여러 마리 중 주인공을 골라주는 것)는 이후 자동 태깅과 강아지 사진 몇 장으로 풀어 이제 영상과 사진만 넣으면 결과가 나옵니다. 그런데 그렇게 나온다고 끝이 아니었습니다. "소개 영상 만들어줘" 한 줄에 파이프라인이 내놓은 건 소개 영상이 아니라 영상의 나열이었거든요. 나오는 것과 잘 만드는 것 사이. 다음 편에서 풀어가겠습니다.

---

이 글에서 다룬 고정 함수 분류층은 ProjectDavid의 일부입니다.

전체를 바닥부터 만드는 과정은 강의 3부작으로 정리하고 있고, 10월에 오픈 예정입니다.

→ 오픈 알림 받기

---

다음글

이전글

관련글

모델은 커모디티가 된다.
마진은 판단에 남는다.

2025년 2월, OpenAI는 당시 가장 비싼 모델 GPT-4.5를 출시했습니다. 백만 토큰당 입력 75 달러, 출력 150 달러. 그리고 다섯 달이 지나기 전, API에서 제거됐습니다. 상업 수명 4.5개월, OpenAI 역사상 최단명 모델입니다. 이 위에 제품을 지었던 개발자들은 그대로 마이그레이션 사이클에 갇혔습니다.

시장이 이 이야기에서 꺼낸 교훈은 명확했습니다. "남의 모델 위에 사업을 짓지 마라. 가치는 모델 소유자에게 남는다." 저는 이 교훈이 절반만 맞다고 봅니다. 정확히 어느 절반이 맞는지가 오늘 글의 주제입니다.

1. 가치는 위로 밀려 올라간다 (Value Migration)

인풋이 커모디티가 되면,
차별화는 위층으로 밀려난다

AI 밸류체인은 세 층입니다. 인프라(GPU, 클라우드), 모델(파운데이션), 콘텐츠/애플리케이션. 인프라는 이미 소수 승자로 굳었고, 지금 움직이는 것은 모델 층입니다.

2026년 6월 기준으로 SWE-bench Verified에서 모델 5개가 0.4점 이내에 몰려 있는데 가격은 5배 차이가 납니다. 시장 전체로 넓히면 최저가 토큰과 프리미엄 추론 토큰의 격차는 600배가 넘습니다. 가격이 더 이상 성능의 대리 지표가 아니라는 뜻입니다. 오픈웨이트와 폐쇄형 프론티어의 격차는 공개 벤치마크 기준 평균 4개월(프라이빗 벤치마크로는 8~10개월, 이 차이는 뒤에서 다시 다루겠습니다.) 수준에서 18개월 넘게 안정적입니다. 격차는 실재합니다. 하지만 좁고, 예측 가능하고, 벌어지지 않습니다.

그리고 파운데이션 모델 훈련은 컴퓨트, 데이터, 인재의 자본전쟁입니다. 하이퍼스케일러가 아닌 모든 주체에게 경쟁 가능한 층은 그 위밖에 없습니다. AI Content가 중요하다는 저의 생각은 낙관이 아니라 소거법의 결론입니다.

2. "그래서 AI Content는 어렵다" (The Bear Case)

반대 서사는 정직하게,
최대 강도로

빅테크와 VC가 애플리케이션 층을 취약하다고 보는 근거는 넷입니다.

첫째, 가격 변동. Claude 3.5 Haiku는 출시 직전까지 가격 유지를 시사했다가 4배 인상됐고(공식 사유: 지능 상승을 반영), 반발이 커지자 한 달 만에 부분 철회됐습니다. 방향이 문제가 아닙니다. o3는 하루아침에 80% 인하됐는데, 경쟁자의 원가가 1/5이 되는 것도 유닛 이코노믹스 파괴입니다. 정가가 조용해도 안심할 순 없습니다. 신형 토크나이저가 같은 텍스트에서 최대 35% 더 많은 토큰을 만들어내면, 정가표는 그대로인데 청구 비용이 올라갑니다. 문제는 인상이냐 인하냐가 아니라 분산입니다.

둘째, 폐기 사이클. 2026년 2월 GPT-4o, 4.1, o4-mini가 약 3개월 예고로 일괄 중단됐습니다. 1년간 다듬은 프롬프트가 새 모델에서 다르게 동작하는 "prompt drift"라는 말까지 생겼죠. 프리뷰 모델은 예고 2주만으로도 은퇴합니다.

셋째, 플랫폼 흡수. 내 래퍼가 하던 기능을 제공사가 자기 제품에 넣어버리는, 이른바 GPT 래퍼의 취약성입니다.

넷째, 규제. 빅테크의 목록에는 없던 항목인데, 올여름 실물로 등장했습니다. 2026년 6월 12일, 출시 사흘 뒤였던 Anthropic의 최상위 공개 모델 Fable 5가 미국 수출통제 지침으로 전 세계 모든 고객에게서 일괄 정지됐고, 지침이 해제된 뒤 7월 1일에야 복구됐습니다. 19일 동안 그 위에 지은 워크플로는 함께 꺼져 있었습니다. 가격과 폐기가 제공사의 선택이라면, 이것은 제공사조차 선택할 수 없는 변수입니다.

이 넷은 특정 조건에서 전부 옳습니다. 그 조건이 무엇인지가 이 글의 나머지입니다.

3. 네 리스크는 하나의 병이다 (The Hidden Premise)

전부 하나의 전제에서 나옵니다.
그것은 남의 호스팅 프론티어에 의존한다는 것입니다.

빅테크가 말하는 리스크 프론티어 API 의존 오픈소스 자체 구동

비용도 정직하게 추산해 보겠습니다. 소비자 GPU 한 장으로 자체 구동하면(3년 감가상각 + 전기료, 가동률 30% 가정) 백만 토큰당 약 1 달러, 이미 보유한 하드웨어라면 한계비용 약 0.5 달러 수준입니다. 최저가 오픈웨이트 API(0.14 달러/0.28 달러)보다 비쌉니다. 절대 비용으로는 집니다.

자체 구동의 경제성은 평균이 아니라 분산에 있습니다. API 비용에는 가격 변동과 폐기, 재테스트라는 분산이 붙고 로컬에는 붙지 않습니다. 하나 덧붙이면 그 최저가 API는 입력 데이터를 학습용으로 보존합니다. 최저가의 숨은 가격은 당신의 데이터입니다.

4. 같은 진단, 반대 처방 (Scale Asymmetry)

진단은 맞다.
복사하면 틀린다

빅테크 규모에서 프론티어 API에 의존하는 콘텐츠 사업은 진짜로 취약합니다. 빅테크 말이 맞습니다. 하지만 소규모 플레이어가 good-enough 구간에서 오픈소스를 자체 구동하는 사업은 취약성을 만드는 의존성을 애초에 끊었으니 오히려 API 기반보다 견고합니다.

트레이드오프는 하나, 절대 프론티어 성능의 포기입니다. 그런데 오픈소스가 이미 기준선을 넘은 구간에서는 그 비용이 사실상 0입니다.

빅테크의 "AI Content는 어렵다"는 진단은 빅테크 자신의 사업 모델에 대해선 맞습니다. 그 진단을 소규모 스타트업에 그대로 복사하는 순간 틀립니다.

5. 공짜는 아니다 (The Honest Brake)

오픈소스라는 길은 엔지니어링 엄밀성을 특별히 보상한다

일방적 낙관으로 끝내면 거짓말입니다. 브레이크 네 개를 밟고 가겠습니다.

• 커모디티 인풋은 커모디티 아웃풋을 만듭니다. 접근이 공짜면 아무나 그 위를 만들 수 있습니다. 해자는 AI에 직교하는 곳이고 유통, 독점 데이터, 도메인 통합, 그리고 검증과 판단에서만 나옵니다.
• good-enough 선은 위로 움직입니다. 그 선에 그냥 주차하면 마진 하락 구간에 주차한 겁니다. 마진은 막 가능해졌지만 경쟁자는 아직 못 따라온 좁은 창을 반복해서 잡는 쪽에 남습니다.
• 경계는 도메인이 아니라 과제 난이도를 가로지릅니다. 프라이빗 벤치마크를 포함한 NIST 평가에서 최상위 오픈웨이트는 수학 벤치마크에선 프론티어와 사실상 대등했지만, 사이버, 추상추론, 장기 에이전틱 코딩에선 30점 이상 벌어졌습니다. 구조화 추출, 요약, 분류, 나레이션은 왼쪽이고 장기 에이전틱 코딩과 오류가 연쇄되는 과제는 오른쪽입니다.
• 자체 구동은 공짜가 아닙니다. 운영, 튜닝, 검증 역량을 요구하고 컴플라이언스 책임도 직접 상속합니다(규제 산업이라면 폐쇄형 모델이 옳은 기본값일 수 있습니다). 의존이 사라진 게 아니라 API 제공사에서 내 역량으로 이동한 것뿐입니다. 역량이 있는 사람에게는 해자가 되고 없는 사람에게는 장벽이 됩니다.

마치며: 승부처는 검증과 판단

같은 오픈 모델을 쓰는 두 팀을 상상해 보세요. A팀은 모델 출력을 그대로 내보냅니다. 이것은 데모입니다. B팀은 비결정성을 표현과 문체에만 허용하고, 사실과 수치, 그리고 식별은 검증 계층을 거쳐야 내보냅니다. 이것은 제품입니다. 같은 인풋, 다른 신뢰죠.

AI Content의 승부처는 싼 모델을 신뢰 가능한 제품으로 바꾸는 엔지니어링 판단입니다. 오픈소스는 그 판단을 가진 사람에게 무기가 됩니다.

참고 자료

• Epoch AI, Open models lag state-of-the-art closed models by 4 months
• LessWrong, How far behind are open models? (프라이빗 벤치 8~10개월)
• OpenAI 공식 모델 폐기 일정
• TechCrunch, Anthropic hikes the price of its Haiku model
• morphllm, LLM API 가격, 벤치마크 스냅샷 (2026.6.28)
• BenchLM, LLM API 가격 가이드 — 600배 스프레드 (2026.7)
• NIST CAISI, Evaluation of DeepSeek V4 Pro (2026.5)
  

  ---

  이 글에서 다룬 고정 함수 분류층은 ProjectDavid의 일부입니다.

  전체를 바닥부터 만드는 과정은 강의 3부작으로 정리하고 있고, 10월에 오픈 예정입니다.

  → 오픈 알림 받기

  ---

관련글