10년 차 디자이너의 바이브 코딩 실험기

플로우차트를 피그마 밖으로 꺼내보자

제품을 만들다 보면, 완성된 화면을 흐름으로 보고 싶다는 니즈는 생각보다 흔하다. 피그마에서 협업을 좀 해본 팀이라면 다들 한 번쯤은 느낀다. 화면은 잘 만들어졌는데, 그래서 이게 전체적으로 어떻게 이어지는데? 라는 질문이 꼭 나온다. 하나하나 프레임만 보고 있으면 분명 잘 만든 것 같은데, 전체 유저 플로우로 놓고 보면 갑자기 길을 잃는다. 그래서 플로우차트가 필요해진다. 이건 새로운 욕망도 아니다. 이미 피그마 플러그인도 많고, 피그잼도 있다. 문제는 늘 그렇듯 된다와 쓸 만하다는 다르다는 데 있다.

플러그인은 처음엔 꽤 솔깃하다. 피그마 안에서 바로 선을 잇고 흐름을 볼 수 있으니까. 그런데 조금만 프로젝트가 커지면 금방 숨이 찬다. 디자인 프레임과 플로우차트가 한 파일 안에 같이 있다 보니 일단 보기부터 불편해진다. 화면 정리하려고 열었는데 선이 여기저기 깔려 있고, 연결선도 결국 파일 안에 생성되는 요소라 프레임 수가 슬금슬금 몇 배로 불어난다. 처음엔 괜찮은데, 나중엔 파일이 약간 다이어트 실패한 겨울 패딩처럼 부해진다. 더 큰 문제는 수정이다. 디자인이 바뀌면 연결선도 다시 손봐야 한다. 화면 하나 움직였더니 선이 다 삐뚤어지고, 프레임 구조가 바뀌면 사실상 전면 재시공에 가까워진다. 한 번은 편한데 계속 쓰기엔 피로가 쌓이는 방식이다.

피그잼은 또 다르다. 아이데이션하거나 짧은 유저 패스를 설명할 때는 확실히 좋다. 여기는 오히려 플로우를 그리라고 만든 동네니까 그런 쪽은 편하다. 그런데 제품 전체 흐름을 보기 시작하면 갑자기 일이 커진다. 피그마 디자인을 다시 복사해서 가져와야 하고, 그걸 정리하고, 붙이고, 또 맞춰야 한다. 무엇보다 원본 디자인이 업데이트돼도 피그잼에 가져다 놓은 결과물은 그걸 따라가지 않는다. 다시 말해 복붙한 순간부터 이미 사본 인생이 시작된다. 이게 짧은 회의용 보드라면 괜찮은데, 계속 살아 움직이는 제품 플로우를 다루기엔 점점 버거워진다.

그래서 결론은 꽤 빨리 났다. 플로우차트는 피그마 밖으로 꺼내야 한다는 것. 같이 있으면 편할 것 같지만, 실제로는 분리하는 편이 더 낫겠다는 판단이었다. 다만 그냥 밖으로만 나가면 안 됐다. 제품 원칙은 아주 분명해야 했다. 

첫째, 피그마 디자인과 동기화될 것. 둘째, 수정이나 삭제 같은 변경 내역을 따라갈 것. 셋째, 피그마와 사용 경험이 비슷해서 적응 비용이 낮을 것. 낯선 툴에 입사 교육받는 느낌이 아니라, 피그마 쓰던 사람이 아 이 정도면 바로 쓰겠네 싶어야 했다. 그렇게 직접 만들기 시작한 게 피그마플로우였고, 지금은 약 2달 반 정도 작업한 끝에 베타 런칭을 준비하고 있다. 이번 글은 그 과정에 대해 소개하고자 한다.

‘해줘’로 시작한 바이브 코딩

