2026년 6월 11일 공개된 에이전틱 워크플로우의 정체

GitHub가 2026년 6월 11일 에이전틱 워크플로우(Agentic Workflows)를 퍼블릭 프리뷰(Public Preview, 공개 미리보기)로 전환하며 모든 저장소에서 코딩 에이전트를 실행할 수 있게 했다. 이제 개발자는 채팅창에 질문을 입력해 답을 얻는 수동적 방식에서 벗어나, AI가 스스로 판단해 이슈를 분류하고 답장을 다는 상시 가동 체제를 선택할 수 있다. 이는 AI를 단순한 보조 도구가 아니라 저장소의 운영 프로세스를 함께 수행하는 일원으로 배치하는 변화다.

이 기능은 기존의 코드 자동 완성이나 사이드바 채팅 기능과는 완전히 다른 층위에서 작동한다. 이슈 내용을 읽고 적절한 라벨을 붙이거나, 풀 리퀘스트(PR, 코드 변경 요청)를 검토하고, 일주일 치 커밋 기록을 분석해 유용한 정보를 추출하는 추론 중심의 반복 업무를 수행하는 것이 핵심이다. 작동 방식은 정해진 시간에 실행되는 스케줄 기반 방식과 특정 이벤트가 발생했을 때 즉각 반응하는 이벤트 트리거(Event-triggered) 방식으로 나뉜다. 사람이 키보드 앞에 앉아 코파일럿(Copilot)에게 질문을 던지는 찰나의 순간이 아니라, 저장소 내부에서 발생하는 사건에 따라 AI가 독립적으로 판단하고 움직인다. 단순히 텍스트를 생성하는 수준을 넘어, 읽어 들인 이슈나 커밋 기록에서 유의미한 정보를 찾아내고 이를 바탕으로 실제 저장소에 영향을 주는 유용한 동작을 수행한다.

이러한 구조는 컨티뉴어스 AI(Continuous AI, 소프트웨어 생명주기 전반에 AI를 체계적으로 적용하는 관행)라는 더 큰 전략적 방향성을 가진다. 이는 한 번의 프롬프트로 단발성 결과를 얻는 기존의 AI 활용법을 넘어, 소프트웨어 개발의 전 과정에 AI를 시스템적으로 배치하는 접근법이다. 개별적인 질문과 답변의 반복이 아니라, 전체 워크플로우 속에 AI의 역할을 정의하고 이를 자동화하는 것이 핵심이다. 에이전틱 워크플로우는 이 관점을 실제 구현하는 기술적 메커니즘으로 작동하며, 개발자가 명시적으로 요청하지 않아도 소프트웨어 생명주기 내에서 AI가 지속적으로 가치를 창출하게 만든다.

실무적으로는 새로운 이슈가 생성되는 즉시 이를 읽고 분류하며, 적절한 라벨을 지정한 뒤 짧고 유용한 답변을 게시하는 이슈 분류 에이전트를 구축하는 것이 대표적이다. 이슈의 맥락을 파악하고 적절한 카테고리를 결정하는 작업은 단순한 키워드 매칭으로는 불가능한 추론 중심의 영역이었으나, 이제는 에이전트가 이를 전담하여 처리한다. 이처럼 추론이 필요한 반복 업무를 자동화함으로써 관리자는 단순 분류 작업에 드는 물리적 시간을 줄이고 실제 코드 수정과 같은 고부가가치 업무에 집중할 수 있는 환경을 갖게 된다.

마크다운 지시서가 GitHub Actions로 변환되는 구조

