1. 한눈에 보기 (핵심 요약)
Theo(t3dotgg)가 운영하는 T3 Code 웹 앱에서 GPU 프로세스가 CPU를 13~50%까지 잡아먹는 이상한 성능 문제를 발견하고, 하루 반나절에 걸쳐 원인을 추적한 실전 디버깅 브이로그다. 결론부터 말하면 범인은 사이드바에서 깜빡이는(pulse) 터미널 아이콘 하나였다. animate-pulse 같은 무한 반복 CSS 애니메이션이 요소를 별도 GPU 컴포지터 레이어로 승격시키면서, 디스플레이 주사율(그의 경우 120Hz)에 맞춰 끊임없이 프레임을 다시 그리게 만든 것이 핵심 원인이었다. 여기에 backdrop-blur와 화면 전체에 깔린 노이즈(grain) 레이어가 결합되며 문제가 증폭됐다.
더 흥미로운 지점은 AI 에이전트(Codex/"Soul", "Fable" 등)가 이 문제를 전혀 풀지 못했다는 것이다. 첫 번째 에이전트는 웹소켓/네트워크 레이어가 문제라고 진단하고 1만 줄이 넘는 리팩터링 PR을 만들었지만 성능은 전혀 개선되지 않았다. Chrome 내장 성능 프로파일러와 AI 요약 기능도 전혀 도움이 되지 않았다(엉뚱하게 UI 컴포저의 그라디언트 효과를 범인으로 지목하는 등). 결국 Theo는 에이전트에게 "문제를 풀어달라"고 요청하는 대신, 런타임에 CSS 속성을 켜고 끌 수 있는 커스텀 디버그 도구(window._t3gpu)를 만들어달라고 요청해서 직접 이분 탐색으로 원인을 좁혀나갔다. 에이전트는 정답을 찾지 못했지만, 정답을 찾기 위한 도구를 빠르게 만들어주는 역할은 훌륭하게 해냈다는 것이 이 영상의 핵심 메시지다.
2. 문제 발견 과정
- T3 Code 웹 앱은 겉보기엔 멀쩡했다 — 클릭하면 즉시 반응하고 네비게이션도 매끄러웠다. 하지만 작업관리자(Task Manager) 기준 GPU 프로세스가 720p 해상도에서 13~15% CPU를 사용했고, 5K Studio Display XDR의 풀 해상도에서는 최대 50%까지 치솟았다.
- Theo는 원래 노트북에서 T3 Code로 에이전틱 코딩을 돌리면서 동시에 Moonlight로 데스크톱 게임을 120fps로 스트리밍하고 있었는데, 이 조합에서 노트북 키보드가 뜨거워질 정도로 발열이 심해졌다.
- Moonlight/Sunshine 설정을 최적화해도 해결되지 않아 다음 날 GPT-5.6("Soul")과 "Fable"을 이용해 트레이싱을 시도했고, 그 과정에서 T3 Code를 돌리는 브라우저 프로세스가 범인이라는 걸 알아냈다.
- 중요한 관찰: Chrome 내장 성능 도구는 전혀 도움이 안 됐다. 이 도구들은 JS 실행 지연이나 느린 로딩, 리소스 병목 같은 문제에 최적화되어 있어서, 문제가 CSS/컴포지터 레이어로 오프로드된 경우에는 유용한 신호를 주지 못한다는 게 이번 사례의 중요한 교훈이다.
- 특정 탭이 문제인지 확인하기 위해 평소 안 쓰는 Chrome을 새로 켜서 T3 Code 탭 하나만 열고 비교했다.
google.com으로 이동하면 GPU 사용률이 18~40%대에서 3%로 뚝 떨어지는 것을 확인하며 문제가 T3 Code 자체에 있음을 확정했다.
3. AI 에이전트들의 삽질 타임라인
- Codex("Soul")의 1차 시도 — 막연한 문제 설명만으로 진단을 요청했더니 "웹소켓 기반 메인 스레드 스톨", "디코딩/히스토리 스캔/상태 재작성/하이라이팅의 곱연산적 경로" 등을 지목하며 자신 있게 원인을 제시. 그대로 코드를 작성·테스트하게 했더니 1만 줄이 넘는 대규모 리팩터링 PR이 나왔지만 성능은 조금도 개선되지 않았다.
- Chrome 자체 AI 요약(Gemini)도 무용지물 — 스크립트/스타일/레이아웃/프레임워크 실행 시간이 다 미미하다고 나왔고, "울트라씽크 컴포저 그라디언트 효과"를 원인으로 지목했는데, 이는 애초에 Claude Code +
ultrathink입력 시에만 나타나는 UI라 Codex 단독 사용 환경에서는 존재하지도 않는 원인이었다. Theo는 이 순간 "이 모델이 문제를 풀어줄 가능성은 없다"고 확신하게 됐다. - 전략 전환: 에이전트에게 '정답'이 아니라 '실험 도구'를 요청 — Theo는 콘솔에서 즉시 실행 가능한
window._t3gpu함수를 만들어달라고 요청. 이 함수는 애니메이션, 필터, 그림자, 컴포저, 블러, 미디어 레이어, 노이즈 레이어 등을 개별적으로 켜고 끌 수 있는 커스텀 CSS 오버라이드였다._t3gpu.applyAll()→ GPU 프로세스 사용률이 3% 이하로 급락 (UI는 깨졌지만 원인 후보군이 이 안에 있다는 게 확정됨)_t3gpu.reset()→ 다시 스파이크- 노이즈만 끄기 → 약간 개선되지만 부족
- 블러만 끄기 → 오히려 20% 가까이 증가(무관 요인)
- 애니메이션만 끄기 → GPU 사용률이 거의 0으로 급락 — 결정적 단서 확보
- Codex 2차 진단 — 애니메이션이 핵심이라는 정보를 주자 "펄스 애니메이션이
transition과animation규칙을 함께 비활성화하고 있으니 분리해서 진단하자"고 제안, 이후 사이드바의 **펄싱 터미널 아이콘(스레드에서 터미널을 열면 나타나는 녹색 점멸 아이콘)**을 주요 원인으로 특정. 다만 "펄스를 정적으로 바꾸거나, 활성화 직후 2.5초만 유한하게 펄스를 주자"는 제안은 Theo가 강하게 거부한 최악의 UX 제안이었다. - "Fable"로 전환 — Codex가 손 놓은 뒤 Theo는 같은 컨텍스트를 Fable에게 넘겨 별도 스레드(다른 데스크톱 머신, Linux)에서 동시에 검증을 진행. Fable은 애니메이션 인벤토리 전체를 훑으며 로딩 스켈레톤, Ultrathink 레인보우/크로마 시프트 등 무관한 후보들을 먼저 나열했지만(역시 부정확), 스크롤을 더 내려가며
animate-pulse(터미널 아이콘, 타이핑 점, 스레드 상태 표시),animate-ping,animate-spin등 실제 후보군을 정리해줬다. 결정적으로 **"무한 애니메이션 하나하나는 저렴해 보여도, 각 요소가 자신만의 GPU 레이어로 승격되면서 컴포지터가 120fps로 영원히 커밋을 반복하게 만든다"**는 정확한 기술적 설명을 제공한 것이 Fable의 가장 유용한 기여였다. - backdrop-blur + 노이즈 레이어 조합이 진짜 증폭기 — Fable은 페이지 전체에 깔린 그레인(노이즈) 레이어(원래 Opus가 디자인 개선용으로 추가했던 것)가
backdrop-blur및 지속적인 애니메이션과 결합될 때 성능이 급격히 나빠진다는 것을 짚어냈다. 다만 이 컬러/톤 수정 과정에서 에이전트가 사이드바·본문·하단 바의 회색 톤을 계속 다르게 망가뜨려서(특히 HDR 디스플레이에서 두드러짐) 여러 차례 스레드를 오가며 직접 수정해야 했다.
4. 최종 원인과 해결
- 1차 원인: 무한 반복되는 CSS 애니메이션(특히
animate-pulse가 적용된 사이드바의 터미널 활성 상태 아이콘, 타이핑 점, 스레드 상태 인디케이터)이 각각 별도 GPU 컴포지터 레이어로 승격되면서, 화면에 실질적 변화가 없어도 디스플레이 주사율(120fps)에 맞춰 계속 프레임을 재구성함. - 2차 증폭 요인:
backdrop-blur와 전역 노이즈(grain) 레이어가 애니메이션과 결합되며 GPU 부하를 더 키움. 특히 고주사율·고해상도·HDR 디스플레이(5K Studio Display XDR, MacBook HDR)에서 체감 문제가 극심했음. - 해결: 문제가 된 펄스 애니메이션을 제거하고, 노이즈 레이어를 완전히 제거한 뒤 색상 톤을 재조정. 최종 PR은 GitHub에 공개되어 있다고 언급됨.
- 덤으로 발견한 사실: Claude.ai 웹 페이지를 그냥 열어놓기만 해도(idle 상태) 탭당 8000달러짜리 노트북 GPU의 10%를 사용하고 있었다 — Theo는 이를 근거로 "Anthropic도 idle 페이지 성능에 대해 진짜 엔지니어를 고용해야 한다"고 농담 섞인 일침을 날렸다. Codex 데스크톱 앱에서도 유사한 문제가 반복적으로 발생했었다고 언급하며, 이는 그가 Codex 앱의 오픈소스 대안을 직접 만들게 된 계기 중 하나였다고 밝혔다.
5. 시사점 및 인사이트
- AI 에이전트 성능 진단의 구조적 한계: 현재 AI 에이전트/브라우저 프로파일링 도구는 JS 실행 시간, 로딩 지연, 네트워크 병목 같은 "전통적" 성능 문제에는 강하지만, 문제가 CSS/컴포지터 레이어로 오프로드된 경우 사실상 무용지물이다. 스크립팅·스타일·레이아웃 소요 시간만 보고 "이상 없음"으로 결론 내리기 쉽다.
- 에이전트를 향한 요청을 "정답을 찾아줘"에서 "실험 도구를 만들어줘"로 전환하라: 모델이 근본 원인을 스스로 못 찾을 때, 대신 런타임에 가설을 빠르게 검증할 수 있는 커스텀 디버그 유틸리티(콘솔 바인딩 함수 등)를 만들어달라고 요청하는 전략이 훨씬 생산적이었다. 에이전트는 정답을 주진 못했지만, 정답을 찾기 위한 도구는 순식간에 만들어줬다.
- DevTools 자체가 관측 대상을 왜곡한다: Chrome DevTools를 열어두는 것만으로 사이트에 디버그 모드용 코드가 주입되어 실제 성능 특성이 바뀐다. 작업관리자(Task Manager)처럼 상대적으로 덜 침습적인 도구로 대조 확인하는 습관이 중요하다.
- 경험 있는 엔지니어의 직관은 여전히 대체 불가: Theo는 "이런 문제가 발생할 수 있는 후보 목록(애니메이션, 필터, 그림자, 블러, 노이즈 등)"을 AI 도움 없이도 사전에 추릴 수 있었던 건 순전히 웹 성능 분야에서 오래 쌓아온 경험 덕분이라고 밝힌다. 에이전트는 코드베이스를 더 빠르게 훑고 도구를 더 빠르게 만들 수 있지만, "진짜 정보"를 가져온 것은 결국 사람이었다.
- 무한 반복 CSS 애니메이션은 생각보다 비싸다: 겉보기엔 "저렴한 컴포지터 전용 애니메이션"이라도, 고주사율 디스플레이 환경에서 여러 개가 동시에 무한 반복되면 디바이스가 절대 idle 상태로 들어가지 못하게 만들어 GPU를 지속적으로 소모시킨다. UI에 은은한 pulse/blink 효과를 남발하는 디자인 패턴은 특히 고주사율·모바일 배터리 환경에서 재고할 필요가 있다.