인프런 강의를 만들고 있습니다.
총 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은 바이브 코딩의 적임자가 맞습니다.

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

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

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

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

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

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

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

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

뭘 만들지 정의하고,

범위를 자르고,

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

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

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

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

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

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

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

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

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

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

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

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

전부 기획 판단입니다.

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

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

그런데 왜 다들 막히는가

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A는 이렇게 시킵니다.

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

B는 이렇게 시킵니다.

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

둘 다 같은 걸 원했지만,

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

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

드롭존과 딤드

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

정리

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

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

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