프런트엔드 공부를 처음 시작했을 때 저는 HTML, CSS, JavaScript를 각각 따로 외우면 된다고 생각했습니다. 하지만 직접 화면을 만들다 보니 태그를 많이 알아도 구조가 엉키고, CSS 속성을 외워도 레이아웃이 깨지며, JavaScript 코드가 맞아 보여도 DOM을 찾지 못하는 문제가 생겼습니다. 그때 세 기술은 따로 움직이는 것이 아니라 브라우저 안에서 하나의 흐름으로 연결된다는 걸 알게 됐습니다. 저는 HTML은 의미 있는 구조를 만들고, CSS는 그 구조를 화면에 맞게 배치하며, JavaScript는 사용자 행동에 반응해 화면을 바꾸는 역할이라고 생각합니다. 이 글에서는 제 경험을 바탕으로 프런트엔드 기초를 어떻게 이해하면 좋은지 정리해 보겠습니다.
프런트엔드 기초, HTML 구조를 설계하는 감각부터 잡아야 합니다
HTML을 처음 배울 때 저는 태그를 외우는 데 집중했습니다. div, p, span, img 같은 것들을 반복해서 쓰면 자연스럽게 익혀질 거라고 생각했습니다. 그런데 직접 자기소개 페이지를 만들어보면서 이상한 점을 발견했습니다. 화면에 보이기는 하는데, 뭔가 엉성하고 정리가 안 된 느낌이었습니다. 나중에 알고 보니 모든 영역을 div로 감싸버린 게 문제였습니다. 여기서 시맨틱 HTML이라는 개념이 중요합니다. 시맨틱 HTML이란 태그 자체에 의미를 담아 문서 구조를 명확하게 전달하는 방식을 말합니다. 예를 들어 머리말에는 header, 주요 콘텐츠에는 main, 글 묶음에는 article, 하단 정보에는 footer를 쓰는 식입니다. 처음에는 div 하나면 다 되는 것 같지만, 시맨틱 태그를 쓰면 검색엔진과 스크린 리더가 페이지 구조를 훨씬 잘 이해합니다. 스크린 리더란 시각 장애인이 화면 내용을 음성으로 듣기 위해 사용하는 보조 기술입니다. 시맨틱 HTML이 잘 갖춰진 페이지는 이 도구가 내용을 올바른 순서로 읽어낼 수 있어 웹 접근성이 높아집니다. 실제로 웹 접근성 관련 지침은 W3C(World Wide Web Consortium)에서 WCAG라는 국제 표준으로 제정해 공개하고 있습니다(출처: W3C). 이 기준에 따르면 의미 있는 HTML 구조는 접근성과 SEO 모두에 직접적인 영향을 줍니다.
제 경험상 이건 좀 다릅니다. HTML을 구조 설계 언어로 보는 시각을 갖는 순간, 단순히 태그를 외우는 것과는 완전히 다른 공부가 시작됩니다. “이 요소가 페이지에서 어떤 의미를 갖는가”를 먼저 생각하고, 그에 맞는 태그를 선택하는 습관이 생기면 이후 CSS나 JavaScript를 연결할 때도 훨씬 수월해집니다.
핵심 포인트:
- div 대신 header, main, article, footer 등 시맨틱 태그를 사용하면 구조가 명확해집니다
- 시맨틱 HTML은 검색엔진 최적화(SEO)와 웹 접근성의 출발점입니다
- HTML 구조를 먼저 설계하는 습관이 CSS, JavaScript 작업 속도를 높여줍니다
CSS 배치를 이해 못 하면 화면은 반드시 깨집니다
CSS가 적용이 안 된다거나 여백이 이상하게 생긴다는 문제, 저도 수도 없이 겪었습니다. 처음에는 속성을 더 외우면 해결될 줄 알았습니다. 그런데 진짜 원인은 따로 있었습니다. 브라우저가 HTML 요소를 화면에 배치하는 방식, 즉 박스 모델을 이해하지 못했던 것입니다. 박스 모델(Box Model)이란 브라우저가 모든 HTML 요소를 사각형 박스로 보고, 그 안에 콘텐츠 영역, 안쪽 여백(padding), 테두리(border), 바깥 여백(margin)을 계산하는 방식을 말합니다. 예를 들어 너비를 100px로 설정했는데 실제 화면에서 더 크게 보이는 현상은 대부분 이 박스 모델 계산을 잘못 이해해서 생깁니다. 이 개념 하나만 제대로 잡아도 레이아웃 오류의 절반은 해결됩니다. 레이아웃 배치 방식에서는 Flexbox와 CSS Grid가 현재 표준처럼 쓰입니다. Flexbox란 요소들을 한 방향(가로 또는 세로)으로 정렬하고 간격을 제어할 때 쓰는 레이아웃 방식입니다. Grid는 행과 열을 동시에 제어해 복잡한 화면 구조를 만들 때 유리합니다. 솔직히 이건 처음에는 어떤 상황에서 무엇을 쓸지 감이 잡히지 않았습니다. 직접 카드 레이아웃을 만들고, 반응형 페이지를 만들어보면서야 두 방식의 차이가 몸으로 느껴졌습니다.
반응형 웹이란 PC, 태블릿, 모바일처럼 화면 크기가 달라져도 레이아웃이 자연스럽게 조정되도록 설계하는 방식을 말합니다. 이를 구현할 때 미디어 쿼리(media query)를 사용하는데, 특정 화면 너비 기준으로 스타일을 분기하는 방식입니다. 2024년 기준 국내 모바일 인터넷 이용률은 93.4%에 달해 모바일 대응은 선택이 아닌 기본값입니다(출처: 과학기술정보통신부). CSS 선택자 우선순위, 박스 모델, Flexbox, 반응형 구조를 이해하고 나면 CSS가 단순히 색을 입히는 도구가 아니라 화면 배치를 정교하게 제어하는 언어로 보이기 시작합니다.
JavaScript DOM 조작 흐름을 몸으로 익혀야 합니다
JavaScript를 처음 배울 때 가장 당황스러웠던 순간이 있습니다. 분명히 코드는 맞는 것 같은데 버튼을 클릭해도 아무 반응이 없었습니다. 콘솔을 열어보니 “Cannot read properties of null”이라는 오류가 찍혀 있었습니다. 원인은 JavaScript 코드가 HTML이 완전히 로드되기 전에 실행되어 요소를 찾지 못한 것이었습니다. 그때부터 브라우저가 HTML, CSS, JavaScript를 처리하는 순서에 대해 진지하게 공부하기 시작했습니다. DOM(Document Object Model)이란 브라우저가 HTML 문서를 읽고 나서 내부적으로 만드는 트리 구조를 말합니다. JavaScript는 이 DOM을 통해 화면 요소를 찾고, 내용을 바꾸고, 이벤트를 연결합니다. 버튼 클릭 시 메뉴가 열리거나, 입력값에 따라 오류 메시지가 나타나는 것이 모두 DOM 조작의 결과입니다. 이 개념을 이해하지 못한 채 React 같은 프레임워크를 배우면 컴포넌트가 왜 다시 렌더링 되는지, 상태(state)가 화면에 어떻게 반영되는지 설명하기 어렵습니다. 이벤트 처리 흐름도 중요합니다. 사용자가 클릭하거나 입력하면 브라우저가 이벤트를 감지하고, JavaScript가 등록된 콜백 함수를 실행하며, DOM이 변경되고, 화면이 다시 그려집니다. 이 흐름을 머릿속에 그릴 수 있을 때 비로소 오류가 어느 단계에서 발생했는지 추적할 수 있습니다. 제가 직접 할 일 목록 프로젝트를 만들어보면서 이 흐름을 체감했는데, 단순한 실습 하나가 강의 영상 열 개보다 훨씬 많은 것을 가르쳐줬습니다. 프레임워크는 기본기를 대신해 주는 도구가 아닙니다. JavaScript와 DOM을 이해한 위에서 더 효율적으로 일하게 해주는 도구입니다. 입문 자라면 아래 실습 순서로 세 기술의 연결을 직접 확인해 보기를 권합니다.
- HTML로 입력창, 버튼, 목록 영역 구조를 만듭니다
- CSS로 여백, 버튼 디자인, 반응형 레이아웃을 적용합니다
- JavaScript로 사용자 입력을 받아 DOM에 항목을 추가하고 삭제합니다
이 작은 과정 하나에 HTML, CSS, JavaScript가 브라우저 안에서 어떻게 연결되는지 모두 담겨 있습니다. 결국 프런트엔드 기초 공부에서 가장 중요한 것은 세 기술을 각각 암기하는 것이 아니라, 브라우저가 하나의 화면을 만드는 흐름 속에서 이해하는 것입니다. HTML 구조가 흔들리면 CSS도 무너지고, JavaScript 실행 시점이 맞지 않으면 DOM 조작도 실패합니다. 지금 막 시작하는 단계라면 작은 웹페이지 하나를 직접 만들어보는 것이 가장 빠른 길입니다. 코드를 완성하는 것보다 오류를 만나고 해결하는 과정에서 훨씬 많이 배우게 됩니다.