AI 프로토타이핑 실험, 바이브 코딩이 디자인 협업을 오히려 치열하게 만드는 이유

바이브 코딩과 디자인 협업, 피그마 없이 8일 만에 기능을 만든 어도비 실험 이야기 🎨

요즘 개발자들 사이에서 "피그마 없이 디자인한다"는 말이 진짜 현실이 되고 있어요. 저도 처음 이 얘기를 들었을 때 반신반의했거든요. 그런데 어도비 디자인팀이 실제로 실험을 해봤고, 그 결과가 생각보다 훨씬 흥미롭더라구요.

바이브 코딩이 뭔지부터 짚고 가요

바이브 코딩은 AI에게 자연어로 "이런 화면 만들어줘"라고 말하면 AI가 실제 동작하는 코드를 만들어주는 방식이에요. 개발자가 한 줄씩 코드를 짜는 대신, AI가 만든 결과물을 검토하고 방향을 잡는 역할에 집중하는 거죠.

2025년 2월 오픈에이아이 공동 창업자 안드레이 카르파시가 이 용어를 처음 쓴 이후로 IT 업계에 빠르게 퍼졌어요. 커서, 깃허브 코파일럿, 클로드 코드 같은 도구들이 대표적이고, 국내에서도 커서가 가장 많이 쓰이는 도구로 자리 잡았습니다.

그런데 이제 이게 개발자만의 이야기가 아니라는 게 핵심이에요. 디자이너의 작업 방식까지 바꾸고 있거든요.

어도비 디자이너가 실제로 해본 실험

어도비 파이어플라이 팀의 UX 디자이너 베로니카 페이통 첸이 소규모 실험 조직을 꾸렸어요. PM 한 명, 엔지니어 세 명, 디자이너 한 명. 의도적으로 작고 기능 중심적으로 구성한 팀이었죠.

이 팀이 정한 실험 조건은 딱 하나였습니다. 디자인을 피그마 목업으로 넘기는 대신, 실제 제품 코드베이스 안에서 바로 만들어보는 것. 디자이너가 AI 코딩 도구로 직접 화면을 구현하고, 엔지니어가 검토 후 메인 브랜치에 합치는 방식으로요.

결과는 8영업일 만에 기능 2개를 실제 프로덕션 빌드에 완성한 거예요. 이미지 슬라이더 기능인 '프리시전 플로우'와 스케치 기반 편집 기능인 '마크업'이 그 결과물이었습니다.

사람들이 많이 하는 오해, 협업이 줄어든다는 것

바이브 코딩에 대한 가장 흔한 오해가 "AI가 다 해주니까 팀원이 덜 필요하다"는 생각이에요. 디자이너가 직접 구현하면 엔지니어 역할이 줄어드는 거 아니냐는 우려도 있고요.

어도비 팀의 실험은 정반대 결론을 냈습니다. 빌드 과정에 가까이 붙어서 일할수록 협업은 오히려 더 깊어졌다는 거예요. 엔지니어는 프로덕션 안정성을 책임지고, 상호작용 아이디어를 실전 압박 속에서 검증하고, 빠른 반복이 가능한 기반을 잡아줬어요. PM은 어떤 문제를 먼저 풀어야 하는지 정의하고 우선순위를 조율했습니다.

국내 프로덕트 조직들도 비슷한 방향으로 가고 있어요. 채널톡은 커서를 전사 도구로 도입하면서 온보딩, 리팩토링, PR 리뷰, UI 구현까지 AI 중심으로 재설계했는데, 구조 설계와 품질 판단은 여전히 사람이 최종 책임을 진다고 밝혔습니다. 토스페이먼츠도 MCP 기반 연동 서버로 자연어 명령만으로 코드 생성이 가능해졌지만, 아키텍처 설계와 결제 안정성 판단은 엔지니어 역할로 남아 있어요.

한 줄 정리하면, 바이브 코딩은 협업을 줄이지 않습니다. 오히려 협업의 밀도를 높입니다.

가까이 붙어서 일했더니 달라진 것들

디자이너가 가장 놀랐던 건 속도가 아니라 '근접성'이 만들어낸 가능성이었어요. 아이디어와 구현 사이의 거리가 줄어들자, 디자인 결정이 제품이 만들어지는 과정에 바로 영향을 줄 수 있었습니다.

