안녕하세요. 저는 프리윌린 잉글리시플랫 프로덕트 디자이너 홍지흔입니다.
제가 제품을 디자인하는 방식이 지난 몇 달 사이에 통째로 바뀌었는데, 어쩌다 그렇게 됐는지 적어보려고 해요.
지금 제가 개발자에게 넘기는 건 시안이 아니라 코드예요. 디자인이 끝난 화면을 깃에 올려두면 개발자가 그 코드를 받아서 작업해요. 그 화면들이 쌓이는 곳에 Flatr라는 이름을 붙였어요. 피그마에 있던 디자인은 5월부터 옮기기 시작해 지금은 전부 넘어왔고, 새 화면도 여기서 만들어요.
처음부터 이런 걸 만들려던 건 아니에요. 시작은 피그마를 조금 더 잘 쓰려던 것뿐이었어요.
처음에는 피그마를 잘 쓰려고 시작한 자동화였어요
AI를 본격적으로 쓰기 시작하면서 제일 먼저 손댄 건 피그마에서 반복하던 일이었어요. 다양한 컴포넌트 variant를 케이스별로 정의하기, 프레임 이름을 컨벤션대로 정리하기. 크게 고민할 일은 아닌데 매번 반복해야 하고 시간만 오래 걸리는 작업이에요.
그래서 컴포넌트를 케이스별로 정의해주는 플러그인과 프레임 이름을 규칙대로 바꿔주는 플러그인을 직접 만들어서 썼어요. 확실히 편해졌어요. 그런데 쓸수록 이상한 기분이 들었어요. 저는 계속 "피그마 안에서 더 잘하는 방법"만 찾고 있었어요. 그러다 문득 이런 생각이 들었어요. 애초에 피그마여야 할까?
그 의문이 확신이 된 건 단어 드릴 스프린트였어요
단어 드릴은 학생이 단어를 반복해서 익히는 화면이라 이 스프린트는 유독 동적인 요소가 많았어요. 캐릭터가 둥둥 떠 있고, 말풍선이 한 글자씩 타이핑되거나 답을 고르면 피드백이 뜨고, 다음 문제로 넘어가요.
화면 자체가 쉬지 않고 움직이다 보니 디스크립션만으로는 전달이 어려웠어요. 이런 동적인 요소는 제 머릿속에는 분명히 있는데, 그것을 글로 옮기는 일이 만만치 않았어요.
피그마에서는 정지된 그림을 여러 장 그려놓고, 그 사이에 무슨 일이 일어나는지를 글로 적어야 했어요. 그렇게 적어놔도 결국 개발자와 말로 다시 맞춰보는 과정이 따라왔어요.
원하는 걸 확실하게 전달하려면 프로토타입을 만들어야 하는데, 프로토타입 역시 AI로 만드는 쪽이 더 빨랐어요. 피그마에서 안 되는 건 아니지만, 더 편한 길이 따로 있겠다고 생각했어요.
그 스프린트를 하면서 생각이 정리됐어요.
동적인 것을 설명하려고 애쓸 일이 아니라, 동적인 것을 그대로 보여줄 수 있는 환경으로 가야 했어요.
이미 동작하는 걸 정지 화면으로 되돌리고 있었어요
피그마 밖을 생각하게 된 이유가 하나 더 있어요. 비슷한 시기에 PM쌤이 바이브코딩으로 프로토타입을 자주 만드셨어요. 그런데 저는 그 프로토타입을 보면서 피그마로 되돌려 그리고 있었어요. 눈앞에 동작하는 게 있는데 그것을 다시 정지 화면으로 옮기는 셈이었어요.
어느 순간 순서가 거꾸로라는 생각이 들었어요. 저도 같은 환경에서 작업하면서, 프로토타입에 있는 걸 그대로 녹여내는 편이 훨씬 빠르겠다고 판단했어요.
피그마를 잘 쓰고 싶어서 자동화를 시작했는데, 자동화를 하다 보니 툴 바깥이 보였어요.
주말 이틀, 가볍게 시작했어요
그렇다고 바로 회사 작업을 옮길 수는 없었어요. 이 방식이 실제로 되는지부터 확인해야 했고, 진행 중인 스프린트에 차질을 줄 수도 없으니까요. 그래서 주말 이틀 동안 시험 삼아 만들어봤어요. 그게 시작이었어요.
우선 머릿속에 그려둔 대로 Flatr의 뼈대부터 세우고, 기술 스택은 제품과 맞췄어요. 그렇게 환경을 만들어두고 나서 피그마에 있던 걸 조금씩 옮기기 시작했는데, 한 번에 다 옮기기에는 양이 너무 많았어요. 그래서 테스트 때는 당장 그 스프린트에 필요한 것 위주로, 버튼이나 배지, 칩, 체크박스 같은 작은 것부터 가져왔어요.
일단 5월 초 첫 테스트 때는 피그마와 Flatr, 두 벌로 작업했어요. 두 방식을 나란히 놓고 봐야 장단점이 정확하게 보일 것 같았고, 그때는 아직 Flatr를 완전히 신뢰하지 못했어요. 새 방식으로만 갔다가 잘못되면 같이 일하는 그룹에 병목이 생기니까, 만일에 대비해 양쪽을 모두 만들어뒀어요. 다행히 그 스프린트는 별 탈 없이 끝났고, 그다음부터는 Flatr로만 작업하고 있어요.
설명을 쓰는 대신 눌러보게 했어요
가장 크게 바뀐 건 개발자에게 넘기는 결과물이었어요. 예전에는 시안을 그리고 디스크립션을 쓰고, 필요하면 스펙 문서까지 따로 만들었는데, 인터랙션 하나 설명하는 데 몇 문단씩 들어가곤 했어요.
앞에서 "살짝 둥둥 떠 있어요"라고 썼던 그 캐릭터의 실제 값은 0.9초에 한 번, 6픽셀인데, 이런 숫자를 처음부터 글로 적어둘 수는 없어요. 만들면서 이 정도가 자연스럽다고 정한 값이니까요. 말풍선은 더 복잡해서, 한 글자씩 타이핑되는 동안 글자 수에 따라 시간이 달라지고 다 치고 나면 잠깐 머물다 사라지는데, 이 흐름을 글로 옮기려면 문단이 필요하고 그렇게 써놔도 읽는 사람마다 다르게 상상해요.
값은 코드에 있고 움직임은 눈으로 보이니까, 이제 설명할 게 없어졌어요. 구체적으로 미리 다 정해서 개발자에게 전달하니까, 개발 중간에 붙잡고 맞추던 시간이 눈에 띄게 줄었어요.
제품 화면에서 시작해 기능이 하나씩 자리를 잡았어요
정해둔 상태를 한자리에 모아뒀어요
어떤 상태까지 그려둬야 하는지는 예전에도 하나씩 짚어서 정했어요. 빈 상태일 때, 항목이 하나뿐일 때, 로딩 중일 때. 달라진 건 그 결정이 화면으로 나란히 놓인다는 점이에요. 빠뜨린 상태가 있으면 그 자리에서 드러나요. 뒤늦게 누락을 발견해 다시 챙기는 일이 없어졌어요.
그렇게 화면별로 모아둔 곳이 케이스북이에요.
화면이 갖춰지고 나니 흐름을 볼 방법이 필요했어요
여기까지는 기대한 만큼 잘 굴러갔고, 그다음에 보완할 지점이 하나 보였어요.
전체 흐름이 한눈에 들어오지 않는다는 점이었어요. 피그마에서는 아트보드를 나란히 늘어놓고 흐름을 한 번에 봤어요. 학습지 만들기를 누르면 지문을 넣는 화면이 뜨고, 지문을 넣으면 문제를 고르는 단계로 넘어가고, 다 고르면 미리보기가 나오고. 어느 버튼이 어느 화면으로 이어지는지가 그림으로 한눈에 보였어요.
코드로 옮기고 나니 화면은 모두 갖춰졌는데, 화면과 화면 사이의 관계를 담을 자리가 아직 없었어요. 이 화면 다음에 무엇이 오는지 알려면 하나씩 열어봐야 했어요. 화면은 다 만들어졌지만 그 사이를 잇는 그림이 비어 있었던 거예요.
그래서 6월에 Flow라는 걸 만들었어요. 화면들을 흐름대로 늘어놓고, 각 화면이 동작하는 채로 한 판에 펼쳐놓고 보는 화면이에요. 피그마에서 하던 걸 그대로 가져온 셈이에요.
그렇게 주요 기능이 네 개가 됐어요
돌아보니 계속 이 패턴이었어요. "이걸로는 설명이 안 되네" 하는 순간마다 다음 기능이 생겼어요. 이렇게 하나씩 살을 붙이다 보니, Flatr에는 화면 말고도 주요 기능이 네 개 생겼어요.
기능명 | 무엇인가요 | 어떤 불편에서 나왔나요 |
컴포넌트북 | 버튼·배지·모달처럼 화면을 이루는 부품을 크기·상태별로 모아둔 곳 | 같은 버튼을 화면마다 다시 그리고 있었어요 |
케이스북 | 화면 하나를 상태별로 나란히 세워둔 곳. 비어 있을 때, 항목이 하나일 때, 계정 권한이 다를 때 | 정의는 해뒀는데 빠진 게 없는지 한눈에 확인할 곳이 없었어요 |
Flow 보드 | 한 도메인의 화면들을 흐름대로 이어 붙여, 동작하는 채로 한 판에 펼쳐놓은 곳 | 화면은 다 있는데 화면과 화면 사이가 안 보였어요 |
화면 명세 | 화면마다 규칙과 예외를 글로 적어둔 문서 | "이럴 땐 어떻게 되나요"에 매번 다시 답하고 있었어요 |
이제 규칙은 사람이 아니라 AI가 읽어요
이 기능들을 쓰면서 화면 하나를 만드는 순서도 정해졌어요. 제품을 측정하고, 코드로 화면을 만들고, 상태별로 케이스를 등록하고, Flow 보드에 연결하고, 화면 명세를 갱신해요. 그 과정에서 필요한 규칙은 문서로 적어둬요.
”간격은 8의 배수를 먼저 쓴다”, “버튼 폭은 정해진 세 가지만 쓴다”, “어떤 글자 크기는 본문에 쓰지 않는다” 같은 규칙을 기반으로 작업을 진행합니다.
문서를 다시 쓰면서 알게 된 것이 하나 있어요. 문서를 읽는 대상이 사람에서 AI로 바뀌니까 문서가 훨씬 정확해졌어요. 디자이너는 "적당히 여백 있게"라는 말을 들으면 그동안 쌓인 미감으로 그 빈칸을 채울 수 있지만 AI는 그게 안 돼요. 추상적인 지시는 해석하지 못하므로 정확한 가이드와 규칙이 있어야 해요. 그래서 AI가 디자인 일관성을 따라올 수 있는 형태로 문서를 다시 썼어요. 그렇게 고친 문서가 결국 사람이 읽기에도, 검토하기에도 좋은 자산으로 남았어요.
팀도, 제 역할도 달라졌어요
방식이 바뀌니까 따라오는 것들이 있었어요. 좋아진 쪽도 있고, 새로 맡게 된 쪽도 있어요.
팀 전체에 다양한 변화가 나타났어요
아무래도 변화를 제일 크게 체감한 건 개발 쪽이에요. 디자인을 동작까지 구현해서 코드로 전달하다 보니 프론트엔드에서 퍼블리싱에 쓰던 시간이 60% 정도 줄었다고 들었어요. 또한 서로 설명하고 확인하던 과정이 동작하는 화면으로 대체되면서 커뮤니케이션도 한결 편해졌어요.
디자인 속도도 눈에 띄게 빨라졌어요. 사실 올해 초까지만 해도 PD 파트는 PM, FE, BE에 비해 AI를 소극적으로 쓰고 있었어요. 손으로 직접 해야 하는 작업이 많았고, 그러다 보니 저희 쪽에서 병목이 생기기도 했어요. 예전에는 일주일 가까이 걸리던 작업이 지금은 1~2일이면 끝나요.
속도가 붙으니까 생각지 못한 여유가 생겼어요. 화면을 만들어내는 데 대부분의 시간을 쓰던 때는 다음 이야기를 꺼낼 틈이 없었어요. 지금은 그게 빨리 끝나니까 PM쌤과 다음 피처를 더 일찍 이야기해요. 이건 이렇게 풀면 어떨까, 이 흐름은 순서를 바꾸는 편이 자연스럽지 않을까 같은 이야기예요. 만드는 시간이 줄어든 만큼, 무엇을 만들지 이야기하는 시간이 늘었어요.
대신 책임져야 할 게 늘었어요
디자인을 바이브로 하는 것만 놓고 보면 편한 점만 있을 것 같지만, Flatr는 스프린트마다 쓰고 버리는 단편적인 화면이 아니에요. 라이브 환경처럼 화면들이 전부 이어져서 실제로 동작해요. 그래서 제가 기능 하나를 붙이면 그게 다른 데 어떤 영향을 주는지까지 같이 챙겨야 해요.
붙이고 나서 직접 눌러보고 제대로 동작하는지 확인하는 일도 제 몫이 됐어요. 예전에는 시안을 넘기면 거기서 제 일이 끝났는데, 지금은 그게 실제로 굴러가는 것까지 보게 된 거예요. 퍼블리싱이든 사이드 이펙트든, 역할이 넓어진 만큼 책임져야 할 것도 같이 늘었어요.
받는 사람을 생각하게 됐어요
넘기는 과정에서도 시행착오가 있었어요. 제일 컸던 건 제 코드를 그대로 쓸 수는 없다는 점이었어요. 저는 화면이 동작하는 걸 목표로 만들었지, 제품에 바로 들어갈 코드를 목표로 만든 게 아니니까요. 그래서 그대로 코드를 가져가기 보다는 FE가 한 번 변환하고 정제해서 사용하고 있어요.
다만 이건 아직 임시방편이에요. 결과적으로는 제가 만든 코드가 변환 없이 그대로 제품에 들어가는 것을 목표로, PD 파트에서 방법을 찾아나가고 있어요.
화면을 만드는 방식이 바뀌면서 개발 쪽 지식도 자연스럽게 쌓이기 시작했어요. 그러다 보니 만들 때 생각하는 것도 달라졌어요. 이렇게 만들면 뒤에서 이어받는 사람이 편할까, 이 구조가 나중에는 어떻게 될까. 예전에는 화면이 잘 나왔는지에서 제 몫이 끝났는데, 지금은 그다음까지 보게 돼요.
프로덕트를 고민하는 건 원래 PD의 일이지만, 그 고민이 닿는 지점이 구현 쪽으로 한 뼘 더 들어온 것 같아요.
그래도 사람이 채워야 하는 20%가 있어요
이렇게 쓰고 나면 AI가 다 해줄 수 있는 것처럼 들릴 수 있는데, 실제로는 그렇지 않아요.
바이브로 작업하면 80% 완성도는 정말 빠르게 나와요. 문제는 나머지예요. 남은 20%의 디테일은 사람이 직접 손대는 게 더 빠를 때가 많아요. 여기는 몇 픽셀만 더, 이 색은 한 단계 옅게, 이 간격은 좁게. 이런 건 AI에게 설명하는 시간보다 제가 직접 고치는 시간이 짧아요.
AI가 빠르게 뽑아주는 만큼 판단을 미루기 쉬운데, 미루면 결국 어중간한 결과가 나와요.
결국 남는 건 판단이에요
세 달 반 동안 제가 만든 건 화면이라기보다 화면을 만드는 방식에 가까웠어요. 정지된 그림 대신 코드를 넘기는 지금이 확실히 나아요. 설명하고 되묻는 데 쓰던 시간이 줄었어요. 피그마에서는 말로 덧붙여야 했던 것을 동작하는 화면과 코드로 그대로 넘기니까요. 같은 화면을 두 번 만들지 않게 된 만큼 코웍 전체의 속도도 붙었어요.
앞으로도 Flatr를 계속 다듬으면서, 코드와 조금 더 싱크를 맞춰보려고 해요. 그렇게 만들고 md로 정리해두면 크고 작은 디자인 결정이 다시 꺼내 쓰기 쉬운 구조로 남아요. 다음 화면은 0에서 시작하지 않고, 같은 판단을 두 번 할 일도 줄어들어요.
이렇게 많은 게 달라졌지만, 한 가지는 계속 그대로예요. 제가 정확한 의도를 가지고 디렉팅할 때 결과물이 제일 빨리 나와요. 애매하게 시키면 애매한 결과가 나오고, 그것을 고치느라 더 오래 걸려요. 툴이 좋아졌다기보다, 의도가 선명해야 한다는 원칙은 피그마를 쓰던 때와 똑같아요.
손이 가는 일이 줄어든 자리에 남는 건 판단이에요. 디자이너는 판단에 더 집중하게 되고, 결국 그것이 프로덕트 퀄리티로 돌아올 거라고 생각해요.
