코드보다 UI 시안 이미지를 먼저 — 이미지-퍼스트 웹디자인 7단계 워크플로우

랜딩 페이지 하나를 에이전트에게 맡기는 과정은 대체로 비슷하게 흘러갑니다. 요구사항을 정리해 넣으면 코드가 나옵니다. 빌드도 되고 반응형도 대충 맞습니다. 그 상태로 클라이언트에게 보여주거나 다음 날 다시 열어보면 같은 말이 나옵니다. “작동은 하는데 느낌이 좀 다른데요.”

문제는 그다음입니다. 이 시점의 결과물은 이미 컴포넌트로 쪼개져 있고, 스타일이 여러 파일에 흩어져 있고, 브레이크포인트 분기가 들어가 있고, 운이 나쁘면 스크롤 애니메이션까지 얹혀 있습니다. 여기서 “히어로를 좌측 정렬로 바꾸고 여백 리듬을 다시 잡자”는 결정을 내리면, 바꿔야 하는 건 판단 한 줄인데 손대야 하는 건 파일 열 개입니다. 그래서 대개는 안 바꿉니다. 고치는 비용이 아쉬움보다 커지는 순간 결과물의 품질은 거기서 고정됩니다.

이 글에서 정리할 워크플로우는 “AI가 디자인을 못 한다”를 해결하려는 게 아닙니다. 디자인 의사결정을 코드보다 앞으로 당기는 순서 조정입니다. 코드를 짜기 전에 화면 시안을 이미지로 먼저 만들어 눈으로 확정하고, 확정된 이미지를 구현 지시서로 넘기는 방식입니다. 방향을 뒤집는 비용이 이미지 재생성 수준으로 떨어지기 때문에, 뒤집는 결정을 실제로 내릴 수 있게 됩니다.

미리 밝혀 둡니다. 이 순서는 디자인하는AI 채널의 19분짜리 가이드 영상에서 제시된 구성을 정리한 것입니다. 저희가 실제 프로젝트를 이 7단계로 처음부터 끝까지 돌려보고 소요 시간과 품질을 측정한 기록은 아직 없습니다. 아래 단계 구분과 도구 조합은 공개된 자료 기준이고, 한계 지적과 적용 판단은 저희 해석입니다. 그래서 검증완료 배지를 붙이지 않았습니다.

왜 이미지가 먼저인가

말로만 시켜서 코드를 뽑는 이른바 바이브 코딩의 결과물은 대체로 예상 범위 안에 들어옵니다. 가운데 정렬 히어로, 특징 카드 3단, 회색 배경 CTA. 영어권에서 이런 결과물을 slop이라고 부릅니다. 모델이 확률 높은 선택을 하기 때문이고, 디자인에서 확률이 높은 선택은 곧 흔한 선택이기 때문입니다.

이걸 고치려고 보통 형용사를 덧붙입니다. “좀 더 세련되게”, “좀 더 프리미엄하게”. 그런데 형용사는 거의 아무 정보도 전달하지 못합니다. 모델 입장에서 “세련되게”는 학습 데이터의 평균값을 한 번 더 꺼내라는 말에 가깝습니다. 시안 이미지를 먼저 만드는 것의 진짜 효용은 여기 있습니다. 지시가 “만들어라”에서 “이것에 맞춰라”로 바뀝니다. 형용사 대신 대조군을 주는 셈입니다.

두 번째 효용은 재작업 비용입니다. 같은 결정을 어느 시점에 뒤집느냐에 따라 되돌려야 하는 산출물의 양이 달라집니다.

방향을 바꾸는 시점	되돌려야 하는 것
시안 이미지 단계	이미지 파일 한 장. 프롬프트 고쳐서 다시 생성
정적 구현 직후	마크업과 스타일. 섹션 단위 재작업
애니메이션·반응형까지 얹은 뒤	컴포넌트 구조, 모션 타임라인, 브레이크포인트 분기. 사실상 재시작

디자인 컨펌을 이미지 단계에서 받아 두면, 아래 두 줄에서 벌어질 일이 위 한 줄로 내려옵니다. 클라이언트 작업이라면 효과가 더 큽니다. 코드 없이 시안만 빠르게 뽑아 컨펌을 받고, 확정된 뒤에 구현에 들어가는 순서가 됩니다.

7단계 전체 그림

영상이 제시하는 흐름은 다음과 같습니다. 타임스탬프는 원본 영상의 챕터 기준입니다.

단계	하는 일	주로 쓰는 도구	챕터
1	UI 시안 이미지 생성	ChatGPT Images 등 이미지 생성기	02:36
2	시안 생성 프롬프트 다듬기	레퍼런스 보드 / 무드 지정	02:57
3	Taste Skill로 품질 올리기	Taste Skill	04:21
4	프론트엔드 구현	Codex 데스크탑 앱	06:50
5	디자인 세부 수정	Codex	11:23
6	애니메이션 추가	Codex	14:29
7	커스텀 도메인 배포	Hostinger 등 호스팅	16:30

