도구 단위로 쪼개진 화면을 작품 단위로 다시 묶은 AIDRA 셸 리디자인

문제 정의

탭 여덟 개가 각자 하나의 스튜디오였고, 작품은 그 사이에 흩어져 있었다

AIDRA는 기획안에서 시작해 회차 대본, 오디오 드라마, 영상까지 AI 드라마 한 편을 만드는 사내 제작 도구다. 2026년 9월, 팀 워크스페이스를 열어 다른 팀과 외부 사용자를 받는 일정이 잡혔다. 그때까지 이 제품을 실제로 쓰던 사람은 드라마팀의 두 명뿐이었고, 둘은 어떤 기능이 어디에 있는지를 몸으로 외우고 있었다. 처음 온 사람에게는 그 기억이 없다. 착수 전에는 운영 화면 35장을 다시 찍어, 처음 온 사람의 눈으로 진단했다.

좌측 레일의 여덟 칸(홈, 기획안, 에피소드, 팟캐스트, 영상, 지식관리, 트렌드, 관리자)은 각각 독립된 스튜디오였다. 작품 한 편을 끝까지 만들려면 기획안, 에피소드, 팟캐스트, 영상 네 탭을 오가며 매번 기획안 선택기에서 같은 작품을 다시 골라야 했다. 뒤로가기 라벨은 화면마다 다섯 가지로 달랐고, LLM과 대화하는 입력창도 다섯 곳에 흩어져 있었다. 만든 캐릭터나 BGM은 만든 자리에 갇혀, 산출물을 가로질러 볼 수 있는 곳은 오디오 탭 하나뿐이었다. 35장에서 나온 증상 여섯 가지는 화면이 사용자의 작업 단위인 작품이 아니라 기능이 생긴 순서대로 쪼개져 있다는 한 원인으로 모였다.

제약은 일정이었다. 외부 개방 전에 끝내야 했고, 두 명이 매일 쓰는 제품이라 중간에 멈출 수도 없었다. 번들러 없이 바닐라 ES 모듈로 된 웹 클라이언트에는 지금의 모듈 경계에 붙은 테스트 파일이 165개 있었다. 무엇을 새로 만들지보다 무엇을 건드리지 않을지가 먼저 정해져야 하는 조건이었다.

가설 수립

스킨을 바꾸는 대신, 크리에이터가 이미 아는 문법으로 구조를 옮기기로 했다

가장 빠른 길은 레일을 그대로 두고 색과 컴포넌트만 정리하는 것이었다. 물론 일정만 보면 그쪽이 안전했다. 하지만 스킨을 바꿔도 작품이 네 탭에 흩어진 구조는 그대로 남는다. 외부 사용자가 길을 잃는 이유가 구조라면, 표면을 아무리 다듬어도 첫 방문에서 막히는 지점은 줄지 않는다고 판단했다. 그래서 정보 구조부터 바꾸기로 했다.

새 구조를 처음부터 발명하지는 않았다. Framer 같은 크리에이터 툴이 이미 굳혀 놓은 문법, 즉 프로젝트 목록에서 하나를 열면 그 프로젝트 전용 편집기로 들어가는 두 겹의 셸을 빌렸다. 영상과 이미지를 다루는 사람에게 익숙한 문법이면 설명 없이도 다음 행동을 짐작할 수 있고, 익히는 부담을 화면 문구 대신 구조가 진다. 목표는 처음 온 사람이 안내 없이 한 프로젝트 안에서 기획부터 영상까지 혼자 끝까지 가는 것이었다. 이 목표를 숫자로 걸어 두지는 않았고, 그 대가는 결과에서 다시 다룬다.

솔루션 도출

레일 여덟 칸을 허브 일곱 칸과 프로젝트 셸 하나로 다시 묶고, 화면 문구를 걷어냈다

기획안 한 편을 곧 프로젝트로 정의하고, 기획안·에피소드·팟캐스트·영상 네 탭을 프로젝트 셸 안의 단계로 넣었다. 프로젝트 홈은 아이디어에서 기획안과 에피소드를 거쳐 오디오와 영상이 나란히 갈라지는 파이프라인 보드다. 카드를 열면 좌측 트리, 중앙 작업면, 우측 속성 패널로 나뉜 작업실이 된다. 전체를 하나의 캔버스로 만드는 안도 있었지만, 단계가 정해진 제작 흐름에는 보드로 순서를 보여 주고 실제 작업은 익숙한 편집 화면에서 하게 하는 하이브리드가 맞다고 봤다. 바깥은 홈, 라이브러리, 프로젝트, 피드, 트렌드, 지식, 관리자 일곱 칸의 허브로 줄였고, 흩어져 있던 산출물은 라이브러리에서 프로젝트를 가로질러 보게 했다.

