GitHub의 새로운 이슈 자동화 기능은 이제 신뢰도(confidence level)와 근거(rationale)를 바탕으로 이슈에 라벨을 달거나, 유형을 지정하거나, 담당자를 할당하거나, 이슈를 닫을 수 있습니다. 이는 작은 UX 개선처럼 들릴 수 있습니다. 하지만 이는 사실 정책 설계(policy-design)의 문제입니다. 모델의 신뢰도는 자신의 출력에 대한 추측인 반면, 권한 부여(authorization)는 시스템이 무엇을 변경할 수 있는지에 대한 규칙입니다.

만약 이러한 개념들을 하나의 임계값(threshold)으로 통합해 버린다면, 운영하기는 쉽지만 관리하기는 어려운 자동화 시스템을 구축하게 될 것입니다. 이 가이드는 프리뷰 기능을 검토 가능한 정책으로 전환하는 방법을 제시합니다. 즉, 작업이 되돌릴 수 있는 경우에만 영향력이 낮은 메타데이터(metadata)를 자동화하고, 모호한 변경 사항은 제안 대기열(suggestion queue)에 유지하며, 보안에 민감한 결정은 실제 제어 경계(control boundary) 뒤에 두는 것입니다.

범위 참고 사항: GitHub는 근거(rationale), 신뢰도(confidence), 승인(approvals)을 퍼블릭 프리뷰(public preview)로 설명합니다. 아래의 예시는 정책 템플릿이며, 해당 프리뷰가 보안 제품이라는 주장이 아닙니다.

GitHub가 실제로 추가한 것

GitHub의 7월 23일 변경 로그(changelog)는 지원되는 이슈 작업에 대해 세 가지 제어 기능을 설명합니다:

• 승인 (Approvals): 자동화 도구가 변경 사항을 즉시 적용하는 대신 제안하도록 요청합니다.
• 신뢰도 (Confidence): 에이전트가 작업의 신뢰도를 높음(high), 중간(medium), 낮음(low)으로 라벨링합니다. 신뢰도가 높은 변경 사항은 자동으로 적용될 수 있으며, 중간 및 낮은 신뢰도의 변경 사항은 제안 상태로 대기합니다.
• 근거 (Rationale): 각 작업은 왜 해당 작업이 제안되었는지 또는 적용되었는지에 대한 이유를 기록합니다.

초기 작업 세트는 라벨, 필드, 이슈 유형, 종료(closing), 그리고 담당자(assignees)를 포함합니다. has:suggestions를 사용하여 대기 중인 항목을 검색할 수 있으며, 저장소 관리자는 신뢰도 임계값을 설정하는 자동화 수준을 구성할 수 있습니다.

중요한 제한 사항은 GitHub 자체의 문구에 있습니다: 승인은 워크플로의 편의 기능일 뿐, 보안 제어(security control)가 아닙니다. 만약 에이전트가 이슈를 변경할 수 있는 권한을 가지고 있다면, 제안하는 대신 변경 사항을 직접 적용할 수 있습니다. 검토 패널은 워크플로를 개선하지만, 권한(permissions), 브랜치 보호(branch protection), 환경 게이트(environment gates) 또는 서버 측 권한 부여(server-side authorization)를 대체하지는 않습니다.

피해야 할 정책적 실수

유혹적인 규칙은 다음과 같습니다:

if confidence == "high":
    apply_change()
else:
...

이 규칙은 신뢰도(confidence)를 마치 권한(permission)인 것처럼 취급합니다. 하지만 그렇지 않습니다. 높은 신뢰도 레이블(label)이라 할지라도 여전히 잘못된 레이블일 수 있으며, 올바르게 분류된 이슈(issue)라 할지라도 닫거나(close) 할당(assign)하기에 안전하지 않을 수 있습니다. 위험 요소는 모델의 오류뿐만이 아닙니다. 오래된 저장소 정책(repository policy), 모호한 소유권(ownership), 중복 보고, 그리고 워크플로(workflow) 작성자가 의도한 것보다 더 광범위한 권한 또한 위험 요소입니다.

더 안전한 의사결정에는 최소한 네 가지 입력값이 필요합니다:

1. 조치 영향도 (Action impact): 변경 사항이 잘못되었을 경우 어떤 일이 발생하는가?
2. 증거 품질 (Evidence quality): 어떤 사실이 해당 조치를 뒷받침하며, 그 사실들이 여전히 최신 상태인가?
3. 가역성 (Reversibility): 유지 관리자(maintainer)가 정보 손실이나 작업 은닉 없이 이를 되돌릴 수 있는가?
4. 권한 (Authority): 이 행위자(actor)와 이 워크플로가 실제로 해당 조치를 수행할 권한이 있는가?

