디자인에서 코드까지: Claude Code 40분 완전정복 튜토리얼 | 메이건 최

채널 아이콘
Peter Yang 구독자 29,800명

요약

이 영상은 Cloud Code를 활용해 디자이너가 Figma 디자인을 바로 코드베이스에 적용하고, 최종 프로덕션 환경까지 직접 배포하는 워크플로우를 보여줍니다. 메이건 최는 아이디어 탐색, 코드 이해, Figma→코드 전환, 마지막 10% 폴리싱까지 3가지 주요 단계별로 실시간 데모와 키 바인딩·프로 팁을 공유합니다. 이를 통해 디자이너와 엔지니어 간 경계를 허물고, 더 빠르고 유연한 협업 환경을 제시합니다.

주요 키워드

Cloud Code Zero-to-One Exploration Pull Request MCP Server Auto Accept Mode Double Diamond CLI Tailwind CSS Design System Background Bashes

하이라이트

  • 🚀 Cloud Code를 통해 디자이너도 바로 코드 베이스에 접속해 PR(풀 리퀘스트)으로 프로토타입을 공유할 수 있습니다.
  • 🌟 Zero-to-One Exploration 단계를 Cloud Code 안에서 실행해 아이디어를 실제 코드베이스에 즉시 반영합니다.
  • 🔑 Shift+Tab으로 계획 모드(plan mode)와 자동 수락 모드(auto accept mode)를 전환해 작업 흐름을 쉽게 관리합니다.
  • 📌 Ctrl+V로 Figma 스크린샷을 드래그 앤 드롭해 코드 화면에 붙여넣고, Vision 기능으로 화면 구조를 분석합니다.
  • ⚡︎ Ctrl+B Background Bashes로 개발 서버를 백그라운드에서 실행하면서도 Claude와 대화를 이어갈 수 있습니다.
  • 🌱 Double Diamond 모델(탐색→설계→프로토타입→폴리싱) 전 단계에서 Cloud Code를 적극 활용해 기술적 과제까지 해결합니다.
  • 🛠️ cloud.md 파일을 커스터마이징해 디자이너 전용 지침을 추가하고, Cloud Code 출력을 개인화합니다.
  • 📈 내부 도그푸딩 이후 외부 커뮤니티에 조기 출시하고, 팀 피드백과 애널리틱스로 실시간 개선을 진행합니다.

용어 설명

Cloud Code

Anthropic에서 제공하는 AI 통합 코드 협업 도구로, 코드베이스 탐색·자동 수정·백그라운드 실행을 지원합니다.

Pull Request (PR)

Git 기반 협업 워크플로에서 코드 변경사항을 제안하고 리뷰를 요청하기 위한 기능입니다.

MCP Server

Cloud Code와 외부 서비스(AI·디자인·테스트 도구 등)를 연결해 추가 기능을 제공하는 서버 플러그인입니다.

Zero-to-One Exploration

제품 초기 아이디어를 코드베이스 맥락에서 신속하게 프로토타입하고 검증하는 탐색 단계입니다.

Auto Accept Mode

Claude가 계획 검토를 건너뛰고 자동으로 코드 변경을 적용하도록 설정하는 모드입니다.

Double Diamond

탐색(Explore)→발견(Discover)→설계(Design)→폴리싱(Polish)으로 이루어진 전통적 디자인 프로세스 프레임워크입니다.

CLI

Command Line Interface의 약자로, 터미널에서 명령어를 입력해 컴퓨터를 제어하는 인터페이스입니다.

Tailwind CSS

유틸리티 클래스 중심의 CSS 프레임워크로, 빠르게 스타일을 정의할 수 있도록 돕습니다.

[00:00:34] 인트로 및 출연자 소개

메이건 최가 디자인 리드로서 Cloud Code를 통해 기능 디자인부터 프로덕션 배포까지 직접 수행하는 환경을 설명하며, 워크플로우 개요를 소개합니다.

[00:38] 인터뷰어가 Claude Code 디자인 리드인 Megan을 소개합니다. Megan은 기능 디자인뿐만 아니라 정기적으로 프로덕션 배포까지 담당하는 인물로, AI를 활용한 디자인 워크플로우와 디자인에서 프로토타입까지의 과정을 데모할 예정이라고 합니다.
[00:01:05] 디자이너의 프로덕션 배포 경험

정기적으로 코드 배포를 경험하는 디자이너로서 두려움과 마법 같은 성취감을 이야기하고, Figma의 디테일을 직접 코드에서 다듬는 과정을 공유합니다.

[01:05] 디자이너로서 정기적으로 프로덕션에 배포하는 경험에 대한 질문에 Megan은 '무섭지만 마법 같다'고 표현합니다. 과거에는 디자인 또는 개발 중 한 쪽에만 집중해야 했지만, 최근 5년간 코딩이 훨씬 쉬워져서 엔지니어들에게 요청하기 어려웠던 세부 사항들을 직접 처리할 수 있게 되었다고 설명합니다.
[01:58] 인터뷰어가 공감하며, 엔지니어들에게 사소한 픽셀 변경이나 카피 수정을 요청하는 것이 미안했다고 언급합니다. Megan은 디자인을 실제 프로덕션으로 옮겼을 때 예상과 다른 결과를 보고 다시 수정을 요청해야 하는 상황에서 더욱 미안함을 느꼈다고 덧붙이며, 이제는 모든 것을 직접 할 수 있는 힘을 얻었다고 강조합니다.
[00:02:26] 디자인 프로세스와 Cloud Code 활용 개요

아이디어 탐색(Zero-to-One Exploration), 코드베이스 이해, Figma 디자인→코드 전환 및 마지막 폴리싱까지 3가지 주요 워크플로우별로 Cloud Code 활용법을 요약합니다.

[02:33] Meaghan이 자신의 디자인 워크플로우에서 Claude Code를 활용하는 세 가지 주요 방법을 소개합니다. 첫 번째는 제로에서 원으로의 탐색으로, 기술적 배경이 적은 사람들도 쉽게 접근할 수 있는 방법입니다.
[02:56] 두 번째와 세 번째 워크플로우는 실무에서 더 자주 사용하는 방법들로, 코드베이스 이해와 실제 구현 단계에서 Claude Code를 활용하는 것입니다. 새로운 기능을 개발할 때 먼저 Claude에게 현재 시스템이 어떻게 작동하는지 물어보는 것부터 시작합니다.
[04:01] 실제 작업 과정에서는 Figma에서 디자인 작업을 한 후, 엔지니어가 구축한 인프라를 바탕으로 최종 다듬기 작업을 하거나 직접 Claude Code로 첫 시도를 해봅니다.
[04:25] 실무에서는 제로에서 원으로의 탐색보다는 코드베이스 이해와 실제 구현에 시간의 90%를 할애한다고 설명합니다. 이어서 전체적인 디자인 프로세스를 더블 다이아몬드 모델로 설명하며, 탐색-발견-디자인-프로토타입-완성의 단계를 거친다고 합니다.
[00:04:49] Double Diamond 모델과 구현 단계

전통적 디자인 프로세스(Double Diamond)의 탐색→발견→설계→프로토타입→폴리싱 단계에서 Cloud Code가 어떻게 기술적 과제까지 지원하는지 구체적 예시를 통해 살펴봅니다.

[05:08] Claude Code는 개발 전용 도구가 아니라 디자이너와 비개발자들이 탐색, 설계, 프로토타이핑 단계에서 활용할 수 있는 강력한 도구라고 설명합니다.
[05:23] 코드베이스에 접근할 수 있게 해주어 기술적 인접 작업들을 수행할 수 있고, 기술 전문가들도 모르는 사이에 자연스럽게 사용하고 있을 정도로 접근성이 높다고 강조합니다.
[05:40] 다양한 솔루션 탐색, 구현 역사 이해, 기능 구축을 위한 계획 수립과 순서 정하기 등의 작업을 Claude Code에서 수행하는 것을 선호한다고 말합니다.
[05:59] 디자이너의 역할은 사용자, 엔지니어, 제품 관리자 등 모든 당사자의 피드백을 받아 작동하는 제품 경험으로 번역하는 것이며, 그 제품 경험은 결국 코드로 구현된다고 설명합니다.
[06:25] 코드가 진실의 소스라고 강조하며, 스펙에서 Figma로, 최종적으로 코드로 이어지는 전통적인 과정 대신 바로 코드에서 프로토타입을 만들고 탐색할 수 있다고 설명합니다.
[06:51] 과거에 Figma 목업 대신 초안 PR을 엔지니어에게 넘겨준 경험을 공유하며, 이것이 일반적인 프로세스보다 더 앞선 시점에서 기능 개발을 시작할 수 있는 좋은 방법이라고 설명합니다.
[07:17] 이런 방식을 통해 팀의 신뢰받는 구성원이 될 수 있다고 하며, 팀 합류 시 엔지니어들로부터 GitHub 액세스 권한을 얻기 위한 대화에 대해 질문받습니다.
[07:32] Anthropic에서는 누구나 코딩할 수 있다고 답변을 시작합니다.
[07:33] Anthropic은 매우 협업적인 환경으로, 역할 구분이 중요하지 않고 팀이 디자이너의 코딩 참여를 적극적으로 환영한다고 설명합니다.
[07:49] 다른 회사에서는 엔지니어와 페어 프로그래밍을 통해 레포지토리 구조와 개발 환경 설정을 배우며, 이를 통해 협력 관계를 구축하고 배포 프로세스를 이해한다고 조언합니다.
[08:30] 디자인 리뷰 과정에 대한 질문에 답하며, 제품 리뷰, 디자인 크리틱, 딥다이브 등 다양한 형태로 진행되며, Figma 프로토타입부터 완전히 작동하는 앱까지 다양한 형태로 발표한다고 설명합니다.
[09:05] 코딩 스킬이 비기술직에게도 활용 가능하며, 이를 새로운 작업 방식으로 생각해야 한다고 강조하고, 코드를 가장 높은 피델리티의 표현 방법으로 간주해야 한다고 제안합니다.
[09:42] 여전히 큰 아키텍처 변경사항의 경우 Figma가 더 적합한 경우가 있다고 인정하며, 이는 개인의 기술적 한계일 수도 있다고 솔직하게 언급합니다.
[09:57] Figma에서 하는 디자인 변경과 코드 작업 간의 시간 효율성을 비교하며, 작업의 복잡도에 따라 적절한 도구를 선택해야 한다고 설명합니다.
[10:11] Figma의 오토 레이아웃 기능이 의외로 복잡하다는 점을 언급하며, 파워 유저 도구라는 특성을 강조합니다.
[10:25] Linear라는 프로젝트 관리 도구의 광고가 진행되며, 빠른 속도와 AI 에이전트 지원, 주요 기업들의 사용 사례를 소개합니다.
[11:06] 실제 데모를 위해 Claude Cafe라는 데모 앱을 소개하며, 내부 작업은 공개할 수 없다고 설명합니다.
[00:11:13] Claude Cafe 데모 및 실행

샘플 앱 Claude Cafe를 로컬에서 Cloud Code로 실행하고, 헤더 정렬과 이미지 배치 등 마지막 10% 다듬기 과정을 실시간 대화형 시연으로 소개합니다.

