디버깅


디버깅은 오류의 원인을 찾고 수정하는 과정이다. 다양한 플랫폼에서 구동되는 자바스크립트 특성상 플랫폼 별로 디버깅 도구가 다양하고, 사용법도 각기 다르기 때문에 보통 "자바스크립트 디버깅은 어렵다"고 말한다. 하지만 자바스크립트 디버깅 도구가 많이 발전했고, 특히 모던 브라우저의 개발자 도구는 대부분 유사한 기능과 UI를 제공하므로 어렵지 않게 디버깅 할 수 있다. 이 가이드는 디버깅 도구 중 가장 많이 사용하는 크롬 개발자 도구 중심으로 설명한다. 그리고 디버깅 환경이 조금 다른 인터넷 익스플로러(이하 IE) 개발자 도구도 설명한다. 다양한 환경에서 발생할 수 있는 크로스 브라우징 이슈는 크로스 브라우징 이슈에서 좀 더 상세히 다루기로 한다.

목차

크롬 개발자 도구

크롬 개발자 도구는 현재 전 세계에서 가장 많이 사용하는 디버깅 도구이고, 가장 많은 기능을 제공한다. Chromium(크롬의 오픈소스 프로젝트)을 기반으로 한 오페라도 크롬과 같은 개발자 도구를 사용한다. 이 가이드는 크롬 70버전을 기준으로 개발자 도구의 주요 화면과 기능을 설명한다. 그 외 기능은 공식 홈페이지에서 확인할 수 있다.

개발자 도구 실행 방법

  • 크롬 메뉴에서 실행하기

    • [도구 더보기] → [개발자 도구] 선택
  • 웹 페이지 상에서 실행하기

    • 마우스 오른쪽 버튼 클릭(이하 우클릭) → [검사] 선택
  • 단축키로 실행하기

    • Ctrl + Shift + I (윈도우)
    • Cmd + Opt + I (맥)

Sources 탭 기능 설명

Sources 탭에서는 페이지에 로드된 리소스 파일을 확인할 수 있으며, 현재 로드된 스크립트를 수정하여 테스트할 수 있는 스크립트 디버깅 기능을 지원한다. 아래의 그림은 Sources 탭 화면이다. 왼편에는 로드된 리소스 파일의 폴더 트리가, 중앙에는 소스코드가, 오른편에는 다양한 기능 버튼과 정보가 있다.

source_tab

위의 그림의 각 번호에 대한 자세한 설명은 아래와 같다.

1 ) 줄 번호를 클릭하여 중단점을 설정한다. 중단점을 설정하면 해당 줄 실행 단계에서 실행이 중단된다. 2 ) 실행이 중단된 상태에서 각 버튼으로 자바스크립트 실행 흐름을 제어하여 스텝 디버깅을 할 수 있다. 3 ) 디버깅 시 살펴보고 싶은 변수나 객체를 Watch에 등록하여 중단 시점에 어떤 값을 가졌는지 확인한다. 4 ) 웹 페이지가 로드된 순간부터 중단된 순간까지의 함수 호출 스택을 확인할 수 있다. 호출 스택을 클릭하면 해당 코드를 바로 볼 수 있다.

다양한 중단점 설정 방법

대개 Sources 탭에서 원하는 줄 번호에 중단점을 걸어서 사용하지만, 디버깅을 하다 보면 특정 위치가 아닌 특정 상황에서 중단점을 걸고 싶은 때가 있다. 크롬 개발자 도구는 코드의 특정 위치를 선택하기 어려운 순간에도 중단점을 설정할 수 있는 다양한 방법을 제공한다.

Event Listener Breakpoints

