@github은 어제 Issues를 위한 에이전트 자동화 제어(agent automation controls) 기능을 출시했습니다. 에이전트가 실제 업무를 다루기 시작할 때 모든 팀이 직면하게 될 문제, 즉 '그 모든 작은 결정들을 누가 검토할 것인가?'라는 문제를 이 설계가 다루고 있기 때문에 저는 문서를 읽는 데 시간을 좀 투자했습니다.

첫 번째 버전은 상당히 좁은 범위입니다. 에이전트는 이슈에 라벨을 달거나, 유형 또는 필드를 설정하거나, 담당자를 지정하거나, 이슈를 닫을 수 있습니다. 제안된 각 작업은 근거(rationale)와 세 가지 신뢰 수준(confidence levels) 중 하나인 높음(high), 중간(medium), 낮음(low)을 포함할 수 있습니다. 관리자는 신뢰도가 높은 변경 사항은 자동으로 적용되도록 허용하는 한편, 불확실한 변경 사항은 검토를 위해 대기시킬 수 있습니다.

메인테이너(maintainer)는 매일 아침 80개의 명백한 라벨을 승인하고 싶어 하지 않습니다. 또한 에이전트의 신뢰 점수가 우연히 높다는 이유로 유효한 버그를 에이전트가 조용히 닫아버렸다는 사실을 나중에 발견해서도 안 됩니다. 토론창을 봇의 댓글로 채우지 않으면서 작업 옆에 이유를 남기는 방식은 유용한 인터페이스로 느껴집니다.

하지만 신뢰도 라벨(confidence label)은 주의가 필요합니다. 이는 에이전트가 자신이 제안한 작업을 스스로 평가하는 것입니다. GitHub은 이러한 등급이 보정된 확률(calibrated probabilities)이라고 주장하지 않습니다. 높은 신뢰도는 라우팅 정보일 뿐, 해당 변경 사항이 정확하다는 증거가 아닙니다. 팀은 임계값(threshold)을 신뢰하기 전에 여전히 해당 라벨들을 실제 결과와 비교해야 합니다.

GitHub은 또 다른 제한 사항에 대해 이례적일 정도로 솔직합니다. 승인 패널(approval panel)은 워크플로우의 편의를 위한 것이지, 보안 경계(security boundary)가 아닙니다. 만약 에이전트가 이미 이슈를 변경할 수 있는 권한을 가지고 있다면, 제안하는 대신 변경 사항을 직접 적용할 수 있습니다.

더 강력한 제어 기능은 인터페이스 아래에 위치합니다. 각 자동화는 하나의 리포지토리(repository)로 범위가 제한됩니다. 팀은 에이전트가 어떤 도구를 받을지 선택합니다. 쓰기 권한(write access)이 없는 사용자의 이벤트는 기본적으로 무시되어, 공개 이슈 및 풀 리퀘스트(pull requests)로부터 발생하는 프롬프트 인젝션(prompt injection) 공격 표면을 줄여줍니다. 에이전트의 풀 리퀘스트는 스스로를 승인할 수 없으며, 에이전트 작업을 통해 생성된 워크플로우는 여전히 쓰기 권한이 있는 사람의 승인이 필요합니다.

또한 실제 운영 비용이 발생합니다. 자동화는 매시간, 매일, 매주, 혹은 이슈가 열릴 때, 풀 리퀘스트 (Pull Request)가 열릴 때, 또는 새로운 커밋 (Commit)이 도착할 때 실행될 수 있습니다. 매 실행마다 GitHub Actions 분 (minutes)과 AI 크레딧 (AI Credits)이 소비됩니다. 범위가 잘못 설정된 분류 (Triage) 프롬프트는 유용한 팀원이 되기도 전에 반복적인 청구서가 될 수 있습니다.

제가 처음으로 도입할 운영 정책은 지루할 정도로 단순할 것입니다:

에이전트가 레이블 (Label)과 같이 되돌릴 수 있는 메타데이터 변경을 적용하도록 허용합니다. 수백 개의 실제 결정에 대해 에이전트의 신뢰도가 측정될 때까지 할당 (Assignment) 및 이슈 종료 (Issue closure) 권한은 유보합니다. 각 자동화에는 필요한 최소한의 도구 세트만 부여합니다. 특정 이유가 없는 한 외부 기여자 (External contributor)의 이벤트는 차단된 상태로 유지합니다. 비용과 오류율을 함께 검토하십시오. 정리 작업을 유발하는 저렴한 에이전트는 결코 저렴하지 않기 때문입니다.

또한 GitHub가 근거 (Rationale)를 구조화된 이력으로 보존한다는 점이 마음에 듭니다. 충분한 작업이 축적되면, 관리자 (Maintainer)는 자동화가 어디에서 주저하는지, 어디에서 자신 있게 틀리는지, 그리고 어떤 리포지토리 지침 (Repository instructions)을 개선해야 하는지를 감사 (Audit)할 수 있습니다. 이러한 피드백은 기억에 의존해 프롬프트를 반복해서 다시 쓰는 것보다 훨씬 유용합니다.

우리는 에이전트가 코드를 작성할 수 있는지 측정하는 데 많은 시간을 보냈습니다. 이제 저는 더 평범한 벤치마크를 보고 싶습니다. 즉, 팀이 모든 관리자를 전업 감독관으로 만들지 않고도 수천 개의 작은 에이전트 결정을 이해하고, 제약하고, 수정할 수 있는가 하는 점입니다.

GitHub의 첫 번째 답변은 불완전합니다. 하지만 동시에 매우 실용적입니다.