게시일: 2026년 11월 10일
WeTV는 Tencent의 국제 동영상 스트리밍 플랫폼입니다. 동남아시아 및 기타 글로벌 시장의 시청자에게 드라마 시리즈, 애니메이션, 버라이어티 쇼를 제공합니다. 동영상을 중심으로 구축된 사이트의 경우 성능에 따라 시청자가 머무는지, 검색엔진이 콘텐츠를 표시하는지, 재생이 원활하게 느껴지는지가 결정됩니다.
WeTV 웹 엔지니어링팀은 성능 목표를 달성하지 못하는 코드를 출시하지 않습니다. 오랫동안 이 기준을 유지하려면 개발자는 빌드가 검사에 실패할 때마다 하던 일을 중단하고 Chrome을 열어 페이지를 직접 프로파일링해야 했습니다. 회귀를 추적하고 수정하는 데 약 4시간이 걸렸습니다.
오늘날에는 AI 코딩 에이전트가 CI/CD 파이프라인의 일부로 이 작업을 수행합니다. 에이전트용 Chrome DevTools를 사용하면 에이전트가 실시간 브라우저에서 페이지를 검사합니다. Modern Web Guidance를 사용하면 현재 웹 플랫폼 표준을 따르는 수정사항을 작성합니다. 이제 워크플로에서 실패한 성능 테스트의 90% 를 자동으로 진단하고 해결하며, 실패한 검사에서 확인된 수정까지 걸리는 시간이 전체 빌드 및 수동 평가를 포함하여 4시간에서 30분으로 단축되었습니다.
문제: 편집기와 브라우저 사이에서 어려움을 겪는 개발자
WeTV 엔지니어들은 이미 IDE에서 AI 코딩 도구를 사용하고 있었습니다. 이러한 도구는 코드를 작성할 수 있지만 브라우저에서 실행된 코드가 무엇을 하는지 확인할 수 없었습니다. 그래서 작업이 두 가지로 나뉘었습니다. 엔지니어는 편집기에서 코드를 작성한 다음 Chrome으로 전환하여 배포, 검사, 확인합니다. 수정할 때마다 이 루프를 수동으로 다시 거쳐야 했습니다.
이러한 분할은 출시 단계에서 가장 큰 타격을 입혔습니다. WeTV의 CI/CD 파이프라인은 모든 출시에서 성능 추적을 실행하고 누적 레이아웃 이동(CLS)을 0.1 이하로 유지합니다. 빌드가 이 선을 넘으면 파이프라인에서 플래그를 지정했지만 원인을 찾는 것은 여전히 수동으로 이루어졌습니다. 엔지니어는 Chrome DevTools를 열고, trace를 기록하고, 이동한 요소를 찾고, 해당 결과를 편집기로 다시 가져와서, 수정사항을 작성하고, 검사를 다시 실행해야 했습니다. 단일 CLS 회귀에는 약 4시간의 엔지니어링 시간이 소요됩니다.
팀에는 실행 중인 페이지를 살펴보고 코드를 알려진 표준에 맞게 수정하는 두 가지 작업을 모두 처리할 수 있는 에이전트가 필요했습니다.
해결책: 에이전트를 브라우저 및 웹 표준에 연결
WeTV는 성능 검증을 병합 요청(MR) 흐름으로 옮겼습니다. 개발자가 MR을 열면 CI/CD 파이프라인은 팀의 IDE 도구에 없는 두 가지 기능을 사용하여 AI 코딩 에이전트가 로컬에서 실행되는 환경을 시작합니다.
- 에이전트용 Chrome DevTools: 모델 컨텍스트 프로토콜(MCP) 서버를 실행하고 에이전트를 실시간 Chrome 인스턴스에 연결합니다. 에이전트는 다른 Chrome DevTools 기능 중에서 성능 트레이스를 기록하고 개발자가 DevTools에서 하는 것과 동일한 방식으로 프런트엔드 코드가 실제로 렌더링되는 방식을 확인할 수 있습니다.
- Modern Web Guidance: 웹 플랫폼 권장사항과 브라우저 호환성 데이터가 포함된 에이전트 기술입니다. 에이전트가 기존 패턴에서 벗어나 최신 웹 플랫폼 기능을 기반으로 빌드된 수정사항을 사용하도록 유도합니다.
에이전트용 DevTools는 에이전트에게 무엇이 잘못되었는지 알려줍니다. Modern Web Guidance는 이를 수정하는 방식을 형성합니다.
실제 사례: 에피소드 재생 페이지의 레이아웃 변경
병합 요청 중에 에이전트가 데스크톱 에피소드 재생 페이지에서 performance_start_trace 도구를 실행했습니다. 트레이스에 기록된 CLS는 0.39로, 한도인 0.1의 거의 4배에 달합니다.
에이전트에게 수정하기 전에 진단하도록 지시
WeTV는 상담사가 임기응변으로 대응하는 것을 허용하지 않습니다. 워크플로를 구동하는 프롬프트는 코드를 건드리기 전에 문제를 진단하고, 모델이 기본적으로 생성하는 것에 의존하는 대신 Modern Web Guidance를 기준으로 결과를 확인하도록 지시합니다.
다음은 WeTV팀에서 사용한 프롬프트의 예입니다.
Context:
"The CLS (Cumulative Layout Shift) of this page needs inspection. Diagnose
first, then modify the code, do not guess."
Mandatory Execution Steps:
1. Performance Trace: Use Chrome DevTools for agents to run performance traces
on both Desktop and Mobile views.
2. Identify Culprits: Use CLSCulprits insight to pinpoint the exact DOM elements
causing shifts (capture class/id, timing, and score).
3. Use web best practices for performance and CSS to optimize CLS.
4. Multi-Agent Parallelism: Enable parallel agents for efficiency:
- Agent A: Investigate Player/Main Layout SSR placeholders.
- Agent B: Investigate Sidebar Ads, VIP buttons, Tabs, and late-injected
lists.
- Agent C: Investigate Fonts and other minor factors.
Constraint: Each agent modifies only files within its scope to prevent
conflicts.
5. Root Cause Confirmation: Confirm the root cause before applying fixes.
Prioritize reserving space over changing interaction semantics just to fix
CLS.
6. Verification: After modification, re-test CLS via equivalent CSS injection
or local build. Target: CLS < 0.1.
이 프롬프트의 두 부분이 가장 큰 비중을 차지합니다. '먼저 진단한 후 코드를 수정'하면 에이전트가 증상을 패치하지 않습니다. 2단계에서는 상담사가 insightName: 'CLSCulprits'와 함께 performance_analyze_insight를 사용하도록 안내하므로 일반적인 의심 대신 정확한 요소, 타이밍, 점수를 보고합니다.
다음 동영상에서 프롬프트가 실행되면 에이전트는 Modern Web Guidance에서 관련 가이드를 검색하여 CLS와 관련된 최신 웹 기능으로 수정사항을 구현하고, 에이전트용 Chrome DevTools를 사용하여 Chrome 브라우저 인스턴스를 열고 성능 추적을 기록합니다.
이러한 런타임 진단과 구조화된 안내의 조합을 통해 복잡한 레이아웃 변경을 자동으로 수정할 수 있습니다. 다음은 자동화된 워크플로로 해결된 문제의 예입니다.
근본 원인 찾기
추적 결과 동영상 플레이어가 원인으로 지목되었습니다. WeTV는 서버에서 플레이어를 렌더링하지만 플레이어의 컨테이너는 높이를 예약하지 않았습니다. 클라이언트가 페이지를 하이드레이션하면 컨테이너의 높이가 확장되고 주변 콘텐츠가 이동했습니다.
표준 기반 수정사항 적용
서버 측 렌더링 중에 공간을 예약하여 하이드레이션 전에 컨테이너의 높이가 이미 올바르게 설정되도록 하는 것이 해결 방법입니다. 다음은 에이전트가 Modern Web Guidance css-layout 가이드를 참고하여 작성한 수정사항의 예입니다.
.play__block--player .play__aside--left {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16/9;
}
에이전트가 CSS를 적용한 후 파이프라인이 페이지를 다시 빌드하고 에이전트가 동일한 trace를 다시 실행했습니다. CLS가 0.1 미만인 경우에만 패치가 사람 검토로 넘어갔습니다.
영향: 빠른 출시 및 안정적인 레이아웃
WeTV는 에이전트용 Chrome DevTools와 Modern Web Guidance를 CI/CD 워크플로에 추가하여 엔지니어링 효율성과 레이아웃 안정성을 크게 개선했습니다.
- 엔드 투 엔드 디버깅 및 해결 시간이 87% 단축되었습니다(4시간에서 30분으로).
- 반복되는 성능 회귀의 90% 가 자동으로 진단되고 해결됩니다.
엔지니어는 더 이상 프로파일링에 근무일의 절반을 소비하지 않습니다. 빌드가 기준점을 넘으면 에이전트가 트레이스를 읽고, 수정사항을 작성하고, 테스트하고, 검증된 패치를 검토자에게 전달합니다. 사람이 최종 결정을 내리지만, 실패한 검사를 이미 통과한 수정사항부터 시작합니다.
CLS 회귀는 병합 요청 내에서 수정되므로 프로덕션에 도달하지 않습니다. 이렇게 하면 페이지가 0.1 목표 미만으로 유지되고 WeTV의 검색 공개 상태가 보호되며 주기 후반에 출시를 차단하는 일반적인 이유가 제거됩니다.
팀을 위한 강의
WeTV의 설정은 스택에 따라 다르지만 그 이면의 패턴은 성능에 따라 출시를 제한하는 대부분의 팀에 적용됩니다.
- 실패가 발생하는 에이전트를 실행합니다. WeTV는 병합 요청에서 에이전트를 트리거하므로 실패한 검사를 확인하고 수동으로 세션을 시작할 필요가 없습니다.
- 에이전트가 수정하기 전에 진단하도록 합니다. 먼저 추적과 원인으로 지목된 요소를 요청하면 추측이 아닌 실제 요소를 타겟팅하는 수정사항이 생성됩니다.
- 런타임 데이터를 표준과 페어링합니다. 트레이스는 에이전트에게 이동한 요소를 알려줍니다. Modern Web Guidance는 현재 플랫폼 관행을 따르는 수정사항을 알려줍니다.
- 증거를 요구합니다. 실패한 동일한 추적을 다시 실행하면 상담사가 수정사항이 작동한다는 증거를 확인할 수 있습니다. P2ER은 필수 실증적 검증 규칙에서 동일한 원칙을 따릅니다.
- 휴먼인더루프를 유지합니다. 에이전트가 조사를 수행하고 엔지니어가 이미 검사를 통과한 패치를 검토합니다.
의견 및 향후 계획
WeTV는 에이전트용 Chrome DevTools의 실시간 런타임 원격 분석을 Modern Web Guidance의 표준화된 규칙과 페어링하면 출시 프로세스에서 수동 성능 분석을 제거하는 동시에 에이전트의 코드 변경사항을 현재 웹 플랫폼 표준에 맞게 유지할 수 있다는 사실을 발견했습니다.
"속도와 품질 측면에서 매우 효과적인 결과를 얻었습니다. 에이전트용 Chrome DevTools와 Modern Web Guidance에서 제공하는 진단 통계는 복잡한 레이아웃 문제를 해결하는 데 신뢰할 수 있는 참고 자료가 되었습니다. 수정할 때마다 엄격한 인증을 수행하며 현재 성공률과 안정성이 출시 신뢰도를 크게 향상시켰습니다."
—양지에 정, WeTV(Tencent) 엔지니어링 책임자
다음으로 WeTV 엔지니어링팀은 예정된 코드 출시를 위한 엔드 투 엔드 테스트 전반에 에이전트용 Chrome DevTools와 Modern Web Guidance를 도입할 계획입니다.
리소스
비슷한 워크플로를 설정하려면 다음 리소스를 살펴보세요.