바이브 코딩 완주 회고 : Figma 플러그인 만들기
꽤나 늦은 감이 있지만, 드디어 '바이브 코딩' 경험을 기록하려 합니다.
바이브 코딩으로 UX Writing 플러그인을 만들어 보았습니다. “멋지고 대단한 기능을 만들어 본다”보다는 전체 프로세스를 경험해보고 싶었던 작은 실험의 기록입니다.
바이브 코딩, 한 번은 끝내봐야지
나는 사실 작년부터 관련 영상이나 글을 보며 수차례 시도했던 시기가 있었다. 몇 시간 또는 하루 만에 멋진 결과물을 만들어 낸 사례가 많았기 때문이다. 그러나 나는 단 한 번도 결과를 내보지 못하고 중단한 경험이 다수였는데 여기에는 몇 가지 이유가 있었다.
이왕 시작하는 거 “완성도 있는 결과물이 나와야 하지 않을까” 하는 생각이 들수록 기획은 커졌고 구조는 복잡해졌으며 나로서는 감당하기 어려운 상태가 되어 지레 겁을 먹고 시작도 못하는 경우가 있었고, 온전히 AI에게 설명하며 기능을 구체화하는 것이 내 한없이 얕은 개발 지식으로는 어쩐지 중간부터 부담스러운 상태가 되어버려 결국 흥미를 잃은 채 흐지부지 끝나곤 했다.
이러한 경험은 곧 "언젠가는 해봐야 하는데"라는 조급한 생각만 남겼고 부채감에 압박당하는 몇 개월을 보냈다. 그러다 문득 기준을 낮추고 목표를 재설정해서 다시 해야겠다는 마음이 생겼다. 무언가를 제대로 만들어내겠다는 욕심보다는, 작은 볼륨으로 처음부터 끝까지 한 번 가보는 경험을 해보고 싶었기 때문이다.
그런데 왜 UX Writing이었을까
"끝을 보자"는 목표를 달성하기 위해 가장 익숙한 영역인 UX Writing을 선택했다. 실무에서 실제로 다루고 있고 스스로 결과물에 대한 판단을 할 수 있는 영역이었기 때문이다.
문구를 작성할 때 목적과 맥락을 고려해 표현을 조정해야 하는 것 외에, 이 과정에서 함께 따라오는 판단을 보조하거나 반복적으로 확인해야 하는 작업들이 있다. 예를 들어 컴포넌트 유형에 따라 글자 수를 정의하는 것, 사내 가이드에 맞는지 점검하는 것 등이 그렇다. 이런 작업들은 판단 자체보다는 기준을 참조하고 검증하는 성격에 가깝다.
이번 프로젝트에서는 단순히 문구를 대신 써주는 도구가 아니라 판단을 보조하고 기준을 명확하게 제안하는 도구를 만들고 싶었다. 반복적으로 확인이 필요한 지점에서 도움을 받는 방식이라면 충분히 완성해 볼 수 있는 범위라고 생각했기 때문이다.
작은 범위에서도 충분히 문제를 정의할 수 있다는 점에서 이번 실험의 목적과 잘 맞아떨어졌다.
설계부터 AI를 활용해 보자
프로젝트를 시작하기 전부터 계획했던 부분이 있었는데 실제 구현 이전 단계부터 AI를 의도적으로 활용해 보는 것이었다. 폭넓게 AI를 활용해 보며 전체 흐름을 빠르게 정리하고 검증하기 위함이었다.
전체적인 과정은 이러하다. PRD를 작성하고 기능 테스트용 디자인 프로토타입을 만든 후 Claude, ChatGPT와 대화를 통해 코드를 구현했다.
먼저, Vooster AI와 대화를 통해 PRD 초안을 구체화했다. 이 실험에서 다루는 문제와 범위를 명확하게 정의하는 데에 집중했다. (특히 무엇을 만들지 않을 것인가를 정리하는 과정에서 큰 도움을 받았다.) 디자인 역시 같은 기준으로 접근했는데, 완성도 높은 시각적 디테일보다는 Figma Make를 사용해서 기능의 흐름과 구조가 실제로 성립하는지 빠르게 검토했다. 아래는 초기 디자인이다. 처음에는 글자 수부터 맞춤법 검사, 문구 추천을 받을 수 있는 플러그인을 구상했기 때문에 다양한 케이스를 고려하여 진행했다.
Figma Make로 구현한 플러그인 디자인중간 점검, 기능 범위를 재조정하다
솔직히 말하면 초기 단계에서는 기능에 대한 욕심도 조금 있었다.
글자 수, 맞춤법 검사 기능부터 시작하여 문구 추천까지 확장하는 방향을 검토했었는데 구현 과정에서 현실적인 조정이 필요했다. 먼저 한글 맞춤법 기능의 경우, 오픈소스 접근에 제약이 있어 여러 시행착오를 겪고 제외하기로 결정했다.
문구 추천 기능도 외부 llm을 쓰게되면 API Key 관리, 호출 비용, 사용량 통제 등을 함께 고려해야 했기 때문에 개인 실험의 범위를 넘어선다고 생각했다. 그래서 문구 추천 기능은 사용자가 자신의 API Key를 직접 입력해 사용하는 방식으로 재설계했다. 추천 기능을 사용하고 싶은 사람이 자신의 Key를 직접 관리하고 필요할 때 선택적으로 사용할 수 있도록 말이다.
API 키가 연결되면 상태를 확인할 수 있다UX Writing 규칙을
코드가 이해하는 형태로 옮기다
실무에서 참고하고 있는 UX Writing 가이드는 그동안 문서 형태로 관리되고 있다. 맥락 설명이나 예외 케이스를 담으며 해석할 수 있도록 되어있는데 실제 플러그인에서는 구조로 이해할 수 있는 방식이 필요했다.
시스템이 사용하는 규칙은 해석의 여지가 없어야 하고 조건에 따라 일관되게 작동해야 하기 때문이다. 그래서 코드가 반복적으로 활용할 수 있는 형태로 규칙을 재정의하기 위해 JSON으로 적용하는 작업을 먼저 진행했다.
노션에 정리한 라이팅 가이드를 JSON으로 변경했다(1) 컴포넌트 유형별 권장 글자 수를 명시하고 (2) 특정 조건에서만 적용되는 가이드는 분기 구조로 나누고 (3) 문장 규칙이 조건과 값의 조합으로 표현되도록 했다. 이 과정에서는 ChatGPT를 활용하여 내가 표로 규칙을 정리하면 GPT가 JSON 구조로 만들어주는 식으로 진행했다.
완벽한 바이브코딩은 아니었지만
돌이켜보면 사실 일반적으로 이야기하는 100% 바이브코딩은 아니었던 것 같다. 원래 계획은 Cursor나 Google AI Studio를 활용하여 코드를 생성하도록 진행할 예정이었으나, 플러그인 만드는 과정을 이해하기 위해 ChatGPT에 질문과 수정을 요청하는 과정을 반복하며 스스로 고쳐보는 형식으로 진행했다. (초반에는 클로드를 사용했었는데, 내 프롬프트의 문제인지 에러의 원인을 비개발자가 이해할 수 있도록 쉽게 설명하지 못하는 것 같아 중간에 GPT로 변경했다.)
AI에게 완전히 맡기기보다는, 이해할 수 있고 진행할 수 있는 단계로 쪼개달라 요청했고 완료한 후 다음 단계로 넘어가도록 말이다.
당시에는 우선적으로 “이해”를 한 상태로 만들고 싶어서 그랬는데, 실제로 대부분의 과정이 AI가 만들어준 코드를 그대로 복붙해가면서 생기는 이슈에 대해 재문의하고 왜 이렇게 동작하는지, 이 로직이 이 위치에 있어야 하는지 등을 묻는 식이었기 때문에 시간이 꽤나 걸렸다. 한 3주 정도?
최종적으로 구현한 기능은 단순하다
들인 시간에 비해 실제로 만든 테스트 버전 플러그인은 참 단순하다.
선택한 텍스트의 글자 수를 자동으로 계산하는 기능
JSON으로 정의한 라이팅 규칙을 반영한 가이드와 컴포넌트별 권장 글자 수 안내 기능
가이드를 기반으로 톤 앤 매너에 맞는 추천 문구 제안 기능
제안된 문구를 복사해서 바로 사용할 수 있는 인터랙션
완성도가 높다고 말하기는 어렵지만 결과물보다는 기능을 구성하고 연결하는 사고 과정을 직접 진행하며 구현했다는 점에서 첫 경험으로는 의미가 있었다.
아쉽게도 개발 지식은 많이 남지 않았다
이 프로젝트를 통해 많은 개발 지식을 얻었다고 생각하지는 않는다. 여전히 혼자서 구조를 처음부터 설계할 수 없고, 모르는 것이 훨씬 많다.
그럼에도 분명하게 남은 것은 하나 있다면, 아이디어를 처음부터 끝까지 구현하며 프로세스를 완결해 본 경험이다. 어디에서 막히는지, 어떤 질문을 던져야 다음 단계로 나아갈 수 있게 AI를 잘 활용할 수 있는지, 무엇을 덜어내야 끝까지 갈 수 있는지 정리해 볼 수 있었다. 덕분에 또 다른 작은 프로젝트 플래닝을 진행할 수 있게 되었다.
AI를 활용하며 배운 것들
이번 프로젝트를 통해 AI 활용에 대해 정리한 몇 가지 인사이트가 있다.
➡️ AI 덕분에 “덜” 고민했던 것
UI 초기 형태
Figma Make를 활용하여 러프한 화면 구조를 실행해 볼 수 있었기 때문에 와이어프레임, 레이아웃을 설계하는 데 시간을 많이 소요하지 않았다. 완성도 높은 화면을 구현하는 대신, 기능 간의 흐름이 성립하는지 빠르게 확인해 볼 수 있었다.
기술적 진입 장벽
AI와의 대화가 개발을 모르는 디자이너의 답답함과 막힘을 완전히 해결해 준 것은 아니었지만 중간에서 멈추지 않고 다음으로 이어갈 수 있도록 만들어 주었다.
➡️ 오히려 “더” 고민해야 했던 것
PRD의 중요성
PRD가 단순 요구사항 정의서가 아니라 실험의 경계를 설정하는 역할로 작동하게 하려면 무엇을 만들지 않을 것인지 정하는 것이 중요했다. 범위를 명확히 정의하지 않으면 AI가 기능을 계속 확장해서 제안하기 때문에 볼륨이 커져가는 문제가 생기기 때문이다.
사람과 시스템 간의 가이드 구분
UX Writing 가이드를 JSON으로 구조화하면서 모든 가이드 규칙을 코드로 옮길 수 없다는 것을 확인했다. 설명과 맥락을 포함하는 사람 버전 가이드와 조건과 값으로 작동해야 하는 시스템 버전 규칙을 분리하고 어디까지 해석의 영역으로 남길지에 대해 더 많은 고민을 해야만 했다.
최종 판단 권한
AI가 제안한 문구의 기준을 정의하고 최종 선택을 해야 하는 주체는 사람이어야 했기 때문에, 어떤 기준을 남기고 어떤 판단을 직접 해야 하는지를 정하는 판단의 밀도가 더 중요했다.
가볍게 시작했기 때문에 가능했다
이번 경험을 통해 모든 시도가 처음부터 완벽할 필요가 없다는 것을 배웠다. 작게 시작하더라도 끝까지 가본 경험은 다음의 많은 시도를 가능하게 만든다는 것을 알게 됐기 때문이다.
물론 그 과정 속에서 모든 것을 완벽하게 이해하며 넘어가지는 못했지만, 시도해 본 것 그리고 결국 완성해 낸 것에 의의를 둔다.
다음 실험에서는 좀 더 복잡한 데이터 구조를 다루거나, 실제 팀원들과 함께 사용할 수 있는 협업 도구를 만들어보고 싶다. 언젠가 더 정교한 서비스를 만들기까지, 이런저런 방식의 실험을 계속 이어갈 예정이다.
문제 정의와 본질에 집중하기 위해 고군분투했던 과정을 기록하며 회고합니다. 커리어 관련된 이야기를 하는 것을 좋아합니다. 커피챗은 언제나 환영이에요!
