바이브코딩 UI 용어 사전 1편 레이아웃: 히어로 섹션부터 반응형까지 13개

이전 글 바이브코딩 UI 용어 사전 0편에서는 화면 세 장에 부품 이름 32개를 붙이고 AI에게 시킬 때 쓰는 요청문 5칸(이름·위치·계기·동작·예외)을 정리했습니다. 이번 글부터 본편입니다.

1편은 "무엇을 어디에 둘까"에 해당하는 레이아웃(Layout, 화면 배치) 용어를 다룹니다. 이름을 모르면 AI에게 "위에 크게 하나, 그 아래 네모 여러 개, 휴대폰에서는 알아서 잘"처럼 말하게 되는데, 마지막의 "알아서 잘"이 생각보다 많은 걸 AI에게 맡깁니다.

이번 글에서는 히어로 섹션부터 반응형·브레이크포인트까지 레이아웃 용어 13개를 가상 사이트에 직접 만들어 띄워 놓고 비교하겠습니다. 그리고 같은 홈페이지를 "반응형으로 만들어 줘" 한마디와, 화면 폭마다 열 수와 순서를 정해 준 요청으로 Claude에게 시켜서 390·768·1024·1440px 화면에서 무엇이 달라지는지 재 보겠습니다.

(작성일 기준 2026-11-02입니다. 화면 속 freeform, Brightlane, borderless, clearsight, Mixvane, neurolume, cutframe, Driftnest, fizzbloom은 포인트 컬러 글을 위해 지어낸 가상의 서비스이고, 색도 그 글에서 고른 조합을 그대로 썼습니다. 용어는 업계에서 흔히 쓰는 뜻을 기준으로 적었고, 디자인 도구마다 부르는 이름이 조금씩 다를 수 있습니다.)

먼저 13개를 한 표로 모았습니다. ★는 바이브코딩을 하면서 꼭 알아 두면 좋은 이름입니다.

이름마다 정의, 띄워 놓은 비교 그림, 언제 쓰는지와 헷갈리는 짝, AI에게 시키는 요청문 순서로 적었습니다. 요청문은 0편의 5칸 중 이 이름에 필요한 칸만 채웠습니다.

페이지의 큰 덩어리

랜딩 페이지를 위에서 아래로 훑으면 큰 덩어리 네 개가 먼저 보입니다. 첫 화면을 채우는 소개, 맨 위 메뉴 줄, 맨 아래 정보 묶음, 그리고 스크롤 없이 보이는 범위입니다.

1. 히어로 섹션 (Hero section)

페이지 맨 위에서 첫 화면을 크게 차지하는 소개 영역입니다. 무슨 서비스인지(헤드라인), 누구에게 무엇을 해 주는지(서브카피), 지금 무엇을 누르면 되는지(CTA 버튼)를 한 번에 보여 주는 자리입니다.

크게 보기

그래픽 에셋 사이트 freeform의 히어로를 일곱 부분으로 나눴습니다. 헤드라인 위의 작은 머리글을 아이브로(Eyebrow)라고 부르는데, "NEW · 2,400 free 3D assets this week"처럼 한 줄로 지금 소식이나 주제를 먼저 알립니다. 버튼은 둘인데 포인트 색(민트)은 주 버튼 하나에만 칠했고 보조 버튼은 테두리만 남겼습니다. 버튼 아래 "이만큼 쓰고 있다"를 보여 주는 줄이 신뢰 줄(Social proof)입니다.

헷갈리는 짝은 배너(Banner)입니다. 배너는 페이지 위나 중간에 끼우는 얇은 띠(이벤트·공지)이고 히어로는 첫 화면 전체를 맡는 영역입니다. "맨 위에 큰 배너"라고 말하면 AI가 둘 중 무엇을 만들지 모르니 히어로라고 부르는 편이 정확합니다.

히어로 섹션: 첫 화면 높이를 채우고, 왼쪽에 아이브로·헤드라인·서브카피·주 버튼 '무료로 시작'(포인트 색)·보조 버튼(테두리만), 오른쪽에 그래픽. 버튼 아래에 신뢰 줄 한 줄. 휴대폰에서는 글 → 버튼 → 그래픽 순서로 쌓기.

AI가 자주 빠뜨리는 것은 반대로 "넣지 말았어야 할 것"입니다. 0편 실험에서 세 결과 모두 "180+ 수행 프로젝트" 같은 숫자를 지어서 신뢰 줄에 넣었습니다. 진짜 숫자를 주거나 "숫자 없이"라고 적어 두는 게 안전합니다.

2. 내비게이션 바·스티키 헤더 (Navbar · Sticky header)

