테마
01. DOM 인터랙션 큰 그림과 현대적 접근
DOM 인터랙션은
엘리먼트를 찾는다에서 끝나지 않는다. 사용자의 행동이 브라우저 기본 동작과 만나고, 그 흐름 중간에 JavaScript가 어디서 개입할지를 읽는 기술이다.
학습 목표
- DOM 인터랙션을 이벤트, 입력, 폼, 브라우저 API, 컴포넌트 관점으로 나눠 설명할 수 있다.
- 프레임워크 시대에도 브라우저 기본 API를 알아야 하는 이유를 이해한다.
- 원문 강의의 "시나리오로 학습하라"는 메시지를 현재 개발 방식에 맞게 해석할 수 있다.
- 이 시리즈 전체가 어떤 순서로 연결되는지 큰 그림을 잡을 수 있다.
1. 왜 지금도 DOM 인터랙션을 다시 공부해야 할까?
React, Vue, Svelte 같은 도구를 써도 결국 실제 브라우저는 아래 일을 직접 처리한다.
- 클릭, 입력, 포커스 이동 같은 이벤트 발생
- 폼 유효성 검사와 제출
- 클립보드 접근과 파일 드롭
- Shadow DOM 경계 안팎의 이벤트 전파
프레임워크는 이 위에 추상화를 얹을 뿐, 기본 동작 자체를 없애지 않는다.
그래서 아래처럼 "브라우저 기본기"가 드러나는 순간이 자주 나온다.
- 특정 버튼 클릭 후 원하는 위치로 포커스를 옮겨야 할 때
- 제출 버튼 종류에 따라 폼 전송 동작을 바꿔야 할 때
- 드래그로 파일을 받아 업로드해야 할 때
- 외부 위젯이나 디자인 시스템을 Web Components로 연결해야 할 때
2. DOM 인터랙션을 시나리오로 읽는 법
원문 강의가 강조한 핵심은 "프로퍼티 이름을 외우지 말고 시나리오를 떠올리라"는 점이었다.
현재 기준으로 바꾸면 아래 흐름으로 읽는 것이 가장 이해가 쉽다.
예를 들어 "회원가입 폼 제출"은 단순히 value를 읽는 문제가 아니다.
- 입력 엘리먼트를 배치한다
- 사용자가 키보드와 포인터로 입력한다
- 브라우저 기본 유효성 검사가 먼저 개입한다
- 개발자가
submit이벤트에서 추가 검증이나 비동기 전송을 수행한다 - 제출 후 포커스와 메시지를 정리한다
즉, DOM 인터랙션은 하나의 메서드 사용법이 아니라 사용자 여정 속 API 연결에 가깝다.
3. 이 시리즈가 다루는 다섯 축
| 축 | 질문 | 대표 API |
|---|---|---|
| 이벤트 | 어떤 행동이 발생했고 어디까지 전파되는가 | addEventListener, preventDefault, closest |
| 입력 | 어떤 장치로 어떤 값이 들어오는가 | PointerEvent, beforeinput, composition*, focus() |
| 폼 | 브라우저는 제출과 검증을 어떻게 처리하는가 | requestSubmit(), checkValidity(), FormData |
| 고급 브라우저 API | 기본 UI 밖의 상호작용을 어떻게 다루는가 | navigator.clipboard, DataTransfer, MutationObserver |
| 컴포넌트 | 재사용 가능한 브라우저 수준 UI를 어떻게 만드는가 | customElements.define, attachShadow, slot |
원문에는 HTMLElement 프로퍼티 목록이 길게 등장하지만, 현재는 이 축 안에 필요한 것만 묶어 보는 편이 더 효율적이다.
4. 오래된 학습 방식과 현재 기준의 차이
예전 강의에서 자주 보이던 방향
onclick="..."같은 인라인 핸들러 예제- 이벤트 제거를 위해 동일한 콜백 참조를 맞추는 법만 장시간 설명
- 폼 제출을
form.submit()중심으로 설명 - HTML5 Drag and Drop을 모든 드래그 UX의 기본처럼 소개
현재 더 중요해진 방향
addEventListener(type, listener, { once, passive, signal })AbortController로 리스너와 비동기 작업 생명주기 통합requestSubmit()과 Constraint Validation API 활용- Pointer Events 기반 입력 통합
- Clipboard API의 보안 조건 이해
- Web Components의 실제 적합한 사용처와 한계 구분
5. 프레임워크를 써도 브라우저 API를 알아야 하는 이유
프레임워크는 반복적인 DOM 조작을 줄여 주지만, 아래 주제는 여전히 브라우저 API 이해가 직접 필요하다.
- 접근성을 위한 포커스 이동
- 스크롤과 터치 성능을 위한
passive옵션 - 파일 업로드 드롭존 구현
- 브라우저 기본 폼 검증 메시지 활용
- 외부 위젯 삽입과 Shadow DOM 경계 처리
실무에서는 "프레임워크가 다 해 준다"보다 "프레임워크가 브라우저 API 위에 어떤 규칙을 얹는가"를 이해하는 편이 훨씬 강하다.
6. 이 시리즈를 읽을 때 잡아야 할 기준
기준 1. 기본 동작과 커스텀 동작을 분리한다
브라우저가 이미 해 주는 일이 있다.
- 버튼 클릭
- 링크 이동
- 폼 검증
- 키보드 포커스 이동
개발자는 이 기본 동작을 무시하고 전부 다시 짜기보다, 어디까지 그대로 두고 어디서 개입할지 결정해야 한다.
기준 2. 생명주기를 같이 본다
이벤트를 추가했으면 정리도 필요하다.
- 리스너 등록
- DOM 갱신
- Observer 연결
- 컴포넌트 제거 시 cleanup
단발성 예제에서는 안 보이지만, 실제 앱에서는 이 정리 단계가 누락되면 메모리 누수와 중복 실행으로 이어진다.
기준 3. "가능한가"보다 "적합한가"를 묻는다
- Drag and Drop은 파일 드롭에는 좋지만, 모바일까지 고려한 카드 재정렬은 Pointer Events 기반 구현이 더 현실적이다
- Web Components는 공용 위젯에는 강하지만, SPA 전체를 대체하는 만능 해법은 아니다
7. 문서 맵
이 시리즈는 아래 순서로 읽으면 흐름이 자연스럽다.
- 이벤트와 속성 제어의 바닥을 잡는다
- 이벤트 전파와 위임으로 "왜 이 핸들러가 여기서 실행되는가"를 이해한다
- 포인터, 키보드, 입력 이벤트로 실제 사용자 조작을 본다
- 폼과 제출 과정을 브라우저 기본 기능 중심으로 다시 본다
- 클립보드, 드래그, DOM 관찰 같은 고급 상호작용을 연결한다
- 마지막으로 Web Components로 재사용 단위를 이해한다
8. PR 리뷰 체크리스트
- 이 기능은 브라우저 기본 동작을 활용하는가, 아니면 불필요하게 다시 구현하는가
- 이벤트 등록과 정리(cleanup)가 한 쌍으로 설계되어 있는가
- 폼 검증과 제출에서 브라우저 기본 기능을 우회하고 있지 않은가
- 특정 API를 사용할 때 보안 조건과 브라우저 지원 범위를 확인했는가
- 프레임워크 코드 안에서도 실제 브라우저 이벤트 흐름을 설명할 수 있는가
핵심 정리
- DOM 인터랙션은 속성 암기가 아니라 사용자 상호작용 흐름을 읽는 문제다
- 프레임워크를 쓰더라도 브라우저 기본 이벤트, 포커스, 폼, 컴포넌트 모델은 여전히 중요하다
- 이 시리즈는 원문 강의의 핵심 흐름을 유지하되, 2026년 실무 기준에 맞게 현대적인 API 선택으로 다시 정리한다