초기 기획은 전형적인 바이브 코딩식으로 갔다. 먼저 ChatGPT와 계속 대화를 주고받으면서 아이데이션과 기획 초안을 만들었다. 이건 어떤 서비스여야 하는지, 왜 기존 방식이 별로였는지, 어떤 경험은 꼭 지켜야 하는지, 사용자는 어디서 편해야 하는지를 계속 말로 밀고 당기면서 정리했다. 이 단계에서는 정갈한 기획서 한 장보다, 머릿속에 떠다니는 생각을 자꾸 언어로 꺼내는 게 더 중요했다. 

쉽게 말하자면, 처음엔 해줘로 시작하면 된다. 이거 대충 이런 서비스면 좋겠는데, 이런 문제 해결해주는 거 있으면 좋겠는데, 정도로 말을 던진다. 그런데 그렇게 던지면 결과물이 나오긴 나온다. 다만 내가 생각한 토스 같은 매끈한 무언가가 아니라, 어딘가 시중은행 이벤트 페이지에서 굴러다니다 주워 온 포인트 적립 앱 같은 느낌으로 나오기 쉽다. 짜잔 하고 열어봤는데 결과물이 누더기면, 그때부터 치졸해질 순간이다. 

이건 왜 이런지, 저건 어디에 쓰는지, 어떤 상황에서 필요한지, 어떤 식으로 동작해야 하는지 하나씩 설명이 붙는다. 결국 처음부터 맥락을 많이 깔아두는 쪽이 훨씬 낫다는 걸 알게 된다. 원래 좋은 스토리텔러가 도입부에서 빌드업을 탄탄하게 쌓듯, 바이브 코딩도 앞단 설명이 허술하면 뒤가 계속 삐걱거린다.

어느 정도 얼개가 잡힌 뒤에는 그 대화 내용을 바탕으로 실제 개발에 필요한 제품 설계 문서를 만드는 단계로 넘어갔다. 여기서는 역할을 좀 나눴다. 먼저 GPT에 지금까지의 대화를 바탕으로 제품 개발에 필요한 문서를 한 장 정리해달라고 하고, 그걸 다시 제미나이에게 가져가서 조금 더 개발 친화적인 설계서 형태로 정리하게 했다. 쉽게 말하면 GPT랑은 방향과 논리를 맞추고, 제미나이한테는 그걸 좀 더 개발 문서처럼 써달라고 한 셈이다. 

그리고 그렇게 정리된 설계서를 들고, 클로드 코드로 갔다. 사실 이 과정도 처음에는 GPT에서 기획과 코드 구축까지 다 진행했었는데, 뭔가 마음에 안 들어서 다른 AI들에게 똑같이 다 시켜보고 얻은 나름의 방법이다.

개발 환경도 같이 세팅했다. GitHub 저장소를 만들고, Vercel 배포를 연결하고, 저장소와 배포 환경을 붙였다. 다행히 이전에 저장소를 만드는 것과 Vercel 배포는 해본 적이 있어서 문제는 없지만, 처음 해보는 사람이라면 왜 그래야 하는지 의문이 들 법하다. 만약 그런 부분이 있다면 작업하면서 그냥 물어보면 된다. 왜 그렇게 하는지 설명해달라고 하면 또 설명해준다. 그 다음엔 클로드 코드가 작업한 결과물을 보면서 수정 사항을 전달하고, 그걸 다시 고치고, 또 확인하는 방식으로 고도화를 이어갔다. 여기까지만 보면 요즘 말하는 바이브 코딩 성공담처럼 보인다. 대화로 기획하고, 문서로 정리하고, AI한테 코드를 맡기고, 배포까지 금방 연결하는 흐름 말이다. 실제로 초반 속도는 꽤 좋았다.

A를 고치면 B가 터지고, B를 고치면 C가 안 됐다

기본적인 기능을 만들어두는 것까진 됐는데 그 다음이 이제 문제였다. 클로드 코드로 작업을 계속하다 보니 전형적인 꼬임이 시작됐다. A를 고치면 B에서 문제가 터지고, B를 고치면 C가 안 된다. 또 C가 안 되는 상황이랑 B를 고치다가 A가 고장 났다는 걸 다시 설명하면, 이번엔 셋 다 비슷하게 무너져 있거나 갑자기 D에서 오류가 나기 시작한다. 

