Deel 디자인팀이 AI 프로토타입을 일부러 조악하게 만드는 이유

제품 아이디어를 검증할 때 흔한 실수는 완성도를 먼저 끌어올리는 것입니다. Deel 디자인팀은 순서를 뒤집습니다. 가설이 맞는지부터 싸고 빠르게 확인하고, 검증이 끝난 뒤에 사내 디자인 시스템에 맞는 실제 코드로 옮깁니다. 그 사이에는 의도적으로 조악하게 만든 화면이 들어갑니다. Deel의 시니어 프로덕트 디자이너가 설명한 방식은 AI 프로토타이핑의 목적이 완성품 제작이 아니라 판단 시점을 앞당기는 데 있다는 점을 보여 줍니다.

정해진 프로세스는 없습니다

Deel의 디자인 작업은 하나의 정형화된 절차를 따르지 않습니다. 새 AI 도구가 나올 때마다 방식이 바뀌고, 프로젝트 성격에 따라 출발점도 달라집니다. 어떤 일은 솔루션 프로토타입에서 곧바로 시작하고, 복잡한 과제는 discovery(문제와 맥락을 먼저 파악하는 조사 단계)에 많은 시간을 씁니다. 이런 복잡한 과제에서 시스템 구조를 이해하고 이해관계자와 방향을 맞추는 일은 어떤 AI 도구로도 대체되지 않습니다. AI는 리서치 정리와 패턴 탐색을 빠르게 해 줄 뿐이고, 어떤 프레임을 쓸지는 디자이너가 정합니다.

Lovable로 만드는 일회용 프로토타입

초기 개념 검증에는 Lovable 같은 도구로 버릴 각오의 프로토타입을 만듭니다. 2024년 초 사례에서는 글로벌 음료 기업의 거래 정산 흐름을 두 가지 방식으로 만들어 비교했습니다. 하나는 거래 항목을 은행 명세에 끌어다 놓는 drag-and-drop 방식이고, 다른 하나는 왼쪽에 미배정 결제, 오른쪽에 후보 명세를 놓고 선택하는 표 방식입니다.

이 개념 프로토타입은 prompt(AI에게 주는 지시문)를 다듬는 데 2시간이 채 걸리지 않았습니다. 결과는 2분 내외의 화면 녹화로 공유했고, 1~2일 안에 이해관계자 확인을 받았습니다. 완성도 높은 PRD(제품 요구사항 문서)를 쓰기 전에 제품 방향이 맞는지 먼저 알 수 있다는 점이 이 방식의 핵심입니다. 늦게 방향을 바꾸면 몇 주가 사라지지만, 이 단계에서 멈추면 잃는 것은 며칠에 불과합니다.

▲ 정산 매칭 방식 두 가지 비교

조악한 화면은 의도된 장치입니다

화면이 거친 것은 실수가 아닙니다. 초기 프로토타입이 프로덕션 디자인 시스템을 정확히 따르는 것은 필요하지도, 바람직하지도 않습니다. 시각적 완성도가 올라가면 이해관계자의 시선이 타이포그래피와 색상으로 쏠리기 때문입니다. AI가 대충 찍어낸 듯한 결과물을 뜻하는 ‘AI slop’ 수준의 화면은 논의를 상호작용이 실제로 작동하는지에 묶어 둡니다.

효과는 검증 결과로 나타났습니다. 표 방식과 drag-and-drop 방식을 내부 사용자에게 시험했을 때, 표가 사람의 실수를 훨씬 효과적으로 줄여 준다는 결론이 나왔습니다. 반대로 고충실도 프로토타입을 너무 일찍 내놓으면 이해관계자가 이미 완성된 소프트웨어로 오해할 수 있다는 점도 주의해야 합니다.

Deel UI Playground와 Claude Code

