figma로 직접 디자인하는 일을 7일간 그만두기

*원문을 번역한 글입니다.

*원문은 발행 이후 수정될 수 있으며, 본 번역은 발송 시점 기준으로 작성되었습니다.

UI 작업 과정의 대부분을 Claude Code와 Claude Design으로 대체했습니다. 손으로 그린 와이어프레임과일상적인 표현으로 작성한 지시 사항, 프롬프트, AI가 생성한 레이아웃을 사용했습니다. 무엇이 효과적이었고 무엇이 그렇지 않았는지, 그리고 제 디자인 방식이 어떻게 달라졌는지 소개합니다.

Figma를 열었습니다.

그리고 곧바로 닫았습니다.

디자인을 그만둔 것은 아닙니다. 그저 직접 그리는 일을 멈췄을 뿐입니다.

일주일 동안 화면을 Figma에서 직접 만드는 익숙한 작업 방식을 제 디자인 프로세스에서 제외했습니다. 대신 그 일을 Claude에게 맡겼습니다.

어떤 때는 손으로 그린 와이어프레임을 Claude에게 전달했습니다. 어떤 때는 원하는 인터페이스를 평범한 말로 설명했습니다. 한 번은 원하는 결과만 이야기하고, 구조는 Claude가 직접 결정하게 두기도 했습니다.

제 역할은 픽셀을 직접 움직이는 디자이너에서 고집 센 디자인 파트너를 지휘하는 디자이너로 바뀌었습니다. 작업이 진행될수록 픽셀을 직접 조정하는 일의 중요성은 줄어들고, 방향을 제시하는 일이 가장 중요해졌습니다.

제가 확인하고 싶었던 것은 한 가지였습니다.

디자이너가 직접 디자인하지 않고도 정말 디자인할 수 있을까요?

엄청나게 많이 열려 있던 Figma 탭을 모두 닫았습니다. 이제 Claude에게 맡겨 볼 시간입니다.

실험

제가 이 실험을 한 이유부터 솔직하게 말씀드리겠습니다. “AI가 미래이기 때문”은 아니었습니다.

그보다는 조금 짜증 나는 사실을 깨달았기 때문입니다. 디자인에 쓰는 시간 중 상당 부분은 의사 결정을 내리는 데 사용되지 않았습니다. 이미 내린 결정을 컴퓨터가 이해하도록 만드는 데 쓰이고 있었습니다.

저는 정보의 위계를 알고 있었습니다. 무엇이 핵심 행동인지도 알았습니다. 이상적인 정상 흐름보다 빈 상태가 더 중요하다는 것도 알고 있었습니다.

그런데도 오토 레이아웃을 설정하고, 간격을 4픽셀씩 옮기고, 레이어 이름을 바꾸고, 올해 들어 서로 다른 세 개의 파일에서 이미 세 번이나 만들었던 카드 컴포넌트를 다시 만드는 데 40분을 쓰곤 했습니다.

그래서 실험을 진행했습니다. 7일 동안 Figma에서 인터페이스를 직접 만들지 않기로 했습니다. Claude Code와 Claude Design이 첫 번째 구현을 담당하고, 저는 방향을 제시하기로 했습니다.

이 실험을 흥미롭게 만든 것은 바로 제약 조건이었습니다.

규칙

Figma에서 화면을 처음부터 직접 만들지 않습니다.

인터페이스의 첫 번째 구현은 Claude가 담당합니다.

저는 스케치, 스크린샷, 참고 자료, 프롬프트, UX 설명 또는 일상적인 표현으로 작성한 지시 사항을 제공할 수 있습니다.

원하는 만큼 비평하고 반복해서 수정할 수 있습니다.

목표는 “AI가 모든 디자인을 하게 하는 것”이 아닙니다.

목표는 디자이너가 창작자에서 디렉터로 역할을 바꾸면 어떤 일이 일어나는지 확인하는 것입니다.

마지막 문장이 결국 그 일주일 전체를 설명하는 말이 되었습니다.

이전 작업 방식과 새로운 작업 방식

작업 과정 비교표.

두 작업 방식을 나란히 비교해 보면, 새로운 과정이 더 짧다는 사실을 바로 알 수 있습니다. 하지만 그것이 가장 흥미로운 부분은 아닙니다.

흥미로웠던 것은 병목 지점이 이동했다는 점입니다. 생각하는 시간이 줄어든 것이 아니라, 생각을 픽셀로 옮기는 데 쓰는 시간이 줄었습니다.

