바이브코딩 UI 용어 사전: 화면 부품 이름 32개와 AI 요청문 5칸

이전 글에서는 포인트 컬러 고르는 법을 다루면서 가상의 사이트 아홉 개에 색을 칠해 봤습니다. 색을 정하고 나면 그다음에 막히는 건 대부분 말입니다. 바이브코딩(코드를 직접 짜지 않고 AI에게 말로 시켜서 서비스를 만드는 방식)을 하다 보면 "오른쪽에서 스르륵 나오는 그거", "누르면 밑으로 펼쳐지는 그거"처럼 이름을 몰라서 설명이 길어지는 순간이 자주 옵니다.

그래서 화면 부품의 이름을 정리하는 시리즈를 시작합니다. 총 9편으로 나눠서 한 편에 질문 하나씩(어디에 둘까, 무엇을 띄울까, 어떻게 움직일까 등) 다룰 예정입니다. 이 글은 그 첫 편이자 색인입니다.

이번 글에서는 랜딩 페이지·대시보드·모바일 앱 화면 세 장을 직접 만들어 부품마다 이름표를 붙이고, 같은 홈페이지를 세 가지 말투로 Claude에게 시켜서 이름을 아는 게 결과를 얼마나 바꾸는지 확인해 보겠습니다. 마지막으로 시리즈 전체에서 쓸 요청문 틀(5칸)을 정리하겠습니다.

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

화면 세 장의 이름표

먼저 가장 흔한 화면 세 종류에 이름표를 붙였습니다. 홈페이지 첫인상을 맡는 랜딩 페이지, 업무 도구에서 자주 보는 대시보드, 그리고 휴대폰 앱입니다.

1. 랜딩 페이지

크게 보기

위에서부터 읽어 보겠습니다. 맨 위 메뉴 줄이 내비게이션 바(Navbar)입니다. 스크롤을 내려도 화면 위에 붙어 따라오게 만들면 스티키 헤더(Sticky header)라고 부릅니다. 그 아래 첫 화면을 크게 차지하는 소개 영역이 히어로 섹션(Hero section)이고 그 안에서 "눌러 주세요"를 맡는 버튼이 CTA(Call to Action, 행동 유도) 버튼입니다. 포인트 컬러 글에서 포인트 색을 아껴 두라고 했던 자리가 바로 여기입니다.

히어로 아래 고객사 이름을 한 줄로 늘어놓은 영역은 로고 띠(Logo cloud)라고 합니다. "이런 회사들이 이미 쓴다"로 믿음을 주는 장치라서 마케팅 쪽에서는 소셜 프루프(social proof, 남들도 쓴다는 증거)라고도 부릅니다. 같은 모양의 카드를 줄 맞춰 늘어놓은 서비스 소개는 카드 그리드(Card grid), 고객 한마디를 크게 보여 주는 칸은 후기(Testimonial), 질문을 누르면 답이 펼쳐지는 FAQ는 아코디언(Accordion), 맨 아래 회사 정보와 링크 묶음은 푸터(Footer)입니다.

2. 대시보드

크게 보기

대시보드는 부품이 많아서 선 대신 번호만 찍었습니다. 왼쪽에 세로로 붙은 메뉴가 사이드바(Sidebar)이고 제목 위의 "Workspace / Projects / Q4 Launch"처럼 지금 위치까지 지나온 길을 보여 주는 줄이 브레드크럼(Breadcrumb)입니다. 헨젤과 그레텔이 숲에 떨어뜨린 빵부스러기에서 온 이름이라고 합니다.

여기서 헷갈리기 쉬운 게 화면 위에 잠깐 겹쳐 뜨는 것들입니다. 아이콘에 마우스를 올리면 뜨는 짧은 설명이 툴팁(Tooltip), "Sort: Due date"를 누르면 아래로 펼쳐지는 선택지가 드롭다운 메뉴(Dropdown menu), 오른쪽 아래에 "Standup moved to 10:30 · Undo"처럼 잠깐 떴다 사라지는 알림이 토스트(Toast)입니다. 셋 다 겹쳐 뜨지만 뜨는 계기(마우스 올림·클릭·작업 완료)가 다릅니다. 반대로 "In review"처럼 표 안에 계속 붙어 있는 작은 상태 표시는 배지(Badge)입니다.

