디자이너가 Figma 플러그인을 직접 만들었다 — 3주간의 바이브 코딩 회고

바이브 코딩이라는 말이 돌기 시작한 게 작년이었잖아요. 몇 시간, 길어야 하루면 결과물이 나온다는 사례가 넘쳐났고, "나도 해봐야지" 하는 마음이 안 생길 수가 없었겠죠. 근데 한 번도 끝까지 가본 적이 없는 사람의 이야기가 여기에 있어요.

"이왕 하는 거 완성도 있어야 하지 않을까?" 생각이 들수록 기획은 커졌고, 구조는 복잡해졌고, 얕은 개발 지식으로는 중간부터 감당이 안 되더라고요. 흥미를 잃은 채 흐지부지 끝나곤 했어요. 남은 건 "언젠가는 해봐야 하는데"라는 조급함, 그리고 부채감에 짓눌리는 몇 달. 어디서 많이 들어본 패턴 아닌가요.

그러다 기준을 낮추기로 했어요. 멋진 결과물을 만들겠다는 욕심 대신, 작은 볼륨으로 처음부터 끝까지 한 번 가보는 경험. 그게 이번 실험의 목표였어요.

왜 하필 UX Writing이었나

"끝을 보자"는 목표를 달성하려면 가장 익숙한 영역이어야 했어요. UX Writing을 선택한 이유가 그거예요. 실무에서 실제로 다루고 있고, 결과물에 대한 판단을 스스로 할 수 있는 영역이니까요.

문구를 작성할 때 목적과 맥락을 고려해 표현을 조정하는 것 외에, 함께 따라오는 판단 보조 작업들이 있거든요. 컴포넌트 유형에 따라 글자 수를 정의하는 것, 사내 가이드에 맞는지 점검하는 것 등. 이런 작업들은 판단 자체보다는 기준을 참조하고 검증하는 성격에 가깝잖아요.

이번에 만들고 싶었던 건 문구를 대신 써주는 도구가 아니었어요. 판단을 보조하고 기준을 명확하게 제안하는 도구. 반복적으로 확인이 필요한 지점에서 도움을 받는 방식이라면 충분히 완성할 수 있는 범위라고 봤거든요.

PRD부터 프로토타입까지, 설계 단계에서도 AI를 썼다

프로젝트 시작 전부터 계획했던 게 있었어요. 구현 이전 단계부터 AI를 의도적으로 활용해 보는 것. 전체 흐름을 빠르게 정리하고 검증하기 위해서였어요.

과정은 이랬어요. Vooster AI와 대화를 통해 PRD 초안을 구체화했어요. 이 실험에서 다루는 문제와 범위를 명확하게 정의하는 데 집중했는데, 특히 '무엇을 만들지 않을 것인가'를 정리하는 과정에서 큰 도움을 받았어요. (이게 생각보다 중요하더라고요. 범위를 안 정하면 AI가 기능을 계속 확장해서 제안하거든요. 볼륨이 끝없이 커져요.)

디자인도 같은 기준으로 접근했어요. 완성도 높은 시각적 디테일보다는 Figma Make를 사용해서 기능의 흐름과 구조가 실제로 성립하는지 빠르게 검토했어요.

처음에는 글자 수 체크부터 맞춤법 검사, 문구 추천까지 받을 수 있는 플러그인을 구상했거든요. 그래서 다양한 케이스를 고려하며 초기 디자인을 잡았어요.

기능 범위를 깎아냈다 — 현실과 타협한 지점들

솔직히 초기에는 욕심이 좀 있었어요.

글자 수, 맞춤법, 문구 추천까지 다 넣으려고 했는데, 구현 과정에서 현실적인 조정이 필요했어요. 한글 맞춤법 기능은 오픈소스 접근에 제약이 있어서 여러 시행착오를 겪고 제외했어요. 문구 추천 기능도 외부 LLM을 쓰려면 API Key 관리, 호출 비용, 사용량 통제를 함께 고려해야 하니까 개인 실험 범위를 넘어선다고 판단했거든요.

결국 문구 추천 기능은 사용자가 자신의 API Key를 직접 입력해 사용하는 방식으로 재설계했어요. 쓰고 싶은 사람이 자기 Key를 직접 관리하고, 필요할 때 선택적으로 사용하는 구조.

기능을 깎아내는 과정이 아깝지 않았냐고요? 오히려 이때 가장 많이 배웠어요. 뭘 빼야 끝까지 갈 수 있는지를 아는 게 PRD의 핵심이었으니까요.

UX Writing 가이드를 JSON으로 바꾸는 건 번역에 가까웠다

실무에서 참고하는 UX Writing 가이드는 그동안 문서 형태로 관리되고 있었어요. 맥락 설명이나 예외 케이스를 담아서 사람이 해석할 수 있도록 되어 있었는데, 플러그인에서는 코드가 이해할 수 있는 구조가 필요했어요. 시스템이 사용하는 규칙은 해석의 여지가 없어야 하고, 조건에 따라 일관되게 작동해야 하니까요.

컴포넌트 유형별 권장 글자 수를 명시하고, 특정 조건에서만 적용되는 가이드는 분기 구조로 나누고, 문장 규칙이 조건과 값의 조합으로 표현되도록 했어요. ChatGPT를 활용해서 표로 규칙을 정리하면 GPT가 JSON 구조로 만들어주는 식으로 진행했거든요.

