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

• 사양 문서 작성과 Figma 목업 대신, 머릿속 아이디어를 그대로 동작하는 프로토타입 기능으로 직접 만드는 디자인 워크플로로 전환
• 과거에는 Copilot, Cursor, Gemini 등 LLM에 회의적이었으나, Jane Street 합류 후 AI 지원이 필수적임을 체감
• Claude는 무료·무제한 반복을 허용해, 50번을 바꿔도 불평 없이 Submit 버튼·단축키·문구 수정 등 세부 개선을 가능하게 함
• 디자이너도 엔지니어처럼 동작하는 개념 증명(POC) 을 스스로 만들어, 타인이 직접 써보며 평가하도록 함
• 실제 산출물 자체에 모든 노력을 집중시키는 방식으로, 중간 단계 부수 작업을 제거하는 새로운 협업 모델로 이어짐

---

LLM에 대한 회의에서 전환

• 오랫동안 LLM에 회의적이었으며, 사용할 때마다 결과에 실망
  • 작년에 직접 만든 게임을 수정하려 Copilot과 Cursor를 시도했으나 둘 다 동작하는 변경을 생성하지 못함
  • 이전 직장에서 Gemini로 제품 브리프 개요와 와이어프레임을 만들었으나 모두 폐기
  • LLM을 시도한 영역이 모두 이미 잘하는 일이었고, 직접 하는 것보다 결과가 나빴음
• 지난여름 Jane Street 합류 후 AI 지원이 필수적임을 체감
  • OCaml과 Bonsai 등 새롭고 아직 서툰 영역이 많기 때문
  • 가장 큰 놀라움은 자신이 가장 잘하는 영역인 디자인 워크플로가 바뀐 점

프로토타입 중심 워크플로

• 사양 문서, Figma 목업, 제안서 작성, 개발자와의 구현 리뷰 대신, 의도한 기능을 그대로 수행하는 프로토타입 기능을 직접 구축

• 실제 작업 흐름

  • 문제와 제안을 글로 작성
  • 에디터를 열고 빌드·서버·Claude를 실행하며, 작성한 설명을 프롬프트로 사용
  • 가능성을 입증하기 위해 기본 기능을 우선 동작시킴
  • 원하는 만큼 반복
  • 변경 사항을 개발 환경에 푸시하고 사용자 의견 수렴
  • 의도한 모습과 동작을 갖춘 feature(이 회사의 pull request에 해당) 제출
• 실제 코드베이스 안의 프로토타입이 목업·문서보다 거의 모든 면에서 더 나았음

JSQL 입력 프로토타입 사례

• 최근 JSQL 입력에 LLM 프롬프팅을 추가한 프로토타입 제작
  • JSQL은 다양한 사용자 대상 도구에 쓰이는 내부 SQL 방언
  • 실제로 동작했으며, 며칠간 사용하고 테스트하며 함께 생활
• Claude는 무료·무제한 반복을 허용해, 50번째로 마음을 바꾸거나 작은 수정을 요청해도 개의치 않음
  • Submit 버튼 다듬기, 키보드 단축키 추가, 문구 수정, 프롬프트 조정, 생성형 확인 메시지 추가
  • 이전 직장이었다면 며칠~몇 주의 엔지니어링·디자인 왕복이 필요했거나 아예 이뤄지지 않았을 개선
• 모든 노력이 실제 산출물 개선에 투입되고, Figma 컴포넌트 생성이나 문서 서식 같은 부수 작업에는 들어가지 않음

워크플로 정착 과정

• 이 방식에 도달하기까지 시간이 걸림
  • 합류 초기에는 UX 자잘한 결함 수정 같은 소규모 작업에만 AI 사용
  • 더 큰 아이디어에는 여전히 Figma·문서를 사용했고, Claude로 시도하면 실패
• 지난 두 달간 Figma에 손을 뻗는 상황이 급감
  • 모델 개선, 본인의 숙련도, 적절한 범위 선택의 조합으로 큰 작업에도 AI가 작동
  • JSQL 프롬프트 외에도 사용자 대상·데이터 모델·라이브러리 변경을 다루는 프로토타입 다수, 그중 일부는 2000줄 이상의 diff
  • Figma에서 설계한 뒤 인터랙티브 프로토타입을 구현하거나, 일부 신규 앱은 Figma를 완전히 건너뛰고 처음부터 Claude로 시각 디자인을 반복