약간 두더지 잡기인데 두더지가 한 마리씩 나오는 게 아니라 집단으로 튀어나오는 느낌이다. 그래서 뒤늦게 작업 히스토리를 저장해서 맥락을 공유하는 스킬도 붙여보고, 작업 전후를 분석하는 스킬도 써봤다. 그래도 한 번에 여러 작업을 동시에 안정적으로 굴리기엔 한계가 있었다. 계속 요약본을 주고받다 보니 결과물이 아주 미세하게 다른 방향으로 완성되고, 나는 그걸 다시 설명해서 미세하게 교정하고, 그러다 또 다른 데가 어긋나는 식이었다. 빠르게 만들 수는 있는데, 전체 제품 맥락을 일관되게 유지하는 건 또 다른 문제라는 걸 여기서 아주 찐하게 배웠다.

이쯤에서 등장한 게 코덱스였다. 체감상 제일 컸던 차이는, 이쪽은 하나의 GitHub 저장소를 기준으로 프로젝트 전체를 같이 보고 작업한다는 점이었다. 같은 프로젝트 안에서 여러 작업이 동시에 돌아가도, 각각을 따로따로 보는 느낌이 아니라 위에서 전체를 내려다보는 컨트롤 타워가 있는 느낌에 더 가까웠다.

예를 들어, A를 고쳤더니 B에서 문제가 생겼다 싶으면, 그냥 B만 급하게 막는 게 아니라 A의 어떤 변화가 B에 영향을 줬는지를 같이 분석하고, 필요하면 B 구조를 다시 설계하는 식으로 접근했다. 물론 AI인 이상 클로드 코드에서 겪었던 문제가 코덱스에는 아예 없다고 할 수는 없다. 다만 대응 퀄리티와 맥락 유지 측면에서는 확실히 만족도가 높았다. 클로드 코드로 몇 주를 붙잡고 씨름하던 파트가, 코덱스로 넘어간 뒤 며칠 만에 매끄럽게 돌아간 순간도 있었다. 드디어 말이 통하는 외주 개발팀 PM을 만난 느낌에 가까웠다.

만들고 싶은 기능보다 먼저 정해야 하는 것

그다음부터는 무턱대고 기능을 늘리기보다, 어디까지를 베타 제품 범위로 볼지 먼저 정하는 게 중요해졌다. 이걸 안 정하면 일정도 안 나온다. 그래서 내가 생각한 최종 제품 형태를 먼저 전달하고, 이걸 전부 구현하려면 어떤 기능과 기술이 필요한지를 역으로 정리해달라고 했다. 그리고 그 목록을 보고 다시 최소 가치 형태를 좁혔다. 결국 핵심은 하나였다. 피그마에서 디자인을 동기화해서 가져오고, 그걸 연결선으로 이을 수 있어야 한다는 것. 다른 기능은 없어도 이건 반드시 제대로 되어야 했다. 코덱스가 우선순위를 정리해주면, 나는 그걸 조정하거나 그대로 받아서 순차적으로 작업을 진행했다. 스타일 수정이나 UI 조정처럼 영향 범위가 작은 것들은 병렬로 돌리기도 했다.

이 과정에서 꽤 유용했던 제안이 플래그였다. 전후 비교가 필요하거나, 혹시 롤백이 필요할 수도 있으니 개선 전후 디자인 코드를 둘 다 유지한 상태에서 특정 URL 파라미터로 새 버전을 볼 수 있게 하자는 방식이었다. 예전에는 한 번 업데이트하면 배포되기를 기다렸다가 확인하고, 이전 버전을 기억 속에서 더듬으면서 이 부분이 달라졌다고 설명하거나 다시 롤백을 요청해야 했다. 말 그대로 인간 비교 툴로 살고 있었다. 그런데 플래그를 도입한 뒤에는 QA 시간과 품질이 눈에 띄게 좋아졌다.

