PART 1: 좋은 디자인을 AI가 잘 구현하게 만드는 방법

들어가기

바이브 코딩(자연어로 AI에게 코드를 생성하게 하는 방식)으로 웹을 만들 때, 시안이 정교해도 코드로 바뀌면 의도와 다르게 보이는 경우가 많아요.

예를 들면 이런 상황이에요.

버튼이 영역 밖으로 넘어간다.

모달이 카드 뒤로 숨는다.

화면은 얼추 비슷한데, hover나 focus 상태가 어색하다.

같은 카드가 반복되는 UI인데, 수정하면 한 카드만 바뀌고 나머지는 변하지 않는다.

spacing, typography, color가 미묘하게 들쭉날쭉해서 전체 완성도가 떨어져 보인다.

이런 문제가 생기는 이유는 단순히 AI가 코드를 못 짜서도 아니고, 디자인이 나빠서도 아니에요. 더 정확히 말하면, 완성도 높은 시안과 구현 가능한 설계는 같지 않기 때문이에요.

사람은 머릿속에서 여러 판단을 하지만, 디자인 시안으로는 드러나지 않을 때가 있어요.

무엇이 핵심 콘텐츠이고, 무엇이 부가 정보인지
어떤 요소는 꼭 고정되어야 하고, 어떤 부분은 유동적이어도 되는지
이 패턴이 한 번 쓰이고 끝나는지, 여러 곳에서 반복되는지

문제는 이런 판단이 AI에게는 거의 전달되지 않는다는 점이에요. AI는 화면을 보고 비슷한 결과를 빠르게 만들 수는 있어요. 하지만 그 안의 구조, 상태, 제약, 예외 케이스, 컴포넌트 경계까지 100% 완벽하게 설계하지는 못해요.

오늘 하고 싶은 말은 이거에요.

머릿속 암묵지를 명시지로 바꿔 전달해야 구현 품질이 올라간다.

이 글(Part 1)에서는 그 배경이 되는 웹 구현의 원리를 3가지 가져왔어요.

웹은 좌표가 아니라 흐름으로 배치된다
웹 화면은 한 장면이 아니라 상태를 가진다
웹은 규칙이 반복되는 시스템이다

모두 디자인에서도 통용될 수 있는 말이지만, 디자인을 웹 구현으로 옮길 때 특히 놓치기 쉬운 부분이라 이 요소들을 강조할게요. 그리고 이 세 가지를 이해해야, 다음 글(Part 2)에서 다룰 AI에게 어떤 방식으로 설명해야 덜 깨지는지도 자연스럽게 연결할 수 있어요.

1. 암묵지를 명시지로 바꿔야 한다

여러분은 지금 화면에서 무엇이 제일 중요하고, 어떤 정렬이 깨지면 안 되고, 어디까지는 허용 가능한 어긋남인지 빠르게 감각적으로 판단할 수 있어요. 하지만 AI 협업에서는 이 강점이 그대로 전달되지 않아요. 오히려 반대로, 말하지 않은 것은 없는 것으로 취급되기 쉽다는 문제가 생겨요.

예를 들면 디자이너는 이런 점을 당연하게 생각해요.

카드 제목은 두 줄까지 허용해야 한다
이 태그는 세 개까지만 노출하고 나머지는 접어야 한다
이 목록은 지금 3개가 보이지만 사실 10개까지 늘어날 수 있다
이 컴포넌트는 한 화면 전용이 아니라 재사용 패턴이다

그런데 AI는 이런 정보를 모르면, 지금 보이는 화면을 기준으로 가장 흔한 패턴을 추정해 버려요. 즉, 판단 기준을 언어로 풀어내는 능력이 같이 중요해져요.

2. 웹 구현에서 알아야 할 세 가지 원리

1) 웹은 좌표가 아니라 흐름으로 배치된다

웹은 기본적으로 normal flow, flex, grid 같은 규칙으로 요소를 배치하고, 일부 요소만 absolute처럼 흐름 밖에서 따로 위치시켜요. 겉모양만 넘기면 AI는 위치를 복원하려다 의도와 다른 결과가 나오기 쉽고, 지금 배치가 어떤 논리로 만들어졌는지를 같이 전달하는 것이 중요해요.

