액션(Actions)을 통해 길들여지고 있는 에이전트 워크플로우 (Agentic Workflows)

GitHub의 에이전트 워크플로우 (Agentic Workflows) 프리뷰는 사람들이 잘못된 결론에 도달하게 만드는 종류의 헤드라인을 가지고 있습니다.

자연어 마크다운 (Markdown)이 GitHub Actions 워크플로우로 변환될 수 있다는 점입니다.

이것은 마치 "YAML이 사라진다"는 소리처럼 들립니다.

하지만 저는 그것이 흥미로운 이야기는 아니라고 생각합니다.

진짜 흥미로운 이야기는 에이전트가 워크플로우 엔진을 벗어나는 것이 아니라, 오히려 그 안으로 끌려 들어가고 있다는 점입니다.

이것이 중요한 이유는 많은 에이전트 데모들이 여전히 미래가 지루한 기계 장치 위에 떠 있는 스마트한 프로세스인 것처럼 가장하기 때문입니다. 즉, 에이전트가 요청을 이해하고, 저장소 (repo)를 편집하고, 몇 가지 명령어를 실행한 뒤 깔끔한 결과를 돌려준다는 식입니다. 멋진 데모이고, 매우 깔끔합니다.

하지만 프로덕션 엔지니어링 (Production engineering)은 그렇게 깔끔하지 않습니다.

프로덕션 엔지니어링에는 권한 (permissions), 로그 (logs), 러너 그룹 (runner groups), 승인 규칙 (approval rules), 비밀값 (secrets), 방화벽 (firewalls), 예산 (budgets), 이상한 오래된 저장소들, 컴플라이언스 (compliance) 문제, 그리고 유용한 자동화가 예상치 못한 행동을 했을 때 무슨 일이 일어났는지 설명해야 하는 사람이 존재합니다.

따라서 에이전트 워크플로우 (Agentic Workflows)의 형태가 유용한 이유는 바로 데모 버전보다 덜 마법 같기 때문입니다. GitHub은 이미 많은 조직적 신뢰를 담보하고 있는 동일한 CI/CD 세계 안에 에이전트를 배치하고 있습니다.

이것이 올바른 방향입니다.

마크다운 (Markdown)은 컨트롤 플레인 (control plane)이 아니다

매력적인 부분은 개발자가 마크다운 (Markdown)으로 워크플로우를 설명하면 GitHub이 이를 표준 Actions YAML로 변환해 준다는 점입니다.

이는 유용합니다. YAML은 성격 테스트가 아니며, 대부분의 팀은 모든 Actions 구문의 예외 케이스를 암기하는 것보다 더 중요한 일을 해야 합니다.

하지만 마크다운 (Markdown)은 단지 입력 표면 (input surface)일 뿐입니다.

컨트롤 플레인 (control plane)은 여전히 Actions입니다.

이 차이는 매우 중요합니다. 만약 생성된 워크플로우가 일반적인 Actions 워크플로우라면, 기존의 모든 기계 장치들이 여전히 유효할 수 있기 때문입니다. 즉, 저장소 권한 (repository permissions), 러너 선택 (runner selection), 로그 (logs), 환경 (environments), 승인 (approvals), 브랜치 보호 (branch protection), 조직 정책 (organization policy), 그리고 회사가 이미 CI 주변에 구축해 놓은 모든 보안 제어 장치들이 그대로 적용됩니다.

이 지점이 바로 제가 에이전트 도구 (agentic tooling)에 대해 더 낙관적이게 되는 이유입니다.

나쁜 버전의 에이전트(agents)는 모델이 멋진 계획을 세울 수 있다는 이유로, 모든 조직에게 새롭고 병렬적인 실행 모델을 신뢰하라고 요구합니다.

더 나은 버전은 에이전트가 조직이 이미 관리하고 있는 워크플로우 (workflows) 내에서 생성 및 운영을 도울 수 있도록 합니다.

이것은 "에이전트가 이제 더 똑똑해졌으니 CI를 버려라"가 아닙니다.

"에이전트가 CI의 언어를 사용하게 하라"입니다.

기본 설정 (defaults)이 실제로 하는 일

미리보기 상세 정보에는 실제로는 매우 중요한, 지루해 보이는 단어들이 가득합니다: 읽기 전용 기본 설정 (read-only defaults), 샌드박스 컨테이너 (sandboxed containers), 방화벽 규칙 (firewall rules), 출력 검증 (output validation), 그리고 위협 탐지 (threat detection) 등입니다.