GitHub Copilot을 조직 소유 저장소에서 사용할 경우 더 이상 PAT(개인 액세스 토큰)를 생성해 수동으로 등록하는 번거로운 과정이 필요 없다. 2026년 6월 11일 릴리스를 기점으로 이 인증 단계가 생략되면서 도입 장벽이 낮아졌다. 작업자는 `.github/workflows/` 폴더 안에 마크다운 파일을 생성하는 것으로 에이전트의 역할을 정의한다. 파일 상단에는 워크플로우의 실행 조건과 접근 권한, 그리고 이를 구동할 AI 엔진을 명시하는 YAML 프론트매터(문서 상단 설정 영역)가 배치된다. 그 아래 영역에는 에이전트가 수행해야 할 구체적인 작업 내용을 일상적인 영어 문장으로 작성한다.

이렇게 작성된 마크다운 파일은 `gh-aw`라는 CLI(명령줄 인터페이스) 도구를 통해 컴파일된다. 이 도구는 자연어 지시서를 분석하여 GitHub Actions의 표준 규격인 `.lock.yml` 파일로 변환한다. 여기서 주목할 점은 저장소에 별도의 에이전트 전용 런타임(프로그램 실행 환경)을 추가로 설치하거나 연결할 필요가 없다는 사실이다. 컴파일된 결과물이 결국 일반적인 YAML 워크플로우 파일이기 때문에, 기존의 GitHub Actions 생태계와 완벽하게 호환된다.

실행 단계에서도 새로운 인프라를 구축할 필요 없이 기존 GitHub Actions 러너(작업 수행 서버)를 그대로 활용한다. 저장소에 이미 적용되어 있는 브랜치 보호 규칙이나 조직의 정책 제약 사항 역시 예외 없이 그대로 적용된다. 자연어로 지시를 내리지만 실제 구동은 이미 검증된 기존 인프라 위에서 이루어지므로, 관리자는 AI 에이전트의 동작을 기존 CI/CD 파이프라인의 통제 범위 내에서 관리할 수 있다. 이는 AI 도입 시 가장 우려되는 통제 불능 상태를 기존의 인프라 제약으로 해결한 구조다.

지원하는 AI 엔진은 기본 엔진인 GitHub Copilot을 포함해 Anthropic Claude, OpenAI Codex, Google Gemini 및 커스텀 프로세서까지 폭넓게 지원한다. 다만 개인 저장소를 사용하거나 Claude, Codex와 같이 별도의 API 키가 필요한 외부 엔진을 선택할 때는 해당 키를 저장소 비밀 값으로 등록해야 한다. 이 과정은 GitHub UI에서 직접 수행하거나 CLI를 통해 다음과 같이 설정할 수 있다.

gh aw secrets set

이러한 구조는 엔진 간 전환 비용을 최소화한다. 사용자는 마크다운 상단의 설정값만 수정함으로써 워크플로우 전체를 다시 설계하지 않고도 서로 다른 AI 모델의 추론 성능을 즉각적으로 비교하고 적용할 수 있다.

기존 방식과 달라진 지점

클라우드 코딩 에이전트(Cloud Coding Agent)는 사용자가 이슈나 풀 리퀘스트(PR)에서 수동으로 실행해 특정 기능을 즉시 구현하도록 요청하는 도구다. 반면 에이전틱 워크플로우(Agentic Workflows)는 저장소에 내재된 상시 정책(Standing Policy)으로 작동한다. 매주 월요일마다 지난 한 주간의 이슈 활동을 요약해 보고하거나, 새로운 PR이 오픈될 때마다 보안 취약점을 자동으로 검토하는 설정이 대표적이다. 사용자가 매번 명령어를 입력하거나 버튼을 누르는 것이 아니라, 정의된 스케줄이나 이벤트 트리거에 따라 AI가 정해진 규칙대로 움직이는 구조다.

이 차이는 일회성 업무 위임(Hand off)과 저장소 자체의 자동화 습관(Habit) 구축이라는 관점에서 극명하게 갈린다. 기존의 코딩 에이전트가 사람이 필요할 때만 AI에게 특정 작업을 맡기는 일시적인 외주 형태였다면, 에이전틱 워크플로우는 소프트웨어 생명주기 전반에 AI의 행동 양식을 심는 과정이다. 실무자는 매번 유사한 요청을 위해 프롬프트를 작성하는 반복 수고를 덜 수 있으며, 팀이 합의한 운영 규칙을 저장소 설정으로 명시해 모든 작업에 일관되게 적용할 수 있다. 특정 개인의 숙련도에 의존하던 검토 과정이 저장소의 기본 속성으로 변하는 셈이다.

