디자이너가 48시간만에 만든 Figma Plugin

안녕하세요. 라포랩스의 플랫폼 디자이너 문대형입니다.

이 글에서는 제가 Cursor AI로 Figma 플러그인을 직접 개발하여 자동화 시스템의 비효율을 해소한 과정을 담고 있습니다. 왜 플러그인을 만들게 되었는지, Cursor의 장점과 플러그인 개발을 시작하는 방법, 작업 과정과 성과 등을 담았습니다. 바이브코딩을 시작하려는 디자이너 분들께 이 글이 도움이 되길 바랍니다.

효율적인 자동화 이면의 비효율

라포랩스에는 업무 효율을 높이는 여러 시스템들이 있지만 그 중 한 가지로 애셋 자동화 시스템을 소개해드리고 싶습니다.

이 자동화 시스템은 피그마에서 제작한 디자인 애셋을 라이브러리 저장소로 바로 배포해주는 역할을 합니다. 덕분에 엔지니어 도움없이 애셋을 생성하고 수정할 수 있어, 소통 비용을 크게 줄이고 생산성을 높이는 고마운 존재입니다.

디자이너가 직접 애셋을 등록하고 관리하기 때문에, 정해진 이름 규칙을 지키기만 하면 배포가 원활하게 진행됩니다.

하지만 사람이 하다보니 의도치않게 규칙을 어길 때가 있습니다. 잘못 배포하면 에러로 이어지기 때문에 고치고 다시 배포해야합니다. 성공할 때까지 디자이너와 개발자 모두 기다려야 하는거죠. 배포 1회당 보통 15분 소요되므로 한 번에 수정을 성공해도 30분이 소요되는 셈입니다. 여기서 에러의 원인을 한 번에 찾지 못하면 그만큼 시간이 지체됩니다. 퀸잇의 제품 규모가 커진만큼 애셋수도 1,000개 이상으로 늘어났기에 원인이 불명확해지면 디자이너는 그때마다 무엇이 잘못되었는지 일일이 찾아 봐야했습니다.

진짜 문제는 ‘불명확한 원인’

가장 큰 문제는 시스템 문제로 배포가 실패하는 경우입니다. 디자이너는 배포 실패의 원인이 정확히 무엇인지 모르기 때문이죠. 실패 후 작업자는 검수와 실패를 반복하며 긴 시간을 보내다 결국 엔지니어에게 도움을 요청하게 됩니다.

얼마 전, 디자이너 한 분께서 여러 차례 배포 실패를 겪다 엔지니어에게 도움을 요청했습니다. 밝혀진 원인은 허무하게도 토큰 만료였습니다. 휴먼 에러는 아니었지만, 문제 원인을 찾느라 아까운 시간을 허비해야 했습니다. 반나절 동안의 상황을 지켜보면서 이 문제가 언제든 다시 반복될 수 있는 문제라 생각했고 최소한의 리소스로 비효율을 해결 할 수 있는 방법을 고민했습니다.

비효율은 언제 시작될까요?

배포 실패 원인이 무엇인지 모르는 작업자는 일단 내부에서 그 원인을 찾기 시작합니다. 바로 Figma를 보며 문제를 찾는 이때가 비효율이 증가하는 시점이었습니다. 그리고 Figma에서 미리 에러 여부를 알 수 있는 플러그인이 있으면 여러 문제가 한 번에 해결 될 것 같았습니다. 검수에 걸리는 수고와 시간도 아낄뿐더러, 무결점 상태에서 배포 실패가 뜨면 시스템 문제임을 바로 알 수 있기 때문입니다.

어떻게 만들까 다음 단계로 넘어갑니다.

라포랩스의 엔지니어분들은 내부에 기술적 불편이 있을 때마다 기꺼이 발 벗고 나서주시는 감사한 존재들인데 이때가 다들 한창 바쁜 시기였기에 고민하다 GPT와 구현 논의를 해봤습니다. 알고보니 이 플러그인을 만드는데 필요한 API는 Figma에서 모두 제공하고 있어서 구현 난이도가 높지 않아보였습니다. 그래서 AI의 도움을 받아 혼자 해결 해보기로 했습니다.

GPT에서 Cursor로

Cursor의 뛰어난 편의성 덕분에 이미 많은 분들이 사용하고 계시지만, 개발환경이 익숙치 않거나 GPT에 더해 Cursor까지 추가로 구독하는게 망설여지는 분도 있을 것 같습니다. 하지만 개발을 해서라도 꼭 해결하고 싶은 문제가 있다면 꼭 써보실 것을 권하고 싶습니다.

그 이유로 첫번째, 개발이 쉽고 빠릅니다. 코드 에디터 내에 AI가 있으니 작업 속도가 월등히 빠릅니다. 필요한 패키지들을 알아서 설치해주고, GPT로 개발 할 때 번거로웠던 코드 복붙, 에러화면 복붙을 하지 않아도 됩니다.

두번째, 빌드 에러를 경험할 확률이 낮습니다. GPT와 달리 Cursor의 에이전트가 전체 파일을 훑어보면서 의존성을 체크하고 디버깅도 해주기 때문에, 빌드 에러를 볼 일이 많이 줄어듭니다. 만약 계속 풀리지 않는 에러가 있다고 해도 스스로 디버깅 환경을 만들어 진단 데이터 복붙을 사용자에게 요청하기도 합니다. 심지어 API 미지원 등을 이유로 개발이 안되는 요구사항이면 안된다고 솔직하게 말합니다.

