Human-in-the-Loop 에이전트 기반 DevOps: GitHub Issues에서 AI 자동화 관리하기

에이전트 기반 (Agentic) DevOps에서 가장 큰 질문은 더 이상 "AI 에이전트가 이것을 자동화할 수 있는가?"가 아닙니다.

그것은 바로 "우리가 에이전트에게 어느 정도의 권한을 부여해야 하며, 에이전트가 확신하지 못할 때는 어떤 일이 발생하는가?"입니다.

이 차이는 매우 중요합니다. 이슈(Issue)에 대한 라벨(Label)을 제안하는 에이전트는 유용합니다. 하지만 잘못된 운영 장애(Production incident)를 확신을 가지고 종료해 버리는 에이전트는 새로운 운영상의 문제를 야기합니다.

2026년 7월 23일, GitHub은 GitHub Issues의 에이전트 자동화 제어 기능 (agent automation controls in GitHub Issues)을 퍼블릭 프리뷰(Public preview)로 발표했습니다. 이 제어 기능은 에이전트가 주도하는 이슈 업데이트에 신뢰 수준(Confidence levels), 근거(Rationales), 그리고 인간의 승인(Human approval) 단계를 추가합니다.

DevOps 팀에게 이것은 또 다른 영리한 프롬프트(Prompt)보다 더 중요합니다. 이는 자동화를 점진적으로 도입하고, 에이전트가 왜 행동하려 하는지 검사하며, 판단이 여전히 중요한 부분에 사람이 개입할 수 있도록 하는 실질적인 방법을 제공합니다.

이 포스트에서는 이 제어 기능이 어떻게 작동하는지, 에이전트 기반 DevOps의 어디에 위치하는지, 그리고 신뢰를 가정하는 것이 아니라 신뢰를 얻을 수 있는 도입 모델을 어떻게 구축할 것인지 탐구할 것입니다.

현재 상태: GitHub Issues의 에이전트 자동화 제어 기능은 퍼블릭 프리뷰 상태이며, 이 글을 작성하는 시점인 2026년 7월 27일 기준으로 변경될 수 있습니다.

자동화의 간극 (The Automation Gap)

전통적인 DevOps 자동화는 대개 결정론적 (Deterministic)입니다:

IF pull request에 "deploy-production" 라벨이 있고
AND 필수 체크(Required checks)를 통과하면
THEN 운영 배포(Production deployment)를 시작한다

규칙은 복잡할 수 있지만, 결과는 예측 가능합니다. 우리는 조건을 테스트할 수 있고, 왜 자동화가 실행되었는지 정확하게 설명할 수 있습니다.

에이전트 기반 자동화는 다릅니다:

이 이슈를 읽으세요.
작성자가 무엇을 필요로 하는지 이해하세요.
적절한 서비스, 심각도(Severity) 및 담당자(Owner)를 선택하세요.
...

이것은 에이전트가 무질서하고 불완전한 언어를 바탕으로 추론할 수 있기 때문에 강력합니다. 하지만 이는 또한 확률론적 (Probabilistic)입니다. 유사한 두 이슈가 서로 다른 권장 사항을 생성할 수 있으며, 확신에 찬 답변이라 할지라도 여전히 틀릴 수 있습니다.

이것은 어색한 간극을 만들어냅니다:

• **전체 수동 분류 (Full manual triage)**는 안전하지만 느리고 반복적입니다.
• **전체 자율 분류 (Full autonomous triage)**는 빠르지만, 조용히 치명적인 실수를 저지를 수 있습니다.
• **Human-in-the-loop 분류 (Human-in-the-loop triage)**는 에이전트가 읽기와 추론을 수행하게 하면서, 사람은 불확실한 작업에 대해 제어권을 유지하도록 합니다.