이것은 출시 페이지를 꾸미기 위한 장식이 아닙니다. 제품이 가장 어려운 부분을 인정하고 있는 것입니다.

에이전트 워크플로우 (agentic workflow)는 단순한 스크립트가 아닙니다. 그것은 지침을 해석하고, 도구 (tools)를 호출하며, 리포지토리 (repository)를 조사하고, 파일을 생성하며, 다음에 무엇을 할지 결정할 수 있는 자동화 (automation)입니다. 만약 이것이 광범위한 권한과 느슨한 네트워크 경계 (network boundary)를 가지고 실행된다면, 조직은 에이전트 플랫폼을 얻은 것이 아닙니다. 너무 넓은 영향력을 가진, 매우 설득력 있는 CI 작업 (CI job)을 만들어낸 것뿐입니다.

읽기 전용 기본 설정 (read-only default)은 특히 중요합니다.

쓰기 권한 (Write access)은 사고가 아니라 결정이어야 합니다. 비밀 정보 접근 (Secret access)도 결정이어야 합니다. 네트워크 접근 (Network access)도 결정이어야 합니다. 풀 리퀘스트 (pull requests)를 열거나, 이슈 (issues)에 댓글을 달거나, 배포 (deployments)를 트리거하거나, 생성된 아티팩트 (artifacts)를 수정하는 능력은 워크플로우 정의 (workflow definition)에 명시되어야 하며, 리포지토리 소유자에 의해 검토 가능해야 합니다.

이것은 우리가 CI, 패키지 레지스트리 (package registries), 브라우저 확장 프로그램 (browser extensions), 클라우드 IAM, 그리고 쿠버네티스 승인 제어 (Kubernetes admission controls)를 통해 배웠던 것과 동일한 교훈입니다. 기본 경계 (default boundary)가 얼마나 많은 잘못된 아이디어가 사고 (incidents)로 이어질지를 결정합니다.

에이전트는 경계를 덜 중요하게 만드는 것이 아니라, 더 중요하게 만듭니다.

오래된 기계 장치들이 계속 승리한다

현재 AI 개발자 도구에는 재미있는 패턴이 있습니다.

제품의 전면(front)은 새로운 언어를 얻습니다: 에이전트 (agents), 태스크 (tasks), 기술 (skills), 자율성 (autonomy), 자연어 (natural language), 컨텍스트 (context), 추론 (reasoning).

제품의 후면(back)은 오래된 인프라를 계속해서 재발견하고 있습니다: 큐 (queues), 토큰 (tokens), 로그 (logs), 승인 (approvals), 샌드박스 (sandboxes), 지출 제한 (spend limits), 역할 기반 액세스 (role-based access), 그리고 감사 추적 (audit trails).

그것은 위선이 아닙니다. 그것은 성숙함입니다.

장기 지속형 개인 액세스 토큰 (Personal Access Tokens, PATs) 대신 GITHUB_TOKEN을 사용하는 에이전트 워크플로우 (Agentic Workflows)가 좋은 예시입니다. 조직 자동화의 기반으로서 PAT를 여기저기 전달하는 것에 대해 그 누구도 열광해서는 안 됩니다. 그것은 작동할 때는 작동하지만, 작동하지 않게 되는 순간 전형적인 난장판이 됩니다. 즉, 불분명한 소유권, 과도하게 넓은 범위 (scope), 어려운 로테이션 (rotation), 그리고 실제 행위자는 워크플로우임에도 불구하고 특정 개인을 가리키는 감사 추적 (audit trail) 같은 문제들 말입니다.

GITHUB_TOKEN은 화려하지 않습니다. 하지만 이것이야말로 에이전트 시스템에 꼭 필요한, 지루할 정도로 기본적인 식별자 원시 타입 (identity primitive)입니다.

조직의 빌링 (billing), 비용 센터 (cost centers), 그리고 실행당 토큰 제한 (per-run token caps)도 마찬가지입니다.

사람들은 에이전트가 더 큰 작업을 완수할 수 있는지에 대해 이야기하고 싶어 합니다. 좋습니다. 하지만 기업이 수많은 리포지토리 (repositories)에 걸쳐 에이전트 워크플로우를 실행하려 한다면, 질문은 고통스러울 정도로 실무적인 영역으로 넘어갑니다.

