오토매틱 30일 바이브 코딩 실험 — 디자이너가 코드로 제품을 출시하기까지

핵심 메시지

• 오토매틱은 30일간 로드맵 업무를 멈추고 2인 팀에 완전한 자율권을 준 '급진적 속도의 달' 실험을 진행했다.
• 첫 라운드에만 약 500명이 참여해 약 794개의 프로젝트를 시작했으며, AI 사용은 권장되었으나 의무는 아니었다.
• 발표자는 코드로 무언가를 실제로 출시해 본 적 없는 디자이너였지만, 30일 만에 세 개의 프로젝트를 만들며 '디자인 엔지니어'로 변모했다.
• 가장 큰 교훈은 엔지니어의 역할이 '직접 만드는 사람'에서 '남을 가능하게 하는 조력자·교사'로 확장된다는 점이다.
• 대기업에서는 새 도구 제공, 조력자 발굴, 실험할 공간과 자율권 부여가 AI 속도를 여는 열쇠다.

쉽게 이해하기

오토매틱은 워드프레스닷컴, 젯팩, 우커머스, 텀블러, 비퍼 등을 만드는 약 1,400명 규모의 완전 분산·비동기 조직이다. 수십 년간 생각과 개념을 문서로 잘 남겨 온 문화가 이번 실험의 밑바탕이 됐다. 회사는 처음부터 직원들에게 AI를 배우고 실험하도록 장려했고, 모든 직원이 자기 역할에 맞춘 2주짜리 몰입형 AI 교육을 받도록 했다.

'급진적 속도의 달'은 약 두 달 전 시작됐다. 지시는 단순했다. 30일간 로드맵 업무를 멈추고, 파트너와 짝을 이뤄, 진짜로 출시할 무언가를 만들라는 것이었다. 한 번에 다 할 수 없어 단계적으로 진행했고, 회사의 약 3분의 1에 해당하는 500명가량이 첫 라운드에 참여해 약 794개의 프로젝트를 시작했다.

발표자 산야는 10년 넘게 소프트웨어를 만들어 온 제품 디자이너지만, 직장에서 코드로 무언가를 실제 출시한 적은 없었다. 첫 프로젝트는 AI 교육 중 네 명이 두 시간 만에 만든 보드게임 세션 관리 앱이었다. 엔지니어 팀원이 깃허브 설정과 기본 명령, 깃 사용법을 알려 준 덕분에 모두가 코드를 커밋할 수 있었다. 여기서 그는 '엔지니어가 남을 가능하게 할 때의 영향력이 스스로 더 많은 엔지니어링을 하는 것보다 클 수 있다'는 깨달음을 얻었다.

두 번째 프로젝트는 디자인 시스템의 최신 정보를 사람과 AI 도구 모두에게 보여 주는 상태 추적기였다. 엔지니어가 성능과 유지보수를 우려했지만, 산야는 개념 증명을 직접 만들어 보기로 했다. 2주 반에 걸쳐 깃허브·스토리북·피그마의 링크를 상태별로 정리하고 라이브러리 이름으로 태그하는 도구를 완성했고, 사내 도구와 외부 공개 사이트 양쪽에 배포했다. 이 순간 그는 디자이너에서 디자인 엔지니어로 넘어갔다고 말한다.

세 번째 프로젝트는 단 6일 만에 우커머스 판매자용 iOS 채팅을 만든 사례다. 워드프레스닷컴 인증과 젯팩 연결을 포함하고, 사이트 방문자의 질문에 실시간으로 답하거나 답할 수 없는 질문을 스스로 가려내는 AI 에이전트까지 갖춘 동작하는 개념 증명이었다. 산야는 늘 피그마에서 고충실도까지 작업하던 기존 방식 대신, 프로토타입(실제 제품)을 먼저 만들고 나중에 피그마로 돌아가 시각적 다듬기만 하는 식으로 과정 자체가 바뀌었다고 설명한다.

주요 인사이트

• AI가 가져오는 속도는 역할이 아니라 조직 규모에 따라 다르게 나타난다. 1~3명이 만드는 제로투원 제품과 수천 명이 5~20년 된 시스템을 다루는 대기업에서의 체감이 크게 갈린다.
• 엔지니어의 진짜 지렛대는 코드를 더 많이 짜는 것이 아니라 비엔지니어 동료가 개발 환경을 띄우고 코드를 커밋하도록 돕는 '조력' 역할에 있다.
• 작업 방식이 '피그마에서 고충실도까지' 대신 '프로토타입/제품 먼저, 피그마는 나중'으로 뒤집혔고, 클로드 코드 폴더에 대화와 아이디어를 파일로 기록하니 협업과 이후 빌드가 빨라졌다.
• 대기업에서 이 변화를 이끄는 방법은 도구 접근권 제공, 조력자와 챔피언 발굴, 실험 공간과 자율권 부여로 사람들의 습관을 깨는 것이다.

자주 묻는 질문

관련 AI 소식