목표는 모든 자동화 단계에 승인 절차를 삽입하는 것이 아닙니다. 그렇게 되면 엔지니어는 단순히 값비싼 확인 버튼(confirmation button)으로 전락할 뿐입니다. 목표는 신뢰도(confidence), 영향도(impact), 그리고 가역성(reversibility)에 따라 자동화하는 것입니다.

GitHub가 Issues에 추가한 기능

퍼블릭 프리뷰(public preview)에서는 GitHub Agentic Workflows 또는 Copilot 클라우드 에이전트 자동화에 의해 수행된 업데이트에 대해 세 가지 관련 제어 기능을 도입합니다.

1. 신뢰도 (Confidence)

에이전트는 제안된 이슈 작업에 대해 높음 (high), 중간 (medium) 또는 낮음 (low) 신뢰도 수준을 할당할 수 있습니다.

저장소 관리자는 변경 사항이 자동으로 적용되는 데 필요한 최소 신뢰도를 선택합니다. 해당 임계값보다 낮은 작업은 사람이 검토해야 하는 제안 사항으로 남습니다.

이를 통해 유용한 절충안을 만들 수 있습니다:

신뢰도는 정확성(correctness)이 아닙니다. 그것은 라우팅 신호(routing signal)입니다. 신뢰도가 높은 실수도 여전히 실수이므로, 작업의 결과(consequence) 또한 정책에 영향을 미쳐야 합니다.

2. 근거 (Rationale)

지원되는 모든 에이전트 작업에는 왜 해당 작업이 제안되었거나 적용되었는지에 대한 짧은 설명이 포함될 수 있습니다.

단순히 다음과 같이 보이는 대신:

라벨 추가됨: incident

다음과 같은 추론 과정을 볼 수 있습니다:

이슈가 활성 프로덕션 장애를 보고하고 상태 확인(health-check) 실패 결과를 포함하고 있으므로 incident를 제안함.

그러한 설명은 검토자가 더 빠르게 결정을 내릴 수 있도록 돕고, 이슈 타임라인에 더 유용한 기록을 남깁니다. 또한 동일한 오해가 반복적으로 나타날 때, 팀이 프롬프트(prompt)와 자동화 규칙을 개선할 수 있는 근거를 제공합니다.

3. 제안 및 승인 (Suggestions and approvals)

설정된 자동화 임계값(automation threshold)을 충족하지 못하는 변경 사항은 이슈(issue)에 제안(suggestions)으로 나타납니다. 검토자(Reviewers)는 이를 개별적으로 수락하거나 거부할 수 있으며, 여러 제안을 한꺼번에 처리할 수도 있습니다.

출시 시점에 제어 기능은 다음과 같은 에이전트 작업(agent actions)을 지원합니다:

• 레이블(labels) 변경
• 이슈 필드(issue fields) 설정
• 이슈 유형(issue type) 변경
• 사용자 및 에이전트 할당 또는 할당 해제
• 이슈 종료(closing issues)

has:suggestions 이슈 검색 한정자(qualifier)를 사용하면 유지 관리자(maintainers)가 사람의 검토를 기다리는 이슈를 쉽게 찾을 수 있습니다.

GitHub는 또한 REST 및 GraphQL API를 통해 이러한 기능을 제공하므로, 동일한 모델을 기반으로 승인 대기열(approval queues)과 보고(reporting) 시스템을 구축하는 것이 가능합니다.

Human-in-the-Loop 흐름 (The Human-in-the-Loop Flow)

잘 설계된 이슈 자동화는 관찰(observation), 권고(recommendation), 권한(authority)을 분리해야 합니다:

새 이슈 또는 업데이트된 이슈
        |
        v
...

이 흐름에는 두 가지 중요한 개념이 있습니다.

첫째, 에이전트는 단순히 답변만을 출력하는 것이 아닙니다. 검토에 충분한 문맥(context)을 포함한 **작업 제안(action proposal)**을 생성합니다.

