FE 개발에서 디버깅 좀 잘해보자 🥺

디버깅은 짜증나는 작업이고, 긴급 대응이고, 원인을 못 찾으면 막막하고 답답하기도 하다.
하지만 많은 저명한 개발자들이 공통적으로 말하는 것이 있다.

디버깅을 잘하는 개발자는 기능을 만드는 것보다 문제를 추적하는 과정에서 더 발전한다.

Brian Kernighan 은 아래와 같이 말했다고 한다.

“코드를 이해하는 것보다 디버깅하는 것이 더 어렵다.
그러므로 디버깅할 수 있을 만큼 이해할 수 있도록 코드를 작성해야 한다.”

즉 디버깅 능력 = 단순 기술이 아니라 소프트웨어를 다루는 철학이다.

 

이번 글에서는 FE 개발을 하고 있는 나의 관점에서 React 및 JS 웹개발의 디버깅 방법들에 대해서 좀 정리해보려고 한다.

 

console.log — 여전히 가장 빠른, 가장 저렴한 디버깅

콘솔 로그는 구식이라고 느껴지지만, 여전히 효과적이다.

다만...

“console.log는 성숙한 디버깅 툴이다. 문제는 대부분이 효율적으로 사용하지 않는다는 점이다.”

예를 들어 아래처럼 범위(boundary), 그룹, 추적을 활용하면 “흩어진 로그” 문제가 사라진다.

console.group("FetchUser()");
console.log("Request Payload:", payload);
console.log("Response:", response);
console.trace("Called at");
console.groupEnd();

console.table(userList);

단순 출력이 아니라 원인-맥락 묶음 로깅이 중요하다.

(또한, 빌드 모드에서는 제거될 수 있도록 번들러 설정을 잘 만져보자)

 

Source Map — 배포 환경 디버깅의 핵심

프로덕션에서 발생한 오류가 bundle.min.js:430:21 에서 난다면 심장 박동이 빨라진다.

하지만 Sourcemap이 on 되어 있다면 다음처럼 바뀐다.

TypeError: undefined
at handleSubmit (src/features/auth/Login.tsx:58:20)

Webpack / Vite 환경에서 간단히 켤 수 있다.

export default defineConfig({
  build: { sourcemap: true },
});

배포 환경 디버깅의 GPS라고 생각하자.

(만약, 빌드가 된 코드의 분석의 경우 Minify나 Uglify 옵션이 켜져 있는 경우, 해제해야 소스맵을 볼 때 코드를 이해하기 좋다.)

 

React & State Debugging — 단순히 값 보는 시대는 끝났다

React 생태계는 디버깅 도구가 폭발적으로 증가했다. 그만큼 상태 관리가 복잡해졌다는 반증이다.

Chrome DevTools

• 네트워크·렌더링·메모리 분석 가능
• Performance 탭을 이용해 FPS, 스크립트 실행 시간 확인
• React DevTools와 함께 사용하면 더 효과적

React DevTools

• 컴포넌트 구조 트리 시각화
• props/state 변화 추적
• 메모이제이션 효과 확인 가능

LocatorJS

• 브라우저에서 UI 요소 클릭하면 소스코드 위치로 바로 이동
• 복잡한 UI 구조일수록 효율 상승
• Next.js, React, Remix 프로젝트에서 특히 유용

Sentry

• 에러 수집/추적/알림 제공
• 배포 버전, 사용자 환경, 발생 경로까지 기록
• 배포 릴리즈 매핑과 함께 사용하면 롤백 판단 근거 제공

OpenTelemetry

• 분산 시스템 관찰성 향상
• 서비스 간 요청 흐름 추적
• APM 또는 Log 기반 시스템과 연동 가능

AI 기반 디버깅 (ex: GitHub Copilot Debug, Cursor Debugger)

• 오류 로그→원인 추론 자동화
• 수정 코드 제안
• 재현 조건 설명 요청 가능

여기에 LocatorJS가 등장하면서 “UI 클릭 → 코드 파일 위치로 이동”까지 가능해졌다.
디자인 시스템 + 중첩 컴포넌트 사용하는 프로젝트에서 혁명적이다.

 

https://www.locatorjs.com/

LocatorJS - click on any component to go to code.

https://chromewebstore.google.com/detail/locatorjs/npbfdllefekhdplbkdigpncggmojpefi

LocatorJS - Chrome 웹 스토어

요런식으로 직접 UI에서 소스코드 접근이 가능해진다고 한다.

 

최신 디버깅 트렌드 — AI 기반 코드 추적

2024~2025 디버깅 흐름을 바꾸는 키워드는 AI Assisted Debugging라고 한다.

Codeium / SourceGraph Cody

• 프로젝트 전체 코드를 분석하여 문제의 root cause를 탐지
• 함수 호출 관계 및 영향을 받는 파일을 함께 제시
• 대규모 모노레포나 복잡한 서비스에서 효과가 큼

VSCode – GitHub Copilot Chat

• stack trace를 입력하면 오류 이유를 분석해 제안
• "왜 이 오류가 발생했는지" 설명을 요청할 수 있음
• 수정 코드까지 바로 제시해 로컬에서 빠르게 패치 검증 가능

Datadog APM + AI