Claude와 실제로 소통한 방법

저는 대략 다음 네 가지 방법을 차례로 발견했습니다. 모든 방법이 똑같이 효과적이지는 않았으며, 그 순서도 예상보다 중요했습니다.

방법 1 — 손으로 그린 와이어프레임

처음에는 이 방법이 실패할 것이라고 생각했습니다.

종이에 30초 만에 레이아웃을 그렸습니다. 상자와 화살표를 그리고, ‘필터 바’를 표현하려고 알아보기 힘든 선도 끄적였습니다. 클라이언트에게 보여 드리기 민망할 정도의 글씨도 적었습니다.

그림을 사진으로 찍어 Claude에게 전달한 뒤, 어떤 용도의 화면인지 두 문장으로 설명했습니다.

손으로 그린 대략적인 와이어프레임.

Claude Design이 생성한 인터페이스.

입력한 것은 30초 만에 그린 미심쩍은 그림이었지만, 결과물은 실제로 작동하는 인터페이스였습니다.

효과가 있었던 부분: 변환 과정에서도 전체 구조가 유지되었습니다. 제가 그린 상자는 실제 레이아웃으로 바뀌었고, 적절한 간격 체계와 컴포넌트 위계도 적용되었습니다. 전반적으로 제가 의도한 구조와 비슷했습니다.

효과가 없었던 부분: 스케치에서 제가 대충 넘어간 내용은 Claude가 임의로 만들어 냈습니다. 제 낙서에는 사용자가 ‘Contact Us’를 클릭했을 때 어떤 일이 일어나는지 표시되어 있지 않았기 때문에, 해당 상태는 아예 구현되지 않았습니다. Claude는 질문하는 대신 모호한 부분을 자신 있게 채웠습니다.

금요일 오후 5시에 주니어 디자이너에게 모호한 와이어프레임을 전달해 본 적이 있다면, 매우 익숙하게 느껴질 만한 상황입니다.

방법 2 — 일상적인 표현으로 작성한 지시 사항

이 방법은 제가 디자인을 생각하는 방식 자체를 바꾸어 놓았습니다. 다음은 제가 실제로 입력한 지시 사항입니다.

신규 사용자가 언어나 SDK에 계측 기능을 빠르게 적용하고 시작할 수 있는 문서 랜딩 페이지가 필요합니다. 대략적인 방향은 다음과 같습니다.

메인 내비게이션은 흰색입니다. 왼쪽에는 Middleware 로고와 Docs를 배치합니다. 메뉴는 Guides, API Reference, Changelog, Community입니다. 오른쪽에는 문서 검색, ⌘K, Ask AI, 보라색 Sign in 버튼을 배치합니다.

히어로 영역은 연한 라벤더와 회색 계열의 배경을 사용하고 가운데에 정렬합니다.

DOCUMENTATION
“오늘은 무엇을 계측하고 싶으신가요?”
OpenTelemetry에 관한 짧은 설명을 추가합니다.

중앙에는 “250개 이상의 페이지를 검색하거나 질문해 보세요”라는 문구가 표시되는 큰 검색창을 배치합니다. ⌘K와 Ask AI도 포함합니다.

인기 항목을 나타내는 필 형태의 버튼은 Kubernetes agent, Flutter RUM, Dual-ship from Datadog, Trace a RAG pipeline, Reduce ingestion cost, MW_TARGET._TARGET으로 구성합니다.

한 줄에 카드 네 개를 배치합니다.
Install an agent — 9개의 대상, 각각 하나의 명령어
Instrument a service — 13개 언어, 에이전트 또는 수동 방식
Migrate from Datadog — 데이터를 두 곳에 동시에 전송한 뒤 완전히 전환
API reference — 공개 API, 서버 렌더링

미니멀하고 여유로운 구성을 사용합니다. 테두리는 은은하게, 그림자는 부드럽게 적용하며, 현대적인 개발자 문서의 미감을 표현합니다.

Claude가 지시 사항을 해석해 만든 결과물.

중요한 사실은 Claude가 화면 하나를 만들었다는 것이 아닙니다. 프롬프트를 작성하면서 제가 발견한 점이 중요했습니다. 저는 이미 디자인을 시스템과 위계, 동작의 관점에서 설명하고 있었습니다. 픽셀 단위로 설명하지 않았습니다.