신뢰도는 해당 의사결정 내에서 작업의 우선순위를 정하는 데 도움을 줄 수 있습니다. 하지만 신뢰도가 당신을 대신해 권한 결정을 내려서는 안 됩니다.

실용적인 분류 매트릭스 (Triage matrix)

다음과 같은 정책을 시작점으로 삼고, 사용 중인 이슈 트래커(issue tracker)의 오탐(false positive) 사례를 바탕으로 미세 조정(tune)하십시오:

이 매트릭스는 무해한 주제 레이블과 달리 "닫기(close)" 및 "할당(assign)"을 의도적으로 다르게 취급합니다. 모델은 자신의 분류에 대해 매우 확신할 수 있지만, 중대한 변경을 수행할 권한이나 컨텍스트(context)가 부족할 수 있습니다.

출력값만이 아닌 의도(intent)를 중심으로 워크플로 구성하기

GitHub Agentic Workflows의 경우, 변경 로그(changelog)는 set-issue-type, set-issue-field, add-labels, close-issue, assign-to-agent, assign-to-user와 같이 지원되는 안전한 출력값에 대해 issue-intents: true를 문서화합니다.

최소한의 정책 스케치는 다음과 같을 수 있습니다:

---
name: Triage incoming issues
on:
...

이것은 완전한 보안 경계(security boundary)가 아닙니다. issues: write 권한은 여전히 중대한 영향을 미치며, 정책 코멘트는 강제 집행(enforcement) 수단이 아닙니다. 워크플로(workflow)를 권한 및 리포지토리(repository) 설정에 대해 독립적인 검토가 필요한 오케스트레이터(orchestrator)로 취급하십시오.

제안 사항을 감사 가능하게 만들기 (Make suggestions auditable)

적용되거나 제안된 모든 작업에 대해 다음 항목을 포함하는 작은 기록을 유지하십시오:

• 이슈 번호 및 리포지토리 (repository);
• 작업(action), 이전 값(old value), 제안된 값(proposed value);
• 신뢰도 수준 (confidence level);
• 근거(rationale) 및 사용된 증거 필드 (evidence fields);
• 워크플로 버전 및 가능한 경우 모델/도구 버전;
• 실행 시점의 행위자 권한 (actor permissions);
• 검토자 결정, 타임스탬프(timestamp) 및 모든 수정 사항.

근거(rationale)는 작업과 비교할 수 있을 때만 유용합니다. "이것은 버그처럼 보입니다"라는 말은 할당(assignment)이나 종료(closure)를 위한 근거로 충분하지 않습니다. 더 강력한 기록은 신호(signal)를 명시합니다. 예를 들어: "이슈에 payments/checkout이 언급되었고, 컴포넌트 맵(component map)이 해당 경로를 Payments로 매핑하며, 현재 소유자는 team-payments입니다." 설령 그렇다 하더라도, 해당 기록은 검토를 위한 증거일 뿐, 변경 사항이 승인되었다는 증거는 아닙니다.

리플레이 세트(replay set)로 정책 테스트하기

신뢰도 임계값(confidence threshold)을 변경하기 전에, 실제 이슈를 바탕으로 라벨이 지정된 작은 세트를 만드십시오. 세트를 거대하게 만들기보다는 대표성을 유지하도록 하십시오:

issue_id,expected_action,expected_value,review_required
101,add-label,bug,false
102,assign-team,payments,true
...

프롬프트(prompt), 워크플로(workflow), 모델(model), 라벨 분류 체계(label taxonomy) 또는 소유권 맵(ownership map)을 변경한 후 이를 리플레이(replay)하십시오. 다음의 개별 결과들을 추적하십시오:

• 작업 정밀도 (action precision): 자동화가 작동했을 때, 그 작업이 얼마나 정확했는가?
• 작업 재현율 (action recall): 발생했어야 할 작업을 얼마나 자주 찾아냈는가?
• 기권 품질 (abstention quality): 제안을 건너뛰거나 하지 않았을 때, 비용이 많이 드는 실수를 피했는가?
• 검토 부하 (review load): 제안된 내용 중 노이즈(noise)가 아닌 실행 가능한(actionable) 항목은 얼마나 되었는가?
• 번복률 (reversal rate): 유지 관리자(maintainer)가 적용된 변경 사항을 얼마나 자주 되돌렸는가?

