디자이너의 새 무기, Claude로 만드는 프로토타입: Figma보다 빠르게 협업하는 법

디자이너의 새 무기, Claude로 만드는 프로토타입

디자이너의 새 무기, Claude로 만드는 프로토타입: Figma보다 빠르게 협업하는 법

디자인 워크플로가 흔들리고 있다. 사양 문서와 Figma 목업 대신, 머릿속 아이디어를 즉시 동작하는 프로토타입으로 꺼내 다른 사람에게 직접 써보게 하는 흐름. Jane Street의 디자이너는 이 변화를 한 줄로 요약한다. "이제 Figma보다 Claude로 더 많이 디자인한다."

기존에 디자이너는 아이디어를 사양서로 풀고, Figma로 와이어프레임을 그리고, 엔지니어에게 넘겨야 했다. 이 과정은 며칠에서 몇 주가 걸렸다. 의도가 사라지기도 했고, 결정 권한은 엔지니어에게 넘어갔다. 그런데 LLM이 등장하면서 이 사이클이 통째로 바뀌었다. 디자이너가 직접 동작하는 프로토타입을 만들 수 있게 된 것이다.

이 글에서는 LLM에 회의적이었던 디자이너가 어떻게 태도를 바꿨는지, 어떤 방식으로 프로토타입을 만드는지, 그리고 우리 팀이 시도해볼 작은 실험을 정리한다.

LLM에 회의적이었던 디자이너의 전환

오랫동안 LLM은 디자이너에게 외면당해왔다. 작년에 게임 코드를 수정하려 Copilot과 Cursor를 시도했지만, 둘 다 동작하는 변경을 만들어내지 못했다. 이전 직장에서 Gemini로 제품 브리프와 와이어프레임을 생성했지만, 결과는 전부 폐기됐다.

결국 LLM이 잘하는 영역은 이미 디자이너도 잘하는 일이었고, 결과도 직접 하는 것보다 나빴다. 전환점은 Jane Street 입사였다. OCaml과 Bonsai라는 새 환경이 낯설었기 때문에 AI 지원이 필수가 됐다. 그런데 가장 큰 변화는 낯선 기술이 아니라, 디자이너 자신의 가장 익숙한 영역인 디자인 워크플로에서 일어났다.

프로토타입 중심 워크플로의 등장

기존 디자인 워크플로는 정적이었다. 사양서를 쓰고, Figma 목업을 그리고, 제안서를 정리한 뒤, 개발자와 구현을 리뷰했다. 이 과정에서 실제 산출물은 사양의 그림자였다. 하지만 LLM 기반 프로토타이핑은 다르다.

디자이너는 다음과 같이 일한다. 먼저 작업 흐름의 문제와 제안을 글로 정리한다. 그 다음 에디터에서 빌드, 서버, Claude를 함께 실행한다. 작성한 설명을 프롬프트로 사용한다. 가장 중요한 점은 기본 기능이 실제로 동작하도록 만들어, 사용자 의견을 받는다는 것이다.

이 방식에서 가장 큰 발견은, 실제 코드베이스 안의 프로토타입이 목업과 문서보다 거의 모든 면에서 더 좋았다는 점이다. 디자이너가 만든 살아 있는 결과물이, 다른 사람이 직접 써보며 평가할 수 있는 가장 강력한 조언이 됐다.

JSQL 입력 프로토타입 사례

대표적인 사례는 JSQL 입력창에 LLM 프롬프팅을 결합한 프로토타입이다. JSQL은 다양한 사용자를 대상으로 쓰이는 내부 SQL 방언이다. 이 기능은 며칠간 실제로 사용되며 테스트됐다. Submit 버튼의 미세 조정, 키보드 단축키 추가, 문구 수정까지 50회 가까운 수정이 이뤄졌다.

예전 직장이었다면 이 모든 개선이 며칠에서 몇 주의 엔지니어링과 디자인 왕복을 요구했거나, 아예 진행되지 않았을 일이다. 그런데 Claude는 무료이고, 무제한 반복을 허용했다. 50번째로 마음을 바꿔도 개의치 않는다. 이런 환경 덕분에 모든 노력이 실제 산출물 개선에 투입됐다.

디자이너에게 돌아오는 힘

엔지니어는 아이디어가 떠오르면 동작하는 개념 증명을 직접 만들 수 있다. 하지만 디자이너는 원래 그러지 못했다. 아이디어를 다른 사람에게 맡기면 시간 낭비가 될 수 있고, 사용자 니즈를 채우지 못하는 제안일 수도 있다. 그래서 디자이너는 늘 남을 설득해야 했다.

Claude로 실제 동작하는 아이디어를 구현하면, 이 부담이 줄어든다. 다른 사람들이 코드를 직접 실행해보고, 동작을 평가하고, 개선점을 제안할 수 있다. 프로토타입은 살아 있는 제안 문서가 됐다. 코드는 일회용이고, 리뷰어는 디자인과 사용자 경험에 대한 피드백을 제공한다.

이런 흐름이 자리 잡으면서 일의 균형이 디자이너 쪽으로 조금씩 기운다. 생각을 글로 쓰고, 동작하는 결과물을 만들고, 피드백을 받는 전 과정을 디자이너가 주도할 수 있기 때문이다.

새로운 긴장과 우려, 그리고 작은 실험

좋은 점만 있는 것은 아니다. Claude로 디자인하면 유연하고 창의적인 사고에서 벗어날 위험이 있다. Claude가 만들 수 있다고 여기는 결과에 갇혀, 같은 패턴의 디자인을 반복할 수 있다. 점진적인 성숙 도구에는 이 방식이 잘 맞지만, 완전히 새로운 영역에서는 통찰이 빠질 수 있다.

이 우려는 새로운 것이 아니다. 2011년에 "디자이너가 코드를 작성해야 하는가"라는 논쟁이 있었다. 비판자들은 프로그래밍을 시작하면 큰 변화를 시도하기 어려워진다고 우려했다. 하지만 실제로는 매체의 제약이 새로운 사고를 유도하기도 한다. 디자인을 코드로 표현하는 행위는 그 자체로 사고를 앞으로 밀어주는 촉매가 된다.

이 흐름을 우리 팀에 그대로 들여올 필요는 없다. 하지만 한두 가지 작은 실험은 시도해볼 만하다. 먼저, 작은 UX 개선을 Claude로 직접 만들어 보는 것이다. 사소한 인터랙션 한두 개를 골라, 디자이너가 직접 동작하는 버전을 만든다. 엔지니어에게 "이렇게 만들면 어떨까"라고 묻는 대신, 실행 가능한 결과물을 함께 본다.

다음으로, 사양서보다 프로토타입을 먼저 만든다. 글로 의도를 설명하는 단계와 실제 코드를 만드는 단계의 순서를 바꾼다. 마지막으로, "50번을 바꿔도 개의치 않는다"는 마인드를 팀에 들여온다. 작은 수정이 누적되어 큰 개선을 만든다는 사실을 모두가 체감하면, 책임 소재도 자연스럽게 풀린다.

결론은 단순하다. 디자인의 무게중심이 문서에서 동작하는 결과물로 이동하고 있다. 디자이너가 그 결과물을 직접 만들 수 있다면, 아이디어가 살아남을 확률이 훨씬 높아진다. Claude는 이 변화의 도구일 뿐, 방향은 여전히 디자이너가 정한다. 우리도 작은 실험부터 시작해보자.