나머지는 이름 그대로입니다. 같은 자리에서 Overview·Timeline을 바꿔 보는 탭(Tabs), 숫자 하나를 크게 보여 주는 통계 카드(Stat card), 정렬·필터가 되는 표 데이터 테이블(Data table), 목록을 쪽 번호로 나누는 페이지네이션(Pagination), 동그란 프로필 사진을 겹쳐 놓은 아바타 그룹(Avatar group)입니다.

3. 모바일 앱

크게 보기

휴대폰은 화면이 좁아서 같은 기능이라도 이름이 바뀌는 경우가 있습니다. 맨 위 위치·날짜 줄은 상단 바(App bar), 맨 아래 Explore·Saved 같은 주요 메뉴 줄은 하단 탭 바(Tab bar)입니다. "All·Sea view·Pool"처럼 작게 눌러서 거르는 버튼들은 칩(Chips), 사진 아래 작은 점들은 옆으로 넘겨 보는 캐러셀(Carousel)이 있다는 표시입니다. 화면 위에 떠 있는 "Map" 버튼은 플로팅 버튼(Floating action button)이라고 부릅니다.

오른쪽은 필터 아이콘을 눌렀을 때입니다. 아래에서 올라와 화면 절반 이상을 덮는 패널이 바텀 시트(Bottom sheet)입니다. 데스크톱에서 옆으로 열리는 패널(드로어)의 휴대폰판이라고 보시면 됩니다. 그 안의 가격 범위 막대가 슬라이더(Slider), "Any·1+·2+·3+"처럼 붙어 있는 버튼 중 하나를 고르는 게 세그먼트 컨트롤(Segmented control), 켜고 끄는 스위치가 토글 스위치(Toggle switch), 여러 개를 고를 수 있는 네모가 체크박스(Checkbox)입니다. 세그먼트 컨트롤은 탭과 생김새가 비슷한데, 탭은 보는 화면을 바꾸고 세그먼트 컨트롤은 값을 고른다는 점이 다릅니다.

세 장에 붙인 이름을 시리즈 순서대로 모았습니다. 아래 5칸 그림에 나오는 드로어까지 32개입니다.

같은 홈페이지, 세 가지 말투

이름표를 붙이고 나니 궁금해졌습니다. 이름을 모르면 AI가 못 알아들을까요? 그리고 이름만 알면 원하는 화면이 나올까요?

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

세 요청 앞에는 아래 문장을 똑같이 붙였습니다.

AI 컨설팅 회사 'clearsight'의 랜딩 페이지를 HTML 파일 하나로 만들어줘. 데스크톱 1440px 기준이고 휴대폰에서도 볼 수 있어야 해. 색은 바탕 #DBF2FC, 보조 #072D59, 포인트 #FD6E88 세 가지만 쓰고 포인트는 주 버튼에만. 외부 이미지·외부 폰트·외부 스크립트 없이 CSS와 JS는 파일 안에 넣어줘.

그 뒤에 붙인 본문만 다릅니다. A는 이름을 하나도 쓰지 않고 머릿속 화면을 말로 설명했습니다.

(A) 맨 위에는 회사를 소개하는 큰 화면을 넣어줘. 스크롤을 내려도 메뉴는 계속 보이면 좋겠어. 그 아래 우리 고객사들을 보여주고, 서비스 세 가지를 소개해줘. 자주 묻는 질문도 넣는데 질문을 누르면 답이 보이게 해줘. 상담 신청 버튼을 누르면 신청서가 옆에서 나오게 해줘.

B는 같은 내용을 UI 이름만으로 적었습니다.

(B) 구성: 스티키 헤더, 히어로 섹션, 로고 띠, 서비스 카드 3개, FAQ 아코디언. 상담 신청은 오른쪽 드로어로.

C는 아래에서 설명할 5칸(이름·위치·계기·동작·예외)에 맞춰 부품마다 적었습니다.

(C)

