AI 웹개발 기초: 프론트엔드 1-1 | 프론트엔드는 왜 이렇게 복잡해졌을까

프론트엔드를 공부하려고 하면 이상하게 기술 이름부터 몰려온다.

HTML, CSS, JavaScript까지는 그래도 알 것 같다. 그런데 곧바로 React, Vue, Angular, Next.js, TypeScript, Node.js, npm, Vite, Webpack, CSR, SSR, hydration 같은 단어가 따라붙는다. 처음 웹 화면 하나를 만들고 싶었을 뿐인데, 갑자기 생태계 전체를 알아야 할 것처럼 느껴진다.

이 글은 그 복잡함을 기술 목록으로 외우지 않기 위한 첫 번째 정리다. 프론트엔드는 어느 날 갑자기 복잡해진 분야가 아니다. 웹 문서가 구조, 표현, 동작, 상태, API 통신, 성능, 배포까지 책임지게 되면서 생긴 문제 해결의 축적이다.

그래서 1편에서는 React나 Next.js부터 시작하지 않는다. 웹이 무엇이었고, HTML/CSS/JavaScript가 왜 나뉘었고, 브라우저와 서버의 역할이 어떻게 바뀌면서 프론트엔드라는 일이 커졌는지를 먼저 본다.

이번 공부에서 내가 붙잡은 문장은 이것이다.

프론트엔드는 웹 문서가 점점 더 많은 책임을 맡으면서 생긴 문제 해결의 축적이다.

프론트엔드는 기술 이름이 아니라 웹이 떠안은 책임의 역사다

프론트엔드를 처음 배울 때 흔한 오해가 있다.

프론트엔드는 화면을 예쁘게 꾸미는 일이고, 백엔드는 중요한 로직을 다루는 일이라는 생각이다. 이 구분은 아주 초기의 정적 페이지를 떠올리면 어느 정도 맞아 보인다. HTML 문서를 만들고, CSS로 색과 여백을 입히고, 서버는 파일을 보내면 끝나는 그림이다.

하지만 지금의 웹 화면은 그렇게 단순하지 않다.

로그인 상태에 따라 메뉴가 바뀐다. 검색어를 입력하면 목록이 다시 그려진다. 장바구니 수량을 바꾸면 가격이 즉시 바뀐다. 글 페이지는 검색엔진에 잘 읽혀야 하고, 공유했을 때 미리보기도 제대로 나와야 한다. 접근성 도구가 버튼과 입력창의 의미를 이해해야 하고, 모바일 화면에서도 내용이 깨지지 않아야 한다.

이런 책임이 브라우저 쪽으로 쌓이면서 프론트엔드는 "화면 꾸미기"보다 훨씬 넓은 일이 됐다.

프론트엔드는 이제 사용자가 만지는 UI, 브라우저가 이해하는 문서 구조, 서버 API와의 계약, 상태 변화, 성능, 접근성, 검색 노출, 빌드와 배포 결과까지 함께 다룬다.

그래서 프론트엔드를 기술명으로 시작하면 길을 잃기 쉽다. 먼저 봐야 할 것은 문제의 순서다.

문서를 연결해야 했다
-> 구조와 주소와 전송 규칙이 필요했다
-> 표현을 분리해야 했다
-> 사용자 행동에 반응해야 했다
-> 브라우저 차이를 견뎌야 했다
-> 서버 데이터로 화면 일부를 바꿔야 했다
-> UI 상태를 추적해야 했다
-> 개발 코드와 배포 코드를 다르게 다뤄야 했다

이 흐름을 잡으면 React나 Next.js도 갑자기 튀어나온 유행어가 아니라, 앞선 문제들이 커진 뒤에 등장한 선택지로 보인다.

웹은 앱이 아니라 문서를 연결하려고 시작했다

먼저 인터넷과 웹을 나눠야 한다.

인터넷은 컴퓨터들이 서로 연결되는 기반망에 가깝다. 웹은 그 기반망 위에서 문서를 주소로 찾고, 링크로 이동하고, 규칙에 따라 주고받는 서비스다. 그래서 웹의 출발점은 앱이 아니라 문서 공유였다.

초기의 핵심 문제는 단순했다.