• 이 실행에 대한 비용은 누가 지불하는가?
• 어떤 팀이 예산을 소유하는가?
• 토큰 제한 (token cap)에 도달하면 어떻게 되는가?
• 하나의 비싸고 유용한 워크플로우와 열 개의 소음이 심한 워크플로우를 구분할 수 있는가?
• 플랫폼 팀이 모든 리포지토리 소유자에게 매번 부탁하지 않고도 이를 중단시킬 수 있는가?

이것이 바로 진정한 도입의 모습입니다. 단 하나의 놀라운 워크플로우가 아니라, 소유권이 필요한 수백 개의 평범한 워크플로우들 말입니다.

이것은 단순히 더 나은 워크플로우 생성만을 의미하지 않습니다

에이전트 워크플로우를 더 나은 워크플로우 생성기로 취급하는 것은 쉬운 일일 것입니다.

"원하는 것을 설명하면, YAML을 얻는다."

이것은 아마 첫날에는 유용할 것입니다. 하지만 더 흥미로운 유스케이스 (use case)는 문서에서 복사-붙여넣기를 하는 것을 대체하는 것이 아닙니다. 그것은 일상적인 엔지니어링 자동화를 위한 더 높은 수준의 경로를 만드는 것입니다.

리포지토리 소유자가 다음과 같이 말한다고 상상해 보십시오.

"매주 금요일마다, 오래된 의존성 (stale dependencies)을 검사하고, 안전한 업그레이드를 제안하며, 표준 테스트 매트릭스 (test matrix)를 실행하고, 변경 사항의 리스크가 낮을 때만 초안 PR (draft PR)을 생성하라."

또는:

"플래키 테스트 (flaky test)에 라벨이 붙으면, 최근의 실패 사례를 수집하고, 가능성이 높은 파일들을 격리하며, 로그와 의심되는 원인에 대한 링크가 포함된 조사 이슈 (investigation issue) 초안을 작성하라."

또는:

배포 전, 병합된 풀 리퀘스트 (pull requests)를 기준으로 문서 (docs), 변경 로그 (changelog), 마이그레이션 노트 (migration notes), 그리고 예제 (examples)를 확인한 다음, 검토 가능한 패치 (patch)를 준비하라.

이것들은 거창한 공상 과학 영화 속 작업들이 아니다. 소프트웨어 인도 (software delivery) 과정에서 발생하는 성가신 접착제 작업 (glue work)들이다.

중요한 점은 출력물이 여전히 통제된 워크플로우 (governed workflow) 내에 안착한다는 것이다. 에이전트 (agent)는 정체불명의 배경 직원 (background employee)이 되지 않는다. 에이전트는 로그, 제한 사항 (limits), 신원 (identity), 그리고 검토 (review)를 갖춘 하나의 워크플로우 단계 (workflow step)가 된다.

이것은 그리 낭만적이지 않다.

하지만 실제 엔지니어링 조직과의 접점에서 살아남을 가능성은 훨씬 더 높다.

승인 (approval)은 신뢰의 결여가 아니다

GitHub 또한 github-actions[bot] 풀 리퀘스트 (pull requests)에 대한 태도를 변경하여, 쓰기 권한 (write access)이 있는 사용자의 승인 후에 워크플로우 (workflows)를 실행할 수 있도록 했다. 이는 Copilot이 생성한 풀 리퀘스트 (pull requests)가 나아가는 일반적인 방향과 일치한다.

이것은 내가 좋아하는 또 다른 지루한 규칙이다.

자동화는 자신의 작업물을 테스트할 수 있어야 한다. CI를 실행할 수 없는 봇 (bot) 생성 PR은 종종 무용지물이다. 하지만 모든 비밀 정보 (secrets)와 배포 가능한 워크플로우 (deployment-capable workflows)에 자동으로 접근할 수 있는 봇 (bot) 생성 PR은 전혀 다른 차원의 문제다.

합리적인 절충안은 리스크가 변하는 경계 지점에서 인간의 승인을 거치는 것이다.

이것이 모든 에이전트 PR에 위원회가 필요하다는 뜻은 아니다. 생성된 작업물이 파이프라인 (pipeline)의 더 권한이 높은 부분으로 진입하려 할 때, 시스템이 이를 인지해야 한다는 의미다.

인간은 단순히 차이점 (diff)을 감상하기 위해 그곳에 있는 것이 아니다. 인간은 폭발 반경 (blast radius)을 수용하는 것이다.

이 부분이 바로 에이전트 툴링 (agent tooling)이 익숙해져야 할 대목이다. 승인 게이트 (approval gates)는 에이전트에 반대하는 것이 아니다. 그것은 자율적인 작업이 공유 시스템 내부에서 수용 가능해지는 방식이다.