이전 버전과 개선 버전을 바로 비교할 수 있고, 위험한 변경도 훨씬 덜 불안하게 볼 수 있었다. 바이브 코딩이 빠를수록 이런 장치가 더 중요해진다는 걸 여기서 실감했다. 바꾸는 건 빨라졌는데 비교가 느리면 결국 사람만 고생한다.

물론 제품은 생각보다 자꾸 커졌다. 대표적인 사례가 삭제 처리였다. 프로젝트 파일을 지웠는데, 다른 브라우저에서 접속해보니 삭제가 안 되어 있었다. 왜 삭제한 게 계속 보이냐고 물었더니, 삭제 정보를 클라우드가 아니라 브라우저 쪽에 저장하고 있던 거였다. 여기서 바로 일이 커졌다. 클라우드에 올라간 파일이면 어디서 접속하든 삭제 상태가 일관되어야 하지 않느냐는 질문이 생겼기 때문이다. 

그런데 이걸 진짜 그렇게 만들려면 생각보다 경우의 수가 많다. 브라우저 A와 브라우저 B가 같은 파일을 보고 있을 때 A에서 지우면 B에선 어떻게 보여야 하는지, A에서 지웠는데 B에서 동시에 편집하면 삭제가 우선인지 편집이 우선인지, 편집이 우선이면 삭제는 취소되는 건지 같은 문제들이다. 여기서 다시 확인하게 됐다. 기획 단계에서 엣지 케이스를 최대한 먼저 찾아내고, 이럴 땐 이렇게 처리한다는 제품 정책을 세우는 일이 얼마나 중요한지 말이다.

그리고 그 정책은 화려할수록 좋은 게 아니었다. 오히려 단순하고 일관될수록 훨씬 좋았다. 이유는 너무 현실적이다. 이럴 땐 이렇게, 저럴 땐 저렇게를 다 코드로 써야 하는데, 예외가 많아질수록 구조가 빠르게 복잡해진다. 구조가 복잡해지면 A를 고치다가 B가 꼬이고, B를 고치다가 다른 곳이 터지는 일이 자꾸 생긴다. 결국 제품 정책이 단순할수록 코드도 덜 꼬이고, AI가 구현할 때도 덜 흔들린다. 정리하면 멋진 기능보다 먼저 중요한 건 단순한 규칙이었다. 서비스가 똑똑해 보이는 건 예외를 많이 처리해서가 아니라, 애초에 예외를 적게 만드는 방식으로 설계됐을 때가 많다.

SaaS가 아닌, IaaS(Individual as a Solution)

그렇게 두 달 이상 코덱스와 계속 주고받으면서 고도화를 반복한 끝에, 베타 오픈을 시작했다. 사전 신청 사용자도 100명 이상 확보했다. 그리고 이 과정에서 예상보다 더 흥미로웠던 건 일반 사용자용 제품 그 자체보다, 그 옆에서 어드민과 내부 도구를 만드는 경험이었다. 어드민에는 생각보다 많은 걸 넣을 수 있었다. 구글 애널리틱스를 연결해서 유입 데이터를 가공해 보여주는 대시보드, 클릭과 스크롤 이벤트를 붙여 UI별 행동 로그를 보는 분석 도구, 홍보용 URL 관리와 그 URL로 들어와 신청한 사람 수 추적, 사용자 관리와 사전 신청자 관리 같은 것들 말이다. 예전 같으면 외부 SaaS를 당연하게 붙였을 기능들이, 이제는 필요한 모양대로 꽤 빠르게 구현된다.