둘째, 임계값(threshold)은 보편적이지 않습니다. 플랫폼 팀은 높은 신뢰도(high confidence)를 가진 문서화 레이블(documentation label)은 자동으로 적용할 수 있지만, 이슈를 종료하거나 온콜 엔지니어(on-call engineer)를 할당하기 전에는 항상 승인을 요구할 수 있습니다.

이는 AI에 대한 열정 때문이 아니라, 리스크(risk)에 기반한 정책입니다.

실무적인 DevOps 시나리오 (A Practical DevOps Scenario)

매일 다음과 같은 이슈들이 접수되는 내부 플랫폼 저장소(internal platform repository)를 상상해 보십시오:

• 배포 워크플로(deployment workflow) 시간 초과
• 개발자가 테스트 클러스터(test cluster)에 인증할 수 없음
• Terraform 문서가 최신 상태가 아님
• 운영 서비스(production service)에서 에러가 발생함
• 요청이 기존 백로그 항목(backlog item)과 중복됨

에이전트는 각 이슈, 저장소 메타데이터(repository metadata) 및 이전 사례들을 조사한 후, 다음과 같이 제안할 수 있습니다:

위험한 작업이 반드시 기술적으로 가장 복잡한 작업은 아니라는 점에 주목하십시오. 이슈를 종료(Closing)하는 것은 실행하기 쉽지만 실제 작업 내용을 숨길 수 있습니다. 담당자를 할당(Assigning)하는 것 역시 쉽지만, 잘못된 온콜(on-call) 엔지니어를 반복적으로 할당하면 노이즈가 발생하고 신뢰가 무너집니다.

Human-in-the-loop 설계는 구현의 난이도가 아니라 **결과(consequence)**에 관한 것입니다.

자율성 스위치가 아닌 신뢰 사다리(Trust Ladder)를 구축하라

팀들은 종종 AI 자동화를 마치 '켜짐(on)' 또는 '꺼짐(off)'이라는 두 가지 설정만 있는 것처럼 논의하곤 합니다. 더 안전한 모델은 신뢰 사다리(trust ladder)입니다.

레벨 1: 관찰 (Observe)

에이전트가 이슈를 분석하고 보고서를 생성하지만, 아무것도 변경하지는 않습니다.

이 단계에서는 에이전트의 권장 사항을 유지 관리자(maintainer)가 실제로 내리는 결정과 비교하는 데 사용하십시오. 오탐(false positives), 모호한 카테고리, 누락된 저장소 컨텍스트(repository context) 등을 기록하십시오.

레벨 2: 제안 (Suggest)

에이전트가 레이블(labels), 필드(fields), 할당(assignments) 또는 종료(closures)를 제안합니다. 인간이 모든 작업을 검토합니다.

이 단계에서는 근거(rationales)가 가치를 발휘합니다. 검토자는 다음 질문에 답할 수 있어야 합니다:

• 에이전트가 올바른 증거를 식별했는가?
• 신뢰도(confidence)를 믿을 수 있는가?
• 제안된 작업이 되돌릴 수 있는가(reversible)?
• 우리라면 동일한 결정을 내렸겠는가?

레벨 3: 저위험 작업 자동 적용 (Auto-apply low-risk actions)

광범위한 영역 레이블을 추가하는 것과 같이 신뢰도가 높고 되돌릴 수 있는 메타데이터 변경을 허용합니다.

거부되거나 수정된 작업을 계속 모니터링하십시오. 만약 유지 관리자가 자동화된 레이블을 일상적으로 취소(undo)한다면, 시스템은 해당 수준의 권한을 얻지 못한 것입니다.

레벨 4: 증거에 따른 확장 (Expand by evidence)

성능과 운영 영향(operational impact)을 측정한 후에만 점진적으로 작업을 추가하십시오.

모든 작업을 한꺼번에 승격시키지 마십시오. 귀하의 자동화 시스템은 문서 이슈를 식별하는 데는 탁월하지만, 중복(duplicates)을 인식하는 데는 미흡할 수 있습니다. 이러한 역량들은 서로 다른 정책을 적용받아야 합니다.