배치를 생각할 때는 크게 두 가지 축으로 볼 수 있어요. 좌표로 직접 지정하는 방식과, 부모가 정한 규칙(흐름)에 따라 배치되는 방식이에요.

Figma에서 일반 프레임은 좌표 기반이고, Auto Layout 안의 자식은 규칙에 따라 배치되며 필요 시 Ignore auto layout으로 흐름 밖에 둘 수 있어요. 웹도 normal flow·flex·grid가 기본이고, absolute는 가장 가까운 positioned 조상 기준으로 흐름 밖에 위치해요. 좌표로 넣는 방식은 Figma에서는 자유롭게 쓸 수 있지만, 웹에서는 뷰나 콘텐츠가 바뀌면 깨지기 쉽습니다.

규칙(흐름)에 따라 배치하는 방식은 Figma의 Auto Layout과 사고방식이 비슷해요. Auto Layout은 콘텐츠 변화에 반응하는 프레임 기반 배치이고, 웹의 Flexbox는 1차원 레이아웃 모델이에요. 완전히 동일한 동작은 아니지만, “부모가 규칙을 정하면 자식이 그에 따라 배치된다”는 점에서는 맞닿아 있어요.

구현을 맡길 때는 먼저 이걸 정하는 게 좋아요. 이 UI의 핵심이 한 방향 흐름인지, 행과 열 구조인지, 흐름 밖에 떠 있는 오버레이인지 말이에요. 카드 리스트처럼 아이템 개수와 텍스트 길이가 달라질 수 있는 UI는 이 기준을 어떻게 주느냐에 따라 결과가 확 달라져요.

Flex와 Grid를 구분하는 기준

Flex는 버튼 묶음, 메뉴, 아이콘 + 텍스트, 카드 내부의 제목 / 설명 / 액션 정렬같은 한 방향 흐름에 적합해요.

한 줄 흐름이 중요하다
순서대로 쌓이는 관계가 핵심이다
카드 내부처럼 1차원 정렬만 잘 되면 된다

Grid는 카드 목록, 갤러리, 대시보드같은 2차원 배치에 적합해요.

카드가 여러 줄로 넘어갈 수 있다
화면 크기에 따라 4열, 3열, 2열처럼 변해야 한다
같은 종류 아이템을 반복적으로 보여 준다
각 행의 시작선과 끝선을 맞추고 싶다

즉 AI에게 전달해야 하는 것은 “지금 화면에서는 이렇게 보인다”가 아니라 이 UI의 핵심이 흐름인지, 격자인지, 오버레이인지예요.

Absolute는 흐름 밖 배치에 쓰인다

absolute는 흐름 밖 배치가 필요한 요소에 유용하지만, 목록·카드 레이아웃처럼 원래 흐름 안에서 해결해야 하는 문제를 대신하는 용도로 남용하면 깨지기 쉬워요. 시각적 위치만 맞추려다 보면 흐름 안에서 정렬돼야 할 구조도 좌표처럼 찍어 버리기 쉽고, AI로 구현할 때도 배치 논리를 안 주면 이런 식으로 나오는 경우가 많아요. 이런 코드는 한 장면에서는 맞아 보여도, 화면 폭이 바뀌거나 콘텐츠 길이가 달라지면 바로 깨져요.

/* 다른 요소들이랑 줄 맞춰 배치하지 않고, 원하는 자리에 직접 올려놔요 */
position: absolute;
/* 왼쪽 기준으로 120px 옆에 놓아요 */
left: 120px;
/* 위쪽 기준으로 340px 아래에 놓아요 */
top: 340px;

그래서 우리가 AI에게 줄 수 있는 중요한 힌트는 이런 거예요.

이 목록은 grid로 배치되어야 한다
이 영역은 세로 흐름이다
이 요소는 흐름에서 벗어나 따로 그러져야 한다

레이아웃에서는 시각적 결과보다 먼저, 배치의 논리를 설명해야 해요.

2) 웹 화면은 한 장면이 아니라 상태를 가진다

디자인 시안은 보통 한 시점의 화면을 보여줘요. 하지만 실제 제품은 상태가 계속 바뀌는 시스템이에요.

예를 들어 이런 상태들이 있어요.

hover / active / focus
enabled / disabled / readonly
checked / unchecked
expanded / collapsed
loading / success / error
empty / filled