이 표를 보면 4번 이후는 평소 하던 작업과 크게 다르지 않습니다. 실질적으로 새로운 건 1~3단계이고, 이 세 단계가 전체 결과물의 인상을 결정합니다. 4~7단계는 그 결정을 코드로 옮기고 실제 주소에 올리는 과정입니다.

1~3단계: 시안을 눈으로 확정하기

시안 이미지 생성에서 결과를 가르는 건 프롬프트 구성입니다. 자료에서 강조하는 핵심은 레퍼런스와 무드를 명시적으로 지정하는 것입니다. “모던한 SaaS 랜딩” 같은 지시로는 다시 평균값이 나옵니다.

아래는 영상에 나온 원문 프롬프트가 아니라, 지정해야 할 항목을 빠뜨리지 않기 위한 틀입니다. 각 칸을 실제 값으로 채워서 쓰는 용도입니다.

[화면] 데스크탑 1440px 폭, 랜딩 페이지 전체 스크롤 시안 1장
[제품] (무엇을 파는 사이트인지 한 문장)
[타깃] (누가 보는가 — 이 한 줄이 밀도와 톤을 바꿉니다)
[무드] (형용사 대신 구체적 레퍼런스로: 어떤 사이트 계열, 어떤 인쇄물 느낌)
[컬러] 주조색 / 배경 / 액센트를 hex로 고정
[타이포] 헤드라인 서체 계열, 본문 서체 계열, 크기 대비 정도
[섹션] 히어로 / 소셜프루프 / 기능 3블록 / 요금 / FAQ / CTA / 푸터
[여백] 섹션 간 여백을 넉넉히, 콘텐츠 폭은 화면보다 좁게
[금지] 보라색 그라데이션, 이모지 아이콘, 가운데 정렬 일변도

마지막 [금지] 줄이 실무에서 은근히 효과가 큽니다. 원하는 걸 묘사하는 것보다 흔하게 나오는 클리셰를 빼라고 지정하는 편이 평균값에서 벗어나기 쉽습니다.

3단계의 Taste Skill은 이 워크플로우의 차별화 지점으로 소개되는 부분입니다. 에이전트가 프론트엔드를 만들 때 참고할 레이아웃·타이포·모션·여백 기준을 문서로 주입하는 오픈소스 스킬이고, MIT 라이선스입니다. 설치는 한 줄입니다.

# 프론트엔드 스킬만 설치 (기본값은 v2 = 실험 버전)
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

기본값이 실험 단계인 v2를 가리킨다는 점은 알고 설치하는 게 좋습니다. 안정적인 쪽을 원하면 design-taste-frontend-v1을 명시해야 합니다. 스킬 자체의 구성과 주의사항은 Taste Skill 정리 글에 따로 적어 두었습니다.

4~6단계: 이미지를 구현 지시서로 쓰기

확정된 시안 이미지를 Codex 데스크탑 앱에 넘겨 코드로 구현하는 단계입니다. 여기서 중요한 건 이미지에 담기지 않은 정보를 함께 적어주는 것입니다. 정지 이미지 한 장은 레이아웃과 색과 타이포는 전달하지만, 나머지는 전달하지 못합니다.

첨부한 시안 이미지를 그대로 구현해 주세요. 아래는 이미지에 없는 요구사항입니다.

- 정확도 우선순위: 여백 리듬 > 타이포 크기 대비 > 색 > 그 외
- 반응형: 1440 / 768 / 375 세 폭. 모바일에서 3단 카드는 세로 스택
- 상태: 버튼과 링크의 hover / focus-visible / disabled 를 모두 정의
- 콘텐츠 가변: 제목이 두 줄이 돼도 레이아웃이 깨지지 않게
- 색 대비는 WCAG AA 기준을 만족할 것
- 임의로 섹션을 추가하거나 순서를 바꾸지 말 것

마지막 줄이 필요한 이유는, 지시가 비어 있는 자리를 에이전트가 자기 기본값으로 채우기 때문입니다. 시안에 없던 “신뢰도 배지 3종” 같은 섹션이 슬쩍 생겨 있는 경우가 흔합니다.

56단계는 코드 상태에서 세부를 다듬고 모션을 얹는 구간입니다. 자료에서도 이 구간은 **한 번에 끝나지 않고 46단계를 반복해야 한다**고 명시합니다. 이미지와 실제 구현 사이의 간극을 메우는 데 드는 시간이 여기 몰려 있다고 보는 편이 맞습니다.

7단계: 배포

마지막은 커스텀 도메인에 올리는 단계입니다. 원본 영상은 Hostinger를 사용하는데, 해당 링크는 제휴 링크로 표기돼 있습니다. 배포 대상은 워크플로우의 본질과 무관하게 교체 가능한 부분이므로, 정적 사이트라면 익숙한 호스팅을 쓰면 됩니다. 이 단계에서 워크플로우가 요구하는 건 특정 업체가 아니라 “실제 도메인에 올려서 끝을 본다”는 것 하나입니다.

이미지가 말해주지 않는 것

