Files, Binary & Compression
.map 파일(또는 인라인 map이 있는 JS 파일)을 붙여 넣고 행:열이나 스택 트레이스를 입력하면 원본 파일, 행 번호, 코드가 나타납니다.
이 탭 안에서만 분석합니다. 원격 소스 파일이나 외부 sourceMappingURL은 가져오지 않습니다.
입력이 바뀌었습니다. 자동으로 분석합니다…
운영 환경 에러 리포트에는 app.3f2a.js:1:20931만 찍혀 있습니다. 압축된 번들의 1행, 2만 번째 열입니다. 함께 빌드된 .map 파일은 그 위치가 어느 .ts나 .tsx 파일의 몇 번째 줄인지 알고 있지만 mappings가 Base64 VLQ로 인코딩되어 있어 눈으로는 읽을 수 없습니다. 이 소스맵 분석 도구가 디코딩과 조회를 대신하므로 에러 하나를 찾자고 source-map 라이브러리를 불러오는 스크립트를 짤 필요가 없습니다.
에러 모니터링에 소스맵을 올려 두지 않았을 때, CI 빌드 결과물만 손에 있을 때, 또는 map이 운영 번들과 같은 빌드에서 나온 것인지 확인하고 싶을 때 쓰면 됩니다. 파일 자체의 소스 맵 디코딩에도 유용합니다. sources에 무엇이 있고, 어떤 항목이 sourcesContent를 갖고, 어떤 항목이 ignoreList에 있으며, mappings가 깨지지 않았는지 볼 수 있습니다. map을 서버로 보내 분석하는 서비스와 달리 아무것도 업로드하지 않고 원격 URL에도 요청하지 않습니다.
궁금한 것은 결국 "원본 코드 위치가 어디인가"입니다. 스택 전체를 한 번에 조회하고, 결과가 근사치일 때는 그렇다고 알려 줍니다.
:행:열로 끝나는 줄은 모두 map에서 조회되어 원본 파일, 행, 열, 원래 식별자 이름과 앞뒤 몇 줄의 코드가 표시됩니다. map의 file과 다른 파일에서 온 프레임에는 경고가 붙어 vendor 번들의 프레임을 앱 map으로 잘못 해석하는 일을 막습니다.
소스 보기는 sources의 모든 항목을 sourceRoot를 붙인 경로로 나열하고, sourcesContent가 있는지와 ignoreList 여부를 표시하며, 행 번호와 함께 코드를 보여 줍니다. 파일 하나씩 저장하거나 포함된 모든 소스를 폴더 구조 그대로 zip으로 받을 수 있어, 원본 저장소를 잃고 map만 남았을 때 유용합니다.
.map JSON을 붙여 넣거나, ".map 파일 열기"로 열거나 끌어다 놓거나, 빌드된 JS/CSS 파일 자체를 붙여 넣어도 됩니다. 끝에 //# sourceMappingURL=data:… 주석이 있으면 인라인 map을 꺼내 디코딩합니다(Base64와 URL 인코딩 모두 지원). 일반 URL을 가리키면 주소만 알려 주고 가져오지 않으니, 그 .map 파일을 직접 여세요.
위치는 12:345, "12 345", 또는 at n (https://example.com/app.js:1:177) 같은 프레임 그대로 입력할 수 있습니다. Chrome, Firefox, Node 스택 트레이스에 맞춰 열 번호는 기본적으로 1부터 셉니다. mozilla/source-map 결과처럼 0부터 세는 값을 쓸 때는 "열 번호 1부터 시작"을 끄세요. 그렇지 않으면 결과가 한 글자씩 어긋납니다.
정확히 일치하면 그 열에서 세그먼트가 시작한다는 뜻입니다. 그렇지 않으면 왼쪽에서 가장 가까운 세그먼트를 쓰고 그 사실을 표시하는데, 브라우저와 source-map 라이브러리의 기본 규칙과 같습니다. "소스에서 보기"를 누르면 해당 원본 행으로 이동하고, 원본 행 번호 칸이 그 행에 매핑된 모든 생성 위치를 역으로 찾아 줍니다.
매핑 보기는 VLQ 문자열을 생성 행:열 → 소스, 원본 행:열, 이름의 표로 풀어 100개씩 보여 주고 전체를 TSV로 내보냅니다. source map 매핑 확인이나 diff 비교에 씁니다.
소스와 원본 행 번호를 고르면 그 행을 가리키는 생성 위치를 모두 나열합니다. 어떤 줄이 인라인되었는지, 복제되었는지, 압축 과정에서 사라졌는지 확인할 수 있습니다.
인라인 data: URL, sections와 offset을 가진 인덱스 맵, sourceRoot 연결, ignoreList와 예전 x_google_ignoreList를 모두 이해하므로 프레임워크 코드와 내 코드를 구분할 수 있습니다.
JSON 문법 오류는 행과 열로, 잘못된 VLQ 문자, 필드 수가 맞지 않는 세그먼트, 범위를 벗어난 source나 name 인덱스는 생성 코드 몇 행의 몇 번째 세그먼트인지로 알려 줍니다.
네. 빌드 결과물의 .map 파일을 위 소스맵 분석 도구에 넣고, 에러가 난 행:열이나 스택 트레이스를 붙여 넣으면 원본 파일과 행, 앞뒤 코드가 바로 보입니다. 브라우저 개발자 도구가 map을 자동으로 불러오지 못하는 운영 환경 에러를 볼 때 특히 편합니다.
mappings는 세미콜론으로 생성 코드의 행을, 쉼표로 세그먼트를 나누고, 각 세그먼트는 1개·4개·5개의 값을 Base64 VLQ로 인코딩한 것입니다. 값은 앞 세그먼트와의 차이입니다. 매핑 보기에서 이를 행:열 대응표로 풀어 볼 수 있습니다.
hidden-source-map은 번들에 sourceMappingURL 주석을 넣지 않을 뿐 .map 파일은 그대로 만듭니다. 그 파일을 여기서 열고 에러 리포트의 행:열이나 스택 트레이스를 붙여 넣으면 됩니다. 브라우저가 map을 찾지 못해도 이 방식으로는 원본 위치를 알 수 있습니다.
공개된 map에 sourcesContent가 있으면 누구나 원본 코드와 주석을 읽을 수 있습니다. 그래서 많은 팀이 map을 에러 모니터링 서비스에만 올리거나 인증이 필요한 곳에 둡니다. 이 도구로 확인하는 것은 노출을 늘리지 않습니다. 모든 분석은 브라우저 안에서 이루어집니다.
에러에 찍힌 행:열을 위치 칸에 입력하세요. 열 번호는 브라우저 스택과 같이 1부터 세는 것이 기본값입니다. 그 열에서 시작하는 세그먼트가 없으면 왼쪽의 가장 가까운 세그먼트로 원본 위치를 계산하고 근사치임을 표시하므로 결과를 얼마나 믿어도 되는지 알 수 있습니다.
궁금한 점이 남았나요?