더 나은 바이브코딩, 디자이너처럼 생각하기
*원문을 번역한 글입니다.
*원문은 발행 이후 수정될 수 있으며, 본 번역은 발송 시점 기준으로 작성되었습니다.
AI 기반 개발 시대에 디자인 리터러시가 부족한 이유는 무엇일까요?요즘 바이브 코딩이 화제입니다. 원하는 것을 설명하면 AI가 그걸 만들어줍니다. 디자인 학위도, 엔지니어링 배경도 필요 없어요. 그냥 당신과 프롬프트만 있으면 됩니다.
하지만 대부분의 튜토리얼에서 간과하는 불편한 진실이 하나 있습니다. 바로 AI 결과물의 품질은 여러분의 사고력에 달려 있다는 것입니다. 그리고 앱에 대해 제대로 생각하려면 무엇이 좋은 결과물인지 알아야 합니다.
이건 디자이너가 되라는 말이 이닙니다. 오히려, 화면을 보고 'CTA 버튼이 본문 텍스트와 시각적 비중이 같아서 눈에 띄지 않는다' 라고 말할 수 있는, 즉 이해력 있는 클라이언트가 되는 것에 대한 이야기입니다. 막연한 시행착오 대신 정확한 프롬프트를 통해 문제를 해결할 수 있는 사람이 되는 것이죠.
이 가이드는 바로 그 격차를 해소하기 위해 만들어졌습니다.
내 이야기: 코드는 제대로 작동하는데 앱이 작동하지 않을 때
저는 소프트웨어 개발자입니다. 터미널에서 디버깅하고, API를 연결하고, 백엔드 로직을 다루는 일에 익숙합니다. 복잡한 상황에도 익숙하며, 코딩에 대한 두려움은 없습니다.
그래서 AI 도구로 인터페이스를 만들기 시작했을 때, 어려운 부분은 이미 끝났다고 생각했습니다. 논리는 이미 구현되었고, AI가 그 논리를 UI로 감싸기만 하면 되는 거라고 생각했죠.
그런데 UI가 끔찍해 보였어요.
기술적으로는 고장난 게 아니었어요. 버튼도 작동했고, 데이터도 표시됐죠. 하지만 모든 화면이 뭔가 어색하게 느껴졌는데, 정확히 뭐라고 설명할 수는 없었어요. 버튼 간 간격이 제멋대로였고, 버튼들이 서로 시선을 끌려고 경쟁하는 것 같았죠. 모바일에서는 완전히 혼란스러웠어요. '더 깔끔하게 만들어줘', '레이아웃을 개선해줘' 같은 명령어를 계속 입력해 봤지만, 결과는 달라졌을 뿐 나아지지는 않았어요.
문제는 AI가 아니었습니다. 문제는 제가 보고 있는 현상을 설명할 언어가 없었다는 것입니다. 데이터 파이프라인은 디버깅할 수 있었지만, Primary CTA와 Secondary CTA가 동일한 크기와 색상 두께가 동일한 채 둘 다 채워진 버튼이라서 시각적으로 구별하기 어렵다는 것을 AI에게 알려줄 수 없었습니다.
무언가 잘못됐다는 것을 아는 것과 그 이유를 정확히 짚어낼 수 있는 것 사이의 간극이 바로 디자인 리터러시가 메워주는 부분입니다. 디자인 용어를 배우고 의식적으로 시각적 감각을 훈련하기 시작하면서, 제게 필요한 정보는 더욱 구체화되었고, 결과물도 훨씬 좋아졌습니다. 이전에는 그저 그런 화면을 만들던 AI 도구들이 이제는 제가 자랑스러워할 만한 인터페이스를 만들어내기 시작했습니다.
디자인 학교에서 몇 년씩 공부할 필요는 없습니다. 디렉팅을 할 수 있는 능력만 있으면 됩니다. 제가 성공했던 길을 알려드리겠습니다.
오늘날 바이브 코딩의 진짜 문제점은 무엇일까요?
Bolt, Lovable, Cursor v0 같은 AI 코딩 도구들은 정말 강력합니다. 하지만 대부분의 사람들이 이 도구들을 사용하는 모습을 보면 비슷한 패턴을 발견하게 됩니다.
첫 화면은 괜찮아 보입니다.
두 번째 화면은 간격이 일정하지 않습니다.
세 번째 화면에는 버튼이 있긴 하지만 시각적으로 잘 보이지 않습니다.
다섯 번째 화면에 이르면 마치 앱을 한 번도 사용해 본 적 없는 로봇들이 모여서 만든 앱처럼 느껴집니다.
이것은 AI의 실패가 아닙니다. 지시의 실패 입니다 .
'깔끔하고 모던하게 만들어 주세요'라고 입력하면 AI가 실패하는 건 아니지만, 기본 설정값을 사용하게 됩니다. 무난하게 받아들일 만한 결과를 보여주는 거죠. 문제는 사용자가 구체적인 방향을 제시한 게 아니라, 분위기를 나타내는 단어를 입력했다는 점입니다. AI는 분위기를 느끼는 게 아니라 지시사항을 처리할 뿐입니다.
바이브 코딩으로 진정으로 좋은 결과를 얻는 사람들에게는 한 가지 공통점이 있습니다. 바로 원하는 것을 구체적으로 설명할 수 있다는 것입니다. 그들은 "내비게이션을 보기 좋게 만드세요"라고 말하지 않습니다.
그들은 '모바일에서 4개의 아이콘으로 구성된 고정형 하단 내비게이션 바를 사용하고, 레이블은 없으며, 활성 상태는 브랜드 블루 #2563EB 색상의 채워진 아이콘으로 표현' 이라고 말합니다.
이러한 구체성은 디자인에 대한 지식에서 비롯됩니다.
1단계: 이론을 배우기 전에 관찰력을 키우세요
가장 효과적인 출발점은 디자인에 대한 글을 읽는 것이 아니라, 의도적으로 디자인을 관찰하는 것입니다.
대부분의 사람들은 앱을 제대로 보지 않고 스크롤만 합니다. 그저 경험할 뿐이죠. 앱을 사용하는 데는 문제가 없지만, 앱을 만드는 데는 전혀 도움이 되지 않습니다. 핵심은 "이 느낌이 좋다" 에서 "왜 이 느낌이 좋을까?" 로 생각을 전환하는 것입니다.
실습:
매일 15분씩 Mobbin 에서 시간을 보내세요: Notion, Linear, Stripe, Airbnb 등 유명 제품의 실제 앱 화면들을 모아놓은 라이브러리입니다. 그냥 스크롤만 하지 마세요. 화면 하나를 골라 다음과 같은 질문을 던져보세요. 왜 주요 동작이 가장 눈에 잘 띄는 곳에 있을까요? 여백을 제거하면 페이지 계층 구조는 어떻게 될까요? 이 화면에는 몇 가지 글꼴 크기가 사용되고 있을까요?
마음에 드는 화면을 복사해 보세요: Figma를 사용하지 말고, 구성 요소 하나하나를 글로 묘사해 보세요. 보이는 모든 것에 이름을 붙여 보세요. 그러면 이전에는 미처 알아차리지 못했던 섬세한 디테일들을 발견하게 될 겁니다. 예를 들어, 카드 테두리의 미묘한 차이, 아이콘과 레이블 사이의 4px 간격, 보조 텍스트와 비활성화 상태에 사용된 회색 색상 등을 말이죠.
애덤 와탄과 스티브 쇼거가 쓴 'UI 리팩토링'을 읽어보세요: 이 목표를 달성하는 데 있어 최고의 투자입니다. 이 책은 당신을 디자이너로 만들어주는 것이 아니라, 경험 많은 디자이너들이 보는 것을 가르쳐줍니다. 각 장마다 앱 개발 과정에서 마주하게 될 실제적인 시각적 문제를 해결해줍니다.
이렇게 2~3주 정도 하다 보면, 이전에는 당연하게 여겼던 자신의 감정적 결과물에서 이상한 점들을 발견하기 시작할 겁니다. 바로 그 알아차리는 능력이 핵심입니다.
2단계: 디자인 어휘 구축하기
정확한 단어를 알지 못하면 적절한 프롬프트를 만들 수 없습니다. 이는 전문 용어 자체를 위한 것이 아니라, 간결성을 위한 것입니다. "보조 동작에 고스트 버튼을 사용하세요" 라는 문구는 다섯 단어로, 그렇지 않았다면 한 단락에 걸쳐 설명해야 했을 내용을 전달합니다. AI는 이러한 용어를 이해하고 안정적으로 응답합니다.
시각 디자인 분야에서 실제로 필요한 용어들:
간격과 계층 구조 부터 시작하세요: 8px 그리드 시스템이 무엇을 의미하는지 이해하세요. 대부분의 디자인 시스템은 간격(패딩, 마진, 갭)에 4 또는 8의 배수를 사용합니다. "카드 내부 패딩 16px, 섹션 사이 패딩 24px"와 같이 구체적으로 지정하면 AI는 구체적인 제약 조건을 적용합니다. 하지만 "여유 공간을 두세요" 라고 하면 AI는 임의로 추측합니다.
타이포그래피 계층 구조를 배우세요: 잘 구성된 화면은 일반적으로 의도적인 굵기 변화를 적용한 세 가지에서 네 가지 텍스트 크기를 사용합니다. 페이지 제목은 24px/Bold, 섹션 제목은 18px/Semibold, 본문은 16px/Regular, 캡션은 14px/Medium으로 설정하는 식입니다. 이렇게 텍스트 크기에 이름을 명확하게 지정하면 일관성을 유지할 수 있습니다. 그렇지 않으면 세 번째 화면부터 혼란스러워집니다.
색상 시스템 용어를 익히세요: Primary(브랜드 활동), Secondary(지원 활동), Neutral(표면, 테두리, 텍스트), Semantic(성공 녹색, 오류 빨간색, 경고 노란색). "검증 메시지에는 brand primary가 아닌 Semantic error red을 사용하세요" 와 같이 지시문에 색상을 명시하면 "오류 메시지를 명확하게 만드세요"라고 하는 것 보다 훨씬 더 나은 결과를 얻을 수 있습니다 .
학습해야 할 컴포넌트 패턴 이름:
이것들은 AI가 이미 잘 알고 있는 구성 요소들입니다. 올바른 용어를 사용하면 그 지식이 활성화됩니다. 주요 용어로는 다음 등이 있습니다.
바텀 시트(bottom sheet) vs 모달(modal) vs 드로어(drawer)
세그먼트 컨트롤(segmented control) vs 탭(tab) vs 토글(toggle)
토스트 알림(toast notification) vs 경고 배너(alert banner) vs 인라인 오류(inline error)
스켈레톤 로더(skeleton loader) vs 스피너(spinner)
빈 상태(empty state)
스티키 헤더(sticky header)
플로팅 액션 버튼(FAB)
"필터 옵션은 전체 모달이 아닌 바텀 시트를 사용하고, 화면 높이의 50%에 맞춰야 한다" 라고 명확하게 지시할 수 있다면 , AI에게 알려진 패턴에 기반한 구체적인 지침을 제공하는 것입니다. 하지만 "필터 메뉴가 어떻게든 화면 하단에서 팝업되도록 해" 라고만 하면 , 결과는 운에 맡겨지게 됩니다.
3단계: 디자이너처럼 글쓰는 법 배우기, 이제 개발자에게 맡기세요
AI 프롬프트에 가장 유용한 기술은 전문 디자인에서 가장 유용한 기술과 동일합니다. 바로 명확한 명세서를 작성하는 능력입니다.
AI 이전에는 디자이너들이 개발자에게 전달할 메모에 정확한 값, 명확한 결정 사항, 명명된 상태 등을 적었습니다. 이러한 체계적인 방식을 프롬프트에도 적용하면 훨씬 더 높은 수준의 결과물을 얻을 수 있습니다.
좋은 디자인 명세서 작성 지침에는 다음 다섯 가지 사항이 포함됩니다.
1. 레이아웃 및 구조, 페이지가 전체적인 수준에서 어떻게 구성되는지.
예: "데스크톱에서는 2단 레이아웃: 왼쪽에 280px 고정 사이드바, 오른쪽에 스크롤 가능한 콘텐츠 영역. 모바일에서는 하단 탭 탐색 기능을 갖춘 단일 열 레이아웃."
2. 구성 요소 목록, 존재하는 UI 요소와 그 명칭.
예: "상단 바에는 로고가 왼쪽 정렬되어 있고, 검색창은 가운데, 아바타와 알림 벨은 오른쪽에 있습니다. 그 아래에는 가로로 스크롤 가능한 태그 필터 행이 있습니다. 그 다음에는 콘텐츠 카드들이 격자 형태로 배열되어 있습니다."
3. 시각적 언어, 즉 디자인을 정의하는 구체적인 값들.
예: "배경색 #F4F5F7, 카드 표면색 #FFFFFF, 카드 테두리 반경 12px, 버튼 테두리 반경 8px. 기본색 #6366F1. 그림자 효과 대신 테두리를 사용하세요."
4. 상태 정의, 즉 인터랙티브 요소의 동작 방식을 정의합니다.
예: "버튼 호버 시: 8% 어두워짐. 활성화됨: 0.97로 확대/축소. 비활성화됨: 40% 투명도, 커서 변경 없음. 로딩 중: 레이블을 스피너로 대체."
5. 안티 패턴, 즉 하지 말아야 할 것은 해야 할 것보다 훨씬 더 중요할 때가 많습니다.
예: "카드 안에 카드를 중첩하지 마십시오. 모바일에서 태그 필터 행을 제외하고는 가로 스크롤을 사용하지 마십시오. 어떤 화면에도 동시에 세 개 이상의 주요 액션을 표시하지 마십시오."
매번 다섯 가지 요소를 모두 적을 필요는 없습니다. 하지만 이러한 요소들이 존재한다는 것을 알고 있으면, 어떤 요소가 여러분의 바이브 코드화된 결과물에 문제를 일으키는지 파악할 수 있습니다.
4단계: 추상적인 분위기가 아닌 실제 제품을 참고하세요
대부분의 사람들이 간과하는 치트키가 하나 있습니다. 바로 AI가 인터넷을 경험했다는 점입니다. AI는 Linear의 사이드바가 어떻게 생겼는지, Stripe의 대시보드 구조는 어떤지, Notion의 인라인 편집 기능은 무엇인지, Apple의 설정 화면은 어떻게 구성되어 있는지 알고 있습니다.
프롬프트에 잘 알려진 제품 이름을 언급하는 것이 처음부터 설명하는 것보다 빠르고 정확합니다. AI가 사용자의 설명에 의존하여 구성하는 대신 실제 시각적 정보를 활용할 수 있기 때문입니다.
동일한 기능에 대한 다음 두 프롬프트를 비교하십시오.
버전 A: "다양한 섹션으로 구성된 깔끔하고 정돈된 설정 화면을 만드세요."
버전 B: "iOS 설정 앱의 규칙을 따르는 설정 화면을 만드세요. 테이블 뷰 스타일의 그룹화된 섹션, 탐색 가능한 행에 화살표 아이콘, 부울 설정에 대한 토글 스위치는 오른쪽 정렬, 섹션 제목은 대문자 소문자로 표시하세요."
버전 B는 더 많은 창의성을 요구하는 것이 아닙니다. iOS 설정 앱이 AI가 특정 시각적 패턴에 매핑할 수 있는 잘 알려진 참조 자료라는 점을 이해하는 것이 중요합니다.
자신만의 참고 자료 라이브러리를 구축하세요. 마음에 드는 인터랙션, 전환 효과, 레이아웃, 컴포넌트 동작 등을 발견하면 이름을 붙이세요. "슈퍼휴먼(Superhuman)이 키보드 단축키 오버레이를 처리하는 방식." "버셀(Vercel) 대시보드의 상태 표시기 사용 방식." "리니어(Linear)가 드래그하여 순서를 변경하는 방식." 이렇게 기록된 참고 자료들은 재사용 가능한 아이디어의 원천이 됩니다.
5단계: 프롬프트 라이브러리 구축
바로 이곳에서 투자 효과가 배가됩니다.
모든 바이브 코딩 프로젝트는 제대로만 접근한다면 배움의 기회입니다. 각 세션이 끝날 때마다 "AI가 무엇을 잘못 판단했는가? 디자인 관점에서 그 이유를 설명할 수 있을까 ?"라고 자문해 보세요. 그리고 나서 프롬프트를 업데이트하세요.
시간이 지남에 따라 재사용 가능한 프롬프트 구성 요소, 시각적 언어를 확립하는 검증된 "디자인 시스템 스타터", 탐색, 간격 및 레이아웃 규칙을 설정하는 "모바일 셸", 반복적으로 구축하는 요소에 대한 구성 요소 수준의 프롬프트 등이 축적됩니다.
기본적인 디자인 시스템 구상을 위한 시작 프롬프트는 다음과 같을 수 있습니다.
프로젝트 전체에 다음 디자인 시스템을 사용하세요: 기본 색상 #6366F1, 배경 #F8FAFC, 표면 색상 #FFFFFF, 기본 텍스트 #0F172A, 보조 텍스트 #64748B, 테두리 #E2E8F0. 기본 글꼴: Inter. 글자 크기: 24/20/18/16/14/12px. 간격: 기본 단위 4px, 4의 배수 사용. 테두리 반경: 입력란 4px, 카드 8px, 모달 12px. 모달을 제외한 모든 요소에는 그림자 효과를 적용하지 마세요 (모달의 경우 rgba(0,0,0,0.08) 0 4px 16px 사용). 모든 인터랙티브 요소는 호버 및 활성 상태를 가져야 합니다.
그 프롬프트를 개발하는 데 시간이 걸렸지만, 이후 모든 프로젝트에서 시간을 절약해 줍니다.
메타 스킬: 무엇이 잘못되었는지 파악하기
이 모든 것은 하나의 핵심 능력으로 귀결됩니다. 바로 바이브 코드로 분석된 화면을 보고 무엇이 잘못되었는지 구체적으로 파악하여 수정할 수 있는 능력입니다 .
"이건 어색해 보인다" 가 아니라 , "기본 CTA와 보조 액션 버튼 모두 크기가 비슷한 채워진 버튼이라 시각적으로 같은 비중을 차지한다. 보조 버튼을 투명 버튼으로 바꾸세요."
"레이아웃이 복잡해 보인다" 가 아니라 , "이 화면에는 서로 다른 다섯 가지 글꼴 크기가 있고 명확한 계층 구조가 없다. 페이지 제목, 본문, 레이블 이렇게 세 가지로 통합하라"는 것입니다.
"모바일 버전이 작동하지 않는다" 가 아니라 , "모바일에서 375px 미만일 때, 2열 카드 그리드가 1열로 축소되지만 카드 패딩은 여전히 24px로 유지되어 콘텐츠를 표시할 공간이 거의 없습니다. 모바일에서는 12px로 변경하세요."
이러한 명명 능력은 AI를 활용하여 생산적인 반복 작업을 하는 사람들과 "더 좋게 만들어 주세요" 라는 식의 변형된 요청만 반복하며 미미한 개선만 이루는 사람들을 구분 짓는 요소입니다.
실용적인 학습 스택
4~6주 안에 이러한 기술을 익히고 싶다면 다음 순서를 따르세요.
먼저, Refactoring UI를 처음부터 끝까지 읽거나, 최소한 계층 구조, 간격, 색상 관련 챕터는 읽으세요. 그다음 Mobbin에서 2주 동안 실제 앱 화면을 매일 집중해서 살펴보세요. Figma 기초(무료 플랜으로도 충분합니다)도 익히세요. Figma에서 직접 디자인할 필요는 없고, 디자이너들이 컴포넌트와 제약 조건을 어떻게 생각하는지 이해할 정도면 충분합니다. 그런 다음, 자신만의 분위기 코딩 화면을 위한 디자인 사양서를 작성해 보세요 . 텍스트 파일이라도 괜찮습니다. 마지막으로, 그 과정에서 프롬프트 라이브러리를 구축해 나가세요 .
투자는 4~6주간의 집중적인 관심입니다. 그 결과는 마치 전문가가 만든 것처럼 보이는 AI 결과물입니다. 왜냐하면 실제로 당신이 그 결과물을 만들어내는 것이기 때문입니다.
더 큰 그림
바이브 코딩에 대한 이야기는 흔히 "AI가 학습의 필요성을 대체한다"는 식으로 전개됩니다. 이는 절반만 맞는 말입니다. AI는 기계적인 부분, 즉 상용구 코드를 작성하고, CSS를 구성하고, 컴포넌트 코드를 구조화하는 등의 작업을 대체하는 것은 맞습니다.
하지만 실행력 자체는 부족하지 않았습니다. 문제는 판단력이었죠. 무엇을 만들어야 할지, 무엇이 좋은 결과인지, 그리고 왜 무언가가 잘못되었다고 느껴지는지 아는 것, 바로 그런 판단력이 저절로 생겨나는 게 아닙니다.
디자인 활용 능력은 도구를 사용할 때 판단력을 발휘하는 방법입니다. 판단력을 갖추면 AI는 단순히 코드만 생성하는 것이 아니라, 사용자의 비전을 정확하게 구현해냅니다.
그것이 바로 바이브 코딩과 방향성 있는 구축 의 차이점입니다 .
이 글이 도움이 되었다면, 언급된 자료들을 참고하세요:
Refactoring UI (refactoringui.com),
Mobbin (mobbin.com),
Laws of UX (lawsofux.com),
Figma (figma.com, 무료 버전).
모두 시간을 투자할 만한 가치가 있습니다.
원문 출처: https://medium.com/@iushv28/you-dont-need-to-be-a-designer-to-vibe-code-better-apps-but-you-need-to-think-like-one-9f5d84c87ad1
DEET를 구독하고 커리어 성장을 위한 작은 습관을 시작해 보세요.
