웹페이지는 어떻게 만들어질까: 주민센터 비유로 보는 HTML, CSS, Javascript

바이브코딩으로 무언가를 만들다 보면 묘한 순간이 온다. 결과물은 나온다. 버튼도 있고, 글자도 보이고, 뭔가 눌리기도 한다. 그런데 정작 내가 지금 뭘 보고 있는지는 모르겠다. 화면 전체가 하나의 덩어리처럼 느껴지기 때문이다.

웹페이지는 실제로 한 덩어리가 아니다. 서로 다른 역할을 맡은 세 층이 겹쳐진 결과물이다. 이 글은 그 층을 문법으로 가르치는 글이 아니다. 큰 그림을 머릿속에 그리는 게 목표다. 오늘은 그 이야기를 주민센터에서 서류를 받는 장면으로 풀어보려 한다.

1. HTML은 서류 양식이다

주민센터에 전입신고를 하러 갔다고 해보자. 창구에서 전입신고서를 받으면, 아직 아무것도 적기 전인데도 종이에는 이미 구조가 있다. 이름 칸, 주소 칸, 서명란, 동의 체크박스, 주의사항 영역. 어디에 무엇을 적어야 하는지 먼저 정해져 있다.

HTML이 딱 이 역할이다. 웹페이지에 무엇이 있는지, 어떤 것이 제목이고 어떤 것이 버튼이고 어떤 것이 입력창인지를 선언하는 층이다. 브라우저는 그 선언을 읽고 화면을 구성한다. HTML 없이 텍스트만 있다면, 어떤 부분이 누를 수 있는 버튼이고 어떤 부분이 그냥 글자인지 구분할 방법이 없다.

HTML은 원래 문서를 구조화해서 공유하기 위한 단순한 언어에서 출발했다. 지금은 거의 모든 웹페이지의 기본 뼈대 역할을 한다.

“예쁘게 만드는 기술”이 아니라는 점이 중요하다. HTML은 오직 “이 페이지에 뭐가 있는가”만 정한다.

HTML section illustration — structured blank form at a municipal service desk

2. CSS는 문서가 읽히게 만드는 규칙이다

이번에는 다른 민원 서류를 받았는데 뭔가 불편하다. 어떤 서류는 제목이 너무 작고, 어떤 서류는 줄 간격이 너무 좁고, 어떤 서류는 중요한 안내문이 눈에 안 들어온다. 직원마다 자기 방식으로 서류를 만든 것이다.

결국 민원팀장이 공통 규칙을 정한다. 대제목은 이 크기, 본문은 이 간격, 중요 안내는 이 색. 그러자 서류는 훨씬 읽기 쉬워진다.

이것이 CSS다. 내용 자체는 그대로인데, 그것이 어떤 모양으로 보일지를 정한다. 글자 크기, 색, 여백, 배치. 이 모든 것이 CSS의 영역이다. HTML이 “무엇이 어디에 있는가”라면, CSS는 “그것이 어떻게 보이는가”다. 같은 HTML 구조도 CSS에 따라 읽기 편한 페이지가 되기도 하고, 어디를 먼저 봐야 할지 모르는 페이지가 되기도 한다.

웹 초창기에는 구조와 모양을 한데 섞어 적는 경우가 많았다. 페이지가 복잡해지면서, 스타일만 따로 다루는 CSS가 필요해졌다.

CSS section illustration — messy and neatly formatted application papers

3. Javascript는 그 자리에서 반응하는 직원이다

복잡한 신청서를 내야 하는 날이다. 서류 칸만 봐서는 무엇부터 적어야 할지 모르겠다. 창구 직원에게 물으니, 형광펜으로 “여기부터 먼저 쓰세요” 하고 표시해준다. 어떤 칸은 지금은 비워두라고 알려주고, 항목을 잘못 적으려 하면 “이건 주소가 아니라 본적란입니다” 하고 바로 잡아준다.

Javascript가 이런 역할을 한다. 버튼을 눌렀을 때 페이지 전체가 새로 뜨지 않고 그 자리에서 내용이 바뀌거나, 이메일 형식이 틀렸을 때 즉시 오류 메시지가 나타나는 것. 이런 반응이 모두 Javascript의 몫이다. HTML과 CSS만으로 “있는 것”과 “보이는 것”은 만들 수 있지만, 사용자의 행동에 응답하려면 Javascript가 필요하다.

Javascript는 웹페이지에 동작과 반응성을 더하기 위해 등장했다. 이름이 비슷해서 Java와 혼동하기 쉬운데, 둘은 전혀 다른 언어다.

주민센터 비유로 묶으면 이렇다. HTML이 종이 서류고, CSS가 그 서류를 보기 좋게 만드는 규칙이라면, Javascript는 그 자리에서 안내하는 직원의 손짓이다.

Javascript section illustration — clerk guiding a form in real time

4. 결국 웹페이지는 세 층이 겹쳐진 결과물이다

중요한 건 정의를 외우는 일이 아니다. 세 기술이 각자 다른 일을 맡고 있다는 감각을 잡는 것이다.

• HTML: 무엇이 어디에 있는지 정하는 양식
• CSS: 그것이 어떻게 보일지 정하는 규칙
• Javascript: 상황에 따라 어떻게 반응할지 정하는 동작

셋은 경쟁 관계가 아니다. 양식이 있어야 내용을 담을 수 있고, 규칙이 있어야 읽기 쉽고, 반응이 있어야 경험이 자연스럽다. 실제 브라우저에서 보는 페이지도 이 세 층 위에 만들어진다.

이 감각이 생기면, “페이지가 이상하다”는 막연한 느낌이 구체적인 질문으로 바뀐다. 구조가 꼬인 건가? 모양이 깨진 건가? 눌렀을 때 반응이 없는 건가? 이 정도만 구분돼도 어디서부터 살펴봐야 할지 감이 생긴다.

5. 지금 필요한 건 문법보다 지도다

바이브코딩에서 AI가 코드를 대신 만들어줄 때, 그 결과물이 어느 층의 문제인지 모른 채 넘어가기 쉽다. 잘 될 때는 상관없지만, 한 번 어긋나기 시작하면 어디서부터 봐야 할지 알 수 없게 된다.

그럴 때 필요한 건 HTML 태그를 외우거나 CSS 문법을 완벽히 아는 것이 아니다. 지금 보이는 문제가 양식의 문제인지, 꾸밈의 문제인지, 반응의 문제인지 구분할 수 있는 아주 얇은 지도다. 그 지도가 생기면, 주민센터 서류처럼 복잡해 보이는 웹페이지도 세 층이 각자 하는 일을 하고 있다는 게 보이기 시작한다.