특정 이벤트가 발생한 시점을 디버깅하고 싶을 때 Event Listener Breakpoints를 사용한다. 예를 들어 클릭 이벤트에 중단점을 설정하면, DOM에 클릭 이벤트가 발생했을 때 이벤트 핸들러에서 실행이 중단된다. Sources 탭 → [Event Listener Breakpoints]에서 원하는 이벤트를 중단점으로 설정하고, 이후에 중단점으로 설정한 이벤트가 발생하면 실행이 중단된다.

event_breakpoint

조건부 중단점

Sources 탭에서 원하는 코드에 중단점을 설정하는 것과 비슷한데, 지정한 조건에서만 실행을 중단한다. 예를 들면 빈번하게 호출되는 함수에서 특정 값의 매개변수가 전달되는 순간이나 루프의 마지막 요소만 확인하고 싶은 순간 등에서 조건부 중단점을 사용한다. 원하는 코드 줄 번호에서 우클릭 → [Add conditional breakpoint]을 선택하면, 원하는 조건을 설정할 수 있다.

conditional_breakpoint1

필요한 조건을 코드로 입력하면, 해당 조건을 만족할 때만 실행이 중단된다.

conditional_breakpoint2

DOM 변화에 따른 중단점

특정 DOM이 변경되었을 때 실행을 중단할 수 있다. 즉, 특정 DOM이나 자식 노드에 변화가 있을 때만 실행을 중단한다. Elements 탭 → 원하는 element에서 우클릭 → [Break on]을 선택하면, 세 가지 메뉴가 나오고 이 중에서 원하는 것을 중단점으로 설정한다.

dom_breakpoint

Ajax 중단점

특정 주소로 요청을 보내는 Ajax 코드를 찾고 싶을 때 Ajax를 중단점으로 설정할 수 있다. 예를 들어 Ajax 호출이 일어나고 있지만 어떤 코드에서 요청하는지 확인하기 힘든 상황에서 활용할 수 있다. Source 탭 → [XHR/Fetch Breakpoints]에서 원하는 패턴을 추가하여 중단점을 설정하면, 해당 패턴의 Ajax 호출이 일어난 코드에서 실행이 중단된다.

ajax_breakpoint

블랙박스 설정 방법

스탭 디버깅으로 디버깅을 하다 보면 라이브러리 코드로 디버깅 포인트가 이동할 때가 있다. 라이브러리 코드에 버그가 있는 경우도 있겠지만 대부분은 우리가 작성한 로직을 디버깅해야 한다. 이때 블랙박스를 사용하면 라이브러리의 코드를 스탭 디버깅에서 숨길 수 있다. 또한, 디버깅 대상이 아닌 파일(라이브러리나 외부 파일 등)을 블랙박스 처리하면 해당 파일을 호출 스택에서 숨길 수 있고, 그럼 호출 스택에는 필요한 파일만 남아 내가 작성한 코드에 집중해서 디버깅할 수 있다. 블랙박스를 설정하는 방법은 두 가지이다.

컨텍스트 메뉴로 설정하기

Sources 탭에서 블랙박스로 처리할 파일을 열고, 우클릭하여 아래 그림과 같이 [Blackbox Script]를 선택한다. 또는 Call Stack에서도 우클릭으로 [Blackbox Script]를 선택할 수 있다.

blackbox1

Settings 메뉴에서 설정하기

[Settings] 메뉴 → Blackboxing 탭에서 블랙박스 처리할 파일을 추가 한다.

blackbox2

메모리 상태 확인

Performance 탭과 Memory 탭은 성능 저하 요인을 찾을 수 있는 중요한 정보를 제공한다. 성능에 대한 더 자세한 내용은 [FE 가이드] 성능을 참고하기 바란다. 이 가이드는 메모리 관점에서 성능 개선 포인트를 찾을 수 있는 방법을 설명한다. Memory 탭을 사용하면 아래의 그림과 같이 총 세 가지 프로파일링을 사용할 수 있다. 메모리 상태를 확인하며 디버깅을 해야할 때, 세 가지 방법을 적절하게 사용해보자.

memory1

