AI Agents for Performance: Ship Faster, Pay Less — Rajat Shah, Netflix

한 줄 핵심

Netflix의 사례는 프로파일링 결과와 코드 저장소, 테스트, canary를 연결한 AI 에이전트로 성능 병목을 더 빨리 찾고 수정해 인프라 비용을 줄이되, 인간 승인과 강한 검증 절차는 반드시 유지해야 한다는 점을 보여준다.

시간별 요약

1. 0:00
   코딩 에이전트가 빠르게 코드를 만들수록 성능이 나쁜 코드도 함께 늘어나므로, 성능 엔지니어링을 사람의 수작업에만 의존하면 확장되지 않는다. 프로파일링을 읽고 병목을 찾는 과정 자체를 AI 에이전트가 맡게 하면 속도와 비용 측면에서 큰 개선 여지가 생긴다.
2. 5:01
   프로파일러의 출력은 언어와 런타임이 달라도 구조가 비슷해 LLM이 읽기 좋은 형식이며, O of N squared 같은 공통 안티패턴도 잘 포착할 수 있다. 에이전트는 프로파일 데이터를 통해 문제 패턴을 찾은 뒤 해당 Git repo와 커밋을 확인해 실제 코드 수정과 code review까지 이어갈 수 있다.
3. 12:01
   한 서비스에서 찾은 안티패턴은 다른 여러 서비스에도 반복될 수 있으므로, 단일 수정에 그치지 않고 cross repo 검색으로 확장하는 것이 중요하다. 실제로 동일 패턴이 7개 서비스에 퍼져 있었고, 이런 식의 재사용 안티패턴은 서비스별로 0.5 to 4.6% 수준의 CPU 절감 여지를 만들 수 있다.
4. 15:03
   에이전트가 더 잘 일하려면 장기 기억이 필요하므로, 패턴과 안티패턴을 중앙 Git repo의 markdown catalog로 축적해 재사용해야 한다. 이 catalog는 human과 agent 모두가 읽고 쓸 수 있어야 하며, confidence, 심볼, 확인된 서비스 정보를 함께 담아 점점 더 정확한 리뷰 근거가 되게 해야 한다.
5. 21:00
   AI가 낸 최적화 제안은 바로 배포하지 말고 unit test, integration test, canary, observability report를 거쳐 검증해야 한다. 특히 canary는 기존 코드와 수정 코드를 동일 트래픽으로 비교해 CPU, latency, error rate를 확인하는 ground truth 역할을 하며, 최종 승인은 반드시 engineer가 내려야 한다.
6. 24:01
   이 접근은 이미 운영 중인 코드를 고치는 반응형 단계에서 시작해, catalog가 쌓이면 code review 단계의 reviewer agent로 이동하고, 더 나아가 코드 작성 단계에서부터 안티패턴을 피하게 하는 선제형 단계로 확장된다. 다만 가장 큰 효과는 AI 자체보다 테스트, canary automation, catalog indexing 같은 기반을 먼저 탄탄히 만들 때 나온다.

실무 인사이트

• 성능 최적화 자동화는 LLM부터 넣기보다 프로파일 수집, repo 연결, canary 비교 같은 하네스를 먼저 표준화해야 효과가 난다.
• 성능 안티패턴 catalog를 중앙 저장소로 관리하면 한 번 찾은 병목 지식을 여러 서비스와 여러 언어에 재사용할 수 있다.
• 에이전트가 code review를 열더라도 배포 승인 책임은 사람에게 남기고, test와 canary로 충분히 검증한 뒤에만 반영해야 한다.