충실도를 높일 때는 외부 도구 대신 사내 저장소로 옮깁니다. Deel UI Playground는 엔지니어링 팀이 만든 내부 GitHub 저장소로, Deel UI 디자인 시스템 token(색상·간격 같은 디자인 값을 정의한 변수)과 의존성, 로컬 서버 명령이 미리 설정돼 있습니다. 디자이너는 저장소를 복제하고 설정 명령을 실행한 뒤 터미널에서 Claude Code를 써서 프로토타입을 띄웁니다. 저장소에 들어 있는 지침 markdown 파일이 AI가 Deel UI 기준을 벗어난 CSS나 컴포넌트를 만들지 않도록 막는 안전장치 역할을 합니다. 결과물은 개발 환경에 배포해 실제 링크와 pull request(코드 변경을 검토하고 반영해 달라는 요청)로 엔지니어에게 넘깁니다.

AI가 없는 인터페이스 요소를 지어내거나 임의의 스타일을 만들 때는 Storybook에서 해당 컴포넌트 코드와 명세를 복사해 prompt에 그대로 붙여 넣습니다. drawer, modal, code input 같은 컴포넌트의 실제 코드를 주면 생성 결과가 Deel의 React 컴포넌트 라이브러리와 어긋나지 않습니다. border radius나 padding, 글꼴이 미묘하게 틀어진 것을 찾아내는 일은 여전히 디자이너의 몫입니다.

문서 대신 동작하는 코드: Checks 모듈

고충실도 프로토타입의 실제 사례가 Checks 모듈입니다. 미국 정부 기관, 세금 압류, 급여 지급 등 종이 수표로 처리되던 흐름을 여러 은행 파트너와 공급자에 걸쳐 디지털화하는 작업이었고, 요구사항 문서는 책 한 권 분량이었습니다. Playground에서 만든 프로토타입에는 실제 데이터 표, 상태 필터, 수표 생성 drawer, CSV 일괄 업로드가 들어갔습니다. 내부 테스트 사용자는 CSV 서식 파일을 올리고 세금과 급여 배분을 미리 본 뒤, 은행 계좌를 수정하고 승인 또는 거절 흐름을 시뮬레이션할 수 있었습니다.

충실도를 높여 만들면 통합 문제가 미리 드러납니다. 공급자 API 응답 시간이나 queued, issued, mailed, delivered, cashed, voided, reconciled로 이어지는 상태 전이 같은 것들입니다. 문서 위에서는 보이지 않던 문제가 코드 위에서는 바로 보입니다.

FigJam에서 시스템을 먼저 그립니다

화면을 그리기 전에 시스템을 이해하는 단계가 있습니다. Treasury Management System 2.0 discovery 작업에서는 FigJam에 재무 인프라 흐름, 이해관계자 동심원 지도, 문제 정의문, 은행 계좌에서 정산까지 이어지는 상세 흐름도를 정리했습니다. 핀테크에서는 버튼 하나, 흐름 하나를 잘못 설계하면 고객 결제가 실패하거나 근로자가 급여를 받지 못할 수 있습니다. API 제약, J.P. Morgan 같은 은행 파트너의 규칙, 회계 요구사항을 한곳에 모아 두는 작업이 먼저입니다.

Loom과 Slack으로 하는 비동기 리뷰

리뷰는 회의 대신 비동기로 돌아갑니다. 전용 Slack 채널에 2분 내외의 화면 녹화와 동작하는 프로토타입 링크를 올리면, 시간대가 다른 23명 규모의 이해관계자가 스레드에서 의견을 냅니다. 엔지니어는 처리되지 않은 API 상태나 빠진 검증 규칙을 그 자리에서 짚습니다. discovery 30% 단계에서 시작한 스레드가 90% 단계까지 이어지는 식으로 진행 상황이 기록됩니다. 모인 피드백은 AI로 정리해 action item을 뽑고, 몇 시간 안에 코드를 고쳐 다시 올립니다.

▲ 터미널에서 만들어지는 동작 화면

Figma 목업의 한계