이 지점에서 어드민과 내부 도구 구축 쪽의 잠재력을 확실히 봤다. 요즘 SaaS 제품들이 왜 점점 더 생존하기 어려워진다고 하는지 조금은 알 것도 같았다. 예전에는 믹스패널이나 앰플리튜드가 당연한 선택지처럼 느껴졌다면, 지금은 필요한 기능만 콕 집어 직접 만들 수도 있다는 감각이 생긴다. 말만 하면 다 만들어주는데? 같은 순간이 실제로 온다.

다만 여기서 가장 중요했던 건, AI가 구현을 대신해 준다고 해서 제품 판단까지 대신해 주지는 않는다는 점이었다. 실제로 코덱스가 제안한 방식이나 코드를 훑어보다가 내가 먼저 지적한 문제들이 꽤 있었다. 예를 들어, 피그마 로그인을 붙였으면, 그 순간부터 개인정보 처리방침이 필요하다. 피그마 이메일 주소와 사용자명은 개인정보이기 때문이다. 

그런데 코덱스는 로그인 기능을 붙이는 데까지는 아주 매끄럽게 가도, 그다음 운영 요소까지는 알아서 챙기지 않았다. 내가 로그인한 유저들을 어드민에서 관리해야 하지 않느냐고 물어야 사용자 관리가 붙고, 사용자 관리를 한다면 개인정보 처리방침도 있어야 하지 않느냐고 물어야 그제서야 관련 문서가 따라왔다. AI는 정말 뚝딱 잘 만든다. 그런데 그 뚝딱 뒤에 따라와야 하는 정책, 운영, 책임 같은 것들은 사람이 계속 옆에서 봐줘야 한다.

AI 시대의 디자이너는 디렉터가 되어야 한다

결국 이번 작업을 하면서 더 확실해진 건, 바이브 코딩이 디자이너에게 엄청 강력한 도구라는 사실과 동시에 그래서 디자이너의 역할도 바뀐다는 사실이었다. 이제 UI 배경색이 어떻고 폰트 크기가 어떻고를 일일이 붙잡고 첨삭하는 사람에 머무르면 안 된다는 생각이 더 강해졌다. 그런 일은 앞으로 더 빠르게 자동화되거나 보조될 가능성이 크다. 

대신 중요한 건 어떤 규칙으로 제품을 설계할지, 어떤 정책으로 예외를 처리할지, 무엇을 베타 범위에 넣고 무엇을 뒤로 미룰지, 어떤 운영 장치가 반드시 필요한지를 판단하는 능력이다. 쉽게 말하면 디자이너 개인이 AI 부사수를 거느린 작은 디렉터처럼 일할 수 있어야 한다는 뜻이다. 손으로 픽셀을 만지는 시간은 줄어들 수 있지만, 구조를 정하고 기준을 세우는 책임은 오히려 더 커진다.

피그마플로우를 바이브 코딩으로 만든 지난 2달 반은 그래서 단순히 서비스를 하나 만든 경험이라기보다, 디자이너의 일이 어디로 이동하고 있는지를 확인한 시간에 더 가까웠다. 아이디어를 실제 제품으로 빠르게 옮길 수 있는 환경은 분명 혁신적이다. 프로토타입을 넘어 베타 수준까지 밀어붙일 수 있다는 점도 예전과는 다르다. 그런데 그럴수록 더 중요해지는 건 디자인 그 자체보다 디자인을 가능하게 만드는 정책과 구조와 운영이다. 

바이브 코딩은 분명 마법처럼 느껴질 때가 있다. 하지만 그 마법은 혼자 알아서 굴러가지 않는다. 옆에서 계속 질문하고, 방향을 바로잡고, 빠진 걸 챙기고, 예외를 줄여주는 사람이 있어야 한다. 그 역할이 앞으로 디자이너에게 점점 더 중요해질 것이다. 이제 디자이너는 예쁘게 만드는 사람을 넘어, AI 부사수들을 데리고 제품을 끝까지 끌고 가는 작은 디렉터가 되어야 한다. 그걸 못하면 솔직히 앞으로 꽤 힘들어질 것 같다는 생각이다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.