연구 문서가 많아지고, 그 문서들이 서로 연결되어야 했다. 어떤 문서는 다른 문서를 참고하고, 어떤 개념은 다른 개념으로 이어진다. 파일을 하나씩 복사하거나 경로를 따로 알려주는 방식으로는 불편했다.

그래서 웹은 하이퍼텍스트의 방식으로 문서를 연결했다. 문서 안에 링크를 두고, 그 링크를 누르면 다른 문서로 이동한다. 지금은 너무 당연해서 별것 아닌 것처럼 보이지만, 웹의 힘은 여기서 시작했다.

프론트엔드 공부에서 이 출발점이 중요한 이유가 있다. 지금 우리가 만드는 복잡한 웹 앱도 결국 브라우저가 어떤 주소의 문서를 받아 해석하는 일에서 출발한다. 아무리 React를 쓰고 Next.js를 써도, 사용자는 URL로 들어오고 브라우저는 HTML을 읽는다.

웹은 앱처럼 보이게 발전했지만, 뿌리는 여전히 문서다.

HTML, URL, HTTP는 역할을 셋으로 나눴다

웹이 문서를 연결하려면 세 가지가 필요했다.

첫째, 문서 안의 구조를 표현하는 방법이 필요했다. 이것이 HTML이다.

둘째, 문서가 어디에 있는지 가리키는 주소가 필요했다. 이것이 URL이다.

셋째, 브라우저와 서버가 문서를 어떻게 요청하고 응답할지 정하는 규칙이 필요했다. 이것이 HTTP다.

이 세 가지를 한 줄로 줄이면 이렇게 볼 수 있다.

HTML: 문서의 구조
URL: 문서의 주소
HTTP: 문서를 주고받는 규칙

예를 들어 사용자가 브라우저 주소창에 어떤 주소를 입력한다. 브라우저는 그 URL을 보고 서버에 HTTP 요청을 보낸다. 서버는 HTML 문서를 응답한다. 브라우저는 그 HTML을 읽고 화면을 만든다.

물론 실제 웹은 이미지, CSS, JavaScript, font, API 요청까지 함께 오가므로 훨씬 복잡하다. 하지만 처음 모델은 이 정도로 잡아도 된다.

사용자
-> URL 입력
-> 브라우저가 HTTP 요청
-> 서버가 HTML 응답
-> 브라우저가 HTML을 해석해 화면 표시

여기서 중요한 점은 HTML이 단순한 "화면 모양"이 아니라는 것이다. HTML은 브라우저가 읽는 구조다. 제목, 문단, 링크, 목록, 버튼, 입력창 같은 의미를 담는다. 이 의미가 제대로 잡혀야 브라우저도, 검색엔진도, 보조기술도 페이지를 더 잘 이해한다.

HTML은 태그 암기가 아니라 브라우저가 읽는 의미 구조다

HTML을 처음 배울 때는 태그 목록처럼 보인다.

h1, p, a, img, button, input, form, section, nav, main, footer.

물론 태그를 알아야 한다. 하지만 HTML을 태그 암기로만 보면 중요한 부분을 놓친다. HTML은 브라우저가 문서를 이해하기 위한 입력이다.

브라우저는 HTML source를 그대로 화면에 붙이지 않는다. 먼저 HTML을 파싱해서 DOM tree를 만든다. 그리고 DOM과 CSS를 바탕으로 화면을 그릴 구조를 만든다. 동시에 DOM, native HTML semantics, ARIA 정보를 바탕으로 접근성 트리도 만든다.

HTML source
-> DOM tree

DOM + CSS
-> render tree
-> layout
-> paint

DOM + HTML semantics + ARIA
-> accessibility tree

여기서 semantic HTML이 중요해진다.

예를 들어 저장 버튼을 만든다고 하자.

<button type="button">저장</button>

이 코드는 브라우저에게 "이것은 버튼이다"라고 말한다. 버튼은 focus를 받을 수 있고, keyboard로 조작할 수 있고, disabled 상태를 가질 수 있고, form 안에서는 submit 동작과도 연결된다. screen reader 같은 보조기술도 이 요소를 버튼으로 이해한다.

반대로 이렇게 만들 수도 있다.

