Logpoints 및 자동 연결 소개

2018년 7월 12일 Kenneth Auchenberg, @auchenberg

지난 몇 달 동안 Visual Studio Code의 디버깅 환경을 개선하는 데 힘써왔습니다. 이 게시물에서는 디버깅에 대한 저희의 생각, 사용자로부터 들은 피드백, 그리고 VS Code에서 디버깅을 더 쉽고 간편하게 만들기 위해 취하고 있는 조치에 대해 설명하겠습니다.

VS Code의 시작부터 저희는 통합 디버깅 환경을 제공해 왔습니다. 저희는 디버깅이 소스 코드를 작성하고 편집하는 곳, 즉 편집기의 필수적인 부분이어야 한다고 믿기 때문입니다.

VS Code debugger

VS Code의 디버깅 환경은 Debug Adapter Protocol(DAP)을 통해 특정 유형의 VS Code 확장 프로그램인 Debug Adapter(DA)와 통신하는 범용 디버거 UI에 의해 구동됩니다. DA는 실제 디버거와 통신하고 DAP와 런타임별 디버거 프로토콜 또는 API 간의 변환을 수행합니다.

이는 VS Code의 핵심이 특정 디버거와 완전히 분리되어 있으며, 이 아키텍처를 통해 VS Code는 여기에 표시된 것처럼 Debug Adapter만 있으면 무엇이든 디버깅할 수 있다는 것을 의미합니다.

VS Code debugging architecture

관찰 및 문제점

오늘날 VS Code로 정기적으로 디버깅하는 만족스러운 개발자가 많이 있지만, 저희의 사명의 일부로서 더 많은 개발자에게 디버깅을 더 쉽게 제공하고자 합니다.

이를 위해 VS Code 디버깅의 문제점과 일부 개발자가 저희 디버거를 전혀 사용하지 않는 이유를 더 잘 이해하기 위해 대화를 시작했습니다.

저희의 관찰 결과는 다음과 같습니다.

디버그 구성을 올바르게 설정하기 어렵습니다.

VS Code는 특정 스택이나 런타임에 특화되지 않은 범용 편집기이며 범용 디버거입니다. 따라서 모든 사용자에게 작동하는 의견이 반영된 기본 디버그 구성을 제공할 수 없습니다.

이는 VS Code가 디버거 설정을 구성하고 런타임을 올바른 매개변수 등으로 시작하는 방법을 지정해야 함을 의미합니다.

이것을 올바르게 설정하는 것이 어렵다는 것을 알고 있지만, 모든 사람을 위해 디버그 구성을 완전히 제거할 방법은 보이지 않습니다. 하지만 디버그 구성이 단순화될 수 있으며, 컨텍스트에 따라 최소한으로 줄어들 수 있다고 믿습니다.

이 내용은 나중에 다시 다루겠습니다.

launch 및 attach 구성 간의 혼란

VS Code에는 두 가지 핵심 디버깅 개념인 **Launch**와 **Attach**가 있으며, 이들은 두 가지 다른 워크플로와 개발자 세그먼트를 처리합니다. 워크플로에 따라 어떤 유형의 구성이 프로젝트에 적합한지 알기 어려울 수 있습니다.

브라우저 DevTools 환경에서 온 경우 "도구에서 시작"이라는 개념에 익숙하지 않을 수 있습니다. 브라우저 인스턴스가 이미 열려 있기 때문입니다. DevTools를 열 때 단순히 열려 있는 브라우저 탭에 DevTools를 **연결**하는 것입니다. 반대로 Java 환경에서 온 경우 편집기가 Java 프로세스를 **시작**하도록 하는 것은 매우 일반적이며, 편집기가 새롭게 시작된 프로세스에 자동으로 디버거를 연결합니다.

**Launch**와 **Attach**의 차이를 설명하는 가장 좋은 방법은 Launch 구성을 VS Code가 연결되기 **전**에 디버그 모드로 앱을 시작하는 방법에 대한 레시피로 생각하는 것이고, Attach 구성은 **이미** 실행 중인 앱이나 프로세스에 VS Code의 디버거를 연결하는 방법에 대한 레시피입니다.

Launch 구성의 가치는 반복 가능하고 프로젝트 및 팀과 공유 가능한 구성을 생성하여 앱을 올바른 디버깅 매개변수로 시작하는 데 드는 인지적 오버헤드를 일부 해제할 수 있는 방법을 제공한다는 것입니다.

그러나 개발자들이 애플리케이션을 시작하는 방법에 대해 이야기했을 때, 우리는 패턴을 보았고 한 가지 중요한 관찰을 했습니다.