근데 이 과정에서 깨달은 게 있어요. 모든 가이드 규칙을 코드로 옮길 수는 없다는 것. 설명과 맥락을 포함하는 사람 버전 가이드와, 조건과 값으로 작동하는 시스템 버전 규칙은 분리해야 했어요. 어디까지 코드에 맡기고 어디부터 해석의 영역으로 남길지. 이 경계를 정하는 게 기술적 문제라기보다 판단의 문제였어요.

100% 바이브 코딩은 아니었다 — 그래서 3주 걸렸다

돌이켜보면 일반적으로 말하는 바이브 코딩과는 좀 달랐어요. 원래 계획은 Cursor나 Google AI Studio를 활용해서 코드를 생성하는 방식이었는데, 플러그인 만드는 과정을 이해하기 위해 ChatGPT에 질문과 수정을 반복하며 직접 고쳐보는 형식으로 진행했거든요. (초반에는 Claude를 썼는데, 에러의 원인을 비개발자가 이해할 수 있게 쉽게 설명하지 못하는 것 같아서 중간에 GPT로 갈아탔어요.)

AI에게 완전히 맡기기보다는, 이해할 수 있고 진행할 수 있는 단계로 쪼개달라고 요청했어요. 한 단계 완료한 뒤 다음 단계로 넘어가는 식이었죠.

실제로 대부분의 과정이 AI가 만들어준 코드를 그대로 복붙하다가 생기는 이슈에 대해 재문의하고, 왜 이렇게 동작하는지, 이 로직이 이 위치에 있어야 하는지 묻는 식이었거든요. 시간이 꽤 걸렸어요. 한 3주 정도.

3주. 바이브 코딩 사례들이 보통 몇 시간이라고 하잖아요. (솔직히 좀 민망했어요.)

결과물은 단순하다 — 들인 시간에 비해서

들인 시간에 비해 실제로 만든 테스트 버전 플러그인은 단순한 편이에요. 선택한 텍스트의 글자 수를 자동으로 계산하는 기능, JSON으로 정의한 라이팅 규칙을 반영한 가이드와 컴포넌트별 권장 글자 수 안내, 가이드 기반으로 톤 앤 매너에 맞는 추천 문구 제안, 제안된 문구를 복사해서 바로 쓸 수 있는 인터랙션. 그게 다예요.

완성도가 높다고 말하기는 어렵지만, 기능을 구성하고 연결하는 사고 과정을 직접 진행하며 구현했다는 점에서 첫 경험으로는 의미가 있었어요.

개발 지식이 많이 남았느냐고 물으면, 솔직히 아니에요. 여전히 혼자서 구조를 처음부터 설계할 수 없고, 모르는 게 훨씬 많아요.

AI 덕분에 "덜" 고민한 것, "더" 고민해야 했던 것

분명하게 남은 게 하나 있다면, 아이디어를 처음부터 끝까지 구현하며 프로세스를 완결해 본 경험이에요. 어디에서 막히는지, 어떤 질문을 던져야 다음 단계로 나아갈 수 있는지, 무엇을 덜어내야 끝까지 갈 수 있는지 정리해 볼 수 있었거든요.

AI 덕분에 덜 고민했던 것도 있어요. UI 초기 형태는 Figma Make를 활용해서 와이어프레임이나 레이아웃 설계에 시간을 많이 쓰지 않았어요. 기능 간의 흐름이 성립하는지 빠르게 확인할 수 있었죠. 기술적 진입 장벽도 마찬가지예요. AI와의 대화가 개발을 모르는 디자이너의 막힘을 완전히 해결해 주진 않았지만, 중간에서 멈추지 않고 다음으로 이어갈 수 있게 만들어줬어요.

반면에 오히려 더 고민해야 했던 것도 있었어요. PRD가 단순한 요구사항 정의서가 아니라 실험의 경계를 설정하는 역할로 작동하게 하려면, 무엇을 만들지 않을 것인지 정하는 게 정말 중요했어요. 범위를 명확히 정의하지 않으면 AI가 기능을 계속 확장해서 제안하거든요. UX Writing 가이드를 JSON으로 구조화하면서는 사람 버전 가이드와 시스템 버전 규칙을 분리하고 어디까지 해석의 영역으로 남길지에 대해 훨씬 많은 고민을 해야 했어요.

그리고 최종 판단 권한. AI가 제안한 문구의 기준을 정의하고 최종 선택을 해야 하는 주체는 사람이어야 했기 때문에, 어떤 기준을 남기고 어떤 판단을 직접 해야 하는지. 판단의 밀도가 도구보다 더 중요했어요.

작게 시작했기 때문에 끝까지 갔다

모든 시도가 처음부터 완벽할 필요 없다는 거. 뻔한 말 같지만 직접 겪어보니까 다르더라고요. 3주 동안 모든 것을 완벽하게 이해하며 넘어가지는 못했어요. 근데 시도한 것, 그리고 결국 완성한 것. 거기에 의의를 두기로 했어요.

다음 실험에서는 좀 더 복잡한 데이터 구조를 다루거나, 실제 팀원들과 함께 쓸 수 있는 협업 도구를 만들어보고 싶다고 하더라고요. 결국 한 바퀴를 돌아본 사람만이 두 번째 바퀴의 크기를 가늠할 수 있는 거니까요.