이 상태들은 단순히 색이 조금 달라지는 정도가 아니라, 사용자에게 지금 무엇이 가능한지, 무엇이 진행 중인지, 무엇이 잘못됐는지를 알려 줘요.

AI가 정적인 시안만 보고 구현하면 기본 화면은 비슷해 보여도, 상태가 바뀌는 순간 어색해질 수 있어요.

예를 들면 이런 식이에요.

버튼 기본 상태만 있고 hover나 disabled가 빠져 있다
입력창의 에러 상태가 정의되지 않았다
로딩 중인데도 일반 상태와 구분이 잘 되지 않는다

아래 두 데모는 각각 버튼·폼에서 “잘 된 케이스”와 “잘 안 된 케이스”를 나란히 보여줍니다.

즉 웹 화면은 한 장의 완성 이미지가 아니라, 조건에 따라 여러 상태를 오가는 인터페이스예요.

그래서 디자인을 구현으로 옮길 때는 기본 화면 하나만 정리하는 것이 아니라, 최소한 어떤 상태가 존재하는지까지 함께 정의해야 해요.

3) 웹은 규칙이 반복되는 시스템이다

마지막은 일관성의 문제예요.

AI가 만든 화면은 한 장만 보면 얼추 괜찮아 보일 수 있어요. 그런데 여러 화면을 나란히 놓고 보면 어딘가 어색해요. 대부분은 디자인 시스템 규칙이 흔들리고 있기 때문이에요.

예를 들면 이런 현상이 생겨요.

간격이 화면마다 조금씩 다르다
타이포 위계가 흐려진다
radius, shadow, border 값이 제각각이다
같은 버튼인데 색과 크기가 살짝 다르다
토큰 대신 임의의 hex 값이나 px 값이 섞인다

AI는 화면을 비슷하게 만드는 데는 강하지만, 왜 이 값이 시스템 값이어야 하는지까지는 완벽히 지키지 못할 수 있어요.

color.primary.500 대신 #3478f6를 직접 넣는다
spacing.4 대신 18px 같은 애매한 값을 만든다
radius.md 대신 10px를 하드코딩한다
타이포 스타일 대신 그때그때 font-size와 line-height를 조합한다

그래서 실제로는 이런 내용을 더 강하게 전달해야 해요.

색상은 토큰만 사용
spacing은 지정한 scale만 사용
radius, shadow, border는 디자인 시스템 값만 사용
타이포는 정해 둔 text style 이름으로만 사용
가능하면 토큰만 사용하고, 예외 값이 필요하다면 임시 하드코딩이 아니라 토큰 체계에 편입할지 먼저 검토한다

웹 구현과 AI 협업에서 결과를 더 안정적으로 만드는 추천하는 규칙들도 보여드릴게요.

1. 클릭 영역과 시각적 크기를 분리해서 생각하기

예를 들어 아이콘이 16px라고 해서, 실제로 눌리는 영역도 16px이면 너무 작을 수 있어요. 보이는 아이콘은 작아도, 실제 버튼 영역은 더 넉넉해야 사용성이 좋아져요. 즉 UI에서는 보이는 크기와 실제로 눌리는 영역(hit area)를 다르게 설계하는 게 좋을 수 있어요.

2. 짝수 픽셀이나 일정한 스케일을 선호하는 이유

모바일에서는 해상도와 DPR(device pixel ratio)이 다양해서, 홀수 픽셀은 배율에 따라 흐릿하거나 어긋나 보일 수 있어요. 짝수·일정한 스케일이면 여러 기기에서 나눗셈과 정렬이 맞기 쉽고, 터치 영역을 설계할 때도 일관되게 잡기 좋아요. 예전에는 픽셀 그리드와 렌더링 이슈 때문에 더 자주 강조됐고, 지금도 아이콘·보더·작은 그래픽에서는 여전히 의미가 있어요. 그 위에 정렬, 반복, 반응형, 토큰화, 컴포넌트 확장까지 포함해서 시스템적으로 안정적인 값을 만들기 쉽다는 이유가 더해져요.

3. 컬러 시스템에서 놓치기 쉬운 점

컬러 토큰을 쓸 때도 비슷한 주의가 필요해요.

