HTML은 꺾쇠로 여닫는 상자다 — 태그, head와 body
웹사이트 하나를 떠올려 보자. 맨 위에 로고와 메뉴가 붙어 있고, 그 아래 큰 배너, 사례를 옆으로 넘겨 보는 슬라이드, 상담 신청란이 있다. 맨 밑에는 사업자 정보와 개인정보 처리방침 링크가 모인 영역이 있는데 이것을 푸터라고 부른다. 브라우저(크롬·사파리처럼 웹페이지를 여는 프로그램)에서는 그림처럼 보이지만, 실제로는 이 구조를 적어 둔 코드가 있다. 그 코드가 HTML이다.
HTML은 꺾쇠 괄호로 약속을 정했다. <html>처럼 꺾쇠 안에 이름을 쓰면 상자가 열리고, </html>처럼 이름 앞에 슬래시(/)를 넣으면 같은 이름의 상자가 닫힌다. 이 한 쌍을 태그라고 한다. 상자 안에는 또 다른 태그가 들어갈 수 있어서, 바깥 태그를 부모, 안쪽 태그를 자식이라고 부른다. 가장 바깥의 부모는 html 태그로 정해져 있다.
html 안의 첫 자식은 둘이다. 눈에 보이지 않는 head와 눈에 보이는 body다. 강의는 이 이름을 편지지에 빗댔다. 편지지 윗부분에 로고와 수신인을 넣는 자리를 레터헤드라고 하듯, head에는 화면에 그려지지 않는 이 페이지의 기본 정보가 들어간다. 검색엔진이 이 페이지를 이해하는 데 필요한 정보, 이 페이지가 끌어다 쓰는 다른 파일로 가는 연결 같은 것들이다. body는 말 그대로 몸통, 우리가 보는 화면 전부다.
head 안의 대표 태그가 둘 있다. 페이지의 기본 정보를 적는 meta 태그는 예외적으로 닫는 태그 없이 하나로 끝난다. title 태그는 열고 닫는데, 그 사이에 쓴 글자가 브라우저 위쪽 탭에 뜨는 페이지 제목이 된다.
직접 볼 수도 있다. 아무 웹페이지에서 F12 키를 누르면(크롬 기준. 맥은 Cmd+Option+I를 누르거나 오른쪽 위 점 세 개 메뉴의 도구 항목에서 연다) 개발자 도구라는 창이 열리고 그 페이지의 HTML이 보인다. 다만 바이브 코딩으로 만든 프로젝트 파일에서는 이런 HTML 원문을 거의 못 본다. 요즘은 다른 틀 위에서 만든 코드를 인터넷에 올리는 시점에 한꺼번에 HTML로 조립하는 방식이 일반적이라서다.
<html>
<head>
<meta charset="utf-8">
<title>상담 신청</title>
</head>
<body>
<!-- 눈에 보이는 화면 전부가 여기에 -->
</body>
</html>태그 이름은 마음대로 지어도 되는데 왜 다들 같은 이름을 쓰나 — 시맨틱 마크업
body 안에 넣는 태그 이름은 사실 마음대로 지어도 동작한다. 강의자는 자기 이니셜을 따서 <yss>라는 태그를 열고 닫아도 된다고 예를 들었다. 그런데 여러 사이트를 개발자 도구로 열어 보면 같은 태그 이름이 계속 보인다.
이유는 검색이다. SEO(검색엔진 최적화, 검색엔진이 내 페이지를 잘 찾고 이해하게 만드는 일)와 GEO(생성형 AI 최적화, AI가 질문에 답할 때 내 페이지를 근거로 삼게 만드는 일)에서는 페이지 구조가 약속대로 적혀 있는지가 중요하다. 검색엔진과 AI가 태그 이름만 보고도 이 부분이 메뉴인지, 입력 양식인지 알아볼 수 있어야 하기 때문이다. 그래서 다들 쓰는 이름으로 쓰자는 약속이 생겼고, 이를 시맨틱 마크업(뜻이 드러나는 태그 쓰기)이라고 한다.
처음 떠올린 웹사이트에 맞춰 보면 이렇다. 맨 위 메뉴 줄은 내비게이션 바, 그 안에서 눌러 이동하는 메뉴 하나하나는 내비게이션 아이템이라고 부르고, 태그로는 nav를 쓴다. 한 칸 한 칸 나뉜 구역은 section이다. 상담 신청란처럼 입력하고 선택하고 제출하는 묶음은 form이다. 구글에서 설문을 만들 때 쓰는 구글 폼의 그 폼, 곧 양식이다.
form 안에서 짧은 글을 입력하는 칸은 input이고, meta처럼 닫는 태그가 없다. 누르는 버튼은 button이다. form에는 제출을 눌렀을 때 입력값이 어디로 갈지를 적는 자리가 있다. 푸터의 이용약관·개인정보 처리방침처럼 누르면 다른 페이지로 가는 링크는 a, 목록은 전체를 ul로 감싸고 항목 하나하나를 li로 적는다.
약속을 어겨도 화면은 뜬다. 약속은 이 부분이 무엇을 뜻하는지 읽는 쪽에 알려 주는 표시다. 바이브 코딩이 없던 시절에는 이 이름들을 익혀 가며 썼는데, 가짓수가 그렇게 많지 않아 외운다기보다 몇 번 보면 익숙해지는 것들이라고 강의는 말한다.
| 화면에서 보이는 것 | 태그 | 강의 예시 |
|---|---|---|
| 맨 위 메뉴 줄 | nav | 로고와 메뉴가 있는 내비게이션 바 |
| 한 칸씩 나뉜 구역 | section | 배너, 사례 슬라이드, 상담 신청란 |
| 입력·선택·제출 묶음 | form | 상담 신청 양식 |
| 짧은 글 입력 칸 | input (닫는 태그 없음) | 이름, 연락처 |
| 누르는 버튼 | button | 보내기 |
| 다른 페이지로 가는 링크 | a | 이용약관, 개인정보 처리방침 |
| 목록 | ul(전체) · li(항목) | 체크리스트 |
속성과 class — style이 길어져서 CSS로 빼냈다
태그 이름 뒤, 꺾쇠를 닫기 전에는 설정값을 더 적을 수 있다. 이름=값 쌍으로 적는 이 설정을 속성(attribute)이라고 한다. 속성 이름도 원칙적으로는 마음대로 지을 수 있지만, 태그처럼 자주 쓰는 이름이 정해져 있다.
가장 대표적인 속성이 class다. class가 왜 생겼는지부터 보자. HTML만 있던 시절에는 구조만 적으면 됐다. 그런데 사람들은 더 보기 좋게 꾸미고 싶어 했다. 화면 구역을 나눌 때 흔히 쓰는 div 태그(division, 구역의 줄임)에 style 속성을 붙여 background: red라고 쓰면 그 구역 배경이 빨갛게 칠해진다.
꾸밀 거리가 배경색 하나로 끝나지 않는다는 게 문제였다. 안쪽 간격, 테두리, 다른 태그와의 거리, 옆으로 늘어세울지 위아래로 쌓을지까지 적다 보면 태그 하나가 한없이 길어진다. 사람이 읽기 어렵고, 같은 꾸밈이 이 페이지 저 페이지에서 반복된다. 그래서 꾸밈 정보를 CSS(Cascading Style Sheets, 꾸밈만 모아 두는 별도 문서)로 빼내고, 꾸밈 묶음마다 이름을 붙인 뒤 태그에는 그 이름만 적게 됐다. 그 이름을 적는 자리가 class다. 개발자 도구로 아무 사이트나 열어 보면 거의 모든 태그에 class가 붙어 있는 이유다.
특별한 기능이 약속된 속성도 있다. 이미지를 띄우는 img 태그에 src 속성을 주고 주소를 적으면, 그 주소에 저장된 이미지가 화면에 뜬다. 06편의 사례 카드와 이어지는 대목이다. 카드의 이미지가 관리자가 올린 것이라면, 이 src 자리에 들어갈 이미지 주소도 데이터베이스(엑셀처럼 줄과 칸으로 값을 저장해 두는 곳)에 저장된 값이다.
<!-- style 속성에 꾸밈을 직접 적으면 길어진다 -->
<div style="background: red; padding: 16px; border: 1px solid black; display: flex;">메뉴</div>
<!-- 꾸밈은 CSS로 빼고, 태그에는 이름만 적는다 -->
<div class="nav-bar">메뉴</div>
<!-- img의 src 속성 = 이미지가 저장된 주소 -->
<img src="https://example.com/case-01.jpg">컴포넌트 — 카드·다이얼로그처럼 자주 쓰는 부품에 붙은 이름
태그에 약속된 이름이 있듯, 화면 부품에도 다들 공유하는 이름이 있다. 이것을 컴포넌트라고 한다. 06편의 사례 목록에서 제목·고객사·이미지·날짜가 든 네모가 반복되는데, 이것을 카드라고 부른다. HTML에 card라는 태그가 있는 건 아니다. 사람들이 그 모양을 카드라고 부르기로 한 것이다. 제출을 눌렀는데 입력이 빠져 경고창이 뜬다면 그 창은 다이얼로그다.
어떤 의도를 화면에 드러낼 때 자주 쓰는 부품을 미리 만들어 둔 것이 컴포넌트이고, 알파벳 A부터 Z까지 늘어놓을 수 있을 만큼 종류가 많다. 무엇을 만들든 거의 반드시 쓰게 되는 것들이라, 누군가 미리 만들어 둔 것을 가져다 쓰는 것이 지금의 일반적인 개발 방식이다.
바이브 코딩에서 자주 만나는 것이 shadcn/ui다. 강의는 이름 끝의 cn을 className, 곧 앞 절에서 본 class 이름의 줄임으로 풀었다. style이 길어져 class로 묶었듯, class 이름 묶음을 미리 만들어 컴포넌트 단위로 가져다 쓸 수 있게 모은 라이브러리(가져다 쓰는 부품 모음)라는 설명이다. 같은 일을 하는 모음은 이름이 다른 것도 많고, 강의자가 예전에 많이 쓴 Bootstrap도 그중 하나다. 그때는 이런 모음이 쓰는 class 이름 규칙을 외워 가며 썼지만 지금은 그럴 필요가 없다고 강의는 말한다. 덧붙이면 이름의 shadcn은 이 라이브러리를 만든 사람의 아이디다. shadcn/ui 코드 안에서 class 이름을 합치는 도구 함수의 이름이 cn()이라, 강의의 풀이는 이렇게 기억하면 편하다는 뜻으로 받아들이면 된다.
외울 필요가 없는 대신 이름은 알아야 한다. 강의는 이것을 UI(사용자가 보고 누르는 화면 요소) 전달력이라고 부른다. AI에게 「사례를 보기 좋게 보여줘」라고 말하는 것과 「사례를 카드로 나열하고, 입력을 빠뜨린 채 제출하면 다이얼로그로 알려줘」라고 말하는 것은 받는 결과가 다르다. 부품 이름을 알면 원하는 화면을 말로 옮길 수 있고, AI가 만든 화면을 보고 무엇이 빠졌는지도 짚을 수 있다.
오늘 해볼 일은 하나다. shadcn/ui 사이트(ui.shadcn.com)에 들어가 메뉴의 Components를 연다. A부터 Z까지 컴포넌트가 쭉 나온다. 이것저것 눌러 보며 이 부품은 어떤 의도를 드러내려고 만들어 둔 것인지 하나씩 짚어 본다.
쓰는 앱의 화면을 데이터와 상태로 관찰하기
컴포넌트를 눌러 보다 보면 공통점이 보인다. 대부분 데이터를 다루거나, 데이터에 따라 모습이 바뀐다. 05편의 상담 신청 폼은 입력값을 데이터베이스에 저장하는 흐름을 따랐고, 06편의 사례 카드 필터는 지금 무엇을 보여 줄지를 담은 상태(state, 화면이 기억하고 있는 현재 선택값)로 움직였다.
강의가 권하는 관점이 이것이다. 화면 뒤에 데이터베이스에 저장된 데이터가 있고, 그 화면을 그렇게 표시하기 위한 상태가 있다는 걸 바닥에 깔고 화면을 본다. 그러면 평소 쓰던 앱에서 재미있는 것이 많이 보인다.
에어비앤비를 열어 그 안의 버튼들이 어떻게 움직이는지 본다. Threads를 열어 본다. 평소 쓰는 앱을 열고 그 안에서 동작하는 UI를 유심히 본다. 이 목록은 어떤 데이터의 배열(여러 값을 대괄호로 묶은 목록)일까, 이 탭은 겉모습만 다른 라디오 버튼(여러 개 중 하나만 고르는 버튼)일까, 지금 눌린 선택은 어떤 상태로 기억될까를 물어 보는 식이다.
관찰한 것을 AI에게 넘길 때는 컴포넌트 이름과 데이터·상태를 함께 적는다. 아래는 06편의 사례 카드 섹션을 그렇게 옮긴 요청문 예시다.
이것으로 「화면 뒤의 데이터」 연재를 마친다. 01~04편은 ERD(데이터를 어떤 표에 나눠 담고 어떻게 이을지 그린 설계도) 강의를 따라 데이터가 어떻게 저장되는지를, 05~07편은 HTML 강의를 따라 그 데이터가 화면에서 어떤 모양으로 드러나는지를 봤다. 강의는 HTML을 아는 것이 바이브 코딩의 기획과 설계에 두고두고 도움이 되는 지식이라는 말로 마무리한다. 화면을 부품 이름과 데이터·상태로 말할 수 있으면, AI에게 맡기는 일도 그만큼 정확해진다.
사례 섹션을 만들어 줘. shadcn/ui 컴포넌트를 써 줘.
- 사례 하나는 카드(Card)로 보여 줘. 카드에는 제목, 고객사, 이미지, 날짜가 들어가.
- 사례 데이터는 관리자가 등록한 것을 불러와. 화면에 고정값으로 박아 넣지 마.
- 사례마다 화면에는 안 보이는 유형(A·B·C) 값이 있어.
- 카드 목록 위에 전체·A·B·C를 탭(Tabs)으로 꺼내 보여 줘. 드롭다운 안에 숨기지 마.
- 지금 선택된 탭은 상태로 관리하고, 한 번에 하나만 선택되게 해 줘.