내가 주시할 점

만약 내가 기업 내부에서 이것을 평가한다면, 생성된 YAML이 예쁜지부터 묻지는 않을 것이다.

나는 정책 (policy)이 어디에 나타나는지를 물을 것이다.

플랫폼 팀이 에이전트 워크플로우 (Agentic Workflows)가 사용할 수 있는 러너 그룹 (runner groups)을 정의할 수 있을까요? 조직 (organization), 리포지토리 (repository), 또는 워크플로우 클래스 (workflow class)별로 토큰 제한 (token caps)을 설정할 수 있을까요? 보안 팀이 어떤 워크플로우가 쓰기 권한 (write access)을 요청했는지 확인할 수 있을까요? 로그를 통해 에이전트가 무엇을 읽고, 생성하고, 검증했으며, 무엇을 수행하기를 거부했는지 설명할 수 있을까요? 리포지토리 소유자가 일반적인 Actions 실패와 조기에 중단된 에이전트의 결정 사이의 차이점을 이해할 수 있을까요?

생성된 워크플로우는 단지 하나의 산출물 (artifact)일 뿐입니다.

실행에 관한 증거 (evidence)가 나중에 중요해질 부분입니다.

6개월 후, 누군가는 왜 워크플로우가 PR을 열었는지, 왜 특정 리포지토리를 건너뛰었는지, 왜 예상보다 많은 비용을 썼는지, 또는 왜 파일에 접근할 수 있는 권한이 있었는지 물을 것입니다. 만약 답변이 "에이전트가 결정했습니다"라면, 플랫폼은 실패한 것입니다.

만약 그 답변이 워크플로우 정의, 실행 로그 (run logs), 승인 이력 (approval history), 토큰 예산 (token budget), 그리고 연결된 풀 리퀘스트 (pull request)에 들어있다면, 우리는 적어도 올바른 방향으로 가고 있는 것입니다.

핵심 (the punchline)

에이전트 워크플로우 (Agentic Workflows)가 흥미로운 이유는 이것이 GitHub Actions를 대체하지 않기 때문입니다. 이것은 Actions를 에이전트가 일반적인 엔지니어링 자동화 (engineering automation)가 되는 장소로 만듭니다.

그것이 바로 내가 확신하는 부분입니다.

미래는 프롬프트 (prompt)가 제안하는 무엇이든 수행하는 자유롭게 떠다니는 에이전트들의 군집 (swarm)이 아닙니다. 미래는 워크플로우 엔진 (workflow engines), 범위가 제한된 토큰 (scoped tokens), 러너 정책 (runner policies), 샌드박스 (sandboxes), 승인 (approvals), 로그 (logs), 예산 (budgets), 그리고 검토 가능한 출력물 (reviewable outputs)과 같은 지루한 기계 장치들을 통해 압축된 에이전트들의 모습입니다.

이는 AI 이야기가 마법처럼 남기를 원하는 사람들을 짜증 나게 할 것입니다.

좋습니다.

소프트웨어 인도 (Software delivery)는 이미 강력한 자동화로 가득 차 있습니다. 교훈은 결코 "자동화를 가능한 한 제약 없이 만드시오"가 아니었습니다. 교훈은 유용한 자동화를 관찰 가능하고 (observable), 거버넌스 가능하며 (governable), 팀이 신뢰할 수 있을 만큼 충분히 지루하게 만드는 것이었습니다.

에이전트 워크플로우 (Agentic workflows)는 단지 그 교훈의 다음 버전일 뿐입니다.

마크다운 프롬프트 (Markdown prompt)는 화려한 부분입니다.

Actions 제어 평면 (control plane)이 진짜 이야기입니다.

참고 문헌 (references)

참고 문헌 (references)

• GitHub Changelog: GitHub Agentic Workflows가 이제 Public Preview에 진입했습니다
• GitHub Changelog: 에이전트 워크플로우는 더 이상 개인 액세스 토큰(personal access token)을 필요로 하지 않습니다
• GitHub Changelog: 봇이 생성한 풀 리퀘스트(pull request)는 승인되면 워크플로우를 실행할 수 있습니다
• GitHub Changelog: 셀프 호스팅 러너(self-hosted runners)에 대한 GitHub Actions 최소 버전 강제 적용 일정

프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하는 데 20 USD가 필요하다면, 이 링크를 이용하세요.