1. 스티키 헤더: 화면 맨 위에 고정. 오른쪽에 '상담 신청' 버튼.
2. 히어로 섹션: 왼쪽에 제목·설명·버튼 두 개(주 버튼 '무료 상담 신청'은 포인트 색, 보조 버튼은 외곽선), 오른쪽에 그래픽. 휴대폰에서는 위아래로 쌓기.
3. 로고 띠: 히어로 바로 아래, 가상의 고객사 6곳을 글자 로고로 한 줄.
4. 서비스 카드 3개: 데스크톱 3열, 768px 이하에서는 1열.
5. FAQ 아코디언: 질문 5개. 질문을 누르면 답이 펼쳐지고, 하나를 열면 나머지는 닫힘. 키보드로도 열고 닫을 수 있게.
6. 상담 신청 드로어: 헤더와 히어로의 상담 버튼을 누르면 오른쪽에서 폭 420px로 열림. Esc, 바깥 클릭, 닫기 버튼으로 닫힘. 열리면 첫 입력칸에 포커스, 닫히면 누른 버튼으로 포커스가 돌아가고, 열린 동안 뒤 화면 스크롤은 잠금. 휴대폰에서는 화면 전체를 덮음.
7. 신청서를 보내면 화면 아래에 '신청이 접수됐습니다' 토스트를 3초 띄우고 드로어를 닫음.
8. 기기에서 모션 줄이기를 켠 사용자에게는 애니메이션을 끔.

본문 길이는 공백 포함 A 150자, B 63자, C 526자입니다. 만들어진 HTML은 손대지 않고 Chromium에서 열어 데스크톱(1440px)과 휴대폰(390px) 화면을 찍었습니다. 버튼 누르기·Esc·바깥 클릭·스크롤 같은 동작은 Playwright(브라우저를 코드로 조작하는 도구) 스크립트로 확인했고 스크립트가 잘못 짚은 곳은 화면을 직접 보고 바로잡았습니다.

크게 보기

솔직히 A는 예상과 달랐습니다. 이름을 하나도 안 썼는데도 스티키 헤더, 히어로, 서비스 카드 3개, 펼쳐지는 FAQ, 오른쪽 신청 패널까지 전부 들어갔습니다. 세 화면을 멀리서 보면 거의 같은 사이트입니다. 차이는 가까이 들여다봐야 보입니다. 확인한 항목을 표로 정리했습니다.

Esc로 닫기, 첫 입력칸 포커스, 스크롤 잠금처럼 꽤 세밀한 동작은 A와 B도 시키지 않았는데 알아서 넣었습니다. 반대로 결과가 갈린 곳은 전부 따로 정해 주지 않은 부분이었습니다. 가장 차이가 큰 곳은 고객사 영역입니다.

크게 보기

A의 "우리 고객사들을 보여주고"는 제목·설명·로고 격자·고객 후기까지 붙은 섹션 하나가 됐습니다. B의 "로고 띠"는 옆으로 계속 흘러가는 띠가 됐는데, 움직이는 요소라 일시정지 버튼까지 달아 뒀습니다.

크게 보기

C는 "한 줄, 6곳, 글자 로고"라고 적은 그대로 멈춰 있는 한 줄이었습니다. 세 결과 모두 틀린 건 아닙니다. 다만 본인이 머릿속에 그린 게 셋 중 하나라면, 나머지 둘은 고쳐 달라고 다시 말해야 합니다.

신청 패널도 비슷했습니다.

크게 보기

셋 다 오른쪽 패널이 열리고 첫 칸에 커서가 가 있습니다. 폭은 A 520px, B 540px였고 420px로 적은 C만 420px였습니다. 신청서를 보낸 뒤는 더 달랐습니다. A와 B는 패널 안에 완료 화면을 띄우고 "확인"이나 "닫기"를 눌러야 닫히는 방식을 골랐고, C는 적은 대로 토스트를 3초 띄우고 패널을 닫았습니다. 어느 쪽이 낫다기보다 그냥 다른 선택인 것 같습니다.

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

