AI로 CI/CD 장애 원인 분류한 실험
AWS 위에 이중 파이프라인 엔진을 만들고, 일부러 망가뜨린 뒤, Claude Code에게 그 더미 속에서 바늘을 찾게 했을 때 벌어진 일.
개발자와 DevOps 엔지니어만이 아는, 아주 특정한 종류의 공포가 있다.
당신은 클라우드 리소스를 엮느라 며칠을 보냈다. 모든 것이 깔끔해 보인다. 작은 업데이트를 커밋하고, 브랜치를 푸시한 다음, 차 한 잔을 만들러 자리를 뜬다. 다시 돌아왔을 때, 화면은 새빨갛게 비명을 지르고 있다.
빌드 로그를 클릭한다. 4,000줄이나 된다.
밤 11시에 터미널 창을 노려보며 fatal, exit code 1, error 같은 단어를 grep 하면서, 스무 개 작업 중 무엇이 실패했는지, 왜 실패했는지, 그리고 그걸 어떻게 고쳐야 하는지 궁금해하는 자신을 발견하게 된다.
DevOps 여정의 10주 차에, 나는 로그를 뚫어져라 보는 일에 지쳤다고 결심했다.
AI 어시스턴트가 나를 대신해 실패 트리아지라는 포렌식 악몽을 처리할 수 있는지 보고 싶었다. 하지만 동시에 나는 AI 에이전트가 수정 사항을 환각처럼 만들어 내거나, 끝없는 재빌드 루프를 유발하거나, 실수로 실제 클라우드 인프라를 향해 파괴적인 스크립트를 실행해 버리는 공포담도 알고 있었다.
그래서 이번 주에는 Azure DevOps와 함께 AWS 위에 분리된 다단계 배포 시스템을 구축했고, 그다음 AI 진단 파트너를 붙였다. 그리고 단 하나의 철칙을 세웠다.
당신은 범죄 현장을 진단할 수는 있다. 하지만 증거를 건드리거나 차를 운전하는 것은 절대 허용되지 않는다.
이 글은 그것이 어떻게 작동했는지, 어떻게 실패했는지, 그리고 코드 배포의 미래에 대해 무엇을 가르쳐 주었는지에 대한 이야기다.
괴물의 해부학
현실적인 무언가를 만들려면, 장난감 같은 “Hello World” 앱은 사용할 수 없다. 우리의 프로젝트인 EpicBook이라는 도서 플랫폼은 현대적인 프로덕션 구성을 그대로 반영한다.
모든 것을 하나의 지저분한 파이프라인 스크립트에 욱여넣는 대신, 우리는 아키텍처를 두 개의 별도 생명주기로 분리했다:
[ Git Push ] │ ├──► 1. Infrastructure Pipeline (Terraform) ──► VPC, Subnets, EC2, RDS MySQL │ └──► 2. Application Pipeline (Ansible) ──► Nginx, Node.js, Health Checks왜 분리했을까? 클라우드 네트워크는 거의 바뀌지 않지만, 애플리케이션 코드는 일주일에 50번씩 바뀌기 때문이다. 둘을 묶어 버리면 CSS를 살짝 수정하거나 오타를 고칠 때마다 Terraform이 AWS 리소스 30개를 다시 평가하게 된다. 느리고, 비싸고, 위험하다.
프로젝트의 처음 네 단계에 걸쳐, 우리는 이를 체계적으로 구축했다:
- 제로 트러스트 핸드셰이크: 범위가 제한된 IAM 서비스 주체를 사용해 Azure DevOps를 AWS에 연결했다. 즉, 설정 파일에 평문 비밀번호나 영구 액세스 키가 전혀 남지 않도록 했다.
- Infrastructure as Code: Terraform 모듈을 작성해 격리된 Virtual Private Cloud(VPC), 멀티 AZ 서브넷, 보안 그룹, EC2 인스턴스, 그리고 Amazon RDS MySQL 데이터베이스 클러스터를 프로비저닝했다. 한 번의 클릭으로 전체 클라우드 환경을 올리거나 내릴 수 있었다.
- 자동화된 구성: Ansible 플레이북을 사용해 서버를 구성하고, Nginx로 리버스 프록시를 설정하고, Node.js 백엔드를 MySQL에 연결하고, 애플리케이션을 배포했다.
- 경계 강화: 콘솔 출력에서 비밀 정보를 마스킹하고, Terraform 원격 상태를 잠가 동시 실행 충돌을 방지했으며, 애플리케이션이 크래시해도 기반 데이터베이스나 네트워크가 절대 내려가지 않도록 보장했다.
파이프라인이 모두 초록색으로 안정적으로 돌아가기 시작하자, 이제 진짜 실험을 할 차례였다.
황금률: AI는 수집하고, 인간이 행동한다
지금 가장 많이 들리는 유행어는 Agentic AI입니다. 모델이 명령을 실행하고, 코드를 커밋하고, 버그를 자율적으로 수정하게 하는 것이죠.
프로덕션 CI/CD 환경에서 보면, 그건 혁신이라기보다 통제 불능의 AWS 요금 청구서를 부르는 무서운 레시피처럼 들립니다.
AI 에이전트가 Ansible 오류를 잘못 읽고, 잘못된 패치를 푸시하고, 새 빌드를 트리거하고, 다시 실패한 뒤, 당신이 잠든 사이 재귀적 재시도 루프에 빠지면 어떻게 될까요? 데이터베이스 서브넷을 지우는 명령을 실행하면 어떻게 될까요?
저는 혼란이 아니라 속도를 원했습니다. 그래서 엄격한 Human-in-the-Loop 운영 모델을 구현했습니다:
Gather (Bash) ──► Analyze (Claude Code) ──► Human Act (Engineer) ──► Verify (Claude Code)- 결정론적 수집: 전용 Bash 스크립트(
pipeline-triage.sh)를 작성했습니다. 이 스크립트는 Azure DevOps REST API와 통신해 브랜치 전반의 최신 실행 결과를 가져오고, 모든 토큰, 비밀번호, 민감한 헤더를 제거합니다. - 읽기 전용 AI 분석: Claude Code를 사용해 엄격한
CLAUDE.md정책으로 관리되는 사용자 정의 스킬(/pipeline-triage)을 만들었습니다. AI에는 정제된 로그에 대한 읽기 권한만 주고, 쓰기 권한은 전혀 주지 않았습니다. 파일 편집, 커밋 푸시, 파이프라인 트리거는 금지했습니다. - 인간의 조치: AI는 엔지니어에게 무엇이 고장 났는지와 왜 그런지 알려줍니다. 인간은 이를 검토해 타당성을 판단하고, 수정 사항을 적용한 뒤 Run을 누릅니다.
- 검증: AI는 새 실행 결과를 검사해 시스템이 실제로 건강한지 확인합니다.
화재 훈련: 프로덕션을 일부러 망가뜨리기
동반 조종사가 실제로 유용한지, 아니면 그저 눈속임인지 확인하기 위해, 임시 브랜치 drill/pipeline-failure에서 통제된 실패 훈련을 진행했습니다.
핵심 배포 플레이북인 ansible/site.yml을 열어, 가운데에 일부러 폭탄 하나를 떨어뜨렸습니다:
- deliberate_syntax_error: [invalid yaml indentation닫히지 않은 괄호. 잘못된 들여쓰기. 유효하지 않은 YAML.
브랜치를 푸시하고 Application Pipeline을 시작했습니다.
예상대로 화면이 빨갛게 변했습니다. Run 26이 Ansible Syntax Check 단계에서 실패했습니다. 파이프라인은 라이브 AWS 서버에 아무것도 닿기 전에 그 자리에서 멈췄습니다.
● Application Pipeline (ID 5) — Run 26Status: FAILED ❌15초 진단
보통 이쯤이면 로그를 스크롤하기 시작합니다. 하지만 이번에는 터미널에 그대로 머물고 Claude Code를 실행한 뒤 두 단어를 입력했습니다:
/pipeline-triage그다음 일어난 일은 정말 흥미로웠습니다.
일반적인 조언이나 환각으로 가득한 코드 덩어리 대신, Claude Code는 triage 스크립트를 실행하고 정제된 오류 스트림을 파싱한 뒤, 다음과 같이 명확한 분석 결과를 내놓았습니다:
PIPELINE TRIAGE REPORT● Status: FAILED (Exit Code: 2)● Pipeline: Application Pipeline (Run 26)● Category: Build Failure — Ansible Playbook Syntax ErrorExact Evidence:[ERROR]: YAML parsing failed: While parsing a block mapping did not find expected key.19 - deliberate_syntax_error: [invalid yaml indentation##[error]Bash exited with code '4'.Root Cause:The playbook site.yml contains invalid YAML syntax on line 19. The opening bracket '[' is unclosed, causing the parser to fail.Recommended Human Action:1. Open ansible/site.yml at line 19.2. Remove or correct the line: - deliberate_syntax_error: [invalid yaml indentation3. Commit, push to drill/pipeline-failure, and manually trigger the pipeline.스크롤도 없었고, 수동 로그 검색도 없었습니다. 15초도 안 되어 AI가 정확한 줄 번호를 찾아 구문 오류를 식별하고, 파일 자체를 건드리려 하지 않으면서 어떻게 수정해야 하는지 알려줬습니다.
복구 루프
운전대는 제가 잡았습니다:
- 로컬에서
drill/pipeline-failure를 체크아웃했습니다. site.yml의 손상된 줄을 되돌렸습니다.- 수정 사항을 커밋했습니다:
fix: resolve deliberate YAML syntax error in site.yml. - GitHub에 푸시하고 Run 27을 수동으로 시작했습니다.
2분 뒤: Run 27이 선명한 초록색으로 바뀌었습니다.
루프를 마무리하기 위해 /pipeline-triage를 마지막으로 한 번 더 실행했습니다.
보고서는 즉시 반전되었습니다:
PIPELINE TRIAGE REPORT✅ HEALTHY — All checks passing.- Infrastructure Pipeline: Run 20 (Succeeded)- Application Pipeline: Run 27 (Succeeded)- Exit Code: 0필요한 것만 병합하고, 드릴 브랜치를 삭제한 뒤, 작업 공간을 깨끗한 상태로 되돌렸습니다. 주입된 실패에서 검증된 복구까지, 전체 사건은 5분도 걸리지 않았습니다.
DevOps에서 AI에 대해 내가 배운 것
이 시스템을 만드는 과정은 자동화에 대해 제가 생각하는 방식을 바꿔 놓았습니다. 크게 세 가지 교훈이 오래 남았습니다:
1. AI에게는 돋보기를, 조종간은 주지 말자
AI가 자율적일 필요는 없다. 그래야 가치가 생기는 것도 아니다. 거대한 로그에서 오류를 찾아내는 일은 엔지니어링에서 지루한 부분이고, 어떻게 고칠지 결정하고 영향 범위를 검증하는 일은 숙련이 필요한 부분이다. AI를 철저히 읽기 전용으로 유지했더니, 운영 리스크는 0%인 상태에서 속도는 90%나 빨라졌다.
2. 결정론적 코드는 영리한 프롬프트를 이긴다
LLM에게 그냥 “Azure DevOps 파이프라인을 확인해 달라”고 시키면, 누락된 토큰에서 막히고, run ID를 환각하고, 오류 로그를 추측하게 된다. 인증을 처리하고, 정확한 queueTimeDescending 레코드를 가져오고, 비밀 정보를 제거하는 단순한 150줄짜리 Bash 스크립트를 작성하니, AI가 100배 더 날카롭게 작동하는 신뢰할 수 있는 다리가 만들어졌다.
3. 분리는 최고의 보험 정책이다
드릴 중에 애플리케이션 플레이북이 실패했을 때도 데이터베이스는 흔들리지 않았고, VPC는 재설정되지 않았으며, AWS 요금도 치솟지 않았다. 인프라와 애플리케이션 배포를 분리해 둔 덕분에 영향 범위는 사전 점검 한 번으로 제한됐다.
마무리 생각
AI가 DevOps 엔지니어를 대체하러 오는 것은 아니다. 하지만 AI 도구 주변에 안전하고 결정론적인 가드레일을 구축하는 방법을 아는 엔지니어는, 여전히 수천 줄의 터미널 출력물을 손으로 스크롤하는 엔지니어보다 문제를 열 배는 더 빠르게 해결하게 될 것이다.
운영의 미래는 통제되지 않은 오토파일럿이 아니다. 지능적이고 책임감 있는 공동 조종사다.
여러분은 어떻게 생각하나요? 프로덕션 배포 파이프라인에 AI에게 쓰기 권한을 부여하겠나요, 아니면 사람을 끝까지 개입시키겠나요? 아래 댓글에서 이야기해 봅시다.
P.S. 이 글은 Pravin Mishra의 Agentic AI Cohort 3와 함께하는 DevOps Micro Internship의 일부입니다( https://dmi.pravinmishra.com ). DMI 대기자 명단에 등록해 DevOps 여정을 시작할 수 있습니다. ( https://lnkd.in/d735Nsd7 )
내 진행 상황은 여기에서 볼 수 있습니다: ( https://dmi.pravinmishra.com/s/Harietonyeabor.html )
출처
- 원문: https://medium.com/@harietogochukwu/i-let-an-ai-triage-my-broken-ci-cd-pipeline-heres-why-i-refused-to-give-it-the-car-keys-67492adbcf22?source=rss------claude_code-5 (2026-09-21 · Henrietta Ogochukwu Okechukwu)