[11:33] Claude Code에서 앱을 로컬로 실행하는 과정을 시연하며, 엔지니어에게 말하듯 자연스럽게 Claude와 대화하는 방식을 보여줍니다.
[12:00] 백그라운드 bash 기능을 소개하며, dev 서버를 백그라운드에서 실행하면서도 Claude와 계속 대화할 수 있다는 편리함을 설명합니다.
[12:29] 디자인을 코드로 구현한 후 두 개의 에이전트가 동시에 작동하며 백그라운드에서 bash 명령을 실행할 수 있다는 것을 확인합니다.
[12:46] 로컬호스트에서 실행 중인 앱을 확인해보니, 원래 디자인과 비교했을 때 이미지 정렬이나 헤더 위치 등 세부사항들이 완벽하지 않아 마지막 10% 완성도를 높일 필요가 있음을 발견합니다.
[13:23] Claude Code에서 가장 많은 시간을 보내는 부분으로, Figma MCP 서버 대신 Claude의 비전 기능을 활용해 디자인 파일을 PNG로 내보내고 드래그 앤 드롭으로 업로드하는 방법을 설명합니다.
[14:36] 더 고급 방법으로는 웹 인스펙터 모드를 사용해 직접 클래스나 렌더링 방식을 확인하고, Claude에게 특정 코드 라인을 찾아 업데이트하도록 지시하는 다양한 워크플로우가 있다고 설명합니다.
[15:20] 디자이너가 일반적인 코딩 워크플로우와 달리 먼저 계획 모드로 들어가는 방법을 설명합니다. Claude에게 계획과 접근 방식의 개요를 요청하고, 작업을 이해하기 쉬운 단계로 나누어달라고 하는 것이 중요하다고 강조합니다.
[15:50] Claude는 소프트웨어 엔지니어처럼 대화하도록 설계되어 있지만, 비전공자를 위해 추가 설명을 요청하는 것이 좋다고 조언합니다. 자동 수락 모드에서는 Claude가 독단적으로 진행할 수 있어 주의가 필요합니다.
[16:15] 계획 단계가 코딩 학습자에게 소프트웨어 아키텍처와 엔지니어의 사고방식을 이해하는데 도움이 된다고 설명합니다. Claude가 변경사항과 CSS를 구체적으로 보여주어 향후 개발에 참고할 수 있게 해줍니다.
[16:50] 자동 수락 편집 모드의 장점을 설명하며, 코드를 완전히 이해하지 못해도 Claude가 변경사항을 적용한 후 최종 결과를 확인할 수 있다고 합니다. 실시간으로 변경사항을 시각적으로 확인하는 것을 선호한다고 말합니다.
[17:15] 로컬호스트 설정의 중요성을 강조하며, 디자인이 시각적 작업이므로 모든 변경사항을 실시간으로 보는 것이 필수적이라고 설명합니다. 데모에서 사용한 클로 카페 앱이 실제가 아닌 팀 디자이너가 만든 프로토타입임을 밝힙니다.
[17:44] AI가 생성하는 동일한 스타일 문제에 대해 질문하고, 메건이 Tailwind CSS의 보라색 배경 등 일반적인 AI 스타일링을 피하는 방법을 설명합니다.
[17:57] 메건은 AI를 기반 없는 완전 새로운 디자인에 사용하지 않는다고 설명하며, 기존 사이트 부분을 참조하거나 영감 이미지를 제공하는 방법을 추천합니다.
[18:25] 구체적인 예시로 클로드 페이지 설정 추가 작업을 들며, 기존 설정을 참조하여 재구현을 요청하는 방식을 설명합니다.
[18:40] 클로드 채팅에서 좋아하는 사이트 스크린샷을 핀터레스트 보드처럼 활용하는 무드보드 방식을 소개합니다.
[18:55] 대화가 메건의 클로드.md 파일로 이동하며, 기존의 단순한 init 명령어보다 훨씬 정교한 파일 구성에 대해 관심을 보입니다.
[19:29] 메건이 클로드.md 생태계의 강력함을 설명하며, 계층적 구조와 공유 지식 시스템을 도입한 업데이트에 대해 설명합니다.
[19:45] 전체 코드베이스용 공유 클로드.md 파일들과 개인용 클로드.md 파일의 차이점을 설명하며, 개인 파일은 전역적으로 작동한다고 소개합니다.
[20:13] 화자가 Claude Code의 디자이너 전용 버전 개발을 팀에 요청했으나, 대신 Claude.md 파일을 활용하여 Claude를 디자이너용으로 커스터마이징하는 방법을 제안받아 직접 구현했다고 설명합니다.
[20:55] 실제 프로덕션 환경에서 발생한 인시던트 경험을 공유하며, 코드 리뷰 과정에서도 가끔 문제가 발생할 수 있음을 인정하고, 이는 개발자라면 누구나 겪는 일반적인 상황이라고 설명합니다.
[21:31] Claude.md 파일의 위치와 Claude Code의 작동 방식에 대해 설명합니다. 글로벌 루트 디렉토리에 위치한 이 파일이 새로운 대화마다 자동으로 컨텍스트에 포함되어 맞춤형 결과를 생성한다고 합니다.
[21:56] 새로운 출력 스타일 기능 개발에 대한 질문에 대해, 자신이 직접적인 역할을 하지 않았으며 이는 마케팅 및 커뮤니케이션 팀의 협업 결과라고 설명합니다. Claude Code의 유연성과 커스터마이징 가능성을 강조하며 마무리합니다.
[22:37] 실제 기능 출시 사례에 대해 논의하기 위해 플로우차트 슬라이드로 돌아가자는 제안. 아이디어 단계부터 출시까지 Claude와 엔지니어들과의 협업 과정에 대한 구체적인 예시를 요청함.
[22:49] 에이전트 기능을 예시로 선택. Claude Code에서 최근 출시한 에이전트는 병렬로 실행 가능한 프로그래밍 가능한 에이전트로, AI 도구가 역할의 유연성을 허용하는 방식을 보여주는 좋은 사례임.
[23:18] 에이전트 기능의 탄생 과정 설명. 엔지니어 Sid가 아이디어를 구상하고 빠르게 프로토타이핑함. Anthropic 전 직원이 Claude Code를 적극적으로 사용하는 도그푸더 문화 강조.
[23:35] Sid가 기능을 개발하여 내부 데모 게시 후 내부 워킹 버전에 출시. 이후 디자이너가 직접 연락하여 디자인 개선사항을 제안하고 협업을 시작하는 자연스러운 과정 묘사.
[23:56] 디자이너, 엔지니어, 추가 디자이너가 함께 빠른 반복 사이클을 통해 기능을 개선하고 팀 프로토타이핑과 피드백을 거쳐 출시 준비를 완료하는 협업 과정.
[24:17] 개발 과정에 대한 질문과 답변. 작은 기능의 경우 별도 스펙이나 디자인 없이 자연스럽게 진행될 수 있음을 확인. 내부 사용자의 직접적인 사용과 피드백이 핵심임을 강조.
[24:43] 출시 준비 완료 시점 판단 기준 설명. 새로운 기능 출시 시 팀원들로부터 많은 피드백을 받다가 시간이 지나면서 피드백이 줄어드는 패턴을 통해 완성도를 판단함.
[24:57] 기능 출시 후 버그와 문제들을 해결하면서 자연스럽게 제품의 일부가 되는 과정을 설명합니다. 애널리틱스와 채택률을 통해 기능이 잘 받아들여지는지 확인하며, 부정적인 피드백이 줄어들면 출시 준비가 되었다고 판단합니다.
[25:16] 앤트로픽은 일찍 출시하고 커뮤니티 피드백을 받는 방식을 택하고 있습니다. 얼리 프리뷰 프로그램이 아닌, 내부 피드백을 충분히 받은 후 바로 커뮤니티에 출시하여 지속적으로 개선해나가는 접근법을 사용합니다.
[25:42] 출시 준비가 되면 커뮤니케이션팀과 마케팅팀이 참여하여 시장에 내놓습니다. 종종 해당 기능을 개발한 엔지니어가 직접 데모 영상을 만들거나 관련 팀과 협력하여 자연스럽게 진행됩니다.
[26:03] 일반적인 회사의 폭포수식 개발 방식과 대비하여 앤트로픽의 유연한 접근법에 대해 토론합니다. 전통적인 방식은 스펙 작성 → 토론 → 디자인 → 엔지니어 전달의 단계적 과정을 거치지만, 앤트로픽은 더 유동적이고 재미있는 방식을 채택하고 있습니다.
[26:29] 팀 내 역할의 유연성과 제품 개선의 신속함에 대해 언급합니다. 최근 출시된 설명/학습 모드도 원래는 팀원이 만든 커스텀 명령에서 시작되어 제품 기능으로 발전한 사례를 소개하며, 여전히 각 분야의 전문가들이 존재한다는 점을 강조합니다.
[27:09] 팀 내에서는 엔지니어들이 새로운 기능을 출시할 때 디자이너들에게 빠른 검토를 요청하며, 디자이너가 기능을 만들 때도 코드 리뷰를 통해 품질을 확인하는 상호 협력적인 방식으로 작업하고 있다.
[27:28] 캣은 진행 중인 모든 기능을 추적하는 마스터 스프레드시트를 관리하고 있으며, 큰 기능들은 전통적인 제품 개발 프로세스를 따르지만 역할 분담은 매우 유동적이다.
[27:54] 팀원들이 각자의 전문성을 유지하면서도 기능을 넘나들며 제품을 위한 최선의 일을 할 수 있는 환경이 최고라고 강조하며, 무작위 아이디어들이 곳곳에서 나타나는 것이 자동화 도구 사용의 제약이 될 수 있다고 설명한다.
[00:28:26] Cloud Code 프로 팁 정리

Shift+Tab 키 바인딩, auto accept/plan 모드 전환, MCP 서버 연결, 이미지 붙여넣기, escape로 작업 취소 등 실제 개발 생산성을 높이는 핵심 단축키와 모드를 공유합니다.

[28:26] 클로드 코드 사용을 위한 프로 팁들을 소개하며, 이러한 팁들은 터미널이나 CLI에 익숙하다는 전제 하에 작동한다고 설명한다.
[28:44] 터미널에 익숙하지 않다면 팀의 엔지니어와 대화하거나 클로드 AI 채팅을 활용해 CLI 사용법을 배울 것을 추천하며, 클로드 코드 특화 키 바인딩과 모범 사례들이 주로 개발자를 위해 설계되었다고 설명한다.
[29:34] 터미널 사용이 익숙하지 않은 디자이너를 위해 Claude Code의 핵심 단축키들을 소개합니다. Shift+Tab으로 자동 수락 모드와 계획 모드를 전환할 수 있으며, 항상 계획 모드로 시작해서 Claude와 함께 변경사항을 파악한 후 자동 수락 모드로 넘어가는 것을 권장합니다.
[29:58] MCP(Model Context Protocol)를 통해 Figma MCP, Playwright MCP 등 다양한 도구에 연결할 수 있습니다. Ctrl+V로 이미지를 붙여넣어 Claude에게 작업 내용을 시각적으로 보여줄 수 있고, Escape로 Claude의 작업을 즉시 중단시킬 수 있습니다.
[30:34] 더블 Escape로 히스토리를 되돌아가 이전 프롬프트를 수정하거나 과거 지시사항을 확인할 수 있습니다. Resume 명령으로 이전 세션에 다시 접근하고, /memory 명령으로 Claude.md 파일을 업데이트할 수 있습니다.
[31:08] 반복적인 작업을 자동화하기 위해 /memory 명령을 자주 활용합니다. 예를 들어 앱 미리보기 자동화를 추가했다가 너무 번거로워서 제거하기도 했으며, 최근에는 Claude가 구현 전에 기존 컴포넌트 라이브러리를 확인하도록 설정해 디자인 시스템 일관성을 유지하고 있습니다.
[31:42] 다른 도구들이 디자인 시스템 지원을 추가하려는 반면, Claude Code는 파일 접근과 이해를 통해 기본적으로 디자인 시스템을 지원하는지에 대한 질문이 제기됩니다.
[31:54] 디자인 시스템 팀이 AI 도구를 염두에 두고 컴포넌트 라이브러리를 설계하면, Claude Code가 문서를 읽고 기능을 구현하기 훨씬 쉬워진다고 설명합니다.
[32:26] Claude Code 개발에서 AI 연구팀과의 협업 방식을 세 가지로 설명합니다. 첫째는 커뮤니티 피드백을 바탕으로 한 전담 개발 팟, 둘째는 연구자들을 돕기 위한 Claude 훈련, 셋째는 상향식 아이디어 개발입니다.
[33:41] Anthropic에서는 모든 새로운 모델을 내부적으로 먼저 테스트하며, 성능이 부족하면 즉시 강한 피드백을 받는다고 설명합니다.
[33:58] 디자인과 PM 역할의 미래에 대한 질문으로, 모든 사람이 각자의 전문성을 가진 빌더가 되어가고 있으며, 코딩 관련 역할들이 점점 더 유동적으로 변화하고 있다고 언급합니다.
[34:20] 디자이너와 PM, 엔지니어 간의 역할 경계가 AI 도구로 인해 더욱 유동적이 되고 있으며, 이는 과거 디자인-PM 유동성과 유사한 현상이라고 설명합니다.
[34:54] 코딩 도구 시대에는 모든 팀원이 코딩 능력을 갖추게 되면서 협업이 증진되지만, 여전히 엔지니어가 최종 의사결정권자와 리뷰어 역할을 담당해야 한다고 강조합니다.
[35:20] 시니어 디자이너들이 매니지먼트 역할보다 빌더 역할을 유지하는 트렌드에 대해 논의하며, Anthropic에서는 빠른 개발 속도로 인해 빌딩의 재미를 느낀다고 언급합니다.
[36:14] AI 네이티브 디자이너가 되고 싶은 초보자에게 claude.ai와 Artifacts부터 시작하여 직접 경험해보라고 조언합니다.
[36:38] Claude.ai와 아티팩트를 먼저 시작해서 코드를 생성하는 모델이 어떤 것인지 이해한 후, Claude Code로 넘어가는 것을 추천합니다. 엔지니어와의 협업이 중요하며, 그들도 디자이너가 코딩을 배우는 것을 환영할 것입니다.
[37:01] React 입문과 Tailwind 입문 수업을 수강했으며, 이는 프론트엔드 작업을 하는 데 라이브러리들의 작동 원리를 이해하는 데 도움이 되었습니다. 필수는 아니지만 구현되는 코드를 이해하는 데 유용합니다.
[37:24] 현재 AI 코딩 커뮤니티는 매우 열려있고 협력적입니다. X, GitHub, 그리고 Anthropic에서 제공하는 바이브 코딩 강좌들이 좋은 학습 자료입니다. 바이브 코딩은 일반 코딩과는 다른 별개의 기술입니다.
[37:51] 가장 중요한 팁은 먼저 계획을 세우는 것입니다. 또한 AI가 뭔가를 만든 후에는 어떻게 했는지 설명해달라고 요청하면 코드가 실제로 무엇을 하는지 배울 수 있습니다.
[38:10] 코드 자체를 이해하는 것이 중요합니다. 이는 미래에 더 복잡한 작업을 가능하게 하고, Claude가 잘못된 방향으로 갈 때 감지하고 수정할 수 있게 해줍니다.
[38:34] X에서 @MEAGHANH_C로 팔로우할 수 있으며, 비기술 인력을 위한 Claude Code 사용 팁과 요령을 공유하고 있습니다. 기술 개발자들도 비기술 동료들이 어떻게 도구를 사용하는지 배우는 데 도움이 됩니다.
[00:38:46] 결론 및 네트워킹 안내