지난 몇 년 동안 모든 디자인 리뷰와 인수인계 문서, 이해관계자 회의에서 저는 늘 이런 방식으로 디자인을 설명해 왔습니다. 단지 그 언어를 사용해 실제 화면까지 만들 수는 없었을 뿐입니다.

제 디자인 논리가 명확할수록 결과물도 더 좋아졌습니다. 이번 주를 어떻게 보내고 있느냐에 따라 이 사실은 매우 안심되게 느껴질 수도 있고, 조금 위협적으로 느껴질 수도 있습니다.

방법 3 — 원하는 것을 그냥 Claude에게 말하기

이 부분은 ‘게으른 디자이너 편’이라고 부르겠습니다. 때로는 와이어프레임이나 기획서를 준비하지 않았습니다. 다음과 같이 말하기만 했습니다.

이것을 여기로 옮겨 주세요. 이 부분을 더 눈에 띄게 만들어 주세요. 인지 부하를 줄여 주세요. 현재 버전은 모든 요소가 관심을 끌려고 소리치는 것처럼 느껴집니다.

Claude는 피드백을 반영해 구현을 수정한 뒤, 제가 커피를 마시는 동안 새로운 버전을 건네주었습니다. 반복 작업은 더 이상 캔버스를 편집하는 과정처럼 느껴지지 않았습니다. 팀원과 대화하는 일처럼 느껴졌습니다.

Figma가 캔버스 기반의 반복 작업이라면, 이 방식은 대화 기반의 반복 작업이었습니다.

두 방식의 차이는 마찰 비용입니다. Figma에서 “내비게이션을 가로 형태로 바꾸면 어떨까?”라는 아이디어를 시험하려면 20분이 걸립니다. 그래서 어느 정도 확신이 들 때만 시도하게 됩니다. 하지만 여기서는 문장 하나면 충분했습니다. 따라서 평소 같으면 스스로 포기했을 질문까지 포함해 끊임없이 질문을 던졌습니다.

유일한 단점이라면, Fable을 사용하는 팀원이 “퀴디치”라고 말할 틈도 없이 크레딧을 모두 써 버릴 수 있다는 점입니다!

가장 놀라웠던 점: 디자인을 덜 하고 있지 않았습니다

처음에는 이 실험의 핵심이 절약한 시간에 관한 이야기가 될 것이라고 생각했습니다. 제가 디자인을 덜 하게 될 것이라고 예상했습니다. 하지만 그렇지 않았습니다. 단지 다른 방식으로 디자인하고 있었습니다.

제 관심은 다음 질문에서,

이것을 어떻게 만들 것인가?

다음 질문으로 이동했습니다.

이것이 정말 만들어야 할 대상인가?

이 두 질문이 실험 전체를 요약합니다.

일주일 동안 저는 방향 설정과 시스템적 사고, UX 논리, 비평, 우선순위 결정, 시각적 판단, 품질 관리에 집중했습니다. 반면 픽셀을 직접 움직이는 일, 반복적인 UI 제작, 간격 조정, 컴포넌트 수동 조립은 거의 하지 않게 되었습니다. 작업 시간이 사라진 것은 아닙니다. 그 시간이 속한 범주가 달라졌습니다.

AI가 놀라울 정도로 잘했던 일

여기서는 구체적으로 이야기할 필요가 있습니다. 단순히 “빠르다”는 것은 의미 있는 발견이라고 보기 어렵기 때문입니다.

속도: 대략적인 아이디어를 생각의 흐름이 끊기기 전에 눈으로 확인할 수 있는 형태로 빠르게 바꿔 주었습니다. 이는 어떤 아이디어를 기꺼이 시도하게 되는지에도 영향을 미칩니다.

반복 작업: 작동하는 인터페이스가 하나 만들어지고 나면 이를 변경하는 데 드는 비용이 매우 낮았습니다. 반복 작업의 비용이 낮아지면 자신도 모르게 기준이 달라집니다. 첫 번째 버전을 굳이 방어하지 않게 됩니다. 디자이너인 저는 우리가 자신의 디자인을 얼마나 열심히 방어하는지 잘 알고 있습니다.

명시적인 디자인 논리 따르기: 위계와 동작, 제약 조건, 의도를 명확하게 설명했을 때는 예상보다 지속적으로 좋은 결과가 나왔습니다. 모호한 요구 사항을 주면 평범한 결과가 나왔고, 명확한 요구 사항을 주면 정말 좋은 결과가 나왔습니다.