**관찰**: VS Code를 사용하는 많은 개발자는 통합 터미널을 매우 좋아하며 애플리케이션을 시작하기 위해 명령줄 도구에 의존합니다. 많은 사람들에게 터미널에서 명령을 실행한 다음 편집기에서 디버거를 연결하는 것이 더 자연스러운 워크플로입니다. 이는 브라우저가 시작된 후 DevTools를 여는 것과 유사합니다.

이 관찰은 핵심이었으며, 많은 사용자가 편집기에서 완전한 "마법 같은" 시작 경험을 원하지 않는다는 것을 깨달았습니다. 그들은 편집기를 소스 코드를 편집하고 디버깅하는 장소로 유지하고 터미널을 사용하여 앱을 시작하고 빌드 스크립트를 실행하는 등의 작업을 수행하기를 원합니다. 이것이 VS Code 내에 통합 터미널 환경이 있는 이유 중 하나입니다. 좋은 기능적 UI는 터미널과 잘 공존하고 통합되어야 한다고 믿기 때문입니다.

많은 개발자가 상태 변경을 검사하기 때문에 중단점을 사용하지 않습니다.

개발자들이 애플리케이션을 디버깅하는 방식을 살펴보면서 또 다른 흥미로운 패턴을 발견했습니다. 바로 중단점 대신 로깅을 사용하는 것입니다.

디버깅을 위한 로깅은 새로운 개념이 아니지만, 관찰은 중요했습니다.

**관찰**: 전통적인 디버깅 워크플로는 프로그램 논리를 검사하기 위해 실행 속도를 늦추는 데 중점을 두는 반면, 로깅 워크플로는 일반적으로 프로그램 상태와 애플리케이션의 정상적인 실행 중에 어떻게 변경되는지를 검사하는 것을 포함합니다. 여기서 기본적인 관찰은 두 가지 기법이 다른 디버깅 목적으로 사용된다는 것입니다.

이 관찰은 특히 JavaScript 개발자에게 관련이 있습니다. 이들은 상태 관리의 복잡성을 주로 다루며, 이것이 대부분의 JavaScript 개발자가 여전히 소스 코드에 console.log를 추가하는 것을 스크립트 디버거를 사용하는 것보다 선호하는 이유를 설명할 수 있습니다.

Node 프로세스에 자동 연결

일부 개발자가 통합 터미널을 사용하여 디버깅 세션을 시작하는 방법을 되돌아보면서 고유한 기회가 나타났습니다. VS Code 내에서 편집기와 통합 터미널의 컨텍스트 정보를 활용함으로써 컨텍스트를 감지하고 디버깅 의도를 추론할 수 있으며, 이는 Node.js 개발자에게 훨씬 더 간단한 디버깅 환경을 제공할 수 있습니다.

따라서 VS Code의 3월 반복에서는 **Node용 자동 연결**이라는 새로운 기능을 출시했습니다. 이 기능은 VS Code의 통합 터미널에서 디버그 모드로 시작된 Node.js 프로세스에 Node 디버거가 자동으로 연결되도록 합니다.

명령 팔레트에서 **디버그: 자동 연결 전환** 명령을 실행하여 자동 연결을 활성화할 수 있으며, 활성화되면 상태 표시줄에서도 자동 연결을 전환할 수 있습니다.

Auto attach

이 기능은 디버그 구성을 완전히 제거합니다. node --inspect로 시작된 모든 Node.js 프로세스를 디버깅하려는 의도로 해석하기 때문입니다. 통합 터미널과 결합하면 훨씬 간단한 디버깅 환경이 제공되어 개발자가 자신만의 방식으로 앱을 시작할 수 있으며 동시에 디버그 구성을 제거할 수 있습니다! 🎉

NPM 스크립트 및 디버깅

많은 Node.js 개발자는 애플리케이션을 시작하거나 디버깅 세션을 시작하기 위해 npm 스크립트에 의존하며, 이에 대해 좋은 소식이 있습니다. 자동 연결은 npm 스크립트와도 작동합니다. npm run debug를 실행하고 "debug" 스크립트가 "node --inspect" 또는 --inspect를 포함하는 다른 명령인 경우, 자동 연결이 이를 감지하고 디버거를 연결합니다 🎉