맨 위 메뉴 줄이 내비게이션 바입니다. 보통 왼쪽에 로고, 가운데나 오른쪽에 메뉴, 맨 오른쪽에 주 버튼 하나가 들어갑니다. 이 줄을 스크롤해도 화면 위에 붙어 있게 만들면 스티키 헤더라고 부릅니다.

크게 보기

같은 Brightlane 홈페이지를 두 창에 띄워 동시에 스크롤했습니다. 왼쪽 일반 헤더는 본문과 함께 올라가 사라지고, 오른쪽 스티키 헤더는 맨 위에 남은 채 스크롤이 80px을 넘으면 높이가 56px에서 46px로 줄고 반투명 배경과 그림자가 생깁니다.

헷갈리는 짝은 고정 헤더(Fixed header)입니다. 스티키는 원래 자리에 있다가 화면 위에 닿는 순간부터 붙고 고정 헤더는 처음부터 화면에 고정돼 있어서 본문 맨 윗부분을 덮기 쉽습니다. 겉보기엔 거의 같아서 "페이지 맨 윗부분이 헤더 밑에 깔린다"는 증상이 보이면 고정 헤더로 만들어진 경우가 많습니다.

내비게이션 바: 왼쪽 로고, 가운데 메뉴 4개, 오른쪽 '무료로 시작' 버튼. 스티키 헤더로 위에 붙이고 스크롤이 80px을 넘으면 반투명 배경과 그림자. 1023px 이하(태블릿·휴대폰)에서는 메뉴를 햄버거 버튼으로 접기.

스티키 헤더를 붙이면 생기기 쉬운 문제가 하나 있습니다. 메뉴를 눌러 해당 섹션으로 이동하면 섹션 제목이 헤더 밑에 가려지는 것입니다. 아래 실험의 두 결과는 시키지 않았는데도 둘 다 이걸 막아 뒀습니다(Flavors·Story·Stores·FAQ 네 메뉴 모두 이동 후 제목이 헤더 아래에 보였습니다). 그래도 요청문에 한 줄 넣어 두면 나중에 확인할 거리가 하나 줄어듭니다.

3. 푸터 (Footer)

페이지 맨 아래 영역입니다. 회사 정보, 링크 묶음, 이용약관·개인정보처리방침, SNS 링크가 여기 모입니다.

크게 보기

채용 플랫폼 borderless의 두 화면입니다. 왼쪽은 로그인처럼 한 가지 일에 집중하는 화면이라 저작권과 약관만 한 줄로 둔 미니 푸터, 오른쪽은 홈페이지 맨 아래라 링크 묶음 5열과 뉴스레터 입력칸, 언어·통화 선택까지 넣은 팻 푸터(Fat footer)입니다. 높이가 48px과 380px로 여덟 배 가까이 차이 납니다. 팻 푸터는 사실상 사이트 지도 역할을 하고 미니 푸터는 화면 밖으로 나갈 길을 일부러 줄입니다.

푸터: 링크 묶음 4열(제품·회사·고객지원·SNS)과 뉴스레터 입력칸, 맨 아래 한 줄에 저작권·이용약관·개인정보처리방침. 태블릿(768~1023px)은 2열, 휴대폰(767px 이하)은 1열.