스케치를 구조로 변환하기: 제가 가장 자주 사용한 방법입니다. 문제 해결과 창작, 다양한 취미 활동을 좋아하는 제 머리는 와이어프레임을 그리고 방향을 제시하는 방식과 잘 맞기 때문입니다.

여러 대안 생성하기: 어떤 레이아웃이 더 나은지 20분 동안 고민하는 대신, 두 가지 접근 방식을 만들어 달라고 요청한 뒤 결과물을 보고 판단했습니다. 실제 결과물을 보고 반응하는 것은 머릿속으로 상상하는 것보다 훨씬 빠르고 솔직합니다.

Claude가 완전히 방향을 잃었던 부분

이 글이 긍정적인 이야기만 담고 있다면 아무런 가치도 없을 것입니다. 따라서 이제 반대편 이야기도 해 보겠습니다.

기술적으로는 올바르지만 시각적으로는 지루한 결과물이 나왔습니다.

디자인 시스템을 제공했는데도 Claude가 자체적인 기본 스타일로 되돌아가곤 했습니다.

화면마다 정보 위계의 일관성이 부족했습니다.

익숙한 SaaS 패턴에 지나치게 의존했습니다. 모든 대시보드와 비슷하게 생긴 대시보드가 만들어졌습니다. 모든 제품이 shadcn을 사용하는 것과 비슷했습니다.

간격은 겉보기에 ‘괜찮아’ 보였지만, 명확한 의도가 느껴지지 않았습니다.

단순해야 할 인터랙션을 지나치게 복잡하게 만들었습니다.

관련 없는 문제를 고치는 과정에서 잘 만들어진 디자인을 망가뜨리기도 했습니다.

지시의 의도를 이해하기보다 문장을 문자 그대로 따랐습니다.

그래서 일주일 내내 다음 문장을 계속 떠올렸습니다.

AI는 그럴듯한 답을 만드는 데 매우 능숙합니다. 디자이너는 그럴듯한 답이 올바른 답이 아닐 때 이를 알아차리는 대가로 보수를 받습니다.

가장 큰 문제: 취향

Claude를 더 많이 사용할수록 한 가지 사실이 더욱 분명해졌습니다.

실행 비용은 낮아지고 있지만, 취향의 가치는 낮아지지 않고 있습니다.

완성된 제품에는 Claude가 만든 결과물보다 훨씬 더 많은 취향과 감각이 담겨 있습니다.

Claude는 레이아웃과 컴포넌트, 대시보드, 폼, 랜딩 페이지, 인터랙션 패턴을 만들 수 있습니다. 유능하고 빠르게, 제가 따라갈 수 없는 양으로 생성해 냅니다.

하지만 “뭔가 이상하다”고 알아차리는 것은 전혀 다른 능력입니다.

왜 이상하게 느껴지는지, 구체적으로 무엇을 바꿔야 하는지 아는 것이야말로 가치 있는 능력입니다. 실험을 진행한 일주일 동안 이 부분이 제 실제 업무와 가장 비슷하게 느껴졌습니다. 아무리 프롬프트를 잘 작성해도 AI가 대신해 주지 못한 부분이기도 합니다.

그 일주일 동안 얻은 좋은 결과물은 모두 제가 내린 판단에서 시작되었습니다. 무엇을 요청할지, 무엇을 거절할지, 더 좋은 대안이 제시됐을 때 무엇을 유지할지 결정해야 했습니다.

이러한 판단을 제거하면, 아무도 제대로 검토하지 않은 질문에 대한 그럴듯한 답만 남습니다.

그래서 Figma 사용을 그만둘 생각인가요?

아닙니다.

단지 모든 디자인 결정이 반드시 Figma에서 시작되어야 한다고 생각하지 않게 되었을 뿐입니다.

4일째가 되자 Figma의 역할은 조용히 바뀌어 있었습니다. 첫 번째 시안을 직접 만드는 곳에서 탐색과 개선, 시각적 제어, 협업을 진행하는 곳으로 바뀌었습니다. Figma가 정말 잘하는 일들입니다. 저는 첫 번째 시안에서 잘못된 부분을 수정하고, 시각적 완성도를 ‘그럴듯한’ 수준 이상으로 끌어올리며, 다른 사람들과 협업하기 위해 Figma를 사용했습니다.

이것은 Figma의 역할이 축소된 것이 아닙니다. 오히려 디자인에서 가장 흥미로운 작업 대부분이 여기에 해당합니다. Figma가 사라진 것은 아닙니다. 단지 UI를 수작업으로 제작하는 일이 선택 사항으로 바뀌고 있을 뿐입니다.