<div onclick="save()">저장</div>

겉으로는 버튼처럼 보일 수 있다. CSS를 입히면 더더욱 그렇다. 하지만 의미상으로는 일반 container인 div다. 브라우저는 이 요소를 기본 버튼으로 이해하지 않는다. keyboard 조작, focus 처리, disabled 상태, 접근성 이름 같은 것을 개발자가 직접 보완해야 한다.

그래서 semantic HTML의 기본 원칙은 간단하다.

HTML에 이미 있는 의미라면 native element를 먼저 쓴다.

폼도 마찬가지다. label, input, name, type, required, fieldset, legend는 단순히 모양을 만드는 장치가 아니다. 브라우저가 입력의 의미를 이해하고, 사용자가 keyboard와 보조기술로 조작하고, 제출 데이터의 key를 구성하게 만드는 구조다.

프론트엔드가 단지 "보이는 화면"만 만드는 일이 아니라는 사실은 여기서부터 드러난다. 같은 모양의 버튼이라도 브라우저가 이해하는 의미는 다를 수 있다.

CSS는 꾸미기 전에 구조와 표현을 분리한 장치였다

HTML만으로 문서를 만들던 시절에는 문서 구조와 표현이 쉽게 섞인다.

제목은 커야 하고, 중요한 문장은 빨간색이어야 하고, 표는 일정한 간격을 가져야 한다. 이런 표현 규칙을 HTML 안에 직접 섞으면 문서가 많아질수록 유지보수가 어려워진다.

CSS는 이 문제를 줄이기 위해 등장한 표현 계층이다.

HTML은 문서의 구조와 의미를 맡고, CSS는 그 구조가 어떻게 보일지 맡는다.

HTML: 이것은 제목이다
CSS: 제목은 크게, 굵게, 위아래 여백을 둔다

이 분리는 단순히 코드를 예쁘게 나누는 문제가 아니다. 같은 HTML 구조라도 화면 크기나 매체에 따라 다르게 보일 수 있다. 데스크톱에서는 2열 layout을 쓰고, 모바일에서는 1열로 쌓을 수 있다. 어두운 배경에서는 색을 바꾸고, 인쇄할 때는 다른 스타일을 적용할 수 있다.

하지만 CSS도 곧 독립적인 난도를 갖게 됐다. 이유는 CSS가 색을 칠하는 언어가 아니라 충돌을 해결하고 박스를 배치하는 규칙 체계이기 때문이다.

CSS가 어려운 이유는 색보다 충돌과 배치에 있다

CSS에서 가장 먼저 부딪히는 문제는 "왜 내 스타일이 적용되지 않지?"다.

같은 요소에 여러 CSS 규칙이 동시에 걸릴 수 있다. 어떤 규칙은 브라우저 기본 스타일에서 오고, 어떤 규칙은 reset에서 오고, 어떤 규칙은 component class에서 오고, 어떤 규칙은 utility class에서 온다. 이때 브라우저는 cascade 규칙으로 최종 값을 고른다.

대략 이런 질문을 순서대로 한다.

어디서 온 스타일인가?
!important가 있는가?
어떤 cascade layer인가?
선택자가 얼마나 구체적인가?
나중에 선언됐는가?

여기서 specificity가 나온다. button보다 .primary-button이 더 구체적이고, .card .footer button처럼 깊은 선택자는 더 강해진다. 처음에는 강한 선택자가 편해 보인다. 그런데 계속 강한 선택자로 덮어쓰기 시작하면 나중에는 더 강한 선택자나 !important가 필요해진다.

그래서 실무 CSS에서는 "강하게 이기는 것"보다 "나중에 고치기 쉽게 낮은 specificity를 유지하는 것"이 중요해진다.

그다음 문제는 layout이다.

브라우저는 모든 요소를 사각형 박스로 계산한다. content, padding, border, margin이 있고, 이 박스들이 normal flow, flexbox, grid 같은 layout algorithm에 따라 배치된다.

CSS selector와 declaration
-> cascade / specificity로 최종 스타일 결정
-> box model로 크기와 간격 계산
-> flexbox / grid로 배치
-> viewport 조건에 따라 responsive layout 조정