또한 일부 개발자는 npm 스크립트를 찾고 실행할 수 있는 더 시각적인 방법을 원한다는 것을 인식했습니다. 따라서 2018년 4월 반복에서는 UI에서 직접 npm 스크립트를 탐색하고 실행할 수 있는 새로운 NPM 스크립트 탐색기를 추가했습니다. 디버그 구성을 단순화하기 위한 작업의 일환으로, 디버그 구성을 생성할 필요 없이 탐색기에서 직접 Node.js 디버깅을 시작할 수 있도록 했습니다.

--inspect와 같은 디버깅 인수를 포함하는 npm 스크립트가 있는 경우, 이를 자동으로 감지하고 여기에 표시된 것처럼 디버거를 시작하는 디버그 작업을 제공합니다.

NPM scripts

Logpoints 소개

로깅이 중요한 디버깅 기술이라는 학습을 바탕으로 기존 디버깅 환경에 상태 검사를 추가할 기회를 보았습니다. VS Code의 3월 반복에서 Logpoints라고 부르는 디버깅 기능의 첫 번째 구현을 출시했습니다.

Logpoint는 디버거를 "중단"하지 않고 대신 콘솔에 메시지를 기록하는 중단점 변형입니다.

Logpoints

Logpoints의 개념은 새로운 것이 아니며, 지난 몇 년 동안 Visual Studio, Edge DevTools 및 GDB와 같은 도구에서 Tracepoints 및 Logpoints와 같은 여러 이름으로 이 개념의 다양한 변형을 보았습니다.

Logpoints를 사용해야 하는 이유 및 시점?

Logpoints는 많은 경우 애플리케이션의 특정 부분에서 실행을 중지하고 싶지 않지만, 대신 애플리케이션 수명 주기 동안 상태가 어떻게 변하는지 검사하고 싶다는 관찰을 기반으로 합니다.

Logpoints를 사용하면 애플리케이션을 시작하기 전에 애플리케이션 로직에 로깅 문을 추가한 것처럼 주문형 로깅 문을 "주입"할 수 있습니다. Logpoints는 소스 코드에 영구적으로 저장되지 않고 실행 시간에 주입되므로 미리 계획할 필요 없이 필요에 따라 Logpoints를 주입할 수 있습니다. 또 다른 장점은 디버깅이 끝나면 소스 코드를 정리하는 것에 대해 걱정할 필요가 없다는 것입니다.

JavaScript 개발자에게는 더 이상 console.log를 남길 걱정을 할 필요가 없다는 것을 의미합니다. Logpoints를 사용하세요! 더 나은 점은 console.log와 Logpoints를 결합할 수 있다는 것입니다. console.log가 이미 있는 소스 코드 블록에 Logpoint를 삽입하면 디버그 콘솔에서 두 가지 유형의 로깅 문을 모두 볼 수 있습니다.

클라우드 컨텍스트의 Logpoints

Logpoints는 클라우드 컨텍스트(또는 실제로 모든 원격 컨텍스트)에서 특히 유용합니다. 애플리케이션을 다시 배포할 필요 없이 원격 환경에 로깅을 주입할 수 있기 때문입니다. 마찬가지로 중요한 것은 Logpoints를 사용해도 스크립트 실행이 중단되지 않으므로 일반 중단점에서 실행 중인 애플리케이션을 중단할 때와 달리 사용자가 영향을 받지 않는다는 것입니다.

Azure에서 Node.js용 Logpoints 사용 방법에 대해 자세히 알아볼 수 있습니다.

지원되는 언어

VS Code에서 Logpoints가 처음 출시된 이후 VS Code Debug Adapter에서 채택이 증가했으며, 오늘날 다음과 같은 언어에 대한 Logpoint 지원이 있습니다.

VS Code의 Logpoints

VS Code의 Debug Adapter에 Logpoint 지원을 추가하는 데 관심이 있다면 프로토콜의 이 변경 사항를 살펴보세요. 또한 위의 디버그 어댑터를 보면 각 런타임에서 Logpoints를 구현하는 방법을 선택한 것을 볼 수 있습니다.

다음 단계

현재까지는 이렇지만, 아직 끝나지 않았습니다. 7월 반복에서는 사용자 피드백을 바탕으로 검색 용이성을 돕기 위해 자동 연결을 개선하고 있습니다(#53640).

자동 연결, NPM 스크립트 탐색기 및 Logpoints의 도입이 VS Code 디버깅을 더 쉽게 만들어주기를 바랍니다. 항상 여러분의 피드백을 듣고 싶으니 GitHub 또는 Twitter의 @code로 문의해주세요.

VS Code 팀을 대표하여: 즐거운 코딩 되세요!

/Kenneth Auchenberg - Twitter의 @auchenberg