7일 후 달라진 점

이전: 컴포넌트를 직접 만들기
이후: 컴포넌트를 만들어 달라고 요청하기

이전: 픽셀 옮기기
이후: 결과물 비평하기

이전: 직접 반복해서 수정하기
이후: 대화로 반복해서 수정하기

이전: 실행 중심
이후: 의사 결정 중심

그리고 전혀 예상하지 못했던 부분도 있었습니다.

가장 큰 생산성 향상은 Claude가 저보다 빠르게 디자인했다는 데서 나오지 않았습니다. 한 가지 아이디어를 선택하기 전에 더 많은 아이디어를 시험할 수 있게 되었다는 점에서 나왔습니다.

새로운 디자이너 작업 방식

이번 주를 처음부터 다시 시작한다면 다음 순서로 진행할 것입니다.

1. 먼저 생각합니다

프롬프트 창부터 열고 화면을 만들어 달라고 요청하지 않습니다. 결과물의 품질은 의도가 얼마나 명확한지에 따라 제한됩니다. 생각하기 전에 프롬프트부터 작성하면 생각하는 일을 AI에 형편없는 방식으로 떠넘기게 될 뿐입니다.

2. 제약 조건을 제공합니다

사용자와 목표, 위계, 동작, 콘텐츠, 한계를 전달합니다. 생략한 제약 조건은 모두 AI의 추측으로 채워지고, 나중에 다시 바로잡아야 할 대상이 됩니다.

3. 첫 번째 버전을 만들게 합니다

첫 번째 버전은 지켜 내야 할 최종 결과물이 아니라, 보고 판단하기 위한 초안으로 다룹니다.

4. 적극적으로 비평합니다

무엇이 잘못되었고 왜 잘못되었는지 구체적으로 설명합니다.

“더 좋게 만들어 주세요”라고 하면 의미 없는 결과가 나옵니다. 반면 “보조 행동이 핵심 행동과 시각적으로 경쟁하고 있습니다”라고 말하면 실제 문제를 수정할 수 있습니다.

5. 대화를 통해 반복해서 수정합니다

무엇을 바꿔야 하는지만 설명하지 말고, 반드시 유지해야 할 조건도 다시 이야기합니다. 그렇지 않으면 한 부분을 고치는 동안 이미 잘 작동하던 다른 부분이 조용히 망가질 수 있습니다.

6. 시각적 제어와 정교한 개선이 중요해지는 시점에 Figma로 이동합니다

이러한 작업은 여전히 자주 필요합니다. 단지 Figma를 사용하는 시점이 이전보다 늦어졌을 뿐입니다.

마치며

일주일 동안 실험한 결과, 디자이너라는 직업이 사라지고 있다고 생각하지는 않습니다.

다만 업무의 성격이 달라지고 있다고 생각합니다.

미래의 디자이너는 인터페이스를 직접 그리는 데 더 적은 시간을 쓰게 될 수 있습니다. 대신 시스템의 방향을 설정하고, 인터랙션을 구체화하고, 결과물에 의문을 제기하며, 무엇이 애초에 만들어질 가치가 있는지 결정하는 데 더 많은 시간을 쓰게 될 것입니다.

불편한 부분도 있습니다.

AI는 측정하기 쉬운 디자인 업무를 매우 능숙하게 수행하고 있습니다. 이는 우리가 ‘단순한 실행 작업’이라고 가볍게 여겼던 일들이 가장 먼저 자동화될 수 있다는 뜻입니다. 취향과 판단력, 맥락에 대한 이해, 공감, 호기심, 그리고 “우리는 애초에 왜 이것을 만들고 있는가?”라고 질문하는 능력이 갑자기 훨씬 더 중요해졌습니다.

저는 일주일 동안 디자인을 그만둔 것이 아닙니다.

디자인이 곧 픽셀을 움직이는 일이라는 생각을 그만두었을 뿐입니다.

비슷한 실험을 해 보셨거나 제가 캔버스를 너무 쉽게 포기했다고 생각하신다면, 여러분의 방식은 어느 지점에서 한계에 부딪혔는지 듣고 싶습니다.

원문 출처: https://medium.com/@theuiface/i-ditched-manual-design-in-figma-for-a-week-7724171906fc

DEET를 구독하고 커리어 성장을 위한 작은 습관을 시작해 보세요.