어떻게 사람들에게 알릴까? : AI Reels Generator

블로그에 글은 썼지만, 보는 사람이 있는지 알기 어려웠다. 조회수 카운터를 만들었는데, 생각보다 조회수가 늘지 않았다. 대부분 내가 테스트로 들어온 조회수였다. 홍보를 조금 해야겠다고 생각했다. 이 블로그는 Ghost로 발행되는데, 글을 발행하면, sns에 공유하는 팝업을 띄워주었다. thread에 한 번 공유해보았다. 리액션은 많이 없었지만, 조회수는 조금 늘었다.

그 후, 릴스를 만들어보자고 생각했다. 콘텐츠를 영상으로 만들면 그걸 통해서 유입을 일으킬 수 있을 것 같았다. 이미 쓴 글에서 흥미로운 이야기를 꺼내 영상으로 옮기면, 나름 괜찮은 영상이 되지 않을까?

시작은 단순했다. AI로 만든 PT형 숏츠가 어떻게 제작되는지 물었고, 곧 GitHub Actions로 만들어보자고 했다. 블로그 URL을 넣으면 대본과 장면 후보를 생성하고, 내가 고른 후보를 영상으로 렌더하는 구조였다. 구현은 AI 코딩 도구와 함께 진행했다.

영상이 나오자 고칠 곳이 보이기 시작했다. 사진이 부족했고, 도식은 개념을 충분히 설명하지 못했다. 자막도 없었다. 한 장면을 고치면 다른 장면에서 비슷한 문제가 나왔다.

프롬프트에도 그 변화가 남아 있다. 처음에는 특정 페이지에 사진을 넣어 달라고 했다. 나중에는 같은 문제가 다음 영상에도 생기지 않도록 지침을 바꾸라고 했다. 지침만으로 부족한 부분은 코드로 검사하게 했고, 검증에 실패하면 같은 작업 안에서 수정하도록 만들었다.

릴스 한 편을 고치는 과정에서 제작 기준이 조금씩 쌓였다.

처음 생성한 후보 중에서는 2번이 가장 마음에 들었다. 다만 3번에 있던 설명 하나는 살리고 싶었다. 페이지를 이해하려고 공부하다가 디스크와 메모리, 파일 시스템과 운영체제로 계속 내려가면 원래 배우려던 목표를 놓칠 수 있다는 내용이었다.

여기에 학습 부채가 학습 속도에 레버리지를 줄 수 있다는 관점을 덧붙였다. 필요하면 페이지를 늘려도 된다고 했다. 원문을 일정한 길이로 줄이는 것보다, 어떤 설명을 남겨야 이야기가 성립하는지가 중요했다.

그래서 후보를 여러 개 만들고 선택하는 흐름은 유지했다. AI가 글에서 서로 다른 관점을 제안하면, 나는 남길 논지와 강조할 부분을 골랐다. 대본과 장면 구성은 JSON으로 저장해 PR에서 수정하고 비교할 수 있게 했다.

하지만 대본을 골랐다고 영상의 방향까지 정해지는 것은 아니었다.

학습의 레버리지를 설명하는 장면에 상승 화살표가 나왔다. 관련 있는 그림이기는 했다. 그래도 작은 힘으로 큰 결과를 움직인다는 관계는 드러나지 않았다. 시소나 지렛대를 쓰면 더 잘 설명할 수 있을 것 같았다. 성장의 차이를 말하는 장면이라면 두 곡선을 비교하는 편이 나았다.

그때부터 시각화를 요청하는 방식이 달라졌다. 어떤 그림을 넣을지와 함께, 그 그림에서 무엇이 어떻게 변해야 하는지를 설명했다. 병목이라면 좁은 입구 앞에 흐름이 쌓여야 하고, 깊이 살펴보는 장면이라면 전체 구조를 보여준 뒤 의미 있는 부분으로 확대해야 했다.

이 요구를 다음 생성에도 적용하려면 장면 데이터부터 바꿔야 했다. 각 장면에 시각적으로 설명할 관계, 요소가 등장하는 순서, 카메라의 이동을 담았다. 자막도 의미 단위와 강조, 쉼을 함께 기록하도록 했다. 의미 중심 모션 편집을 추가한 커밋에서 이 구조를 확인할 수 있다.

자막에는 특히 신경이 쓰였다. "그럴 수 있다"가 "그럴", "수", "있다"로 나뉘면 읽는 호흡이 끊겼다. 처음에는 최소 글자 수를 정하면 될 것 같았지만, 짧아도 따로 보여줘야 하는 말이 있었다. "아니다"처럼 한 번 끊어 강조할 때가 그렇다.