Cloud Code 커뮤니티 활용 방법과, 메이건이 X(구 트위터)에서 제공하는 추가 팁 채널 정보를 안내하며 Q&A로 마무리합니다.

타임라인 정보가 없습니다.

[00:00] 저 같은 경우에는 지금 Claude 코드에서 보내는 시간이
[00:02] Figma에서 보내는 시간과 거의 비슷해요.
[00:03] Figma 목업을 엔지니어에게 전달하는 대신,
[00:06] 제가 작성한 PR 초안을
[00:07] 제가 무엇을 하려고 했는지에 대한
[00:09] 설명과 함께 전달합니다.
[00:11] 그러면 바로 제 눈으로 볼 수 있어요.
[00:13] 아, 이게 제가 디자인한 앱과
[00:14] 정확히 똑같이 보이지 않네요.
[00:16] 이런 작은 디테일들이 많이 있거든요.
[00:18] 그래서 실제로 제가 Claude 코드에서
[00:20] 가장 많은 시간을 보내는 곳이 바로
[00:22] 마지막 10% 완성도 작업이에요.
[00:25] Anthropic에서는 누구나 코딩할 수 있고
[00:27] 정말 협업적인 환경이라서
[00:28] 저희 역할은 중요하지 않다고 느껴요.
[00:29] 또 다른 슬라이드가 있으시네요.
[00:32] 전체 플로우 다이어그램이 있는데
[00:33] 이것도 설명해 주실 수 있나요?
[00:34] 네, 물론이죠.
[00:38] 자, 여러분 환영합니다. 오늘 제 게스트는
[00:40] Claude 코드의 디자인 리드인 Megan입니다.
[00:42] Megan은 기능을 디자인할 뿐만 아니라
[00:44] 정기적으로 프로덕션에 배포도 하고 있어요.
[00:46] AI가 디자이너들이 더 빠르게 작업하는 데
[00:49] 어떻게 도움이 될 수 있는지에 대해 이야기하고
[00:51] 디자인에서 프로토타입까지의 정확한
[00:53] 워크플로우를 데모해 주실 예정이라 정말 기대됩니다.
[00:55] 자, Megan 환영합니다.
[00:57] 정말 감사합니다. 이 자리에 있게 되어서 너무 기쁘고
[00:58] 네, 제가 Claude 코드를 어떻게 사용하는지
[01:00] 이야기할 수 있어서 정말 흥미진진해요.
[01:03] 네. 좋습니다. 그러면 이것부터 시작해 보죠.
[01:05] 정기적으로 프로덕션에 배포하는
[01:07] 디자이너가 되는 것이 어떤 기분인가요?
[01:09] 솔직히 말하면 조금 무섭기도 하고
[01:11] 동시에 정말 마법 같은 느낌이에요.
[01:14] 지난 몇 년 동안 저는
[01:17] 항상 개발에 정말 관심이 있었거든요.
[01:21] 하지만 당시에는, 특히 제가 커리어를 시작했을 때
[01:23] 디자인이든 개발이든
[01:26] 정말 한 쪽 기술을 연마해야 한다는 느낌이었어요.
[01:27] 정말 특별한 유니콘이 아니라면
[01:29] 양쪽 사이의 격차를 메우기가
[01:30] 어려웠거든요.
[01:32] 그런데 지난 5년 정도
[01:33] 코딩이 훨씬 쉬워졌어요.
[01:36] 그리고 제가 항상 엔지니어들에게
[01:37] 요청하기 어려웠던 작은 디테일들,
[01:40] P2가 될 것 같거나
[01:42] 설정하고 수정하는 데 정말 오랜 시간이
[01:44] 걸릴 것 같았던 것들을
[01:46] 이제는 직접 배포할 수 있어요.
[01:48] 그래서 제가 항상 원했던
[01:51] 정말 완성도 높은 제품이
[01:53] 바로 거기 준비되어 있어요.
[01:55] 정말 놀라운 일이죠.
[01:57] 네, 정말 그래요. 저도 엔지니어들에게
[01:58] 미안한 마음이 항상 들거든요.
[02:00] "야, 5가지 다른 카피를 조정해 줄 수 있어?"
[02:01] "이 픽셀 변경이나 뭔가를 해줄 수 있어?" 라고
[02:03] 요청하기가 미안했는데
[02:06] 이제는 직접 할 수 있잖아요, 그렇죠?
[02:07] 맞아요. 정확히 그래요. 그리고 때로는
[02:08] 실제로 디자인을 포팅하거나
[02:10] 머릿속에 있는 아이디어를
[02:12] 프로덕션으로 옮기고 나서
[02:13] 실제로 보면 "아, 이게 내가 생각했던
[02:15] 모습이 아니네"라고 생각하게 돼요.
[02:17] 그러면 다시 바꿔달라고 하거나
[02:18] 또 다시 수정해 달라고 할 때
[02:19] 더 미안한 마음이 들거든요.
[02:21] 이제는 모든 걸 직접 할 수 있는
[02:22] 힘을 얻게 된 거예요.
[02:25] 정말 멋지네요. 정말 멋져요.
[02:26] 그럼 전체 디자인 프로세스와
[02:28] AI와 Claude 코드가 어디서
[02:30] 도움이 될 수 있는지 설명해 주실 수 있나요?
[02:33] 네, 물론이죠. 제게는 실제로 이것과 관련된 슬라이드가 있어서
[02:36] 공유할 수 있습니다. 정말 유용한 자료거든요. 화면을
[02:38] 공유해드릴게요.
[02:40] 네.
[02:41] 네.
[02:42] 현재 제 워크플로우가 바뀐 방법들이
[02:45] 몇 가지 있습니다. 큰 변화 중 하나는
[02:49] 제가 이것을 세 가지 주요 워크플로우로
[02:51] 분류한다는 것입니다. 이제 Claude Code를
[02:53] 특별히 사용하는 워크플로우 말이죠.
[02:56] 첫 번째는 기술적으로 덜 익숙한 분들이
[02:58] 가장 자주 찾는 방법이라고 생각합니다.
[03:00] 그리고 이것은 Claude AI의 아티팩트 기능만으로도
[03:04] 오늘 당장 할 수 있는 것으로,
[03:05] 반드시 코드 도구가 필요하지는 않습니다.
[03:08] 바로 제로에서 원으로의 탐색입니다.
[03:10] 새로운 아이디어를 탐색할 수 있지만,
[03:12] 종종 이것은 독립적으로 이루어지고
[03:14] 반드시 코드베이스 안에 있지는 않습니다.
[03:16] 제로에서 원으로의 탐색의 장점은
[03:18] Claude Code에서 수행한다면
[03:20] 실제로 코드베이스 안에서
[03:21] 작업할 수 있고, 여러분의 코드를 이해하고
[03:23] 어디에 맞는지 알 수 있다는 것입니다.
[03:24] 그래서 단순히 별도의 프로토타입에서
[03:26] 작업하는 것보다 훨씬 실질적입니다.
[03:28] 그리고 제가 현재 가장 자주 사용하는
[03:30] 다른 두 워크플로우는,
[03:33] 음, 세 번째부터 말씀드리자면,
[03:35] 코드베이스를 이해하는 것입니다.
[03:37] 새로운 기능을 개발하거나
[03:40] 새 프로젝트를 작업할 때,
[03:42] 브레인스토밍 전 단계에서 실제로
[03:46] Claude에게 현재 어떻게 작동하는지,
[03:48] 오늘날 어떻게 구현되어 있는지 물어봅니다.
[03:51] 시스템 프롬프트가 무엇인지,
[03:53] 어떻게 구성되어 있는지, 어떻게
[03:54] 아키텍처가 구성되어 있는지까지
[03:57] 사용 사례를 정말 이해하기 위해서요.
[03:59] 때로는 '이것을 어떻게 다르게
[04:01] 설계하겠습니까?'라고 묻기도 합니다.
[04:03] 그리고 Figma에서 디자인을 하는
[04:05] 단계가 있고, 준비가 되면
[04:07] 다시 코드로 돌아가서 마지막
[04:09] 다듬기 작업을 합니다. 엔지니어가
[04:11] 필요한 인프라의 많은 부분을
[04:13] 구축했을 때이거나, 때로는
[04:14] 첫 번째 시도를 직접 해보고
[04:16] Claude Code로 얼마나 멀리 갈 수 있는지
[04:18] 확인해봅니다.
[04:20] 알겠습니다. 코드베이스 이해하기와
[04:22] 코드 구축하기를 더 많이 하시죠?
[04:24] 성숙한 기능 작업 시 말이죠?
[04:25] 맞습니다. 첫 번째 카테고리는
[04:27] 실제로 직장에서는 거의 하지 않습니다.
[04:29] 개인 시간이나 개인 프로젝트에서
[04:31] 하는 것이지만, 디자이너로서
[04:32] 엔지니어링 팀, 제품 팀과 함께
[04:34] 일할 때는 제 시간의 90%를
[04:36] 후자의 두 가지 사용 사례에
[04:38] 할애합니다.
[04:40] 좋습니다. 그리고 다른 슬라이드도
[04:41] 있으시죠. 전체 플로우 다이어그램이
[04:42] 있는 슬라이드 말이에요.
[04:44] 탐색에 관한.
[04:47] 네.
[04:49] 설명해주실 수 있나요? 네, 물론입니다.
[04:51] 이것이 실제로 어떤 느낌인지
[04:54] 조금 더 구체적으로 들어가는
[04:55] 부분이라고 생각합니다. 이것을
[04:57] 일반적인 디자인 프로세스가
[04:59] 어떤 모습인지로 나누었습니다.
[05:01] 탐색과 발견의 더블 다이아몬드,
[05:03] 그다음 디자인, 프로토타입,
[05:05] 그리고 다듬기와 완성 단계죠.
[05:08] 제 생각에 Claude Code를 보는 방식은
[05:11] 많은 사람들이 이것이
[05:13] 정말 개발 용도로만 있다고 생각하죠
[05:15] 아마 여기 4단계와 5단계에서만 쓰인다고 생각하겠지만
[05:17] 제 생각에는 1, 2, 3단계가
[05:19] 실제로는 Claude Code가
[05:21] 비개발자들에게 빛나는 부분이라고 봅니다
[05:23] 많은 기술적 인접 작업들을
[05:26] 할 수 있게 해주거든요
[05:28] 엔지니어링 인접 작업들 말이죠
[05:30] 코드베이스에 접근할 수 있으니까요
[05:31] 실제로 여기 1, 2, 3번은
[05:32] 우리의 매우 기술적인
[05:34] 고객들도 Claude Code에서 하는 일이지만
[05:36] 그들도 자신이 하고 있다는 걸 모를 정도예요
[05:38] 시작하기가 너무 쉽거든요
[05:40] 그리고 그것이 바로 탐색하는 것이죠
[05:42] 이해할 수 있는 다양한 솔루션들을
[05:44] 탐색하고, 어떤 것이 왜
[05:46] 그런 식으로 구현되었는지의 역사를 탐색하고
[05:48] 그리고 계획을 세우고 순서를 정하는 것
[05:50] 다양한 기능을 구축하기 위해 어떻게 나눌지
[05:51] 제가 이것을 Claude Code에서
[05:53] 더 좋아하는 이유는
[05:55] Claude AI보다도요, 물론 둘 사이를 오가긴 하지만
[05:57] 디자이너로서 우리의 역할은
[05:59] 모든 정보와 피드백을 받아서
[06:03] 사용자, 엔지니어,
[06:06] 제품 관리자 등
[06:08] 모든 다른 당사자들로부터의
[06:10] 피드백을 받아서
[06:12] 작동하는 제품 경험으로 번역하는 것입니다
[06:14] 그런데 그 작동하는 제품 경험은
[06:16] 코드로 이루어져 있어요
[06:18] 그래서 어떻게 구현될지를
[06:19] 코드로 빨리 이해할 수록
[06:21] 실제 제품 경험을 더 현실적으로
[06:22] 표현할 수 있습니다
[06:25] 네, 코드가 진실의 소스죠
[06:26] 저는 10년 동안 제품을 만들면서
[06:28] 항상 느꼈던 게
[06:30] 제가 스펙과 PD를 작성하면
[06:31] Figma가 실제로 준비되면
[06:32] 사람들이 더 이상 제 스펙을 보지 않아요
[06:35] Figma가 스펙보다 훨씬 충실하거든요
[06:36] 그리고 결국
[06:38] 실제 코드로 넘어가죠
[06:39] 이 과정을 통해서는
[06:42] 기본적으로 코드로 바로 들어갈 수 있어요
[06:44] 이 과정으로
[06:45] 코드에서 바로 프로토타입을 만들고
[06:46] 코드를 직접 탐색할 수 있죠
[06:48] 코드를 직접
[06:50] 맞습니다
[06:51] 정확히 그래요. 사실 과거에는
[06:53] Figma 목업을 엔지니어에게 넘기는 대신
[06:55] 제가 작성한 초안 PR을 넘기기도 했어요
[06:57] 제가 무엇을 하려고 했는지
[06:59] 설명과 함께요
[07:00] 제가 완료하지 못한 부분이 어딘지도요
[07:02] 결국 많은 것들이
[07:04] 코딩 지식이 많지 않다면
[07:05] 여전히 꽤 어렵거든요
[07:07] 그래서 이것은 정말 좋은
[07:10] 기능 개발의 시작점이 되어줘요
[07:12] 일반적으로보다 프로세스에서 조금 더 앞선
[07:14] 시점에서 시작할 수 있죠
[07:16] 그리고 이제 여러분은
[07:17] 팀의 신뢰받는 구성원이 되었죠
[07:20] 팀에 합류했을 때
[07:22] 엔지니어들이나 사람들로부터
[07:24] GitHub 액세스 권한을 얻고
[07:26] 이런 일들을 시작하게 하려면
[07:28] 어떤 대화를 나누셨나요?
[07:32] Anthropic에서는 누구나 코딩할 수 있고
[07:33] 협업적인 환경이라 사실
[07:35] 우리의 역할은 중요하지 않다고 생각해요. 여기서는
[07:36] 정말 쉬웠어요. 실제로
[07:37] 팀에서 제가 이런 일을 하고 싶어한다는 걸 보고 정말 흥미로워했어요.
[07:39] 많은
[07:41] 디자이너들이 스스로 코딩을 해요. 그래서
[07:44] 클라우드 코드가
[07:45] 직접 통합되기 전에도 많은
[07:47] 디자이너들이 PR을 만들고 스스로
[07:48] 처리하는 걸 볼 수 있었어요.
[07:49] 음, 조금 더 어려운 회사에서는
[07:51] 조금 더 신중하게 접근했는데,
[07:53] 음, 제 과정의 일부는 실제로
[07:56] 엔지니어와 함께 앉아서 하루 종일
[07:58] 페어 프로그래밍을 하는 거예요. 왜냐하면
[08:01] 정말 각각의 레포지토리가
[08:03] 너무 다르게 설정되어 있거든요. 아시겠지만
[08:04] 이거요. 처음 시작했을 때는 좀 덜
[08:05] 익숙했어요. 심지어
[08:07] 프리뷰 앱을 실행시키는 방법이나
[08:08] 모든 의존성들을
[08:10] 설치하고 로컬 개발 환경을
[08:12] 설정하는 것도 새로운 회사에서는 정말 어려웠어요.
[08:14] 그래서 이게 엔지니어링
[08:17] 파트너들과 좋은 협력 관계를 구축하는 데 도움이 되고,
[08:18] 그리고 또한
[08:20] 암묵적인
[08:23] 코드가 어떻게 푸시되는지의 의미론과
[08:25] 회사에서의 배포 시간에 대한 기대치나
[08:27] 프리뷰 빌드 같은
[08:29] 것들을 이해하는 데 도움이 돼요.
[08:30] 그리고 빠른 질문 하나 더 하자면, 여러분들은
[08:32] 디자인 리뷰나 예를 들어
[08:33] Mike에게 발표해야 하는 것 같은 게 있나요? 아니면
[08:35] 그냥 코드를 발표하나요? 어떻게 하시나요?
[08:38] 네.
[08:39] 음, 흥미로운 점이 있어요.
[08:41] 저희는 제품 리뷰도 있고 디자인
[08:43] 크리틱도 있고, 때로는 디자인
[08:45] 딥다이브나 디자인 리뷰도 해요. 다양하게
[08:46] 섞여 있어요. 때로는 Figma
[08:48] 프로토타입을 발표하기도 하고, 때로는
[08:50] 완전히 작동하는 앱을 발표하기도 해요.
[08:51] 때로는 로컬 프리뷰를
[08:54] 발표하기도 해요.
[08:56] 그때그때 어떤 기능인지에 따라 다르죠. 그리고
[08:59] 다른
[09:01] 디자이너들에게도 자주 말하는 건데, 지금 함께 일하는
[09:03] 디자이너들에게요. 음, 코딩의 이런
[09:05] 스킬셋은 많은
[09:07] 비기술직 사람들에게도 사용 가능해요. 음, 여러분은
[09:09] 이것을 여러분의 작업을 발표하는 새로운 방법이나
[09:12] 작업하는 새로운 방법으로
[09:14] 생각해봐야 해요. 그리고 디자인이나 제품의 초기
[09:16] 질문들과 마찬가지로, 이게
[09:18] 로우 피델리티여야 하는지 하이
[09:19] 피델리티여야 하는지 생각해봐야 하는 것처럼
[09:21] 코드를 가능한 한 가장 높은
[09:22] 피델리티로 생각해야 해요. 그리고 드는 노력과
[09:25] 받게 되는 피드백의 종류는
[09:27] 여러분이 보여주는 것에 따라 달라질 거예요.
[09:29] 알겠어요. 알겠습니다. 결국
[09:31] 사용자가 실제로 보고
[09:33] 제품에서 느낄 수 있는 것을 파악하는 것이 중요하죠. 그래서
[09:34] 모든 것에 대한 프로토타입을 만들고
[09:36] 핵심 사용자
[09:38] 경험에 대한 프로토타입을 만드는 거죠. 맞죠?
[09:40] 경험을 위해요. 그런 것 같아요.
[09:42] 음, 여전히 몇 가지
[09:43] 경우에는 개인적으로
[09:45] 프로토타이핑보다는 Figma에서 작업하는 게
[09:47] 더 쉽다고 생각해요. 이건 확실히
[09:49] 제 기술적 능력의 한계일 수도 있어요.
[09:52] 하지만 코드에서 아키텍처상 하기 어려운
[09:53] 더 큰 변경사항들의 경우,
[09:56] 때로는 클라우드에게 물어봐요.
[09:57] 이걸 바꾸는 게 얼마나 어려운지?
[09:59] 피그마에서는 1분이면 되는데
[10:01] 코드로 하면 30분이 걸릴 수 있다면
[10:03] 피그마에서 하는 게 더 말이 되죠.
[10:05] 그래서 여전히
[10:06] 어디서 하는 게 가장 적절한지에 대한
[10:08] 트레이드오프가 있다고 생각해요.
[10:10] 뭘 달성하려고 하느냐에 따라서요.
[10:11] 네, 피그마는 놀랍게도 제 말은
[10:13] 디자이너들이 저를 놀리지만, 그냥
[10:15] 오토 레이아웃 작동시키는 것만 해도
[10:16] 어려워요. 저는 해결할 수가 없어요.
[10:19] 맞아요. 확실히.
[10:19] 피그마도 그렇게 쉽지 않아요.
[10:21] 네, 네. 확실히 파워 유저 도구라고
[10:23] 할 수 있죠.
[10:25] 이 에피소드는
[10:26] Linear의 후원으로 제작됩니다. 솔직히 말해서
[10:29] 대부분의 프로젝트 관리 도구들은 형편없어요.
[10:31] 그래서 저는 Linear로 작업하는 것을 좋아해요.
[10:32] 왜냐하면 저와 같이 장인정신과 품질에
[10:35] 집착하거든요. Linear는 믿을 수 없을 만큼 빠르고
[10:36] 아름답게 디자인되었으며
[10:38] Cursor 같은 AI 에이전트를 위한 내장 지원이
[10:40] 제공됩니다. PM으로서 저는
[10:42] 고객 피드백을 캡처하고, PRD를 작성하고,
[10:44] 개발을 관리하고 조직 전체에서
[10:46] 소통하기 위해 Linear를 사용하는 것을 좋아해요.
[10:49] OpenAI, Vercel, BRS, Cash App의 제품 팀들 모두
[10:52] 번개 같은 속도로 복잡한 제품을 만들기 위해
[10:54] Linear를 사용합니다. linear.app/behindthecraft를
[10:56] 방문해서 직접 확인해보세요. linear.app/behindthecraft입니다.
[11:00] linear.app/behindthecraft입니다.
[11:04] 자, 이제 다시 에피소드로 돌아가겠습니다.
[11:06] 좋아요, 그럼 이제 좀
[11:08] 실제 데모로 이 과정을 살펴보죠.
[11:09] 실제 데모 같은 거 있나요?
[11:11] 작은 데모 앱이라도
[11:12] 보여줄 수 있나요?
[11:13] 네, 물론입니다. 한번 살펴보죠.
[11:15] 안타깝게도 제가 내부적으로 하는
[11:17] 작업은 공유할 수 없지만,
[11:19] Claude Cafe라는
[11:20] 작은 데모 앱을 보여드릴 수 있어요.
[11:23] 여기서 어떻게 생겼는지 목업을 볼 수 있어요.
[11:26] 그리고 지금 이미
[11:29] Claude Code에서 열어서 실행하고 있어요.
[11:33] Claude Cafe 레포지토리에 있고
[11:36] Claude가 열려 있고 실행 중이에요.
[11:39] 제가 가장 먼저 하는 일은 Claude에게
[11:41] 이 앱을 미리보기 도와달라고 요청하는 거예요.
[11:45] 아주 간단하게
[11:46] 엔지니어에게 말하듯이 Claude에게 말하면 돼요.
[11:48] '이걸 로컬에서 실행하는 걸 도와줘'라고 말이죠.
[11:50] 일부 엔지니어들에게는 더 쉬운 일이라고 생각해요.
[11:53] 그들은 '아, 그냥 bash 명령어로
[11:54] 하면 돼'라고 할 거예요. 하지만 저는
[11:56] 설치해야 할 패키지나 앱을 실행하기 위해
[11:57] 필요한 명령어를 항상 알지는 못해요.
[11:58] 그래서 이게 훨씬 쉽다고 느껴요.
[12:00] 최근에 출시한 기능 중에
[12:03] 이걸 가능하게 해주는 기능이 있어요.
[12:04] 제가 몇 달 동안 사용해 왔고
[12:06] 지난달에 처음으로
[12:08] 외부에 제공된 기능인데
[12:09] 백그라운드 bash예요.
[12:11] 여기서 보시면 Control+B를 눌러
[12:12] 백그라운드에서 실행한다고 나와있어요.
[12:15] dev 서버를 실행하는 건 아시겠지만
[12:17] 비기술직 분들은 모를 수도 있어요.
[12:19] 계속 진행되는 프로세스예요.
[12:21] Control+B를 누르면
[12:23] 백그라운드에서 실행되는 걸 볼 수 있고
[12:24] 진행 상황을 계속 업데이트해주지만
[12:26] 여전히 실행 중일 때도
[12:27] Claude와 계속 채팅할 수 있어요.
[12:29] 실행 중이네요. 오, 좋아요. 그럼 기본적으로 두 개의 에이전트가 동시에 작동하는 건가요?
[12:32] 어, 어느 정도는 그렇다고 할 수 있어요.
[12:35] 조금은요.
[12:36] 여기서 보시면
[12:37] 성공적으로 실행되었고
[12:39] 저희는 병렬 에이전트를 실행할 수 있는 기능이 있어요.
[12:40] 이건 백그라운드 bash 명령을 실행할 수 있게 해주는 거예요.
[12:42] 지속적인 명령어 같은 것들 말이죠.
[12:44] 알겠습니다. 좋아요. 로컬호스트를 열어서
[12:46] 어떻게 생겼는지 봐야겠어요
[12:47] 확실히요.
[12:48] 지금 어떻게 생겼는지 볼 수 있어요.
[12:50] 아, 죄송해요. 다른 브라우저에서 열렸는데
[12:52] 여기로 가져올게요.
[12:53] 앱이 이렇게 생겼어요.
[12:55] 프리뷰에서 실행되고 있고 앱이 나와 있어요.
[12:59] 앱이요.
[13:00] 멋지게 생겼네요. 네.
[13:02] 바로 제가 보기에도
[13:04] 제가 디자인한 앱과 정확히 똑같지는 않다는 걸 알 수 있어요.
[13:05] 이미지들이 보시면
[13:07] 제대로 정렬되지 않았고
[13:09] 헤더는 왼쪽 정렬이어야 하는데
[13:11] 이런 세부적인 것들이
[13:13] 구현된 방식을 보면 알 수 있어요.
[13:15] 그리고 제가 바꾸고 싶은 부분들이
[13:17] 있어요.
[13:19] 마지막 10% 정도의 완성도를 위해서요.
[13:20] 음. 그래서 실제로 여기가
[13:23] Claude Code에서 제가 가장 많은 시간을 보내는 곳이에요.
[13:25] 앱이 실행되고 있을 때
[13:32] 몇 가지 다른 방법이 있어요.
[13:34] 이전 비디오에서
[13:36] Figma MCP 서버를 사용하는 것을 언급했어요.
[13:39] 정말 완성도가 높다면 가끔 그걸 사용하지만
[13:40] Claude는 실제로
[13:42] 비전 기능을 가지고 있어요.
[13:44] 그래서 저는 보통 MCP 서버를 사용하는 대신
[13:47] 이걸 PNG로 내보내서
[13:51] 데스크톱에 저장해요.
[13:53] 데스크톱으로 보내겠습니다.
[13:56] 거기 있네요.
[14:06] 그다음에 그걸 드래그 앤 드롭으로
[14:08] Claude에 넣을 거예요
[14:12] 그리고 헤더와 이미지 정렬을 업데이트해 달라고
[14:15] 요청할 거예요
[14:19] 이 목업처럼요.
[14:21] 좋아요. 음
[14:22] 해상도가 조금 낮긴 하지만
[14:24] Figma MCP 서버는 저한테
[14:26] 가끔 항상 로그인되어 있지 않거나
[14:27] 제대로 설정되지 않을 때가 있어요.
[14:29] 그리고 개발 모드 간 전환이
[14:31] 저한테는 개인적으로
[14:34] 이미지를 통해 하는 게 선호하는 방식이에요.
[14:36] 제가 하는 다른 방법은
[14:38] 조금 더 고급 방법인데
[14:40] 기술적 능력의 스펙트럼에서
[14:42] 어디에 위치하느냐에 따라 다르지만
[14:45] 실제로 웹 인스펙트 모드로 들어가서
[14:48] 정렬이나 클래스가 어디에 있는지 보고
[14:50] 그다음에 Claude에게 직접
[14:54] 이 페이지 기능을 보라고 지시하고
[14:56] 그 방식으로 업데이트를 하는 거예요.
[14:59] 이런 워크플로우에 들어갈 수 있는
[15:00] 다양한 방법이 있어요.
[15:02] 그럼 실제로 코드를 여기에 붙여넣어서
[15:04] 살펴보는 거군요.
[15:05] 음 저는 가끔
[15:09] 클래스나 렌더링된 방식을 실제로 보는 걸 좋아하고
[15:11] Claude에게 그 코드 라인을 찾아서
[15:12] 제가 필요하다고 생각하는 것으로 업데이트하라고
[15:14] 말해요.
[15:15] 좋아요.
[15:16] Claude가 이 모든 걸에 접근할 수 있으니까요.
[15:18] 네.
[15:19] 네, 네.
[15:19] 네. 이해됩니다. 네.
[15:20] 음, 이 경우에는 바로 코딩으로
[15:22] 넘어간 것을 보셨겠지만,
[15:24] 사실 이건 제가 평소에 쓰는
[15:26] 워크플로우는 아닙니다. 보통은
[15:28] 먼저 계획 모드로 들어가거든요.
[15:30] 이게 최선의 방법이라고 생각하거든요.
[15:32] 실제로 계획과 접근 방식에 대한
[15:35] 개요를 제공해달라고 요청하고,
[15:40] 또한 음,
[15:43] 이 작업을 이해하기 쉬운
[15:47] 단계와 변경사항으로 나누어달라고 합니다.
[15:51] 마지막 요청은 특히
[15:52] 큰 변경을 시도할 때
[15:54] 자주 추가하는데, Claude는 기본적으로
[15:57] 소프트웨어 엔지니어인 것처럼
[15:58] 말하도록 설계되어 있거든요.
[15:59] 저는 소프트웨어 엔지니어가 아니라서
[16:01] 추가 설명을 자주 요청합니다.
[16:03] 네, 저도 똑같이 해요.
[16:04] 항상 계획을 세우거나
[16:06] 할 일 목록을 만들어서 검토하도록 하죠.
[16:08] 가끔 너무 성급할 때가 있거든요.
[16:10] 여러분.
[16:10] 확실히요. 특히
[16:12] 자동 수락 모드에서는
[16:13] 정말 제 맘대로 시작하거든요.
[16:15] 이것도 코딩을 배우는 입장에서
[16:17] 소프트웨어 아키텍처를
[16:18] 더 잘 이해하는데 도움이 되고,
[16:19] 소프트웨어 엔지니어가
[16:21] 이런 변경사항을 어떻게 생각하는지
[16:22] 알 수 있어서 정말 도움이 됩니다.
[16:24] 그럼 변경사항들이 들어오는 걸 볼 수 있어요.
[16:28] Claude는 당연히 칭찬을 아끼지 않죠.
[16:29] 세련된 새 헤더가 생길 거라고,
[16:31] 정말 멋지다고 하고요.
[16:32] 여기서 계획을 읽어보면
[16:35] 변경사항을 적용할
[16:36] 파일을 나열해주는 걸 볼 수 있어요.
[16:39] 패딩 헤딩을 업데이트하고,
[16:41] 왼쪽으로 이동시키네요.
[16:43] 바로 제가 원했던 거예요.
[16:45] CSS를 실제로 보여주는 게
[16:46] 정말 좋아요. 나중에 어떻게 하는지
[16:48] 알 수 있거든요.
[16:50] 그리고 전반적으로 괜찮아 보이니까
[16:52] 네라고 하고 자동 수락 편집 모드로 가죠.
[16:54] 코드의 모든 라인을
[16:56] 완전히 이해하지 못하더라도
[16:58] 이것도 최고의 친구입니다.
[17:00] 자동 수락 편집 모드는 Claude가
[17:03] 변경사항을 적용하도록 하고
[17:04] 나중에 돌아와서 최종 결과물을
[17:06] 볼 수 있게 해줍니다.
[17:07] 제가 정말 좋아하는 것 중 하나는
[17:09] 변경사항을 실시간으로 보는 거예요.
[17:11] 중간에 가끔 깨지고 다시 렌더링되긴 하지만,
[17:13] 요소들이 움직이는 걸 보는 게 좋아요.
[17:14] 네. 네. 정말 좋죠.
[17:15] 그래서 먼저 로컬호스트를
[17:16] 설정하는 게 중요해요.
[17:17] 뭘 하고 있는지 볼 수 있거든요.
[17:19] 물론이죠. 디자인은
[17:20] 정말 시각적인 작업이라서
[17:22] 모든 걸 함께 보는 게
[17:23] 훨씬 도움이 됩니다.
[17:25] 그런데 이게 진짜예요?
[17:27] 실제로 클로 카페가 있나요?
[17:29] 아니요. 사무실에 카페가 있고
[17:31] 음료를 주문할 수는 있어요.
[17:33] 이런 테마였으면 좋겠지만,
[17:35] 안타깝게도 이건 우리 팀의
[17:36] 디자이너 중 한 명이 데모용으로
[17:37] 만든 앱이에요.
[17:39] 알겠습니다. 저도 프로토타이핑을
[17:42] 많이 해보려고 하는데, AI가
[17:44] 같아요. Tailwind CSS의 그 보라색 배경과
[17:47] 그런 스타일링이요.
[17:49] 어떻게 이런 걸 피할 수 있나요?
[17:50] 정말 엄청 짜증나거든요.
[17:53] 네.
[17:54] 그냥 이미지를 사용하고
[17:55] 더 정확한 지시를 주는 건가요?
[17:57] 네, 맞습니다. 저는 클로드나
[18:00] 다른 AI 모델들을 일반적으로
[18:04] 완전히 새로운 디자인을 만들 때는
[18:06] 기반 없이는 사용하지 않는 편이에요
[18:08] 왜냐하면 정확히 그런 똑같은 스타일링을
[18:10] 얻게 되거든요. 어떤 모델에게든
[18:12] 물어보면 매우 비슷한 스타일링을
[18:14] 줄 거예요. 제가 추천하는
[18:16] 팁들은 첫 번째로, 저는 종종
[18:18] 이미 존재하는 사이트의 일부나
[18:21] 제가 좋아하는 영감을 참조해서
[18:22] 이미지로 첨부하고 말하죠.
[18:23] "이렇게 만들어 줘"라고요.
[18:25] 예를 들어 몇 주 전에
[18:27] 클로드 페이지에 새로운 설정을
[18:30] 추가하고 있었는데, 그냥 설정을
[18:32] 생성해 달라고 하는 대신에
[18:33] "기존 설정 페이지를 보고,
[18:35] 특히 이 설정을 보고
[18:36] 이런 식으로 다시 구현해 줘.
[18:37] 이런 식으로 보이게 하고 싶어"라고 했어요.
[18:40] 또는 때로는 클로드 채팅에서
[18:42] 정말 좋아하는 사이트들의
[18:44] 스크린샷을 올리거나
[18:46] 핀터레스트 보드 스타일처럼
[18:48] 이것과 비슷하게 만들어 달라고 해요.
[18:50] 아. 무드보드 같은 거네요.
[18:52] 무엇을 하는지 이해할 수 있도록요.
[18:53] 네, 맞아요. 알겠습니다.
[18:55] 그리고 이야기해보고 싶은 게
[18:58] 출력에서 저위험, 고위험 같은
[19:00] 내용들을 많이 봤는데요.
[19:04] 클로드 파일을 보여주실 수 있나요?
[19:06] 정말 훌륭한 파일을 가지고 계시는 것 같아요.
[19:07] 물론이죠. 지금 찾아보겠습니다.
[19:10] 이게 제 클로드.md 파일이에요.
[19:12] 이렇게 생겼어요.
[19:13] 네, 정말 훌륭한 파일이네요.
[19:15] 저는 클로드.md를 그냥 init 타이핑하고
[19:17] 코드베이스를 분석하게 했는데,
[19:19] 이건 훨씬 훨씬 낫네요.
[19:21] 이건 진짜로
[19:22] 메건의 클로드.md네요.
[19:25] 왜 이런 것들을 추가했는지
[19:26] 설명해 주실 수 있나요?
[19:29] 네, 물론입니다. 클로드.md는
[19:30] 생태계로서 정말 엄청나게 강력해요.
[19:32] 처음 사용할 때는 완전히
[19:34] 이해하지 못했었는데,
[19:35] 여러 계층적 클로드.md를 가질 수 있도록
[19:38] 많은 업데이트를 했거든요.
[19:40] 그래서 공유 클로드.md가 있는데
[19:42] 이는 클로드가 여러분의
[19:43] 저장소에 대해 접근할 수 있는
[19:45] 공유 지식 같은 거예요.
[19:48] 전체 코드베이스에 대해서 실제로
[19:50] 팀 전체에서 공유되는
[19:52] 많은 클로드.md 파일들이 있고
[19:54] 이들은 저장소에 체크인되어 있어요.
[19:55] 구조 같은 것들과
[19:56] 공유되어 있죠. 이게 보통
[19:58] /init을 사용할 때 얻는 것이에요.
[20:00] 여러분의 코드베이스를 이해하는 거죠.
[20:03] 시간이 지나면서 개인적인
[20:05] 클로드.md 파일도 추가했어요.
[20:07] 이건 제 클로드 실행 인스턴스에만 해당되고
[20:09] 코드베이스와는 관련이 없어요.
[20:11] 실제로는 어떤 저장소에서든
[20:13] 사용자로서 말이에요. 처음에 제가 팀에게
[20:17] 실제로 물어봤던 게 있어요.
[20:19] 혹시 Claude Code의
[20:20] 프로덕트 디자이너 전용 버전을
[20:24] 만들 수 있을지 물어봤거든요.
[20:26] 정말 유용한 도구가 될 것 같아서요.
[20:28] 그런데 그들이 말하길
[20:30] "Claude.md에 추가해보셨나요?
[20:31] Claude는 지시사항을 정말 잘 따라서
[20:33] 그 방법으로도 충분히
[20:35] 원하는 결과를 얻을 수 있을 거라고 생각해요."
[20:37] 그래서 Claude와 함께 작업해서
[20:39] 이 Claude.md 파일을 작성했어요.
[20:41] 몇 번 반복 수정을 거쳐서
[20:44] Claude를 디자이너용으로 만드는
[20:46] 방법에 도달했어요.
[20:48] 네, 그러니까 '나는 디자이너야.
[20:50] 좀 더 자세히 설명해줘'라고 하는 거죠.
[20:52] 그리고 이모지도 좋아해서
[20:53] 위험도가 높은 수정사항이면
[20:55] 표시하도록 했어요.
[20:57] 네, 맞아요. 최근에 실제로
[20:59] 제가 인시던트를 일으킨 적이 있어요.
[21:02] 프로덕션에 코드를 푸시해서 생긴
[21:03] 제 첫 번째 인시던트였는데,
[21:05] 다행히 빠르게 발견되어
[21:06] 해결되었고 여기 모든 분들이
[21:08] 정말 훌륭하세요. 이런 일은
[21:10] 누구에게나 일어난다고 하더라고요.
[21:11] 프로덕션에 코드를 푸시한다면
[21:13] 언젠가는 인시던트를 일으키게 된다고요.
[21:15] 하지만 그 일 이후에 추가한 내용이에요.
[21:17] 그런데 프로덕션에 푸시하는 모든 코드는
[21:19] PR로 올라가잖아요?
[21:19] 엔지니어가 검토해야 하는 건가요?
[21:20] 네, 모든 분들이 여전히 검토하고 있어요.
[21:22] 하지만 가끔씩 뭔가
[21:23] 빠져나가는 경우가 있어요. 모든 사람에게 일어나는 일이죠.
[21:26] 알겠네요. 네, 정말 좋네요.
[21:28] 그런데 이게 프로젝트의
[21:29] 루트 디렉토리에 있는 건가요
[21:31] 아니면 글로벌에 있는 건가요?
[21:33] 제 글로벌 루트 디렉토리에 있어요.
[21:36] 네, 그럼 Claude Code가
[21:37] 어떻게 작동하는지 설명해보면,
[21:39] 새로운 대화를 시작할 때마다
[21:41] 이것을 컨텍스트에 포함시키는 거죠?
[21:43] 정확해요. 그래서 항상
[21:45] 인식하고 있고 이 지침들을
[21:47] 잘 따르게 되어 있어요. Claude를 프롬프팅했거든요.
[21:49] 그래서 제 결과물은 종종
[21:51] 엔지니어들의 결과물과는
[21:52] 매우 다르게 보여요.
[21:54] 훨씬 더 자세하고 상세해요.
[21:56] 그리고 새로운 출력 스타일 기능을
[21:57] 출시하는 데 꽤 큰 역할을 했을 것 같은데
[22:00] 실제로 중요한 역할을 했나요?
[22:01] 아니요,
[22:02] 실제로는 그렇지 않았어요. 그건
[22:06] 시장 진출 팀과 마케팅 팀,
[22:10] 커뮤니케이션 팀의 여러 사람들이
[22:13] 함께 작업한 결과예요.
[22:15] 비기술자 청중에게
[22:18] 더 확대하는 방법을 생각한 거죠.
[22:20] 출시되었을 때 정말 기뻤어요.
[22:21] Claude.md와 함께 사용할 수 있거든요.
[22:24] 제게는 Claude.md만으로도
[22:26] 충분하다고 느꼈고, 이게 바로
[22:28] Claude Code의 아름다운 점 중 하나예요.
[22:29] 정말 유연해요.
[22:30] 매우 커스터마이징이 가능해서
[22:31] 자신만의 것으로 만들 수 있어요.
[22:33] 네, 정확해요. 그런데 혹시
[22:36] 그 슬라이드로 다시 돌아가서
[22:37] 플로우차트가 있는 슬라이드로 다시 돌아가 줄 수 있나요?
[22:39] 실제 사례에 대해 이야기해보고 싶거든요
[22:40] 여러분이 출시한 기능 중에서
[22:42] 말이에요
[22:42] 아이디어 단계부터 출시까지의
[22:44] 전체 과정에 대한 예시를 공유해주실 수 있나요?
[22:46] Claude와 함께 일하는 방식이나
[22:47] 엔지니어들과의 협업 과정 말이에요.
[22:49] 네, 좋은 예시를 생각해보죠
[22:51] 에이전트는 어떨까요?
[22:54] 정말 좋은 예시인 것 같아요.
[22:55] Claude Code에서 최근에 에이전트를 출시했는데
[22:58] 이것들은 프로그래밍 가능한 에이전트로
[23:01] 여러분이... 죄송해요
[23:02] 죄송합니다
[23:03] Claude Code를 병렬로 실행할 수 있게 해줍니다.
[23:09] 이건 실제로 정말 훌륭한 기능이었다고 생각해요
[23:11] AI 도구들이 전반적으로 어떻게
[23:14] 역할의 유연성을 허용하는지 보여주거든요.
[23:15] 에이전트는 원래 우리 팀의
[23:18] 엔지니어 Sid가 아이디어로 구상한 것이었고
[23:20] 그가 아이디어를 빠르게 프로토타이핑하고 있었어요
[23:23] Cat이 자신의 세션에서 언급했을 수도 있지만
[23:26] 여기 Anthropic에서는
[23:28] 모든 사람이 Claude Code를 자주 사용해요
[23:30] 우리는 최고의 도그푸더들이죠
[23:32] 제품을 항상 사용하고
[23:34] 피드백을 제공합니다
[23:35] 그래서 그가 기능을 만들어서
[23:37] 내부적으로 작동하는 데모를 게시했고
[23:40] 그리고 나서 그것을 우리의 내부
[23:42] Claude Code 워킹 버전에 출시했어요
[23:45] 거기서부터 제가 그에게 연락해서
[23:47] '이거 정말 멋진 기능이네요'라고 했죠
[23:48] 사용하기 시작했는데, 제가 추천하고 싶은
[23:50] 디자인 업데이트들이 많이 있었어요
[23:52] 이걸 더 강조해야 한다고 생각했고
[23:53] 병렬 에이전트를 보여줄 수 있는
[23:54] 방법이 있다고 생각했어요
[23:56] 그래서 저와 팀의 다른 디자이너,
[23:58] 그리고 Sid와 함께 몇 차례의
[24:00] 빠른 반복 사이클을 거쳐서
[24:02] 기능을 개선하고 우리가 만족할 수 있는
[24:05] 완성도 수준까지 끌어올렸어요
[24:07] 그리고 괜찮다고 느껴지면
[24:09] 팀과 함께 조금 더 프로토타입을 만들었고
[24:10] 몇몇 다른 사람들이 피드백을 주었고
[24:11] 그것을 사용한 후에
[24:12] 출시할 준비가 되었다고 생각했어요
[24:14] 피드백 사이클의 대부분이
[24:16] 실제로 우리가 직접 사용해보는 것이었어요
[24:17] 와. 좋아요. 기본적으로 Sid가
[24:20] 일주일이나 며칠 정도를
[24:21] 혼자서 프로토타이핑에 보내고
[24:23] 먼저 내부 사용자들에게 출시했다는 거죠?
[24:25] 맞아요. 정확히 그래요.
[24:27] 스펙이나 다른 것들은 없었나요?
[24:29] 디자인이나 다른 것들 말이에요. 그냥 출시했나요?
[24:31] 그런 작은 기능들에 대해서는 아니에요
[24:32] 꽤 자연스럽게
[24:33] 일어날 수 있어요
[24:35] 좋아요. 그러면 여러분이 앞뒤로
[24:36] 소통하면서 더 좋게 만들었고
[24:38] 그러면 언제 출시할 준비가 되었다는 걸
[24:40] 어떻게 알 수 있나요?
[24:42] 내부 사람들이 '이제 내보내자'고
[24:43] 했을 때인가요?
[24:43] 새로운 기능을 처음 출시할 때
[24:45] 팀으로부터 많은 피드백을 받게 돼요
[24:47] 우리 팀원들이 최고의
[24:48] 피드백 소스이자 가장 솔직하거든요
[24:49] 그래서 새로운 프로토타입을 출시하면
[24:52] 처음에는 많은 피드백을 받게 되죠
[24:53] 사람들이 그것을 발견하면서 말이에요
[24:54] 그리고 시간이 지나면서
[24:56] 서서히 줄어들게 돼요
[24:57] 버그와 기능들을 모두 해결했기 때문에
[24:59] 자연스럽게 제품의 일부가 되죠.
[25:01] 우리는 또한 기능들이 얼마나
[25:03] 잘 받아들여지고 있는지 보기 위해
[25:05] 애널리틱스와 채택률을 살펴봅니다.
[25:06] 앤트로픽 내부에서는 '개미들(ants)'이라고
[25:09] 부르는 사람들의 반응을 보죠.
[25:10] 꾸준히 증가하는 것을 보고
[25:13] 부정적인 피드백이 줄어드는 것을 보면
[25:14] 그냥 '이제 됐다'라고 느끼는 순간이 있어요.
[25:16] 저는 또한 우리가 조금 긴장되는 편이라고 생각하는데,
[25:17] 항상 저에게는 조금 떨리는 일이지만
[25:19] 일찍 출시하고
[25:21] 커뮤니티로부터도 피드백을 받는 것이
[25:22] 정말 아름다운 과정이었어요.
[25:24] 지속적으로 업데이트하고
[25:26] 개선할 수 있거든요.
[25:28] 아, 얼리 프리뷰 프로그램 같은 게 있나요?
[25:29] 아니면 뭔가 그런 것 같은...
[25:30] 얼리 프리뷰도 아니에요.
[25:32] 우리는 그냥 일찍 출시해요.
[25:33] 준비가 된 것 같다고 느끼는 지점에서
[25:35] 커뮤니티로부터 더 나은 피드백을
[25:36] 받을 수 있을 때 말이죠.
[25:38] 내부 사람들로부터
[25:40] 받을 수 있는 모든 피드백을 받은 후에요.
[25:42] 그리고 출시 준비가 되면
[25:43] 시장으로 나가는 거죠. 마치 알다시피
[25:45] 커뮤니케이션팀이나 마케팅팀을 참여시키고
[25:48] 포스트를 올리는 것 같은...
[25:49] 정확히 그렇죠.
[25:51] 종종 그 기능을 만든 엔지니어가 직접
[25:54] 자신의 기능에 대한
[25:56] 작은 화면 녹화를 만들거나
[25:58] 개발자 관계팀이나
[25:59] 커뮤니케이션팀과 협력하죠. 하지만
[26:01] 모든 것이 매우 자연스러워요.
[26:03] 그거 정말 좋네요.
[26:04] 일반적인 회사가 이런 것들을 출시하는 방식과는
[26:06] 다르잖아요, 맞죠?
[26:08] 일반적인 회사는 알다시피
[26:09] 폭포수 방식 같은 거죠.
[26:11] 스펙을 작성하고, 내부적으로 토론하고
[26:13] 그다음에 디자인을 만들고
[26:14] 엔지니어들에게 넘기면서
[26:16] '여기 완벽한 디자인 스펙이니까
[26:18] 가서 만들어봐'라고 하는 식이죠.
[26:21] 여러분도 아마 정말 큰 기능들,
[26:22] 기업용이나 뭔가 그런 것들에 대해서는
[26:24] 그런 식으로 할 수도 있겠지만...
[26:25] 하지만 여러분이 하는 방식이
[26:27] 훨씬 더 재미있는 것 같아요.
[26:29] 저도 그렇게 생각해요.
[26:31] 제가 자주 생각해보는 것 중 하나는
[26:34] 팀에서 역할들이 얼마나 유연해졌는지
[26:36] 그리고 얼마나 빨리
[26:38] 제품을 더 좋게 만들고
[26:40] 원하는 제품을 만들 수
[26:41] 있는지예요.
[26:41] 얼마 전에 출시된 설명 모드나
[26:44] 학습 모드 같은 것 말이죠.
[26:45] 그것도 실제로는 커스텀 명령이었어요.
[26:47] 우리는 커스텀 슬래시 명령이 있어서
[26:49] 직접 작업하고 커스터마이즈할 수 있는
[26:51] 기능이 있는데, 팀의 누군가가 그걸 만들어서
[26:53] '이거 다른 사람들에게도 정말 유용할 것 같다'고
[26:55] 말했죠.
[26:56] 그래서 그들이 그 방향으로
[26:57] 작업을 시작했고, 그것이
[26:59] 우리 제품 기능으로 발전했어요.
[27:01] 한 가지 주목할 점은 제가 항상 정말 좋아하는 것인데
[27:03] 우리가 여전히 하는 일이 있어요.
[27:05] 팀에는 여전히 각자 하는 일의 전문가들이 있어요.
[27:07] 그래서 새로운 기능이 나갈 때
[27:08] 엔지니어들이
[27:09] 종종 저나 팀의 다른 디자이너인
[27:11] 네이트에게 연락해서 이렇게 말하죠.
[27:13] 이거 한 번 빠르게 검토해줄 수 있어?
[27:15] 괜찮아 보이는데 우리 시스템과
[27:16] 맞는지 확인하고 싶어서
[27:18] 승인해주면 돼. 보통 우리는 그냥
[27:20] 사용해보곤 해요. 마찬가지로
[27:21] 디자이너가 기능을 만들고 있다면
[27:23] 코드 리뷰를 통해서 모든 게
[27:25] 제대로 작동하는지 확인하죠.
[27:28] 캣이 진행 중인 모든 기능을
[27:29] 추적하는 스프레드시트 같은 걸 가지고 있나요?
[27:31] 아, 네. 네. 진행되고 있는
[27:33] 모든 것의 마스터 스프레드시트가
[27:34] 있어요. 어... 우리는 항상
[27:37] 최신 상태로 유지하려고 노력하고
[27:39] 있고, 조금 더 전통적인 제품
[27:41] 개발 프로세스를 따르는
[27:43] 큰 기능들이 많이 있어요.
[27:46] 하지만 전통적인 프로세스를
[27:48] 따르긴 하지만, 누가 초안을 작성하고
[27:50] 누가 기여하는지의 역할은
[27:51] 우리 팀에서 매우 유동적이에요.
[27:54] 즉,
[27:54] 그게 최고죠. 사람들이 여전히
[27:55] 각자의 전문성은 가지고 있지만
[27:57] 기능을 넘나들며 제품을 위해
[27:58] 최선의 일을 할 수 있어요.
[28:00] 정말 그래요. 어쩌면
[28:01] 여러분은 슬래시 카메라 같은 걸
[28:03] 사용해야 할 것 같은데, 캣이 매일 아침
[28:05] 실행해서 코드베이스를 확인하고
[28:07] 어떤 새로운 기능이 있는지
[28:08] 볼 수 있도록 말이에요.
[28:10] 캣에게는 정말 놀라운 일일 것
[28:12] 같아요. 하지만 잘 작동할지는
[28:15] 확실하지 않아요. 우리는 종종
[28:17] 무작위 아이디어들이 곳곳에서
[28:19] 나타나곤 하거든요.
[28:20] 알겠어요. 그리고 클로드 코드
[28:22] 사용에 대한 프로 팁 슬라이드가
[28:24] 하나 더 있는 것 같은데요.
[28:26] 네, 그렇습니다. 그것도 공유해드릴게요.
[28:28] 프로 팁들이에요. 이것들은 클로드
[28:32] 코드를 위한 제 프로 팁입니다.
[28:36] 시작하는 분들에게 이것들을
[28:38] 추천해요. 한 가지 말씀드리고 싶은 건
[28:40] 이 프로 팁들은 처음에는
[28:41] 터미널이나 CLI에 익숙하다는
[28:44] 전제에 달려있어요. 만약 그렇지
[28:46] 않다면, 제가 가장 추천하는 건
[28:48] 팀의 엔지니어와 대화하는 거예요.
[28:50] 엔지니어라면 누구나 터미널 사용법이나
[28:53] 터미널 명령어가 무엇인지
[28:54] 설명하는 걸 좋아할 거예요.
[28:55] 평생 CLI를 사용해온 사람들도
[28:58] 모든 명령어를 다 알지는
[29:00] 못할 수도 있어요. CLI 사용법을
[29:02] 배우는 또 다른 방법은 클로드 AI
[29:04] 채팅에서 물어보는 거예요.
[29:06] 저는 터미널에서 클로드 코드를
[29:09] 열기 전에 제대로 된 위치에
[29:10] 있는지, 올바른 git 브랜치에
[29:11] 있는지 확인하기 위해 클로디에게
[29:12] 자주 물어봐요. 가끔은 클로드
[29:15] 코드 안에서 클로드 코드에게
[29:17] 도움을 요청하기도 해요.
[29:18] 조금 인셉션 같지만, 일단 거기까지
[29:21] 가면, 이것들이 제가 추천하는
[29:24] 클로드 코드 특화 키 바인딩과
[29:26] 모범 사례들이에요.
[29:28] 이걸 터미널에 익숙해지기라고
[29:31] 부르는 이유는 이것들의 많은 부분이
[29:32] 개발자를 위해 설계되었기 때문이에요.
[29:34] 터미널을 더 많이 사용할수록
[29:35] 더 익숙해질 거예요.
[29:36] 하지만 처음이라면 좀 낯설 수 있어요.
[29:37] 그럼 첫 번째로
[29:39] Shift+Tab으로 자동 수락 모드와
[29:41] 계획 모드 사이를 전환할 수 있어요. 이건 제가 가장 많이 쓰는
[29:44] 모드예요. 무언가를 할 때는 항상 계획
[29:45] 모드로 시작하는 편이에요
[29:47] Claude와 계획을 세우고
[29:48] 어떤 변경사항이 있는지 이해하기 위해서죠.
[29:50] 그리고 자동 수락 모드에서는 Claude가
[29:52] 코드 변경사항을 자율적으로 수락하고
[29:54] 최종 코드 변경이 완료될 때까지 기다렸다가
[29:56] 리뷰하는 방식이에요.
[29:58] MCP는 MCP 서버에 연결할 수 있게 해줘요.
[30:02] Claude가 사용할 수 있는 더 많은 도구에
[30:04] 접근할 수 있게 해주죠. Figma MCP는
[30:06] 많은 디자이너가 사용하는 도구 중 하나예요.
[30:08] 많은 분들이 앱을 미리보기 위해 Playwright MCP도
[30:10] 사용해요. 이것도 정말
[30:12] 도움이 될 수 있어요. 엔지니어링 팀에
[30:14] 어떤 MCP를 설정했는지
[30:15] 문의해보실 수 있어요. 이런 정보는
[30:17] 실제로 공유할 가치가 있다고 생각해요.
[30:19] Ctrl+V로 이미지를 붙여넣기 할 수 있어요. 오늘
[30:22] 어떻게 사용하는지 보여드렸는데, 정말
[30:23] Claude에게 제가 작업하고 있는 것을 보여주기 위해서예요.
[30:25] Escape로 취소하기는 중요한 기능이에요.
[30:28] Claude가 뭔가를 하고 있는데
[30:30] 불안하거나
[30:31] 어디로 가는지 확실하지 않을 때
[30:33] Escape를 눌러서 Claude의 작업을
[30:34] 즉시 중단시킬 수 있어요. 더블 Escape는
[30:36] 히스토리를 되돌아갈 수 있게 해주는데
[30:38] 이것도 정말 좋아해요. 프롬프트를 보냈는데
[30:40] 결과가 마음에 들지 않으면
[30:42] 더블 Escape를 두 번 눌러서
[30:43] 그 프롬프트로 다시 돌아가서
[30:45] 지시사항을 업데이트하거나
[30:47] Claude에게 보낸 과거
[30:48] 지시사항들을 볼 수 있어요.
[30:49] 알겠어요.
[30:50] Resume 명령은
[30:52] 이전 세션에 다시 접근할 수 있게 해줘요.
[30:54] Claude Code 세션을 열었다가
[30:57] 닫고, 다시 그
[30:58] 작업으로 돌아가고 싶을 때 resume을 사용할 수 있어요.
[31:00] 그리고 /memory 명령으로
[31:02] Claude.md 파일을 업데이트할 수 있어요.
[31:04] 마지막 것은 언제 사용하나요?
[31:05] /memory 말이에요. 새로운 팁을
[31:07] 공유하고 싶을 때나
[31:08] 네, 맞아요. Claude와 반복적으로
[31:10] 하는 작업이 있어서 Claude가
[31:13] 자동으로 해주길 원할 때
[31:14] 많이 사용해요.
[31:16] 한동안 시작하기 전에 앱을 미리보기 하거나
[31:18] 변경할 때마다 앱을 미리보기 하도록 추가했는데
[31:20] 너무 번거로워서
[31:22] 결국 제거했어요. 제 워크플로에 맞게
[31:23] Claude를 최적화하기 위해
[31:25] 계속 조정하고 있어요.
[31:27] 가장 최근 메모리 업데이트에서는
[31:30] Claude가 구현 결정을 확정하기 전에
[31:32] 기존 컴포넌트 라이브러리를 살펴보도록 해서
[31:35] 디자인 시스템 모범 사례를
[31:37] 따르도록 했어요.
[31:38] 아, 그렇군요.
[31:40] 알겠어요. 실제로 다른 도구들 중 일부는
[31:42] 디자인 시스템 지원을 추가하려고 하는데
[31:44] Claude Code는
[31:45] 그런 걸 기본적으로
[31:47] 지원하나요? 파일에 접근해서 파일을 이해하는
[31:49] 방식으로요?
[31:52] 파일들을 이해하는
[31:53] 방식으로 말이에요.
[31:54] 이것이 바로 디자인 시스템 역할이
[31:56] 디자인과 엔지니어링을 아름답게
[31:58] 연결하는 지점이라고 생각해요.
[31:59] 그리고 디자인 시스템 팀이 실제로
[32:01] 시스템과 컴포넌트 라이브러리를
[32:04] 코딩 도구나 AI 협업자가 읽을 수 있도록
[32:07] 염두에 두고 설계하기 시작하면,
[32:09] 실제로 Claude Code가 우리 문서를
[32:11] 읽고 기능을 구현하기가 훨씬
[32:13] 쉬워집니다.
[32:15] 특징을 구현하는 게 더 쉬워져요.
[32:16] 그렇군요. 이해됩니다.
[32:17] 좋아요. 그럼 캣에게 깜빡하고
[32:19] 못 물었던 다른 질문들을 해볼게요.
[32:21] 명백히 이런 것들 대부분이
[32:22] 모델의 품질과 모델팀이 하는 일에
[32:24] 달려 있잖아요?
[32:26] 그래서 AI 연구자들과는
[32:27] 어떻게 협업하시나요? 음, 저는
[32:30] Claude Code 관련해서 몇 가지
[32:31] 전담 작업 스트림이 있다고 말하고 싶어요.
[32:34] 우리가 작업하고 싶은 큰 기능들이나
[32:35] 커뮤니티 피드백을 통해 확인한
[32:37] 큰 개선사항들에 대해서요.
[32:38] 이런 것들은 연구팀과 제품팀 내
[32:40] 전담 팟이 있고, 계속해서
[32:41] 반복 개선하는 파트너십이 있습니다.
[32:43] 이것이 하나의 방법이에요.
[32:45] 매우 표준적인 방법으로, 커뮤니티에서
[32:47] 피드백을 받거나 문제를 발견했을 때
[32:48] 모델을 훈련시켜서
[32:49] 더 나아지게 하는 거죠.
[32:51] 두 번째 방법은 우리가 현재
[32:55] 검토하고 있는 것으로, Claude Code가
[32:57] 연구자들을 더 잘 도울 수 있는
[33:00] 방법에 관한 것입니다.
[33:02] 이것이 우리가 정말 밀접하게
[33:03] 파트너십을 맺는 두 번째 방법인데,
[33:04] 소프트웨어 개발 플로우는 매우 광범위합니다.
[33:07] 하지만 우리가 할 수 있다고 생각하는
[33:09] 한 가지는 Claude를 프로덕션 코드뿐만 아니라
[33:11] 연구에도 정말 능숙하도록
[33:13] 훈련시키는 것입니다. 그것이
[33:16] 우리가 가진 또 다른 팟입니다.
[33:18] 세 번째는 Anthropic에서는 프로세스
[33:20] 관점에서 매우 상향식으로 운영됩니다.
[33:21] 때로는 제품팀에서, 때로는 연구팀과
[33:22] 함께 누군가가 Claude가 하기를
[33:24] 원하는 아이디어를 가지게 되면,
[33:25] 새로운 것을 함께 작업하는
[33:27] 미니 팟을 시작합니다.
[33:29] 완전히 새로운 것을 말이죠.
[33:31] 훌륭하네요. 정말 재미있겠어요.
[33:33] 알겠습니다. 그리고 아마도
[33:36] 모든 초기 모델들에 접근할 수 있고
[33:37] 그런 것들에 접근할 수 있을 거예요. 네, 맞습니다.
[33:41] 우리는 확실히 모든 모델들을
[33:42] 내부적으로 먼저 직접 테스트해보고,
[33:46] 모델이 제대로 성능을 발휘하지
[33:48] 않으면 즉시 강한 피드백을
[33:49] 받게 됩니다. 왜냐하면 사람들이
[33:52] 다른 걸로 바꿔버리거든요.
[33:53] 알겠습니다. 좋아요. 미건, 이것 정말 멋져요.
[33:56] 그럼, 디자인과 PM 역할이
[33:58] 어떻게 진화할 거라고 생각하시나요?
[34:00] 아니면 이미 진화하고 있을까요?
[34:02] 제 생각에는 모든 사람이 그냥
[34:04] 각자의 전문성을 가진 빌더가
[34:05] 되어가는 것 같은데요.
[34:08] 아니면...
[34:09] 네, 정말 좋은 질문이네요.
[34:11] 느낌상으로는
[34:13] 기술 전반에 걸쳐, 특히
[34:16] 코딩과 관련된 역할에 있다면,
[34:18] 실제로 점점 더 유동적으로
[34:20] 우리의 역할이 더욱 유연해지고 있다는 걸 말하는 거예요.
[34:22] 역사적으로 저는 디자인-PM의 유동성에 대해 많이 얘기했어요.
[34:27] 프로덕트 매니저가 디자인 지향적이거나 디자이너가 프로덕트 지향적이냐에 따라서요.
[34:31] 시니어가 되거나 작은 팀에서 일하다 보면
[34:35] 책임의 경계가 정말 유동적으로 변하는 걸 보게 됩니다.
[34:39] EM과도 마찬가지로 프로덕트 전략이나
[34:42] 그런 것들을 누가 담당하는지가 조금씩 유동적이 되죠.
[34:45] 그건 프로덕트 마인드를 갖춘 스킬셋이
[34:48] 시간이 지나면서 발전했지만 프로덕트 매니저가 여전히
[34:51] 그 분야의 전문가이자 의사결정권자였기 때문이에요.
[34:54] 코딩 도구들에 관해서도 비슷하게 생각해요.
[34:57] 이제 우리 모두가 코딩할 수 있는 스킬과 능력을 갖추게 됐으니까요.
[35:00] 그래서 책임이 조금 더 유동적이 되었고, 서로의 역할에
[35:04] 기여하며 훨씬 더 많이 협업할 수 있게 됐어요.
[35:08] 하지만 최종 의사결정권자는 여전히 엔지니어여야 하고
[35:10] 리뷰어도 엔지니어여야 해요.
[35:11] 그래서 역할의 유동성과 스킬셋의 확장이라고 할 수 있어요.
[35:16] 이제 우리 툴킷에 코드라는 새로운 도구가 하나 더 생긴 거죠.
[35:20] 네. 그리고 최근에 좋은 트렌드 중 하나는
[35:22] 미간씨 같은 시니어 디자이너들이 빌더 역할을 계속 유지하기로 선택한다는 거예요.
[35:26] 예전에는 매니저가 되거나
[35:29] 매니지먼트 업무를 해야만 했잖아요.
[35:33] 하지만 이제는 프로덕트와 크래프트를 중시하는 사람들이
[35:36] 더 가치있게 여겨지는 것 같아요. 제가 편견이 있나 모르겠지만요.
[35:44] 그런 변화를 느끼시나요? 개인적으로는
[35:47] 잘 모르겠어요. 하지만 충분히 믿을 만해요.
[35:50] 저 같은 경우는 이제 클로드 코드에서 보내는 시간이 Figma에서만큼이나 많아요.
[35:55] Anthropic 동료들과도 가끔 이야기하는데
[35:57] 여기서 빌딩하는 게 정말 재밌거든요. 너무 빠르게 만들 수 있어서
[36:03] 빌더가 되지 않을 수가 없어요.
[36:06] Anthropic의 매니저들도 직접 빌딩을 하고 있어요.
[36:09] 매니저 역할도 이런 도구들에 훨씬 빠르게
[36:12] 접근할 수 있어서 더 많은 기회를 갖게 됐어요.
[36:14] 그렇다면 제가 디자이너이고
[36:17] 미간씨처럼 AI 네이티브 디자이너가 되고 싶거나
[36:19] Anthropic에서 일하고 싶다면
[36:22] 어떻게 준비해야 할까요?
[36:26] 코딩이 완전히 처음이고 시작하고 싶다면
[36:31] 솔직히 그냥 시작하라고 권하고 싶어요.
[36:34] 모르는 걸 아는 것은 어렵거든요. claude.ai와
[36:37] Artifacts부터 시작하면 실제로
[36:38] 코드를 생성하는 모델이 어떤 느낌인지
[36:40] 잘 이해할 수 있을 것입니다.
[36:42] 음, 거기서 시작해서
[36:44] 직접 Claude Code로 넘어가는 걸 추천합니다.
[36:46] 정말 훌륭한 파트너십이죠.
[36:48] 엔지니어 파트너가 있다면
[36:49] 실제로 저희와 협업할 수 있어요.
[36:51] 엔지니어 파트너들은
[36:52] 당신이 코딩하고 싶어한다는 걸 기뻐할 거예요.
[36:54] 그들이 더 빨라질 수 있거든요.
[36:56] 당신도 훨씬 많이 배우게 될 거예요.
[36:57] 그런 파트너십과
[36:59] 교량을 구축할 수 있는 좋은 순간이라고 생각해요.
[37:01] 제가 한 몇 가지는
[37:03] React 입문과 Tailwind 입문 수업을 들었어요.
[37:05] 제가 하는 대부분의 변경사항은
[37:07] 프론트엔드이고, 이것들이 도움이 되었어요.
[37:09] 이런 라이브러리들이 어떻게 작동하고
[37:11] 어떻게 직접 렌더링되는지에 대한
[37:12] 이해를 조금 더 깊게 해주었거든요.
[37:15] 필수는 아니지만
[37:16] 구현되는 코드를
[37:18] 이해하는 데 도움이 된다고 생각해요.
[37:21] 그리고 실제 바이브 코딩과
[37:22] 실제 AI 쪽으로 들어가려면
[37:24] 지금 커뮤니티가 매우 열려있고 협력적이라고 말하고 싶어요.
[37:27] 우리는 새로운 기술의
[37:28] 좋은 시점에 있어요.
[37:30] 사람들이 그냥 흥미로워하고
[37:32] 자신들이 하는 일을 공유하고 있거든요.
[37:35] X는 정말 좋은 곳이에요.
[37:37] GitHub도 배우기에
[37:39] 정말 좋은 곳이라고 말하고 싶어요.
[37:40] 실제로 Anthropic에서 제공하는
[37:42] 몇 가지 강좌가 있어요.
[37:44] 바이브 코딩 방법을 가르쳐주는 강좌들이죠.
[37:46] 정말 훌륭해요.
[37:48] 바이브 코딩을 배우는 데 약간의 스킬이 필요하거든요.
[37:50] 그냥 코딩과는 다른 별개의 것이에요.
[37:51] 네, 그렇죠. 사람들에게 주는
[37:53] 1번 팁은
[37:55] 먼저 계획을 세우는 것이에요.
[37:57] 맞습니다.
[37:58] 그리고 제가 가진 다른 팁은
[38:00] 자주 하지는 않지만
[38:02] 뭔가를 만든 후에
[38:04] 어떻게 했는지 설명해달라고 요청하는 거예요.
[38:06] 그러면 실제로
[38:08] 코드가 실제로 뭘 하는지
[38:09] 배울 수 있거든요.
[38:10] 맞습니다, 맞습니다.
[38:12] 코드 자체에 들어가는 것이 정말정말 도움이 된다고 생각해요.
[38:15] 미래에 더 복잡한 일들도 할 수 있게 해주고
[38:17] Claude가 틀렸을 때
[38:18] 감지할 수 있어요.
[38:20] 때때로 Claude가
[38:21] 방향 수정이 필요한
[38:23] 방향으로 가기도 하거든요.
[38:25] 네, 네. '완전히 맞습니다'라고
[38:26] 말하기 시작하면 뭔가 잘못되고 있는 거죠.
[38:28] 네, 맞습니다. 좋아요.
[38:31] 좋아요. 미간, 사람들이
[38:32] 당신을 어디서 찾을 수 있나요?
[38:34] 또는 더 배울 수 있는 곳은요?
[38:34] 네, X에서 저를 팔로우하실 수 있어요.
[38:38] 제 핸들이 좀 복잡한데
[38:40] 제 이름 철자가
[38:41] 복잡하거든요. M-E-A-G-H-A-N-H_C입니다.
[38:46] 종종 비기술 인력을 위한
[38:49] Claude Code 사용법에 대한 팁과 요령을
[38:51] 공유하고 있어요.
[38:53] 곧 출시될 기능들과
[38:55] 제가 그것들을 사용하는 방법을
[38:57] 기술 개발자들을 직접
[38:59] 대상으로 하지 않는 방식으로 공유해요.
[39:01] 또한 개발자들이
[39:02] 거기서 배우는 것이 도움이 된다는
[39:04] 피드백을 받았어요.
[39:06] 비기술 동료들이
[39:08] Claude Code를 어떻게 사용하는지
[39:10] 볼 수 있거든요.
[39:12] 네, 당신의 게시물들을 정말 좋아해요.
[39:14] 정말 실용적이고, 제가 올렸던 내용인데
[39:16] Claude Code는 정말 좋은
[39:18] 에이전트 같아요.
[39:19] 지금은 코딩에 가장 많이 사용되지만
[39:21] 디자인, 제품 작업에도
[39:22] 사용할 수 있어요. 맞습니다.
[39:24] 맞습니다, 맞습니다.
[39:26] 네, 좋아요. 계속 작업하세요.
[39:27] 계속 작업하세요. 저는 파워 유저예요. 좋아요, 미간.