• B는 63자로 A(150자)와 같은 뼈대를 받았습니다. 이름이 하는 일은 AI를 알아듣게 만드는 것보다 같은 내용을 짧게 말하게 해 주는 것에 가까운 것 같습니다.
• C는 대화 턴이 12번이었습니다. 기록을 열어 보니 C는 HTML을 파일로 쓴 뒤 Edge 브라우저로 열어 스크린샷을 찍고 그 스크린샷을 다시 읽으면서 고쳤습니다. B는 파일을 쓰고 문법 검사만 했고 A는 한 번에 답했습니다. 요청이 구체적이라 스스로 확인할 거리가 생긴 건지 우연인지는 한 번씩 돌린 것으로는 알 수 없습니다.
• 세 결과 모두 숫자를 지어냈습니다. A는 "180+ 수행 프로젝트, 92% 고객 재계약률"과 이름을 가린 고객 후기를, B는 "80여 개 기업"을, C는 "120+ 누적 AI 프로젝트, 87% 고객 재계약률"을 넣었습니다. 포인트 컬러 글의 실험에서도 가입자 수를 지어 넣은 적이 있었는데, 이번에도 셋 다 같았습니다. 실제 서비스라면 반드시 지워야 하는 문구입니다.

요청문 5칸

실험에서 결과가 갈린 곳을 거꾸로 보면, AI에게 무엇을 더 말해야 하는지가 보입니다. 이걸 다섯 칸으로 정리했습니다.

크게 보기

1. 이름 - 무슨 부품인지. 위 표의 32개 같은 이름입니다. 실험에서는 이름이 있으면 같은 내용을 반도 안 되는 길이로 말할 수 있었습니다.

2. 위치 - 어디에, 얼마나 크게. "오른쪽, 폭 420px", "히어로 바로 아래 한 줄"처럼 적습니다. 실험에서 패널 폭(520·540·420px)과 고객사 영역 모양이 갈린 칸입니다.

3. 계기 - 언제 나타나고 언제 바뀌는지. "헤더와 히어로의 상담 버튼을 누르면", "스크롤이 80px을 넘으면", "저장이 끝나면" 같은 조건입니다.

4. 동작 - 어떻게 움직이고 어떻게 닫히는지. "하나를 열면 나머지는 닫힘", "토스트 3초 후 닫힘"이 여기 들어갑니다. FAQ 동작과 신청 후 처리가 갈린 칸입니다.

5. 예외 - 휴대폰, 빈 화면, 모션 줄이기 설정처럼 평소와 다른 상황. 이번 실험에서는 셋 다 휴대폰에서 패널을 화면 전체로 바꿔서 차이가 없었지만 이 칸을 비우면 AI가 고르는 대로 갑니다.

미용실에서 머리를 자를 때와 비슷하다고 생각합니다. "투블럭으로 해 주세요"라고 하면 설명이 짧아집니다. 그런데 윗머리를 몇 cm 남길지, 앞머리는 그대로 둘지까지 말하지 않으면 디자이너의 기본값으로 잘립니다. 스타일 이름이 1칸이고 길이와 예외가 나머지 4칸입니다.

머릿속 말을 5칸으로 바꾼 예를 몇 개 적어 봤습니다.

복사해서 쓰실 수 있게 빈칸으로 바꾼 틀은 다음과 같습니다.

[이름]으로 만들어 줘. [위치]에, [크기]로. [계기]하면 나타나고, [동작]하면 닫혀. [예외 상황]에서는 [다르게 할 것].

다섯 칸을 매번 다 채울 필요는 없다고 생각합니다. 위 실험에서 A가 고른 520px 패널이 마음에 든다면 위치 칸은 비워 둬도 됩니다. 다른 결과가 나와도 괜찮은 칸은 비우고, 꼭 그렇게 나와야 하는 칸만 채우는 것이 요청을 짧게 유지하는 방법입니다.

시리즈 순서

이 글을 포함해 9편으로 나눴습니다. 편마다 질문 하나를 맡고 용어마다 화면을 직접 만들어 띄워 놓고 비교합니다. 색은 포인트 컬러 글의 아홉 조합을 그대로 쓰고 포인트 색은 CTA처럼 눈길을 모아야 할 곳에만 칠합니다.

