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

[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년쯤 같이 해커톤 했던 기억이 있음
  동작하는 프로토타입까지 더 빨리 도달하는 능력은, 미완성 아이디어를 그대로 배포하려는 유혹이 있더라도 매우 힘을 실어줌
  디자인과 사용자 경험 요구사항은 스토리보드와 와이어프레임을 넘어서 실제 흐름을 만져보고 경험할 수 있을 때 큰 이득을 얻음