• 배포 이후 발생한 장애 원인을 예측해 링크로 제공
• 트랜잭션, 성능 저하, 오류 발생 구간을 AI가 하이라이트
• 배포 전후 비교로 "언제부터 문제가 생겼는가" 추적 가능

Vercel AI Log Patterning

• 로그 패턴을 학습해 이상 징후를 사전 탐지
• 에러 패턴 감지 및 알려지지 않은 오류군 발견
• Next.js / Edge Function 기반 서비스와 자연스럽게 연동

 

특히 Copilot Chat의 Debug 모드는 꽤 현실적이라고 한다.

“이 에러가 왜 났는지, PR의 어느 코드가 영향을 줬는지”
“테스트 실패 log를 읽고 확정 원인을 제시”

 

개발자가 해야 할 것은 도구에 맡길 문제 vs 직접 추적해야 하는 문제를 구분하는 것이다.

 

https://code.visualstudio.com/docs/copilot/guides/debug-with-copilot

Debug with GitHub Copilot

https://skywork.ai/

Skywork︱The Originator of AI Workspace Agents

https://vercel.com/docs/ai-gateway/observability

Observability

 

Observability — 디버깅을 넘어 '시스템 관찰력'

현대 애플리케이션은 단일 브라우저 코드가 아니라

• FE → API → Auth Server → Log → CDN → Redis → DB

까지 흘러가며, 분산된 시스템 디버깅이 핵심이 되었다.

그래서 등장한 개념이 Observability (가시성)이다.

OpenTelemetry

• 로그, 메트릭, 트레이스 표준화
• 다양한 APM/모니터링 도구와 연동 가능한 벤더 중립 접근

Sentry

• 브라우저 + 서버 API 에러 수집
• 사용자 세션 기반 오류 재현, sourcemap 기반 FE 디버깅 강점

Datadog

• APM + 성능 분석 + 로그 분석 통합
• 장애 지점 추적 및 배포 전후 성능 변화 비교

NewRelic

• 분산 트랜잭션 자동 다이어그램 시각화
• 마이크로서비스 환경에서 요청 흐름을 따라가며 디버깅 가능

Cloudflare Workers Trace

• 글로벌 엣지 네트워크 기반 latency 기반 디버그
• 지역별 레이턴시 및 Lambda/Edge 성능 추적에 특화

특히 FE 개발자라도 Sentry는 필수다.

예외 발생 → 사용자 정보 → 브라우저 → 라우터 → 마지막 액션 까지 자동으로 기록된다.

다만, 이런 서비스들은 보통 유료이다...

 

https://www.datadoghq.com/

Cloud Monitoring as a Service | Datadog

https://sentry.io/welcome

Application Performance Monitoring & Error Tracking Software

디버깅 능력을 높이는 습관적 구조

1. 로그는 무조건 이벤트를 그룹화한다.
2. 오류는 무조건 Context를 포함해야 한다.
3. 성공 케이스도 기록하는 것이 좋다.
4. 해결이 되었으면, 기록 및 정리를 하자.
5. 같은 에러가 3회 이상 반복된다면, 코드 구조의 개선이 필요하다.

 

로그의 이벤트를 그룹화하면, 타임라인에 따라서 어느 이벤트 시점에 문제가 발생했는지 확인할 수 있다.

성공케이스나 에러 상황의 해결 후에는 개인적으로는 테스트 코드를 작성하는 것이 좋다고 생각한다.

-> 만일, 다른 코드를 수정하다가 문제가 발생할 경우 빠르게 탐지할 수 있다.

 

디버깅을 기록하는 습관이 디버깅 “스피드”를 높이는 게 아니라
디버깅 “정확도”를 높인다.

 

+ 디버깅을 종류에 따라 나눈다면 다음과 같다.

로그 기반 디버깅

• 가장 단순하지만 가장 광범위하게 사용
• structured logs 권장(JSON 기반)

재현 기반 디버깅

• 문제 상황을 동일하게 만들 수 있어야 원인 추적 가능
• E2E 테스트 도구(Cypress, Playwright) 활용 가능

프로파일링 기반 디버깅

• 느림, 지연, 프리즈, CPU spike 등 성능 문제 추적
• DevTools Performance / React Profiler 사용

배포 환경 기반 디버깅

• 로컬 환경에서는 발생하지 않는 문제 해결
• Sourcemap 업로드 필수(Sentry + sourcemap 연동)

참고자료 및 출처

• Brian Kernighan — The Elements of Programming Style
  https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style
• Paul Irish — Advanced Debugging with Chrome DevTools
  https://www.paulirish.com
• Dan Abramov — Debugging React Apps & Overreacted
  https://overreacted.io
• OpenTelemetry — CNCF 공식 문서
  https://opentelemetry.io/docs/
• GitHub Copilot — AI Assisted Debugging Docs
  https://docs.github.com/en/copilot
• Sentry Engineering Blog — Production Debugging
  https://blog.sentry.io/
• LocatorJS — UI-to-Source Code Navigation
  https://www.locatorjs.com
• Datadog Engineering — Observability & APM Debugging
  https://www.datadoghq.com/blog/
• Chrome DevTools Blog — debugging features
  https://developer.chrome.com/docs/devtools