레벨 5: 엄격한 승인 경계 유지 (Retain hard approval boundaries)

에이전트가 뛰어난 성능을 보이더라도 일부 결정은 인간의 소유로 남겨두어야 합니다:

• 보안 또는 인시던트 리포트(incident reports) 종료
• 활성 프로덕션 이벤트(production events)의 심각도(severity) 변경
• 권한이 필요한 복구 작업(remediation work) 할당
• 배포(deployments) 또는 인프라 변경 트리거
• 컴플라이언스(compliance) 또는 고객 영향이 있는 결정 수행

성숙함은 최대의 자율성을 의미하지 않습니다. 성숙함이란 어떤 권한을 절대 암묵적으로 위임해서는 안 되는지 아는 것입니다.

신뢰도(Confidence)는 신호이지, 통제 수단이 아니다

이 부분은 특별한 주의가 필요합니다.

GitHub는 승인(approval) 경험을 보안 경계(security boundary)가 아닌 워크플로의 편의 기능으로 설명합니다. 만약 자동화 도구가 이슈(issue)를 직접 업데이트할 수 있는 권한을 가지고 있다면, 제안 패널(suggestion panel)이 있다고 해서 그 근저에 있는 권한 자체가 사라지는 것은 아닙니다.

즉, 신뢰도 임계값(confidence thresholds)과 승인은 더 넓은 보안 모델 내에 위치해야 합니다:

• 실질적으로 필요한 최소한의 리포지토리(repository) 권한만 부여할 것
• 신뢰할 수 없는 이슈 콘텐츠를 비밀 정보(secrets)로부터 격리할 것
• 에이전트가 사용할 수 있는 도구를 제한할 것
• 작업 내용과 근거(rationales)를 기록할 것
• 코드 및 배포를 위해 브랜치 보호(branch protection) 및 환경 보호(environment protection)를 사용할 것
• 프롬프트(prompts)를 액세스 제어(access control)가 아닌 가이드라인으로 취급할 것
• 중대한 변경 사항에 대해서는 독립적인 검토(review)를 유지할 것

소스 파일이 그러하듯, 이슈 댓글(issue comment)에도 프롬프트 인젝션(prompt injection)이 포함될 수 있습니다. 악의적이거나 실수로 입력된 지침은 에이전트를 리다이렉트하거나, 가용한 컨텍스트(context)를 노출시키거나, 관련 없는 작업을 수행하도록 설득하려 할 수 있습니다.

인간의 검토는 리스크를 줄여주지만, 권한 설계(permission design)는 발생 가능한 피해를 제한합니다.

에이전트 자동화 제어(Agent Automation Controls) vs 에이전트 워크플로(Agentic Workflows)

이 명칭들은 혼동하기 쉬우므로 다음과 같이 구분합니다:

제어(controls)는 에이전트가 주도하는 이슈 변경에 대한 거버넌스(governance) 계층입니다. 에이전트 워크플로(Agentic Workflows)와 클라우드 에이전트 자동화는 그러한 변경을 생성하는 방법입니다.

이는 익숙한 DevOps 패턴과 유사합니다. 배포 워크플로(deployment workflow)가 작업을 수행하는 동안, 환경 보호 규칙(environment protection rule)은 해당 작업의 진행 여부를 제어합니다. 구현(implementation)과 결정 경계(decision boundary)는 서로 연관되어 있지만, 동일한 것은 아닙니다.

인간의 검토가 실패할 수 있는 지점

사람을 추가한다고 해서 시스템이 자동으로 안전해지는 것은 아닙니다. 잘못 설계된 검토 프로세스는 그 자체로 실패 모드(failure modes)를 만들어냅니다.

승인 피로 (Approval fatigue)

모든 명백한 레이블(label)이 승인을 기다려야 한다면, 유지 관리자(maintainers)는 내용을 읽지 않고 제안을 수락하게 될 것입니다.