이 워크플로우의 가장 정직한 한계는 자료에도 리스크로 적혀 있습니다. 이미지와 실제 구현 사이에는 간극이 있고, 반응형과 상호작용은 이미지로 표현되지 않습니다. 구체적으로 시안 한 장이 침묵하는 항목은 다음과 같습니다.

• 반응형 — 데스크탑 시안만 예쁘게 나오고, 모바일에서 어떻게 접힐지는 아무도 결정하지 않은 상태입니다.
• 상태 변화 — hover, focus, 로딩, 빈 상태, 에러 화면. 실제 사용 시간의 상당 부분이 여기에 있는데 시안에는 없습니다.
• 콘텐츠 가변성 — 시안 속 제목은 항상 한 줄로 예쁘게 떨어집니다. 실제 데이터는 그렇지 않습니다.
• 성능 — 이미지 속 유리 질감, 큰 배경, 복잡한 그림자는 생성 비용이 0이지만 구현 비용은 0이 아닙니다.
• 접근성 — 대비가 부족한 색 조합이 이미지에서는 오히려 근사해 보입니다.

그래서 실무에 넣을 때는 시안을 데스크탑 한 장으로 끝내지 말고 모바일 폭 시안을 함께 뽑아 두는 편이 낫습니다. 컨펌 대상에 모바일이 포함되면, 위 목록 중 가장 비싼 항목 하나가 이미지 단계로 내려옵니다.

점수: 7.9

좋은 점

• 순서를 바꾸는 것만으로 효과가 나오는 방식이라 도입 장벽이 낮습니다. 새 SaaS를 결제하거나 파이프라인을 갈아엎을 필요가 없습니다.
• 컨펌 시점이 앞으로 당겨집니다. 클라이언트 작업에서 “다 만들어놓고 뒤집히는” 최악의 시나리오 확률이 줄어듭니다.
• 지시가 형용사에서 이미지로 바뀝니다. 에이전트가 헤맬 여지가 줄고, 사람 사이의 커뮤니케이션에서도 같은 효과가 납니다.
• 각 단계의 도구가 서로 갈아 끼울 수 있습니다. 이미지 생성기도, 코딩 에이전트도, 호스팅도 대체 가능하고 순서만 남습니다.

아쉬운 점

• 이미지와 구현의 간극이 그대로 남습니다. 반응형·상태·가변 콘텐츠는 결국 4~6단계 반복으로 해결해야 하고, 이 반복 비용이 앞단에서 아낀 비용을 얼마나 상쇄하는지는 실측해 봐야 압니다.
• 시안 프롬프트를 잘 쓰는 것 자체가 별도의 기술입니다. 이 단계를 대충 하면 예쁜 평균값 이미지를 얻고, 그걸 정확히 구현하는 데 시간을 쓰게 됩니다.
• 이미 디자인 시스템이 있는 프로젝트와 잘 맞지 않습니다. 토큰과 컴포넌트가 정해진 상태에서 자유롭게 생성된 시안은 시스템 밖으로 나가기 쉽고, 그걸 되돌리는 작업이 추가됩니다.
• 대시보드처럼 데이터 밀도와 상태 전이가 본질인 화면에서는 시안 이미지가 사실상 거짓말을 합니다. 실제 데이터가 들어가는 순간 레이아웃 판단이 대부분 무효가 됩니다.
• 원본 자료가 영상 한 편이고 제휴 링크가 포함돼 있습니다. 단계 구분은 참고하되 도구 선택까지 그대로 따를 이유는 없습니다.

이럴 때 쓰세요: 랜딩·브로슈어·포트폴리오처럼 첫인상이 성패를 가르는 페이지를 자주 만들고, 만들어 놓은 뒤에 방향이 뒤집혀 재작업한 경험이 있다면 다음 한 건에 이 순서를 적용해 볼 만합니다.

정리

이 워크플로우가 파는 건 새로운 도구가 아니라 순서입니다. 그리고 순서를 바꿔서 얻는 이득은 딱 하나로 요약됩니다. 틀렸다는 걸 싸게 알게 된다는 것. 코드 없이 이미지 단계에서 방향이 틀렸음을 확인하면 다시 만드는 데 프롬프트 한 번이면 되지만, 애니메이션까지 얹은 뒤에 같은 사실을 알면 그건 재시작입니다.

다만 이 워크플로우를 채택한다고 해서 구현 난이도가 사라지지는 않습니다. 이미지가 침묵하는 항목들, 그러니까 반응형과 상태와 가변 콘텐츠는 여전히 손으로 결정해야 합니다. 이미지-퍼스트는 그 결정을 없애는 게 아니라 결정의 순서를 정리해 주는 것에 가깝습니다.

저희도 아직 이 7단계를 끝까지 돌려본 기록이 없어서, 다음 랜딩 작업 하나를 이 순서대로 배포까지 진행해 볼 계획입니다. 소요 시간과 4~6단계 반복 횟수를 기록해 두면 “앞단에서 아낀 만큼 뒤에서 쓰는가”라는 질문에 숫자로 답할 수 있을 것 같습니다. 그 결과는 별도 글로 남기겠습니다.