바깥 허브의 홈. 좌측 레일은 홈·라이브러리·프로젝트·피드·트렌드·지식·관리자 일곱 칸이고, 이어서 작업할 것은 작품 카드로 놓인다

프로젝트 하나를 열면 나오는 파이프라인 보드. 맨 위에 다음 한 걸음이 오고, 아이디어·기획안·에피소드가 순서대로 진행 상태를 보여 준다. 오디오는 아래 선택 구간에 따로 놓인다

카드를 열면 들어가는 작업실. 좌측 목록, 중앙 작업면, 우측 속성 패널의 3분할이다. 상단 탭으로 기획·에피소드·에셋·영상·오디오 단계를 오간다

일정 제약 때문에 재작성 대신 재구성을 택했다. 셸을 들이는 단계에서는 기존 화면 모듈을 새 셸의 중앙 페인에 그대로 얹어, 테스트 165개가 붙은 모듈 경계를 건드리지 않고 구조를 바꿨다. 새 셸은 런타임 플래그 뒤에서 운영에 먼저 올리고, 나와 영상 담당 개발자가 먼저 켜서 써 본 뒤 기본값을 넘겼다. 나는 계획 문서와 결정 12건을 쓰고, 구현은 단계별로 에이전트에 나눠 맡긴 뒤 검증과 판정을 쥐었다.

프로젝트 목록. 스마트 폴더와 팀·사람 트리로 작품을 찾고, 작품은 지금 어느 단계에 있는지로 묶여 보인다

라이브러리. 만든 자리에 갇혀 있던 클립·캐릭터·배경·BGM·효과음·배경음·음성이 프로젝트를 가로질러 한곳에 모인다

구조를 바꾸고 매일 써 보니 다음 문제가 보였다. 툴인데 기능을 풀어 설명하는 보조 문구가 작업면을 덮고 있었다. 처음 온 사람을 위해 안내를 늘리는 쪽이 직관적이었지만, 크리에이터 툴의 사용자는 글을 읽지 않고 눌러 본다는 판단으로 반대로 갔다. 규칙은 판단 순서로 세웠다. 꼭 남길 것인지 먼저 보고, 아니면 지우고, 관용 아이콘이 있으면 아이콘으로 바꾸고, 그래도 남는 것만 줄인다. 유료 동작의 금액과 개수는 남길 것으로 분류해 건드리지 않았는데, 글을 줄이는 원칙도 사용자의 돈 앞에서는 멈춰야 한다고 봤기 때문이다.

결과 & 배운 점

11일 만에 새 셸이 유일한 화면이 됐지만, 목표를 잴 장치는 함께 심지 못했다

9월 10일 착수 후 11일 만인 9월 21일, 플래그와 옛 화면을 걷어내고 새 셸을 유일한 화면으로 만들었다. 화면 문구는 소스 기준 111,972자에서 90,423자로 약 20% 줄었고, 프롬프트 문자열이 같은 파일에 섞여 있는 영상 탭을 빼고 보면 24%가 줄었다. 변경 전 빌드를 따로 띄워 같은 32개 라우트를 나란히 재면, 버튼을 뺀 화면 글자는 12,729자에서 10,861자가 됐다. 매일 쓰는 내부 사용자들은 화면이 깔끔해지고 비로소 툴답게 바뀌었다고 반응했다. 독립 검증에서는 감사 첫 판이 결함 0이라고 적은 떠 있는 패널이 사실 표본 4개만 본 결과였고, 전수로는 26개 중 6개만 키보드 초점을 가두고 있었다. 두 곳은 바로 고쳤지만 나머지 대부분은 다음 라운드의 부채로 기록해 두었다.

정작 처음 세운 목표, 처음 온 사람이 혼자 끝까지 가는지는 아직 확인하지 못했다. 외부 사용자가 들어오기 전이었고, 무엇보다 그것을 잴 퍼널을 새 셸과 함께 심지 않았다. 지금 손에 쥔 근거는 글자 수와 내부 체감뿐이다. 이 프로젝트에서 나는 구조가 먼저이고 표면은 나중이라는 순서를 배웠다. 구조를 먼저 고정해 두자 재질 같은 표면 실험은 되돌려도 아무것도 깨지지 않을 만큼 싸졌다. 다음에는 목표 문장을 쓰는 그 자리에서, 그 목표를 잴 장치도 함께 설계할 것이다.