CI/CD에서의 Agentic AI (에이전트형 AI)에 대한 실습 가이드입니다. 실패를 분류(triage)하고, PR(Pull Request)을 생성하며, 오늘 바로 복사해서 사용할 수 있는 실제 GitHub Actions 코드로 문제를 해결하는 자가 치유(self-healing) 파이프라인을 구축해 보세요.

이 포스트에서는 "agentic" AI가 DevOps에 실제로 무엇을 의미하는지 보여드린 후, 실패한 빌드를 자동으로 분류하고 수정 PR을 생성하는 자가 치유 GitHub Actions 파이프라인을 구축하는 과정을 안내하겠습니다. 모든 코드가 포함되어 있습니다. 🚀

모든 DevOps 엔지니어가 알고 있는 새벽 2시의 문제

경험해 보셨을 겁니다. 새벽 2시에 배포가 실패합니다. PagerDuty가 비명을 지릅니다. 노트북으로 비틀거리며 다가가 파이프라인 로그를 열고, 4,000줄의 노이즈를 스크롤하며 발견합니다... 불안정한 테스트(flaky test)와 업데이트된 의존성(dependency)이 빌드를 깨뜨렸다는 사실을 말이죠.

당신의 인생 중 20분이 사라졌습니다. 솔직히 말해서, 꽤나 뻔한 해결책을 찾기 위해서 말입니다.

이제 파이프라인이 이미 문제를 진단하고, 수정 사항이 담긴 Pull Request를 생성했으며, 호출기가 울리기도 전에 한 줄 요약과 함께 당신에게 알림을 보냈다고 상상해 보세요.

그것이 바로 agentic DevOps이며, 올해 CI/CD 분야에서 일어난 가장 큰 변화입니다.

"Agentic"이 실제로 의미하는 것 (과장 없이)

마케팅 용어는 걷어내고 이야기해 봅시다. 파이프라인에는 세 가지 수준의 AI가 있습니다:

Agentic 시스템은 다음과 같은 요소를 갖추고 있습니다:

1. Perception (인지) — 로그, 테스트 출력, diff를 읽습니다.
2. Reasoning (추론) — LLM(대규모 언어 모델)이 무언가가 왜 실패했는지 결정합니다.
3. Tools (도구) — 실제로 무언가를 _수행_할 수 있습니다: PR 생성, 댓글 작성, 작업 재실행, 롤백(roll back).
4. A feedback loop (피드백 루프) — 자신의 행동 결과를 관찰하고 필요에 따라 다시 시도합니다.

직접 만들어 봅시다 🛠️

GitHub Actions를 사용하여 최소한의 기능이지만 실제 작동하는 자가 치유 파이프라인을 구축할 것입니다. 테스트가 실패하면 AI 에이전트는 다음과 같이 동작합니다:

1. 실패 로그를 가져옵니다 (Grab the failure logs)
2. LLM (Large Language Model)에게 근본 원인을 진단하도록 요청합니다 (Ask an LLM to diagnose the root cause)
3. 진단 내용을 PR (Pull Request) 댓글로 게시합니다 (그리고 선택적으로 수정 PR을 생성합니다) (Post a diagnosis as a PR comment (and optionally open a fix PR))

GitHub 저장소와 API 키 (OpenAI, Anthropic, 또는 Copilot/Azure 엔드포인트)만 있으면 됩니다.

flowchart LR
    PR[Pull Request] --> T{test job}
    T -->|pass| M[✅ ready to merge]
...

Step 1: 베이스라인 파이프라인 (The Baseline Pipeline)

여기에는 아직 마법 같은 요소가 없는 일반적인 테스트 워크플로 (workflow)가 있습니다.

# .github/workflows/ci.yml
name: CI

...

Step 2: 실패 포착하기 (Capture the Failure)

핵심 비결은 테스트 작업 (test job)이 실패했을 때만 에이전트를 트리거하는 것입니다. 첫 번째 작업에 의존하며 실패 시에만 실행되는 두 번째 작업을 추가합니다.

  diagnose:
    needs: test
    if: failure()          # 👈 `test`가 실패했을 때만 실행됨
...

Step 3: 에이전트, LLM으로 진단하기 (The Agent, Diagnose With an LLM)

이것이 핵심입니다. 작은 스크립트가 로그를 LLM에 보내고 구조화된 진단을 요청합니다.

// scripts/diagnose.js
import fs from "node:fs";
import OpenAI from "openai";
...

Step 4: 에이전트가 _행동_하게 하기 (Let the Agent Act)

이제 진단 내용을 PR의 댓글로 다시 연결합니다. 이것이

• 자동 수정 PR 열기 (Open a fix PR automatically) :- 에이전트가 패치를 생성하고 peter-evans/create-pull-request를 사용하여 PR을 자동으로 엽니다.
• 불안정한 테스트 자동 재실행 (Auto-rerun flaky tests) :- 에이전트가 'flaky: yes'라고 판단하면, 사람에게 알림(paging)을 보내는 대신 작업을 다시 실행합니다.
• 신뢰도 기반 게이트 설정 (Gate on confidence) :- 신뢰도가 'high'일 때만 자동 행동을 수행하고, 나머지는 에스컬레이션합니다.

      - name: Auto-retry flaky failures
        if: contains(fromJSON(steps.diag.outputs.result).flaky, 'yes')
        run: gh workflow run ci.yml --ref ${{ github.head_ref }}
...

절대 건너뛰어서는 안 될 방화벽 (The Guardrails You Must Not Skip) 🛡️

에이전트 기반 파이프라인은 강력하지만, 그만큼 새로운 공격 표면(attack surface)이 됩니다. 이것을 배포하기 전에 다음 사항들을 고려해야 합니다:

• ✅ 최소 권한 원칙 (Least privilege) :- 에이전트에게 필요한 토큰 범위만 부여합니다 (pull-requests: write, 관리자 권한 아님).
• ✅ 작성 시 인간 개입 루프 (Human-in-the-loop for writes) :- 댓글 달기는 자유롭게 자동화할 수 있지만, 병합(auto-merge)하기 전에는 검토를 거치도록 합니다.
• ✅ 절대로 비밀 정보를 LLM에 주지 않기 (Never feed secrets to the LLM) :- 토큰과 환경 변수(env vars)가 포함된 로그는 전송 전에 반드시 제거합니다(scrub).
• ✅ 파급 효과 제한 (Cap the blast radius) :- 에이전트의 행동에 속도 제한을 걸고, 비상 정지 스위치(kill switch)를 추가합니다 (예: AGENT_ENABLED와 같은 리포지토리 변수).
• ✅ 에이전트가 수행하는 모든 것을 기록하기 (Log everything the agent does) :- 에이전트가 잘못된 결정을 내렸을 때 감사 추적(audit trail)이 필요합니다.

에이전트를 커밋 접근 권한을 가진 주니어 엔지니어처럼 다루세요: 도움이 되고, 빠르지만, 가끔은 자신감 있게 틀릴 수 있습니다.

앞으로의 방향 (Where This Is Going)

2026년 말까지

• 에이전트에게 맡기고 싶을 만큼 가장 짜증 나는 파이프라인 장애는 무엇인가요?
• AI가 main 브랜치에 PR (Pull Request)을 생성하는 것을 신뢰하시겠습니까? 그 이유는 무엇인가요?

이 내용이 도움이 되었다면, DevOpsLesson을 팔로우하고 https://devopslesson.com/을 방문해 주세요.

즐거운 배포 되시길 바랍니다. 🚢