바이브코딩의 '미시적' 시야에서 벗어나는 방법

여러분은 바이브코딩을 하면서, '시야가 좁아진다'라는 느낌을 받아보신 적이 있으신가요? 저는 클로드 디자인, 클로드 코드, 코덱스 등등 다양한 툴을 사용하면 항상 요청을 '~를 몇px 옮겨줘', '모바일뷰/테블릿뷰에서 비율을 ~하게 수정해줘' 같이 미시적인 부분을 보다 보니 시야가 정말 좁아진다는 느낌을 정말 많이 받았습니다. 정작 전체적인 데이터 구조, 사용자의 인풋과 아웃풋, 전략적인 로직은 빼먹고 있다는 생각이 들더라구요.

그래서 요즘은 새로운 서비스를 만들기보다, Figma 플러그인으로 소소한 자동화를 하나씩 시도해보고 있습니다.(서비스도 이제 없는 서비스가 없더군요.. 좋은 서비스 아이디어 생각나서 검색해보면 다 있고..)

Figma 플러그인 자동화는 생각보다 미시적인 부분 외에 거시적인 틀을 보는데 도움이 되어 제가 느낀 점과 시각을 오늘 뉴스레터에서 공유해봅니다.

"PM은 개발 몰라도 돼요."

예전에 많이 들었던 말인데요. 직접 뭔가를 만들기 시작하면서 이 말이 조금씩 다르게 들리기 시작했습니다. 화면은 다 그렸는데, 서비스가 어떻게 돌아가는지 명확하게 설명할 수 없으면 0점짜리 기획이라고 생각합니다.

Figma에서 와이어프레임이나 AI로 만든 디자인 페이지를 옮겨서 작업을 하다 보면 텍스트를 여러 언어로 바꿔야 할 때가 있었습니다. 이 과정에서 매번 번역기를 열고, 복사하고, 붙여넣는 게 번거로웠어요. 

이를 피그마 플러그인으로 자동화 해보면 좋을 것 같아, 기획을 시작했습니다. 초반에 기능 자체는 굉장히 간단하다고 생각했습니다. 텍스트 레이어를 선택하고 버튼 하나 누르면 번역된 텍스트로 바뀌는 것. 화면 설계로 치면 5분도 안 걸릴 내용이었죠.

그런데 막상 만들려고 하니 생각보다 시스템적으로 고려할 요소들이 많았습니다. 특히 혼자 쓰는게 아닌, 팀원과 공유해야 하는 상황이면 더욱 고려할 요소가 많아집니다.

Google Translate API를 발급받고, 이 API 키를 노출시키지 않으려면 중간에 서버가 필요합니다. 플러그인이 직접 Google에 요청하는 게 아니라, 내 서버를 거쳐서 요청하는 구조가 필요하죠. 이걸 '프록시 서버'라고 합니다.

결국 "번역 버튼 하나"를 만들기 위해 이런 흐름이 필요했습니다.

Figma 플러그인 (사용자 클릭)

→ Vercel 프록시 서버 (API 키 보호)

→ Google Translate API (실제 번역)

→ 번역 결과 반환

→ Figma 텍스트 레이어 업데이트

화면에서는 버튼 하나였지만, 그 뒤에는 세 개의 서비스가 연결되어 있었습니다.

이런 측면에서, 피그마 플러그인을 직접 만들어보는 경험이 단순 UI를 넘어서 거시적인 시스템을 볼 수 있는 좋은 기회였습니다.

무언가 만드려고 한다면, 시스템을 이해해야 하는 진짜 이유

PM이 시스템을 이해해야 하는 건 개발자처럼 코드를 짜기 위해서가 아닙니다. 기획의 빈틈을 스스로 발견하기 위해서입니다.

화면 설계서에는 '정상 케이스'만 있습니다. 그런데 실제 바이브코딩으로 서비스를 만들다보면 이런 질문들이 항상 따라옵니다.

- API 요청이 실패하면 사용자에게 어떤 메시지를 보여주나요?

- 번역 가능한 글자 수에 제한이 있나요?

- 요청이 너무 많이 들어오면 비용은 어떻게 되나요?

그렇다고 PM/마케터인데 개발 베이스를 무조건 공부하세요! 라는 말은 아닙니다. 하지만 최소 아래의 요소들은 이해하고 있어야 한다고 생각합니다.

이걸 이해하는 것과 모르는 것은, 기획의 깊이에서 차이가 납니다.

개인적으로 저는 지금의 AI가 브레이크 없는 트럭과 비슷하다고 생각합니다. "이런 기능을 가진 웹사이트 만들어줘!"라고 하면 엔터를 치기가 무섭게 바로 무언가를 만들기 시작하죠. 요즘 Claude나 Liner 같은 AI들이 시작 전에 몇 가지 질문을 던지고 확인하는 방식으로 발전하고 있긴 하지만, 모든 케이스에서 AI가 처음부터 유저 사이드의 질문들을 미리 생각하고 기획해주지는 않습니다.

인스타그램에서 많이 공유되는 Claude/Codex 명령어들도 결국 AI가 무작정 직진하지 않도록 브레이크를 걸어주는 역할인 셈이죠. 그 브레이크 역할을 할 수 있는 사람은 바로 시스템을 이해하는 PM이 되어야 합니다.

"이 기능, 결제 실패하면 어떻게 돼요?" "API 키가 외부에 노출되는 건 아닌가요?" "데이터가 어디에 쌓이는지 확인할 수 있는 구조인가요?"

AI가 빠르게 달려갈수록, 그 속도에 브레이크를 걸 수 있는 판단력이 더욱 더 중요해질 것 같습니다.

오늘 내용도 귀감이 되었길 바라며,

서두에 말한 것처럼 저와 같은 '시야가 좁아지는'감정을 느꼈던 분들이라면, 피그마 플러그인을 제작해보시는 것도 적극 추천드립니다 :)