힙 메모리 상태 확인

자바스크립트 구동 시에 힙 메모리에 올라가는 것에는 변수, 객체, 클로저 등이 있고, 가비지 컬렉터가 메모리 생명 주기를 관리한다. 가비지 컬렉터는 더 이상 사용하지 않는 메모리를 주기적으로 회수하는데, 이때 참조가 하나라도 남아있는 객체는 회수하지 않는다. 이렇게 남아 있는 메모리는 메모리 누수를 발생시킨다. [Heap snapshot] 프로파일링 방법을 사용하여 현재 힙 메모리 상태를 확인할 수 있다.

memory_heap_snapshots

위의 그림은 두 개의 힙 스냅샷을 생성하여 비교한 화면이다. Snapshot 1은 페이지가 로딩되고 힙 스냅샷을 기록한 것이고, Snapshot 2은 페이지 로딩 이후 여러 동작을 한 뒤 힙 스냅샷을 기록한 것이다. 이때 Snapshot 2화면에서 빨간 박스 항목을 Comparison으로 변경하면 Snapshot 2를 기준을 Snapshot 1과 메모리를 비교할 수 있다. 비정상적으로 메모리가 증가하거나 혹은 해제되지 않는 부분이 있는지 두 Snapshot 비교 결과로 유추할 수 있다.

타임라인으로 메모리 할당/해제 확인

타임라인으로 메모리 변화를 확인하고 싶을 때는 [Allocation instrumentation on timeline]을 사용하여 웹 페이지 동작 중 메모리 사용량이 어떻게 변하는지 기록할 수 있다. 아래의 그림은 타임라인으로 메모리를 기록한 것으로 파란색 막대는 새롭게 할당된 메모리양을 나타낸다. 파란색 막대를 토대로 메모리 누수나 증가 혹은 가비지 컬렉터가 불필요하게 많이 일어나지는 않는지 등 메모리 사용량 추이를 확인한다.

memory_timeline

메모리가 할당되는 시점 찾기

[Allocation sampling]은 메모리가 할당되는 시점을 기록한다. 아래의 그림처럼 함수별 메모리 할당 내역을 보여주고, 가장 많은 메모리가 할당된 함수부터 나열해주므로 메모리를 많이 사용하는 함수를 찾을 수 있다.

allocation samplling

모바일 디버깅

모바일에서 실행된 웹 페이지를 디버깅하려고 할 때 개발자 도구를 모바일 환경에서 실행시킬 수 없으니 막막할 수 있다. 이때 크롬이나 사파리의 원격 디버깅을 사용하면 모바일의 브라우저 및 웹뷰에서 구동된 페이지를 PC에서 디버깅할 수 있다. 안드로이드 기기는 크롬을, iOS 기기는 사파리를 이용하여 원격 디버깅을 한다.

안드로이드 웹 페이지 디버깅

크롬의 원격 디버깅으로 안드로이드 기기의 웹 페이지를 디버깅하는 방법을 설명한다. 참고로 웹뷰를 디버깅할 때는 웹뷰 어플리케이션 내에 설정이 따로 필요하므로 관련 문서를 확인하길 바란다.

준비사항

  • 크롬 32버전 이상
  • 안드로이드 4버전(아이스크림 샌드위치) 이상
  • 안드로이드 기기에 크롬 설치
  • 윈도우의 경우 개발용 컴퓨터에 안드로이드 USB 드라이버 설치
  • 안드로이드 기기와 연결할 USB 케이블

안드로이드 기기에서 설정할 것

  • [Settings] → [Developer Options] → [Enable USB Debugging]을 설정한다.
  • 개발용 컴퓨터와 USB 케이블로 연결한다.

개발용 컴퓨터에서 디버깅하기

개발용 컴퓨터에서 크롬 개발자 도구를 열어 [More tools] → [Remote devices]를 선택한다.

remote_debugging1

