오늘은 실무에서 정말 중요한 에러 핸들링과 모니터링에 대해 이야기해볼게. 많은 신입 개발자들이 로컬에서 에러 없이 잘 돌아가면 끝이라고 생각하는데, 진짜 전쟁은 배포하고 나서 시작되거든. 사용자가 "이거 안 돼요"라고 말하기 전에 우리가 먼저 에러를 잡고 해결하는 게 진짜 프로의 자세야.
1. 단순 console.error와 로그 파일의 한계
내가 15년 동안 풀스택 개발자로 일하면서 수많은 장애를 겪어봤는데, 단순한 텍스트 로그나 console.error에만 의존하는 건 정말 위험하더라. 로컬에서는 에러가 나면 바로 터미널을 보면 되지만, 운영 서버에서는 에러가 언제, 누구에게, 왜 발생했는지 추적하기가 하늘의 별 따기거든. 단순히 "에러가 발생했습니다"라는 로그 한 줄로는 에러가 터지기 직전에 사용자가 어떤 행동을 했는지, 브라우저 환경은 어땠는지 전혀 알 수 없어. 그래서 우리는 에러의 맥락(Context)을 파악할 수 있는 시스템을 구축해야 돼.
2. 에러 트래킹 도구, Sentry 제대로 활용하기
실무에서는 에러 모니터링 플랫폼으로 Sentry를 정말 많이 써. 단순 로그와 달리 Sentry는 에러가 발생한 시점의 Stack Trace는 물론이고, 에러 발생 전 사용자의 클릭 동선을 보여주는 Breadcrumbs, 실제 화면을 녹화해서 보여주는 Session Replay까지 제공하거든. 프론트엔드라면 배포 시 Source Map을 업로드해서 난독화된 코드가 아닌 실제 원본 코드의 몇 번째 줄에서 에러가 났는지 매핑해주는 작업이 필수야. 다만, 실무에서 쓸 때는 Quota(할당량) 관리를 조심해야 해. 배포 오류로 무한 루프 에러가 터지면 순식간에 한 달 치 할당량을 다 써버려서 정작 중요한 에러를 놓치거나 추가 비용이 발생할 수 있으니, sampling rate를 적절히 조절해서 수집량을 제어하는 노하우가 필요해.
3. 구조화된 로깅과 관측 가능성(Observability)
에러 핸들링의 최종 목적지는 시스템의 관측 가능성을 높이는 거야. 이를 위해 로그를 남길 때는 텍스트가 아닌 JSON 형태의 **구조화된 로그(Structured Logs)**를 사용해봐. 예를 들어 {"level": "error", "userId": 104, "action": "payment", "message": "timeout"}처럼 규격화해두면, 나중에 로그 검색 엔진에서 특정 유저나 특정 API의 에러만 필터링하기가 아주 쉬워져. 더 나아가 프론트엔드와 백엔드 간에 Trace ID를 공유해서, 클라이언트에서 발생한 에러가 서버의 어떤 API 호출에서 시작되었는지 한 번에 추적할 수 있는 환경을 만드는 게 실무에서 진짜 일 잘하는 개발자의 팁이야.
💡 핵심 정리
- 단순 로그 적재를 넘어
Sentry같은 전문 에러 트래킹 도구를 도입해봐.- 에러 해결을 위해
Breadcrumbs와Source Map을 활용해 에러의 맥락을 파악해야 해.- 구조화된 로그(Structured Logs)를 남기고, 할당량 관리를 위해
sampling설정을 잊지 마. 에러는 피할 수 없지만, 어떻게 다루느냐에 따라 서비스의 신뢰도와 네 가치가 결정되는 법이야. 오늘 개발 중인 프로젝트에 Sentry 같은 도구를 연동해서 에러를 능동적으로 수집하는 연습을 꼭 시작해봐.