Claude Code의 수석 디자이너가 AI로 빌드하는 방법 [유튜브]

 (youtube.com)
11P by GN⁺ | ★ favorite | 댓글과 토론
  • 실제 제품 개발에서 클로드 코드를 어떻게 쓰는지, Excalidraw에 autocomplete 기능을 직접 추가하며 실전 워크플로우를 시연
  • 디자이너의 발표지만 내용은 거의 개발자 워크플로우에 가까우며, worktree로 여러 Claude 세션을 병렬 실행하고, 기능 프로토타입을 만들고, 브라우저에서 검증하고, PR까지 올리는 과정을 CLI 중심으로 다룸
  • 핵심은 AI를 단순히 코드를 대신 쓰는 도구로 쓰는 것이 아니라, 아이디어 탐색 → 구현안 비교 → 셀프 검증 → PR 작성 → 리뷰 반영 → 머지 보조까지 이어지는 제품 개발 파이프라인에 넣는 방식임
  • 디자이너에게 유용한 지점은 Claude가 아직 디자인 판단을 잘하지 못한다는 한계를 인정하면서도, 여러 구현안을 빠르게 만들고 스크린샷·GIF가 포함된 PR로 검토하게 만들어 디자인 의사결정의 속도와 품질 관리를 함께 높이는 방법을 보여준다는 점
  • 개발자에게 유용한 지점은 /prototype, loop, 자동 권한 모드, Chrome 기반 셀프 테스트, 코드 정리·리뷰·PR 머지 자동화처럼 Claude Code를 실제 저장소와 협업 흐름 안에 연결하는 구체적인 패턴을 볼 수 있다는 점
  • 특히 “모두가 만들 수 있다고 해서 모든 것이 배포되어야 하는 것은 아니다”라는 관점이 중요하며, AI 시대에는 더 많은 사람이 코드를 만들 수 있게 되는 만큼 검증, 리뷰, 디자인 관여, 배포 기준을 자동화된 시스템으로 확장해야 함
  • 결국 이 영상은 디자이너가 AI로 코딩하는 법보다, 디자이너와 개발자가 AI를 사이에 두고 제품 품질을 유지하면서 더 빠르게 실험하는 방식을 보여주는 사례

발표 맥락과 발표자

  • Claude Code의 리드 디자이너인 Meaghan Choi
  • AI 도입 이전부터 CLI 제품을 설계해 왔으며, Claude CLI 설계에 참여했고 스스로 "CLI 신봉자(CLI die-hard)"라 표현
  • Anthropic 구성원은 도구에 상시 접근하며 종일 사용하기에, 더 최적의 작업 방식을 끊임없이 찾는 분위기라고 언급
  • 데스크톱 앱이 더 접근성이 높고, 데모의 모든 작업은 desktop app에서도 동일하게 가능하다고 명시
    • CLI는 발표자 개인 취향이며 시청자가 반드시 따라야 하는 방식은 아님

병렬·고속 작업 환경 설정

  • worktree

    • 로컬 저장소에서 여러 Claude를 동시에 돌리면 서로 작업을 덮어쓰며 충돌이 발생할 수 있음
    • worktree는 저장소의 격리된 복사본을 만들어 여러 작업을 병렬로 수행하게 함
      • 엔지니어들이 Claude를 4~5개 열어 두는 경우, 저장소를 repo1·repo2처럼 복제했거나 worktree를 쓰는 것
      • claude --worktree 실행 시 자동으로 새 브랜치를 체크아웃, 관리가 더 쉬워 추천

  • Opus 1M · fast mode

    • 발표자는 항상 Opus 100만 컨텍스트와 fast mode를 사용, 단 조직에 따라 접근이 제한될 수 있음
    • 15분 데모를 빠르게 진행하기 위한 설정으로, 약간의 속도 차이가 있다고 설명

  • auto mode

    • Anthropic 구성원은 항상 auto mode 사용, 낮은 권한 모드에 대한 대안
    • 분류기(classifier) 가 위험한 동작 여부를 감지하므로, "Yes, accept"를 반복 승인할 필요 없이 작업이 훨씬 빨라짐

  • Loop

    • Loop는 "다 끝날 때까지 계속"을 의미하는 표준 프롬프트로, 완료될 때까지 작업을 반복하게 함

