AI 보조 개발22 분 읽기

하이엔드 UI 프롬프트 3개를 전문 공개합니다 — 그리고 코드에 실제로 남은 규칙은 절반이었습니다

iOS·안드로이드·게임 UI를 뽑아내는 프롬프트 3개를 통째로 공개합니다. 그리고 그 규칙들이 실제 출하 코드에 얼마나 남았는지 grep으로 셌습니다. 잘 지켜진 규칙 3개, 거의 무시된 규칙 3개가 나왔습니다.

#prompts#design#ai-workflow#first-principles#reality-check
왼쪽은 프롬프트가 요구한 규칙 목록, 오른쪽은 출하된 코드를 grep 한 실제 채택 수치. continuous 코너 122개 파일, 햅틱 29개 파일은 살아남았고 systemGroupedBackground 1개 파일, redacted placeholder 2개 파일은 사실상 무시됐다
왼쪽은 제가 시킨 것, 오른쪽은 코드가 실제로 지킨 것입니다.

AI에게 UI를 시키면 대체로 같은 것이 나옵니다. 시스템 파랑 버튼, 흰 배경, 플레인 리스트, 카드마다 박힌 회색 구분선. 기능은 되는데 아무도 쓰고 싶어 하지 않는 화면입니다.

그래서 저는 "예쁘게 만들어줘" 대신, 금지 목록이 절반을 차지하는 프롬프트를 씁니다. 아래 세 개가 iOS·안드로이드·게임 화면을 뽑을 때 실제로 붙여 넣는 전문입니다. 먼저 그대로 공개하고, 그다음이 이 글의 본론입니다 — 그 규칙들이 출하된 코드에 정말 남아 있는지 grep으로 셌습니다.

먼저 하나 물어보겠습니다. 당신이 지난달 AI에게 시킨 UI 지시문 중, 실제 저장소에 흔적이 남은 규칙이 몇 개입니까? 세어본 적 있습니까?

프롬프트 1 — iOS / SwiftUI

[역할]
너는 Apple의 Design Team 출신이자 토스(Toss), Airbnb, Revolut 수준의 프리미엄 iOS 앱을 제작하는
Senior iOS Engineer & Product Designer다. AI 특유의 '투박한 템플릿 느낌(과도한 원색, 흔한 카드 레이아웃,
조잡한 그라데이션)'을 완전히 배제하고, Apple Human Interface Guidelines(HIG)를 완벽히 준수한
하이엔드 SwiftUI UI를 작성해라.
 
[목표 구현]
- 대상 화면: 고품질화 고도화를 1원칙으로 자율 판정
- 핵심 컨셉: 고품질화 고도화를 1원칙으로 자율 판정
 
[제1원칙 기반 iOS 디자인 시스템 (Strict Rules)]
1. Typography & Hierarchy (시각적 계층의 원칙):
   - SF Pro 폰트의 가독성을 최대로 활용하고, Large Title과 Footnote/Caption 간의
     시각적 체급 차이를 명확히 둘 것.
   - 불필요한 구획선(Divider)을 없애고, 넉넉한 여백(Padding 20pt~24pt)과
     타이포그래피 크기 차이로만 구역을 구분할 것.
 
2. Depth & Materials (재질과 깊이감의 원칙):
   - Background: Pure White 대신 iOS System Background (Color(.systemGroupedBackground))를
     활용해 정교한 레이어링을 구현할 것.
   - Glassmorphism & Blur: 애플 특유의 Ultra Thin Material (.ultraThinMaterial)과
     미세한 Stroke(Color.white.opacity(0.2))를 조합해 깊이감 연출.
   - Shadow: 어두운 Drop Shadow 금지. 아주 은은한 Y축 Offset Shadow 또는 Material 레이어로 구분할 것.
 