디자이너에게 주는 힘

• 엔지니어는 아이디어가 생기면 동작하는 개념 증명을 직접 만들 수 있지만, 디자이너는 남을 설득해야 함
  • "JSQL 입력 내 직접 LLM 프롬프팅" 같은 아이디어는 시작 시점에 실현 가능성조차 불분명해, 누군가에게 프로토타입을 맡기면 시간 낭비가 될 수 있음
  • 사용자 니즈를 분명히 채우지 못하는 제안일 수도 있음
• Claude로 아이디어를 실제로 구현하면, 다른 사람들이 직접 써보며 평가하기가 훨씬 쉬워짐

리뷰 방식의 과제

• 단점은 리뷰어가 완성된 기능을 받게 된다는 점
  • 기능에 대한 입력 권한 없이 코드만 검토하게 되는지에 대한 의문
  • 디자인 영역에서 PM이 준 상세 와이어프레임을 받아 "보기 좋게만 만들라"고 요청받는 것과 유사
  • 제안은 최대한 명확·완전하게 하되, 엔지니어 동료들이 Figma 목업처럼 함께 디자인 영역에서 반복해 주길 원함

• 현재의 해결책

  • 기능을 다르게 바라보기로 하고, 설명에 짧은 안내 작성
  • 프로토타입은 살아있는 제안 문서, 코드는 일회용, 리뷰어의 역할은 디자인과 사용자 경험에 대한 피드백 제공
  • 최종적으로 리뷰어가 아이디어를 넘겨받아 별도 feature에서 구현하며, 프로토타입을 참조하되 프로덕션 코드를 직접 소유
  • 무엇이 합리적이고 좋은 느낌인지는 아직 모색 중

우려와 익숙한 긴장

• Claude로 디자인하면 유연하고 창의적인 사고에서 벗어나, Claude가 만들 수 있다고 여기는 결과에 갇힌 반복적 사고에 머무를 수 있다는 두려움
  • 변경이 점진적인 성숙한 도구에는 괜찮지만, 새로운 것을 다룰 때는 아이디어를 놓칠 수 있음
• 이는 익숙한 긴장이며, 2011년 "디자이너가 코드를 작성해야 하는가"라는 논의와 연결
  • 비판자들은 프로그래밍을 시작하면 아이디어에 큰 변화를 주기 어려워진다고 주장
  • 그러나 웹사이트 제작과 프로그래밍을 모두 좋아해 계속 코드를 작성
• React 같은 프런트엔드 프레임워크가 보편화되고 개발이 복잡해지자 전문화를 선택
  • 개인 프로젝트는 여전히 React로 만들어 개발자와의 소통에 도움
  • 업무 시간 대부분은 Figma와 문서에 투입
• LLM 이전에 Jane Street에 합류했다면 Figma에 더 깊이 매몰되었을 것
  • JavaScript는 어느 정도 경험이 있으나 OCaml과 Bonsai는 완전히 새로워 기술적 기여가 손에 닿지 않게 느껴졌을 것
  • 대신 실제 산출물을 다시 만들며, 그 매체로 돌아온 것이 멋지게 느껴지고 무엇이든 시도할 자유를 더 크게 체감

[GN⁺]

Hacker News 의견들