그럼 아래와 같이 연결된 기기 정보가 왼쪽에 표시되고 해당 기기를 선택하면 안드로이드 크롬에 열려있는 링크를 확인할 수 있다.

remote_debugging2

디버깅할 페이지의 [Inspect] 버튼을 눌러 디버깅을 한다.

iOS 웹 페이지 디버깅

사파리의 원격 디버깅으로 iOS 기기의 웹 페이지를 디버깅하는 방법을 설명한다.

준비사항

  • iOS 6 이상이 설치된 기기
  • 맥 OS가 설치된 기기
  • iOS 기기와 맥 OS 기기를 연결할 케이블

iOS 기기에서 설정할 것

  • [Settings] → [Safari] → [Advanced]에서 [Web Inspector] 설정을 켜둔다.
  • 맥과 아이폰을 케이블로 연결한다.

개발용 컴퓨터에서 디버깅하기

개발용 컴퓨터에서 사파리를 실행하고, [Safari] → [Preferences] → [Advanced] → [Show Develop menu in menu bar]를 설정한다.

safari_remote_debugging1

그럼 메뉴표시줄에 Develop(개발자용) 메뉴가 생기고, 아래의 그림처럼 연결된 아이폰 기기의 실행 중인 웹 페이지를 확인할 수 있다. 혹시 연결된 아이폰 기기가 보이지 않는다면, 아이폰의 사파리 버전과 맥 OS의 사파리 버전이 일치하는지 확인하고, 일치하지 않는다면 같은 버전으로 맞춰준다.

safari_remote_debugging_2

디버깅하고자 하는 웹 페이지를 선택하면 아래의 그림처럼 개발자 도구가 실행되고, 아이폰 기기의 웹 페이지를 디버깅한다.

safari_remote_debugging_3

iphone_debugging

프락시를 통한 디버깅

특정 패킷을 조작하여 서버의 응답을 다르게 받거나, 서버에 배포된 자바스크립트 파일을 교체해서 테스트하고 싶을 때 Fiddler나 Charles와 같은 프락시 도구가 필요하다. 프락시 도구는 PC의 네트워크 요청과 응답을 모니터링하고 서버와의 요청/응답에 중단점(Breakpoints)을 걸어 패킷을 조작할 수 있다. 그리고 프락시 도구로 이미 서버에 배포되어 서비스 중인 페이지의 파일(자바스크립트 파일, CSS 파일 등)을 원하는 파일로 대체하여 테스트해 볼 수 있다. 이 가이드에서는 Fiddler와 Charles를 예시로 네트워크 트래픽을 모니터링해보고, 서버의 응답을 변경하는 방법을 설명한다. 이 외의 많은 기능은 Fiddler의 공식 문서Charles의 공식 문서에서 확인할 수 있다.

Fiddler

Fiddler로 네트워크 트래픽을 기록하고 조회하며, 서버 요청에 대한 응답을 변경할 수 있다. 설치 파일은 공식 다운로드 페이지에서 다운로드하고, 특별한 설정 없이 [다음] 버튼을 이용하여 설치한다.

트래픽 캡처

트래픽 캡처는 Fiddler의 주요 기능 중 하나로 Fiddler를 실행하면 아래와 같이 트래픽을 조회할 수 있다.

Fiddler_1

하지만 모든 트래픽을 캡처하기 때문에 디버깅이 어렵다. 이럴 때 필터링 기능으로 원하는 트래픽만 캡처한다. 아래 그림은 자바스크립트 파일만 캡처하도록 설정한 예제이다.

Fiddler_2

Fiddler_3

AutoResponder로 응답 변경하기

AutoResponder는 Fiddler의 가장 강력한 기능 중 하나로, 특정 요청에 대해 응답 값을 변경할 수 있다. 이 기능을 사용하면 서버에 배포된 자바스크립트나 CSS 파일 등을 원하는 파일로 바꿀 수 있다. 예를 들어 A 사이트에서 config.js의 파일을 임시로 수정하고 싶다고 가정하자. 우선 config.js를 수정하여 로컬에 저장하고, 아래와 같이 체크 박스를 선택하여 AutoResponder를 활성화한다.