3. Motion & Micro-interaction (iOS 전용 감성):
   - 버튼 및 카드 터치 시 .scaleEffect와 애플 특유의
     .spring(response: 0.3, dampingFraction: 0.7) 애니메이션 적용.
   - Haptic Feedback (UIImpactFeedbackGenerator) 호출 구문을 포함하여 손맛을 살릴 것.
   - 이미지 영역: AsyncImage 활용, 로딩 시 은은한 Shimmer Redacted 효과(.redacted(reason: .placeholder))
     및 Continuous Rounded Corner(.clipShape(RoundedRectangle(cornerRadius: 16, style: .continuous))) 적용.
   - State Design: Empty State, Loading, Error 상태에 대한 시각적 분기 포함.
 
[출력 형식]
- SwiftUI 코드로 작성할 것.
- 가독성과 재사용성을 위해 View를 세부 컴포넌트(Extract Subview)로 깔끔하게 분리할 것.
- Xcode에서 즉시 확인 가능하도록 #Preview 코드를 포함할 것.

프롬프트 2 — 안드로이드 / Jetpack Compose

[역할]
너는 토스(Toss), 애플(Apple), 리볼루트(Revolut) 수준의 하이엔드 UI/UX를 설계하는
Senior Android Dev & Product Designer다. AI 특유의 '투박하고 전형적인 템플릿 느낌
(과도한 원색, 빽빽한 카드리스트, 단순한 둥근 모서리)'을 완전히 제거하고,
실무 출시 수준의 고도화된 안드로이드 UI를 작성해라.
 
[목표 구현]
- 대상 화면: 고품질화 고도화를 1원칙으로 자율 판정
- 핵심 컨셉: 고품질화 고도화를 1원칙으로 자율 판정
 
[제1원칙 기반 디자인 시스템 (Strict Rules)]
1. Layout & Space (여백의 원칙):
   - 컴포넌트 간 여백을 넉넉하게 확보(Padding 20dp~24dp)하여 시각적 답답함을 없앨 것.
   - 불필요한 테두리(Border)나 Divider를 남발하지 말고, 여백과 폰트 크기 차이만으로 구역을 구분할 것.
 