대응책: 검증된 저영향(low-impact) 작업은 자동으로 적용(auto-apply)하고, 모호함이나 결과적 영향이 큰 작업에 대해서만 주의를 집중하도록 합니다.

자동화 편향 (Automation bias)

검토자는 에이전트(agent)로부터 전달되었고 세련된 근거(rationale)를 포함하고 있다는 이유로, 자신감 있게 제시된 권장 사항을 신뢰할 수 있습니다.

대응책: 검토자에게 문장의 품질이 아니라, 인용된 증거(evidence)를 검증하도록 요청하십시오.

오래된 제안 (Stale suggestions)

권장 사항이 대기열(queue)에서 기다리는 동안 이슈(issue)의 내용이 변경될 수 있습니다.

대응책: 의미 있는 이슈 업데이트가 발생한 후에는 제안을 재평가하고, 오래된 컨텍스트(context)를 기반으로 결정을 내리는 것을 피하십시오.

보이지 않는 수정 (Invisible corrections)

팀원들이 에이전트가 틀렸다는 기록을 남기지 않은 채, 잘못된 레이블을 수동으로 수정할 수 있습니다.

대응책: 거부(declined), 되돌리기(reverted), 수정(corrected)된 작업을 추적하여 자동화의 품질을 측정할 수 있도록 합니다.

권한 남용 (Authority creep)

자동화가 분류(triage) 작업으로 시작했다가, 편리하다는 이유로 점차 더 넓은 쓰기 권한(write permissions)을 얻게 되는 현상입니다.

대응책: 프로덕션 워크플로(production workflows)에 사용되는 것과 동일한 변경 제어 프로세스의 일부로서 권한과 작업 범위(action scope)를 검토하십시오.

더 큰 DevOps 교훈

에이전트 기반 DevOps(Agentic DevOps)는 자동화의 형태를 변화시킵니다.

우리는 명시적인 명령을 실행하는 워크플로에서, 의도(intent)를 해석하고 행동을 선택하는 시스템으로 이동하고 있습니다. 이는 자동화를 더 유능하게 만들지만, 동시에 불확실성(uncertainty)이 가시화되어야 함을 의미합니다.

신뢰도(confidence), 근거(rationale), 그리고 승인(approval)은 숨겨진 모델의 판단을 검사 가능한 워크플로로 전환해주기 때문에 유용합니다:

• 신뢰도(confidence)는 의사결정 경로를 지정하는 데 도움을 줍니다.
• 근거(rationale)는 검토자가 이를 이해하는 데 도움을 줍니다.
• 승인(approval)은 권한을 적절한 사람에게 유지시켜 줍니다.
• 감사 이력(audit history)은 팀이 시스템을 개선하는 데 도움을 줍니다.

이 중 그 어떤 것도 권한(permissions), 샌드박싱(sandboxing), 보호된 환경(protected environments) 또는 독립적인 검토(independent review)를 대체하지 않습니다. 이들은 그러한 통제 수단들을 보완합니다.

최고의 에이전트 기반(agentic) DevOps 시스템은 모든 루프에서 인간을 제거하는 시스템이 아닙니다. 맥락(context), 책임(accountability), 그리고 판단(judgement)이 중요한 정확한 지점에는 사람을 다시 참여시키면서, 반복적인 작업으로부터 사람을 해방시키는 시스템입니다.

제안(suggestions)부터 시작하세요. 수정 사항을 측정하세요. 자동화가 여러분의 신뢰를 얻었을 때만 확장하세요.

저자

[

](/pwd9000)

Marcel.Lupo팔로우

DevTech 분야의 Microsoft MVP - DevOps | DevOps 아키텍트 | Microsoft 기술, 에이전트 기반 AI (Agentic AI), Azure에서의 IaC 및 자동화에 집중하는 기술 강연자. GitHub에서 저를 찾아보세요: https://github.com/Pwd9000-ML