넷플릭스 AI 에이전트 성능 엔지니어링 사례 — 프로파일링 자동 분석과 안티패턴 카탈로그

핵심 메시지

• 코딩 에이전트 덕분에 코드는 10배 빨리 쌓이지만, 그 코드가 항상 빠른 코드는 아니어서 컴퓨팅 비용도 함께 불어난다.
• 프로파일러 출력은 언어와 무관하게 호출 스택과 CPU 시간이라는 비슷한 구조라서, LLM이 읽고 병목을 짚기에 적합한 데이터다.
• 발견한 안티패턴을 마크다운 파일로 된 중앙 깃 저장소 카탈로그에 쌓아 두면, 그것이 에이전트의 장기 기억 역할을 한다.
• 테스트 통과와 카나리 배포 비교 리포트를 에이전트가 스스로 확인하게 한 뒤에야 사람에게 코드 리뷰를 요청하게 해 소음을 줄인다.
• 운영 중 코드를 고치는 사후 대응에서 시작해, 리뷰 단계·코드 작성 단계로 점점 앞당기는 것이 목표다.

쉽게 이해하기

넷플릭스에서 머신러닝 모델 호스팅용 대규모 분산 시스템을 만드는 스태프 엔지니어 라자트 샤가 AI 엔지니어 월드페어 2026에서 성능 엔지니어링 작업에 AI 에이전트를 붙인 경험을 공유했다. 발표의 성격은 이론이 아니라 다른 조직도 따라 할 수 있는 실무 지침서에 가깝다. 출발점이 된 문제의식은 단순하다. 코딩 에이전트가 좋아지면서 코드를 만들어내는 속도는 빨라졌는데, 그 속도만큼 인프라 비용도 같이 오르고 있다는 것이다.

그는 코딩 에이전트가 자동으로 빠른 코드를 써 줄 것이라는 기대에 선을 긋는다. 에이전트는 그 회사의 플랫폼과 프레임워크, 내부 코드베이스의 관행을 알지 못하기 때문에, 다른 코드베이스에서 본 방식을 그대로 가져오거나 아무도 예상하지 못한 새 패턴을 만들어내곤 한다는 것이다. 반대로 사람이 하는 성능 개선은 프로파일링을 걸고 데이터를 내려받아 시각화 도구로 열어 호출 스택을 뒤지는 과정이라, 병목 하나 찾는 데만 수십 분이 들고 학습 곡선도 가파르다. 그래서 대부분의 조직에서 이 작업은 새벽에 장애가 났을 때나 겨우 이뤄진다.

실험의 전제는 두 가지였다. 첫째, 자바든 파이썬이든 고든 프로파일러가 뱉어내는 결과는 호출 스택과 메서드별 CPU 시간이라는 비슷한 형태이므로 LLM이 다루기 좋은 구조화 데이터다. 둘째, O(N²) 반복문이나 루프 안에서 매번 반복되는 불변 계산, 같은 객체를 계속 새로 만드는 코드처럼 널리 알려진 안티패턴은 좋은 품질의 코드로 학습한 에이전트가 이미 알고 있다. 실제로 에이전트는 코드베이스를 보지 않고 호출 스택만으로 이차 복잡도 문제를 짚어냈고, 이것이 첫 번째 확신이 됐다.

여기서 한 걸음 더 나아가, 에이전트에 지침을 충분히 주면 문제를 찾는 데서 그치지 않고 실제 수정까지 이어졌다. 프로덕션에서 돌고 있는 커밋으로 깃 저장소를 체크아웃하고, 해당 메서드가 정의된 위치를 찾아 호출 경로를 추적한 뒤 코드 리뷰를 올리는 네 단계다. 발표에서 소개된 사례에서는 프로파일링 기간 중 CPU 시간의 8.8%를 쓰던 코드를 찾아냈고, 큰 코드베이스에서도 이 과정이 5분 안에 끝났다. 더 큰 수확은 확장성이었다. 지표 카운터 객체를 뜨거운 경로에서 매번 생성하던 나쁜 패턴을 여러 저장소에 걸쳐 검색했더니 7개 서비스에서 같은 문제가 발견됐고, 모두 고칠 경우 서비스별로 0.5~4.6%의 CPU 절감이 가능하다는 추정이 나왔다.

핵심 장치는 화려한 기술이 아니라 '카탈로그'다. LLM은 기억이 짧기 때문에, 발견한 패턴과 안티패턴을 팀이나 제품에 종속되지 않는 중앙 깃 저장소에 마크다운으로 계속 쌓아 둔다. 항목에는 관련 심볼 목록, 확인된 서비스, 신뢰도, 그리고 나쁜 예와 좋은 예를 함께 적는다. 벡터 데이터베이스도 필요 없고 빈 카탈로그에서 시작해도 되며, 제프 딘의 C++ 최적화 글이나 파이토치의 torchfix 저장소, 사내 성능 플레이북을 출발점으로 삼을 수 있다. 한 서비스가 찾아낸 패턴을 다음 서비스의 에이전트가 그대로 재사용하는 것이 이 구조의 이득이다.

주요 인사이트

• 이 접근의 진짜 전제 조건은 AI가 아니라 기본기다. 단단한 테스트 커버리지, 잘 돌아가는 카나리 자동화, 신뢰할 만한 관측 지표가 먼저 있어야 하고, 에이전트는 그것들을 호출하고 리포트를 읽는 역할만 맡는다.
• 발표자는 에이전트가 프로덕션 코드를 직접 배포하게 두지 않는다. 잘 돌아가던 코드를 성능 때문에 손대는 일은 비즈니스 맥락과 테스트가 부족하면 위험하기 때문에, 사람의 승인을 마지막 관문으로 의도적으로 남겨 뒀다.
• 프로파일러는 추정치를 주고 카나리는 실측을 준다는 구분이 판단 기준으로 제시된다. 같은 트래픽을 옛 코드와 새 코드에 10분쯤 흘려 CPU·지연시간·오류율을 비교한 뒤, 오류율이 늘었다면 에이전트가 리뷰를 올리지 않고 멈춘다.
• 가장 큰 효과는 왼쪽으로 당길수록 커진다. 장애 후 대응에서 코드 리뷰 시점의 인라인 지적으로, 다시 코드를 쓰는 순간 카탈로그를 참조해 애초에 느린 코드를 쓰지 않는 단계로 옮겨 가는 것이 지향점이다.
• 자율성을 무작정 높이는 것은 권하지 않는다. 에이전트가 스스로 계획하고 판단하는 3단계로 가려면 평가와 샌드박싱, 프롬프트 인젝션 같은 보안 문제에 훨씬 큰 투자가 필요하므로, 정해진 워크플로를 주기적으로 돌리는 2단계에서 대부분의 이득을 얻으라고 조언한다.

자주 묻는 질문

관련 AI 소식