같은 스케일 숫자여도 색마다 인지되는 명도가 다를 수 있어요. Grey 100, Blue 100, Red 100을 같이 쓰면 100으로 통일했는데도 얼룩덜룩해 보일 수 있어요. 인지적으로 균일한 색공간(OKLCH 등)을 기준으로 명도를 맞추면, 같은 스케일끼리 썼을 때 대비와 리듬이 안정적이에요.
라이트모드와 다크모드에서 같은 토큰이 다른 대비로 보일 수 있어요. 라이트 기준으로 맞춘 Teal 50이 다크에서는 너무 튀어서, 다크만 따로 커스텀하는 일이 생기기 쉬워요. 다크모드는 어두운 배경에서 시인성이 더 떨어지므로, 별도 명도 기준(예: APCA)을 두는 편이 안전해요.
시맨틱 토큰(대상·역할·변형)으로 쓰면 "이건 어떤 용도인지"가 명확해져서, AI나 개발자에게 전달할 때도 일관되게 설명하기 쉬워요. (예시: 예: fill/text/border, brand/neutral/primary, weak/alt)

4. 반응형: clamp와 flex, grid

화면 폭에 따라 글자 크기나 간격, 열 개수를 유연하게 바꾸고 싶을 때는 clamp와 flex·grid 조합이 자주 쓰여요.

clamp로 유동적인 값 잡기

clamp(최소, 선호값, 최대)는 "최소보다 작아지지 않고, 최대보다 커지지 않으며, 그 사이에서는 선호값을 따른다"는 뜻이에요. 폰트 크기, padding, margin, width 같은 데 쓰면 뷰포트가 바뀌어도 한 번에 유연하게 맞출 수 있어요.

/* 폰트: 작은 화면에서 14px 이하로 안 내려가고, 큰 화면에서 18px 넘지 않게, 그 사이는 뷰포트에 비례 */
font-size: clamp(14px, 2.5vw, 18px);

/* 카드 padding: 16px~24px 사이에서 화면에 따라 변하게 */
padding: clamp(16px, 4vw, 24px);

/* 콘텐츠 최대 너비를 유지하면서 좌우 여백이 줄어들지 않게 */
max-width: clamp(320px, 90vw, 1200px);

Flex로 반응형 줄바꿈

Flex는 flex-wrap과 min-width를 쓰면 "공간이 부족해지면 다음 줄로 넘긴다"는 식으로 반응형을 만들 수 있어요. 버튼 묶음, 태그 리스트, 카드 행처럼 한 방향 흐름이면서 개수가 많을 때만 줄바꿈이 필요할 때 적합해요.

.card-row {
  display: flex;
  flex-wrap: wrap;
  gap: 16px;
}
/* 아이템이 최소 280px은 유지하고, 남는 공간에 따라 개수가 정해짐 */
.card-row .card {
  min-width: 280px;
  flex: 1 1 280px;
}

Grid로 반응형 열 개수

Grid는 repeat(auto-fill, minmax(...))나 repeat(auto-fit, ...)로 "한 줄에 들어갈 만큼만 열을 만들고, 열 크기는 최소값 이상으로" 같은 반응형을 한 번에 표현할 수 있어요. 카드 목록, 갤러리처럼 2차원 격자이면서 화면이 넓을수록 열이 늘어나야 할 때 잘 맞아요.

/* 카드 최소 280px, 최대 1fr. 공간에 맞춰 열 개수가 자동으로 정해짐 */
.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  gap: 16px;
}

/* breakpoint로 열 수를 명시하고 싶을 때 */
.card-grid {
  display: grid;
  gap: 16px;
}
@media (min-width: 1024px) {
  .card-grid {
    grid-template-columns: repeat(3, 1fr);
  }
}
@media (min-width: 768px) and (max-width: 1023px) {
  .card-grid {
    grid-template-columns: repeat(2, 1fr);
  }
}
@media (max-width: 767px) {
  .card-grid {
    grid-template-columns: 1fr;
  }
}

AI에게 반응형을 부탁할 때는 "clamp로 폰트/간격 범위를 주고, 카드 리스트는 grid로 minmax 반응형"처럼 어떤 방식으로 유연하게 할지까지 같이 말해 주면 더 안정적으로 나와요.

3. AI는 흔한 패턴을 추정한다

