매일 수천 건의 CI(지속적 통합) 로그가 쏟아지는 환경에서 모든 데이터를 거대 언어 모델에 밀어 넣는 방식은 비효율적이다. 최근 개발자 커뮤니티에서는 수 테라바이트 규모의 로그를 처리하면서도 비용을 획기적으로 낮춘 에이전트 설계 방식이 주목받고 있다. 핵심은 모든 작업을 고성능 모델에 맡기지 않고, 작업의 난이도에 따라 모델을 계층화하는 것이다.

계층적 에이전트 구조와 비용 최적화

연구팀은 Anthropic의 Opus(고성능 추론 모델)와 Haiku(경량화된 고속 모델)를 조합한 트리거(Triager) 패턴을 도입했다. 전체 CI 실패 사례 중 약 80%는 이미 알려진 문제이거나 단순 중복 오류로 판명된다. 기존에는 이를 구분하기 위해 Sonnet(중간급 성능 모델)을 사용했으나, 비용 대비 성능이 만족스럽지 않았다. 새로운 구조에서는 Haiku가 먼저 로그를 읽고 오류 메시지를 검색해 기존에 추적 중인 문제인지 판별한다. 만약 중복된 문제라면 즉시 종료하고, 새로운 문제일 경우에만 Opus로 작업을 이관한다. 이 방식을 통해 전체 실패 사례의 80%가 Opus에 도달하지 않으며, 결과적으로 Opus 4.6 버전을 사용하면서도 이전의 Sonnet 4.0 환경보다 낮은 비용을 유지하고 있다.

SQL 인터페이스를 통한 로그 데이터 접근

예전에는 로그 파일 전체를 프롬프트에 포함해 모델에 전달했으나, 이제는 에이전트가 직접 ClickHouse(대규모 데이터를 빠르게 분석하는 오픈소스 데이터베이스)에 SQL 쿼리를 날려 필요한 정보만 추출한다. 이는 단순히 토큰 비용을 아끼는 것 이상의 효과를 낸다. 특정 로그 라인을 미리 선택해 전달하면 에이전트가 해당 정보에 고착(Anchoring)되어 편향된 판단을 내릴 위험이 크기 때문이다. 에이전트는 materialized views(미리 계산된 데이터를 저장하는 뷰)를 활용해 실패율과 작업 시간 등을 먼저 파악하고, 필요할 때만 원본 로그를 조회한다. 이 과정에서 에이전트는 스스로 쿼리 결과를 판단하며, 결과가 너무 많으면 더 구체적인 뷰를 요청하거나 GitHub CLI(터미널에서 깃허브를 제어하는 도구)를 통해 부족한 정보를 보완한다.

Opus의 추론과 Haiku의 실행 분리

개발자가 체감하는 가장 큰 변화는 Opus가 직접 로그를 읽지 않는다는 점이다. Opus는 가설을 세우고 하위 에이전트인 Haiku를 생성하여 구체적인 조사를 지시한다. 예를 들어, 빌드 실패 원인을 찾을 때 Opus는 하위 에이전트에게 특정 오류 메시지를 추출하라고 명령만 내린다. 하위 에이전트는 해당 작업이 끝나면 결과를 Opus에게 전달하고 즉시 소멸한다. 이러한 방식은 두 가지 이점을 제공한다. 첫째, Opus의 문맥(Context)이 하위 에이전트의 상세 로그로 오염되지 않아 판단력이 유지된다. 둘째, 하위 에이전트의 생성 깊이를 1단계로 제한하여 무분별한 비용 증가를 방지한다. 결과적으로 Haiku가 전체 입력 토큰의 65%를 처리하지만, 전체 비용의 36%만을 차지하게 되어 전체 운영 비용을 절반 이하로 낮추는 성과를 거두었다.

에이전트의 지능은 모델의 크기가 아니라, 복잡한 문제를 얼마나 잘게 쪼개어 적재적소의 도구에 할당하느냐는 설계 역량에서 결정된다.