기존에는 기획, 목업, 엔지니어 전달이 끝난 후에야 문제가 발견됐는데, 이제는 제약사항이 생기는 순간 바로 해결할 수 있게 된 거예요. 엔지니어도 문서가 아니라 실제로 움직이는 화면을 보며 피드백을 줄 수 있었고요.

피그마 사용 방식도 달라졌어요. 예전처럼 수십 개 화면을 정교하게 이어 붙이는 대신, 아이디어를 빠르게 스케치하거나 방향을 잡을 때만 선택적으로 씁니다. 핵심 화면 몇 개만 20분에서 1시간 안에 그리고, 나머지 시간은 AI 코딩 도구로 실제 구현에 쓰는 방식이에요.

실제 앱 안에서 작업하다 보니 타이밍, 동작, 피드백, 상태 전환처럼 정적인 목업으로는 잡기 어려운 요소들이 바로 드러났어요. 명암비나 포커스 상태 같은 접근성 문제도 문서로 정리하는 게 아니라 실제 경험 안에서 바로 확인하고 고칠 수 있었습니다.

바이브 코딩이 디자인의 본질을 더 선명하게 만든다

이 실험이 던지는 진짜 질문은 이거예요. "AI가 구현을 대신해주면 디자이너에게 남는 건 뭘까?"

답은 공감 능력, 판단력, 안목, 장인정신이에요. 이런 역량들은 바이브 코딩 환경에서도 변하지 않습니다. 오히려 더 중요해져요. 결정이 실제로 이루어지는 순간, 화면이 만들어지는 바로 그 시점에 발휘해야 하니까요.

기존 프로세스에서는 디자이너의 판단이 목업과 스펙 문서를 거쳐 엔지니어를 통해 제품에 반영됐어요. 그 과정에서 원래 의도가 희석될 여지가 있었죠. 바이브 코딩 방식에서는 그 판단이 직접 제품에 닿습니다. 그만큼 책임감도, 정밀함도 더 요구돼요.

물론 유의할 점도 있어요. 바이브 코딩은 계속 달리게 만드는 힘이 있어서 숨을 고를 타이밍을 잃기 쉽고, 세밀한 작업에 몰두하다 전체 그림을 놓칠 수도 있습니다. 모든 문제에 바이브 코딩이 맞는 것도 아니고요.

한국 기업들이 배울 수 있는 것

국내에서도 바이브 코딩 도입 논의가 활발한데, 많은 팀이 "AI 코딩 도구를 쓰면 개발이 빨라진다" 수준에서 멈춰 있는 경우가 많아요.

어도비 실험이 보여준 건 한 단계 더 깊은 이야기입니다. 도구가 아니라 협업 구조 자체가 바뀌어야 한다는 것. 디자이너가 코드베이스에 직접 접근하고, 엔지니어가 초기 단계부터 설계에 관여하고, 리서치나 법무 담당자도 아직 유연한 시점에 피드백을 줄 수 있는 구조요.

실제로 최근 몇 달 사이 국내에서도 넥슨코리아의 게임 디자이너가 코드를 전혀 몰랐던 상태에서 구글 안티그래비티로 협업용 맵 에디터를 직접 만든 사례가 화제가 됐고, 한국(K-)바이브코딩협회와 블루포지가 손을 잡고 한국형 바이브코딩 생태계와 자격 체계까지 구축하려는 움직임도 시작됐어요. 도구를 넘어 생태계 차원의 변화가 진행 중이라는 신호로 볼 수 있습니다.

기존 방식에서 협업이 '핸드오프' 중심이었다면, 바이브 코딩 방식에서 협업은 '오버랩' 중심으로 바뀝니다. 결정이 여전히 유연한 시점에 다 같이 뛰어드는 거예요.

마무리

어도비 팀의 실험은 완성된 시스템을 만든 게 아니라 오히려 더 많은 질문을 남겼어요. 하지만 하나는 분명합니다. 디자인, 엔지니어링, 프로덕트가 더 촘촘한 피드백 루프 안에서 같은 실물에 빠르게 접근할 수 있다면 무엇이 가능해지는지를 보여줬거든요.

바이브 코딩은 도구가 아니라 일하는 방식의 패러다임 전환이에요. 그리고 그 전환은 사람을 덜 필요로 하는 게 아니라, 사람을 더 올바른 시점에 더 가까이 붙여놓는 방향으로 가고 있습니다. 지금이 바로 우리 팀의 협업 방식을 점검해볼 적기예요.