한 2년 전인가 구글 개발자들이 회사에 온 적이 있는데 당시에 내가 했던 질문이 "DOM/Event Listener Breakpoint는 유용한 기능인데 항상 라이브러리에서 멈추기 때문에 활용도가 떨어지는데 개선할 계획이 있냐?" 였다.

그 때 paul irish가 "아. 그거 조만간 나올 예정이다"라고 했다.

그리고 나서 작년 겨울인가 디버깅하다가 갑자기 생각나서 그 기능 개발되었나 하고 찾아보니 적용이 되어 있어서 사용하고 있는데 생각보다 사람들이 이 기능을 몰라서 잠깐 설명할까 한다.


예를 들어, 어느날 서비스를 담당하는 개발자가 휴가를 갔다. 근데 버그가 발견되어서 내가 대신 처리해야 하는 상황이다.

버그는 특정 버튼을 누를 때 레이아웃이 이상하게 된다고 가정하자.

이런 상황에서 일반적으로 내가 해당 코드를 모르기 때문에 js을 바로 찾진 못하고 버튼 엘리먼트의 아이디, 클래스, 이벤트명등의 단서를 가지고 js파일을 찾는다. 그리고 거기에 debugger을 걸면서 해당 이벤트가 발생하는 시점을 확인하면서 디버깅을 한다.

만약에 click이 발생하는 시점에 호출되는 함수를 알 수 있다면 아마 좀 더 쉽게 디버깅을 할 수 있을 것이다.

이게 바로 source tab에 있는 Event Listener Breakpoints다.


위와 같이 click은 선택하면 click이벤트가 발생했을때 해당 함수에 break point가 걸린다.

근데 문제는 대부분이 라이브러리를 사용하기 때문에 아래와 같이 라이브러리 코드에서 멈춘다.



그러면 다음 다음을 누르면서 해당 함수를 찾아가야 하니 생각보다 편하지 않다.

이때, 사용하는게 "Blackbox JavaScript Source Files"다.

크롬 개발자 도구에서 "설정 -> General -> Sources"에 가면 아래와 같이 "Manage framework blackboxing..."을 눌러 라이브러리를 등록한다.



그리고 나서 다시 실행하면 아까와는 다르게 아래와 같이 내가 작성한 코드에서 break point가 걸린다.


이제 부터 "Event Listener Breakpoints"는 너무 편해진다.

그리고 디버깅할 때 등록한 라이브러리 코드는 디버깅 대상에서 제외된다. 이것도 완전 편하다. 항상 다음 함수로 넘어가기를 누르면 라이브러리 코드로 가서 들어갔다 나왔다를 반복해야 하는데 이런 문제도 없다. 

이 기능은 정말 디버깅할 때 강추한다.

내가 사용해보니 좀 노하우가 생겼는데 그 중 하나가 라이브러리 코드 뿐 아니라 의존성을 가지는 파일 중에 보지 않아도 되는 파일이 있다면 해당 파일을 등록하면 좀 더 디버깅이 간단해진다.


ps. 참. 아쉽게도 DOM break point은 black box을 사용할 수 없다.

[깨알팁 시리즈]

Posted by 전용우