자동으로 처리된 이슈의 비율만을 최적화하지 마십시오. 자동화율이 낮더라도 위험한 오탐 (false positives)을 제거하고 리뷰가 영향력이 큰 작업에 집중할 수 있다면 그것이 더 나은 결과일 수 있습니다.

테스트 세트에 추가할 가치가 있는 실패 모드 (Failure modes)

단순히 정상적인 경로 (happy path)뿐만 아니라, 정책을 시험할 수 있는 사례들을 포함하십시오:

• 오래된(stale) 컴포넌트-소유자 매핑;
• "정식 (canonical)" 이슈가 이미 종료된 중복 이슈;
• 이슈 본문이나 붙여넣은 로그에 포함된 프롬프트 인젝션 (prompt injection);
• 필수 필드가 누락된 높은 신뢰도의 분류;
• 적용해도 무해한 낮은 신뢰도의 제안;
• 신뢰할 수 없는 사용자의 주장으로부터 추론된 보안 라벨;
• 편집 후에 의미가 변하는 이슈;
• 읽기 전용이어야 하지만 쓰기 권한을 가진 워크플로 (workflow).

영향력이 큰 작업의 경우, 권한 경계 (permission boundary)를 별도로 테스트하십시오. 승인 패널 (approval panel)은 워크플로가 의도된 범위를 벗어난 작업을 수행할 수 없는지 검증하는 수단을 대체할 수 없습니다.

짧은 출시 계획 (Rollout plan)

1. 제안 모드 (suggestion mode)로 시작하십시오. has:suggestions를 사용하여 리뷰 대기열을 구축하고 근거 (rationales)를 검토하십시오.
2. 번복률 (reversal rate)과 리뷰 비용을 측정하십시오. 대기열이 바쁘게 느껴진다고 해서 임계값 (threshold)을 높이지 마십시오. 어떤 제안이 실제로 안전한지 검토하십시오.
3. 되돌릴 수 있는 메타데이터부터 먼저 자동화하십시오. 증거와 권한 규칙이 안정될 때까지 이슈 종료 (closure), 할당 (assignment), 에스컬레이션 (escalation), 보안 라벨 (security labels)은 리뷰 대상 상태로 유지하십시오.
4. 정책과 프롬프트 텍스트를 분리하십시오. 소유권, 허용된 라벨, 그리고 작업 경계 (action boundaries)를 버전 관리되는 설정 또는 코드에 저장하십시오.
5. 분류 체계 (taxonomy)나 권한이 변경될 때마다 재테스트하십시오. 라벨 이름 변경이나 팀 변경은 겉보기에 좋아 보이는 자동화를 무효화할 수 있습니다.

체크리스트

• 신뢰도(Confidence)는 권한 부여(Authorization)가 아닌 순위 신호(Ranking signal)로 취급됩니다.
• 각 작업은 명시적인 영향력(Impact) 및 가역성(Reversibility) 등급을 가집니다.
• 워크플로(Workflow) 권한은 가능한 가장 넓은 에이전트(Agent) 역량보다 더 좁게 설정됩니다.
• 제안(Suggestions) 및 적용된 작업은 근거(Rationale)와 증거(Evidence)를 유지합니다.
• 이슈 종료(Closure) 및 할당(Assignment)은 검토 경로(Review path)와 롤백 경로(Rollback path)를 가집니다.
• 프롬프트 인젝션(Prompt-injection), 오래된 데이터(Stale-data), 컨텍스트 누락(Missing-context) 사례가 재생 세트(Replay set)에 포함되어 있습니다.
• 임계값(Threshold) 변경은 정밀도(Precision), 재현율(Recall), 기권(Abstention), 검토 부하(Review load) 및 번복(Reversals)을 기준으로 평가됩니다.
• 개별 제안뿐만 아니라 정책 자체를 사람이 검토합니다.

GitHub의 프리뷰(Preview) 기능은 이슈 자동화를 더 쉽게 검사할 수 있게 해주며, 이는 매우 가치 있는 일입니다. 안전한 해석은 “에이전트가 확신하고 있으니 실행하게 두자”가 아니라, “에이전트가 증거와 함께 제안을 생성했으므로, 이제 영향력, 권한 및 검토에 대해 저장소(Repository)의 정책을 적용하자”가 되어야 합니다.

출처

• GitHub: Agent automation controls in GitHub Issues in public preview
• GitHub Docs: About rationale, confidence, and approvals for issues
• GitHub Docs: About GitHub Agentic Workflows

귀하의 이슈 또는 저장소 자동화에서는 모델의 신뢰도(Confidence)와 실제 권한 부여(Authorization)를 어떻게 분리하고 계십니까?