• 비즈니스 쪽은 이미 요구사항을 자기들이 생각해낸 해결책 형태로 가져오곤 하고, 대개 Rube Goldberg 장치 같은 물건이라 대화를 통해 역공학해야 진짜 요구사항에 도달함
  앞으로는 이미 “준비됐고” “동작하는” 해결책을 들고 와서, 설계와 아키텍처를 전체적으로 보자는 말에 더 안 열려 있을 것 같음
  “그냥 이렇게 만들면 되잖아. 거의 다 됐는데 왜 X 인시가 필요해?”가 될 듯함

  • 이미 이런 걸 봤고, 처음부터 끝까지 바이브 코딩으로 만들어져 있었음
    단점은 비즈니스 쪽이 왜 그 앱을 그대로 운영 배포하면 안 되는지 이해하지 못한다는 것임
    “AI로 빨리 갈 수 있잖아”라는 압박이 커지고, 결국 건강한 조직 역학에 달린 일이 될 것 같음
    장점은 냅킨 스케치보다 아이디어가 훨씬 더 철저히 검증되어 있다는 점임
    Claude가 이미 경계 사례와 설계 결정을 물어봤을 테고, 어느 순간 “그건 신경 쓰지 말고 가정해”나 “몇 번 써보니 이 상호작용은 별로니 다르게 해줘”라고 명시했을 가능성이 큼
    지금은 “뭐가 문제야, 그냥 배포해” 압박이 강하고 멍청하며 사기를 꺾어서 순손실에 가깝지만, 안정화되면 미래 프로젝트에는 순이득이 될 수도 있음
  • “거의 다 됐고, 운영 배포 전에 사소한 수정 몇 개만 하면 된다”는 식으로 들어오는 게 너무 많음
    그 사소한 수정이라는 게 브라우저가 정확히 1920px 폭이 아니면 레이아웃이 깨지는 문제, 필터와 정렬이 가끔 제대로 안 되는 문제, 어떤 동작 뒤 새 값이 앱에 제대로 갱신되지 않는 문제 같은 것들임
    문제와 상관없이 비즈니스 쪽은 자기들이 이미 95%를 했다고 생각해서 “숙련 개발자라면 금방 고칠 것”이라고 미리 추정함
  • 홈 데모 음악이 전문 품질에 가까워지면서 오디오 엔지니어링 세계에서는 이런 일이 한동안 흔했음
    사람들이 자기가 가진 결과물에 익숙해지고, 새 전문 믹스에서 바뀌는 걸 더 받아들이기 어려워함
  • 우리도 비즈니스 쪽이 자기들이 생각한 해결책을 요구사항처럼 가져오는데, 대개 고객이 원하는 것이 아님
    고객 문제를 사용성 좋은 제품 기능으로 번역하는 감각이 있는 PM, CSM, TAM도 있지만, 문제 정의를 건너뛰고 다른 기능 조직이 해결책을 만들게 하지 않으면 보통 엔지니어링과 다른 자원을 크게 낭비하는 참사가 됨
    누군가 해결책을 들고 오면 몇 달 동안 운영 가능한 소프트웨어를 만들고 나서야 고객이 싫어하고, 문제를 못 고치거나 새 문제를 만든다는 걸 알게 될 위험이 큼
  • 지금 실제로 벌어지고 있음
    내가 일하는 곳은 아니고 예전에 있던 곳인데, 데이터 손실과 보안 문제를 안고 그대로 운영 배포까지 됨

• Jane Street가 Anthropic 투자자인 걸로 알고 있으니, 그 점은 감안해야 함

  • 아주 큰 소금 한 줌과 함께 받아들여야 함
    2025년 7월 인도 증권거래위원회 SEBI가 Jane Street가 여러 법인을 이용해 시장 조작을 했다고 주장하며 시장 접근을 금지했다는 점도 있음
  • 내가 이해한 Jane Street는 OCaml에 큰 기여를 했고 자체 웹 프레임워크도 만드는 곳임
    큰 돈통에는 대시보드가 많이 필요할 테니까
    여기서 디자이너는 잘못된 접근을 하는 듯하고, 프로토타입을 최대한 깊고 현실적으로 만들고 싶어 하는 엔지니어 선망에 빠진 것처럼 보임
    하지만 그건 디자인 업무에서 가장 중요한 부분이 아님
    가장 중요한 건 올바른 것이 만들어지는 것임
    “왜 JSQL 입력 상자가 필요한가? 실제로 원하는 건 무엇인가? 다른 방법은 무엇인가?” 같은 질문은 펜과 종이 스케치, 회의, 관찰, 토론으로 더 잘 풀리는 경우가 많음
    특정 디자인으로 너무 빨리 좁혀서 버튼이 왼쪽이냐 오른쪽이냐, LLM 세부 동작이 어떠냐 같은 논의로 들어가는 것보다 낫다
  • 설령 투자자가 아니더라도, 퀀트 트레이딩 회사의 프론트엔드 디자인 견해를 얼마나 신경 써야 하는지는 잘 모르겠음
  • HN 전체가 이제 거대한 AI 광고판 같음
  • 무작위 직원의 조금 흥미로운 블로그 글까지 심리전으로 볼 필요는 없을지도 모름
    물론 그들이 바로 그렇게 생각하길 원하는 걸 수도 있음

