누구나 한 번쯤 이런 경험이 있을 겁니다. 새로운 기능을 만들기 위해 10시간 넘게 몰입해서 작업했고, 모든 게 잘 되는 것처럼 보였습니다. 빌드 후 프로덕션에 배포했는데… 갑자기 프로덕션 에러 알림이 뜹니다. 팀원들은 원인을 찾기 시작하고, 결국 문제의 커밋은 바로 ‘나’였습니다. 그런데 이상하게도 테스트에서는 아무 문제도 없었고, 코드 자체도 멀쩡해 보입니다.
로그를 확인해 보니 이런 에러가 찍혀 있습니다:
Uncaught Error: Cannot read property 'xyz' of undefined at app.min.js:1:45678
app.min.js:1:45678? 이런 파일을 만든 적도 없고, 내 파일은 app.js였습니다.
게다가 4만 자가 넘는 한 줄짜리 코드라니… 디버깅이 거의 불가능해 보입니다. 이때 등장하는 것이 바로 Source Map(소스 맵)입니다.
소스 맵은 난독화·압축된 코드(우리가 방금 본 의미 없는 문자 덩어리)를 원래의 소스 코드와 연결해 주는 지도입니다. 덕분에 실제 문제가 발생한 원본 코드 위치를 정확히 찾아 디버깅할 수 있습니다.
이번 블로그에서는 소스 맵이 무엇인지, 왜 그리고 어떻게 생성되는지 자세히 알아보고, 소스 맵을 효과적으로 사용하여 코드를 디버깅하는 몇 가지 팁을 알려드리겠습니다. 자, 시작해 볼까요!
소스 맵을 이해하려면 먼저, 우리가 작성한 깔끔한 코드가 왜 브라우저에서는 전혀 다른 모습으로 보이는지 알아야 합니다.
간단히 말하면, 그 이유는 바로 파일 축소 Minification(압축/난독화) 때문입니다.
Minification은 기능은 그대로 유지한 채, 코드의 크기를 최대한 줄여서 프로덕션용 코드로 변환하는 과정입니다. 이 작업은 보통 Webpack 같은 번들러가 수행합니다. 번들러에 대해 더 자세히 알아보려면 Snipcart에서 제공하는 자바스크립트 번들러 관련 유용한 가이드를 참고하세요 .
번들러는 다음과 같은 최적화를 수행합니다.