Angular 소스맵 설정 및 디버깅 방법 요약

1. angular.json 소스맵 옵션 이해

• scripts: true: 개발자가 작성한 TypeScript 코드 디버깅을 위해 필수.
• styles: true: CSS 문제 추적에 유용.
• vendor: false: 외부 라이브러리 소스맵을 제외하여 빌드 성능 향상 및 번들 크기 감소 (일반적으로 권장).
• hidden: true: 소스맵 파일은 생성하되, 빌드된 JS/CSS 파일에 소스맵 연결 주석을 포함하지 않아 보안을 강화합니다. 일반 사용자는 소스맵의 존재를 알 수 없으며, 관리자는 수동으로 연결해야 합니다.

angular.json 파일 내의 production 빌드 설정 부분 예시

// angular.json
"architect": {
  "build": {
    "configurations": {
      "production": {
        // ...
        "sourceMap": {
          "scripts": true,
          "styles": true,
          "vendor": false,
          "hidden": true
        },
        // ...
      }
    }
  }
}

2. hidden: true 환경에서의 디버깅 방법

hidden: true 설정 시 관리자가 소스맵을 사용하여 디버깅하는 주요 방법은 다음과 같습니다.

1. Node.js 서버를 통한 접근 제어:
   • Node.js (Express) 서버에 미들웨어를 추가하여 .map 파일 요청을 가로챕니다.
   • 특정 쿼리 파라미터(예: debug_token)나 헤더가 일치하는 경우에만 소스맵 파일을 제공합니다.
   • 관리자는 브라우저 개발자 도구에서 소스맵 URL에 해당 토큰을 포함하여 수동으로 연결합니다.
2. 인증된 사용자에게 동적으로 스크립트 태그 삽입 (대안):
   • 관리자가 로그인했을 때, 서버가 index.html에 소스맵 정보를 활성화하는 스크립트를 동적으로 삽입하여 제공합니다.
   • 이 방법은 서버가 HTML을 동적으로 처리해야 하며, 캐싱 전략을 신중히 고려해야 합니다.
3. 로컬 프록시 서버 + 브라우저 확장 프로그램 (가장 권장되는 자동화 방법):
   • 로컬에 소스맵 파일 보관: 프로덕션 빌드와 일치하는 .map 파일들을 개발자 로컬 PC에 저장합니다.
   • 로컬 프록시 서버 실행: 로컬 PC에서 간단한 HTTP 서버를 띄워 로컬 소스맵 파일을 제공합니다.
   • 브라우저 확장 프로그램 설정 (예: Requestly): 운영 서버의 .map 파일 요청을 로컬 프록시 서버로 리디렉션하도록 규칙을 설정합니다.
   • 장점: 운영 서버 코드 수정 불필요, 최고의 보안성, Lazy Loading 모듈 포함 모든 소스맵 자동 연결 효과.

3. 청크(Chunk) 분리 및 Lazy Loading 모듈 디버깅

• 개별 청크 소스맵의 독립성: Angular는 --aot 빌드 시 코드를 여러 청크 파일(예: main.js, vendor.js, Lazy Loading 모듈 청크)로 분리하며, 각 청크는 자체적인 .js.map 파일을 가집니다.
• 부분 디버깅 가능: 디버깅하려는 특정 코드나 모듈이 포함된 청크의 소스맵만 연결하면 해당 부분은 디버깅이 가능합니다. 모든 청크의 소스맵을 연결해야만 디버깅이 가능한 것은 아닙니다.
• 효율적인 디버깅: 하지만 복잡한 호출 스택을 추적하거나 애플리케이션 전반의 오류를 분석할 때는 관련된 여러 청크의 소스맵을 연결하는 것이 훨씬 효율적입니다.
• Lazy Loading 문제 해결: Lazy Loading된 모듈의 소스맵이 보이지 않는 문제는 주로 소스맵 불일치, 개발자 도구의 한계, 여러 청크의 복합성, 소스맵 경로 문제 등으로 발생할 수 있습니다. 위에서 언급한 로컬 프록시 서버 + 브라우저 확장 프로그램 방식이 Lazy Loading 모듈의 소스맵을 자동으로 연결하는 가장 효과적인 방법입니다.

4. 로컬 파일 와일드카드 연결 (간접적 방법)

• 브라우저 개발자 도구의 Add source map... 기능은 로컬 파일 경로에 대한 와일드카드를 직접 지원하지 않습니다.
• 하지만 로컬 프록시 서버 + 브라우저 확장 프로그램 방식을 사용하면, Requestly와 같은 확장 프로그램의 리디렉션 규칙에서 와일드카드를 사용하여 운영 서버의 모든 .js.map 요청을 로컬 파일 시스템의 소스맵으로 자동으로 리디렉션할 수 있습니다. 이는 개발자에게 마치 로컬 파일 시스템의 모든 소스맵이 자동으로 연결되는 것과 같은 효과를 제공합니다.

5. 로컬 파일 직접 사용 시점

• 매우 높은 보안 요구사항: 소스맵 파일이 서버에 전혀 배포되지 않아야 할 때.
• 일회성/비정기적 디버깅: 복잡한 설정 없이 특정 버그를 한두 번만 확인할 때.
• 오프라인 환경: 인터넷 연결 없이 로컬 소스맵으로 디버깅해야 할 때.
• 단점: 번거로움, 버전 관리의 어려움, 팀 환경에서의 비효율성.

6. Requestly 무료/유료 버전 차이

• 무료 버전: 기본적인 요청/응답 수정, 리디렉션, 블록 기능 제공. 규칙 수 제한, 클라우드 동기화 및 팀 협업 기능 부재.
• 유료 버전: 무제한 규칙, 클라우드 동기화, 팀 협업, 환경별 규칙, 고급 매칭 조건, API 모의 등 고급 기능 제공.
• 소스맵 리디렉션 용도: 무료 버전으로도 충분히 가능합니다.

7. Requestly의 작동 방식

• Requestly는 웹 브라우저 확장 프로그램이며, 별도의 PC 버전 애플리케이션이 아닙니다.
• 웹 브라우저 내에서 웹 요청을 실시간으로 감시하고 제어하는 데 특화되어 있습니다.
• 규칙 설정은 웹 기반 UI를 통해 이루어집니다.

8. Requestly에서 로컬 파일 경로 직접 사용 및 주의사항

• Requestly의 Redirect Request 규칙에서 Another URL 필드에 file://C:/inetpub/wwwroot/$1.js.map과 같은 로컬 파일 경로를 직접 사용하는 것이 가능합니다.
• 이 방법은 로컬 프록시 서버를 띄울 필요 없이 Requestly가 직접 로컬 파일 시스템의 소스맵을 제공하도록 하여 설정을 더욱 간편하게 합니다.
• 중요한 점은 file:// 프로토콜 사용 시 슬래시를 2개만 사용해야 한다는 점입니다. (예: file://C:/path/to/file.js.map)
• file:/// (슬래시 3개)는 일부 환경에서 작동하지 않을 수 있습니다.
• Requestly에 로컬 파일 접근 권한을 부여해야 합니다.