도태되는 것이 두려웠던 프로덕트 디자이너의 목적 없는 바이브 코딩

그래서 뭐부터 시작해야 저 바이브 코딩 대화에 낄 수 있는데요?

저는 IT 회사에서 디자인 시스템이나 만지며 살고 있던 프로덕트 디자이너였는데요. 별안간 GPT가 시작하고 클로드가 장악한 AI 세상에 떨어지게 되었어요. 그 영향을 받는 건 프로덕트 디자인 계열도 당연히 예외는 아니었고, 변화에 제일 먼저 앞장서서 달려가던 사람들은 웃고 있었으나 대다수는 그러지 못했어요.

당시 저는 제미나이로 시스템 가이드 문서를 작성하거나, GPT로 이미지 생성을 하고, 토큰 규칙에 대한 질의를 하는 등. 단순히 AI(LLM)를 업무 보조로 이용하는 것은 기존에도 충분히 하고 있었는데, 대체 바이브 코딩이 뭐길래 저렇게들 호들갑이지? 라는 생각을 했었어요.

취준하는 동생들은 취업 시장이 얼어붙었다고 했고, 몇몇 디자이너 친구들은 탈디(탈디자인)를 선언하며 디자인을 그만두었어요. SNS에는 바이브 코딩으로 너무 쉽게 앱을 만들었다는 사람들의 이야기와 알아듣지 못할 개발자들의 AI 코딩 활용기들이 올라오고 있었고, 동기 디자이너님은 사이드로 우리도 바이브 코딩을 해보자고 제안했어요.

딸깍으로 모두가 앱을 만들 수 있다는 세상과 스킬, 토큰 최적화를 이루며 효율적으로 에이전트를 돌리는 세상 사이의 간극은 너무나도 커 보였기에 저는 ‘그래서 뭐부터 시작해야지 저기에 낄 수 있지?’라는 생각을 하며 막연히 불안해하곤 했어요.

바이브 코딩? 그게 뭔데, 그거 어떻게 하는 건데

원래대로라면 만들고 싶은 앱 혹은 서비스가 먼저 있고, 바이브 코딩은 수단이 되어야 하는데, 제 경우에는 ‘다들 나 빼고 바이브 코딩을 해? 그게 뭔데 나도 뒤처질 수 없지.’의 바이브로 시작하였더니 제 바이브 코딩을 위한 바이브 코딩의 여정은 한 걸음을 내디딜 때마다 이게 맞나? 상태에 직면하게 되었어요.

바이브 코딩으로 유명한 툴을 설치하고, AI에게 학습 계획을 짜달라고 하고, 추천받아 우선 간단한 투두리스트 화면을 만들어보는 것으로 시작하기로 했는데 진행하는 내내 머릿속에서는 물음표가 사라지지 않았어요.

• 이렇게 단순한 기능을 AI 시켜서 구현하는 게 의미가 있나?
• 이거 뭔가 HTML 태그 외우고 이래야 공부 아닌가?
• 근데 그거 안 외우고 되는 게 바이브 코딩 아닌가? 시대역행?
• 그럼, 이 단순한 기능 구현 잘 시키기가 무슨 공부가 되는 거지?
• 역시 기획부터 해야 하나?
• 근데 나는 디자이넌데 디자인을 바이브 코딩으로 해야 하는 거 아니야?
• 디자이너의 업무 프로세스에 바이브 코딩이 어떤 식으로 들어갈 수 있을까?

그러던 중 우연한 기회로 해답을 얻게 되었어요. 당시 회사에서 디자이너를 대상으로 업무 만족도 중간 점검 설문을 진행했었는데 앞으로 팀에서 지원해 주길 바라는 교육에 관련된 질문이 있었어요. 신기하게도 다수의 디자이너가 업무 관련 AI 사용과 코드 베이스 작업(바이브 코딩)에 대한 요청을 해주셨고, 거기서 인사이트를 느끼신 팀장님은 디자이너들에게 개발 환경을 준 다음 직접 작업을 해볼 수 있게 코드 베이스의 환경을 만들어 주셨어요.

그러고는 디자이너들과 개발자들을 1대1로 팀을 지어서 디자이너는 피그마의 디자인 시스템이나 컴포넌트들을 코드로 잘 옮겨보고, 개발자들은 그 만들어진 시스템으로 원하는 화면을 기획하고 그려보도록 미션을 주셨어요. 신기한 것은 막연히 바이브 코딩을 목적으로 뭔가 하려고 할 때에는 뭘 하지 싶었는데 업무의 과정에서 코드 베이스가 생기니까 자연스럽게 해보고 싶은 것들이 많아졌어요. 당시 기존 프로젝트에서 피그마 베이스로 디자인 시스템을 다루고 있었던 저는 코드만 사용해서 디자인 시스템을 처음부터 구현해 보고 싶다고 생각하게 되었어요.

Claude와 Claude code, 뭐가 다른 거예요?