자동화 범위가 넓어지면 저장소 내의 신뢰할 수 없는 텍스트를 통한 프롬프트 인젝션(Prompt Injection, 외부 입력값으로 AI의 지시사항을 조작하는 공격) 위험이 필연적으로 따라온다. 오픈소스나 협업 저장소의 경우, 이슈 댓글이나 파일 내용에 숨겨진 악의적인 명령어가 에이전트를 조작해 권한 밖의 동작을 수행하게 만들 가능성이 있다. GitHub는 이러한 위험을 단순히 부정하지 않고 5단계의 격리 계층을 구축해 위험을 제어하는 방식을 택했다. 에이전트가 읽는 데이터와 실행하는 동작 사이에 물리적, 논리적 벽을 세워 보안 사고가 전체 시스템으로 확산되는 것을 방지하는 설계다.

실무자가 체감하는 변화는 AI를 도구로 쓰느냐, 시스템의 일부로 쓰느냐의 차이다. 단발성 작업 요청은 빠른 구현에는 유리하지만, 프로젝트 전체의 품질 유지나 반복적인 관리 업무를 자동화하는 데는 한계가 있다. 에이전틱 워크플로우는 관리자가 일일이 챙겨야 했던 리마인드나 기본 검토 업무를 AI가 상시 수행하게 함으로써, 사람이 더 고차원적인 설계와 의사결정에 집중할 수 있는 환경을 만든다. 이는 단순한 생산성 향상을 넘어, 저장소 운영의 표준을 코드로 관리하는 새로운 운영 방식의 도입이다.

Carvana와 마크앤스펜서가 확인한 실무 임팩트와 보안

Carvana는 하나의 저장소를 넘어 여러 저장소를 동시에 수정해야 하는 복잡한 시스템 변경 작업에 에이전틱 워크플로우를 적용했다. 일반적으로 다중 저장소 변경은 의존성 충돌 위험이 커 사람이 일일이 확인해야 하지만, 내장된 제어 기능을 통해 엔지니어링 팀이 안심하고 자동화를 실행할 수 있는 환경을 만들었다. 마크앤스펜서는 개발자들이 스프린트(Sprint, 짧은 개발 주기) 시간의 상당 부분을 소모하던 단순 반복 업무에 주목했다. 이슈 분류(Issue triage, 접수된 이슈를 분석해 담당자와 라벨을 지정하는 작업), 의존성 유지보수, 취약점 보완, 루틴 리뷰 같은 업무를 자동화했다. 특히 재사용 가능한 워크플로우 카탈로그를 구축해, 새로운 저장소를 만들 때마다 자동화 설정을 다시 짜지 않고 기존 카탈로그에서 필요한 기능을 선택해 즉시 적용하는 체계를 갖춰 개발 생산성을 높였다.

Hud.io(깃허브 생태계 도구 개발사)는 에이전트가 풀 리퀘스트(Pull Request, 코드 변경 사항을 반영해달라고 요청하는 제안)를 생성하는 단계는 더 이상 기술적 난제가 아니라고 짚었다. 실무자에게 진짜 어려운 지점은 AI가 내놓은 결과물을 신뢰하여 실제로 병합(Merge) 버튼을 누르는 과정이다. 코드를 생성하는 능력보다 그 결과물이 시스템 전체에 미칠 영향을 확신할 수 있는 신뢰 확보 방안이 더 중요하다는 관점이다. 이는 단순히 AI의 성능을 높이는 문제가 아니라, 결과물이 생성되고 검증되는 전 과정에 보안과 감사가 개입해야 함을 의미한다.

