이제 Figma보다 Claude로 더 많이 디자인한다

• 디자인 워크플로는 명세 문서와 Figma 목업을 거쳐 구현을 검토하는 방식에서, 실제 코드베이스에 동작하는 프로토타입 기능을 만드는 흐름으로 이동 중
• Copilot, Cursor, Gemini는 이미 잘하던 게임 수정·제품 브리프·와이어프레임 작업에서 기대에 못 미쳤지만, 새로 익혀야 하는 OCaml과 Bonsai 환경에서는 AI 지원이 필수 요소
• 문제와 제안을 프롬프트로 넘긴 뒤 기본 기능 구현, 반복 수정, 개발 환경 배포, 사용자 의견 확인, feature 제출까지 이어지는 실제 구현 중심 절차
• JSQL 입력에 LLM 프롬프팅을 더한 프로토타입은 버튼, 단축키, 문구, 프롬프트, 확인 메시지를 여러 차례 다듬게 했고, Figma 컴포넌트나 문서 서식 대신 실제 산출물에 노력 집중
• 디자이너가 아이디어를 직접 사용 가능한 형태로 만들 수 있게 됐지만, 완성된 기능처럼 보이는 프로토타입은 리뷰 참여 방식과 창의적 탐색에 새로운 과제 동반

LLM 회의감에서 필수 지원 도구로

• 오랫동안 LLM을 쓸 때마다 결과에 실망했고, 잘하는 작업에 LLM을 적용할 때마다 직접 하는 것보다 낮은 품질이라는 경험
• 지난해 만든 게임을 수정하려고 Copilot과 Cursor를 사용했지만 둘 다 동작하는 변경을 만들지 못했고, 이전 직장에서 Gemini로 제품 브리프 개요와 와이어프레임 생성을 시도했지만 모두 폐기
• 지난여름 Jane Street 합류 후 새로 배울 것이 많았고, 아직 익숙하지 않은 OCaml과 Bonsai 같은 기술 때문에 AI 지원이 필수적 역할
• 큰 변화는 가장 자신 있던 디자인 워크플로까지 AI가 바꿨다는 점

Figma·문서 대신 실제 코드베이스 프로토타입

• 명세 문서 작성, Figma 목업 제작, 제안서 작성, 개발자와의 구현 검토 대신 머릿속에 있는 기능을 정확히 수행하는 프로토타입 기능 제작
• 실제 흐름은 문제와 제안을 설명하는 문장을 쓰고, 에디터에서 빌드·서버·Claude를 실행하며, 작성한 설명을 프롬프트로 사용하는 방식
  • 기본 기능을 작동시켜 가능성을 확인한 뒤 원하는 만큼 반복 수정
  • 변경 사항을 개발 환경에 올리고 사용자 의견을 물은 뒤, 원하는 모양과 동작을 갖춘 feature 제출
  • feature는 Jane Street에서 pull request에 해당하는 절차
• 실제 코드베이스 안의 프로토타입 기능은 목업과 문서보다 거의 모든 면에서 더 나은 경험
• 최근 JSQL 입력에 LLM 프롬프팅을 추가한 프로토타입은 실제로 동작했고, 며칠 동안 직접 사용하며 테스트한 사례
  • JSQL은 여러 사용자 대상 도구에 쓰는 내부 SQL 방언
  • Claude는 50번째 마음 변경이나 작은 수정 요청에도 개의치 않는 자유롭고 무제한인 반복 제공
  • Submit 버튼, 키보드 단축키, 문구, 프롬프트, 생성된 확인 메시지까지 개선
• 이전 직장에서는 엔지니어링과 디자인의 며칠 또는 몇 주짜리 왕복 작업이 필요했거나, 더 높은 확률로 아예 일어나지 않았을 워크플로 개선
• 이 기능에 들인 노력은 Figma 컴포넌트 생성이나 문서 서식 조정 같은 중간 산출물이 아니라 실제 산출물 개선에 집중

최근 두 달 사이의 범위 확대

