핵심 요약

  • AI 에이전트 루프는 정해진 시각이나 사건에 따라 프롬프트를 다시 실행하거나, 목표가 검증될 때까지 작업을 이어가는 방식이다.
  • 루프를 설계할 때는 확인할 대상, 실행 주기, 원하는 결과, 문제가 생겼을 때 알릴 사람을 구체적으로 정해야 한다.
  • 모질라는 파일의 위험도와 웹페이지에서의 접근 가능성을 평가해 조사 대상을 고르고, 실제 충돌과 별도 검증을 거쳐 보안 버그를 확인했다.
  • 두 사례 모두 종료·검증 기준과 사람의 검토가 결과의 품질과 실행 비용에 영향을 준다는 점을 보여준다.

반복 실행과 목표 달성은 어떻게 다른가

How I AI의 첫 번째 에피소드에서 클레어는 루프를 프롬프트가 다시 실행되도록 만드는 자동화로 설명한다. 하트비트, 정기 실행(cron), 웹훅처럼 시간이나 사건을 계기로 실행하는 방식에 AI 에이전트를 연결한 것이다.

목표 기반 루프는 정해진 시간이 지나면 끝나는 방식과 다르다. 결과가 검증되거나 에이전트가 더 진행하지 못할 때까지 작업을 이어간다. 따라서 성공 기준이 모호하면 완료 여부를 판단하지 못한 채 토큰을 계속 쓸 수 있다. 클레어는 목표를 작성할 때 Codex가 목표 자체를 쓰도록 하는 방안을 제안한다.

업무 지시처럼 루프를 설계한다

클레어는 루프 설계를 직원에게 업무를 맡기는 과정에 비유한다. 무엇을 확인할지, 얼마나 자주 실행할지, 어떤 결과를 낼지, 문제가 생기면 누구에게 알릴지를 정해야 한다는 뜻이다. 매주 금요일 오전 10시에 병합된 PR을 검토하고 에이전트에 부족한 스킬을 찾으라는 지시는 업무 설명인 동시에 루프의 프롬프트가 된다.

에피소드에서 소개한 Claude Code의 일일 PR 검토 루프는 개별 PR을 맡을 하위 에이전트를 만들어 병합 검사 상태를 추적한다. Codex의 주간 스킬 루프는 부족한 스킬을 찾고, 새 스킬을 검증할 하위 에이전트에게 각각 목표 기반 루프를 맡긴다. 더 단순한 출발점으로는 Claude Cowork에서 매일 아침 일정과 이메일을 확인해 Slack으로 요약을 보내는 예약 작업을 들었다.

루프의 비용도 검증해야 한다

클레어는 성공 기준이 흐리거나 검증 기준이 지나치게 약하면 에이전트가 유의미한 진전 없이 계속 실행될 수 있다고 지적한다. 루프를 만든 뒤에는 실행 비용과 결과물의 품질을 함께 살펴야 한다.

모질라는 어디부터 조사했나

두 번째 에피소드에서 모질라의 브라이언 그린스테드는 팀이 한 달 동안 파이어폭스 보안 수정 423건을 내놓는 데 AI 에이전트를 활용한 과정을 설명한다. 그에 따르면 성과에는 모델뿐 아니라 에이전트에 도구를 제공하고 작업을 검증하는 전용 실행 환경이 기여했다.

파이어폭스처럼 코드가 방대한 프로젝트에서는 조사 순서도 중요했다. 모질라는 언어 모델을 평가자로 써서 각 파일을 메모리 안전성 문제가 있을 가능성과 웹페이지에서 접근하기 쉬운 정도라는 두 기준으로 평가했다. 이를 바탕으로 에이전트가 살펴볼 대상을 우선순위에 놓았다.

실제 충돌과 별도 검증으로 버그를 확인한다

그린스테드에 따르면 에이전트는 한 버그를 재현하기 위해 여러 방법을 끈질기게 시도한다. 성공하기까지 14번의 시도가 필요했던 버그도 있었다.

모질라의 확인 과정은 두 단계다. 먼저 에이전트가 퍼징용 빌드에서 실제 충돌을 일으켜야 한다. 이어 별도의 검증 하위 에이전트가 버그 보고의 타당성과 테스트 전용 설정에만 의존한 결과가 아닌지를 확인한다. 그린스테드는 이 과정을 거쳐 사람에게 전달된 버그 보고에는 잘못된 판정이 거의 없다고 설명했다.

패치에는 사람의 넓은 검토가 필요하다

패치 작성 에이전트는 발견한 취약 지점 한 곳만 고치는 경향이 있었다. 사람인 엔지니어는 패치를 검토하며 코드베이스의 다른 유사 지점도 확인해야 한다고 판단하곤 했다. 에이전트가 특정 작업을 끝내더라도 검토 범위를 넓히는 일은 남는 셈이다.

모질라는 Claude의 에이전트 SDK에서 출발해 작업에 필요한 도구를 연결했다. 그린스테드는 보안 작업에서는 서로 다른 모델과 실행 환경이 다른 취약점을 찾아낼 수 있으므로 여러 접근법을 쓰는 편이 좋다고 봤다. 같은 구조를 성능 최적화에도 적용하는 작업을 진행 중이라고 밝혔다.

결론

두 에피소드의 사례에서 에이전트는 반복 실행만으로 결과를 보장하지 않았다. 맡길 작업과 완료 기준을 정하고, 발견한 문제를 재현·검증한 뒤 사람이 결과를 살피는 과정이 함께 있었다.