AI랑 같이하는 코딩

1. 주제 소개

프론트엔드 초보 코드에서 가장 빨리 복잡해지는 부분은 이벤트 처리입니다. 버튼 클릭, 입력 변경, 스크롤, 모달 열기/닫기 같은 동작을 기능별로 급하게 붙이다 보면 `addEventListener`가 파일 곳곳에 흩어지고, 비슷한 콜백 로직이 반복되며, 상태 변경이 여러 군데서 동시에 일어납니다. 화면은 돌아가지만 "왜 이 버튼이 여기서도 반응하지?" 같은 예측 불가능한 버그가 생기기 쉽습니다. 특히 이벤트 바인딩 해제 없이 재렌더링이 반복되면 중복 호출까지 발생합니다.

이번 글은 지저분해진 이벤트 코드를 정리하는 기본 기준을 Before & After 관점으로 설명합니다. 핵심은 고급 패턴보다 흐름 통제입니다. 이벤트 등록 위치를 모으고, 핸들러 책임을 분리하고, 상태 변경 경로를 단순화하면 코드가 훨씬 읽기 쉬워집니다. 이 정리만으로도 디버깅 속도와 기능 안정성이 크게 올라갑니다.

2. 핵심 내용

첫 번째 기준은 "이벤트 등록의 단일 진입점"입니다. 이벤트를 함수마다 임의로 등록하면 흐름을 추적하기 어렵습니다. 초기화 함수에서 이벤트를 한 번에 바인딩하고, 각 이벤트는 명시적인 핸들러로 연결하는 구조가 좋습니다. 예를 들어 `initEventListeners()`에서 클릭/입력/체인지 이벤트를 모두 등록하면 페이지가 어떻게 반응하는지 한눈에 파악할 수 있습니다. 두 번째 기준은 핸들러 내부를 짧게 유지하는 것입니다. 핸들러가 검증, API 호출, 렌더링까지 전부 처리하면 다시 비대해집니다. 핸들러는 "이벤트 해석"만 하고 실제 작업은 별도 함수로 위임하세요.

세 번째는 이벤트 위임을 활용하는 것입니다. 리스트 아이템이 동적으로 추가되는 화면에서 각 아이템마다 리스너를 붙이면 코드가 중복되고 메모리 부담도 커집니다. 상위 컨테이너에 리스너 하나를 두고 `event.target` 기반으로 분기하면 유지보수가 쉬워집니다. 네 번째는 상태 변경 규칙 통일입니다. 여기저기서 전역 상태를 직접 바꾸기보다 `setState` 같은 단일 경로를 두면 버그 위치를 좁히기 쉽습니다.

마지막으로 해제(cleanup) 전략이 필요합니다. 모달, 탭, SPA 화면 전환처럼 컴포넌트 생명주기가 있는 경우에는 이벤트 해제를 빼먹기 쉽습니다. 등록과 해제를 같은 모듈 안에서 쌍으로 관리하면 중복 호출과 메모리 누수를 예방할 수 있습니다.

3. 적용 방법

실전 적용은 다음 순서가 안전합니다. 먼저 파일 전체의 이벤트 등록 지점을 검색해 목록화합니다. 다음으로 화면 단위 초기화 함수로 등록 코드를 모읍니다. 각 콜백에서 비즈니스 로직을 분리해 `handleClick`, `handleInput`, `submitForm` 같은 책임 함수로 나눕니다. 동적 목록은 이벤트 위임으로 전환하고, 마지막으로 화면 종료 시 리스너를 해제하는 cleanup 함수를 추가합니다. 이 과정을 작은 모듈부터 적용하면 서비스 중인 코드에도 부담이 적습니다.

Before 코드에서는 같은 이벤트가 여러 번 등록되어 클릭 한 번에 요청이 두세 번 나가는 문제가 흔합니다. After 구조에서는 이벤트 등록 지점이 명확하고, 핸들러가 작아서 원인 추적이 빠릅니다. 또한 기능 추가 시 "어디에 붙여야 하는지" 기준이 생기므로 코드 일관성이 유지됩니다. 이벤트 코드는 사용자 경험과 직결되기 때문에, 작은 정리만으로도 서비스 품질이 체감될 만큼 좋아집니다.

4. 정리

이벤트 코드 정리의 목표는 화려한 패턴 도입이 아니라 흐름의 예측 가능성 확보입니다. 등록 지점을 모으고, 핸들러를 짧게 유지하고, 상태 변경을 한 경로로 관리하면 지저분한 코드도 빠르게 안정됩니다. 초보 단계에서 특히 중요한 것은 "새 이벤트를 붙일 때마다 기존 규칙을 지키는 습관"입니다. 이 습관이 쌓이면 코드 리뷰에서도 버그보다 구조 개선 의견이 많아지고, 팀 생산성도 함께 올라갑니다. 결국 좋은 이벤트 코드는 동작하는 코드가 아니라, 다음 변경에도 버티는 코드입니다.

5. 자주 묻는 질문