발표자: Mike (Thundra 공동창업자 겸 CTO)
핵심 주장
성능 최적화는 대부분의 팀에서 "새는 양동이(leaky bucket)"처럼 방치된다. 사소한 성능 이슈는 무시되다가 위기 수준으로 악화된 뒤에야 전사 비상 대응으로 처리되고, 해결되면 다시 방치 상태로 돌아간다. 이런 악순환의 근본 원인은 "조사 단계(research phase)"가 블랙박스라는 데 있다 — 특정 최적화를 실행하는 데 걸리는 시간은 예측 가능해도, 그 원인을 찾아내는 데 걸리는 시간은 1시간이 될지 몇 주가 될지 아무도 모른다. 그래서 아무도 우선순위를 매기지 못한다.
Thundra 팀은 이 "조사(investigation)" 자체를 에이전트로 자동화했다. 매주 프로덕션 실데이터를 기반으로 고ROI 성능 개선 기회를 자동으로 찾아내고, 스코어링하고, 실제로 고쳐보고, 그 수정이 효과가 있었다는 것까지 검증한 뒤 사람에게 리뷰 게이트로 넘긴다. 핵심은 "이런 걸 할 수 있을 것 같다"가 아니라 "이미 작동하는 수정안이고, 이게 왜 비즈니스에 영향을 주는지 근거까지 있다"는 결과물을 사람에게 전달하는 것이다.
동시에 저자는 자율 실행되는 에이전틱 자동화(autonomous automation)와 사람이 옆에서 지켜보며 쓰는 코딩 에이전트(agentic coding with a human in the loop)는 완전히 다른 신뢰 수준을 요구한다고 강조한다. IDE에서 커서로 쓰는 에이전트가 80% 정확도로도 쓸만한 이유는 사람이 바로 옆에서 맥락을 쥐고 있고 즉시 수정할 수 있기 때문이다. 반면 자율적으로 도는 자동화는 스스로 판단해 사람에게 결과를 넘기므로, 그 판단이 "고칠 가치가 있는 이슈"이고 "런타임에서 검증된 수정"이라는 확신이 80~90% 수준으로 훨씬 높아야 신뢰를 얻을 수 있다.
주요 근거와 사례
- Google DORA 2026 메트릭 인용: AI 도입이 팀에 미치는 가장 큰 영향은 "개인 생산성 체감"(엄청 빨라진 느낌)이었다. 하지만 팀 전체 처리량(throughput)은 기대만큼 늘지 않았고, 오히려 소프트웨어 배포 안정성(delivery instability)이 나빠졌다 — 개인은 빨라졌다고 느끼지만 팀 단위 산출물은 그대로이고, 소프트웨어는 더 자주 깨진다는 역설.
- "Plausible unverified"(그럴듯하지만 검증 안 됨) 문제: 에이전트가 제안한 수정이 이론적으로는 말이 되지만 실제 검증해보면 작동하지 않는 경우가 초기 시도에서 자주 나왔다. 해결책은 수정안을 프로덕션에서 실제로 일어나는 일에 접지(ground)시키는 것.
- "Lazy fix"(게으른 수정) 문제: 예외(exception)가 발생하면 에이전트가 "그냥 그 예외를 캐치하면 되지 않을까요"라고 제안하는 패턴. 진짜 필요한 건 왜애초에 예외가 발생했는지, 왜 결과가 지연되는지 근본 원인을 이해하는 것.
- 복잡한 쿼리 문제: ClickHouse(컬럼형 DB)를 사용하는데, 일반적인 SQL 패턴과는 다소 다른 쿼리 패턴을 요구해서 에이전트가 다루기 까다로웠다.
- 컨텍스트의 딜레마: 런타임/프로덕션 컨텍스트는 "너무 많거나 너무 적은" 문제를 동시에 갖는다 — 에이전트가 추론하기엔 노이즈가 큰 저신호(low-signal) 데이터가 넘치는 동시에, 실제 조사에 필요한 로그·트레이스·메트릭은 부족해서 추측과 가설로 공백을 메우게 된다.
- 메트릭과 코드 사이의 언어 불일치: 서비스 레벨 CPU/메모리, 엔드포인트 P90 같은 메트릭은 함수 레벨과 연결되어 있지 않다. 코딩 에이전트는 코드(함수·파일 레벨)로 추론하는데 메트릭은 서비스·엔드포인트 레벨이라 "같은 언어를 쓰지 않는" 문제가 생기고, 이게 정확도 저하로 이어진다.
- 실제 사례: 어떤 엔드포인트가 평소엔 200ms인데 가끔 45초가 걸리는 문제 — 원인은 MongoDB에서
distinct를 쓰고 검색 인덱스를 쓰지 않아서였다. 이런 케이스를 사람이 읽기 쉬운 짧은 설명("무슨 일이 일어났는지 + 어떻게 고치는지")으로 리포트화했다. - 80개 PR을 한꺼번에 열지 않는다: 처음엔 "매주 찾아서 자동으로 PR을 다 열면 다들 고치겠지"라고 생각했지만, 실제로는 누구도 80개짜리 PR 폭탄을 원하지 않았다. 그래서 우선순위가 높은 것 하나씩만 표면화해 "습관과 신뢰"를 먼저 쌓는 방식으로 전환했다.
구체적 인사이트
1. 인프라 설계 원칙 (vendor-neutral) 에이전틱 워크플로우 인프라를 컴퓨트, 실행 하네스, 모델 세 가지 모두에서 특정 벤더에 종속되지 않도록 설계했다. 모델과 도구 생태계가 너무 빠르게 바뀌기 때문. 실제 구현은 GitHub Actions 워크플로우 위에서 Claude Code를 사용해 매주 실행하고, MCP를 통해 런타임 인텔리전스 오버헤드를 캡처하고, 결과를 Slack으로 전송하는 구조 (Teams나 이메일, Cursor, Copilot으로도 대체 가능한 설계).
2. "Prod-to-code" 컨텍스트 매핑 서비스/엔드포인트 레벨 메트릭과 함수/파일 레벨 코드 추론 사이의 간극을 메우기 위해, 함수 레벨에서 실행되는 컨텍스트를 엔드포인트·이벤트 컨슈머·크론잡과 연결했다. 이를 통해 "이 엔드포인트가 가끔 7초씩 걸리는데 시간이 어디서 쓰이고 뭘 할 수 있나?"라는 질문에 함수 단위(DB 호출, LLM 호출, 다른 마이크로서비스 호출 등)로 답할 수 있게 만들었다. 요청이 P99나 특정 임계값을 넘을 때만 포렌식 증거를 캡처해 "여기 실제로 오래 걸린 요청 예시가 있으니 원인을 찾자"는 식으로 접근.
3. HUD (Heads-Up Display) 포렌식 데이터셋을 코드 위에 오버레이해서 보여주는 뷰. 코딩 엔지니어가 훨씬 이해하기 쉬운 형태로 데이터 구조를 표현.
4. 계층 구조: 데이터 → 쿼리 언어 → 스킬 → 자동화
- 기반 레이어: 함수·엔드포인트·포렌식 구조 위의 HUD 쿼리 언어(ClickHouse 쿼리)
- 그 위에 스킬(skills) 레이어 추가: 단순 쿼리만으로는 부족했고, "올바른 쿼리를 반복적으로 정확히 만들어내는 것" 자체가 평가(eval) 변동성의 원인이었음. 예: HTTP 500 에러 → 원인 추적 스킬, 메모리 스파이크 → 해당 시점 파드에서 뭐가 돌고 있었는지 베이스라인과 비교하는 스킬
- 최상위: 자동화(automations) — 이슈 자동 수정, 60일간 실행되지 않은 데드 코드 탐지 및 제거, 성능 자동 개선 등. 성능 자동화의 구체 타겟: 인위적 지연(타임아웃, sleep), N+1 쿼리, 인덱스 누락, 순차 처리(sequential processing) 등 — 20년 된 코드베이스, 수백 명의 기여자가 있는 환경에서 흔히 발견되고 제거하기도 상대적으로 쉬운 패턴들.
5. 우선순위 스코어링 기준
- 얼마나 자주 실행되는 핫 패스인가 (hot path)
- 비즈니스 임팩트 — 결제나 회원가입 플로우처럼 민감한 영역인가 (PM을 설득할 수 있을 만큼 중요한가로 자가진단)
- 리스크 — 마이그레이션이 필요한 등 위험한 변경인가 (리스크가 높으면 리뷰어의 시간이 더 필요하므로, 최고 임팩트가 아니라 최고 ROI를 기준으로 선별)
6. 리포트 UX가 PR보다 나았다 자동으로 PR을 여는 대신, "왜 고칠 가치가 있는지 사람을 설득하는" 형태의 휴먼 프렌들리 리포트를 만들었다. 이슈 설명 + 원인 + 수정안을 짧게 제시하고, 사람이 티켓을 만들거나 직접 PR을 만들거나 그냥 넘어갈 선택권을 준다. 사람은 여전히 루프 안에 있어야 하고, 그 사람의 시간을 존중하는 것이 신뢰 구축의 핵심이었다.
실행 포인트
- 에이전트가 "이미 검증까지 끝낸 결과"를 사람에게 넘기게 하라. 단순히 "이런 걸 할 수 있을 것 같다"는 제안이 아니라, 원인을 파악하고, 수정하고, 테스트를 재실행해서 실제 개선 효과를 확인한 뒤에 리뷰 게이트로 넘겨야 신뢰가 쌓인다.
- 스코어링과 가드레일 없이 자동화만 늘리면 슬롭(slop)이 된다. 무엇이 "고칠 가치가 있는지" 먼저 정의하라. 자동화 비용이 예전보다 훨씬 저렴해졌더라도, 사람 리뷰어의 시간과 리스크는 여전히 공짜가 아니다.
- 한 번에 다 쏟아내지 말고 하나씩 표면화하며 신뢰(습관)를 먼저 구축하라. 80개짜리 PR 폭탄은 아무도 안 본다. 작게 시작해서 "고쳤더니 진짜 효과가 있었다"는 경험을 반복시켜야 다음 리포트를 열어보게 된다.
- "context over cleverness" — 에이전트에게 올바른 컨텍스트와 올바른 스킬을 주는 것이 모델 자체의 영리함보다 거의 항상 더 중요하다. 모델은 계속 좋아지고 있지만, 어느 방향으로 조준할지는 여전히 사람(도메인 지식)이 정해야 한다.
- 자율 자동화와 IDE 코딩 어시스턴트를 같은 신뢰 기준으로 평가하지 마라. 사람이 옆에서 즉시 개입 가능한 IDE 코딩 에이전트는 80% 정확도로도 충분히 유용하지만, 사람 없이 자율적으로 돌아가는 자동화는 결과를 사람에게 넘기기 전에 80~90% 수준의 확신이 필요하다.
- 메트릭과 코드 사이의 언어 격차를 메워라 (prod-to-code). 서비스/엔드포인트 레벨 관측 데이터를 함수/파일 레벨로 매핑해줘야 코딩 에이전트가 실제로 쓸모 있는 진단을 내놓는다. 이 매핑 작업 자체가 정확도를 좌우하는 핵심 인프라 투자다.