결국 의미 단위로 묶되 강조할 부분은 따로 표현할 수 있게 했다. 이후 실제 결과에서 크기가 계속 바뀌어 글리치처럼 보이는 문제를 발견했고, 크기를 안정적으로 유지하면서 강조를 절제하는 방향으로 다시 조정했다. 리듬을 주겠다는 의도가 모든 단어를 튀게 만드는 결과로 이어지지 않도록 해야 했다.

디자인도 같은 과정을 거쳤다. 검정 배경, 큰 타이포, 모노크롬 사진으로 블로그의 분위기를 이어가고 싶었다. 사진은 화면을 크게 덮는 구성이 좋았다. 그런데 사진을 넣으라는 규칙을 강조하니 설명이 이어져야 할 자리에 사진이 끼어들 수 있었다.

사진의 개수보다 장면의 역할을 먼저 판단해야 했다. 방이나 문처럼 구체적인 대상을 말할 때는 사진이 유용했다. 두 구조의 차이를 설명할 때는 같은 좌표와 객체를 유지한 채 변화를 보여주는 편이 나았다. 템플릿을 다양하게 쓰는 것도 설명의 흐름 안에서 해야 했다.

이런 판단을 하려면 결과를 쉽게 볼 수 있어야 했다.

초기에는 렌더가 끝난 뒤 영상을 확인했다. 휴대폰에서 접근하기가 번거로웠고, 완성 영상을 만든 다음에야 레이아웃 문제를 발견했다. 그래서 각 장면의 스냅샷으로 스토리보드를 먼저 만들고 승인하는 단계를 넣었다.

스토리보드에서는 TTS를 호출하지 않는다. 추정 길이로 장면 이미지를 만들고, 내가 확인한 뒤에 실제 음성과 최종 영상을 생성한다. 승인 단계를 추가한 변경으로 검토 시점이 제작 중간으로 옮겨갔다.

JSON만 읽고 장면을 상상하는 것도 불편해서 읽기용 스토리보드를 함께 만들었다. 장면 이미지와 대본, 화면 구성, 자막 강조점을 볼 수 있게 했다. 휴대폰에서는 모아보기 이미지로 순서를 훑고, 개별 이미지나 PDF로 글자를 확인했다. Release 본문에 렌더 실행 링크와 복사할 JSON 경로도 넣었다. 완성 영상과 릴스 게시 문구까지 같은 곳에서 받을 수 있도록 이어 붙였다.

이런 변경은 작아 보이지만 계속 쓰려면 필요했다. 매번 결과 파일의 위치와 다음 실행 방법을 물어야 한다면, 그 단계마다 내가 작업을 연결해줘야 했기 때문이다.

스토리보드를 보기 쉬워지자 반복되는 오류도 더 잘 보였다. 연결선이 객체와 어긋나고, 한글 라벨을 통과했다. 밑줄이 받침에 붙거나 안전영역 때문에 다른 요소가 겹쳤다. 연결선이 자라나는 애니메이션에서는 선이 짧은 점처럼 먼저 보이기도 했다.

처음에는 여백과 배치 지침을 자세히 적었다. 그래도 비슷한 오류가 나와서 요청을 바꿨다.

"지침기준으로 하드하게 관리할 수 있는건 그렇게 전환해줘"

라벨의 최소 크기와 내부 여백, 텍스트 보호영역, 선과 글자의 충돌처럼 수치로 확인할 수 있는 것은 코드가 검사하도록 했다. 연결선도 별도의 좌표를 주는 대신 객체의 연결점에서 계산하게 했다. 객체가 움직이면 선도 그 위치를 따라가야 했다.

움직임이 있는 장면은 완료된 화면만 검사해서는 부족했다. 시작과 중간, 최대 확대 상태에서 겹칠 수 있었다. 사전 검사에 여러 시점을 포함하고, 렌더 과정에서도 프레임을 검사하도록 했다. 실제 제목과 자막은 폰트가 로딩된 뒤 배치를 확인했다. 레이아웃 검증을 강화한 커밋에 이 기준을 반영했다.

반면 무엇이 앞에 보여야 하는지는 숫자만으로 정하기 어려웠다. 사진 위에 제목을 올리는 것은 의도된 중첩이고, 연결선이 라벨을 가리는 것은 오류다. 도형의 종류만 보고 레이어 순서를 고정할 수도 없었다.

그래서 기하학적으로 검사할 부분과 의미를 보고 판단할 부분을 나눴다. 자동 검사를 통과해도 사진이 내용에 맞는지, 장면의 변화가 주장을 제대로 설명하는지는 따로 봐야 했다.

그 리뷰도 반복됐다. 스토리보드를 보고 개선점을 적고, AI에 전달하고, 수정한 결과를 다시 확인했다. 이 흐름을 워크플로우로 옮겼다.

