코드 리뷰 에이전트의 의견 수용률이 50%에서 100%로 올랐습니다. 그런데 어려운 결함을 지적하지 않게 된 결과라면 개선이라고 할 수 있을까요? 운영 피드백을 에이전트의 다음 설정으로 되돌릴 때 먼저 풀어야 할 문제입니다.

GitHub는 10월 28일 발표에서 Copilot Automations가 실제 결과를 바탕으로 개선안을 제안한다고 설명했습니다. 리뷰 의견의 수용, 이슈 라벨의 수정, 생성한 PR의 병합이 신호가 됩니다. 이 글은 10월 29일 공식 문서 검토와 합성 데이터 계산이며, 실제 저장소에서 Automations를 가동한 후기는 아닙니다.

작업을 수행하는 루프 밖에 평가 루프를 둔다

발표의 코드 리뷰 사례는 PR을 검토하는 자동화와 주간 결과를 분석하는 자동화를 나눕니다. 후자가 프롬프트·도구·트리거 변경을 제안하면 사람이 적용 또는 거부합니다. 제품이 모델 가중치를 재학습한다는 발표로 읽어서는 안 됩니다. 바뀌는 대상은 자동화의 구성입니다.

다음은 이 구조를 운영 설계로 풀어 쓴 자체 도식입니다. GitHub의 내부 구현을 재현한 것은 아닙니다.

구성 v1 → 리뷰 실행 → 개발자의 반응·후속 결과
   ↑                         ↓
승인된 구성 v2 ← 사람의 검토 ← 개선 제안

실행 중 답을 다시 쓰는 재시도와 달리, 다음 작업들의 행동 기준을 바꾼다는 점이 중요합니다. 잘못 선택한 지표가 설정에 반영되면 한 번의 오답보다 넓게 영향을 줄 수 있습니다.

‘수용된 의견 / 남긴 의견’에는 놓친 결함이 없다

리뷰어가 스타일 지적을 받아들이는 이유와 보안 결함을 고치는 이유는 다릅니다. 반대로 타당한 지적도 별도 이슈로 옮겨지거나 범위 문제로 보류될 수 있습니다. 수용 여부는 유용한 관측값이지만 정확성 판정 그 자체는 아닙니다.

이를 작은 데이터로 확인해 보겠습니다. Node.js 18 이상에서 아래 코드를 feedback.mjs로 저장하고 node feedback.mjs를 실행하세요. 패키지·키·네트워크가 필요 없습니다. 열 개의 독립된 결함 사례에 대해 미리 정답이 있다고 가정한 교육용 합성 데이터이며, 제품 성능 수치가 아닙니다.

const cases = Array.from({ length: 10 }, (_, i) => ({
  id: i + 1, defect: true, accepted: i < 5
}));
const policies = {
  broad: () => true,
  easyOnly: row => row.id <= 5
};
for (const [name, emits] of Object.entries(policies)) {
  const comments = cases.filter(emits);
  const accepted = comments.filter(row => row.accepted).length;
  const found = comments.filter(row => row.defect).length;
  const total = cases.filter(row => row.defect).length;
  const rate = comments.length ? `${100 * accepted / comments.length}%` : 'n/a';
  console.log(`${name}: accepted=${accepted}/${comments.length} (${rate}), defects=${found}/${total}`);
}

로컬 실행 결과:

broad: accepted=5/10 (50%), defects=10/10
easyOnly: accepted=5/5 (100%), defects=5/10

후자는 의견 수를 줄여 수용률을 높였지만 결함 절반을 놓쳤습니다. 실제 시스템이 이런 정책을 택한다는 주장이 아니라, 수용률만으로 두 정책을 비교할 수 없음을 보인 것입니다. 예제에는 정상 코드·오탐·심각도·관측 지연이 없으므로 실제 평가에서는 별도로 넣어야 합니다. 의견을 하나도 남기지 않으면 수용률은 0%가 아니라 정의할 수 없는 값입니다.

개선안을 승인할 때 남길 네 가지 근거

다음 표는 제품의 자동 판정 규칙이 아닌, 팀이 제안 검토에 사용할 기준입니다.

검토할 질문 함께 남길 기록
같은 종류의 작업을 비교했는가 구성 버전, 대상 PR, 제외 이유, 난이도·결함 종류
의견을 덜 남겨 지표가 좋아졌는가 의견 수, 수용 수, 검토한 PR 수, 알려진 결함 누락 수
결과를 관측할 시간이 충분했는가 고정 관측 기간과 아직 결론이 안 난 PR·의견
제안이 권한이나 실행량을 넓히는가 추가 도구의 권한, 트리거 변화, 예상 실행 수, 되돌릴 구성

처음에는 정답을 아는 과거 사례에서 이전·후보 구성을 비교하고, 이후 좁은 범위에서 후속 결과를 관찰하는 편이 좋습니다. 평가에 쓴 사례만 계속 최적화하면 그 사례에 맞춘 설정이 될 수 있으므로, 승인 판단용 사례 일부를 개선 과정에서 분리하세요. 이 절차는 제안이며 여기서 제품 A/B 실험을 수행하지 않았습니다.

라벨 분류라면 수정률과 함께 클래스별 누락을, 성능 수정 PR이라면 병합 여부와 함께 회귀 테스트·이후 되돌림을 기록할 수 있습니다. 관측값 하나를 모든 자동화의 공통 점수로 만들 필요는 없습니다. 특히 병합된 PR도 이후 되돌려질 수 있어 “병합 시점 성공”과 “운영 성공”을 구분해야 합니다.

Automations와 Markdown 워크플로는 저장 위치부터 다르다

공식 Automations 문서는 구성이 저장소 코드와 별도로 저장되며 Git 커밋·PR로 관리되지 않는다고 설명합니다. 적용 전후 설정과 제안 이유를 팀의 변경 기록에 남겨야 비교와 롤백의 기준이 생깁니다. Agentic Workflows의 Markdown·lock 파일과 같은 버전 관리 흐름이라고 가정하지 마세요.

같은 문서를 10월 29일 확인한 기준으로 Automations는 유료 Copilot 플랜과 private/internal 저장소를 대상으로 하며 cloud agent 및 조직 정책의 허용이 필요합니다. 실행은 AI Credits와 별도의 Actions 분을 사용합니다. 일·주·월 한도는 이미 실행 중인 작업을 멈추지 않으므로 실행당 한도도 따로 검토해야 합니다. 평가 자동화의 실행 비용까지 예산에 넣으세요. 여기서는 실제 청구액을 측정하지 않았습니다.

도구 변경도 문구 수정과 같은 수준으로 승인해서는 곤란합니다. MCP 도구는 서버 자격증명이 허용하는 외부 시스템까지 접근할 수 있습니다. 개선 제안에 새로운 쓰기 도구가 포함됐다면 수용률 개선 근거와 별도로 접근 범위를 확인해야 합니다.

이 기능을 도입할 첫 조건은 피드백이 많다는 사실보다, 무엇을 성공으로 셀지 설명할 수 있다는 점입니다. 주간 개선안을 받기 전에 현재 구성의 분모·누락·관측 기간부터 기록하세요. 루프 엔지니어링의 실무 가치는 반복 횟수가 아니라 다음 변경을 판단할 근거를 남기는 데 있습니다.

아래 공개 유료 강의는 에이전트의 실행·검증·피드백 루프 설계와 연결됩니다. Copilot Automations 전용 교육을 뜻하지 않으며, 링크는 홍보 링크입니다.