Elastic, AI 에이전트가 Elasticsearch를 스스로 최적화하게 만든 하네스 공개

Elastic이 Elasticsearch 코드베이스의 성능 최적화 작업을 AI 코딩 에이전트에 맡기는 자동화 파이프라인을 공개했다. 요점은 에이전트를 잘 부리는 프롬프트가 아니라, 에이전트가 내놓은 결과가 진짜인지 가려내는 측정 장치다. 이들은 이 장치를 하네스(harness)라고 부르며, 에이전트가 상당한 비율로 틀릴 것이라고 가정한 상태에서 시작한다.

파이프라인은 역할이 분리된 여러 태스크로 구성된다. 먼저 탐색(exploration) 태스크가 실제 워크로드를 프로파일링해 성능 개선 여지가 있는 지점을 순위 목록으로 뽑아낸다. 사람이 그중 하나를 골라 승격시키면, 착취(exploitation) 태스크가 승인된 마이크로벤치마크를 상대로 코드를 고치고 실험을 반복한다. 통과한 변경은 실제 워크로드에 대한 검증을 거친 뒤 사람이 리뷰하고 PR로 올린다. 핫패스를 커버하는 벤치마크가 없으면 별도의 벤치마크 태스크가 새로 작성하고, 사람이 이를 레지스트리에 등록한다. 이 전 과정을 CLI 도구 atune이 받쳐주며, 각 태스크가 학습한 내용은 성능 아틀라스(performance atlas)에 누적된다.

에이전트가 실제로 보는 것은 프로파일러와 도구가 돌려주는 신호다. 쿼리 유형별로 실제 워크로드 시간이 코드 어디에 쓰이는지, 할당과 락 샘플링이 같은 캡처에서 어떻게 잡히는지, 비용이 사이클인지 가비지인지 경합인지 같은 정보가 여기에 해당한다. 비용 구성 분류기는 샘플링된 스택을 스코프 내 연산, 기타 제품 코드, GC, JIT·세이프포인트 오버헤드, CPU 밖 대기, 파킹된 스레드 같은 버킷으로 나눠 준다. 이 밖에도 변경이 측정된 노이즈 플로어 안에서 도움이 됐는지, 새 코드가 할당을 더 늘렸는지, 지금 이 머신이 측정 가능한 상태인지, 이미 누가 같은 문제를 보고하거나 고쳤는지까지 신호로 제공된다.

가장 눈에 띄는 설계는 패싯 분해(facet-decomposition)다. 혼합 쿼리 워크로드를 프로파일링하면 그룹핑용 해시맵 삽입과 퍼센타일 스케치 갱신이 둘 다 한 자릿수 퍼센트로 잡혀 비슷해 보이지만, 실제로는 전혀 비교할 수 없는 비용이다. 해시맵 삽입은 거의 모든 집계 쿼리가 지불하는 비용이고, 스케치 갱신은 누군가 퍼센타일을 요청할 때만 발생한다. 그래서 프로파일러는 쿼리 패싯을 각각 별도의 경주로 돌리고, 기록되는 모든 기회에 universal·broad·narrow 중 하나의 넓이(breadth) 값을 붙인다. 순위는 headroom × tractability × breadth로 매겨지며, universal한 3%가 narrow한 10%를 이긴다. 이 순위 함수를 도구 안에 넣어둔 덕분에 매 실행마다 순위 기준을 다시 발명할 필요가 없다.

배경에는 성능 최적화라는 작업의 성격이 있다. Elasticsearch는 대량 인덱스 구축과 실시간 검색·분석을 동시에 처리해야 하고, 코드베이스는 크고 계속 변한다. 모든 핫패스를 사람이 훑어 비효율을 찾기에는 공학 시간이 절대적으로 부족했다. 반면 성능 최적화는 결과가 숫자로 떨어지는 드문 영역이다. 코드를 더 빠르게 만들어 달라고 요청하면 끝에 하드 넘버가 남고, 프로파일러가 왜 그런지 설명해 준다. 이 글은 자율 작업에 적합한 조건으로 객관적 판정, 조밀한 유도 신호, 제한된 파급 범위를 꼽는다. 벤치마크가 판정을, 프로파일러가 다음에 무엇을 시도할지 알려주는 그라디언트를 제공하고, 잘못된 패치는 정확성을 깨뜨리는 대신 시간만 쓰고 되돌리면 된다는 것이다.

실무적으로 눈여겨볼 지점은 에이전트를 벤치마크에 그냥 들이대면 신호 대 잡음비가 형편없다는 경고다. 환경 분산 안에 들어오는 승리, 열 스로틀링 때문에 생긴 변동이 개선으로 둔갑하기 쉽다. 그래서 이들은 '원칙적으로 검증 가능'과 '실제로 검증됨' 사이의 간극을 메우는 데 공을 들였다. 에이전트가 자주 틀린다는 전제를 깔고, 맞았을 때는 확실히 증명하고, 다음에 어디를 볼지 안내하는 루프를 만드는 것이 핵심이다.

아직 남은 조건도 분명하다. 사람의 승인 게이트가 여러 곳에 남아 있고, 마이크로벤치마크가 실제 핫패스를 실제 운용 구간에서 대표하는지 증명하는 절차가 전제로 깔려 있다. 이 글은 설계 선택을 다루는 1부이며, 실제로 건진 사례는 2부에서 다룰 예정이다. 예고된 내용에는 ES|QL(Elasticsearch Query Language)의 문자열 변환 비효율, NEON 벡터 내적 구현 개선, 사용 중이던 gzip 라이브러리의 업그레이드 기회가 포함된다.