MOSS 2007 기반으로 개발을 하거나, 기타 웹 어플리케이션을 만들면 꼭 들어가는 코드가 바로 JavaScript 이다.특히나 동적 웹을 구현을 하려면 특히 자주 활용하게 된다.
하지만, 그 Javascript의 동작이 올바른지 올바르지 않은지에 대한 판단을 하는 모습을 보면, 상당히 원시적으로 하는 경우를 많이 보게 된다. 일단 동작하는 화면을 보고, 그 결과물을 보고 현재 구성된 Javascript를 보고, 일부 수정하거나 MessageBox를 띄우고 결과물 보고..
이렇게 Javascript를 수정하는 경우 경험이 많은 개발자야 짐작과 동시에 문제점을 찾기라도 하지만, 웹 개발에 익숙치 않거나, 아예 문법 오류로 인해 Javascript 자체가 실행 안된 경우라면, 거의 좌절이다. 게다가, 웹 페이지 내에 직접 박아 넣은 Javascript라면 그럭저럭 짐작이라도 하는데, 다른 Javascript 소스를 include 한 경우라면, 이야기가 점점 꼬이기 시작한다. 뭐가 문제인지 짐작도 되지 않는다.
다행이, FireFox나 Google Chrome과 같은 웹브라우저에서는 자체적으로 혹은 외부 플러그인을 통해 디버깅이 가능하며 그 기능은 상상을 초월한다. 훌륭하다 못해 멋지기 까지 할 정도로 정확하게 값을 뽑아오며, 정확히 어느 파일의 어느 위치에 오류가 있는지 알려주며, 현재 상태 값을 보면서 정확한 오류 내용을 파악할 수 있다.
그러나, 우리나라 환경에서 개발하는, 그것도 새로 개발도 아니고, 기존 코드를 수정하는 입장인 경우, Javascript를 까보면, FireFox나, Chrome에서는 동작하지도 않는 경우가 허다하다. 특히나 ActiveX 같은 X 같은 플러그인 꽂은 곳은 아예 Gothem! 레벨. 결국 IE로 띄워 뭔가 디버깅을 시도해야 된다는 슬픈 일이 닥친다.
하지만, MS 기반, IE 온리 개발하는 곳에서는 일반적으로 Visual Studio를 이용한 .NET 개발이 주로 발생되는데, 이 경우 라면 해피하다. 여기서는 이 해피한 경우에 대처하는 좋은 방법을 알려드리려 한다.
1. IE 설정.
IE가 6.0으로 쫑 날 줄 알았으나, FireFox와 Chrome, 사파리 등의 웹 브라우저의 등장으로 위기감의 고조와 함께, 그 동안 계속되었던 6.0의 버그, 속도 문제등의 이유로 결국 7.0을 내 놓았다. 그러나, 7.0을 탑재한 Vista의 처절한 실패로 인해 Windos 7과 함께, 등장한 8.0 으로 업그레이드 되었다.
즉, 이제 IE는 6.0, 7.0, 8.0 이 혼재된 모습을 보이기 시작했다.
일단, 8.0을 기준으로 설명하며, 7,0이나, 6.0은 다른 곳을 찾아보거나, 짐작해서 옵션을 변경해야 할 것 같다.
IE를 실행 한 뒤, 인터넷 옵션을 띄우고, 인터넷 옵션에서 “고급”탭을 클릭해서 연다.
여러가지의 항목들 중 “스크립트 디버깅 사용 안함(기타)”, “스크립트 디버깅 사용 안함(Internet Explorer)”에 체크 되어 있는 것을 끄도록 한다.
2. 에러 페이지까지 가기.
Visual Studio가 깔린 PC에서 IE를 통해 먼저 에러가 발생하는 페이지까지 접근하도록 한다. 지금 필자에게는 마땅히 띄울 UI가 담긴 Page가 없으므로 에러가 발생하는 페이지를 띄우도록 할 것이다.
에러가 발생했다. 그러면 에러 페이지가 뜨는데, 여기서 체크 박스들을 없애고 “예(Y)”를 클릭한다.
위의 팝업이 안뜨면 브라우저의 왼쪽 아래에 있는 경고 표시를 클릭하면 볼 수 있다.
일단 “예(Y)”를 하면, IE에 등록된 Javascript 디버거들의 목록이 뜬다.
현재 필자는 변변한 디버거라고는 Visual Studio 정도지만, Office 2003~2007 을 전체설치하는 경우 Javascript 디버거가 별도로 설치될 수 있다. 또는 3rd Party 제품이 뜰 수도 있다. 다른 제품들은 각 제품의 설명을 보도록 하고, 여기서는 Visual Studio로 선택하도록 한다.
혹여 Visual Studio일지라도 이미 떠 있는 Visual Studio를 선택할 수 있는데, 가급적이면, 새 인스턴스 Visual Studio를 선택하도록 한다.
3. Visual Studio 에서 디버깅.
“새 인스턴스 Visual Studio XXXX”를 선택하고 “Y”를 클릭하면 Visual Studio가 뜬다. 이 때 디버깅을 하는 것은 iexplore.exe 자체. 무슨 프로세스를 걸던 간에 일단 띄워보면, 정확한 오류 메시지를 알려준다.
오류 보시고, 이번엔 “중단(B)” 버튼을 클릭한다.
그러면 소스가 보일 것이고, 어디서 오류가 났는지 볼 수 있다.
왼편에는 지금 오류가 난 페이지와 관련된 각종 Javascript 소스들과 Html 소스들이 쭉 나래비가 펼쳐질 것이고,
오른편에는 해당되는 소스가 보인다. 여기서 부터는 Visual Studio 만의 디버그 UI를 활용함으로써 충분한 기능을 발휘할 수 있다.
소스 자체에서 커서를 위로 올리면 인텔리센스의 또다른 기능인, 변수 값들을 볼 수 있으며, 조사식, 콜스택, 지역 변수 값들을 모두 보면서 진행할 수 있다. 한단계씩 실행할 수도 있다.
4. 고급 디버깅 - 중단점
꼭 오류가 나기 이전 단계에서 디버그를 시작하고 싶은 경우에는 중단점을 이용하면 된다.
자신이 원하는 곳에다 중단점을 걸고 진행하면 되는데, 이를 위해서는 항상 동일한 위치에서 오류가 발생해야 쉽게 적용 가능하다. 방법은 아래와 같다.
1. 자신이 원하는 위치에 중단점을 건다.(Visual Studio 버전에 따라 중단점을 걸게 되는 조건이 조금씩 다르다.)
2. 디버그를 끝까지 진행시킨다.(디버그에서 계속 버튼 – 디버깅이 멈춰진 곳에서 계속 진행하도록 하는 버튼)을 누르거나 선택하면 된다.)
3. 경고창으로 뜨는 메시지에 예외를 iexplore로 보내겠다는 메시지에 예(Y)를 선택한다.
4. 브라우저로 돌아와서, 다시 Refresh를 한다.
5. 그러면 자신이 중단점을 건 위치에 커서가 멈춰 있게 된다.
5. 줄이며.
사실 Visual Studio의 기능은 막강한 편이다. 최초 5.0, 6.0 같은 경우 Windows 기반 Application 제작에 비중이 실렸다면, Visual Studio 2003 부터 조금씩 조금씩 웹 쪽에 대한 기능이 실리기 시작했다. 특히 Visual Studio 2005 부터는 ASP 개발에 있어 그 편리성은 혁신에 가깝게 진행되었다.
최소한 위의 디버그 모드에 대한 기능은 2003보다는 2005가, 2005 보다는 2008에서 더 정확하게 확실하게 동작함을 알 수 있다. 다소 툴이 무거워 쉽게 접근하는건 무리겠지만, 웹 표준에 제대로 맞지도 않는 웹 개발을 특히나 유지보수를 하려고 한다면, IE를 쓰고, Visual Studio를 쓰는 강수를 노려야 되니… 뭐 억지로라도 쓰도록 한다.
일단 쓸 수 있는 환경(CPU나 RAM이나.. 개발자 PC의 성능 문제가 대부분)이라면, 나름 장점이 많은 도구이니, 활용하는데 큰 무리가 없으리라 본다.
UPDATE:
저 위의 방법은 Javascript가 오류가 난다는 가정하에서 하나씩 거는 방법이다. 만일 Javascript의 오류가 나지 않을때, 디버그를 걸어 확인하고 싶을 때까 있다.
그런 경우에는 소스 내에 "debugger;" 라는 줄을 추가하면 된다.
그러면 debugger 라고 적힌 줄에서 에러가 난 것 처럼 표시되고, 위의 방법대로 진행이 가능하다.
