Figma 없이 UI 만든다고? AI 시대의 UI/UX 디자인 시스템과 워크플로우

우연히 브런치 글 제목 하나가 눈에 걸렸어요. “Figma로 직접 디자인하는 일을 7일간 그만두기.” 피그마를 전혀 열지 않고 UI를 만든다고? 대체 디자이너가 무슨 수로 화면을 그려냈는지 궁금해서 최근 올라온 UI/UX 관련 아티클 5편을 차례로 뜯어보기 시작했습니다.

픽셀을 옮기던 손에서 AI를 가르치는 감독으로

디자이너와 개발자의 일이 “피그마 벡터 툴로 픽셀 옮기기”에서 “AI에게 명확한 정답지(SSOT)를 쥐어주고 결과를 감독하기“로 급격히 이동하고 있습니다.

AI에게 무작정 “예쁜 UI 만들어줘”라고 요청하면 매번 다른 툴팁과 어색한 버튼을 지어냅니다. 하지만 컴포넌트 규칙과 디자인 토큰을 정답지로 먼저 정의하고, 기획 검토와 시안 제작을 스킬로 고정해 두면 AI가 곧바로 사용할 수 있는 프론트엔드 코드 시안을 토해냅니다.

오늘 읽은 5편의 글에서 건진 핵심 워크플로우와 실전 팁을 제 언어로 정리해 보았어요.

1. 피그마 대신 종이 스케치와 말로 시안을 뽑는 7일간의 실험

원문 아티클 보기

🎨 픽셀 옮기기를 그만두다

7일 동안 피그마를 닫고 종이에 대충 그린 와이어프레임 사진을 Claude에게 넘겨 시안을 뽑은 실험기입니다. 결국 디자인 자체를 그만둔 게 아니라, 피그마에서 픽셀을 일일이 옮기던 손작업을 그만둔 셈입니다. 디자이너가 작업자에서 감독이 되는 과정이네요.

✅ 좋았던 점: 시안 제작 속도가 압도적으로 빠르고, 시안 선택지를 여러 개 뽑는 비용이 거의 들지 않습니다.
❌ 아쉬운 점: 시각적인 정교함, 세밀한 디자인 시스템 일관성, 전체 브랜드 맥락 이해는 여전히 사람의 개입이 필수적입니다.

2. AI가 일관되게 디자인하도록 ‘정답지(SSOT)’ 구축하기

원문 아티클 보기

📚 정답지(Single Source of Truth)를 먼저 친다

AI가 매번 제각각으로 UI를 만들어내지 않게 하려면, 기준이 되어줄 울타리가 필요합니다. 스토리북 컴포넌트 목록, 컴포넌트 레지스트리, UX 원칙 문서를 먼저 작성해서 “이 안에서만 골라 써“라고 명시하는 것이죠.

🔁 프로세스를 굳히는 2가지 핵심 스킬

Spec-Review (5단계): 기획서 읽기 → 진짜 문제 진단 → 디자인 접근 분류 → 빠진 질문 도출 → 리스크 분석 → 디자이너 해석 정리
Spec-to-UI (9단계): 목표 설정 → 상황 나열 → 컴포넌트 매핑 → 시안 생성 → 문구 점검 → 리뷰 → 핸드오프 없는 반복

시안이 곧 프론트엔드 코드로 나오기 때문에 “디자인 후 개발 전달(Handoff)“이라는 단계 자체가 사라진다는 대목이 참 흥미로웠습니다.

3. 메타·커서·버셀 공고가 말하는 ’디자인 엔지니어’의 부상

원문 공고 분석 보기

📋 최근 채용 공고에 적힌 디자이너의 역할

메타, 커서, 버셀, 당근마켓의 최신 채용 공고를 뜯어보니 디자이너에게 요구하는 역량이 눈에 띄게 변했습니다.

메타: 프롬프트 엔지니어링 능력을 갖춘 디자이너
커서: 아예 “디자인 엔지니어(Design Engineer)” 직군 채용
버셀: 피그마와 v0, Cursor를 자유롭게 넘나드는 워크플로우
당근: AI 산출물의 품질을 제어하고 관리하는 디자인 시스템 구축

직군의 경계는 무너지는데, 한 사람이 다룰 수 있는 범위는 훨씬 넓어지는 방향으로 가고 있습니다.

또한 제가 인상 깊었던 것은 여기서 새로운 디자이너 JD의 방향성이었습니다. 첫째로 동작하는 프로토타입, 디자인 시스템 코드를 산출하는 능력입니다. 둘째로 Figma, v0, Cursor, Claude Code를 활용해서 AI를 활용해 시안을 뽑고, 또는 기존의 디자인 패턴을 AI 한테 가르치면서 만듭니다. 여기서 디자인 시스템은 더이상 사람이 읽는 가이드가 아닌, AI가 참조하는 정답지(SSOT)로서의 역할을 하게 됩니다.

여기서 v0는 사용자의 말-자연어와 프롬프트를 바탕으로 UI 컴포넌트부터 풀스택 웹 애플리케이션까지 생성해 주는 Vercel의 AI 기반 개발 플랫폼입니다. v0 공식 홈페이지를 참고하시면 더 자세한 정보를 확인하실 수 있습니다. v0 또한 결과물이 React 코드로 나오기 때문에, 디자이너가 직접 코드를 다루는 능력도 필요하다는 점이 흥미로웠습니다.

