2019년 4분기부터 Chrome DevTools 팀은 쿠키와 관련된 DevTools의 개발자 환경을 개선하기 시작했습니다. 이는 Chrome과 기타 브라우저에서 기본 쿠키 동작을 변경하기 시작했기 때문에 특히 중요했습니다.
DevTools가 이미 제공하는 도구를 연구하는 동안 우리는 종종 다음과 같은 상황에 처했습니다.
📊 콘솔에는 경고와 오류 메시지가 가득했고, 다소 기술적인 설명이 포함되어 있었고 때로는 chromestatus.com 링크도 있었죠. 모든 메시지가 거의 똑같이 중요해 보였기 때문에 어떤 메시지를 먼저 처리해야 하는지 파악하기가 어려웠습니다. 무엇보다도, 텍스트가 DevTools의 추가 정보로 연결되지 않아 무슨 일이 발생했는지 이해하기가 어려웠습니다. 마지막으로, 웹 개발자가 문제를 해결하는 방법을 알아내거나 기술적 맥락을 파악하도록 하는 과정에서 메시지가 온전히 묻히는 경우가 많았습니다.
또한 자체 애플리케이션의 메시지도 콘솔을 사용하는 경우 브라우저의 모든 메시지 간에 메시지를 찾기가 어려울 수 있습니다.
사람뿐만 아니라 자동화된 프로세스가 콘솔 메시지와 상호작용하는 것도 어렵습니다. 예를 들어 개발자는 지속적 통합/지속적 배포 시나리오에서 Chrome Headless 및 Puppeteer를 사용할 수 있습니다. 콘솔 메시지는 문자열에 불과하므로 개발자는 정규 표현식이나 다른 파서를 작성하여 실행 가능한 정보를 추출해야 합니다.
해결 방법: 체계적이고 실행 가능한 문제 보고
발견한 문제에 대한 더 나은 해결책을 찾기 위해 먼저 요구사항에 대해 생각하고 이러한 요구사항을 디자인 문서에 수집했습니다.
Google의 목표는 문제를 명확하게 설명하고 해결하는 방법을 제시하는 것입니다. 설계 과정에서 각 문제에는 다음 네 부분이 포함되어야 함을 깨달았습니다.
- 제목
- 설명
- DevTools 내에서 영향을 받는 리소스 링크
- 추가 안내 링크
제목의 경우 개발자가 핵심 문제를 이해할 수 있도록 짧고 정밀하게 표현해야 하며, 종종 문제 해결에 관한 힌트를 주는 경우가 많습니다. 예를 들어 이제 쿠키 문제는 다음과 같습니다.
크로스 사이트 쿠키를 '보안'으로 표시하여 크로스 사이트 컨텍스트에서 설정할 수 있습니다.
모든 문제의 설명에 발생한 문제를 설명하고, 문제 해결 방법에 대한 실행 가능한 조언을 제공하는 자세한 정보가 포함되어 있으며, 맥락 안에서 문제를 이해할 수 있도록 DevTools 내의 다른 패널로 연결되는 링크가 포함되어 있습니다. 웹 개발자가 이 주제에 관해 더 자세히 알아볼 수 있도록 web.dev의 심층 기사 링크도 제공됩니다.
각 문제의 중요한 부분은 영향을 받는 리소스 섹션입니다. 이 섹션은 DevTools의 다른 부분으로 연결되어 쉽게 더 자세히 조사할 수 있도록 도와줍니다. 쿠키 문제 예시의 경우 문제를 트리거한 네트워크 요청 목록이 있어야 하며 요청을 클릭하면 네트워크 패널로 바로 이동합니다. 이 방법이 편리할 뿐만 아니라 특정 종류의 문제를 디버그하는 데 DevTools 내부의 어떤 패널과 도구를 사용할 수 있는지도 강화해주길 바랍니다.
문제 탭과의 개발자 상호작용을 장기적으로 생각해보면 개발자 상호작용이 다음과 같이 발전할 것으로 예상됩니다.
- 특정 문제가 처음으로 발생하면 웹 개발자는 문제를 자세히 이해하기 위해 도움말을 읽습니다.
- Google에서는 두 번째로 문제가 발생하는 경우 문제 설명을 통해 개발자에게 문제의 내용을 상기시키고 개발자가 즉시 문제를 조사하고 해결하기 위한 조치를 취할 수 있기를 바랍니다.
- 몇 차례 문제가 발생한 후에는 개발자가 문제 유형을 인식하기에 문제 제목으로 충분하기를 바랍니다.
개선해야 할 또 다른 중요한 측면은 집계입니다. 예를 들어 동일한 쿠키가 동일한 문제를 여러 번 일으킨 경우 이 쿠키를 한 번만 보고하려고 합니다. 이렇게 하면 메일 수를 상당히 줄일 수 있을 뿐만 아니라 문제의 근본 원인을 더 빠르게 식별할 수 있습니다.
구현
이러한 요구사항을 염두에 두고 팀은 새로운 기능을 구현하는 방법을 찾기 시작했습니다. Chrome DevTools용 프로젝트는 일반적으로 세 가지 영역으로 나뉩니다.
- Chrome에서 C++로 작성된 오픈소스 프로젝트인 Chromium
- DevTools 프런트엔드: Chrome DevTools의 JavaScript 구현
- 이 두 프로토콜을 연결하는 레이어인 Chrome DevTools 프로토콜 (CDP)
그런 다음 구현은 다음 세 가지 작업으로 구성되었습니다.
- Chromium 내부에서는 원하는 정보가 포함된 구성요소를 식별하고 속도나 보안을 저해하지 않으면서 DevTools 프로토콜에서 해당 정보에 액세스할 수 있도록 해야 했습니다.
- 그런 다음 DevTools 프런트엔드와 같은 클라이언트에 정보를 노출하는 API를 정의하는 Chrome DevTools 프로토콜 (CDP)을 설계해야 했습니다.
- 마지막으로, 개발자가 정보를 쉽게 해석하고 상호작용할 수 있도록 CDP를 통해 브라우저의 정보를 요청하고 적절한 UI에 표시하는 구성요소를 DevTools 프런트엔드에 구현해야 했습니다.
브라우저 측에서는 콘솔 메시지가 처리되는 방식을 먼저 살펴보았습니다. 콘솔 메시지가 문제를 해결하기 위해 생각했던 동작과 매우 유사하기 때문입니다. CodeSearch는 일반적으로 이와 같은 탐색 분석을 위한 좋은 시작점입니다. 이를 통해 온라인으로 Chromium 프로젝트의 전체 소스 코드를 검색하고 탐색할 수 있습니다. 이를 통해 콘솔 메시지의 구현에 대해 학습했으며, 문제 해결을 위해 수집한 요구사항을 중심으로 동시에 생성되었지만 더 구조화된 방식을 구축할 수 있었습니다.
이 작업은 특히 까다롭습니다. 왜냐하면 우리가 항상 염두에 두어야 하는 모든 보안 관련 사항들 때문입니다. Chromium 프로젝트는 사물을 여러 프로세스로 분리하고 제어된 통신 채널을 통해서만 통신하여 정보 유출을 방지하도록 하는 데 많은 도움이 됩니다. 문제에는 민감한 정보가 포함될 수 있으므로 이러한 정보를 알 수 없는 브라우저 부분으로 보내지 않도록 주의해야 합니다.
DevTools 프런트엔드
DevTools 자체는 JavaScript 및 CSS로 작성된 웹 애플리케이션입니다. 10년 이상 사용되었다는 점을 제외하면 다른 웹 애플리케이션과 매우 유사합니다. 물론 백엔드는 기본적으로 브라우저에 대한 직접 통신 채널, 즉 Chrome DevTools 프로토콜입니다.
문제 탭에서는 먼저 사용자 사례와 개발자가 문제를 해결하기 위해 무엇을 해야 하는지 생각했습니다. YouTube의 아이디어는 더 자세한 정보를 보여주는 패널과 사람들을 연결하는 조사를 위한 중심적인 출발점으로 문제 탭을 사용하는 것과 관련하여 발전했습니다. 우리는 개발자가 Network 또는 Application 패널과 같은 다른 DevTools 구성 요소와 상호작용하는 동안에도 문제 탭을 열린 상태로 유지할 수 있도록 DevTools 하단에 다른 탭과 함께 두기로 결정했습니다.
UX 디자이너는 이 점을 염두에 두고 우리가 목표로 하는 것이 무엇인지 이해하고 다음과 같은 초기 제안의 프로토타입을 제작했습니다.
최적의 솔루션에 대해 많은 논의 끝에 Google은 설계를 구현하고 결정을 반복하면서 점차 문제 탭이 오늘날의 모습에 도달하게 되었습니다.
또 다른 중요한 요소는 문제 탭의 검색 가능성이었습니다. 과거에는 개발자가 무엇을 찾아야 하는지 정확히 모르면 훌륭한 Devtools 기능을 찾을 수 없었습니다. Issues 탭에서는 개발자가 중요한 문제를 놓치지 않도록 다양한 영역의 문제를 강조표시하기로 했습니다.
Google은 문제를 해결하기 위해 특정 콘솔 메시지가 삭제되었으므로 콘솔 패널에 알림을 추가하기로 했습니다. DevTools 창의 오른쪽 상단에 있는 경고 및 오류 카운터에도 아이콘을 추가했습니다.
마지막으로, Issues 탭은 다른 DevTools 패널로 연결될 뿐만 아니라 문제와 관련된 리소스도 Issues 탭으로 다시 연결됩니다.
프로토콜
프런트엔드와 백엔드 간의 통신은 Chromium DevTools 프로토콜 (CDP)이라는 프로토콜을 통해 이루어집니다. CDP는 Chrome DevTools인 웹 앱의 백엔드라고 생각할 수 있습니다. CDP는 여러 도메인으로 세분화되며, 모든 도메인에는 다수의 명령과 이벤트가 포함됩니다.
문제 탭에서는 새로운 문제가 발생할 때마다 트리거되는 새로운 이벤트를 감사 도메인에 추가하기로 했습니다. DevTools가 아직 열려 있지 않은 동안 발생하는 문제도 보고할 수 있도록 Audits 도메인은 가장 최근의 문제를 저장하고 DevTools가 연결되는 즉시 이를 전달합니다. 그러면 DevTools가 이러한 모든 문제를 수집하여 종합합니다.
또한 CDP를 사용하면 Puppeteer와 같은 다른 프로토콜 클라이언트에서 문제를 수신하고 처리할 수 있습니다. CDP를 통해 전송된 구조화된 문제 정보가 기존의 지속적 통합 인프라에 통합하고 단순화하는 데 도움이 되기를 바랍니다. 이렇게 하면 페이지가 배포되기 전에도 문제를 감지하고 해결할 수 있습니다.
향후 일정
먼저 콘솔에서 문제 탭으로 훨씬 더 많은 메시지를 이동해야 합니다. 특히 새로 추가되는 모든 문제에 대해 명확하고 실행 가능한 문서를 제공하고자 하므로 다소 시간이 걸릴 수 있습니다. 향후 개발자가 콘솔이 아닌 문제 탭에서 문제를 찾아보시기 바랍니다.
또한 Google에서는 Chromium 백엔드 이외의 다른 소스에서 받은 문제를 '문제' 탭에 통합하는 방법을 검토하고 있습니다.
Google은 문제 탭을 깔끔하게 유지하고 사용성을 개선하기 위해 노력하고 있습니다. 올해는 검색, 필터링, 개선된 집계 기능이 포함되어 있습니다. Google에서는 신고된 문제 수를 파악하기 위해 지원 중단이 예정된 문제만 표시하는 등의 문제 카테고리를 도입하고 있습니다. 또한 개발자가 문제를 일시적으로 숨기는 데 사용할 수 있는 다시 알림 기능을 추가하는 방안을 고려하고 있습니다.
문제를 조치를 취할 수 있도록 하기 위해 Google에서는 페이지의 어느 부분에서 문제를 일으켰는지 보다 쉽게 파악할 수 있도록 만들고자 합니다. 특히 Google에서는 게시자가 삽입한 리소스로 인해 발생하지만 직접적으로 제어할 수는 없는 문제 (예: 광고 네트워크)와 실제 페이지 (예: 퍼스트 파티) 문제를 구별하고 필터링하는 방법을 모색하고 있습니다. 첫 번째 단계로 Chrome 86에서 서드 파티 쿠키 문제를 숨길 수 있습니다.
문제 탭을 개선하기 위한 제안사항이 있으면 버그를 신고하여 알려주시기 바랍니다.
미리보기 채널 다운로드
Chrome Canary, 개발자 또는 베타를 기본 개발 브라우저로 사용하는 것이 좋습니다. 이러한 Preview 채널을 통해 개발자는 최신 DevTools 기능에 액세스하고 최첨단 웹 플랫폼 API를 테스트하며 다른 사용자보다 먼저 사이트에서 문제를 찾을 수 있습니다.
Chrome DevTools팀에 문의하기
게시물에서 새로운 기능과 변경사항 또는 DevTools와 관련된 다른 항목에 대해 논의하려면 다음 옵션을 사용하세요.
- crbug.com을 통해 제안 또는 의견을 제출하세요.
- DevTools에서 옵션 더보기
> 도움말 > DevTools 문제 신고를 사용하여 DevTools 문제를 신고합니다. - @ChromeDevTools로 트윗을 보냅니다.
- DevTools의 새로운 기능 YouTube 동영상 또는 DevTools 팁 YouTube 동영상에 댓글을 남겨주세요.