디자이너도 Claude Code로 직접 만든다 — '누구나 만드는 시대'의 진짜 관문

Claude Code 리드 디자이너가 자기 손으로 기능을 붙이는 워크플로우를 공개했다. 디자이너가, 개발자 없이, 코드를 짜서 제품에 기능을 넣는다. 그런데 이 영상에서 내가 받은 메시지는 "이제 누구나 다 만들 수 있다"가 아니었다. 진짜 변화는 다른 곳에 있다.

오늘 나는 비개발자들을 대상으로 AI 활용 입문 강의를 한다. 그래서 이 영상이 더 와닿았다. "디자이너도 만든다"는 장면은 강의에서 내가 하려는 말과 정확히 겹치는데, 동시에 강의에서 꼭 짚어야 할 함정도 같이 보여줬다.

디자이너가 코드를 짠다는 것

영상의 주인공은 Meaghan Choi, Anthropic에서 Claude Code와 Cowork의 디자인을 총괄(Head of Design)하는 사람이다. 그는 Claude Code를 "사용"만 하지 않는다. 실제 제품 코드베이스 안에서 직접 기능을 만든다. 본인 말로 "이제 Figma만큼 Claude Code에 시간을 쓴다. 엔지니어에게 목업 대신 초안 PR을 넘긴다"고 한다. 디자이너가 화면 시안만 그려서 넘기던 방식에서, 작동하는 코드 초안을 같이 넘기는 방식으로 일하는 단위 자체가 바뀐 셈이다.

이번 시연에서는 그림 도구 Excalidraw에 자동완성 기능을 직접 붙였다. 아이디어를 탐색하고, 구현안을 여러 개 비교하고, 검증하고, PR을 만들고, 리뷰하고, 머지하는 전체 사이클을 터미널에서 돌린다. 디자이너가 기획만 넘기고 기다리는 게 아니라, 작동하는 결과물까지 직접 끌고 간다.

그가 꼽은 디자이너의 Claude Code 활용처는 세 가지다. 첫째 0에서 1을 만드는 탐색, 둘째 기존 제품에 새 기능을 붙이는 프로토타이핑, 셋째 코드베이스를 이해하는 것. 셋 다 "디자인 결과를 코드로 옮기는" 일이라기보다 "코드를 디자인의 재료로 쓰는" 쪽에 가깝다. 손으로 만질 수 있는 진짜 프로토타입으로 검증하니, 시안으로는 안 보이던 문제가 일찍 드러난다.

여기서 디자이너들이 가장 안심할 만한 말이 나온다. Claude Code를 잘 쓰는 디자이너들은 입을 모아 "엔지니어처럼 생각할 필요가 없다"고 한다. 필요한 건 원하는 것을 명확하게 설명하는 능력인데, 그건 디자이너가 이미 매일 훈련하는 일이다. 코드 문법보다 "무엇을, 왜, 어떤 느낌으로"를 또렷하게 전달하는 쪽이 결과를 더 좌우한다.

도구 구성도 참고할 만하다. worktree로 작업 공간을 분리하고, Opus의 100만 토큰 컨텍스트와 빠른 모드를 써서 여러 Claude 세션을 동시에 띄우되 서로 충돌하지 않게 한다. PR 머지, 코드 리뷰, CSS 다듬기처럼 반복적인 일은 Claude에게 위임한다. 한 가지 전제는 있다. 디자인 시스템을 코드베이스와 맞춰두는 것이다. Figma의 색·타이포·간격·컴포넌트가 코드에서도 같은 의미를 갖도록 정렬해두면, 에이전트가 만든 결과가 디자인 의도에서 덜 벗어난다.

여기까지만 보면 결론은 단순해 보인다. "이제 직군 경계가 무너졌다. 누구나 만든다." 맞는 말이지만, 절반만 맞다.

핵심은 '만든다'가 아니라 '거른다'

영상에서 가장 오래 곱씹은 문장은 이거였다. "누구나 만들 수 있다고 해서 모든 것을 배포해야 하는 것은 아니다."

만드는 능력이 민주화됐다고 품질까지 민주화된 건 아니다. 그래서 그는 자동화된 검증, 리뷰, 기능 플래그 시스템을 따로 구축해 둔다. 만드는 문턱이 낮아진 만큼, 만든 것을 거르는 장치를 더 단단하게 세운다. LLM은 아직 디자인 자체에는 약하다는 전제를 깔고, 사람은 완성도와 선택을 책임지고 Claude는 여러 안을 빠르게 생성하는 보조에 둔다.