프롬프트와 prototype skill

  • 디자인 스펙 없이 "autocomplete를 추가하고 싶다"는 단순 프롬프트만으로 Excalidraw에 기능 추가를 지시

  • prototype skill

    • Claude에게 요청해 직접 만든 slash prototype skill, 한 기능에 대해 기본 5개(n개) 구현안을 생성하고 HTML 파일로 미리보기 후 반복
      • 스킬은 손으로 작성하지 않고 프롬프트로 만든다고 강조, "요즘 스킬을 손으로 쓰는 사람은 없다"고 표현
    • Claude가 먼저 하나의 안을 직접 고르고 이유를 설명하도록 요청, 발표자는 결과를 보는 재미가 있다고 언급
    • "온라인 리서치 허용"을 추가, 프로덕션 코드베이스라면 Slack·Google Docs·논의 기록·BigQuery 등 모든 소스를 참고하게 지시했을 것
    • 최선안 구현·검증·스타일 일치 후 스크린샷이 포함된 PR 생성 지시
      • 이후 트랜스크립트가 아니라, 구현 기능의 녹화가 담긴 PR을 검토하는 방식으로 전환
    • 데모에서 Claude가 제시한 여러 탭 완성(autocomplete) 안 중 청중 의견을 반영해 2번 선택

작업의 3가지 원칙

  • Claude를 포함한 대부분의 LLM은 아직 디자인에 약함, 따라서 craft와 의사결정에는 사람이 계속 개입해야 함
    • 영구적인 한계는 아니지만, 현재 워크플로우는 "사람이 제품에 들어갈 것을 결정"한다는 전제 위에 구성
  • 코딩은 자동화하되 비코딩 업무도 Claude에 위임해야 하며, 그렇지 않으면 가장 자동화된 방식으로 쓰는 것이 아님
  • 누구나 ship할 수 있다고 모든 것을 ship해야 하는 것은 아님, 모두가 프로덕션에 푸시할 수 있게 된 만큼 확장 가능한 시스템이 필요

비코딩 업무 자동화

  • Claude in the web (cloud)

    • 앱에서 발견한 수백 개의 작은 polish 수정을 별도 세션 없이 상시 처리하는 용도
    • 수정이 너무 많다는 엔지니어 불만이 있을 땐 하나의 PR로 squash 요청
      • 사소한 CSS 변경은 검토 없이 자동 승인되기도 함, 제품의 완성도 유지에 유용

  • PR 머지 자동화

    • 거의 모든 구성원이 Claude를 상시 실행해 PR 머지를 돕게 함, 발표자는 더 이상 CI나 머지 직전 단계에 직접 관여하지 않음
    • simplify·code review는 저장소 내부용으로 코드베이스를 정리(prune), AI를 쓰는 엔지니어링 팀이라면 유사 도구가 있을 것
    • commit push PR은 내부 검사를 일괄 실행하는 명령
    • 열려 있는 PR을 검토해 완료 단계까지 밀어붙이는 명령은 스킬에 내장
      • Slack과 연동되어 코드 리뷰어나 on-call 담당에게 자동 DM, 도구 묶음의 통합이 핵심

  • Claude in Chrome

    • Claude가 직접 Chrome을 열어 동작을 테스트, 프론트엔드 변경의 자가 검증에 가장 좋은 방식으로 추천
    • 일련의 GIF로 스크린샷을 기록해 게시한 뒤 PR을 여는 흐름

  • 스케줄 루틴 (Claude code work)

    • 예약 작업(routine)으로 모든 저장소의 프론트엔드 변경을 스크랩
    • Slack·Google Meet 트랜스크립트·Google Docs 등을 훑어 디자이너 참여 여부를 확인, 미참여 시 플래그 처리
    • 미참여 시 디자인을 검토해 반대 관점의 디자인(adversarial design) PR을 초안으로 작성, 해당 엔지니어에게 DM 후 디자이너와 협업 요청
      • Claude가 디자인에 약해 DM 기능은 꺼 둔 상태, 1번 원칙(LLM은 아직 디자인에 약함)과 연결
    • 첫 단계가 아니라 다음 단계의 다음 단계까지 자동화를 밀어붙여, 차기 모델 출시 시 바로 적용할 수 있도록 미리 작성해 두는 전략

디자이너·개발자에게 유용한 이유

  • 발표의 목표 자체가 Claude Code 사용자의 작업 수준 향상(up level), 실제 Anthropic 내부에서 인기 있는 작업 방식을 그대로 공개
  • 개발자 관점에서는 worktree로 병렬 작업, auto mode로 승인 반복 제거, PR 머지·CI 자동화 등 일일 작업 속도를 직접 높이는 구체 명령과 동작을 제시
    • 발표에 쓰인 simplify·code review 같은 도구는 AI를 쓰는 엔지니어링 팀이라면 사내에 동등한 것이 있으므로, 엔지니어링 파트너에게 물어 활용하라고 안내
  • 디자이너 관점에서는 LLM이 아직 디자인에 약함을 전제로, 사람이 craft·의사결정의 주체로 남고 자동화는 보조에 둔다는 입장을 분명히 함
    • 디자이너 참여 없이 ship된 프론트엔드 변경을 탐지·플래그하는 스케줄 루틴처럼, 디자인 품질을 시스템으로 지키는 접근을 제시

함께 보면 좋은 글 β