Fiddler_4

AutoResponder를 활성화했다면, 좌측 트래픽 영역에서 응답을 변경할 요청을 선택한 후 [Add Rule] 버튼을 눌러 응답 규칙을 추가한다.

Fiddler_5

만일 변경 할 요청을 정규식으로 정의하고 싶다면 "regex: 정규식"을 사용한다. 자세한 사용법은 관련 문서를 참고하기 바란다.

Fiddler_6

요청 설정을 완료했다면, 아래와 같이 응답 입력란을 클릭하여 응답 규칙을 설정한다.

Fiddler_7

[Find a file]을 선택하면 응답으로 대체할 파일을 탐색기에서 선택할 수 있다. 이때 로컬에서 수정한 config.js 파일을 선택하고 [Save] 버튼을 누른다. 그리고 브라우저를 새로고침하면, 지정한 파일로 응답이 변경된 것을 확인할 수 있다. 만일 지정한 파일로 응답이 변경되지 않았다면, 브라우저 캐시를 삭제하고 다시 시도해본다.

Fiddler_8

자주 발생하는 문제

Fiddler를 종료하지 않고 PC를 끌 경우, 다음 부팅 시 브라우저를 열었을 때 아래와 같은 현상이 발생하는 경우가 있다. 이 현상이 발생할 때는 Fiddler를 다시 실행하거나 정상적으로 종료하면 된다.

Fiddler_9

Charles

현재까지 OSX에서 가장 많이 사용하는 프락시 도구이다. Fiddler의 AutoResponder와 같은 기능을 하는 Map Local/Map Remote와 세션 디버깅 기능이 있다. HTTP와 HTTPS를 지원하고, 세션을 순서 위주로 보는 Sequence 탭과 주소 위주로 보는 Structure 탭이 있는 것이 특징이다.

설치

공식 사이트에서 제공하는 설치 파일을 사용할 수 있지만, 유료 라이센스이므로 별도 구매가 필요하다. 설치 후 Charles를 실행하면 자동으로 프락시가 설정된다. 만약 안 될 경우 아래의 그림처럼 [Proxy] → [Proxy Settings] 메뉴에서 HTTP Proxy의 Port가 현재 PC에서 사용하고 있는 포트와 겹치지 않는지 확인한다. 또는 Mac OS X 탭에서 [Enable Mac OS X proxy]가 제대로 체크되어 있는지 확인한다. 만약 PC에서 VPN이 설정되어 있거나 브라우저의 플러그인으로 VPN이 동작하고 있으면 세션이 캡처되지 않기 때문에 문제 발생 시 이 부분도 참고하면 도움이 된다.

charles_proxy_setting

세션 목록 보기

Charles에서는 세션 목록을 확인하는 방법으로 Sequence와 Structure 탭을 제공한다. 상황에 따라 적절한 탭에서 세션 정보를 확인한다. 각 탭의 특징은 아래와 같다.

Sequence

Fiddler와 마찬가지로 모든 요청을 시간순으로 쌓아 보여 준다. 각 요청에 대한 상세 정보를 테이블 형태로 빠르게 볼 수 있는 장점이 있다.

charles_sequence

Structure

트래픽을 감지하는 동안 쌓이는 세션을 도메인 기준의 트리 형태로 보여 준다. 아래 그림과 같이 도메인 별로 나뉘기 때문에 단순 나열보다 보기 편하다. 아래 그림에서 왼편은 도메인 리스트로 여기서 원하는 항목을 선택하면 오른편에서 상세 내용을 볼 수 있다. 같은 요청이 발생된 경우에는 마지막 폴더에 요청이 쌓인다.