본편에서는 헷갈리는 짝을 같은 화면에 나란히 띄워 비교할 생각입니다. 예를 들면 5편의 모달과 드로어는 이런 식입니다.

크게 보기

둘 다 화면 위에 겹쳐 뜨지만 모달은 지금 답을 받아야 할 때(내보낼까요?), 드로어는 화면을 보면서 설정을 고칠 때 씁니다. 이런 짝이 시리즈 전체에 열 개 넘게 있습니다.

개인적인 생각 & 한계점

이번 실험 전에는 이름을 모르면 AI가 엉뚱한 걸 만들 거라고 생각했습니다. 막상 해 보니 지금 모델은 "옆에서 나오게"만으로도 드로어를 만들고 Esc로 닫기까지 알아서 넣었습니다. 그래서 이름의 가치는 알아듣게 만드는 것보다 다른 데 있는 것 같습니다.

1. 처음 화면을 만들 때 - 이름은 요청을 짧게 만들어 줍니다. B는 63자로 A와 같은 뼈대를 받았습니다. 대신 이름만 나열하면 나머지는 AI 기본값으로 채워지니, 꼭 그렇게 나와야 하는 부분만 5칸으로 덧붙이는 걸 추천합니다.

2. 만든 화면을 고칠 때 - 개인적으로는 이름이 가장 쓸모 있는 순간이 여기라고 생각합니다. "아래쪽 그거 좀 이상해"보다 "FAQ 아코디언에서 하나 열면 나머지는 닫히게"가 고칠 곳과 고칠 내용을 한 번에 가리킵니다. A의 FAQ를 C처럼 바꾸려면 이 한 문장이면 됩니다.

3. 마음에 드는 사이트를 보고 따라 만들 때 - 디자인 레퍼런스 사이트 글에서 레퍼런스를 보여 주면 결과가 달라진다고 했는데, 레퍼런스 화면을 보면서 위 해부도처럼 부품 이름을 먼저 짚어 두면 "이 사이트의 로고 띠처럼, 단 멈춰 있게"처럼 일부만 골라 가져오기 쉬워집니다.

한계도 적어 두겠습니다.

• 실험은 A·B·C 각 1회입니다. 같은 요청도 돌릴 때마다 결과가 달라지기 때문에 "일상어로 말해도 항상 이렇게 나온다"고 일반화하긴 어렵습니다.
• C는 브라우저로 스스로 확인하는 과정을 거쳤고 A는 그러지 않았습니다. 결과 차이가 요청 내용 때문인지, 이 확인 과정 때문인지는 이번 실험으로 나눌 수 없습니다.
• 동작 확인은 Playwright 스크립트와 화면 확인을 섞었습니다. 모션 줄이기는 CSS에 설정이 들어 있는지만 봤고 실제로 애니메이션이 꺼지는지는 확인하지 않았습니다.
• 용어는 업계에서 흔히 쓰는 뜻을 기준으로 적었습니다. 토스트를 스낵바(Snackbar), 드로어를 시트(Sheet)라고 부르는 디자인 시스템도 있어서 쓰는 도구가 있다면 그 도구의 이름을 따르는 게 안전합니다.
• 화면 세 장은 이 글을 위해 만든 가상의 화면입니다. 부품 배치는 흔한 예시일 뿐 정답 배치는 아닙니다.

이 글을 마치며

다음 글에서는 1편 레이아웃을 다루겠습니다. 히어로 섹션부터 벤토 그리드, 반응형까지 "무엇을 어디에 둘까"에 해당하는 이름들을 화면 폭 세 개(1440·768·390px)에서 직접 렌더해 비교해 볼 생각입니다.

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

• 포인트 컬러 고르는 법 : 이 시리즈의 화면 색이 모두 여기서 나왔습니다. 포인트 색을 어디에 칠할지 정하는 규칙도 함께 있습니다.
• 바이브코딩 디자인 레퍼런스 사이트 : 따라 만들 화면을 찾을 때 볼 만한 사이트 다섯 곳을 정리했습니다.
• Claude Code 프론트엔드 디자인 도구 : AI에게 디자인 규칙을 주는 도구 쪽 이야기입니다.

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