AI가 만든 UI, 이젠 실무에서 진짜 씁니다
AI 에이전트 제작기 - UI 디자인
스파르타 제품실에서 직무 간 경계가 사라지고, PM/디자이너/개발자였던 사람들이 PE라는 이름 아래 같은 일을 하게 된 지 어느덧 세 달에 가까운 시간이 흘렀어요. 전환 과정에서 디자이너(였던 사람)로서 가장 고민이 되었던 건 ‘디자이너가 아니었던 사람들이 AI를 통해 스스로 디자인을 할 수 있게 만드는 방법’이었어요. AI가 정말 실무에 바로 쓸 수 있는 수준의 UI를 만들 수 있을까? 디자이너의 손을 타지 않고도 제품을 만들 수 있을까?
고민이 이어지던 차에 구글 스티치(Google Stitch)가 DESIGN.md를 공개했어요. 그 안에는 구글의 디자인 언어가 글과 표로 서술되어 있었고, 가이드 아래 스티치는 일관된 스타일로 디자인 프로토타입을 뚝딱 만들어내고 있었어요. 디자인 언어를 고유한 표현으로 정의할 수 있다면, 그것을 잘 관리할 수만 있다면 우리도 가능할지 모르겠다는 생각이 들었죠.
피그마를 건너뛰기
처음에는 디자인 시스템(STACK)과 DESIGN.md를 기반으로 AI가 피그마에 화면을 그려주는 방식을 떠올렸어요. AI가 작업이 필요한 프레임을 피그마에서 스스로 찾아서 복제하고, 화면을 그리고, 배포가 끝나면 피그마 전 범위에 업데이트 사항을 반영해 줄 수 있을 것 같았어요. 그러기 위해서는 실서버에서 라이브 중인 화면과 피그마 상의 디자인 파일을 완전히 일치시키는 작업이 필요했어요. ‘GNB에서 아이콘 바꾸고 싶어’와 같은 명령을 수행할 수 있으려면 AI가 피그마에서 AS-IS 상태의 GNB 프레임을 찾고, 아이콘 슬롯을 발견할 수 있어야 할 테니까요.
하지만 기존의 작업물들은 그렇지 않았어요. 피그마에는 배포 환경에서 벌어지는 모든 동작에 대한 명세가 기록되어있지 않았고, 피그마에 없는 화면이 배포되어있기도 했어요. 코드에서 부르는 컴포넌트 명칭과 피그마에서 정의한 레이어 이름이 달라서 AI가 요소를 바로 찾을 수도 없었어요.
한 마디로 기존의 피그마 환경은 AI가 읽을 수 없는 환경이었죠. playwright로 배포된 화면을 캡처해 피그마에 불러오기도 해 봤고, 코드 ↔ STACK 매핑 테이블에 따라 코드를 역으로 추적해서 피그마에 화면을 그리게 시켜보기도 했어요. 하지만 그 과정에서 디자인이 유실되거나 전혀 다른 형태의 화면이 만들어졌어요.
결국 당시로서는 ‘코드를 피그마의 그래픽 노드로 완벽하게 변환하는 작업은 불가능하다’고 판단할 수밖에 없었어요. 가능하더라도, 디자인을 하나 고치려고 하면 수많은 노드를 편집하는 과정에서 매우 많은 토큰과 시간이 쓰였죠. 빠르게 만들고 검증하는 실무의 방향성과는 거리가 있었어요.
시행착오 끝에 새로운 아이디어가 떠올랐어요. 꼭 피그마여야 할까? 피그마는 디자이너에게 친숙한 툴이에요. 디자이너가 아니었던 사람들은 대부분 피그마를 어려워했고, 작업을 위해서는 편집 권한부터 파일 관리까지 신경 쓸 일이 아주 많았어요. 어쩌면 관성적으로 ‘디자인은 피그마에서 해야 한다’는 생각에 갇혀있던 것일지도 몰라요.
처음부터 디자인 시안을 코드로 구현할 수 있다면 페이지 간의 연결성이나 마이크로 인터랙션 같은 것들을 프로토타입으로 생생하게 확인해 볼 수 있어요. 그 과정에서 UT를 해볼 수도 있고, User Flow 상 구멍 난 곳은 없는지 직접 점검해 볼 수도 있죠. 확정된 디자인을 실제 개발로 옮길 때도 이미 만들어진 코드 파일을 기반으로 구체화할 수 있었어요.
/ui-prototype-generate
그래서 개발 환경에서 바로 디자인 시안을 만들기로 했어요. ‘화면 디자인’과 ‘동작 방식을 구현’하는 일이 거의 동시에 벌어지는 셈이에요. 코드에서 수정한 뒤 로컬 호스트에서 확인하는 방식이라, 피그마를 모르는 동료도 처음부터 끝까지 오직 클로드 코드만을 사용해서 작업할 수 있었어요. AX 전환 관점에서도 더 적합했어요.
/ui-prototype-generate 스킬의 목표는 딱 세 가지였어요.
1. 디자인 품질이 실무에서 쓸 수 있는 수준이어야 한다.
2. 기존 제품의 맥락을 유지해야 한다.
3. 쉽고 빠르게 반복할 수 있어야 한다.
처음부터 완성에 가까운 디자인을 만들어내는 무거운 도구가 필요하지 않았어요. 스파르타다운 화면을 빠르게 만들고, 쉽게 수정하면서, 필요하다면 언제든 버리고 새로운 아이디어를 찾을 수 있는 도구를 만들어야 했어요.
알잘딱 스킬을 만들기 위한 3가지 방법
‘알아서 잘 딱’ 같은 건 AI에게는 통하지 않더라고요. 품질이 좋으면서도 맥락을 잘 이해하고, 가볍기까지 한 스킬을 만들기 위해서는 다음과 같은 노력이 필요했어요.
1. 디자이너의 뇌를 만들어주기
AI가 디자이너의 관점에서 적절한 판단을 내릴 수 있도록 아래 문서를 만들어 학습시켰어요.
STACK-Spec
스파르타의 디자인 시스템, STACK의 모든 정보를 담고 있는 스펙 문서예요. 보유 중인 컴포넌트 목록, 각 컴포넌트의 Props, 사용 방법, 주의사항 등을 담고 있어요.
Design-Principle
STACK-Spec은 ‘디자인 시스템을 기술적으로 사용하는 방법’에 대한 가이드여서, ‘이런 상황에서는 어떤 컴포넌트를 사용하는 게 좋은 UX일까?’와 같은 관점은 빠져있어요. 이처럼 디자이너의 관점이 필요한 회색 영역을 Design-Principle로 해소하려고 했어요.
이 안에는 프로덕트 디자이너가 실무에서 실제로 사용하던 의사결정 프레임워크부터, 상황에 따른 컴포넌트 선택 기준, UX/UI에 대한 기본적인 개념과 원칙이 정의되어 있어요. 스킬을 통해 구현된 모든 UI는 Design-Principle에 기반해요. 정의가 견고해질수록 소위 말하는 ‘AI 스러움’은 벗겨지고 익숙하게 보던 UI 결과물들이 나오기 시작했어요.
끔찍했던 디자인에서 조금씩 나아지고 있는 모습2. 모든 작업의 시작은 Repo로부터
디자인 기획 단계에서 해당 작업이 반영될 지면의 실제 코드 저장소, 즉 레포지토리 주소를 입력받아요. 그러면 스킬이 코드 기반 최신 정바카라을 확인한 뒤, AS-IS 상태의 제품 문법을 이해하고 있는 상태로 작업을 진행해요.
3. 기존 코드를 건드리지 않고, 독립된 섬 안에서만 작업하기
처음에는 AI가 클론으로 내려받은 폴더 안에서 코드 전체를 자유롭게 수정했어요. 그랬더니 시간도 오래 걸릴뿐더러 영향 범위를 정확히 알 수 없어서 코드 리뷰를 보는 것이 불가능에 가까웠어요. 디자인이 마음에 안 들어서 일부분만 수정하거나 다시 처음으로 돌아가고 싶을 때도 쉽지 않았죠.
그래서 클론으로 최신 상태의 코드를 내려받되 그 안에서 독립적인 ‘prototype’ 폴더를 만들도록 했어요. 기존 코드를 참조하면서, 이 스킬을 통해 확인해보고 싶은 프로토타입 범위까지만 독립적인 데모 환경을 만드는 거예요. 제품 맥락 기반으로 적절한 더미 데이터를 활용하므로 백엔드 서버까지 연결할 필요도 없고, 프로토타입 결과가 마음에 들지 않으면 언제든 폴더를 지우고 처음부터 다시 시작할 수 있어요.
7단계로 완성하는 UI 프로토타입
좋은 결과물을 만들기 위해서는 좋은 인풋이 필요하죠. 스킬 실행 시 정해진 7단계를 돌도록 고정했고, 그 안에서 적시에 필요한 인풋을 수집할 수 있도록 설계했어요.
스킬을 실행하면 다음과 같이 대화가 이어져요. 기획 내용에 따라 질문 구성은 조금씩 바뀌어요.
Phase 1. 기획 확인
프로토타입으로 만들 기획안을 보내주세요. 아래 세 형식 중 하나면 됩니다.
1. 노션 링크 — 본문을 직접 불러와 분석합니다.
2. 기획 텍스트 — 이 대화에 그대로 붙여 넣어 주세요.
3. 피그마 링크 — 링크와 함께 화면의 목적·핵심 요구사항을 텍스트로 적어 주세요.
받으면 먼저 다음 항목으로 기획을 정리하겠습니다: 목적, 타겟 사용자, 핵심 과업, 성공 기준, 적용 지면, 제약사항. 이후 정보 보강과 두 차례의 승인 단계를 거쳐 격리된 프로토타입을 구현합니다.
Phase 2. 정보 보강
프로토타입의 시각적 위계와 더미 콘텐츠를 결정하기 위해 다음 항목을 확인하겠습니다.
1. 타겟 특성 관리자는 어떤 환경에서 이 화면을 사용하나요? - 데스크톱 업무 환경에서 반복적으로 사용 / 태블릿과 데스크톱을 함께 사용 / 모바일 중심 / 아직 정해지지 않음
2. 핵심 과업 우선순위 가장 강조해야 할 작업은 무엇인가요? - 응답 내용을 빠르게 읽기 / 응답자를 빠르게 찾기 / 응답을 상태별로 분류하기 / 응답을 다운로드하거나 외부로 공유하기
3. 더미 데이터 프로토타입에 들어갈 실제와 비슷한 응답 예시가 있나요? - 실제 설문과 유사한 한국어 응답을 임의 작성 / 사용자가 제공한 문구 사용 / 짧은 응답과 긴 응답을 섞어서 작성 / 숫자와 선택형 응답 위주로 작성
4. 인터랙션 정바카라 어떤 상태까지 눈으로 검증해야 하나요? - 기본·로딩·빈 상태·에러 상태 모두 / 기본 상태와 빈 상태 / 기본 상태와 상세 모달 / 기본 상태만
5. 반응형과 다크 모드 어느 범위까지 대응할까요? - 데스크톱만, 라이트 모드만 / 데스크톱과 모바일, 라이트 모드 / 데스크톱과 모바일, 라이트·다크 모드 / 기존 제품 화면과 동일한 범위
6. 연결 플로우 다른 지면으로 이어지는 흐름이 있나요? - 목록에서 응답 클릭 → 상세 모달 / 목록에서 응답 클릭 → 별도 상세 페이지 / 필터 적용 → 같은 화면에서 결과 변경 / 별도 연결 플로우 없음
7. 추가 지면 현재 식별한 화면 외에 별도 프로토타입 화면이 필요한가요? - 현재 화면 1개만 필요 / 응답 상세 화면 추가 / 설문 설정 화면 추가 / 결과 리포트 화면 추가
Phase 3. 모드 분기와 경로 확인
이 프로토타입은 어떤 종류인가요?
1. 기존 제품 플로우의 일부 수정 또는 추가 - 기존 화면 전체를 복제하고 변경분을 반영하는 수정 모드
2. 흉내 낼 기존 페이지가 없는 신규 지면 - 디자인 원칙을 기반으로 새로 작성하는 신규 모드
수정 모드에서는 잘못된 화면을 복제하지 않도록 라이브 URL 또는 파일 경로가 필요합니다. 다음 정보를 확인해 주세요.
- 라이브 URL 또는 제품 내 라우트
- 해당 화면을 렌더 하는 파일 경로
- 적용할 로컬 repo의 절대경로
라이브 URL과 파일 경로를 둘 다 알려주면 가장 안전합니다.
Phase 4. 격리 폴더 생성과 분석
✅ 격리 폴더 생성 완료
- src/prototype/*******/
- pages/test/prototype/*******.tsx
격리 규칙:
1. 모든 신규 컴포넌트·함수·타입은 src/prototype/* 안에만 생성
2. src/prototype에서 기존 코드를 읽거나 import하는 단방향 참조만 허용
3. 기존 제품 코드가 prototype 코드를 import하는 역참조 금지
4. 모든 데이터는 더미로 작성
5. fetch·useQuery·실제 API 호출 금지
6. 검증 종료 시 위 폴더와 라우트 파일만 삭제하면 원복
Repo Scan 후 기존 화면 분석을 마쳤습니다.
확인한 주요 특징:
- 기존 관리자 Layout과 상단 GNB를 그대로 사용해야 합니다.
- 화면은 라이트 테마를 기본으로 사용합니다.
- 페이지 본문은 회색 배경 위의 흰색 콘텐츠 영역으로 구성돼 있습니다.
- 필터와 검색은 응답 표 위에 배치돼 있습니다.
- 응답 상세는 별도 페이지가 아니라 모달로 열립니다.
- 주관식 응답 길이가 길 때 표의 열 너비와 줄바꿈이 가장 중요한 검증 요소입니다.
- 도움말과 다른 관리자 메뉴는 이번 변경 플로우와 무관하므로 화면은 유지하되 클릭은 동작하지 않게 처리합니다.
기존 화면의 외곽 구성과 데이터 밀도를 기준으로 UI 전략을 정리하겠습니다.
Phase 5. UI 전략 제안
# UI 전략: 설문 응답 확인 개선
## 한 줄 요약
관리자가 응답자의 핵심 정보와 긴 주관식 답변을 표 안에서 빠르게 훑고, 필요한 응답만 상세 모달로 확인할 수 있게 합니다.
## 핵심 디자인 결정
1. **응답 내용을 가장 넓게 배치합니다.** - 이 화면의 최우선 과업이 응답 읽기이므로 이름이나 제출 시각보다 답변 영역에 더 많은 공간을 사용합니다.
2. **긴 응답은 잘리지 않고 여러 줄로 표시합니다.** - 관리자가 매번 상세 화면을 열지 않아도 응답의 내용을 판단할 수 있게 합니다.
3. **응답자와 제출 시각은 보조 정보로 구분합니다.** - 중요한 답변 내용과 메타 정보가 같은 강도로 경쟁하지 않게 합니다.
4. **행을 클릭하면 상세 모달을 엽니다.** - 전체 답변과 문항별 내용을 확인할 때 현재 목록의 검색·필터 상태를 잃지 않게 합니다.
5. **기존 관리자 화면의 외곽 구조를 그대로 유지합니다.** - 새로운 화면처럼 보이지 않도록 GNB, 배경, 필터 위치와 페이지네이션 구조를 보존합니다.
## 적용한 디자인 원칙
- 핵심 과업 우선 원칙: “응답 읽기”를 표의 첫 번째 시각적 우선순위로 설정했습니다.
- 정보 위계 원칙: 답변 내용, 응답자 정보, 제출 시각을 서로 다른 강조 수준으로 구분합니다.
- 컨테이너 그룹화 원칙: 검색·필터, 응답 목록, 페이지네이션을 역할별로 묶습니다.
- 기존 플로우 충실도 원칙: 기존 페이지의 GNB, 배경, 필터, 표, 모달 구조를 모두 유지합니다.
## 연결 플로우
[설문 응답 목록] → [응답 행 클릭] → [응답 상세 모달]
## 미해결 의문점
- ❓ 상세 모달에서 응답을 관리자가 수정할 수 있는지 정바카라이 정해지지 않았습니다. 이번 프로토타입에서는 읽기 전용으로 가정합니다.
? 위 전략을 검토해 주세요. 승인 전에는 구현으로 넘어가지 않습니다.
- ✅ 승인 → 프로토타입 구현 시작
- ? 수정 → 요청사항을 반영해 전략 다시 작성
- ❌ 반려 → 기획 또는 요구사항 확인 단계로 회귀
Phase 6 — 프로토타입 구현
* 구현 작업 진행
Phase 7. 실행 링크 공유
##개발 서버 실행:
```bash
pnpm dev
##프로토타입 진입 URL:
http://127.0.0.0:0000/test/prototype/********
##확인할 플로우:
1. 설문 응답 목록을 확인합니다.
2. 긴 주관식 응답이 표 안에서 줄바꿈 되는지 확인합니다.
3. 응답 행을 클릭합니다.
4. 응답 상세 모달에서 전체 문항과 답변을 확인합니다.
5. 모달을 닫았을 때 기존 목록과 필터 상태가 유지되는지 확인합니다.
Phase 8. 캡처와 Google Drive 적재
* Phase 7 완료 후, 자동으로 프로토타입 주요 화면 캡처 후 Google Drive에 저장
Phase 9. Notion 사용 기록 적재
* Phase 7 완료 후, 자동으로 기획 내용 및 UX 전략을 Notion DB에 저장
실무 사례
이렇게 만들어진 UI 프로토타입 스킬은 5월에 있었던 제품실 AX 해커톤을 시작으로, 지금까지 다양한 프로젝트에서 쓰이고 있어요.
사례 1
수강환경 앱 론칭 직후 앱 설치를 독려하는 바텀시트를 만들었어요. 디자인 시스템에 등록된 아이콘을 맥락에 맞게 사용했고, 적용할 지면에 따라 라이트/다크모드 분기까지 잘 구현됐어요.
사례 2
AI 기술을 통해 사용자의 이력서를 첨삭해 주는 기능을 만들었어요. 수정이 필요한 영역에 순번을 매겨 하이라이팅 해주고, 해당 영역을 클릭하면 연관된 리뷰 카드가 활성화돼요. 복잡한 마이크로 인터랙션도 프로토타입을 통해 빠르게 구현했어요.
사례 3
동기부여를 위한 학습 대시보드를 만들었어요. 처음 만들어진 초안은 구조 자체는 괜찮았지만 부분적으로 가독성이 떨어졌어요. 부분 수정을 통해 강조가 필요한 영역과 그렇지 않은 영역의 위계를 조정했고, 결과적으로 훨씬 깔끔한 형태의 최종안이 나왔어요.
마치며 - 말로 전하던 가치를 글로 남겨야 할 때
세상에 틀린 디자인은 없잖아요. 비즈니스의 목표, 고객의 상태, 제품의 맥락, 주어진 시간에 맞춰 ‘가장 적절한 디자인’을 찾을 뿐이죠. 그런 작업을 AI가 잘할 수 있으려면 생각보다 많은 것들이 정의되어야 하고, 또 잘 저장되어있어야 해요. 이른바 ‘암묵지’에 해당하는 것들이죠.
UI 프로토타입 스킬을 통해 ‘말로만 떠돌던 가치를 글로 옮기기 시작’했다는 점에서 특히 의미가 깊어요. 이제는 개인의 경험과 역량에 의존하고 있던, 정해지지 않은 것들에 대한 명문화가 중요해지는 시점인 것 같아요. 전보다 더 많이 ‘가치’에 대한 추상적인 이야기를 나누게 될지도 모르겠어요. (좋은 디자인이란 무엇인가, 우리 제품에서 지켜야 할 가장 중요한 경험은 무엇인가, …)
이제 디자인을 만들어내는 건 누구나 다 할 수 있는 일이 되었죠. 생산이 쉬워진 시대에서 ‘좋은 문제를 찾는 감각’이 무엇보다도 중요해지고 있어요. 모두가 예리하게 감각을 세워 좋은 문제를 발견하고, 그 문제를 해결하기 위한 최적의 솔루션을 찾는 과정에서 UI 프로토타입 스킬이 부디 실질적인 도움이 되길 바라요.
by. 곽진, 고우정 Product Engineer