Flexbox와 Grid도 여기서 등장한다.

Flexbox는 한 방향 흐름을 정렬하는 데 좋다. header 안에서 logo와 nav를 양쪽으로 보내거나, 버튼 안에서 icon과 text를 나란히 놓거나, tag badge들을 줄바꿈하며 배치할 때 자연스럽다.

Grid는 큰 판을 짜는 데 좋다. 글 목록을 1열/2열로 바꾸거나, 본문과 목차를 2열로 나누거나, dashboard card들을 행과 열로 배치할 때 자연스럽다.

그래서 "CSS는 디자인"이라고만 말하면 부족하다. CSS는 브라우저가 박스를 계산하고 배치하는 방식이다. 프론트엔드에서 layout이 별도 기술처럼 느껴지는 이유가 여기에 있다.

JavaScript는 문서를 사용자 행동에 반응하게 만들었다

HTML과 CSS만 있으면 문서를 만들 수 있다. 구조가 있고, 표현이 있다. 하지만 사용자가 무언가를 했을 때 화면이 바뀌려면 동작이 필요하다.

JavaScript는 그 동작을 맡았다.

버튼을 눌렀을 때 메뉴를 열고, 입력값이 비어 있으면 오류를 보여주고, 체크박스를 누르면 총액을 다시 계산하고, 서버에 요청을 보내 결과를 화면에 반영한다.

이때 JavaScript가 직접 화면 픽셀을 칠한다고 생각하면 모델이 흐려진다. 더 정확히는 JavaScript가 DOM을 읽고 바꾼다. 브라우저는 바뀐 DOM과 CSS를 바탕으로 layout과 paint를 다시 계산한다.

사용자 click
-> event handler 실행
-> JavaScript가 DOM 변경
-> browser가 rendering 결과 갱신

이 설명은 2편에서 더 자세히 다룰 내용이다. 1편에서는 핵심만 잡으면 된다.

JavaScript가 붙으면서 웹 문서는 "읽는 문서"에서 "조작하는 화면"으로 바뀌기 시작했다.

브라우저가 여러 개가 되자 같은 코드가 다르게 보였다

웹이 널리 쓰이기 시작하자 브라우저도 많아졌다. 문제는 브라우저마다 HTML, CSS, JavaScript, DOM API 지원 방식이 조금씩 달랐다는 점이다.

개발자 입장에서는 같은 코드를 썼는데 어떤 브라우저에서는 되고, 어떤 브라우저에서는 깨지는 일이 생긴다. 지금도 완전히 사라진 문제는 아니다. 다만 표준화와 브라우저 개선 덕분에 예전보다 많이 줄었을 뿐이다.

이 시기에는 cross-browser 대응이 큰 일이었다.

요소를 찾는 방법, 이벤트를 붙이는 방법, AJAX 요청을 보내는 방법이 브라우저마다 다르면 개발자는 매번 차이를 감안해야 한다. 그래서 jQuery 같은 library가 큰 생산성 도구가 됐다.

jQuery의 가치는 "짧게 쓸 수 있다"에만 있지 않았다. 더 큰 가치는 브라우저 차이를 감싸고, DOM 조작과 이벤트 처리와 비동기 요청을 일관된 API로 다루게 해준 데 있었다.

$(".button").on("click", function () {
  $(".message").text("저장했습니다.");
});

이런 코드는 지금 보면 오래된 스타일처럼 보일 수 있다. 하지만 당시에는 복잡한 브라우저 차이를 줄이고, 화면 일부를 쉽게 바꾸게 해준 중요한 진전이었다.

기술은 맥락 없이 낡거나 새롭지 않다. jQuery는 그 시대의 문제를 해결했다. 그리고 웹 UI가 더 커지자 다른 문제가 나타났다.

서버가 모든 HTML을 만들던 구조에서 화면과 데이터가 분리됐다

초기 웹에서는 서버가 완성된 HTML을 만들어 보내는 경우가 많았다.

사용자가 /posts로 이동하면 서버가 글 목록 HTML을 만들고, /posts/1로 이동하면 서버가 상세 페이지 HTML을 만든다. 브라우저는 새 HTML 문서를 받아 화면을 다시 표시한다.