이 지점이 어제 정리한 에이전틱 코드 리뷰 흐름과 정확히 같은 결이다. 코딩 에이전트 성능이 올라갈수록 엔지니어링의 어려운 지점은 "코드를 짜는 것"에서 "이 코드를 신뢰하고 내보내도 되는지 판단하는 것"으로 옮겨간다. 만드는 단계가 싸지면, 거르는 단계가 비싸진다.

내가 실제로 써보니

나는 회사 백엔드 작업에 worktree와 멀티 세션, 100만 토큰 컨텍스트를 매일 쓴다. 여러 작업을 동시에 다른 세션에서 굴리고, 코드 리뷰는 별도 에이전트에게 맡긴다. 직접 짠 AI 도구 스택으로 SDD 방식 워크플로우를 돌리고, 야간에는 에이전트가 스스로 과거 작업을 복기해 개선안을 만들게 한다.

그런데 도구를 깊게 쓸수록 분명해진 게 있다. 코드를 뽑아내는 속도는 이미 충분히 빠르다. 진짜 일은 "이 변경을 dev에 올려도 되는지, prod까지 보내도 되는지" 거르는 판단이다. 만드는 양이 늘수록 거르는 부담이 같이 늘어서, 검증 시스템을 안 갖추면 오히려 더 위험해진다. AI에 일을 많이 맡기는 게 약점이 아니라, 맡긴 결과를 거르는 눈을 같이 키우는 게 실력이다.

비개발자 강의를 준비하며

오늘 나는 이 영상을 강의 사례로 쓸 생각이다. 청중 대부분은 코드를 한 줄도 안 짜본 사람들이다. 그들에게 "디자이너도 직접 만든다"는 장면은 용기를 준다. 나도 처음엔 그 용기로 시작했다. 그런데 강의에서 꼭 한 가지를 덧붙이려 한다. 만드는 건 시작일 뿐이고, 만든 것을 어떻게 거를지가 진짜 실력이라고. 도구가 좋아질수록 이 말은 더 중요해진다. AI가 다 해주는 것처럼 보여도, 무엇을 남기고 무엇을 버릴지는 끝까지 사람이 정한다. 그래서 입문자에게 필요한 건 "어떻게 만드나"보다 "이게 쓸 만한가"를 스스로 물어보는 습관이다.

만드는 도구를 빨리 익히는 사람은 많아질 거다. 하지만 만든 것을 솔직하게 평가하고 버릴 줄 아는 사람은 여전히 드물다. 그 차이가 다음 일 년의 격차를 만든다고 본다.

무엇이 바뀌고 무엇이 안 바뀌었나

구분	AI 이전	지금
만드는 주체	개발자만	디자이너·기획자도 직접
진짜 병목	구현 속도	검증·신뢰 판단
사람의 역할	코드 작성	완성도·선택·품질 게이트
경쟁력	빨리 만드는 능력	무엇을 내보낼지 거르는 능력

디자이너·비개발자를 위한 첫걸음 가이드

말로만 "해봐라"는 공허하니, 디자이너가 Claude Code로 첫 기능을 만드는 순서를 정리한다.

1. 빈 폴더에서 시작한다. 만들 작업물의 폴더를 하나 만들고 거기서 Claude Code를 켠다. 비어 있어도 괜찮다. "어디서 시작하느냐"가 첫 단추다.

2. 코드 용어 말고 '결과'로 설명한다. "REST API 만들어줘"가 아니라 "버튼을 누르면 할 일이 아래 목록에 쌓이는 웹페이지, 색은 파스텔톤으로"처럼. 디자이너가 매일 하는 그 설명 그대로다.

3. 반드시 실행해서 눈으로 본다. 코드가 생기면 끝이 아니다. "이거 어떻게 띄워서 보는지 알려줘"라고 물어 화면에 직접 띄운다. 눈으로 봐야 진짜 완성이다.

4. 작게, 하나씩 고친다. "전체 다 바꿔줘"보다 "이 버튼만 더 크게"가 낫다. 보고 피드백하는 디자이너의 강점이 그대로 통한다.