AI는 예전보다 꽤 잘 따라오지만, 여전히 의도·예외·경계 조건이 빠진 구조를 만들기 쉬워요. 그래서 중요한 건 암묵지를 명시지로 바꾸는 능력이에요. 예를 들어 이런 식이에요.

구조: 무엇이 무엇을 감싸는가
- A 요소(또는 프레임)는 B 요소와 C 요소를 flex로 감싼다(Auto Layout Vertical/Horizontal).
- D 요소는 기존 흐름에서 벗어나, 다른 층위에 표시된다.
제약: 어디까지 늘어나고 줄어들 수 있는가
- 콘텐츠 영역은 1200px까지 늘어날 수 있고, 최소 800px이어야 한다.
- 양쪽으로 80px 패딩을 가져야 한다.
상태: 기본, hover, focus, disabled, error, loading에서 어떻게 달라지는가
- 이 버튼은 disabled일 때 클릭이 막히고, 로딩 중일 때 문구가 "제출 중…"으로 바뀐다.
- 이 입력창은 에러일 때 빨간 테두리와 필드 아래 메시지를 보여 준다.
의미: 버튼인지, 링크인지, 제목인지, 토글인지
- 이 영역은 버튼(button)이어야 하고, 저 영역은 링크(a)여야 한다.
- 이 아이콘은 장식용이고, 저 아이콘은 필수 입력 같은 정보를 전달한다.
반복 단위: 우연한 화면 묶음인지, 실제로 재사용되는 리스트 단위인지
- 이 카드들은 리스트의 한 아이템 단위로, 개수가 늘어나도 같은 컴포넌트가 반복된다.
- 저 상단 바는 이 화면에만 쓰이는 묶음이고, 다른 화면에서 재사용하는 헤더 컴포넌트가 아니다.

이걸 설명하지 않으면 AI는 가장 흔한 패턴으로 적당히 메워 버려요.

설명 방식에 따른 결과와 예외·컴포넌트

이 차이는 아주 작은 UI 하나만 봐도 드러나요.

예를 들어 카드 리스트 UI를 만든다고 해 볼게요.

Before: 대부분 깨지기 쉬운 요청

이 카드 디자인처럼 만들어줘.

이 요청은 너무 많은 것을 AI가 추정하게 만들어요.

카드 하나가 컴포넌트인지
리스트가 grid인지 flex인지
제목이 몇 줄까지 허용되는지
이미지가 없으면 어떻게 되는지
태그가 많아지면 어떻게 되는지
빈 상태는 있는지
모바일에서는 어떻게 바뀌는지

즉 “보이는 결과”만 있고, 규칙과 제약은 거의 없어요.

After: 훨씬 덜 깨지는 요청

블로그 카드 리스트 UI를 만들어줘.

카드 하나를 재사용 가능한 Card 컴포넌트로 만든다

리스트는 grid 기반이며 desktop 3열, tablet 2열, mobile 1열이다

카드 폭은 320px 이상을 유지하고, 더 넓어지면 480px까지만 자연스럽게 커진다

제목은 최대 2줄, 넘으면 말줄임표 처리한다

본문은 최소 3줄, 최대 5줄까지 노출하고 넘으면 말줄임표 + “더 보기” 링크를 보여 준다

썸네일 이미지가 없으면 120px 높이의 회색 placeholder와 “이미지 없음” 텍스트를 중앙 정렬한다

태그는 최대 3개만 노출하고, 초과분은 +N으로 표시한다

CTA 버튼은 카드 하단에 고정되도록 정렬한다

hover, focus, disabled 상태를 모두 정의한다

색상과 spacing은 지정된 design token만 사용한다

빈 리스트 상태에서는 “아직 등록된 글이 없습니다” 문구와 CTA 버튼을 중앙 정렬해 보여 준다

아래는 실제로 자주 터지는 엣지 케이스들이에요.

자주 터지는 엣지 케이스 예시

1) 텍스트 길이

제목은 최대 2줄, 넘으면 말줄임표
부제는 1줄 고정
본문은 3~5줄 범위에서 유연하게 노출

2) 이미지 없음

이미지가 없으면 placeholder를 보여 주고 레이아웃 높이는 유지
이미지 비율이 다르더라도 카드 높이가 들쭉날쭉해지지 않게 한다

3) 리스트 개수 변화