이 구조는 단순하고 강하다. URL마다 서버가 HTML을 만들어 보내므로 검색엔진도 본문을 읽기 쉽고, 브라우저도 응답을 받아 그대로 표시하면 된다.

그런데 사용자는 점점 더 앱 같은 경험을 기대하게 됐다.

검색 조건을 바꿀 때마다 전체 페이지가 깜빡이지 않았으면 좋겠다. 댓글을 작성했을 때 글 전체를 다시 받지 않고 댓글 목록만 갱신됐으면 좋겠다. 장바구니 수량을 바꾸면 총액만 즉시 바뀌었으면 좋겠다.

이 요구가 AJAX와 API 통신의 중요성을 키웠다.

AJAX의 핵심은 페이지 전체를 새로고침하지 않고 JavaScript가 서버와 비동기 통신해 필요한 부분만 갱신하는 것이다. 현대 웹에서는 XML보다 JSON을 많이 쓰지만, 중요한 것은 이름의 XML이 아니라 비동기 요청과 부분 갱신이다.

예전 방식:
URL 이동
-> 서버가 새 HTML 전체 생성
-> 브라우저가 전체 화면 교체

부분 갱신 방식:
사용자 action
-> JavaScript가 API 요청
-> JSON data 응답
-> 필요한 DOM/UI만 갱신

이 변화가 프론트엔드의 책임을 크게 늘렸다.

서버는 점점 "화면을 완성해 보내는 곳"만이 아니라 "데이터를 API로 제공하는 곳"이 됐다. 브라우저는 그 데이터를 받아 어떤 화면을 보여줄지 결정하기 시작했다.

여기서부터 프론트엔드는 단순한 문서 작성이 아니라 application 구조에 가까워진다.

프론트엔드는 화면 꾸미기가 아니라 사용자 경험의 계약 지점이 됐다

서버가 HTML을 만들어 보내는 동안에는 많은 결정이 서버 쪽에 있었다. 하지만 브라우저가 API data를 받아 화면을 구성하기 시작하면 프론트엔드가 결정해야 할 것이 늘어난다.

데이터를 언제 요청할 것인가.

로딩 중에는 무엇을 보여줄 것인가.

요청이 실패하면 어떤 오류를 보여줄 것인가.

결과가 비어 있으면 어떤 empty state를 보여줄 것인가.

사용자 입력은 어디에 저장하고, 언제 검증하고, 어떤 형식으로 서버에 보낼 것인가.

이런 질문은 "예쁘게 만들어줘"로는 해결되지 않는다. API contract, UI state, accessibility, error handling, responsive layout, performance가 함께 들어간다.

예를 들어 검색 화면 하나만 봐도 그렇다.

검색어 입력
-> 입력값 상태 저장
-> submit 또는 debounce 후 API 요청
-> loading 표시
-> 결과 목록 표시
-> 결과 없음 표시
-> 오류 표시
-> 모바일/데스크톱 layout 대응
-> keyboard와 screen reader 접근성 확인

이 전체 흐름이 사용자가 실제로 만지는 경험이다. 그래서 프론트엔드는 사용자 경험의 계약 지점이다.

백엔드 API가 아무리 잘 만들어져도, 프론트엔드가 로딩과 오류와 빈 결과를 제대로 처리하지 않으면 사용자는 서비스가 불안정하다고 느낀다. 반대로 프론트엔드가 아무리 화려해도, API data shape와 상태 전이가 정리되지 않으면 화면은 금방 꼬인다.

React와 Next.js는 시작점이 아니라 뒤에서 등장하는 해결책이다

이제 React 이야기를 조금만 예고할 수 있다.

jQuery 방식에서는 이벤트가 발생할 때 개발자가 DOM을 직접 찾아 바꾼다. 작은 화면에서는 충분히 편하다. 하지만 화면이 커지고 상태가 많아지면 문제가 생긴다.

장바구니 수량, 총액, 할인, 배송비, 품절 여부, 버튼 disabled 상태, 오류 메시지가 서로 연결되어 있다고 해보자. 사용자가 수량을 바꿀 때 DOM 여러 곳을 직접 수정해야 한다면, 어느 순간 "지금 화면이 왜 이렇게 보이는지" 추적하기 어려워진다.