5. 마음에 들면 저장한다. "지금까지 한 거 저장해줘"라고 하면, 나중에 망가져도 그 시점으로 되돌릴 수 있다.

디자이너가 자주 밟는 지뢰도 셋이다. 첫째 한 번에 너무 많이 시키기. 화면 하나, 기능 하나씩 쌓아 올려야 결과가 산으로 안 간다. 둘째 실행 확인 없이 다음으로 넘어가기. 코드가 나왔다고 동작하는 게 아니라서, 매번 띄워보고 확인한 뒤 다음을 요청해야 오류가 눈덩이처럼 쌓이지 않는다. 셋째 안 될 때 화면만 캡처해 "안 돼요" 하기. 빨간 에러 메시지를 그대로 복사해 붙여넣는 게 가장 빠른 해결이다.

그리고 거르는 단계. 만든 것을 내보내기 전에 이 다섯 개를 점검하면 사고를 크게 줄인다.

점검 항목	통과 기준
핵심 시나리오	처음부터 끝까지 내가 직접 해봤다
오류 상황	일부러 잘못 눌러도 앱이 죽지 않고 안내가 뜬다
보안	비밀키가 코드나 깃허브에 노출되지 않았다
빌드	에러 없이 통과한다
되돌리기	잘 되는 상태로 저장돼 있어 문제 시 복구된다

하나라도 아니면 배포 보류가 정답이다. 검증이 부담스럽다면, 새 세션에 "리뷰어 역할"을 주고 방금 만든 것을 비판적으로 봐달라고 시키는 방법도 있다. 자기가 짠 것을 자기가 칭찬하는 편향을 줄여준다.

한 줄로 줄이면 이렇다. AI는 실력 좋지만 자신만만한 인턴이다. 명확히 지시하고, 작게 쪼개 맡기고, 결과를 항상 검수한다. 디자이너의 기획력과 "이거 좀 이상한데" 하는 디테일 감각이 오히려 최고의 무기다.

개발자라면 방향이 하나 더 있다. 검증과 리뷰와 기능 플래그를 머릿속이 아니라 시스템으로 옮기는 것이다. 만드는 사람이 늘어날수록, 거르는 장치가 팀의 진짜 자산이 된다.

내 결론

"누구나 만든다"는 진입 장벽에 대한 이야기다. 그건 이미 낮아졌고, 더 낮아질 거다. 하지만 그게 끝이 아니라 시작이다. 진짜 관문은 "무엇을 배포할지 거르는 판단"으로 넘어갔다. 만드는 법을 배우는 것보다, 거르는 법을 갖추는 쪽이 앞으로 더 귀해진다. 오늘 강의에서도 이 한 줄을 꼭 남기려 한다. 도구는 만드는 문턱을 낮춰줄 뿐, 무엇을 내보낼지는 끝까지 사람의 몫이다.

자주 묻는 질문

Q. 비개발자도 Claude Code로 앱을 만들 수 있나?

간단한 기능이나 작은 도구 수준은 충분히 가능하다. 디자이너가 그림 도구에 자동완성을 붙이는 시연이 그 증거다. 다만 만든 것을 검증하고 내보낼지 판단하는 단계는 여전히 사람이 책임져야 한다.

Q. worktree가 뭔가?

하나의 코드 저장소를 여러 작업 공간으로 분리하는 방식이다. 여러 작업을 동시에 진행해도 서로 섞이지 않게 해줘서, 여러 AI 세션을 병렬로 돌릴 때 유용하다.

Q. 디자이너가 코딩하면 개발자는 필요 없어지나?

역할이 옮겨갈 뿐이다. 만드는 일이 쉬워질수록 검증, 구조 설계, 품질 게이트처럼 거르는 일의 가치가 올라간다. 개발자의 무게중심이 작성에서 판단으로 이동한다고 보는 게 맞다.

Q. 어디서부터 시작하면 되나?

거창한 프로젝트 말고, 평소 반복하는 작은 일 하나를 AI에게 맡겨보는 것부터 시작하면 된다. 만들어보고, 그 결과를 직접 거르는 경험을 쌓는 게 첫걸음이다.

Q. AI가 만든 코드를 믿어도 되나?

무조건 믿는 것도, 무조건 의심하는 것도 답이 아니다. 검증과 리뷰를 시스템으로 만들어두고, 그 시스템을 통과한 것만 내보내는 습관을 들이는 게 현실적인 답이다.