Dart 튜토리얼 33편: 디버깅 & DevTools(Dart DevTools·웹 디버깅)
요약
핵심 요지
- 문제 정의: 디버깅 도구를 늦게 붙이면, 원인을 찾는 시간이 늘어나고 같은 문제를 반복한다.
- 핵심 주장: Dart DevTools는 디버깅/로그/진단 도구 모음이며, CLI는
dart run --observe1, 웹은webdev serve --debug2 같은 실행 옵션으로 DevTools 연결을 활성화하는 흐름이 제시된다. - 주요 근거: CLI 실행 시 VM service URL과 DevTools URL이 출력되는 예시, 웹에서는
Alt+D(macOS는Option+D)로 DevTools를 여는 안내, Chrome DevTools와 source maps 사용 안내가 제시된다. - 실무 기준: 로직 디버깅은 DevTools(브레이크포인트/변수/로그), 웹 UI/성능은 브라우저 DevTools로 분리한다.
문서가 설명하는 범위
- DevTools가 어떤 앱 타입에서 어떤 도구를 제공하는지의 개요
- CLI 앱에서
--observe로 DevTools를 연결해 디버깅하는 방법 - 웹 앱에서
webdev serve --debug/--debug-extension로 DevTools/Chrome DevTools를 사용하는 방법
읽는 시간: 13분 | 난이도: 초급
참고 자료
문제 상황
문제가 생겼을 때 “출력문을 더 찍어볼까?”로 시작하면, 어느 순간부터는 출력이 너무 많아져서 오히려 원인이 안 보입니다.
특히 비동기 코드나 이벤트 기반 코드는, 브레이크포인트로 멈춰서 현재 상태를 보는 편이 훨씬 빠를 때가 많습니다.
그래서 DevTools 연결까지 포함한 실행 습관을 먼저 만들어두는 것이 좋습니다.
해결 방법
단계 1: CLI는 dart run --observe로 “VM 서비스 + DevTools URL”을 얻는다
Why
NOTECLI 앱은 UI가 없어서, 디버깅 연결을 실행 옵션으로 활성화해야 합니다.
연결이 되면 브레이크포인트/변수 확인/로그 확인을 같은 화면에서 할 수 있습니다.
What
NOTE
dart run --observe로 실행하면 VM 서비스가 열리고, DevTools에 접속할 URL이 출력되는 흐름이 제시됩니다.
또한--pause-isolates-on-start3로 시작 시점에 자동으로 멈출 수 있습니다.
How
TIP실행 예시는 다음과 같이 제시됩니다.
Terminal window $ cd path/to/dart/app$ dart run --pause-isolates-on-start --observe main.dartThe Dart VM service is listening on http://127.0.0.1:8181/afZySiNbDPg=/The Dart DevTools debugger and profiler is available at: http://127.0.0.1:8181/afZySiNbDPg=/devtools/#/?uri=ws%3A%2F%2F127.0.0.1%3A8181%2FafZySiNbDPg%3D%2Fws출력된 “DevTools debugger and profiler” URL을 브라우저 주소창에 붙여 넣고, Debugger 탭에서 디버깅을 시작합니다.
Watch out
WARNING이 URL에는 보안 토큰이 포함되고 실행할 때마다 달라질 수 있다는 안내가 있습니다.
즉, 앱을 재실행하면 DevTools도 새 URL로 다시 연결해야 합니다.
결론: CLI 디버깅은 --observe로 시작하고, 출력된 DevTools URL로 연결하는 습관이 핵심입니다.
단계 2: 웹은 webdev serve --debug로 DevTools를 연결하고, 단축키로 연다
Why
NOTE웹 앱은 브라우저에서 실행되므로, 개발 서버/소스맵/확장 프로그램 등 도구가 함께 필요합니다.
그중 DevTools 연결은webdev플래그로 활성화하는 흐름이 제시됩니다.
What
NOTE웹 앱 디버깅은
webdev serve로 개발 컴파일러를 실행하고,--debug또는--debug-extension옵션으로 DevTools 연결을 활성화하는 방식이 제시됩니다.
How
TIP커맨드라인 예시:
Terminal window $ webdev serve --debug그리고
--debug로 실행한 경우, 브라우저에서 Alt+D(macOS는 Option+D)로 DevTools를 여는 안내가 있습니다.
--debug-extension은 이미 실행 중인 Chrome 인스턴스에서 디버깅할 때 사용되는 흐름으로 제시됩니다.
Watch out
WARNING웹 앱에서 UI/성능(HTML/CSS/렌더링)은 브라우저 도구(Chrome DevTools)를 쓰는 것이 적합하다는 기준이 제시됩니다.
또한 Dart 소스를 보려면 source maps를 사용하는 흐름이 제시됩니다.
결론: 웹은 webdev serve --debug로 디버깅 환경을 만들고, 로직은 DevTools, UI/성능은 브라우저 DevTools로 분리합니다.
단계 3: “어떤 DevTools를 쓸 수 있는지”를 앱 타입별로 구분한다
Why
NOTEDevTools에는 디버거뿐 아니라 메모리/성능/네트워크 같은 도구가 있지만, 앱 타입에 따라 지원 범위가 다릅니다.
이걸 모르고 찾으면 “왜 메뉴가 없지?”에서 헤맵니다.
What
NOTE디버거와 로그 뷰는 모든 앱 타입에서 사용 가능하다는 요약이 제시됩니다.
반면 웹 앱은 타임라인/메모리/성능 뷰를 사용할 수 없고, 대신 브라우저 도구를 사용하라는 기준이 제시됩니다.
How
TIP문제가 “로직/상태”라면 DevTools Debugger/Logging을 먼저 열고, 문제가 “UI/레이아웃/성능”이라면 Chrome DevTools의 요소/성능 패널을 먼저 엽니다.
이 기준을 팀의 디버깅 루틴으로 고정하면, 문제 재현과 공유가 빨라집니다.
Watch out
WARNING웹 디버깅은 Chrome 확장 프로그램(예: Dart Debug Extension)이나
webdev실행 방식에 영향을 받을 수 있습니다.
따라서 연결이 안 되면 “실행 플래그/확장 설치/브라우저”부터 확인하는 것이 우선입니다.
결론: DevTools는 “앱 타입별 지원 범위”를 전제로 사용해야 하고, 웹에서는 브라우저 도구와 역할을 분리해야 합니다.
Footnotes
공유
이 글이 도움이 되었다면 다른 사람과 공유해주세요!