charles_structure

보통 자바스크립트 개발 시의 문제는 한 도메인 내에서 생기는 경우가 많기 때문에 Structure를 사용하는 것이 좋다. 왜냐하면 API를 혼동하지 않고 문제가 되는 세션을 빠르게 찾을 수 있기 때문이다.

세션 상세 보기

세션 상세 보기는 총 5개의 탭으로 구성되어 있으며 각 탭에서 확인할 수 있는 정보는 다음과 같다.

Overview 탭

세션의 정보를 간략히 보는 탭으로 요청, 응답, 타이밍 등을 확인할 수 있다.

charles_overview

Contents 탭

세션의 요청과 응답을 확인할 수 있다. 상단이 요청내용이고 하단이 응답 내용이다. 단일 파일 요청은 아래와 같이 단순하나 JSON과 같은 데이터의 경우 정렬된 모양으로 볼 수 있다.

charles_content

Summary 탭

세션의 정보를 테이블 형태로 보여주는 탭으로 단일 세션을 보는 용도보다는 다른 세션과 비교하는 용도로 사용한다.

charles_summary

Chart 탭

세션의 타임라인을 막대그래프로 볼 수 있다.

charles_chart

Note 탭

세션에 메모를 하고 싶을 경우 사용한다.

charles_note

Map Local로 응답 변경하기

Fiddler의 AutoResponder와 같은 기능으로 서버의 응답을 로컬의 특정 파일로 보낼 수 있다. 우선 세션 중 로컬 파일로 응답을 대체하고 싶은 파일을 찾는다. 예시로 아래의 그림에서 basic_dummy.js 파일을 로컬 파일로 대체한다고 가정하자.

charles_map_local_1

basic_dummy.js 파일에서 우클릭하여 Map Local을 선택하면 아래와 같이 대체할 파일을 선택할 수 있는 Edit Mapping 창이 나타난다. 여기서 [Choose] 버튼을 클릭하여 대체할 로컬 파일을 선택한다.

charles_map_local_edit_mapping

혹은 메뉴의 [Tools] → [Map Local]을 선택하여 Map Local Settings 창에서 맵핑 할 내용을 추가할 수 있다. Enable Map Local을 체크하고 [Add] 버튼을 눌러서 맵핑 할 내용을 추가한다.

charles_map_local_setting

Map Remote로 요청 변경하기

특정 요청을 다른 요청으로 대체할 수 있다. Map Local과 비슷하지만 대체할 파일을 등록하는 것이 아니라 요청 자체를 다른 요청으로 변환하는 것이다. 사용 방법은 Map Local과 같이 우클릭하여 Map Remote 메뉴를 선택하면 아래와 같이 Edit Mapping 창이 나타난다. 하단의 Map To 내용을 대체할 요청으로 채워 넣는다.

charles_map_remote_edit_mapping

혹은 메뉴에서 [Tools] → [Map Remote]를 선택하여 Map Remote Settings 창에서 맵핑할 내용을 추가할 수 있다. Enable Map Remote를 체크하고 [Add] 버튼을 눌러서 맵핑할 내용을 추가한다.

charles_map_remote_settings

IE 개발자 도구

IE8 미만

IE8 미만은 디버깅 도구를 지원하지 않는다. 그래서 Debug Bar라는 별도의 도구를 사용해야 한다. Debug Bar는 Companions.JS에서 제공하는 무료 도구로 IE에서 console 객체를 사용하여 디버깅할 수 있도록 지원하는 도구이다. DebugBar 공식 사이트에서 다운로드하거나 설치 매뉴얼을 확인할 수 있다.

IE8 ~ IE11 그리고 엣지

