안녕하세요, 오늘의집 프로덕트 디자이너 Gongdee(공디)입니다.
디자인 업무에 AI를 도입하려는 분이라면 누구나 한 번쯤 이런 상상을 해보셨을 거예요. "AI가 피그마에 화면을 바로 그려줄 순 없을까?" 저 역시 그 기대를 품고 Claude Code와 MCP(Model Context Protocol)를 활용해 피그마와 AI를 직접 연결해 봤습니다. AI가 피그마 안에서 직접 움직이며 결과물을 만들어내는 환경을 구축한 거죠.그런데 설레는 마음으로 해본 결과는 예상과 조금 달랐습니다. 화면 하나를 뽑는 데 20분 가까이 걸렸고, 나온 결과물은 처음부터 다시 손봐야 할 정도로 아쉬운 수준이었어요.
여기서 질문을 바꿔봤습니다. AI로 디자인을 단번에 '완성'하려 하기보다, 작업 흐름에서 유독 시간이 많이 걸리는 '병목 구간'을 푸는 데 집중해 보면 어떨까 하고요. 그렇게 접근을 바꾸자 변화가 생겼습니다. 2시간 걸리던 작업이 15분으로 줄었거든요. 오늘은 제가 시행착오 끝에 정리한, 실무에서 정말 효과적이었던 AI 디자인 워크플로우를 소개해 드릴게요.
왜 ‘AI가 직접 그리기’는 아직 어려울까요?
처음 Figma 공식 MCP*가 나왔을 땐 피그마 파일을 읽어오는 것만 가능했어요. 그래서 ODS(오늘의집 디자인시스템) 컴포넌트까지 활용해 피그마에 직접 그릴 수 있는 Figma DS MCP를 자체적으로 만들어 테스트해 봤습니다. 이후 공식 MCP도 그리기 기능을 지원하면서 다시 시도해 봤지만, 결과는 크게 다르지 않았어요.
- 첫째, 생각보다 시간이 꽤 걸려요. 화면 하나 그리는 데 15~20분이 걸립니다. 사실 숙련된 디자이너가 피그마에서 직접 그리면 5분이면 충분한 작업이라, 오히려 시간이 더 걸리는 셈이었죠.
- 둘째, Figma만으로는 화면 사이의 '흐름'까지 담아내기 어려웠어요. Claude나 Figma Make처럼 동적인 툴은 플로우 사이의 인터랙션이나 예외 케이스까지 함께 검증할 수 있지만, Figma는 정적인 화면 단위라 A에서 B로 넘어가는 유기적인 Flow를 표현하는 데 한계가 있었습니다. 결과적으로 단편적인 화면 나열에 그치게 됐어요.
- 셋째, 퀄리티를 위해 결국 사람의 손길이 필요해요. ODS 컴포넌트를 사용하더라도 결국 처음부터 다시 손봐야 할 때가 많았습니다. AI가 컴포넌트를 '불러올 줄' 안다고 해서, 그걸 맥락에 맞게 '잘 배치하는' 것까지는 또 다른 영역의 문제였어요.
물론 편리한 부분도 있었어요.
- ODS 토큰 미적용 영역에 토큰 일괄 적용
- 화면이 많을 때 공통 수정 사항 일괄 반영
- Athena MCP*로 실제 상품 데이터를 가져와 디자인에 적용
하지만 디테일을 잡아 디자인을 완성하는 용도로는 아직 아쉬움이 있었어요. 그래서 고민의 방향을 바꿨습니다. '디자인 완성'이 아니라, 작업 과정에서 유독 시간이 걸리는 '병목 구간'을 AI로 풀어보면 어떨까 하고요.
*MCP(Model Context Protocol) : AI가 내 로컬 환경이나 피그마 같은 외부 툴의 맥락(Context)을 실시간으로 파악하고 동작하게 만드는 연결 프로토콜
*Athena MCP : 오늘의집 내부 데이터를 조회할 수 있는 인터페이스. AI 모델이 이 규칙(Protocol)을 통해 실제 상품 정보나 유저 데이터를 안전하게 불러올 수 있어요.
① 디자인 초안: Figma Make와 Claude Code로 방향 잡기
디자인 초안의 핵심은 여러 방향을 펼쳐놓고 팀과 함께 가장 나은 방향을 찾아가는 과정이에요. 그런데 와이어프레임 수준으로 그리는 것만 해도 보통 2~3일은 걸리고, 구체화된 시안까지 가면 일주일 가까이 걸리곤 했습니다.
저는 화면을 직접 동작시켜 보면서 디자인을 검증하는 편이라 초안 단계에서도 프로토타입을 자주 만드는데요. 플로우 기반으로 화면을 생성해 주는 Figma Make가 처음 나왔을 때 무척 반가웠습니다. 화면 간 전환과 흐름을 통째로 만들어주고, 프롬프트 몇 번이면 초안을 뽑아낼 수 있었으니까요.
💡 초반 탐색엔 Figma Make와 Claude Code 둘 다 적합해요. Figma Make는 피그마 안에서 빠르게 여러 방향을 시도하기 좋고, Claude Code는 이미 있는 피그마 프레임을 읽어서 실제 동작하는 프로토타입을 만들 때 강해요.
[Figma Make] 피그마 안에서 바로 작업하기
Figma Make는 피그마 안에서 결과물이 바로 나오기 때문에, 곧바로 디자인을 다듬기에 정말 편해요. 적극적으로 활용하면서 나름의 노하우도 생겼어요.
- 자주 쓰는 화면은 템플릿화하기 : 주요 화면들을 미리 만들어두고 복사해서 쓰면, 매번 처음부터 만들지 않아도 되어 시간이 크게 단축됩니다.
- 요소 하나하나 짚어주기 : 참고할 피그마 링크를 넣고, 화면에 들어갈 요소들을 구체적으로 언급해 보세요. 상세하게 요청할수록 결과물의 퀄리티가 눈에 띄게 올라갑니다.
- 단계별로 다듬기 : 처음부터 완벽한 결과물을 기대하기보다, 프롬프트를 여러 번 주고받으며 디테일을 잡아 나가는 방식이 훨씬 효과적이에요.
[Claude Code] 기존 디자인을 읽어와서 HTML로 바로 만들기
Claude Code는 접근 방식이 조금 달라요. Figma MCP로 기존 디자인 프레임을 읽어오면 구체적인 프롬프트 없이도 디자인을 잘 만들어냅니다. 한 가지 차이점은 작업 환경이에요. 피그마 안에서 바로 수정하는 방식이 아니라, 피그마 밖에서 실제로 동작하는 별도의 HTML 파일로 결과물이 만들어진다는 점이 특징입니다.
아이디어 펼치기
두 도구 중 어떤 걸 쓰든, 초안의 뼈대가 잡히고 나면 본격적으로 다양한 아이디어를 시도해 보는 단계로 넘어갑니다. 이때는 하나의 시안을 파고들기보다, 여러 갈래의 시안을 동시에 펼쳐놓고 비교하는 방식이 훨씬 유용했어요.
방향이 열려있을 때는 AI에게 시안을 요청하고, 이미 구체적인 시안이 있을 때는 그걸 그대로 요구할 수 있습니다. 처음 나오는 결과물이 바로 쓸 수준은 아니지만, AI가 같은 문제를 다양한 방식으로 풀어주는 걸 눈으로 확인하면서 힌트를 얻고, 그걸 바탕으로 제 방식대로 디벨롭해나갈 수 있다는 점이 가장 큰 장점이었어요. 무엇보다 시안 작업에 며칠씩 고민하는 대신, 아이디어가 떠오른 그날 바로 팀과 논의를 시작할 수 있게 된 점이 정말 좋았어요.
② 방향이 정해졌다면 UT까지 그대로 이어가기
초안 단계에서 만든 프로토타입을 UT에도 그대로 활용할 수 있다는 점이 큰 장점이었습니다. 별도로 UT용 목업을 다시 만들 필요 없이, 초안 프로토타입에 유저 데이터만 넣으면 바로 테스트에 들어갈 수 있었어요. 몰입도 높은 UT를 만들려면 참여자에게 맞는 실제 데이터를 넣는 게 중요한데, 이 과정에서 Figma Make와 Claude Code의 차이가 꽤 컸습니다.
[Figma Make] 유저별 데이터를 일일이 수작업
Figma Make로 만든 프로토타입에 유저별 데이터를 넣으려면, 참여자마다 맞는 상품 사진과 정보를 직접 찾아서 하나하나 교체해야 했어요. 참여자 5명만 되어도 2시간 넘게 단순 반복 작업을 해야 하는 상황이었죠.
[Claude Code + Athena MCP] 유저 ID 하나로 한 번에
Claude Code로 만든 HTML 프로토타입은 달랐습니다. 사내 데이터 조회 MCP인 Athena를 연동해 두니, 유저 아이디와 필요한 조건만 알려주면 데이터를 바로 조회해서 프로토타입에 한꺼번에 반영할 수 있었어요.
1. Athena MCP로 원하는 데이터를 조회한다.
"유저 ID XXXXXXX, XXXXXXX ... 의 최근 1달간 가구/가전 카테고리 상품 조회 이력을 뽑아서, 3개 이상 조회한 카테고리의 상품을 알려줘”
2. 조회한 데이터를 프로토타입에 적용해달라고 요청한다.
"유저 ID별로 카테고리 2개씩만 상품 ID 가져와서 '상품비교_mobile_light.html'에 적용해줘.”
3. 유저가 실제로 담은 패키지 상품이 프로토타입에 반영된다.
💡 이렇게 하면 UT 참여자가 실제로 봤던 상품을 화면에 넣을 수 있어 몰입도가 확 올라가고, 유저 5명 데이터 세팅도 2시간 → 15분으로 줄일 수 있어요.
③ 만져보는 인터랙티브 스펙으로 정책 커뮤니케이션하기
UT에서 실제 동작하는 프로토타입의 힘을 체감한 뒤, 같은 접근을 팀 내 커뮤니케이션에도 적용해봤습니다.
문서로는 전달하기 어려운 조건부 UI
커머스는 정책들이 서로 얽혀 있어서 조건부 케이스가 많은 편이에요. 이걸 정리하고 전달하는 과정에서도 AI를 유용하게 쓸 수 있었습니다. 특히 가격 ATF(화면을 켜자마자 바로 보이는 영역) 케이스를 정리해서 전달할 때마다 이 문제가 자주 생겼어요. 기존에는 텍스트나 시안 이미지로 케이스를 정리하곤 했어요. 하지만 만드는 사람도 내용을 빠뜨리기 쉽고, 확인하는 사람도 원하는 케이스를 찾기가 참 어려웠죠. PDP(상품 상세 페이지) ATF 가격 커뮤니케이션만 해도 상품쿠폰 × 장바구니쿠폰 × 패키지 상품 여부 × 수령 여부 조합만으로 케이스가 기하급수적으로 늘어나거든요.
읽는 스펙이 아니라 만져보는 스펙
그래서 조건을 직접 토글하면 목업 UI가 실시간으로 바뀌는 인터랙티브 스펙을 만들었습니다. 문서를 읽고 상상하는 방식이 아니라, 원하는 조건을 직접 조작하면서 화면을 확인할 수 있게요.
[제작 방법]
- 디자인 스크린샷 전달하기
피그마에 정리한 스펙을 캡처해 Claude Code에 첨부하고, 항목별로 조작 가능한 프로토타입을 만들어달라고 요청합니다.
- Figma MCP로 디테일 잡기
"Figma MCP로 이 화면을 읽어서 똑같이 만들어줘"라고 덧붙이면, 실제 디자인의 룩앤필(Look & feel)이 그대로 반영됩니다.
- 간편한 수정
새로운 정책이나 조건이 생겨도 프롬프트 한 줄이면 즉시 반영할 수 있어요.
💡 상품쿠폰, 장바구니쿠폰, 패키지쿠폰 수령 여부를 토글하면 쿠폰할인가, 버튼 상태, 문구가 조건에 따라 즉시 바뀌어요. 개발/기획/QA가 궁금한 케이스를 스스로 조작하며 확인할 수 있게 되면서, PDP 가격 정책 개발/QA 과정에서 반복되던 확인 질문이 0건이 됐습니다.
정리하며
피그마 → 프로토타입 → 테스트 → 다시 피그마. 이 흐름이 효과적이었던 건 분명하지만, 실제로 반복해 보니 아직 풀리지 않은 병목들이 있습니다.
- ODS 자동 적용의 한계 - AI 결과물에 ODS 컴포넌트가 자동으로 입혀지진 않아요. 핸드오프를 위해 컴포넌트를 교체하고 디테일을 잡는 건 여전히 디자이너의 몫입니다.
- 프롬프트 의존성 - Figma Make든 Claude Code든 결과물의 퀄리티가 프롬프트 작성 능력에 좌우됩니다. 결국 디자이너의 도메인 이해도가 가장 중요한 기반이 되더라고요.
- 두 벌 관리 - 피그마 파일과 AI 프로토타입이 각각 존재하다 보니, 디자인 수정 시 양쪽을 모두 업데이트해야 하는 수고가 따릅니다.
그럼에도 분명한 변화가 있었어요. AI가 피그마에 완벽한 화면을 바로 그려주길 기대했지만, 진짜 효과적이었던 건 AI에게 모든 걸 맡기는 게 아니라, AI로 빠르게 검증하고 확정된 방향을 피그마에서 완성하는 흐름을 만든 것이었습니다.
- 시안 작업 : 3~4일 → 반나절
- UT 데이터 세팅 : 참여자 5명 기준 2시간 → 15분
- 정책 커뮤니케이션 : 반복 질문 → 인터랙티브 스펙으로 0건
디자인시스템이 코드 기반으로 구축되어 있지 않은 환경에서는, AI가 디자인을 완성해 주길 기대하기보다 디자이너의 판단을 더 빠르게 검증하는 도구로 쓸 때 가장 잘 맞았어요. AI 도구들이 계속 발전하고 있는 만큼, 이 워크플로우도 함께 다듬어 나갈 예정입니다.
