멘드럴이 오퍼스 업그레이드를 통해 LLM 비용을 절감한 방법: 트라이어저 패턴, SQL 접근, 서브 에이전트 아키텍처

Mendral은 최근 CI 실패 분석을 위해 Opus 4.6으로 업그레이드하면서도 이전 Sonnet 4.0 설정보다 전체 LLM 비용을 절감한 방법에 대한 세부 정보를 공개했습니다. 핵심은 트라이지와 조사를 분리하고 무거운 작업에 저렴한 하위 에이전트를 사용하는 아키텍처입니다.

아키텍처: 저렴한 트라이저, 비싼 플래너

분석된 약 4,000개의 CI 실패 중 3,187개는 중복이었습니다. 즉, 알려진 불안정한 테스트, 인프라 결함 또는 네트워크 문제였습니다. 이러한 경우에 비싼 모델을 깨우는 것은 낭비입니다. 그러나 중복 제거는 결정적이지 않습니다. 동일한 작업이 다른 이유로 실패할 수 있습니다. 그들의 해결책은 트라이저 패턴입니다:

• Haiku 에이전트는 좁은 작업을 처리합니다: 실패가 이미 추적되고 있는지 결정합니다. 정확한 일치 및 알려진 오류 메시지에 대한 시맨틱 검색(pgvector)을 사용합니다. operator does not exist bigint character varying와 migration type mismatch on installation_id처럼 다른 두 문자열이 동일한 근본 원인인 경우 시맨틱 검색이 이를 포착합니다.
• 의심스러운 경우 Haiku는 Opus 4.6으로 에스컬레이션합니다. 거짓 양성은 약간의 비용이 들지만, 거짓 음성은 실제 버그를 놓칠 수 있습니다.
• 실패 5개 중 4개는 Opus에 도달하지 않습니다. 트라이저 일치 비용은 전체 조사보다 약 25배 저렴합니다.

에이전트가 컨텍스트를 가져오게 하고, 푸시하지 마세요

200K+ 줄의 로그를 프롬프트에 집어넣는 대신, 에이전트는 ClickHouse에 대한 SQL 인터페이스를 얻습니다. 원시 테이블(github_logs, 로그 라인당 한 행)과 사전 집계된 데이터가 있는 구체화된 뷰(워크플로별 실패율, 작업 타이밍, 결과 수)가 있습니다. 대부분의 조사는 뷰로 시작하여 범위를 좁힌 다음 원시 로그를 드릴다운합니다. 쿼리가 너무 많은 행을 반환하면 시스템이 잘라내고 더 구체적인 뷰를 제안합니다. 로그가 아직 수집되지 않은 경우 에이전트는 GitHub CLI로 대체합니다.

비싼 모델은 계획하고, 저렴한 모델은 실행합니다

Opus는 가설을 세우고 Haiku 하위 에이전트를 생성하며, 깊이는 1단계로 제한됩니다. 즉, 무제한 팬아웃이 없습니다. 각 하위 에이전트는 Opus로부터 프롬프트를 받습니다: 정확히 무엇을 검색하고 어떻게 할지. 실제 사례의 예:

세 개의 Storybook CI 작업이 동일한 커밋에서 실패하여 pnpm install에서 충돌했습니다. Opus는 해당 단계에서 오류 메시지를 가져오기 위해 하위 에이전트를 보냈습니다. ClickHouse에 아직 로그가 없었기 때문에 하위 에이전트는 GitHub CLI를 사용하여 반환했습니다: gyp ERR! not found: make — [email protected]이 러너에 make가 없어 컴파일할 수 없었습니다. Opus는 ClickHouse에서 14일간의 실패 추세를 쿼리하고 변곡점을 찾아 에스컬레이션했습니다. 하위 에이전트 프롬프트는 명시적입니다: "이 실행의 CI 로그를 가져와. pnpm install 단계의 정확한 오류 메시지, 전체 오류 출력, 특히 마지막 50-100줄을 반환해."

이 글이 필요한 사람

CI 디버깅 또는 컨텍스트 크기와 비용이 문제인 모든 작업을 위해 LLM 기반 에이전트를 구축하는 팀.