게시일: 2025년 1월 14일
작년 Google I/O 2024에서는 Chrome DevTools의 첫 번째 AI 기능인 콘솔 통계를 출시했습니다. 콘솔 통계는 로그 메시지와 관련된 네트워크 데이터, 소스 코드, 스택 트레이스를 Google의 대규모 언어 모델 (LLM)인 Gemini로 전송하여 콘솔에 로깅된 오류와 경고를 이해하는 데 도움이 됩니다. Console 통계는 Gemini에 단일 프롬프트를 전송하며, 이 프롬프트는 개발자가 후속 질문을 할 수 없는 단일 응답을 반환합니다. 이 단일 상호작용 흐름은 오류 메시지를 설명하는 데는 비교적 효과적이지만, 검사된 페이지에서 AI가 어떤 데이터를 필요로 하는지 명확하지 않은 DevTools 내의 더 복잡한 디버깅 사용 사례에는 확장되지 않습니다.
스타일 지정 문제 디버깅이 이러한 사용 사례 중 하나입니다. 단일 웹페이지에는 수천 개의 요소와 CSS 규칙이 포함될 수 있으며, 이 중 일부만 특정 시나리오 디버깅과 관련이 있습니다. 디버그할 올바른 코드를 식별하는 것은 인간에게도 쉽지 않을 수 있습니다. 하지만 Google의 AI 해커톤에서 빌드한 프로토타입을 통해 LLM이 실제로 상당히 우수하다는 사실을 알게 되었습니다. 따라서 페이지에서 추가 컨텍스트 데이터를 대화형으로 쿼리하여 스타일 지정 문제를 조사할 수 있는 도구를 만들어 DevTools 사용자에게 이 기능을 제공하고자 했습니다. 몇 개월 후 스타일 지정을 위한 AI 지원으로 출시되었습니다.
이 게시물에서는 웹 앱인 Chrome DevTools와 같이 많은 사랑을 받는 제품에 AI를 도입하는 과정에서 직면한 문제와 자체 AI 기능에 적용할 수 있는 사항을 살펴봅니다.
올바른 데이터 수집
Console 통계는 항상 동일한 데이터 포인트를 사용하여 사전 정의된 프롬프트에 응답합니다. AI 지원이 사용자 정의 프롬프트에 유용하려면 현재 쿼리에 중요한 컨텍스트 데이터를 동적으로 결정해야 합니다.
따라서 ReAct (Yao et al., 2022) 전략을 이 프롬프트 전략을 사용하면 LLM이 자율적으로 추론하고 추론에 따라 후속 작업을 결정할 수 있습니다.
이렇게 하면 AI 지원이 사용자의 쿼리에 적합한 응답을 결정할 때까지 사고, 행동, 관찰의 주기를 반복하다가 주기를 종료하고 답변을 제공합니다. 이 반복 프로세스를 통해 LLM은 스타일 지정 문제를 효과적으로 디버그하는 데 필요한 정확한 정보를 수집할 수 있습니다.
정보를 수집하기 위해 Gemini에는 검사된 페이지에서 JavaScript를 실행하는 하나의 도구만 제공되었습니다. 이를 통해 Gemini는 AI 지원을 통해 다음과 같은 작업을 할 수 있습니다.
- DOM에 액세스하고 분석: DOM 트리를 탐색하고, 요소 속성을 검사하고, 요소 간의 관계를 이해합니다.
- 계산된 스타일 검색: 모든 요소의 계산된 스타일에 액세스합니다.
- 계산 및 측정 수행: JavaScript 코드를 실행하여 요소의 거리, 크기, 위치를 계산합니다.
이렇게 하면 AI 지원이 관련성 있는 코드에만 대화식으로 작동하므로 전체 HTML 및 CSS 소스 코드를 Gemini로 전송하는 것보다 응답 품질, 응답 시간, 컴퓨팅 리소스 사용이 개선됩니다.
사용자 공간에서 AI 생성 코드 실행
스타일 지정 문제를 디버그하는 데 JavaScript를 사용했다는 것이 예상치 못한 것처럼 보일 수 있습니다. 여기에는 두 가지 이유가 있습니다.
- 웹 API는 매우 강력하며 본질적으로 많은 디버깅 사용 사례를 다룹니다. 개발자가 API 호출을 수동으로 사용하여 DOM을 탐색하거나 디버깅을 위해 계산된 스타일에 액세스하는 것은 번거로울 수 있지만 LLM이 이를 호출하는 코드를 생성하는 것은 문제가 아닙니다.
- 상담사가 사용할 새 API를 만들 수도 있지만, 기존의 공개 API를 재사용하는 것이 더 나은 선택인 경우가 많습니다. 이러한 API는 이미 LLM에 알려져 있기 때문입니다. 새 API에 관해 LLM을 교육하려면 미세 조정 및 특정 학습 데이터에 관한 많은 리소스가 필요합니다.
하지만 사용자 공간에서 AI 생성 코드를 실행하면 위험이 있습니다. AI 지원을 위해 상담사가 페이지를 파괴적으로 변경할 위험을 최소화해야 했습니다. 이를 위해 Chrome DevTools 프로토콜을 통해 Chrome의 JavaScript 엔진인 V8이 노출하는 부작용 검사를 사용했습니다. DevTools Console의 자동 완성 기능에도 동일한 검사가 사용됩니다. 페이지 상태를 수정하지 않는 한 JavaScript 코드만 실행됩니다. 이 검사는 V8이 코드를 실행하는 동안 실행되며 부작용이 없는 것으로 알려진 JavaScript 내장 함수의 허용 목록을 기반으로 합니다.
검사에서 생성된 코드가 검사된 페이지를 수정하는 것으로 감지되면 실행이 일시중지되고 사용자에게 코드를 검토하고 실행해도 괜찮은지 확인해 달라는 메시지가 표시됩니다.
또한 생성된 JavaScript는 소위 격리된 '세계'에서 실행됩니다. 이는 확장 프로그램이 샌드박스 스크립트를 실행하는 방식과 유사합니다. 생성된 코드는 DOM 및 Web API에 액세스할 수 있지만 검사된 페이지에서 정의된 JavaScript 코드나 상태에는 액세스할 수 없습니다.
상담사가 수행한 변경사항 추적
문제 조사 및 페이지 관련 디버깅 질문에 답변하는 것 외에도 AI 지원 상담사에게 개발자가 추적할 수 있는 방식으로 페이지의 스타일을 수정할 수 있는 기능을 제공하고자 했습니다.
이를 위해 기본 웹 API 외에도 에이전트의 실행 컨텍스트에 노출되는 setElementStyles라는 바인딩을 구현했습니다.
Gemini가 이 새 메서드를 인식하도록 하려면 AI 지원 시작 부분에서 이를 사용하라고 지시합니다.
If you need to set styles on an HTML element, always call the \`async setElementStyles(el: Element, styles: object)\` function.
이 API는 상담사를 위해 특별히 설계되었으며 앞서 언급한 문제점이 있지만 미세 조정 없이도 Gemini는 특정 요소의 스타일을 변경해야 할 때 이 API를 매우 안정적으로 사용합니다.
DevTools 측에서 setElementStyles가 상담사로부터 호출되면 AI 지원은 검사기 스타일시트를 사용하여 요소 선택기의 변경사항을 기록합니다. CSS 중첩은 변경사항의 이름을 지정하고 요소의 선택자 특이성을 높이는 데 사용됩니다. 따라서 에이전트가 생성한 CSS 규칙의 예는 다음과 같습니다.
.ai-style-change-1 { /* the ID is incremented for each change*/
.element-selector { /* Element selector is computed based on the element setElementStyles was called on. */
color: blue;
}
}
이렇게 해도 페이지에서 발생할 수 있는 모든 스타일 충돌이 해결되는 것은 아니지만 대부분의 경우에는 효과가 있습니다.
인라인 스타일에 비해 검사기 스타일시트를 사용하는 이점은 에이전트가 실행한 변경사항이 변경사항 패널에도 표시되므로 요소 스타일의 변경사항과 개발자가 기본 소스 코드로 전송해야 하는 항목을 더 쉽게 추적할 수 있다는 것입니다. 변경사항 패널과의 통합을 통해 더 이상 변경사항이 필요하지 않은 경우 변경사항을 롤백할 수도 있습니다.
사용자가 상담사의 작업을 관찰할 수 있도록 하기
제품에 상담사 기능을 추가할 때는 사용자가 상담사 작업을 추적하고 이해하며 개입할 수 있도록 상담사 작업을 사용자에게 투명하게 공개하는 것이 중요합니다.
따라서 AI 지원을 위해 Gemini에 서문과 함께 특정 형식으로 응답을 구성하도록 안내합니다.
You are going to answer to the query in these steps:
* THOUGHT
* TITLE
* ACTION
* ANSWER
* SUGGESTIONS
Use THOUGHT to explain why you take the ACTION. Use TITLE to provide a short summary of the thought.
그런 다음 이 구조는 Gemini의 사고 과정과 작업을 처음에는 접힌 단계로 표시하는 데 사용되어 정보 과부하를 방지하면서도 사용자가 기본 세부정보를 검토하거나 의도하지 않은 부작용이 발생할 경우 실행을 중지할 수 있도록 합니다.
이 접근 방식은 AI를 관찰하는 것만이 아니라 AI로부터 적극적으로 학습하는 것입니다. 사용자는 이러한 섹션을 펼쳐 Gemini가 특정 문제의 디버깅과 관련이 있다고 판단한 데이터를 분석하고 Gemini가 따르는 프로세스를 파악할 수 있습니다. 이러한 투명성을 통해 사용자는 AI의 디버깅 전략을 학습할 수 있으므로 AI 없이 작업하는 경우에도 향후 과제에 유사한 기법을 적용할 수 있습니다.
또한 AI 지원은 사용자 환경을 더욱 개선하기 위해 AI의 답변에 이어 문맥과 관련된 제안을 제공합니다. 이러한 추천은 대화를 간소화하여 다음 디버깅 단계에 대한 아이디어를 제공하거나 사용자가 클릭 한 번으로 권장 수정사항을 직접 실행할 수 있도록 허용합니다.
처음에는 AI 지원에서 단계 제목과 제안을 생성하기 위해 요약에만 사용할 수 있는 별도의 소형 모델을 사용하는 것이 좋겠다고 생각했습니다. 하지만 Gemini의 추론을 '생각'과 '작업'의 루프로 구성하는 ReAct 패턴을 효과적으로 확장할 수 있음을 깨달았습니다. 따라서 지연 시간이 추가로 발생하는 두 번째 모델을 도입하는 대신 프롬프트를 수정하여 Gemini가 핵심 '생각' 및 '작업'뿐만 아니라 동일한 ReAct 루프 내에서 간결한 제목과 유용한 제안을 생성하도록 안내했습니다.
평가 기반 개발
스타일링을 위한 AI 지원은 엄격한 평가 프로세스를 통해 개발되었습니다. 성능을 측정하고 개선이 필요한 영역을 파악하기 위해 일반적인 오버플로 문제, 웹 구성요소, 애니메이션 등을 다루는 실제 웹 디버깅 예시를 종합적으로 선별했습니다. 이를 통해 웹 디버깅 문제 공간의 폭을 매핑하고 관련 문제를 철저히 이해할 수 있었습니다. 하지만 이 작업은 끝나지 않습니다. 웹 플랫폼에 새로운 기능이 정기적으로 추가되므로 향후 이러한 예시를 최신 상태로 유지해야 합니다.
이러한 예시는 자동 평가 파이프라인에 제공되어 Gemini의 응답을 기록합니다. 그런 다음 이러한 자동화된 테스트 실행의 데이터는 맞춤 제작 도구에서 사용할 수 있게 되며, 이 도구에서는 사전 정의된 루브릭에 따라 Gemini의 AI 지원 성능을 수동으로 평가하여 후속 개발 작업에 정보를 제공합니다.
이러한 평가 중심 접근 방식을 통해 기존 동작을 미세 조정하거나 새로운 기능을 도입하는 등 모든 변경사항이 의도한 개선사항을 달성하고 기존 기능의 회귀를 방지하도록 신중하게 검증됩니다.
Google은 평가 절차를 더욱 개선하기 위해 다음과 같은 자동화된 인증 방법을 모색하고 있습니다.
- 수정사항이 올바르게 적용되었는지 확인하는 어설션
- Gemini에서 원치 않는 출력을 방지하기 위한 코드 기반 검사
- LLM을 특정 평가 기준에 따라 판단하는 판사로 활용하여 수동 평가를 반자동화하고 가속화
자동 인증은 확장에 도움이 되지만 사람의 의견도 중요합니다. Google에서는 AI 지원의 모든 대답 아래에 투표 컨트롤을 사용하여 사용자의 만족도를 파악하기 위한 사용자 의견을 수집하고 있습니다. 신고 버튼을 추가하면 사용자가 논쟁의 소지가 있는 대답에 대해 더 정확한 의견을 제공할 수 있습니다.
프롬프트 삽입
LLM의 잘 알려진 제한사항은 프롬프트 삽입이 발생하기 쉽다는 점입니다. 프롬프트 삽입은 LLM의 원래 시스템 안내를 덮어써 개발자가 의도하지 않은 콘텐츠를 출력하도록 하는 방법을 찾는 기법입니다.
현재 대부분의 모델에는 Gemini와 마찬가지로 프롬프트 삽입에 대한 완화 조치가 내장되어 있습니다. 또한 AI 지원의 경우 다음 안내를 포함하여 시작 문구에서 이를 완화하기 위해 노력하고 있습니다.
If the user asks a question about religion, race, politics, sexuality, gender, or other sensitive topics, answer with "Sorry, I can't answer that. I'm best at questions about debugging web pages.
이는 일부 명시적인 주제 외 질문에는 효과적이지만 완벽하지는 않습니다. 단점은 짧고 모호한 검색어는 주제와 관련 없는 것으로 분류될 수 있다는 점입니다.
견고한 기반 구축
제품에 AI를 처음 도입할 때는 한 번에 큰 폭으로 변화시키는 대신 단계적으로 진행하는 것이 좋습니다. AI 지원을 위해 접근한 방식도 마찬가지입니다. 스타일 지정 에이전트를 빌드할 때 배운 모든 것을 바탕으로 나중에 DevTools의 다른 영역으로 AI 지원을 확장할 수 있는 견고한 기반을 마련했습니다.
스타일 지정 에이전트 작업 시 발생하는 큰 문제의 대부분을 해결한 지 몇 개월 만에 네트워크, 실적, 소스에 AI 지원을 도입하고 각 문제에 집중할 수 있었습니다.
네트워크 요청을 사용할 때의 보안 관련 고려사항
네트워크를 위한 AI 지원을 사용하면 사용자가 요청의 데이터를 대화의 컨텍스트로 사용하여 Gemini와 특정 네트워크 요청에 관해 논의할 수 있습니다. 구체적으로 다음 데이터가 Gemini로 전송됩니다.
- 요청 헤더: 브라우저에서 서버로 전송하는 헤더의 하위 집합입니다.
- 응답 헤더: 서버에서 반환한 헤더의 하위 집합입니다.
- 응답 상태: 서버의 응답을 나타내는 HTTP 상태 코드입니다(예: 200, 404).
- 타이밍: 연결 설정 및 데이터 전송과 같은 요청의 다양한 단계를 다루는 자세한 타이밍 정보입니다.
- 요청 시작점 체인: 요청을 시작한 작업 및 스크립트의 순서입니다.
헤더는 요청이 어떻게 구성되는지 완전히 이해하는 데 중요하지만 보안 위험이 있습니다. API 키, 세션 토큰, 일반 비밀번호와 같은 사용자 인증 정보가 포함될 수 있기 때문입니다. 이러한 민감한 정보를 보호하기 위해 Google에서는 일부 헤더만 Gemini로 전송합니다. 대신 허용된 헤더의 허용 목록을 유지합니다. 허용 목록에 없는 헤더의 값은 <redacted>로 대체됩니다. 이 접근 방식을 사용하면 Gemini가 사용자 데이터를 보호하면서 필요한 컨텍스트를 수신할 수 있습니다.
다양한 데이터 형식에 맞게 조정
소스에 대한 AI 지원을 사용하면 개발자가 소스 패널에서 소스 파일에 관해 질문할 수 있습니다(예: '이 파일은 무엇인가요?').
파일 이름, 파일 콘텐츠, 소스 매핑 여부 등 파일에 관한 데이터가 모두 단일 프롬프트로 전송됩니다. 일반 텍스트이므로 효과적입니다. 하지만 대용량 텍스트 파일이나 바이너리 파일은 LLM에 어려움을 줍니다. 바이너리 파일의 경우 프롬프트에서 콘텐츠가 바이너리임을 표시하고 실제 콘텐츠를 전송하지 않기로 결정했습니다. 대용량 텍스트 파일의 경우 파일 시작 부분에서 가져온 콘텐츠의 일부만 전송합니다.
개발자가 녹화된 성능 프로필에서 특정 작업에 관해 질문할 수 있는 성능 관련 AI 지원의 경우에도 Gemini의 컨텍스트 창에 맞고 추가 통계를 제공하도록 해석할 수 있는 표현을 만드는 것과 유사한 문제가 있습니다.
성능 프로필에서 이러한 프레젠테이션을 만들기 위해 LLM이 처리할 수 있는 방식으로 작업의 호출 트리를 형식 지정하는 전용 직렬화 도구인 AiCallTree를 만들었습니다. 앞으로는 Gemini에 미리 전송해야 하는 데이터의 양을 최소화하기 위해 ReAct 전략도 살펴볼 예정입니다.
미래의 AI 지원
이러한 작업의 결과는 이제 Chrome 132부터 사용할 수 있으며, 여기에는 스타일 지정, 네트워크, 소스, 성능에 관한 AI 지원이 포함되어 있습니다. YouTube가 이 기능을 만드는 데 들인 열정만큼 여러분도 즐겁게 사용하시기 바랍니다.
시작할 때 어떤 부분을 중점적으로 살펴봐야 할지 알아보려면 자체 페이지에서 사용해 볼 수 있는 데모 프롬프트가 많이 포함된 종합적인 AI 지원 빠른 시작 가이드를 확인하고, 버그 토론에서 의견을 공유해 주세요.