4. 앱 캡처 대신 약관 문서를 AI에게 읽히는 경쟁사 리서치

원문 리서치 팁 보기

🔍 화면 대신 텍스트 문서를 뜯는다

경쟁사 앱 화면을 일일이 캡처하는 리서치는 시간도 오래 걸리고 놓치는 예외 조건이 많습니다. 하지만 이용약관, FAQ, 공지사항 문서에는 서비스의 동작 조건이 글자로 명확히 적혀 있습니다.

이 원문 텍스트를 AI에게 투입하고 병렬로 분석시키면 3일 걸리던 경쟁사 리서치가 반나절로 줄어든다고 해요.

⚙️ 반나절 만에 끝내는 리서치 3단계

분석 소스의 우선순위 정하기 (약관 → 가이드 → FAQ)
통일된 분석 프레임(구조)으로 AI에게 병렬로 돌리기
출력 포맷(표, 비교 리스트)을 미리 명시하기

5. 피그마를 열기 전, HTML 한 장으로 전체 톤 미리보기

원문 워크플로우 보기

🛠️ AI를 붙여 효율을 높인 4가지 지점

레퍼런스 조사: 핀터레스트 대신 특정 조건을 지정해 AI에게 색다른 사례 추천받기
디자인 시스템 미리보기: 화면을 그리기 전, 색상·타이포·컴포넌트를 HTML 한 장으로 뽑아 다크모드 포함 전체 톤을 미리 검증하기
Figma Make: 프로토타입을 빠르게 만들고 말로 수정한 뒤 디자인 레이어로 전환하기
사용자 흐름 검수: 에러·로딩·예외 케이스를 AI가 먼저 리스트업하게 만들기

어떤 시안이 맞는지 판단하는 눈과 머리 즉 사용자의 경험을 설계하는 능력은 여전히 사람에게 달려있지만, AI를 활용하면 시안 제작과 검증 속도가 비약적으로 빨라진다고 합니다. 특히 HTML 한 장으로 전체 톤을 미리 검증하는 방식은 화면 캡처보다 훨씬 빠르고, 다크모드까지 포함해 전체적인 톤을 확인할 수 있어 유용합니다.

⚠️ AI 디자인 워크플로우 도입 시 조심할 점

출처 근거 표시 필수: 약관 문서나 리서치를 AI에게 시킬 때 출처 위치(조항번호, 페이지)를 반드시 명시하게 해야 환각(Hallucination)을 막을 수 있습니다.
디자인 일관성 무너짐 경계: SSOT(정답지) 문서 없이 프롬프트만 돌리면 화면마다 버튼 크기나 여백이 제각각으로 흩어집니다.
원문 검증 생략 금지: AI가 요약한 결과를 맹신하지 말고, 핵심 리스크 문항은 사람이 직접 원문과 대조해야 합니다.

🚀 내일 바로 해볼 실천 리스트

내 프로젝트(mesa) 색상·타이포·컴포넌트를 HTML 한 장으로 시안 뽑아보기
종이에 손으로 와이어프레임 그려서 AI에게 코드 변환 요청해보기
Spec-Review 5단계를 적용한 UIUX 분석 프롬프트 템플릿 만들기

📝 3줄 요약

디자이너와 개발자의 역할이 픽셀 그리기에서 AI 감독 및 정답지(SSOT) 설계로 이동하고 있습니다.
기획 검토(Spec-Review)와 시안 생성(Spec-to-UI)을 스킬로 굳히면 시안이 곧 코드가 됩니다.
화면 캡처 대신 약관 분석과 HTML 1장 미리보기를 활용하면 리서치와 톤 검증 속도가 비약적으로 빨라집니다.

💡 마무리하며

이번에 UI/UX 기사들을 읽으면서 디자인 패턴 공부에 대한 막연한 두려움이 많이 사라졌어요. Top-Down 으로 읽어가나간 아티클들이 현재 UI/UX 작업의 방향성을 알게 해줬습니다. 개발자 입장에서 디자인 시스템은 결국 잘 짜여진 컴포넌트 아키텍처와 비슷하게 느껴졌습니다. 그리고 이제 Figma, v0, Cursor, Claude Code 를 자유롭게 넘나드는 워크플로우를 다룰 수 있는 디자이너가 필요하다는 점이 인상 깊었습니다. 앞으로는 디자이너와 개발자가 함께 디자인 시스템을 구축하고, AI를 활용해 시안을 뽑고, 프론트엔드 코드까지 바로 연결하는 시대가 올 것 같아요.

모두가 빌더가 되는 시대가 되어가고 있는데요, 그 덕분에 디자인과 개발의 경계가 무너지고, 훨씬 더 재밌게 작업할 수 있을 것 같아 기대됩니다. 앞으로 만들 mesa 프로젝트 프론트엔드에도 오늘 배운 ’HTML 1장 미리보기’와 ‘손스케치 + AI 시안’ 방식을 그대로 적용해 보면 좋을 것 같아요.