• 가끔 이게 보임
  LLM은 현재 반복 너머를 보지 못해서, 내가 틀 밖에서 생각하며 “이 관점에서 보면 어떨까?”라고 해야 갑자기 새로운 설계 방식이 생김
  때로는 LLM이 자기 진행 단계 너머를 보게 하려고 흐름도를 만들어야 함

• “Claude가 내가 50번째로 마음을 바꾸거나 작은 수정을 요청해도 신경 쓰지 않는, 무료 무제한 반복을 줬다”는 말에서, Claude 비용을 안 내는 건가?

  • 여기서 “무료, 무제한 반복, 신경 쓰지 않음”은 보통 제3자 프로젝트 단위나 프리랜서 디자이너와 일할 때 “초안 + 수정 1회” 가격이고 이후 변경마다 추가 비용이 붙는다는 뜻에 가까워 보임
    작은 디자인 스튜디오도 비슷하고, 개발자처럼 시간당 과금이 아닐 때가 많음
  • Jane Street의 2025년 직원 1인당 순이익은 매출이 아니라 이익 기준으로 수백만 달러 후반대였음
  • 가격이 아니라 수작업 없이 창작적으로 자유롭다는 의미의 무료로 보임
  • 약간 관련해서, 예전에 CEO, 리드 개발자, 리드 디자이너가 있는 면접에서 뻔한 “약점이 뭐냐” 질문을 받았음
    솔직히 디자인을 정말 못하고, 디자인 시스템을 외삽하는 데도 문제가 있다고 답했음
    괜찮아 보이는 지점에 도달하기가 너무 어렵고, 그 과정에서 거의 항상 더 나쁘게 만들게 됨
    면접하던 디자이너가 그걸 개인적으로 받아들이고 나를 몰아붙였음
    전에도 비슷했음
    디자이너들은 어떻게 보여야 하는지에 대한 끊임없는 질문을 싫어했고, 한 번 넘기면 끝나는 식의 인계를 원했음
    마케팅·광고 에이전시에서도 디자인 명세에 없는 것들이 어떻게 보여야 하는지 샘플을 달라고 계속 싸워야 했음
    내가 옳았다는 말은 아니지만, 내게는 큰 아킬레스건임
    그래서 “무료, 무제한 반복, 신경 쓰지 않음”이라고 하면 돈보다 시간과 인내가 먼저 떠오름
    내가 프로토타이핑에 쓰는 Bolt는 화를 내지 않음
    최고의 디자인을 만들지는 못해도 내가 할 수 있는 것보다 훨씬 낫고, 끝나면 진짜 디자이너에게 더 좋게 만들게 하면 됨
    그 전까지 누군가를 화나게 할 걱정을 안 해도 됨

• 프런트엔드에 Claude Design을 써왔음
  결과물의 모양과 느낌은 충분히 괜찮지만, 디자인이 자주 비슷해 보이고 대체로 현대 웹의 상투적 패턴을 따름
  이걸로 비전형적인 창의적 시도를 해본 사람이 있는지 궁금함

  • 포트폴리오 사이트를 봐 주세요, 데스크톱에서 보는 게 좋음
    현재까지 약 3주 들였고 아직 미완성이지만 감은 올 것임
    지난 10년간 SaaS 보일러플레이트가 있었던 것처럼, 인터넷으로 학습된 LLM 보일러플레이트도 있음
    그래도 충분히 손을 들이면 무엇이든 여전히 가능함
  • 나도 그런 경험이 있어서 다른 프롬프트와 입력을 테스트하기 시작했음
    요구사항을 주면 맞추는 점과, 방향을 주지 않으면 안전한 선택을 하는 점이 재미있음
    출력의 미학과 사용자 경험·콘텐츠를 평가할 거면서 미학 쪽 프롬프트를 거의 안 주면, 안전한 기본값만 받게 됨
    bootstrap/tailwind 복제 느낌의 디자인은 잘 만들지만, 그 부분을 의식적으로 밀어야 함
    단순 웹 페이지에서는 초기 반복의 유일한 초점을 시각 스타일에 두기 시작했음
  • 대부분의 애플리케이션에는 비전형적인 창의성이 필요하지 않음
  • 나도 비슷함
    표준적이지 않게 보이도록 구체적으로 지시하고, 원하는 웹사이트 스타일 예시를 주면 됨
    좀 씨름하면 조금 더 창의적으로 느껴지지만, 프롬프트 작업이 필요함
  • 나도 Claude Design을 씀
    아주 존중받고 경험 많은 디자이너들에게 추천받았는데, 그들은 이제 거의 전적으로 Claude에서 프로토타입을 만들고 마음에 들면 Figma에서 다듬음
    애초에 자세한 스타일 프롬프트 없이 일반적인 UI를 요청하면 일반적인 디자인이 나오는 건 당연함