IE8부터는 개발자 도구가 기본적으로 포함되어 있다. 그래서 브라우저의 도구 메뉴나 F12 키를 통해 개발자 도구를 실행시킬 수 있다. 개발자 도구가 실행되면 아래 그림과 같이 브라우저 하단에 화면이 분리되어 나타난다. IE8 이상과 엣지의 개발자 도구는 앞서 설명한 크롬 개발자 도구와 유사하므로 자세한 설명은 생략하겠다. (참고: IE 개발자 문서, 엣지 개발자도구 문서)

ie_dev_tool2

가상 머신

2013년도 Microsoft에서는 여러가지 IE 버전을 다양한 플랫폼에서 테스트하기 위해 modern IE를 내놓았다. modern IE는 IE6부터 IE11까지의 실행 환경을 가상머신으로 제공하는 도구이다. 하지만 2015년에 엣지라는 새로운 브라우저를 발표하면서 더는 modern.IE라는 명칭은 사용하지 않는 것으로 보인다. modern IE로 접속 시 가상 머신 이미지 다운로드 페이지로 리다이렉션 되고, 해당 페이지에서 가상 머신으로 제공하는 IE의 버전도 8부터 11까지로 변경되었다. 그리고 엣지의 가상 머신 이미지도 새롭게 추가되었다. 2018년 9월 현재 제공하는 가상 머신 도구는 Virtual Box, Vagrant, VMware, Hyper-V, Parallels 이다.

개발 환경이 윈도우가 아닌데 IE 디버깅이 필요하거나, 특정 윈도우 버전에서의 IE 테스트가 필요한 경우에 가상머신을 사용해서 IE를 디버깅할 수 있다. 이 가이드는 Virtual Box로 IE8 가상 머신을 사용하는 방법을 설명한다. Virtual Box는 단순 테스팅 용도로는 자유롭게 사용할 수 있지만, 그 외의 사용에 대해서는 라이선스 비용이 발생한다.

VirtualBox 가상 머신 플랫폼 설치

VirtualBox 공식 사이트에서 자신 PC의 OS에 해당하는 설치 파일로 설치한다. 가상 머신 하나당 크기가 1G 이상이기 때문에, 가상 머신이 설치될 경로를 용량이 넉넉한 위치로 지정하도록 한다.

VM1

가상 머신 다운로드

가상 머신 이미지 다운로드에서 설치하고자 하는 OS와 IE 버전을 선택한 뒤 Select Platform을 "VirtualBox"로 선택하여 가상 머신을 다운로드한다.

modernIE_download

구동하기

VirtualBox에서 다운로드한 가상 머신 이미지를 구동하면 된다. 아래와 같이 가상 시스템 가져오기 메뉴를 클릭하여 다운로드한 가상 머신 이미지 파일을 지정한다.

VM2

현재 PC의 RAM 상태를 고려하여 필요할 경우 가상 머신의 RAM을 조정한다.

VM3

설정을 마치면 시스템을 불러오기 시작하는데, 모두 완료될 때까지 몇 분이 소요된다.

VM4

모두 완료 되면 아래와 같이 선택한 가상 시스템이 추가되고, 해당 가상 시스템을 더블클릭하면 가상 머신이 구동된다.

virtual_machine

맺음말

브라우저의 개발자 도구와 프락시 도구 및 모바일 기기의 디버깅까지 웹 페이지를 디버깅하는 다양한 방법을 알아보았다. 웹이 동작할 수 있는 환경이 많아지면서 디버깅의 형태와 방법이 다양해지고 있다. 이 가이드에서 다루는 디버깅 방법만 익혀도 효율적인 디버깅을 할 수 있을 것이다. 이 가이드가 당신의 디버깅에 도움이 될 것이다.


이 문서는 NHN Cloud의 FE개발랩에서 작성하고 관리하는 공식 웹 프론트 개발 가이드이다. 가이드 적용 관련 문의나 문서의 오류, 개선 제안은 공식 문의 채널(dl_javascript@nhn.com)을 통해 할 수 있다.


Last Modified
2019. 05. 07
FE Development LabBack to list