아래 실험에서 만든 두 푸터는 링크 20개 중 14개, 17개 중 10개가 아무 데도 가지 않는 링크(#)였습니다. 예시 페이지라 자연스러운 결과이긴 한데, 실제 사이트에 옮길 때는 링크 주소 목록을 같이 주거나 "아직 없는 페이지는 링크를 빼기"라고 적어 두는 편이 좋습니다.

4. 첫 화면 (Above the fold)

스크롤하지 않고 처음 보이는 범위입니다. 신문을 반으로 접었을 때 접힌 선 위쪽을 부르던 말에서 왔습니다. 데스크톱은 보통 1440×900, 휴대폰은 390×844 정도를 기준으로 봅니다.

크게 보기

같은 clearsight 랜딩을 데스크톱 한 장, 휴대폰 두 장으로 놓고 첫 화면이 끝나는 자리에 점선을 그었습니다. 데스크톱은 상담 버튼이 위에서 510px이라 첫 화면(900px) 안에 들어옵니다. 휴대폰에서 그래픽을 먼저 쌓으면 버튼이 857px까지 내려가 첫 화면(844px) 밖으로 밀려나고, 글을 먼저 쌓은 오른쪽은 311px이라 바로 보입니다. 같은 내용인데 순서 하나로 갈립니다.

데스크톱에서 좌우로 놓인 것이 휴대폰에서 위아래로 쌓일 때 어느 쪽이 위로 갈지는 AI가 정합니다. 그래서 첫 화면 이야기는 결국 반응형의 "순서" 이야기로 이어집니다(아래 실험에서 다시 봅니다).

첫 화면: 데스크톱 1440×900과 휴대폰 390×844 모두에서 헤드라인과 주 버튼이 스크롤 없이 보이게. 휴대폰에서는 그래픽을 버튼 아래로 내리고 높이를 줄이기.

칸 나누기와 배치

큰 덩어리 안을 어떻게 나눌지에 관한 이름들입니다. 눈금(그리드)을 먼저 보고 그 눈금 위에 칸을 늘어놓는 방식 다섯 가지를 차례로 보겠습니다.

5. 그리드·열 (Grid · Columns)

화면을 세로 열로 나눈 보이지 않는 눈금입니다. 내용은 이 눈금에 맞춰 "몇 열을 차지할지"로 배치합니다. 열과 열 사이 간격을 거터(Gutter), 화면 양 끝의 빈 공간을 마진(Margin)이라고 부릅니다.

크게 보기

데스크톱은 12열이 가장 흔합니다. 12는 2·3·4·6으로 나누어떨어져서 카드 3개(4열씩), 4개(3열씩), 글과 그림 반반(6열씩)을 모두 맞출 수 있기 때문입니다. 휴대폰은 화면이 좁아서 4열 정도로 줄이고 카드 하나가 4열 전체를 씁니다.

바이브코딩에서 12열을 직접 말할 일은 많지 않습니다. 대신 "데스크톱 3열, 휴대폰 1열"처럼 열 수를 말하면 AI가 그리드를 알아서 짭니다. 열 수를 안 말하면 무엇이 정해지는지는 아래 실험에서 봅니다.

서비스 카드 3개를 그리드로: 데스크톱 3열(카드 사이 24px), 768~1023px은 2열, 767px 이하는 1열. 내용 전체 폭은 최대 1200px.

6. 카드 레이아웃 (Card layout)

정보를 카드(테두리나 그림자로 묶은 상자)에 담아 격자로 늘어놓는 배치입니다. 카드 한 장의 구조(사진·제목·정보·버튼)는 3편에서 따로 다루고 여기서는 늘어놓는 방식만 봅니다.

크게 보기

음원 서비스 Mixvane의 신곡 6개를 리스트와 카드로 나란히 놓았습니다. 같은 6곡인데 리스트는 한 줄에 한 곡이라 발매일·재생 수·길이를 위아래로 비교하기 쉽고 카드(3열)는 커버가 커서 그림을 보고 고르기 좋습니다. 대신 카드는 한 화면에 들어가는 개수가 적습니다. 리스트는 같은 높이에 6곡과 "View all 48 releases" 링크까지 들어갔습니다.

그래서 기준은 단순하게 잡으시면 됩니다. 고르는 근거가 그림(앨범 커버, 숙소 사진, 상품 사진)이면 카드, 글자나 숫자(곡 길이, 가격, 날짜)를 비교하는 거라면 리스트나 표가 맞습니다.

신곡 목록을 카드 레이아웃으로: 카드마다 커버·제목·아티스트, 데스크톱 4열·휴대폰 2열, 카드 높이는 같게 맞추고 제목은 두 줄까지만.

마지막 "카드 높이 같게, 제목 두 줄까지"는 저는 꼭 적는 편입니다. 실제 데이터는 제목 길이가 제각각이라 카드 높이가 들쭉날쭉해지기 쉬운데, AI가 넣는 예시 제목은 대개 길이가 비슷해서 만든 직후에는 잘 드러나지 않습니다. (카드가 긴 제목에 깨지는지는 3편에서 직접 넣어 보겠습니다.)

7. 벤토 그리드 (Bento grid)

도시락(벤토) 칸처럼 크기가 다른 칸을 한 격자 안에 맞춰 넣은 배치입니다. 기능 소개 섹션에서 특히 자주 보입니다.

크게 보기

웰니스 서비스 neurolume의 기능 6개를 같은 크기 카드(왼쪽)와 벤토 그리드(오른쪽)로 놓았습니다. 왼쪽은 여섯 개가 모두 같은 무게라 어디부터 봐야 할지 정해 주지 않습니다. 오른쪽은 집중도 82% 칸을 2×2로 키워 주인공을 정하고 나머지는 세로로 긴 칸, 가로로 긴 칸, 작은 칸으로 나눴습니다. 칸 크기가 곧 중요도입니다.

기능 6개를 벤토 그리드로: 4열 격자, 'Focus score' 칸은 2×2로 가장 크게, 'Sleep'은 세로 2칸, 'EEG'와 'Integrations'는 가로 2칸, 나머지는 1칸, 칸 사이 16px. 767px 이하에서는 1열로 쌓되 큰 칸이 맨 위.

벤토는 데스크톱에서 예쁘게 맞춘 칸이 휴대폰에서 어떻게 쌓일지가 관건입니다. 위 요청문의 마지막 줄을 빼면 어떻게 되는지는 실험에서 확인했습니다.

8. 매서너리 (Masonry)

높이가 다른 카드를 열마다 위에서 아래로 벽돌처럼 쌓는 배치입니다. 사진이나 작품처럼 가로세로 비율이 제각각인 것을 모아 보여 줄 때 씁니다.

크게 보기

freeform의 에셋 12개를 균일 그리드(왼쪽)와 매서너리(오른쪽)로 놓았습니다. 균일 그리드는 모든 칸이 1:1이라 세로로 긴 MAKE 포스터와 NO LIMITS 글자가 칸에 맞춰 잘립니다. 매서너리는 그림을 원래 비율대로 두고 열마다 위에서 아래로 쌓아서 잘리는 그림이 없습니다.

알아 둘 점이 하나 있습니다. 가장 간단한 매서너리 구현(CSS 다단 columns)은 첫 열을 위에서 아래로 다 채운 다음 두 번째 열로 넘어갑니다. 그래서 1·2·3번이 첫 열에 세로로 놓입니다. 최신순처럼 순서가 중요하면 "왼쪽에서 오른쪽 순서 유지"라고 적어야 합니다.

에셋 목록을 매서너리로: 데스크톱 4열·태블릿 3열·휴대폰 2열, 그림은 원래 비율 그대로(자르지 않기), 칸 사이 16px, 순서는 왼쪽에서 오른쪽으로.

9. 스플릿 레이아웃 (Split layout)

화면을 좌우 두 덩어리로 나눈 배치입니다. 글과 그림, 가입 폼과 브랜드 소개처럼 성격이 다른 두 가지를 대등하게 놓을 때 씁니다.

크게 보기

영상 편집 앱 cutframe의 같은 가입 화면을 가운데 정렬(왼쪽)과 스플릿(오른쪽)으로 만들었습니다. 가운데 정렬은 폼 하나에만 눈이 가고 스플릿은 왼쪽에서 가입하는 동안 오른쪽 미리보기로 "가입하면 이걸 쓴다"를 보여 줍니다. 비율은 50:50이 기본이고 한쪽을 강조하고 싶으면 60:40 정도로 나눕니다.

헷갈리는 짝은 아래 사이드바 레이아웃입니다. 스플릿은 두 덩어리가 대등하고 사이드바는 좁은 보조 영역과 넓은 본문으로 처음부터 크기가 다릅니다.

가입 화면을 스플릿 레이아웃으로: 왼쪽 50%에 가입 폼, 오른쪽 50%에 편집기 미리보기 그래픽과 사용자 한마디. 767px 이하에서는 오른쪽 패널을 폼 아래로 내리고 높이를 줄이기.

10. 사이드바 레이아웃 (Sidebar layout)

한쪽(주로 왼쪽)에 좁은 세로 영역을 고정하고 나머지를 본문으로 쓰는 배치입니다. 앱·대시보드의 메뉴, 쇼핑몰 목록 화면의 검색 필터가 대표적입니다.

크게 보기

팀 캘린더 Brightlane 앱의 같은 주간 화면입니다. 왼쪽은 메뉴 이름까지 보이는 펼친 사이드바, 오른쪽은 접기 버튼을 눌러 아이콘만 남긴 접힌 사이드바입니다. 접힌 쪽은 본문(캘린더)이 넓어지는 대신 메뉴 이름이 사라지니 아이콘에 마우스를 올리면 이름이 뜨는 툴팁을 같이 붙입니다.

사이드바 레이아웃: 왼쪽 240px 사이드바에 메뉴(아이콘+이름)와 팀 목록, 접기 버튼을 누르면 72px 아이콘만 남고 마우스를 올리면 툴팁으로 이름. 사이드바는 화면 높이에 고정, 본문만 스크롤. 1023px 이하에서는 사이드바를 숨기고 햄버거 버튼으로 열기.

"사이드바는 고정, 본문만 스크롤"은 적어 두는 편이 좋습니다. 이 한 줄이 없으면 본문을 내릴 때 사이드바가 같이 올라갈지 제자리에 남을지를 AI가 고릅니다. 메뉴가 길지 않은 앱이라면 대부분 제자리에 남는 쪽을 원하실 것 같습니다.

화면 폭과 여백

마지막 세 개는 화면 폭이 바뀔 때와 칸 사이를 얼마나 띄울지에 관한 이름입니다. 바이브코딩으로 만든 화면이 "어딘가 어설퍼 보이는" 이유가 이 셋에 몰려 있는 경우가 많다고 생각합니다.

11. 반응형·브레이크포인트 (Responsive · Breakpoint)

반응형은 화면 폭에 따라 배치가 바뀌는 것이고 브레이크포인트는 배치가 바뀌는 폭의 경계값입니다. "768px부터는 2열" 할 때 768px이 브레이크포인트입니다.

크게 보기

음료 브랜드 fizzbloom 페이지 하나를 실제로 390·768·1440px 창에서 열어 나란히 놓았습니다(그림을 세 장 따로 그린 게 아니라 페이지 하나가 폭에 따라 바뀐 모습입니다). 1024px 이상은 상품 카드 4열, 768~1023px은 2열에 메뉴를 햄버거 버튼으로 접고, 767px 이하는 히어로를 제목 → 설명 → 버튼 → 캔 그림 순서로 세로로 쌓았습니다.

브레이크포인트 숫자는 정답이 있는 건 아닙니다. 흔히 휴대폰 390px 안팎, 태블릿 세로 768px, 작은 노트북 1024px, 데스크톱 1440px을 기준으로 잡습니다. 다만 요청할 때는 숫자 하나보다 구간으로 말하는 게 안전합니다. "768px"이라고만 하면 768px이 태블릿에 들어가는지 휴대폰에 들어가는지 AI가 정해야 하기 때문입니다.

반응형은 세 구간으로: 데스크톱(1024px 이상) 카드 4열, 태블릿(768~1023px) 카드 2열·햄버거 메뉴, 휴대폰(767px 이하) 카드 2열·히어로는 제목 → 버튼 → 그림 순서로 세로. 어느 폭에서도 가로 스크롤 없이.

이 요청문이 실제로 "반응형으로" 한마디와 얼마나 다른 결과를 내는지가 이번 글의 실험입니다.

12. 컨테이너·최대 폭 (Container · Max width)

내용을 담는 가운데 상자가 컨테이너이고, 화면이 아무리 넓어도 그 상자가 일정 폭을 넘지 않게 막는 상한이 최대 폭(max-width)입니다.

크게 보기

숙소 예약 서비스 Driftnest 페이지를 1920px 모니터 폭에서 렌더했습니다. 최대 폭이 없는 위쪽은 검색창과 카드가 화면 끝까지 늘어나고 문단 한 줄이 1,834px입니다. 한 줄이 이만큼 길면 다음 줄 첫 글자를 찾느라 눈이 길을 잃습니다. 아래쪽은 내용을 가운데 1200px 안에 담고(양옆 360px은 비움) 긴 문단은 680px에서 끊어 다섯 줄이 됐습니다.

헷갈리는 짝은 풀 블리드(Full-bleed)입니다. 배경색이나 큰 사진은 화면 끝까지 채우고(풀 블리드) 그 위의 글과 버튼만 컨테이너 안에 두는 게 흔한 조합입니다.

모든 섹션의 내용은 최대 폭 1200px 컨테이너 안에 가운데 정렬, 좌우 여백 데스크톱 40px·휴대폰 16px. 긴 문단은 680px까지. 섹션 배경색은 화면 끝까지.

13. 여백 (Padding · Margin · Gap)

빈 공간에도 이름이 셋 있습니다. 패딩(padding)은 상자 안쪽 여백, 마진(margin)은 상자 바깥 여백, 갭(gap)은 칸과 칸 사이 간격입니다. 액자로 치면 그림과 액자 테두리 사이의 흰 매트가 패딩이고, 벽에 건 액자와 액자 사이가 갭, 액자 묶음과 벽 끝 사이가 마진입니다.

크게 보기

fizzbloom 상품 카드 세 장을 여백이 부족한 버전(왼쪽, 패딩 4px·갭 4px·마진 0)과 여백을 정한 버전(오른쪽, 패딩 20px·갭 24px·마진 80px)으로 놓았습니다. 오른쪽에는 브라우저 개발자 도구처럼 패딩은 초록, 갭은 보라, 마진은 주황으로 칠했습니다. 카드 내용과 색은 같은데 왼쪽은 글자가 테두리에 붙어 답답하고 오른쪽은 정돈돼 보입니다. 달라진 건 숫자 세 개뿐입니다.

"좀 더 여유 있게"는 AI가 해석할 여지가 큰 말입니다. 어디를 얼마나 띄울지 이름과 숫자로 말하면 한 번에 끝납니다.

여백: 카드 안쪽 패딩 20px, 카드 사이 갭 데스크톱 24px·휴대폰 12px, 섹션 위아래 마진 80px(휴대폰 48px).

아래 실험에서도 여백 숫자는 적은 만큼만 지켜졌습니다. B 요청에 카드 사이 간격을 데스크톱 24px, 휴대폰 12px로 적었더니 결과도 정확히 24px, 12px이었고 적지 않은 태블릿(768px)은 20px이 나왔습니다. 숫자를 준 칸은 그대로, 비운 칸은 AI가 채운다는 0편의 결론이 여백에서도 똑같았습니다.

"반응형으로" 한마디와 폭별 지정

용어를 정리하다 보니 궁금해졌습니다. 반응형이라는 이름만 말해도 AI는 휴대폰 화면을 꽤 잘 만듭니다. 그럼 브레이크포인트까지 숫자로 정해 주는 건 얼마나 차이가 날까요?

같은 fizzbloom 홈페이지를 두 가지로 Claude Code에 시켰습니다. Claude Code 2.1.316을 화면 없이 실행하는 모드(claude -p)로, 모델은 따로 지정하지 않았고(두 번 모두 Claude Opus 5.5로 돌았습니다) 두 요청을 각각 새 세션에서 같은 시각에 한 번씩 돌렸습니다.

두 요청 앞부분은 똑같습니다. 색과 구성(스티키 헤더, 스플릿 히어로, 상품 카드 8개, 벤토 그리드, 푸터)을 이 글의 이름으로 적었습니다.

탄산음료 브랜드 'fizzbloom'의 홈페이지를 HTML 파일 하나로 만들어줘. 색은 바탕 #FD550A, 보조 #015D47, 포인트 #E0F354 세 가지와 흰색만 쓰고 포인트는 주문 버튼에만. (중략)

1. 스티키 헤더: 로고, 메뉴 4개(Flavors·Story·Stores·FAQ), 장바구니 버튼
2. 스플릿 히어로: 왼쪽에 제목·설명·'지금 주문하기' 버튼, 오른쪽에 음료 캔 그림
3. 상품 카드 8개: 맛 이름·한 줄 설명·가격·담기 버튼
4. 벤토 그리드: 브랜드 특징 4가지(무설탕, 천연 과즙, 재활용 캔, 정기 배송)를 크기가 다른 칸으로
5. 푸터: 링크 묶음 4개(제품·회사·고객지원·SNS)와 저작권 줄

A는 그 뒤에 한 줄만 붙였습니다.

(A) 반응형으로 만들어줘.

B는 화면 폭을 세 구간으로 나눠 구간마다 열 수와 순서를 적었습니다.

(B) 반응형은 화면 폭을 세 구간으로 나눠줘.

• 데스크톱(1024px 이상): 콘텐츠 최대 폭 1200px, 가운데 정렬. 상품 카드 4열, 벤토 그리드 4열(무설탕 칸이 2×2로 가장 크게), 푸터 4열.
• 태블릿(768~1023px): 헤더 메뉴는 햄버거 버튼으로 접기. 히어로는 좌우 배치 유지. 상품 카드 2열, 벤토 2열, 푸터 2열.
• 휴대폰(767px 이하): 좌우 여백 16px. 히어로는 제목 → 설명 → 주문 버튼 → 캔 그림 순서로 세로로 쌓기. 상품 카드 2열, 벤토 1열(무설탕 칸이 맨 위), 푸터 1열.
• 카드 사이 간격은 데스크톱 24px, 휴대폰 12px. 어느 폭에서도 가로 스크롤이 생기지 않게.

만들어진 HTML은 손대지 않고 Chromium에서 390·768·1024·1440px 폭으로 열었습니다. 가로 스크롤이 생기는지, 상품 카드·벤토·푸터가 한 줄에 몇 칸인지, 히어로가 어떤 순서로 쌓이는지, 메뉴가 햄버거로 접히는지를 Playwright(브라우저를 코드로 조작하는 도구) 스크립트로 쟀고 스크립트 값은 스크린샷과 하나씩 맞춰 봤습니다.

결과부터 말하면 둘 다 멀쩡했습니다. 네 폭 어디에서도 가로 스크롤이 생기지 않았고 스티키 헤더, 주문 버튼에만 칠한 포인트 색, 1440px에서 내용 폭 1200px까지 같았습니다. "반응형으로" 한마디만으로도 휴대폰에서 깨지는 화면은 나오지 않았습니다.

차이는 바뀌는 폭에서 났습니다. 두 HTML에서 화면 폭에 따라 배치를 바꾸는 규칙(CSS 미디어 쿼리)을 꺼내 자 위에 찍어 봤습니다.

크게 보기

B는 적은 대로 1023px과 767px 두 곳에서 한꺼번에 바뀝니다(359px 이하 아주 좁은 화면용 규칙이 하나 더 있습니다). A는 부품마다 따로 정했습니다. 카드는 1080px, 벤토는 960px, 히어로는 900px, 메뉴는 860px에서 바뀌고 그 아래 600·560·520·480px에서 한 번씩 더 바뀝니다. 브레이크포인트가 여덟 개입니다.

틀린 건 아닙니다. 부품마다 가장 자연스럽게 접히는 폭을 따로 고른 것에 가깝습니다. 다만 그 사이 폭에서는 예상하지 못한 조합이 나옵니다. 예를 들어 880px 창에서 A는 히어로가 이미 세로로 쌓였는데 메뉴는 아직 펼쳐져 있습니다.

크게 보기

768px에서 A는 히어로를 세로로 쌓았고 B는 적은 대로 좌우를 유지했습니다. 390px 첫 화면은 둘 다 무난했습니다. A는 글 → 버튼 → 숫자 세 칸 → 캔, B는 제목 → 설명 → 버튼 → 캔 순서였고 둘 다 주문 버튼이 첫 화면 안에 들어왔습니다. 위 첫 화면 항목에서 걱정한 "그림 먼저 쌓기"는 두 결과 모두 하지 않았습니다.

가장 눈에 띄는 차이는 상품 카드입니다.

크게 보기

1024px은 작은 노트북 폭인데 A는 상품 카드를 2열로 크게 놓았고 B는 4열이었습니다. 390px에서는 A가 카드를 가로형 1열(그림 왼쪽, 글 오른쪽)로 바꿔 8개를 세로로 늘어놓았고 B는 적은 대로 2열이었습니다. 그래서 휴대폰 페이지 길이가 A 5,665px, B 4,837px로 A가 800px 넘게 깁니다. 확인한 항목을 표로 정리했습니다.

몇 가지를 더 적어 두겠습니다.

• 두 세션 기록을 열어 보니 둘 다 스스로 화면을 찍어 확인했습니다. A는 Edge 브라우저로 1440px과 390px(그리고 375px) 화면을, B는 Playwright로 1440·900·375px 화면을 찍어 읽었습니다. 둘 다 768px과 1024px은 한 번도 보지 않았습니다. A의 1024px 카드 2열이 그대로 남은 게 이 때문인지는 한 번씩 돌린 것으로는 알 수 없습니다.
• 벤토는 A도 무설탕 칸을 맨 위에, 데스크톱에서 가장 크게 뒀습니다. 요청 목록의 첫 번째가 무설탕이라 그렇게 읽은 것 같습니다. 순서를 적어 둔 것만으로도 꽤 강하게 작동한 셈입니다.
• 숫자 지어내기는 이번에도 나왔습니다. 둘 다 "한 캔 15kcal", "100% 재활용 알루미늄"을 넣었고 과즙 함량은 A 12%, B 10%로 서로 달랐습니다. 0편 실험과 같은 결과라서 아래 요청문 모음 마지막 줄에 "숫자는 지어내지 말기"를 넣었습니다.

레이아웃 요청문 모음

위에서 용어마다 적은 요청문을 랜딩 페이지 하나를 처음 만드는 순서로 이어 붙였습니다. 숫자는 예시라서 본인 화면에 맞게 바꿔 쓰시면 되고 결과가 어떻게 나와도 괜찮은 줄은 지워도 됩니다.

전체: 모든 섹션 내용은 최대 폭 1200px 컨테이너 안에 가운데 정렬, 좌우 여백 데스크톱 40px·휴대폰 16px. 섹션 배경색은 화면 끝까지. 반응형: 데스크톱(1024px 이상), 태블릿(768~1023px), 휴대폰(767px 이하) 세 구간. 어느 폭에서도 가로 스크롤 없이.

1. 스티키 헤더: 왼쪽 로고, 가운데 메뉴 4개, 오른쪽 주 버튼. 스크롤 80px부터 반투명 배경과 그림자. 태블릿부터 메뉴는 햄버거 버튼. 메뉴를 눌러 이동한 섹션 제목이 헤더에 가리지 않게.
2. 히어로 섹션(스플릿): 왼쪽에 아이브로·헤드라인·서브카피·주 버튼(포인트 색)·보조 버튼, 오른쪽에 그래픽. 휴대폰에서는 제목 → 설명 → 버튼 → 그래픽 순서로 쌓고 헤드라인과 주 버튼이 첫 화면(390×844) 안에.
3. 카드 레이아웃: 카드 8개, 데스크톱 4열·태블릿 2열·휴대폰 2열, 카드 사이 갭 24px(휴대폰 12px), 카드 높이 같게, 제목은 두 줄까지.
4. 벤토 그리드: 4열 격자, 주인공 칸은 2×2, 태블릿 2열, 휴대폰 1열로 쌓되 주인공 칸이 맨 위.
5. 푸터: 링크 묶음 4열과 뉴스레터 입력칸, 맨 아래 저작권·약관 한 줄. 태블릿 2열, 휴대폰 1열.
6. 여백: 카드 안쪽 패딩 20px, 섹션 위아래 마진 80px(휴대폰 48px).
7. 숫자·후기·고객사 이름은 지어내지 말고 자리만 비워 두기.

개인적인 생각 & 한계점

이번 실험 전에는 "반응형으로"만 쓰면 휴대폰 화면이 어딘가 깨질 거라고 생각했습니다. 막상 해 보니 가로 스크롤 하나 없이 깔끔했습니다. 그래서 레이아웃 이름의 쓸모를 상황별로 나눠 봤습니다.

1. 처음 만들 때 - 스티키 헤더, 스플릿 히어로, 벤토 그리드처럼 이름 몇 개와 "반응형으로"면 깨지지 않는 첫 결과가 나옵니다. 대신 태블릿과 작은 노트북에서 어떻게 보일지는 AI가 부품마다 따로 정합니다. 사용자가 주로 휴대폰과 큰 모니터로 들어오는 서비스라면 이 정도로도 충분할 수 있다고 생각합니다.

2. 특정 폭이 마음에 안 들 때 - 개인적으로는 브레이크포인트라는 이름이 가장 쓸모 있는 순간이 여기라고 생각합니다. "노트북에서 카드가 너무 커"보다 "1024px 이상은 카드 4열"이 고칠 곳과 고칠 값을 한 번에 가리킵니다. A의 1024px 화면을 B처럼 바꾸려면 이 한 줄이면 됩니다.

3. 결과를 확인할 때 - 실험의 두 세션 모두 768px과 1024px은 직접 보지 않았습니다. 그래서 요청 끝에 "390·768·1024·1440px 네 폭에서 스크린샷을 찍어 확인해 줘"처럼 확인할 폭까지 적어 두는 걸 추천합니다. 브라우저 개발자 도구의 기기 모드에서 폭을 직접 바꿔 보셔도 됩니다.

한계도 적어 두겠습니다.

• 실험은 A·B 각 1회입니다. "반응형으로"라고 하면 항상 브레이크포인트가 여덟 개 나온다는 뜻은 아닙니다. 같은 요청도 돌릴 때마다 결과가 달라집니다.
• 측정은 Chromium 창 폭을 바꿔 가며 한 것이고 실제 휴대폰·태블릿 기기에서 보지는 않았습니다. 주소창 높이나 글자 크기 설정 같은 기기 차이는 반영되지 않았습니다.
• 열 수와 순서는 Playwright 스크립트로 재고 스크린샷과 하나씩 맞춰 봤습니다. 스크립트가 처음에 버튼 안 화살표 아이콘을 히어로 그림으로 잘못 짚은 곳은 화면을 보고 고쳤습니다.
• 용어별 그림은 이 글을 위해 직접 만든 가상의 화면이고 브레이크포인트·여백 숫자는 흔히 쓰는 예시일 뿐 정답 값은 아닙니다.
• 용어는 디자인 도구마다 부르는 이름이 조금씩 다릅니다. 매서너리를 벽돌형 그리드, 스플릿 레이아웃을 투 칼럼 레이아웃이라고 부르는 곳도 있어서 쓰는 도구가 있다면 그 도구의 이름을 따르는 게 안전합니다.

이 글을 마치며

다음 글에서는 2편 내비게이션을 다루겠습니다. 이번 글에서 "햄버거 버튼으로 접기"라고 한 줄로 넘어간 부분부터 탭과 세그먼트 컨트롤, 브레드크럼, 페이지네이션과 무한 스크롤, 하단 탭 바까지 "어디로 가게 할까"에 해당하는 이름들입니다. 390px 화면에서 메뉴를 열고 닫고 키보드로만 움직여 보는 실험도 같이 해 볼 생각입니다.

같이 보면 좋은 글은 다음과 같습니다.

• 바이브코딩 UI 용어 사전 0편 : 화면 세 장의 이름표, 요청문 5칸, 시리즈 9편의 순서가 있습니다. 이 글의 요청문도 그 5칸을 따랐습니다.
• 포인트 컬러 고르는 법 : 이 글의 가상 브랜드 아홉 개와 색이 모두 여기서 나왔습니다. 포인트 색을 CTA 버튼에만 칠한 이유도 여기 있습니다.
• 바이브코딩 디자인 레퍼런스 사이트 : 마음에 드는 레이아웃을 찾을 때 볼 만한 사이트를 정리했습니다. 찾은 화면을 위 13개 이름으로 쪼개 보면 AI에게 설명하기가 쉬워집니다.

긴 글 읽어주셔서 감사합니다 :)