AI VIDEO BRIEFING

에이전틱 AI 엔지니어: 스펙·평가·진단 루프로 AI 에이전트 자동 개선

Mutagent 창업자들이 소개한 '에이전틱 AI 엔지니어' 개념. 스펙·빌드·평가·진단·최적화로 이어지는 오프라인/온라인 루프를 에이전트가 직접 돌려 AI 에이전트 개발을 확장하는 방법을 정리했다.

에이전트를 에이전트로 만든다: 자동화된 평가·진단 루프로 가는 '에이전틱 AI 엔지니어' 영상 대표 이미지

핵심 메시지

  • AI 에이전트 개발은 빌드·평가의 오프라인 루프와 운영·진단의 온라인 루프로 이뤄지며, 수작업으로는 확장되지 않는다.
  • 루프 자체를 에이전트가 돌리게 하면 같은 시간에 더 많은 개선 주기를 돌릴 수 있어 인간 검토 병목을 푼다.
  • 스펙은 구현(하네스·프레임워크)과 분리해 두어, 더 나은 도구로 바꿔도 재사용할 수 있는 청사진이 된다.
  • 평가는 코딩의 단위 테스트에 해당하며, 점수형보다 실행 가능한 이진 기준이 무엇을 고칠지 알려준다.
  • 진단은 실패 모드를 근본 원인별로 묶고, 코드로 점검 가능한 지표와 대표 샘플링으로 방대한 트레이스 비용을 줄인다.

쉽게 이해하기

Mutagent의 공동창업자 베네(CEO)와 부락(CTO)은 소프트웨어를 "에이전틱 루프"로 만드는 방식이 AI 에이전트 구축에도 그대로 적용된다고 말한다. 여기에는 두 개의 루프가 있다. 빌드하면서 테스트·평가·개선을 반복하는 오프라인 루프와, 운영에 배포한 뒤 트레이스를 모니터링하고 진단해 다시 최적화로 되먹이는 온라인 루프다.

문제는 이 루프를 사람이 수작업으로 돌리면 너무 느리다는 점이다. 이슈를 발견하고 변경을 구현하고 샘플을 만들어 트레이스를 들여다보고 배포·AB 테스트까지 모두 수동이면, 결국 인간의 검토와 빌드 시간이 병목이 된다. 조직에서 수백 개의 에이전트를 운영하려 할수록 이 방식은 확장되지 않는다. 그래서 두 사람은 '에이전틱 AI 엔지니어'를 다음 단계로 제시한다.

제안하는 흐름은 단계로 이뤄진다. 먼저 에이전트의 책임과 의사결정을 정의하는 스펙을 만들고, 이를 특정 하네스나 프레임워크(클로드 코드, 코덱스 등)에서 구현(빌드)한다. 이어 단위 테스트에 해당하는 평가를 정의해 성능을 검증하고, 통과하면 운영에 배포(ship)한다. 운영 단계에서는 트레이스 양이나 주기 같은 트리거 조건에 따라 자동 진단이 시작되고, 실패를 모아 근본 원인을 분석한 뒤, 발견된 실패 모드를 겨냥한 구체적 변경(뮤테이션)으로 최적화하고 다시 주기를 반복한다.

스펙 기반 개발이 강조되는 이유는, 코딩 외 영역의 에이전트는 회사마다 다른 특화된 프로세스를 다루기 때문이다. 필요한 맥락·통합·도구, 맡을 일과 맡지 않을 일, 제약과 경계를 명확히 정의해 두면 이후 모든 개발을 이 청사진에 비춰 검증할 수 있다. 또한 스펙을 구현 세부에서 분리해 두면, 한계에 부딪힌 프레임워크를 다른 하네스로 갈아탈 때도 같은 스펙을 재사용할 수 있다. 발표자들은 헤르메스(Hermes)나 deep agents처럼 빠르게 등장하는 새 하네스를 예로 든다.

평가 주도 개발은 테스트 주도 개발의 에이전트 버전이다. 평가 묶음은 지표·기준과 데이터셋으로 구성되는데, 처음부터 완벽히 설계하기는 어렵고 사용자 피드백과 운영 실패에서 점진적으로 발견된다. 점수형 평가는 루브릭이 정교하지 않으면 무엇을 고칠지 알려주지 못하므로, 실패 시 곧바로 행동으로 이어지는 이진 기준이 선호된다. LLM을 심판으로 쓸 때는 실행마다 결과가 흔들리는 분산 문제를 보정해야 실험 결과를 신뢰할 수 있다. 운영 단계의 진단에서는 실패 모드를 근본 원인별로 묶고, 코드로 점검 가능한 지표와 지능적 세분화로 대표 샘플만 읽어 수백만 건의 트레이스를 일일이 읽는 비용을 피한다. 두 사람은 이 모든 것을 평가자 에이전트와 진단 에이전트, 그리고 코딩 환경의 오케스트레이터로 묶은 Mutagent 제품으로 시연한다.

주요 인사이트

  • 핵심 전환은 "사람이 루프를 돈다"에서 "사람이 명확한 평가·종료 게이트를 갖춘 루프를 설계한다"로 옮겨가는 것이다.
  • 스펙을 구현과 분리하면 빠르게 바뀌는 에이전트 프레임워크 생태계에서 갈아타기 비용이 크게 줄어든다.
  • 점수형 평가보다 이진 기준이 나은 이유는 정확도가 아니라 "무엇을 고쳐야 하는가"라는 실행 가능성에 있다.
  • 트레이스를 전부 읽으면 실행보다 진단이 더 비싸질 수 있어, 대표 샘플링과 코드 점검 지표가 비용을 좌우한다.
  • 진단 결과에서 도출된 새 평가 기준이 다시 스펙과 에이전트의 일부가 되며, 운영할수록 에이전트가 함께 성장한다.

자주 묻는 질문

오프라인 루프와 온라인 루프는 무엇인가요?

오프라인 루프는 에이전트를 빌드하며 테스트·평가·개선을 반복하는 단계이고, 온라인 루프는 운영에 배포한 뒤 트레이스를 모니터링·진단해 다시 최적화로 되먹이는 단계입니다.

왜 스펙을 구현과 분리하나요?

에이전트 프레임워크와 하네스가 빠르게 바뀌고 때로 한계에 부딪히기 때문입니다. 스펙을 구현 세부에서 분리해 두면 더 적합한 도구로 갈아타도 같은 스펙을 재사용해 새 버전을 만들 수 있습니다.

평가에서 이진 기준을 선호하는 이유는?

점수형 평가는 루브릭이 매우 정교하지 않으면 무엇을 고쳐야 할지 알려주지 못합니다. 이진 기준은 실패 시 무슨 일이 있었고 어떻게 대응할지 분명한 행동 신호를 주기 때문에 선호됩니다.

수백만 건의 트레이스를 어떻게 효율적으로 진단하나요?

트레이스를 전부 읽으면 실행보다 비용이 더 들 수 있어, 코드로 점검 가능한 실패 지표와 지능적 세분화로 대표 샘플만 골라 읽는 방식을 씁니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식