• 이 흐름에 이르기까지 시간이 걸렸고, 합류 초기에는 UX의 작은 불편 수정 같은 작은 작업에만 AI 사용
• 큰 아이디어에는 여전히 Figma와 문서를 사용했고, Claude로 만들려는 시도는 실패
• 지난 2개월 동안 Figma를 여는 상황이 급격히 줄었고, 개선된 모델, 도구 숙련도, 적절한 범위 선택이 함께 작용
• AI는 JSQL 프롬프트뿐 아니라 사용자 대상, 데이터 모델, 라이브러리 변경을 만드는 6개가량의 프로토타입에도 작동
  • 일부 프로토타입은 2000줄 이상 diff
  • Figma에서 설계한 새 앱의 인터랙티브 프로토타입 구현에도 사용
  • 일부 새 앱은 Figma를 건너뛰고 처음부터 Claude로 시각 디자인 반복

디자이너의 권한 확대와 리뷰 방식 재정의

• 엔지니어는 아이디어가 있을 때 동작하는 개념 증명을 만들 수 있지만, 디자이너는 다른 사람이 대신 만들어주도록 설득해야 하는 구조
• “JSQL 입력에서 직접 LLM 프롬프팅” 같은 아이디어는 시작 시점에 실현 가능성이 분명하지 않아, 다른 사람에게 프로토타입을 맡기면 시간을 낭비할 수 있는 상황
• 어떤 제안은 사용자 요구를 명확히 채우지 못할 수 있고, Claude로 아이디어를 실제 형태로 만들면 다른 사람이 직접 사용하며 평가하기 쉬운 상태
• 단점은 리뷰어가 완성된 기능을 받는 형태가 되어 기능에 대한 입력 없이 코드만 검토해야 하는지 불분명해지는 문제
• 디자인 쪽으로 비유하면 PM이 상세 와이어프레임을 주고 보기 좋게 만들어달라고 하는 일과 비슷해, 즐거운 리뷰 작업이 아님
• 제안은 명확하고 완전해야 하지만, 엔지니어 동료가 Figma 목업처럼 디자인 공간에서 함께 반복할 대상으로 다루어야 하는 요구
• 현재 해결책은 feature 설명에 짧은 알림을 넣는 방식
  • 프로토타입은 살아 있는 제안 문서
  • 코드는 폐기 가능
  • 리뷰어의 역할은 디자인과 사용자 경험 피드백
• 최종적으로 리뷰어가 아이디어를 넘겨받아 별도 feature에서 구현하고, 프로토타입을 참조하되 프로덕션 코드는 리뷰어가 소유하는 방식
• 실제 업무에서는 새 워크플로에서 무엇이 타당하고 좋은 느낌인지 계속 파악 중

반복 작업의 제약과 다시 실제 매체로 돌아온 감각

• Claude로 디자인하면 유동적이고 창의적인 사고방식에서 멀어지고, Claude가 만들 수 있다고 생각하는 결과 안에서 반복 작업에 갇힐 수 있다는 우려
• 성숙한 도구처럼 변화가 반복적인 경우에는 괜찮지만, 새로운 것을 만들 때는 아이디어를 놓칠 수 있는 위험
• 2011년 전문 경력을 시작할 무렵 designers should code 논의가 많았고, 비판자들은 프로그래밍을 시작하면 아이디어에 큰 변화를 주기 어렵다고 주장
• 웹사이트 만들기와 프로그래밍을 좋아해서 계속 코드를 썼고, React 같은 프런트엔드 프레임워크가 보편화되고 프런트엔드 개발이 복잡해진 뒤에는 전문화를 선택
• React 개인 프로젝트는 개발자와 상호작용하는 데 도움이 되었지만, 직장에서는 거의 모든 시간을 Figma와 문서에서 사용
• LLM 이전에 Jane Street에 합류했다면 Figma에 더 깊이 고착되었을 것이고, JavaScript와 달리 OCaml과 Bonsai는 완전히 새로워 기술적 기여가 손닿지 않는 일처럼 느껴졌을 상황
• 지금은 다시 실제 결과물을 만들고 있으며, 그 매체 안에서 작업하고 무엇이든 시도할 자유가 커진 감각