시작: 첫 커밋의 긴장감

처음으로 개발 브랜치에 코드를 푸시하던 순간이 기억난다. Cursor에서 커밋 메시지를 작성하고 푸시 버튼을 누르기 전 몇 초간 망설였다. "내 코드가 다른 개발자들의 작업을 망치는 건 아닐까?" 하는 두려움이었다. 하지만 그 커밋 이후, 디자이너로서 제품을 만드는 방식이 완전히 달라졌다.

우리가 마주한 문제

프로덕트 디자이너는 전통적으로 제품 개발의 앞단에 위치한다. 리서치하고, 디자인하고, 프로토타입을 만들고, 팀·고객과 의견을 조율하며 디자인을 발전시킨다. 그리고 Figma 형태로 디자인을 개발자에게 전달한다. 개발자는 Figma를 코드로 구현한다.

이 과정에서 많은 손실이 발생한다. 디자이너의 의도를 제대로 구현하기 위해 디자이너는 Figma를 자세히 만들어야 하고, 개발자와 지속적인 의사소통과 완성된 코드 테스트를 반복해야 한다. 모두가 최선의 노력을 했음에도 불구하고 디자인과 코드 사이의 불일치가 종종 발생한다.

"디자이너가 개발자에게 이렇게 해주세요, 저렇게 해주세요 하는 대신 직접 디자인과 인터랙션을 구현하면 완성도가 높아지지 않을까?"

이 질문에서 새로운 시도가 시작되었다.

AI Agent Studio 프로젝트

최근 AppZen에서 AI Agent Studio를 출시했다. Enterprise의 Finance 팀이 그들의 financial operation에 맞는 AI Agent를 만들고 테스트하고 적용할 수 있는 플랫폼 제품이다. 나는 이 제품의 디자이너로 개발에 참여하고 있다.

이 제품을 만드는 과정에서 기존 프로덕트 디자이너의 영역을 확장하는 시도를 하고 있다. Figma를 개발자에게 전달하는 대신, Cursor와 Claude Code를 사용해서 직접 코드를 development branch에 푸시하는 것이다.

결과적으로 이 과정을 통해 제품의 완성도가 높아졌다. 아직 나와 우리 팀 멤버들도 어떻게 하는 것이 좋은지 실험하는 단계지만, 그 과정을 공유하고 싶다.

머지않은 미래에 디자이너, 개발자, 프로덕트 매니저의 경계는 없어지고 모두 빌더가 될 것이라고 믿는다. 디자인에 강점이 있는 빌더, 개발에 강점이 있는 빌더라는 식으로 말이다. 새로운 시도를 함께 하고 있는 Tiffany Choy, Sonal Pansari, Damian Bocanegra에게 다시 한번 고마움을 전하고 싶다.

준비: 기술 스택과 워크플로우 설정

프로젝트를 시작하던 시점에 우리는 새로운 frontend tech stack을 고민하고 있었다. 마침 Cursor, Claude Code, Codex와 같은 바이브 코딩 툴들이 엄청난 가능성을 보이고 있었다. 우리는 최대한 바이브 코딩을 도입하고 싶었다. 그래서 바이브 코딩에 친화적이라고 생각되는 플랫폼을 선택했다. AI Agent Studio는 Next.js, Tailwind, ShadCN을 적극 활용한다.

디자이너인 내가 code repository에 code를 어떻게 푸시할지에 대한 의견 교환이 선행되었다. 나는 예전에 Adobe에서 UX Engineer로 근무했던 경력이 있다. 다른 개발자와 iOS 앱 개발 협업을 한 경험이 있기 때문에 모든 것을 처음부터 배워야 하는 상황은 아니었다.

그럼에도 불구하고 실제 코드를 건드리는 것에 대한 두려움이 있었다. 내가 혹시 동료들의 작업을 오히려 방해하는 것은 아닌지, 나 때문에 할 일이 더 늘어나는 것은 아닌지 하는 두려움 말이다. 우리는 feature dev branch를 만들어서 나와 개발자들의 코드를 모으고, 나중에 feature dev branch에서 pull request를 만드는 형식으로 진행했다.

우리 제품의 코드베이스에서 개발하는 것이 처음이었던 나는 시행착오를 좀 겪었다. 프론트엔드 코드만 작성하는 것이었지만, 여전히 Authentication을 비롯한 여러 backend dependency가 있어서 여러 가지를 내 컴퓨터에 세팅하고 배우는 과정이 필요했다.

실제 작업 방식

Figma의 새로운 역할

AI Agent Studio를 만드는 과정에서 Figma의 중요도가 줄어들지는 않았다. 여전히 나는 Figma를 이용해서 다양한 컴포넌트, 인터랙션, 유저 플로우를 만들었다. Figma로 만든 디자인으로 CEO, CTO 등을 비롯한 내부 관계자와 의견을 조율하고 의사소통했으며, 여러 버전을 고객들과 공유하고 피드백을 받을 수 있었다.

기존 프로젝트와의 차이점이 있다면, 이번 Figma는 전체적인 맥락에 집중했고 디테일은 작업하지 않았다는 점이다. 예를 들면 컴포넌트별 상태는 어떻게 표현하는지, 인터랙션은 구체적으로 어떻게 표현되는지, breakpoint별로 어떤 양상을 보이는지 하는 세세한 것들은 Figma에서 작업하지 않았다. 대신 Cursor와 Claude Code를 이용해 작업하기 시작했다.

