AI를 활용한 Web 성능개선 실전 사례

채널톡 관리자 페이지의 성능 부채를 AI를 활용해 하루 만에 여러 건 개선한 기록이다. 수백 개 방과 상시 WebSocket 연결, 매 초 쏟아지는 소켓 이벤트를 다루는 앱이라 성능 문제의 원인이 한 곳에 있는 경우가 드물었다. 도구로 React DevTools Profiler 대신 flame chart를 쓰는 이유를 짚고, AI가 어디까지 대신하고 사람이 무엇을 판단해야 하는지 경계를 나눈다.

핵심 포인트

Profiler는 React의 commit phase 안에서 일어나는 일만 본다. Redux saga가 소켓 이벤트를 받아 store를 여러 번 갈아치우는 과정은 render cycle 바깥이라 마지막 dispatch가 트리거한 리렌더만 찍힌다.
postMessage로 수백 번 메시지를 주고받는 structured clone 직렬화 비용도 플랫폼 레벨이라 Profiler의 시야 밖이다.
flame chart는 saga 내부 실행, 직렬화 비용, task queue와 microtask queue의 인터리빙까지 다 보여주고 50ms를 넘는 Long Task를 잡아낸다.
AI가 잘하는 것은 flame chart의 의심 지점에서 호출 경로를 추적해 병목 원인을 찾는 일이고, 사람이 해야 하는 것은 어디가 UX 관점의 크리티컬 패스인지 정의하고 우선순위를 정하는 일이다.
팀챗 리스트 섹션 연산이 399ms에서 72ms로 줄었다.

상세 정리

저자의 성능 관점: 미리 최적화하겠다고 코드를 복잡하게 만드는 것보다 문제가 보일 때 집중해서 잡는 쪽이 낫다고 본다. 채널톡을 팀 메신저로 쓰고 있어 실사용자로서 체감할 수 있다는 점도 언급한다.
Profiler의 한계 정리: hook 안의 O(n²) 탐색은 증상은 보인다. 이 컴포넌트 렌더에 200ms 걸렸다는 식이다. 하지만 어떤 함수의 어떤 루프가 시간을 먹는지는 안 보인다.
기존 워크플로우: flame chart를 열고 의심 구간을 눈으로 찾고 코드를 따라가며 원인을 좁혔다. Long Task가 보이면 가장 넓은 블록의 함수명을 확인하고 소스맵을 따라 원본 파일을 열어 한 줄씩 읽는 식으로, 경험과 감이 필요하고 시간이 오래 걸렸다.
AI 도입 후: flame chart에서 핫패스가 보이면 함수명이나 파일명을 넘겨 왜 느린지 분석하게 하고, HAR 파일의 WebSocket 메시지를 통째로 넘겨 불필요한 소켓 이벤트 패턴을 찾게 하면 로그를 한 줄씩 읽을 필요 없이 정리돼 나온다.
사람의 몫: 이 구간이 유저에게 정말 체감되는지, 이걸 먼저 고쳐야 하는지는 제품을 아는 사람이 판단해야 한다.
실제 워크플로우: 크리티컬 패스에서 레코딩하고 flame chart에서 병목 위치만 대충 잡은 뒤 깊이 파는 건 AI에 맡긴다. 생각과 다른 방향이 나올 때도 있지만 이 함수가 전체 Long Task의 60%를 차지한다는 식의 정량 분석은 확실히 잘해, 감으로 우선순위를 정하던 과정이 줄었다.
추가 실험: Auto Research 방식을 바탕으로 Datadog MCP와 Chrome DevTools Protocol을 써서 유저 크리티컬 패스를 유추하고 측정부터 개선까지 자동 루프를 돌려봤고 꽤 괜찮은 결과가 나와 별도로 다루겠다고 예고한다.
개선 사례 1: 팀챗 목록을 섹션별로 구성하는 훅이 매번 핫패스에 찍혔다. 방이 수백 개인 환경에서 방을 이동할 때마다 실행되는데 전형적인 O(n²) 패턴이었다.
같은 파일에 배열을 spread로 누적하는 패턴도 있었는데 매 iteration마다 배열 전체를 복사하므로 이것도 O(n²)다.
측정 조건을 명시한다. source-map을 켜고 진행해 production 환경보다 느린 상태에서 잰 값이다.
이런 패턴이 코드 리뷰에서 놓치기 쉬운 이유는 개발 환경에서는 데이터가 적어 티가 안 나다가 프로덕션에서 데이터가 쌓이면 느려지기 때문이다.
개선 사례 2 방향: 메시지 블록을 구조화된 노드로 변환하는 파서를 메인 스레드 블로킹을 피하려고 Web Worker에서 돌리는데, 그 과정의 비용을 다룬다.