마지막으로, 잘 작동하던 과거로 되돌릴 수 있습니다. GPT에서 추가 코드를 넣다가 문제가 생기면 정확한 복구 시점을 확인하고 되돌리는데 시간이 걸렸습니다. 반면, Cursor에서는 Restore Checkpoint로 간단하게 돌아갈 수 있습니다. 이 덕분에 다양한 디자인 실험들을 편하게 해볼 수 있었습니다.

일전에 GPT로 간단한 플러그인을 만든 적이 있었는데 운 좋게(?) 완성한 느낌이었습니다. Cursor로 개발할 때는 동작 원리를 이해하고 진척도를 컨트롤 할 수 있어서 요청자도 제작 과정을 잘 이해 할 수 있었습니다.

기획부터 완성까지

준비가 끝났으니 GPT에게 구현 논의한 쓰레드를 바탕으로 PRD 제작을 요청하고, 이 내용을 Cursor에게 전달하여 제작을 시작합니다.

실제 프로젝트와 같이 처음에는 MVP로 시작합니다. 한번에 만들지 않고 먼저 올바른 접두사를 썼는지 확인하는 검수로직 하나만 만들어줄 것을 요청합니다. 첫번째 검수 로직이 만들어진 것을 확인하고 나머지 검수 로직도 차례대로 추가합니다.

디자이너분들이 좀 더 쓰기 좋도록 사용성도 개선합니다.

오류 애셋을 발견하면 수정하러 가야하니 선택할 수 있도록 ‘바로 가기’ 버튼을 추가하고, 중복 애셋은 모두 선택되도록 합니다. 어떻게 수정해야 하는지도 궁금할 수 있으니 각 에러마다 원인과 함께 올바른 가이드라인도 함께 제공합니다. 작동 상태를 더 명확히 알려주기 위해 검수 중, 검수 결과 같은 상태 메시지와 타임스탬프도 추가합니다.

이런 디테일한 개선들은 디자이너라면 중요하게 생각하고 핸드오프 때 전달하는 요구사항들인데 직접 개발이 가능한 상태에서 속도감있게 시도해볼 수 있어 재밌었습니다.

Cursor에 프롬프트를 쓸 때 구체적인 개발 용어를 써가며 요청한 게 아니고 위에 쓴 설명과 크게 다르지 않았습니다. 예를 들면, “OOO 디자인 시스템으로 UI를 변경해줘”, “첨부한 ‘UX라이팅원칙.PDF’ 문서를 참고해서 모든 문구를 다듬어줘”처럼 간단한 명령으로 디자인 일관성을 빠르게 높인 요청들도 있었습니다.

마지막으로 자동화 시스템과 유사한 검수 환경을 만듭니다. 자동화 시스템은 배포 과정에서 애셋 이름을 올바른 형식에 맞게 가공해주는 문자열 정규화 로직이 있습니다. 플러그인에도 동일한 로직을 추가하여 불필요한 에러수를 줄이면 사실상 개발이 끝납니다.

이 모든 과정이 단 이틀 걸렸습니다.

플러그인이 바꾼 것들

플러그인을 공개했을 때 디자이너분들께서 정말 많이 좋아해주셨습니다. 15분의 기다림 없이 단 ‘1초’만에 에러 여부를 알 수 있게되었기 때문이죠.

또, 플러그인 배포한 지 4주가 지난 지금 배포 실패 사례가 아직까지 한번도 발생하지 않았습니다. 매달 5~15회 정도 실패했던 것을 감안하면 Figma 단계에서 실수를 막는 게 올바른 문제해결 방향이 맞았던거죠.

무엇보다 좋았던 사실은 디자이너 혼자 제품을 개발한 경험이 서로에게 동기부여가 되었다는 점입니다. 이미 라포랩스의 디자이너분들은 매주 1회 진행하는 퀄리티데이 시간을 통해 플러그인 뿐만 아니라 GPTs, 자체적으로 학습시킨 생성형 AI를 을 만들어 실무의 비효율을 해결한 사례가 여럿 있습니다. (머지않아 라포랩스 디자이너분들의 또다른 AI 문제해결 사례를 기다려주세요!) 그러면서 서로가 서로에게 자신의 노하우를 공유하기 때문에 AI 역량을 성장시키는 측면에서 선순환을 만들어내고 있습니다.

이번 사례로 프로덕트 디자이너도 Cursor 유료 플랜 구독을 지원받았으며 일부 멤버는 벌써 새로운 프로젝트를 진행하고 있습니다.

마치며

이번에 만든 Figma 플러그인은 기존 시스템의 사용성을 높이는 데 실질적인 기여를 했습니다. 디자이너가 직접 개발이라는 기존과 다른 프로세스를 시도했지만, 사용자의 불편을 감지하고 최선의 해결책을 설계하는 과정은 우리가 늘 해오던 디자인의 본질과 다르지 않았습니다.

결국 달라진 건 ‘AI’라는 수단뿐이었습니다.

새로운 AI 도구를 빠르게 익히는 것도 중요하지만, 무엇보다 어떤 문제를 풀 것인가에 대한 고민을 우선하는게 더 중요하다는 생각을 했습니다. AI가 직무의 한계를 넘어선 문제 해결에 도움을 줄 수 있는만큼, 앞으로 과거에 미뤄뒀던 문제나 지금 당면한 문제가 여전히 해결하기 어려운지 다시 돌아보고 디자인 챕터원분들과 함께 풀어나갈 예정입니다.