• 여기서 이점은 디자이너가 코딩을 배우는 것임
  소프트웨어가 어떻게 만들어지는지 모른 채 디자이너가 소프트웨어를 형성한다는 게 늘 이상했음
  참고로 나도 디자이너임
  다만 코드로 디자인하는 건 기술 우선 접근임
  디자인의 목적이 인간의 목적에 맞게 산출물을 형성하는 것이라면, 코드의 엄격한 규칙에서 시작하지 않는 편이 더 낫다고도 볼 수 있음
  보기 좋은 결과물 때문이 아니라 사고를 앞으로 밀어주는 데는 여전히 펜과 종이를 이기기 어려움

  • 6년 동안 풀스택과 프런트엔드 중심 엔지니어로 일하다가 손으로 코드 쓰는 데 질려 디자인으로 옮겼음
    이제 사실상 목소리로 코딩할 수 있게 되면서 다시 바이브 코딩과 제품 만들기로 돌아가고 있고, 정말 좋음
    상사는 이 새로운 상황을 아직 파악 중이지만, 구식 역할 분리는 죽어가기 시작한 것 같음
    교차점에 있는 게 지금은 가장 좋은 자리라고 봄
    내 평생이 이 순간을 준비해온 느낌임
  • 매체의 제약을 이해하는 건 도움이 되지만, 실리콘 안에서 전자가 움직이는 수준까지 모든 층위를 알 필요는 없음
  • LLM은 보통 코딩을 잊게 만들기 때문에, 이런 식으로 쓰면 학습에 좋을지는 의심스러움
    디자이너에게는 결과를 보고 시각 편집기 대신 언어로 수정하는 Figma와 비슷할 듯함
  • 디자이너들이 코딩을 배우는 게 아님
    내 아내는 FAANG에서 제품 관리자로 일하는데, 팀이 원래 Word나 Excel 같은 걸로 했을 소프트웨어 조각을 AI로 바이브 코딩하는 데 극도로 기대고 있음
    그들은 코딩을 배우지 않고, 코드를 1초도 들여다보지 않음
  • 엔지니어와 긴밀히 일해봤고 판단이 제대로 서 있는 디자이너가 필요함

• “프로토타입은 살아 있는 제안 문서이고, 코드는 버려도 되며, 리뷰어의 일은 설계와 사용자 경험에 피드백을 주는 것이다
  결국 리뷰어가 아이디어를 넘겨받아 별도 기능으로 구현하고, 프로토타입은 참고하되 운영 코드는 직접 소유한다”는 접근은 내가 모든 POC에서 겪던 문제를 풀어줌
  정말 좋은 방식임

  • 그 글은 Figma로 생계를 유지하는 사람이 쓴 게 아님
    특정 제품의 특정 이슈를 다룰 때는 “제안 문서”라고 부르기 쉽다
    하지만 여전히 수많은 디자이너가 Figma를 사용해 제품과 플랫폼 전반에 걸친 디자인 시스템을 정의하고 유지하며, 그 경우 Figma가 진실의 원천임

