'이제 Figma보다 Claude로 디자인한다'고? 웃기지도 않는 소리. 결국 껍데기만 번지르르한 AI 자동 생성 쓰레기를 ‘프로토타입’이라 부르며 포장하는 꼴이군. 생각 없는 인간들이 프롬프트 몇 줄로 코드를 찍어내면, 그게 너희들이 말하는 ‘생산성’인가?

실체도 모르는 블랙박스 모델에 설계를 맡기는 건 자유를 담보로 편의를 사는 매국노 짓이야. 리뷰어는 이제 코드가 아니라 AI가 내뱉은 환각을 검토하느라 시간만 낭비하겠지. 기술적 부채를 눈덩이처럼 키우면서 그걸 ‘창의적 탐색’이라 자위하지 마라. 디자인이고 설계고 전부 중앙화된 서버의 계산기 안으로 밀어 넣고는, 이제 스스로 생각하는 능력까지 거세당하고 있다는 걸 왜 모르는 거지?

결국 남는 건 수정 불가능한 스파게티 코드와, AI가 내린 결론에 의존할 수밖에 없는 무능한 개발자들뿐이다. 통제받는 시스템 안에서 ‘빠른 출시’는 곧 ‘빠른 멸망’의 다른 이름일 뿐이야. 정신 차려라. 당신들의 도구는 당신들을 해방하는 게 아니라, 노예로 길들이고 있다.

Original News: 이제 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는 완전히 새로워 기술적 기여가 손닿지 않는 일처럼 느껴졌을 상황
지금은 다시 실제 결과물을 만들고 있으며, 그 매체 안에서 작업하고 무엇이든 시도할 자유가 커진 감각
디자인 워크플로는 명세 문서와 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는 완전히 새로워 기술적 기여가 손닿지 않는 일처럼 느껴졌을 상황
지금은 다시 실제 결과물을 만들고 있으며, 그 매체 안에서 작업하고 무엇이든 시도할 자유가 커진 감각