2. Color & Depth (깊이감의 원칙):
   - Background: Pure White(#FFFFFF) 대신 Off-White(#F8F9FA 또는 #F5F5F7)를 적용해 눈의 피로도를 낮출 것.
   - Shadow: 투박한 Drop Shadow 금지. 아주 은은한 그림자(Blur) 또는 1dp의 미세한
     Muted Border(#E5E5EA)로 레이어를 레이어링할 것.
   - Text Color: Pure Black(#000000) 금지. Primary는 #111111, Secondary는 #8E8E93 사용.
 
3. Visual & Micro-interaction (비주얼/동적 고도화):
   - 모든 클릭 가능 요소에 Ripple Effect 및 미세한 스케일(Scale) 축소/확대 애니메이션 포함.
   - 이미지 영역: 단순 사각형이 아닌 Smooth Rounded Corner 적용, Coil 연동 구조 및
     고급스러운 비정형 Shimmer Loading 효과 포함.
   - 데이터 없음(Empty State) 및 로딩 중(Loading State) 시각 디자인 포함.
 
[출력 형식]
- Android Jetpack Compose 코드로 작성할 것.
- 가독성과 재사용성을 위해 UI 컴포넌트를 기능별로 깔끔하게 분리할 것.
- Android Studio에서 바로 확인할 수 있도록 @Preview 코드를 포함할 것.

프롬프트 3 — 게임 UI / 에셋

[역할]
너는 슈퍼셀(Supercell), 라이엇 게임즈(Riot Games), 넥슨(Nexon) 수준의 모바일/웹 게임을 제작하는
Lead Game UI/UX Designer 겸 Senior Game Developer다. AI 특유의 '유치하고 촌스러운 템플릿 느낌
(흔한 원색 버튼, 가독성 떨어지는 화려함만 강조된 인터페이스, 어색한 AI 캐릭터 에셋)'을 완전히 배제하고,
몰입감 높은 고품질 게임 UI와 에셋 생성 가이드를 제시해라.
 
[목표 구현]
- 게임 장르/컨셉: 고품질화 고도화를 1원칙으로 자율 판정
- 대상 화면: 고품질화 고도화를 1원칙으로 자율 판정
- 프론트엔드/엔진 스택: 고품질화 고도화를 1원칙으로 자율 판정
 
[제1원칙 기반 게임 UI/UX 디자인 시스템 (Strict Rules)]
1. UI Layout & Readability (가독성과 몰입감의 원칙):
   - 게임 배경을 과도하게 가리지 않는 효율적인 HUD 및 모듈형 팝업 구조 설계.
   - 텍스트 가독성을 위해 베벨/엠보스가 과한 양산형 폰트를 피하고, 게임 컨셉에 맞되
     가독성이 높은 스탠다드 폰트 체계와 미세한 Drop Shadow/Stroke 적용.
   - 불필요한 UI 요소를 최소화하고, 게임 핵심 요소(재화, 캐릭터, 시작 버튼)로 시선이
     자연스럽게 이동하도록 시각적 위계(Visual Hierarchy) 구축.
 
2. Color, Depth & Texture (재질감과 톤앤매너):
   - 원색 위주의 유치한 스키오모피즘을 지양하고, Modern Flat과
     Subtle Textures(금속, 유리, 빛 반사 등)가 조화된 세련된 디자인 연출.
   - Primary/Secondary/Accent 컬러를 7:2:1 비율로 엄격히 제한하여 과도한 색상 혼란 방지.
 
3. Micro-interaction & Juicy Feedback (타격감과 손맛):
   - 버튼 클릭 시 단순 색상 변화가 아닌, Scale Down(0.95x), Spring Animation, Glow Effect 적용.
   - 재화 획득, 아이템 장착 시의 파티클/광원 애니메이션 및 Haptic Feedback 구문 포함.
   - Screen State(로딩 중, 승리/패배, 보상 획득) 디자인 연출 포함.
 
4. ImageGen & Game Asset Generation Strategy:
   - 게임에 필요한 배경, 캐릭터 일러스트, 아이콘, 버튼 테두리 등의 비주얼 에셋에 대해
     Image Generator 툴을 활용해 구체적으로 지시할 것.
   - [ImageGen 프롬프트 작성 지침]:
     * AI 티 나는 기형적인 손가락, 비대칭 얼굴, 전형적인 3D 렌더링 스타일 엄격히 금지.
     * [컨셉/장르]에 맞춰 'Unreal Engine 5 Render', 'Stylized Concept Art', 'Vector Game Icon',
       'Crisp Alpha PNG' 등의 기법을 포함한 극도로 상세한 에셋 프롬프트를 작성할 것.
     * 에셋은 UI 위에서 배경 레이어, 캐릭터 포트레이트, 아이콘 Slot 형태로
       자연스럽게 조화되도록 코드를 작성할 것.
 
[출력 요구사항]
1. [Game Asset ImageGen Prompts]: 메인 배경, 핵심 아이콘, 캐릭터/카드 일러스트 생성용 프롬프트를
   개별적으로 구분하여 작성.
2. [UI Code Implementation]: 지정한 스택 기반의 Clean Code 작성(컴포넌트 분리 필수),
   바로 확인 가능한 Preview 또는 실행 가능한 컴포넌트 구조 포함.

왜 이렇게 썼나 — 금지 목록이 본체입니다

세 프롬프트의 공통 구조는 같습니다. 역할 → 금지 → 수치 → 출력 형식. 그중 실제로 결과를 바꾸는 건 두 번째입니다.

  • 금지를 먼저 쓴다. "고급스럽게"는 측정 불가입니다. "Pure Black(#000000) 금지", "어두운 Drop Shadow 금지", "베벨 과한 양산형 폰트 금지"는 결과물에서 바로 확인됩니다. 모델은 좋은 것을 상상하는 것보다 나쁜 것을 피하는 것을 훨씬 잘합니다.
  • 수치를 준다. 20pt~24pt, #8E8E93, 0.95x, 7:2:1. 숫자가 없으면 매번 다른 화면이 나오고, 앱 30개를 굴리면 그게 곧 브랜드 붕괴입니다.
  • 상태 분기를 강제한다. Empty / Loading / Error를 프롬프트에 안 박으면 AI는 행복한 경로만 그립니다. 실제 앱에서 사용자가 처음 보는 화면은 대부분 빈 화면인데도요.
  • "1원칙으로 자율 판정"을 남겨둔다. 화면 종류와 컨셉을 제가 고정하지 않은 이유는, 대상이 매번 다르기 때문입니다. 대신 판정 기준을 한 문장으로 못 박습니다. 이 강제 질문 방식은 1원칙 프롬프트 글에서 다뤘습니다.

그래서 코드에 남았나 — grep으로 셌습니다

여기부터가 이 글을 쓴 이유입니다. 프롬프트 공개 글은 보통 여기서 끝납니다. "이렇게 쓰면 좋아요." 증거는 없습니다.

그래서 저는 인과를 주장하는 대신 지문(fingerprint)을 셌습니다. 프롬프트가 지목한 API 이름은 전부 grep 가능한 문자열입니다. Swift 파일 2,260개, Kotlin 파일 243개를 훑었습니다.

iOS(SwiftUI) — 살아남은 규칙

프롬프트가 시킨 것 코드 실측
RoundedRectangle(style: .continuous) 122개 파일 / 313곳
UIImpactFeedbackGenerator 햅틱 29개 파일
.ultraThinMaterial 33개 파일 / 41곳 (다른 Material까지 85곳)
AsyncImage 29개 파일

iOS — 사실상 무시된 규칙

프롬프트가 시킨 것 코드 실측
Color(.systemGroupedBackground) 배경 1개 파일
.redacted(reason: .placeholder) 셔머 2개 파일
.spring(response: 0.3, dampingFraction: 0.7) 정확히 2개 파일 (spring 자체는 17개 파일)

안드로이드(Compose) — 거의 통째로 무시

Compose 파일 56개를 뒤졌더니 rememberRipple 0곳, Modifier.scale 0곳, shimmer 0곳, Coil 0곳. 살아남은 건 animateFloatAsState 2개 파일과 indication = null 한 줄뿐이었습니다.

게임(웹) — HUD·글래스 규칙은 남았습니다(backdrop-filter 16곳, navigator.vibrate 햅틱, 스케일 0.95). 반면 프롬프트 4번 항목 ImageGen 에셋 전략은 실전에서 한 번도 안 썼습니다. 출하된 게임 4개의 스프라이트 에셋은 0개입니다. 전부 도형·캔버스로 그렸습니다.

이 편차를 어떻게 읽어야 하나

세 가지로 갈립니다. 그리고 셋 다 프롬프트를 고쳐야 한다는 뜻은 아닙니다.

  1. 모양 규칙은 살아남는다. 코너·햅틱·머티리얼처럼 한 줄로 끝나고 지역적인 규칙은 리팩터링을 견딥니다. 313곳이 그 증거입니다.
  2. 전역 규칙은 브랜드에 밀려난다. systemGroupedBackground가 1개 파일뿐인 건 실패가 아니라 의도적 이탈입니다. 앱마다 브랜드 accent와 ambient 배경 토큰을 따로 쓰기 때문에, 시스템 회색 배경은 두 번째 패스에서 전부 교체됐습니다. 스프링 값이 0.55/0.86, 0.28/0.78로 흩어진 것도 같은 이유입니다 — 화면 성격에 맞춰 손으로 튜닝했습니다.
  3. 다른 스택으로는 이식되지 않는다. 안드로이드 결과가 이걸 정확히 보여줍니다. 두 앱은 iOS를 이식한 것이고, 프롬프트는 새로 그리는 화면에만 힘을 씁니다. 프롬프트는 포팅 작업에 아무 영향을 주지 못했습니다.

여기서 당신이라면 어떻게 하겠습니까? 준수율을 올리려고 프롬프트를 더 조이겠습니까, 아니면 지켜지지 않는 규칙을 프롬프트에서 빼겠습니까? 저는 후자 쪽으로 기울었습니다. 다만 그 판단은 grep을 돌려본 다음에 나왔지, 감으로 나오지 않았습니다.

디자인에 실제로 쓴 스킬

프롬프트 하나로 끝나지 않습니다. 붙여 쓴 것들:

  • frontend-design 스킬 — "템플릿처럼 보이지 않는 선택"을 강제하는 심미 방향·타이포 가이드. 프롬프트가 규칙이면 이건 취향의 축입니다.
  • 1원칙 강제 질문 — "진짜 의미 있는 숫자 하나가 뭐냐"를 디자인에도 겁니다. 이 글의 grep 자체가 그 산물입니다.
  • 재사용 프롬프트·스킬 라이브러리 — 간결 모드, YAGNI 모드, 자율진행 신호. 에이전트 길들이기 글에 정리했습니다.
  • 일괄 재디자인 오케스트레이션 — 앱 30여 개를 한 패스로 갈아엎을 때의 절차는 한방 재디자인 글에 있습니다.
  • 봇으로 플레이시켜 검증 — 게임 UI는 눈으로 보면 다 예쁩니다. 헤드리스 브라우저로 끝까지 주행시켜야 45분 지점에서 죽는 걸 잡습니다.

솔직한 부분 — MVP 바는 넘고, 상용 바는 못 넘습니다

이 프롬프트들이 뽑아주는 결과물의 실제 체급은 이렇습니다.

넘습니다. 첫인상, 스크린샷, 데모, 심사 통과. 시스템 파랑·플레인 리스트 화면과는 확실히 다릅니다. 앱스토어 심사도, 사용자가 첫 3초에 이탈하지 않는 것도 이 선에서 해결됩니다. MVP를 빨리 세우는 용도로는 가성비가 아주 좋습니다.

못 넘습니다. 상용 완성도는 프롬프트가 못 만드는 곳에서 갈립니다.

  • 접근성. Dynamic Type 최대 크기에서 레이아웃이 깨지는지, VoiceOver 순서가 맞는지 프롬프트는 신경 쓰지 않습니다.
  • 성능. 머티리얼과 블러를 리스트 셀마다 깔면 구형 기기에서 스크롤이 끊깁니다. AI는 그걸 예쁘다고 더 깔아줍니다.
  • 일관성. 화면 단위로 생성하면 화면 단위로 예쁩니다. 앱 전체를 관통하는 스페이싱 스케일과 토큰은 사람이 정해서 고정해야 합니다.
  • 데이터가 이상할 때. 제목이 40자일 때, 이미지가 404일 때, 목록이 1개일 때 — 생성물은 대체로 깨집니다.

정리하면, 디자인의 첫 70%를 몇 분에 끝내주는 도구이고 나머지 30%는 여전히 손입니다. 그런데 그 30%가 상용과 MVP를 가릅니다.

자가진단 3개

  1. 당신의 UI 프롬프트에서 금지 항목이 몇 개입니까? 0개면 그건 지시문이 아니라 소원입니다.
  2. 프롬프트가 지목한 API 이름을 저장소에 grep 하면 몇 건 나옵니까? 0건이면 그 규칙은 존재하지 않는 규칙입니다.
  3. Empty·Loading·Error 화면이 실제로 스크린샷으로 남아 있습니까, 아니면 행복한 경로만 찍혀 있습니까?

적용된 결과물

이 규칙들이 실제로 들어간 출하물입니다. 취향 판단은 직접 보시는 게 맞다고 생각합니다.

iOS(App Store, 라이브 28개 중 일부)

Google Play

웹 게임 / 웹앱

마지막으로

프롬프트를 공개하는 건 쉽습니다. 어려운 건 그 프롬프트가 실제로 코드에 남았는지 확인하는 것입니다. 저는 이번에 처음 세어봤고, 절반은 안 남아 있었습니다. 그중 일부는 제 판단으로 버린 것이고, 일부는 그냥 잊힌 것이었습니다. 둘을 구분하려면 숫자가 필요합니다.

지금 딱 하나만 해보세요. 당신의 UI 프롬프트에서 API 이름 하나를 골라, 저장소에 grep -rl 을 걸어보십시오. 몇 개 파일이 나옵니까? 0개라면, 그 규칙은 지난 한 달간 존재한 적이 없습니다.

관련 글