영상을 내리고 그 앞 단계를 넣은 AIDRA 스토리보드 스튜디오
협업팀이 스토리보드 니즈를 말해주자 이미 배포한 영상 탭을 내리고, 옆 기능의 검증된 골격을 미러해 인터뷰 종료 두 시간 안에 프로덕션에 올린 프로젝트
Problem
회차 산출물에 영상 생성기용 클립 프롬프트만 있어 연출 기획자가 회차의 시각적 전개를 눈으로 확인할 방법이 없었고, 영상 생성을 먼저 붙여둔 탓에 실무의 순서와 제품의 순서가 뒤집혀 있었다
Hypothesis
연출 기획자는 영상을 뽑기 전에 그림으로 흐름을 먼저 판단하므로 그 단계를 제품화하는 것이 우선이라 보고, 새로 짓는 대신 이미 검증된 영상 스튜디오의 골격을 미러하면 하루 안에 출시할 수 있다고 판단했다
Solution
이미지 종류와 프롬프트 재작성, 저장 경로 세 가지만 델타로 남기고 나머지를 전부 재사용했으며, 클립과 캐릭터를 잇는 기계 판독 신호가 없어 자동 매핑 대신 프리필 후 사람이 확정하게 했다
Result
인터뷰 종료부터 프로덕션 배포까지 1시간 55분이 걸렸고, 착수 전 관문으로 세운 검증이 신규 기능이 아니라 이미 배포된 기능의 잠복 결함을 찾아냈다. 다만 아직 베타이고 현업팀 사용은 시작 전이다
Lesson Learned
만든 순서보다 쓰는 순서가 우선이며 매몰 비용은 판단의 근거가 아니라는 것을 배웠다. 추론을 자동화하지 않고 사람의 확정을 남겨둔 자리에서 오류가 눈에 보이게 드러났다
문제 정의
영상을 만들던 중에, 그 앞 단계가 더 급하다는 말을 들었다
AIDRA는 기획안에서 회차 시나리오까지 만들고, 그다음 단계로 영상 생성을 붙여둔 상태였다. 회차 영상 스튜디오는 이미 배포돼 있었고 다음 확장도 그쪽으로 이어갈 계획이었다. 그런데 만들던 중에 협업팀에서 스토리보드에 대한 니즈를 말해줬다. 영상보다 그게 먼저라는 이야기였다.
이 제품의 실사용자는 두 명이고 둘 다 연출 기획 역할이다. 그들의 실무를 놓고 보면 이유가 분명했다. 회차 시나리오가 나오면 그다음에 하는 일은 영상을 뽑는 게 아니라, 이 회차가 어떤 그림으로 흘러가는지를 먼저 눈으로 확인하는 것이다. 영상은 그 판단이 끝난 뒤에 만든다. 순서를 뒤집어 놓고 있었던 셈이다.
당시 회차 산출물에는 영상 생성기용 클립 프롬프트가 열에서 스무 개씩 들어 있었다. 클립당 15초 이하로 쪼개진 영어 지시문 덩어리인데, 이건 기계가 읽을 형식이지 사람이 회차 흐름을 훑을 수 있는 형태가 아니다. 연출 기획자가 이 텍스트만 보고 회차의 시각적 전개를 판단하기는 어려웠다. 그래서 이미 만들어둔 영상 탭을 좌측 레일에서 내리고, 그 자리에 스토리보드를 넣기로 했다.
가설 수립
새로 짓지 않고, 옆 기능의 검증된 골격을 그대로 옮긴다
범위를 정하는 인터뷰를 다섯 라운드 돌렸다. 첫 게이트에서 정한 것은 무엇을 빼느냐였다. 스토리보드 컷을 영상 스튜디오의 입력으로 넘기는 배선은 이번에 하지 않기로 했다. 그 연결은 나중에 붙일 수 있고, 지금 필요한 것은 시각화 자체의 가치를 먼저 세우는 일이었다. 대신 컷 이미지를 저장소에 영속시켜 나중에 배선만 하면 되는 상태로 남겼다.
단위도 이때 확정했다. 씬으로 묶을지 클립으로 쪼갤지 고민했는데, 클립 하나를 컷 하나로 잡으면 나중에 영상 소스와 일대일로 대응된다. 그리고 캐릭터 매핑은 자동 리졸버를 만들지 않기로 했다. 회차 산출물에는 클립과 캐릭터를 기계가 읽을 수 있게 이어주는 신호가 없고, 대사 없는 클립은 아예 단서가 0이다. 자동으로 추론하게 하면 조용히 틀린 얼굴이 붙는다.
가장 중요한 결정은 구현 전략이었다. 영상 스튜디오가 이미 검증된 골격을 갖고 있었으므로 그것을 미러하고, 다른 부분만 국소화하기로 했다. 이미지 종류가 다르고, 프롬프트를 스틸용으로 다시 쓰는 단계가 추가되고, 저장 경로가 다르다는 세 가지가 델타의 전부였다. 재발명을 금지한 이유는 명확했다. 이 제품에서 프록시 계약이 어긋났을 때 프로덕션 전량 실패가 난 이력이 있었기 때문이다.
인터뷰의 네 번째 라운드에서 당연하게 여기던 가정 하나가 깨졌다. 영상용 클립 프롬프트를 그대로 이미지 생성에 쓰면 된다고 생각했는데, 카메라를 밀고 당기고 따라가라는 모션 지시어가 스틸 이미지에는 부적합하다는 반문이 나왔다. 그래서 회차 단위로 한 번에 스틸 키프레임용 프롬프트로 다시 쓰는 단계를 넣었다. 그리고 이 판단을 눈으로 확인하는 대신 모션 관련 단어가 결과에 하나도 남지 않는지를 테스트로 고정했다.
솔루션 도출
인터뷰가 끝나고 두 시간 안에 프로덕션에 올렸다
인터뷰가 끝난 시각이 오후 4시 9분, 합의 플랜이 승인된 시각이 4시 43분, 구현 커밋이 5시 20분이었다. 그 사이 37분 동안 37개 파일에 1,925줄이 들어갔고 단위 테스트는 1,836개가 통과했다. 독립 검증에서 지적된 부분을 보강한 뒤 6시 4분에 병합하고 프로덕션에 배포했다. 인터뷰 종료부터 배포까지 1시간 55분이 걸렸다. 이 속도는 재사용 전략의 직접적인 결과다.
배포 직후에 하기로 했던 검증이 남아 있었다. 캐릭터 참조 이미지를 넣어 생성했을 때 얼굴이 유지되는지를 실제로 재보는 관문이었는데, 병합과 배포를 먼저 진행하려다 그 두 가지가 아직 미실시라는 것을 확인하고, 관문을 직접 수행한 뒤 배포하기로 순서를 되돌렸다. 프로덕션에서 실제 컨셉아트로 네 조합을 제출했더니 전부 같은 오류로 거부됐다. 참조 이미지 자체가 받아들여지지 않고 있었다.
여기서 예상하지 못한 것이 드러났다. 단일 캐릭터 참조도 거부됐고, 확인해보니 이미 배포돼 쓰이고 있던 컨셉아트 보완 기능이 정확히 같은 코드 경로를 타고 있었다. 프로덕션 로그에서 참조 이미지를 포함한 성공 건수를 세어보니 표본 30건 중 0건이었다. 신규 기능을 위해 세운 관문이 이미 배포된 기능의 잠복 결함을 찾아냈다. 관문이 없었다면 그 기능은 계속 깨진 채로 있었을 것이다.
이 진단에는 뒷이야기가 둘 있다. 하나는 구조적 차단이라고 내린 결론이 하루 뒤에 틀린 것으로 밝혀진 일이다. 프록시 쪽에서 필드 하나를 빠뜨린 버그였고, 고쳐지면서 우리 쪽 호출 형식을 바꿔야 했다. 기록을 지우는 대신 문서 상단에 결론이 틀렸다는 표시를 달고 원문을 남겼다.
다른 하나는 사흘 뒤에 다중 캐릭터 처리 방식을 통째로 바꾼 일이다. 여러 얼굴을 한 장으로 합성해 넣던 방식이 인원이 늘면 잘리고 정렬도 어긋났는데, 프로덕션에서 재보니 이미지 모델이 참조를 배열로 받아 전부 반영하고 있었다. 영상 쪽은 한 장 제약이 실측이라 그대로 두고 스토리보드만 배열로 바꿨다.
결과 & 배운 점
만들어 올렸고, 아직 검증을 기다리는 중이다
스토리보드 탭은 프로덕션에 올라가 있고 지금도 다듬는 중이다. 베타 상태이고 현업팀의 본격적인 사용은 아직 시작되지 않았다. 그러므로 이 기능이 실무를 바꿨다고 말할 단계는 아니다. 지금 말할 수 있는 것은 만드는 과정에서 확인된 것들뿐이다.
자동 매핑을 막은 판단은 사흘 만에 값을 했다. 실사용 중에 캐릭터 시트의 이름과 클립 안 화자 이름이 한 글자 다른 경우가 나왔는데, 같은 모델이 회차를 만들면서 표기를 흔든 것이었다. 자동 리졸버였다면 조용히 다른 얼굴이 붙었을 것이다. 실제로는 미정의 인물이라는 배너가 떠서 사람이 볼 수 있게 막혔다. 추론을 자동화하지 않고 사람의 확정을 남겨둔 자리에서 오류가 눈에 보이게 드러났다.
배운 것은 세 가지다. 먼저 새로 짓지 않는 것이 가장 빠른 길이라는 점이다. 옆 기능의 검증된 골격을 미러하고 델타만 국소화하니 신규 탭이 오후 한나절에 들어갔고, 그 골격에 이미 녹아 있던 실패 교훈들도 함께 따라왔다. 클립마다 독립적으로 제출하고 과금하는 규칙이나 자동 리졸버를 금지하는 규칙은 영상 스튜디오가 먼저 겪고 배운 것들이었다.
다음으로 스스로 세운 관문이 예상 밖의 것을 잡아낼 수 있다는 점이다. 참조 이미지 충실도를 재보려던 관문이 신규 기능이 아니라 이미 쓰이던 기능의 결함을 드러냈다. 마지막으로 만든 순서보다 쓰는 순서가 우선이라는 것이다. 영상은 이미 배포까지 마쳤지만 사용자가 그 앞 단계를 먼저 원했고, 그렇다면 만든 것을 내리는 편이 맞다. 매몰 비용은 판단의 근거가 아니다. 다만 그 판단이 옳았는지는 현업팀이 실제로 쓰기 시작해야 알 수 있고, 그건 아직 앞에 남아 있다.
Supercent
에서의 다른 경험도 살펴보기
말해줄 때까지 기다리지 않는 AIDRA 피드백 트리아지 루프
물어봐야 조금씩 말해주던 파트너팀 피드백을, 인앱 티켓과 회신이 한 바퀴 도는 루프로 바꾸고 그 운영 절차를 스킬로 코드화해 다섯 주간 열세 번 반복한 프로젝트
기획자가 이미 보던 것을 안으로 옮긴 AIDRA 트렌드 허브
AI가 요약해주는 인사이트를 만드는 대신, 기획자가 실제로 시장 신호를 얻던 경로를 관찰해 그 방식 그대로 제품 안으로 옮긴 프로젝트
1번 액션을 덮지 않고 팀 피드를 홈 아래로 내린 AIDRA 홈 개편
팀원의 완성물을 볼 서버 경로조차 없던 제품에 피드를 얹으면서, SNS 관례대로 홈 위에 올렸다가 주 동선을 해치자 이틀 만에 아래로 내린 프로젝트