제가 코드 베이스에서 바이브 코딩을 하며 느낀 것은 , 단순히 AI(LLM)를 업무 보조로 쓰는 것과 바이브 코딩을 하는 것의 차이는 결국 AI에게 어떤 환경에서 어떤 권한까지 줄 것인가에 있다고 느꼈어요.

단순히 claude나 ChatGPT를 쓰는 것은 AI를 방 하나에 가둬놓고 내가 보여줄 자료를 들고 들어가서 질문하는 것에 가깝다면 claude code나 codex는 AI에게 집을 구석구석 뒤질 수 있는 권한(허용된 범위의)을 주고 네가 A폴더의 자료를 찾아서 가져오고 그걸 B폴더 속 자료처럼 새로운 데이터를 작성하라고 할 수 있는 것에 가까운 것 같아요.

제 업무로 예를 들자면 기존에 쓰던 방식이 컴포넌트 가이드를 만들어야 하는 상황에서 AI(LLM)에게 우리 컴포넌트 이미지와 컴포넌트 상세 명세를 주고, 가이드 예시들도 준 뒤, 이 자료들을 바탕으로 가이드를 생성해달라고 하고 작성해 준 답변을 저장하거나 노션에 옮기는 방식이라면

코드 베이스의 방식은 AI에게 내 컴퓨터 속에 있는 우리 컴포넌트 코드 파일 직접 찾아서 이미지 캡처하고 상세 명세 확인한 뒤, 이 리소스로 다른 컴포넌트 가이드들 참고해서 동일한 양식으로 컴포넌트 가이드 작성해달라고 할 수 있어요. 이렇게 하면 제가 매번 파일을 찾아 열고, 자료를 복사하고, 기존 가이드 양식을 맞춰 옮기는 반복 작업이 크게 줄어들어요.

AI에게 웹 권한을 쥐여줘 보았다.

크롬(웹)에서 AI(LLM) 플러그인을 쓰는 것도 유사해요. 코드 베이스의 작업은 아니지만 AI에게 웹을 제어할 수 있는 권한을 주고, 마치 사람처럼 버튼을 누르고 상태를 확인하고 폼을 채우고 결과를 검증할 수 있는 권한을 주는 거예요.

저는 QA를 진행할 때, 웹사이트에 올라가 있는 컴포넌트의 상태를 QA에 필요한 상태로 바꾸어달라고 요청하거나. 직접 원하는 상태 QA를 요청할 수도 있었고

그리드 라이브러리를 제공하는 서비스의 웹사이트에 올라와 있는 설명 문서에서 원하는 기능이 어떤 위치에 작성되어 있는지를 빠르게 찾는 데에도 사용할 수 있었어요.

제 현재 작업 단계에서는 해당 작업이 많이 필요하지 않았지만, 경쟁사 사이트들의 플로우나 레퍼런스를 수집하고 IA와 콘텐츠 구조를 추출해서 분석해 보는 작업도 유용할 것으로 생각해요.

그래서 멸종되지 않으려면 우린 뭐부터 해야 할까요?

이 글을 보고 저처럼 멸종 위기를 느끼며 불안해하지만, 뭐부터 해봐야 할지 모르겠는 분들께, 업무에 코드 베이스 작업을 끼워넣기 시작하는 데에 좋은 작업을 추천해 드려보려 해요!

친한 개발자 친구 하나를 만들어 보는 것 어떤가요?

…이런 말을 하려는 것은 아니고요.

프로덕트 디자이너로서 업무에 집중하다 보면 세상의 빠른 변화를 놓치기 십상인 것 같아요. 모두가 기술에 빠삭하면 좋겠지만 현실적인 한계가 있죠. 반면 AI의 언어는 코드이고, 이를 다루는 개발자들은 이 변화에 가장 빠르게 반응하는 직군이라고 생각해요. 사실 제가 AI를 웹 환경이나 코드 베이스에서 직접 다뤄볼 수 있었던 것도 개발자이신 팀장님이 먼저 제안해 주신 덕분이거든요.

최근 진행한 디자이너-개발자 프로젝트는 이런 교류의 가치를 다시금 깨닫는 계기가 되었던 것 같아요. 평소라면 바쁠까 봐, 귀찮아할까 봐 묻어두었던 질문들을 꺼내고, 함께 실험하며 깊게 디깅하는 과정을 거쳤거든요. 서로 잘 아는 분야가 다르다 보니 새로운 시각에서 문제에 접근할 수 있었고, 인사이트를 교환하며 함께 실행해 보는 환경 자체가 무척 가치 있고 흥미로웠어요. 변화의 흐름을 배우고 새로운 기술을 나의 작업에 적용해 내 것으로 만들고 싶다면, 변화에 관심 있는 사람들과 활발하게 교류하는 것이 중요하다는 생각을 다시금 하게 된 계기였어요.

평소에 회사에서 협업하던 개발자, 사이드 프로젝트에서, 소모임에서, 학교 다닐 때 프로젝트를 같이한 개발자 누구든 친해지고 싶은 사람이 있다면, 한번 이 이미지를 보내보시는 것 어떤가요?