React는 이 문제를 다른 방식으로 푼다.

DOM을 직접 계속 바꾸기보다, 현재 state라면 화면이 어떻게 보여야 하는지를 component와 JSX로 선언한다. 상태가 바뀌면 React가 그 상태에 맞춰 UI를 다시 계산하고 DOM 반영을 조율한다.

jQuery식 사고:
이 이벤트가 생기면 이 DOM과 저 DOM을 바꾼다

React식 사고:
현재 state가 이렇다면 화면은 이렇게 보여야 한다

Next.js는 또 다른 층위다. React가 UI library라면, Next.js는 React 위에 routing, SSR/SSG, metadata, image/font optimization, cache 같은 실제 웹 서비스 문제를 묶어주는 framework에 가깝다.

하지만 이 글에서 React와 Next.js를 깊게 들어가지는 않는다. 중요한 것은 순서다.

React와 Next.js는 프론트엔드의 시작점이 아니다. HTML/CSS/JavaScript, 브라우저, API 통신, 상태 추적 문제가 쌓인 뒤에 등장한 해결책이다.

AI에게 웹 작업을 맡길 때도 기술명보다 문제 조건이 먼저다

이 시리즈를 공부하는 이유는 기술 면접 암기가 아니다. AI에게 웹 작업을 더 정확히 맡기기 위해서다.

AI에게 "프론트엔드 만들어줘"라고 하면 결과는 흔들린다. AI는 대충 화면을 만들 수 있지만, 어떤 구조가 필요한지, 어떤 동작이 필요한지, 어떤 접근성이나 API 조건이 있는지 모르면 중요한 부분을 놓칠 수 있다.

질문을 이렇게 바꾸면 훨씬 좋아진다.

이 화면을 semantic HTML 구조로 나누고,
모바일/데스크톱 responsive layout을 잡아줘.

검색어 입력, loading, error, empty state를 포함해서
API 응답 shape에 맞는 UI 상태를 설계해줘.

버튼과 form control의 accessible name,
keyboard 조작 가능성,
screen reader에 전달될 상태 메시지를 점검해줘.

기술명을 말하지 말라는 뜻이 아니다. React를 써야 할 수도 있고, Next.js가 맞을 수도 있다. 하지만 기술명은 문제 조건 뒤에 와야 한다.

좋은 프론트엔드 요청은 보통 이런 순서로 구체화된다.

누가 쓰는 화면인가
어떤 정보를 보여주는가
사용자가 무엇을 입력하거나 클릭하는가
서버와 어떤 data를 주고받는가
로딩/오류/빈 결과는 어떻게 처리하는가
모바일에서는 어떻게 바뀌는가
검색/공유/접근성 요구가 있는가

이 질문들이 있어야 AI가 만든 코드도 검토할 수 있다.

복잡함은 웹 문서가 맡은 책임이 늘어난 결과다

프론트엔드는 복잡하다.

그런데 이유 없이 복잡한 것은 아니다. 웹 문서가 점점 더 많은 책임을 맡았기 때문에 복잡해졌다.

처음에는 문서를 연결하면 됐다. 그래서 HTML, URL, HTTP가 중요했다. 문서가 많아지자 구조와 표현을 분리해야 했다. 그래서 CSS가 필요했다. 사용자가 조작하는 화면이 되자 JavaScript와 DOM이 중요해졌다. 브라우저가 다양해지자 표준화와 library가 필요했다. 서버 데이터로 화면 일부를 바꾸기 시작하자 API 통신과 UI 상태가 프론트엔드의 책임이 됐다.

이 흐름을 이해하면 프론트엔드 생태계가 조금 덜 무섭다.

React, Next.js, Node.js, npm, build, SSR 같은 단어는 이 글의 출발점이 아니라 다음 문제들의 이름이다. 그래서 다음 편에서는 그중 가장 중요한 기반으로 내려간다.

브라우저는 HTML/CSS/JavaScript를 실제로 어떻게 읽고, 어떤 내부 모델로 바꾸고, 어떤 비용을 치르며 화면을 다시 그릴까.

2편의 주제는 DOM과 reflow다.