카드가 1개일 때도 어색하지 않아야 한다
카드가 10개 이상일 때도 줄바꿈 규칙이 유지돼야 한다
빈 상태에서는 별도 메시지와 CTA를 보여 준다

4) 태그 / 배지 과다

태그는 최대 3개까지만 노출
초과 시 +N으로 접는다
태그 길이가 길어도 카드 높이를 과도하게 밀지 않게 한다

5) 상태 변화

hover만 정의하지 말고 focus 정의
disabled는 단순히 흐리게가 아니라 실제 상호작용 불가 상태로 처리
skeleton 또는 spinner 상태를 정의

6) 반응형

desktop에서는 3열, tablet에서는 2열, mobile에서는 1열
모바일에서는 보조 메타 정보를 접고 핵심 정보만 유지
container가 좁아지면 버튼 정렬을 가로에서 세로로 전환

4. MCP가 있어도 왜 설명은 여전히 필요할까

Q. Figma MCP를 쓰면 이 문제가 해결되는 것 아닌가요? A. 물론 많은 부분이 좋아지지만, 설명이 필요 없어지는 것은 아니에요.

최근에는 Figma MCP 서버와 여러 개발 도구의 MCP 지원 덕분에, 레이아웃 구조를 코드로 옮기는 워크플로가 점점 현실적인 선택지가 되고 있어요. 실제로 MCP를 쓰면 레이아웃 구조를 전달하는 정확도는 확실히 좋아져요.

MCP가 잘 해주는 것

예를 들어 이런 정보는 이전보다 훨씬 안정적으로 전달돼요.

Frame
 ├ Auto Layout: horizontal
 ├ gap: 24
 ├ padding: 16
 └ children

Auto Layout horizontal → flex row
gap 24 → gap: 24px
padding 16 → padding: 16px

Auto Layout, gap, padding 같은 기본 구조 전달
프레임 계층, 정렬 방향, spacing 같은 레이아웃 정보 해석
화면의 큰 골격을 코드로 옮기는 초기 변환 작업

여전히 사람이 설명해야 하는 것

1) 의도 중심 판단

이건 flex인가, grid인가
이 컴포넌트는 일회성인가, 재사용 패턴인가

2) 상태

disabled는 단순한 시각 변화인지, 실제 상호작용 차단인지
error, loading 상태를 어디까지 정의할지

3) 토큰 강제력

색상은 token만 써야 하는가
spacing은 정해 둔 scale만 허용하는가
AI가 임의 hex, 임의 px를 섞지 않게 어디까지 강제할 것인가

4) 컴포넌트 추상화 수준

카드 하나가 컴포넌트인가
카드 묶음이 하나의 컴포넌트인가, 리스트 단위인가
버튼은 공통 컴포넌트인가, 특정 화면 전용인가
어디까지를 variant로 볼 것인가

5) breakpoint별 의도 전환

mobile은 desktop의 축소판인가
단순 축소가 아니라 정보 재배치가 필요한가

즉 MCP는 구조 전달의 품질을 크게 높여 주는 도구예요. 하지만 의도, 제약, 예외, 토큰 규칙, 컴포넌트 경계까지 자동으로 결정해 주지는 않아요. 오히려 MCP를 쓰면 이런 사실이 더 잘 드러나요.

예를 들어 이런 경우를 생각해 볼 수 있어요.

사실은 grid가 필요한 구조인데 한 방향 Auto Layout으로만 설계되어 있었다
반복되는 카드 리스트인데 우연한 화면 묶음이 아니라 재사용 리스트 단위로 설계해야 했는데 그렇지 못했다
기본 상태는 정교하지만 hover, focus, error 정의는 약했다
디자인 시스템 토큰보다 눈대중 값이 더 많이 섞여 있었다

이 경우 MCP는 구조를 더 정확히 전달해 줄 수는 있어도, 잘못 잡힌 구조를 올바른 웹 구조로 자동 수정해 주지는 않아요.

마무리

Part 2에서는 이 세 가지 원리를 바탕으로

AI에게 디자인을 어떻게 설명하면 좋은지
어떤 단위로 요청해야 덜 깨지는지
실제로 바이브 코딩으로 페이지를 만드는 방법은 무엇인지

를 더 실전적으로 다룰게요.