Figma 목업은 소프트웨어가 어떻게 동작해야 하는지를 그린 정적인 도식입니다. 실제로 어떻게 동작하는지는 코드가 보여 줍니다. Deel의 시니어 프로덕트 디자이너는 커리어 동안 Figma 설계와 엔지니어링 구현 사이의 차이를 반복해서 겪었고, 그때마다 버그 목록이 쌓였습니다. 동작하는 프로토타입은 micro-interaction(버튼 반응 같은 작은 상호작용), 반응형 상태, edge case(드물게 생기는 예외 상황)를 몇 분 안에 확인하고 정리하게 해 줍니다. 코딩이 능숙하지 않은 디자이너도 AI를 통해 실제 코드베이스를 다룰 수 있게 된 것이 이런 전환을 가능하게 했습니다.

token을 아끼는 순서

도구는 단계에 맞춰 씁니다. 처음에는 Claude에 텍스트 요구사항과 discovery 단계의 참고 자료를 넣어 레이아웃 개념을 확인합니다. 이때 텍스트 prompt를 우선하는 이유는 큰 이미지를 올리는 것보다 token(AI가 텍스트를 처리하는 단위이자 사용량 기준)을 적게 쓰면서 맥락을 유지할 수 있기 때문입니다. 개념이 가능성을 보이면 Playground의 Claude Code로 옮겨 재사용 가능한 코드를 만듭니다. 검증되기 전에 Claude Code에서 token을 소모하는 것은 권하지 않습니다. 문제 정의를 먼저 다듬는 편이 낫습니다. 어떤 도구를 쓰는지는 부차적이고, 문제를 얼마나 명확히 정의했는지가 결과를 가릅니다.

디자이너에서 프로덕트 빌더로

효과는 시간 절감보다 영향 범위의 확장으로 나타납니다. Deel에는 약 90명의 디자이너와 2,000~4,500명 규모의 엔지니어가 있어, 디자이너 한 명이 감당해야 할 커뮤니케이션 부담이 큽니다. PM 승인이나 엔지니어링 티켓을 기다리는 대신 동작하는 해결책을 만들어 경영진에게 직접 보여 줄 수 있습니다. 사내 agent(여러 단계의 작업을 스스로 수행하는 AI) 플랫폼인 Akai도 같은 방향의 도구입니다. Research Assistant workflow는 인터뷰 기록, 설문, Amplitude 같은 행동 데이터를 넣으면 정해진 절차를 거쳐 구조화된 리서치 보고서를 만듭니다. 문제 맥락, 데이터 완결성, 번역 정확성, 실행 가능한 권고를 검증하는 품질 gate를 두고 있고, 플랫폼 대시보드에는 누적 9,329회 실행이 표시됩니다. Treasury의 Accounts Health dashboard처럼 글로벌 은행 파트너 연결 상태를 보여 주는 화면도 텍스트 요구사항과 discovery 흐름도에서 곧바로 동작하는 프로토타입으로 발전했습니다.

지금 해 볼 수 있는 것

핵심은 순서입니다. 문제 정의를 텍스트로 먼저 정리하고, 저충실도 프로토타입으로 가설을 검증하고, 검증이 끝난 뒤에 디자인 시스템에 맞는 코드로 넘어갑니다. 조악한 화면은 부끄러운 결과물이 아니라 검증을 앞당기는 장치입니다.

• 큰 코드 생성 도구를 켜기 전에 사용자 목표와 문제 정의를 글로 먼저 정리합니다.
• 사내 디자인 시스템과 Storybook 명세를 미리 준비해 두고, AI가 지어낸 스타일에 대응할 때 해당 컴포넌트 코드를 prompt에 붙여 넣습니다.
• 2분 내외의 화면 녹화와 동작하는 링크를 함께 올려 리뷰를 비동기로 돌립니다.
• 복잡한 도메인이라면 화면 설계 전에 외부 API와 상태 변화까지 포함한 전체 흐름을 먼저 그립니다.
• agent workflow를 만들 때는 맥락 완결성과 필수 항목을 확인하는 품질 gate를 둡니다.

Deel의 사례는 AI 프로토타이핑이 디자이너를 정적인 목업 제작자에서 제품 방향을 만드는 사람으로 옮겨 놓는다는 점을 보여 줍니다. 도구 조합은 회사마다 달라질 수 있지만, 완성도보다 검증 속도를 앞세우는 순서는 어디서나 응용할 수 있습니다.