• 우리 팀도 이렇게 하고 있고, 나는 프런트엔드 엔지니어인데 솔직히 예전 방식이 정말 그리움
  작성된 명세가 동작하는 프로토타입으로 대체되면서, 이제 코드를 읽고 의도된 변경이 무엇인지, 버려야 할 잡음이 무엇인지 판단해야 하는 추가 인지 부담이 생김
  생성된 PR을 넘겨받아 필요한 변경을 할지, 처음부터 다시 만들지 결정해야 하고 어느 쪽이든 마찰이 있음
  의도치 않은 변경이 잔뜩 생성된 적도 있는데, 내가 재구현에 시간을 들여 옮긴 뒤 나중에 “앗, 죄송해요, 그건 바꾸려던 게 아니었어요”가 되기도 했음
  권한을 준다는 점은 이해하지만, 예전 일에서 느꼈던 즐거움 일부를 빼앗고 골칫거리로 바꿔놓음

  • 나도 비슷한 처지임
    디자인과 제품 쪽이 Claude로 기능이나 경험을 바이브 설계·코딩하고 빠르게 프로토타입을 만들어, 최소한의 엔지니어링 시간으로 고객 앞에 가져가 피드백을 받음
    훌륭함
    하지만 전체적으로 더 빨리 출시하는 데는 별 도움이 되지 않았다는 점이 놀라울 수 있음
    이유는 그 과정에서 생각을 잃었기 때문이라고 봄
    적지 않은 사고가 이제 언어 모델에 외주화됐음
    프롬프트의 빈틈을 덮어 칠하고, 명시되지 않은 동작을 환각으로 채워 넣음
    예전 같으면 “이건 잘 안 맞는데”, “이 아이디어를 어떻게 전달하지”, “이 경우엔 어떻게 되지”라며 멈췄을 것들이 사라졌고, 이제 그런 세부사항은 제대로 만든 뒤로 밀림
    물론 프로세스를 개선하고 이 새 기법을 더 잘 활용하는 법을 돌아볼 수는 있지만, 예전보다 나은가 하면 글쎄
  • Claude Design에게 프로토타입을 완전히 명세하는 문서를 쓰게 하면 안 되나?
  • 예전 방식은 둔하고, 피드백 주기가 길고, UI를 게이트키핑했음
    사양함
    이제 백엔드 사람들이 프런트엔드도 함
  • 코드는 이제 읽으라고 만든 게 아님
    그게 착각임
    컴파일러가 만들어낸 어셈블리를 들여다보나? 안 봄
    그런데 왜 이 코드를 보고 있나?
    우리는 추상화 계층을 위로 올린 것임

• 나도 같은 접근을 많이 씀
  AI 전에도 수동으로 이렇게 했음
  먼저 사용자와 펜·종이만 들고 앉고, 그다음 프런트엔드 POC나 데모를 빠르게 만들고, 사용자가 만져보게 한 뒤 원하는 대로 작동할 때까지 조정했음
  내게는 운영 품질이 아닌 빠른 프런트엔드 데모를 코드로 만드는 게 Figma에서 정확한 상호작용을 만드는 것보다 이미 더 빠른 경우가 많았음
  완전한 상호작용이 가능해서 사용자 경험 쪽 경계 사례를 훨씬 더 많이 잡을 수 있었음
  이제 Claude Code 덕분에 버릴 프로토타입을 만드는 속도가 더 빨라졌지만, 엄청난 차이는 아님
  사용자와 논의하고 어떻게 동작해야 할지 생각하는 시간이 전체의 80%라서, Claude는 직접 빠르게 만들 때와 비교해 나머지 20%를 절반으로 줄여주는 정도임
  첫 버전은 더 빠르지만, 완전히 이해하지 못했을 때 반복은 더 느림

• Edwin, 글이 올라온 걸 보니 반갑다
  2012/2013년쯤 같이 해커톤 했던 기억이 있음
  동작하는 프로토타입까지 더 빨리 도달하는 능력은, 미완성 아이디어를 그대로 배포하려는 유혹이 있더라도 매우 힘을 실어줌
  디자인과 사용자 경험 요구사항은 스토리보드와 와이어프레임을 넘어서 실제 흐름을 만져보고 경험할 수 있을 때 큰 이득을 얻음