원문과 장면 JSON, 실제 스토리보드 이미지에 선택 코멘트를 더해 AI가 리뷰하게 했다. 도식은 초기·변화·결과 이미지를 함께 전달했다. 리뷰에 따라 후보를 수정하고, 검증과 재렌더를 거친 뒤 개선 PR을 만들었다. 내가 특별히 고치고 싶은 부분이 있으면 코멘트를 넣고, 없으면 공통 품질 기준으로 검토하게 했다. 스토리보드 리뷰와 개선 PR 구현

여기서도 실제로 돌려보니 문제가 생겼다. 리뷰 전에 현재 코드로 원본을 다시 렌더하면, 내가 보고 지적한 화면과 리뷰 대상이 달라질 수 있었다. 나중에는 기존 Release의 스냅샷과 원본 JSON을 가져와 검토하도록 바꿨다. 어떤 결과를 기준으로 수정하는지도 제작 과정의 일부였다.

검증을 엄격하게 만든 뒤에는 실패 처리에 손이 많이 갔다. 오류를 확인하고 다시 수정해 달라고 요청하는 일이 이어졌다. 결국 이렇게 물었다.

"한 워크플로우 안에서 루프로 끝낼 수는 없나? 계속 수정하라고 요청해야해?"

검증 오류를 해당 장면과 함께 AI에 전달하고, 도식 명세를 고친 뒤 같은 검사를 다시 수행하도록 했다. 같은 배치를 조금씩 바꾸는 것만으로 해결되지 않을 수 있어 초반에는 부분 수정, 이후에는 의미를 유지한 재설계로 전환했다. 이전 오류 이력도 함께 전달했다.

무작정 반복하지는 않도록 장면별 시도 횟수와 작업 전체의 호출·시간 예산을 제한했다. 실패한 장면과 마지막 도식, 오류 이력은 남겼다. 수정으로 해결할 수 없는 문제는 중단하고 원인을 볼 수 있어야 했다. 재설계와 오류 이력을 포함한 수정 루프

이 루프가 모든 실패를 고치지는 못한다. 렌더러 코드 자체의 결함이나 권한 문제는 별도 수정이 필요하다. 그래도 검증 오류를 그대로 복사해 다시 요청하던 작업은 워크플로우 안으로 옮길 수 있었다.

후반에는 이야기의 순서에도 같은 방식으로 기준을 남겼다.

한 영상의 도입이 설득되지 않았다. 아직 질문이 생기지 않았는데 결론부터 말하고 있었다. 다른 영상에서는 "AI의 글, 왜 읽고 싶지 않을까?"로 시작하는 편이 자연스러웠다. 먼저 시청자가 알아볼 수 있는 문제를 보여주고, 설명을 쌓은 뒤 결론에 도착해야 했다.

커버만 고치지 않고 생성 지침에도 질문과 결론의 순서를 반영했다. 마지막 문장은 앞에서 충분히 설명한 말을 덜어내고 판단을 선명하게 남기도록 했다. "위임 경쟁의 승패, 평가 환경에 달렸습니다"라는 문장도 그렇게 다듬었다.

표현 기능 역시 콘텐츠에서 필요가 생길 때 확장했다. 고유한 경험이 평균화되는 이야기를 보며, 비정형 도형이 매끈한 원으로 바뀌면 그 변화를 보여줄 수 있겠다고 생각했다. 원의 둘레를 노이즈로 왜곡하고 그 강도를 줄이는 모핑을 추가했다. 이미 발행한 후보는 그대로 두고, 다음 제작에서 쓸 지침과 렌더링 기능에 반영했다. 비정형 도형 모핑 구현

돌아보면 요청이 점점 구체적인 장면에서 공통 규칙으로 옮겨갔다. 사진 한 장을 바꾸는 데서 시작해 사진을 선택하는 기준을 적었다. 겹친 라벨을 옮기다가 겹침을 검사하게 했다. 실패를 다시 전달하다가 오류를 받아 수정하는 루프를 만들었다.

이 과정으로 릴스를 실제 발행하기까지 이어갔다. 다만 조회수나 완주율이 얼마나 좋아졌는지, 제작 시간이 얼마나 줄었는지는 아직 말할 수 없다. SNS 업로드도 직접 한다. 정지 이미지 리뷰로는 음성 타이밍과 BGM, 모션의 자연스러움을 확인할 수 없어 최종 영상 검수도 남아 있다.

현재 시스템에는 내가 봐야 할 부분이 여전히 많다. 그래도 한 번 발견한 문제를 다음 제작에서 다시 설명하지 않도록 남길 곳이 생겼다. 편집 의도는 지침과 장면 명세에, 측정 가능한 조건은 검증 코드에, 반복되는 오류 대응은 수정 루프에 들어갔다.

다음 영상에서도 고칠 곳은 나올 것이다. 중요한 건, 수정을 차곡차곡 쌓아 하나의 시스템으로 만들어가는 일이다. 그리고 내가 어디에 개입할 때 가장 큰 결과를 내는지 평가하고 자리를 찾아가는 일이다.

인스타그램에서 릴스 보기