저장소 콘텐츠를 통해 AI의 지시를 조작하는 프롬프트 인젝션(Prompt Injection)을 막기 위해 5단계의 격리 계층을 도입했다. 외부 입력값이 AI의 시스템 프롬프트를 덮어쓰거나 권한 밖의 동작을 유도하지 못하도록 단계별로 필터링하고 격리하는 구조다. 권한 모델 역시 기존의 서드파티 깃허브 액션(GitHub Action) 방식과 차별화했다. 기존 방식이 외부 앱에 광범위한 쓰기 권한을 믿고 부여했다면, 이 모델은 에이전트에게 읽기 권한은 넓게 주되 쓰기 동작은 사용자가 정의한 좁고 감사 가능한 계약(Contract, AI가 수행할 수 있는 동작의 범위와 조건을 명시한 약속)을 통해서만 수행하게 제한했다. 사용자가 허용한 특정 경로와 방식 외에는 어떤 코드 수정도 불가능하며, 모든 쓰기 시도는 기록에 남아 사후 검토가 가능하다. 이는 AI에게 전권을 주는 것이 아니라, 사람이 정한 규칙 안에서만 움직이게 하는 통제 중심의 신뢰 모델이다.

실무 적용을 위한 전제 조건과 설정 단계

GitHub Actions를 활성화하고 저장소 쓰기 권한과 AI 엔진 계정을 확보한 실무자라면 즉시 설정을 시작할 수 있다. 우선 GitHub CLI(명령줄 인터페이스) 2.0.0 버전 이상이 설치되어 있어야 한다. 설치 여부와 버전은 다음 명령어로 확인한다.

gh --version

버전 확인 후 계정 인증이 필요하다면 아래 명령어를 입력해 로그인 절차를 밟는다.

gh auth login

기본 도구를 갖추는 단계는 단순하지만 모든 권한 설정이 선행되어야 에이전트가 실제 코드를 수정하거나 이슈에 답글을 남기는 쓰기 작업이 가능하다.

마크다운 파일을 YAML 형식으로 변환해주는 컴파일 확장 도구를 설치해야 한다. 터미널에서 다음 명령어를 실행한다.

gh extension install github/gh-aw

GitHub CLI 2.90.0 버전 이상을 사용 중이라면 gh aw 명령어를 처음 실행할 때 확장 도구가 자동으로 설치되므로 별도의 오류 없이 진행 가능하다. 도구 설치가 끝나면 초기 설정을 위해 다음 명령어를 실행한다.

gh aw init

이 과정은 자연어로 작성한 지시서를 GitHub Actions가 이해할 수 있는 실행 파일로 바꾸는 환경을 구축하는 작업이다.

Copilot 조직 플랜을 사용하는 기업은 개별 API 키를 관리하는 번거로움을 없앨 수 있다. 조직 관리자가 설정에서 Allow use of Copilot CLI billed to the organization 항목을 활성화하면 비용 청구가 조직 단위로 통합된다. 특히 2026년 6월 11일 이후부터는 개인 액세스 토큰(PAT) 없이 GITHUB_TOKEN만으로 인증이 가능하다. 워크플로우 프론트매터에 다음과 같이 설정한다.

GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

개별 개발자가 토큰 유효기간을 관리하거나 보안 위험을 감수하지 않고 조직의 정책 안에서 AI 워크플로우를 운영할 수 있는 구조다.

설정이 완료되면 Copilot CLI나 VS Code 에이전트 모드에서 프롬프트를 통해 실제 워크플로우를 생성한다. create a new workflow that triage 같은 구체적인 요청을 입력하면 에이전트가 기초 구조를 잡는다. 단순한 코드 작성을 넘어 매주 월요일 이슈 요약처럼 저장소 차원의 상시 정책을 구축하는 것이 이 도구의 핵심 활용법이다. 실무자는 일회성 작업 위임이 아니라 저장소 자체가 스스로 관리되는 자동화 습관을 설계하는 데 집중해야 한다.