나의 목표는 바이브 코딩을 통해 프로토타이핑을 하는 것이 아니었다. 실제 제품에 들어갈 코드를 만드는 것이기 때문에 우리 코드베이스의 규칙을 사용해야 했고, 완성도가 높아야 했다.

(참고: Claude Code는 내가 주어진 Cursor 사용량을 다 채워서 추가로 사용하게 되었다.)

Figma에서 코드로: 나만의 워크플로우

Figma에서 만든 디자인을 Cursor에서 어떻게 재구현할까 여러 가지 실험을 해봤다.

첫 번째, 스타일 시스템 통일: 우선 Figma의 variable과 코드베이스의 globals.css를 통일했다. Figma와 코드베이스 모두 hard code를 피하고 style variable 사용을 강제했다. 스타일 구현 완성도 면에서 큰 효과를 본 방법이다.

두 번째, 코드 생성 도구: 컴포넌트와 페이지를 코드로 구현할 때 MCP를 사용해봤는데 크게 도움이 되지 않았다. 대신 Figma plugin 중에 "Figma to Shadcn" 유료 플러그인을 사용했는데 큰 효과를 보았다. 이 플러그인을 통해 큰 얼개를 Cursor에서 구현했다.

세 번째, 디테일 조정: Cursor에서 상세한 부분을 조정했는데 주로 spacing의 미세한 차이였다. 이때는 AI에게 지시하기보다는 직접 파일을 열어서 수정하는 것이 효과적이었다.

Playground: 자유로운 실험 공간

앞서 이야기한 backend dependency를 우회할 방법이 필요했다. 우리 코드베이스에 playground 폴더를 만들었다. 기존 코드베이스의 컴포넌트를 활용하면서도 내가 자유롭게 실험할 수 있는 공간이었다. 특히 여러 컴포넌트를 디자인할 때 잘 활용했다.

예를 들어 AI Agent Studio에는 Notion과 비슷한 마크다운 텍스트 에디터가 있는데, 다양한 인터랙션이 있다. 텍스트 편집은 기본이고, slash command를 활용해서 요소를 추가하고, 요소별로 parameter를 지정할 수 있다. 또한 AI와 채팅을 통해서 텍스트를 생성하고 편집할 수 있다. 다양한 패턴이 동시에 존재하고 있어서 시간이 꽤 걸릴 수 있는 디자인인데, 빠른 시간에 완성도 있게 작업할 수 있었다.

Refactoring: 자유로운 코드를 규칙에 맞게

Playground에서 디자인이 끝난 컴포넌트들은 그대로 사용되지 않는다. 이쪽에서 디자인, 테스트가 끝난 것들은 지나치게 자유롭게 만들어진 경우가 많았다. 그래서 우리 코드베이스의 규칙에 맞게 정리해줄 필요가 있었다.

우리는 공용으로 사용하는 Cursor rules가 있는데, 이를 활용해서 Refactor를 했다. 팀원들이 주로 지적하고 내가 신경 썼던 부분은 Logic의 분리였다. Cursor와의 상호작용을 통해 성공적으로 정리할 수 있었다.

이렇게 정리된 컴포넌트들은 목적에 따라 페이지별 컴포넌트 폴더나 전체 공용 컴포넌트 폴더로 이전된다. 작업이 끝나면 나는 코드를 푸시하고, 개발자들이 API 연결을 비롯한 다른 작업들을 진행한다.

결과와 배운 점

여전히 팀 차원에서 바이브 코딩은 초기 단계에 있다고 생각한다.

개인적 관점에서: 디자이너인 나의 입장에서 이 과정은 제품의 완성도를 높이기는 하지만, 내 업무량이 늘어나는 것이기도 했다. 하지만 제품에 더 직접적으로 관여할 수 있다는 점에서 더 큰 성취감을 느낄 수 있었다.

효율성 관점에서: 엔지니어 파트너와의 커뮤니케이션에 들어가는 비용이 비교할 수 없을 정도로 줄어들었다. Codebase에 작업한 디자인, 컴포넌트, 패턴이 쌓이면서 작업 속도는 더 빨라질 것이라고 생각한다.

팀 관점에서: 엔지니어 파트너 관점에서 봤을 때 아직 부족한 점이 많을 것이라고 생각된다. 이는 지속적인 의견 교환, cursor rules 업데이트 등을 통해 금방 발전시킬 수 있을 것이라고 생각한다.

다음 스텝: 팀 전체로 확장

내가 했던 이 과정을 정리해서 이제는 우리 다른 디자이너도 할 수 있도록 도와야 한다. 얼마 전에 디자이너 컴퓨터에 우리 코드베이스를 clone할 수 있도록 여러 세팅을 도왔다. 더 진행하면 이에 관련된 이야기도 공유하도록 하겠다.

마치며

요즘 많은 회사와 팀에서 바이브 코딩을 실험하고 있는 것으로 알고 있다. 디자이너로서 AI 도구를 도입하는 과정은 각자의 맥락에서 다르게 펼쳐질 것이다. 여러분의 경험과 시행착오도 함께 나눌 수 있다면 좋겠다.

이 글에서 다루지 못한 궁금한 점이나, 비슷한 시도를 하면서 겪는 어려움이 있다면 편하게 댓글로 남겨주길 바란다. 내가 아는 범위 내에서 최대한 답변하겠다. 또한 여러분의 이야기도 듣고 싶다. 우리가 함께 배워가는 과정이라고 생각한다.