요즘 1인 바이브 코딩에 대한 이야기가 많이 보인다. 혼자 얼마나 빠르게 만들 수 있는지, 개발을 잘 몰라도 어떻게 제품을 만들 수 있는지.
그런데 막상 기존 팀 단위에서의 협업은 어떻게 바뀌어야 하는지에 대해서는 생각보다 이야기가 많지 않은 느낌이다.
다들 협업 과정에서는 AI를 어떻게 쓰고 있을까?
최근에 디자이너-개발자 간의 협업 방식을 조금 다르게 실험해보고 있다. 시작은 이미 많은 조직에서 겪고 있는 어려움에서 출발했다. Figma와 코드, 두 개의 시스템을 계속 병행하는 게 정말 최선일까? 디자인 시스템은 Figma에 있고, 실제 구현 시스템은 코드에 있고, 그 둘을 싱크 하는데 계속 코스트를 투자하는 현재의 구조는 바꿀 수 없는 걸까?
그래서 아예 전제를 바꿨다. 코드베이스를 Single source of truth로 두고, 디자인도 그 위에서 이루어지도록 해보자고.
이 과정에서 가장 크게 바뀐 건 디자이너의 역할이었다. 디자이너가 더 이상 화면을 만드는 사람이 아니라, 원칙을 정의하는 사람이 되어야 했다. 물론 기존에도 그랬지만 그 역할이 더 강화될 필요가 생겼다. 디자인 시스템과 토큰을 명확하게 정리하고, 컴포넌트 규칙을 문서화하고, 유저 플로우의 방향성을 먼저 구조화한다. 그리고 그 원칙을 기반으로 AI에게 UI 코드를 직접 제너레이션 하도록 한다. 디자이너는 그 코드를 기준으로 리뷰하고, 사용성을 점검한다. 픽셀을 다루는 사람이라기보다, 시스템의 기준을 설계하는 역할에 가까워졌다. 나는 이 역할을 Design Orchestrator라고 부른다.
물론 이 작업을 진행함에 있어서 보조적 도구로써 피그마를 사용할 수도 있다. 완전 그래픽적인 인스트럭션을 말로 설명하기 힘든 부분만 피그마로 그려서 전달하는 방식이다.
개발자의 역할도 같이 선명해졌다. UI를 다시 옮겨 적는 시간이 줄어들면서, 대신 성능 최적화에 시간을 좀 더 투자하고, 데이터 스키마를 설계하는 데 더 집중하게 됐다. 그리고 무엇보다 중요한 건, 코드에 대한 최종 책임은 여전히 개발자가 가진다는 점이다. AI가 코드를 만들 수는 있지만, 그 코드의 안정성과 배포에 대한 책임까지 가져가지는 않는다. 이런 변화된 협업 과정에서 개발자의 역할은 사라지는 게 아니라, 오히려 책임을 지는 위치로 더 또렷해진다고 생각한다.
당연히 이렇게 프로세스를 변경하기 위해서는 몇 가지 안전장치와 도구가 필요하다. 먼저 디자이너를 위한 브랜치 전략을 추가했다. 이 전략을 통해 디자이너가 작업하는 브랜치 안에서는 우리가 정의한 Agent 스킬이 자동으로 주입되도록 만들었다.
UI디자인 단계에서의 코드 작업은 프로덕션을 목표로 하는 코드와는 달라야 한다. 모킹 데이터 셋업, flow처리 등 협업이 제대로 굴러가려면 결국 룰이 필요하다.
이 방식으로 한 feature에 대해 사이클을 돌려봤는데, 기존에 3일 정도 걸릴 것으로 예상한 작업이 하루도 채 걸리지 않았다. 속도도 인상적이었지만, 더 의미 있었던 건 역할이 명확해졌음에도, 정리를 위한 정리 작업이 사라지고 커뮤니케이션 코스트가 급감했다는 점이었다.
물론 아직 고민도 있다. 코드는 Figma처럼 한눈에 펼쳐보기 어렵기 때문에, 렌더 기반 시각화나 스냅샷 자동화 같은 레이어를 더 고민하고 있다.
그래도 한 가지는 확실하다. AI 이후의 협업은 단순히 도구를 추가하는 문제가 아니라, 역할과 책임을 다시 정의하는 문제라는 것.