댓글을 달아 주세요

  1. Favicon of http://sunbie.tistory.com/ BlogIcon Sunbie 2015.09.17 08:21  댓글주소  수정/삭제  댓글쓰기

    감사합니다. 이것 때문에 고생 까지는 아니지만 꽤 디버깅이 귀찮았습니다. F10만 주욱 누르고 있었는데 ㅎㅎㅎ 게다가 반복문이라도 있으면...@_@;
    이제 해방이네요.

  2. 강태희 2015.09.18 00:10  댓글주소  수정/삭제  댓글쓰기

    정말 감사합니다!!! 어쩜이리도 좋은 정보를 감사합니다 (__)

  3. 이범희 2015.09.18 10:04  댓글주소  수정/삭제  댓글쓰기

    좋은 내용 공유 감사합니다.

    다만, 아쉬운게 개발중일때에는 쉽게 block을 할 수 있는데
    서비스 되고 있는 페이지를 디버깅하기에는 쉽지 않겠네요.
    (특별한 상황이긴 하지만 다른 서비스 디버깅이라던가,, 우리 서비스 디버깅이라던가...)

    대부분이 라이브러리 코드도 같이 하나의 파일로 묶어서 서비스 하는 경우가 많으니...

    그래도 매우 좋은 기능이라 활용도가 많을 것 같습니다.




    • Favicon of http://www.jasonim.me BlogIcon 임승진 2015.09.18 14:14  댓글주소  수정/삭제

      서비스상황에서도 확인해볼 수 있도록 minify된 소스를 적당히 풀어서 보여주는 기능이 크롬에 있습니다.ㅎㅎ 큰 도움이 됐어요. - 지나가는 개발자...

    • nundefined 2015.09.22 00:14  댓글주소  수정/삭제

      모듈 구조로 되어 있다면 모든 파일을 한 줄로 이어붙이지 않고 모듈별로 한 줄씩 출력해도 디버깅이 살짝 편해집니다. 적어도 어느 모듈에서 문제가 발생했는지 알게 되서 쉽게 문제의 범위를 줄일 수 있더군요.

  4. Favicon of http://www.ysnotool.com BlogIcon yson 2015.10.13 15:05  댓글주소  수정/삭제  댓글쓰기

    좋은 팁입니다. 감사합니다 ^^
    사파리에도 있을라나 모르겠네요 ㅎㅎ

  5. 김야동 2015.11.04 18:00  댓글주소  수정/삭제  댓글쓰기

    꿀팁 감사

  6. 윤종문 2016.08.12 11:46  댓글주소  수정/삭제  댓글쓰기

    블랙박스가 이때 쓰는 거군요!

기존 자바스크립트 프로파일링은 어떤 함수가 얼마나 오래 걸렸는지 프로파일링 하기 때문에 소비 시간을 기준으로 느린 함수와 빠른 함수를 확인할 수 있었다.

하지만, 어떤 시점에 어떤 함수가 실행되고 얼마나 느린지 확인할 수 없었다.

예를 들어, 프로파일링을 실행하고 이벤트들을 수행한 다음 프로파일링을 끝내면 기존에는 프로파일링은 어떤 함수가 느린지 확인할 수 있었다면, 이벤트가 발생한 시점에 어떤 함수가 빠르고 느린지 확인할 수 없었다.

이 부분을 최근 크롬 개발자도구에서 프레임차트(Frame Chart)의 기능을 이용하여 시간의 흐름에 따라 함수의 실행시간을 확인할 수 있다.

즉, 특정 시점에 어떤 함수가 느린지 확인하고 싶을때 프레임 차트를 사용하면 유용하다.


프레임차트의 사용법은 기존과 같이 JavaScript CPU 프로파일 수집하기(Collect JavaScript CPU Profile)을 실행한 후 결과화면에서 아래와 같이 프레임차트(Frame chart)을 선택하면 된다.





아래와 같은 화면을 볼 수 있다.





여기서 확인할 수 있는 데이터는 5가지이다.


이름(Name) : 함수의 이름

실행 시간(Self time) : 호출된 함수를 제외하고 자신이 실행한 시간

전체 시간(Total time) : 함수가 실행된 전체 시간

실행 시간 합계(Aggregated self time) : 함수의 실행 시간(Self time)의 합

전체 시간 합계(Aggregated self time) : 함수의 전체 시간(Total time)의 합


이 5가지 데이터를 가지고 개선작업을 하면 된다.


ps. 크롬 개발자 도구는 정말 좋다.

Posted by 전용우

댓글을 달아 주세요

  1. Favicon of https://namocom.tistory.com BlogIcon 나모찾기 2014.01.09 19:20 신고  댓글주소  수정/삭제  댓글쓰기

    혹시 '자바스크립트 테스트와 디버깅' 저자 전용우 님이신가요?

  2. Favicon of http://www.jkun.net BlogIcon JKUN 2014.12.31 16:51  댓글주소  수정/삭제  댓글쓰기

    오옷 왜 여태 몰랐을까요 ㅎㅎ
    감사합니다.

    담아가서 링크 크게 걸어놓았습니다~ ^^