디자인 도구보다 코드 구현이 빨라진 워크플로우

피그마(Figma)로 목업을 그리고 스펙 문서를 작성하는 대신, 실제 코드베이스에서 작동하는 프로토타입을 먼저 만든다. 제인 스트리트(Jane Street)의 디자이너 에드윈(Edwin)이 최근 클로드(Claude)를 도입하며 바꾼 작업 방식이다. 과거에는 아이디어를 구현하기 위해 제안서를 쓰고, 피그마로 컴포넌트를 만들고, 개발자와 함께 구현 가능성을 검토하는 과정을 거쳤으나 이제는 이 과정을 생략하고 바로 '작동하는 기능'을 구축한다.

최근 진행한 JSQL(제인 스트리트 내부 SQL 방언) 입력창에 LLM 프롬프팅 기능을 추가하는 작업이 대표적이다. 에드윈은 클로드를 이용해 제출 버튼의 디테일을 수정하고, 키보드 단축키를 추가하며, 생성된 확인 메시지를 조정하는 작업을 반복했다. 이 과정에서 피그마 컴포넌트를 만들거나 문서를 포맷팅하는 등의 부수적인 작업은 완전히 사라졌다.

초기에는 UX의 사소한 수정 작업에만 AI를 활용했으나, 최근 2개월 사이 그 범위가 크게 확장됐다. 현재는 2,000라인 이상의 코드 차이(diff)가 발생하는 데이터 모델 및 라이브러리 변경 사항까지 클로드로 구현하고 있다. 일부 신규 앱의 경우 피그마 단계를 완전히 건너뛰고 클로드와 함께 시각적 디자인을 반복하며 곧바로 인터랙티브 프로토타입을 완성하는 수준에 이르렀다.

'설득'에서 '경험'으로 바뀌는 채택 흐름

디자이너가 직접 작동하는 결과물을 내놓으면서 협업의 중심축이 '설득'에서 '경험'으로 이동하고 있다. 기존 워크플로우에서 디자이너는 아이디어의 실현 가능성을 증명하기 위해 개발자를 설득해야 했고, 개발자 입장에서는 불확실한 아이디어를 위해 프로토타입을 만드는 것이 시간 낭비가 될 위험이 있었다. 하지만 디자이너가 AI로 직접 작동하는 증명(Proof of Concept)을 제시하면, 동료들은 문서를 읽는 대신 기능을 직접 사용하며 빠르게 평가할 수 있다.

이러한 변화는 기술적 진입장벽의 붕괴와 맞물려 있다. 에드윈은 과거 리액트(React) 같은 프론트엔드 프레임워크를 다룰 줄 알았기에 개발자와 소통할 수 있었지만, 제인 스트리트에서 사용하는 OCaml이나 Bonsai(내부 프레임워크) 같은 생소한 언어 앞에서는 무력했다. 그러나 클로드를 통해 언어의 장벽을 넘어서면서, 전문 개발자가 아니더라도 실제 매체(Medium)에서 직접 디자인을 실험할 수 있는 환경이 마련됐다.

다만, 이러한 흐름은 '반복적 사고'에 갇힐 수 있다는 리스크를 동반한다. AI가 생성할 수 있는 결과물 범위 내에서만 아이디어를 수정하게 되어, 완전히 새로운 창의적 도약을 놓칠 수 있다는 우려다. 이는 도구가 성숙한 단계의 제품을 개선할 때는 효율적이지만, 완전히 새로운 것을 창조해야 하는 초기 단계에서는 제약이 될 수 있는 지점이다.

'완성된 기능'이 주는 리뷰 리스크와 대응

작동하는 프로토타입을 제출하는 방식은 리뷰어에게 새로운 과제를 던진다. 리뷰어가 받는 결과물이 이미 '완전히 구워진(fully baked)' 기능이기 때문에, 기능적 설계에 개입할 여지가 줄어들고 단순히 코드를 리뷰하는 역할로 전락할 위험이 있기 때문이다. 이는 디자인 세계에서 기획자가 상세 와이어프레임을 주고 디자이너에게 '예쁘게만 만들어달라'고 요청하는 상황과 유사하다.

제인 스트리트 팀은 이를 해결하기 위해 프로토타입의 성격을 재정의했다. 프로토타입을 '살아있는 제안 문서'로 간주하고, 작성된 코드는 언제든 버릴 수 있는 '일회용(disposable)'임을 명시하는 방식이다. 리뷰어의 역할은 코드를 검증하는 것이 아니라, 디자인과 사용자 경험(UX)에 대해 피드백을 주는 것에 집중한다. 최종적으로는 리뷰어가 아이디어를 이어받아 별도의 기능을 통해 프로덕션 코드로 다시 구현함으로써 코드의 품질과 소유권을 확보한다.

한국의 AI 실무자와 기업들이 주목해야 할 지점은 AI가 단순히 생산성을 높이는 도구를 넘어, 직군 간의 역할 경계와 협업 프로세스를 어떻게 재편하는가이다. 특히 디자인-개발 간의 핸드오프(Handoff) 과정에서 발생하는 비용을 줄이기 위해 '작동하는 프로토타입'을 소통 수단으로 삼는 방식은, 도입 시점과 리뷰 체계만 적절히 설정한다면 개발 리소스를 획기적으로 아낄 수 있는 선택지가 될 수 있다.