DevOps 엔지니어는 여전히 필요할까요? Azure AI가 답변을 바꾸는 배포 가속기를 구축하고 있습니다

솔직히 아무도 이야기하지 않는 변화입니다!

10년 동안 클라우드에 배포한다는 것은 전문적인 작업의 스택(stack)을 의미했습니다. Terraform 모듈, YAML 파이프라인, PowerShell 연결 스크립트, 그리고 '릴리스 작동 방식을 아는' 한 명의 엔지니어가 필요했죠.

하지만 이것은 빠르게 변화하고 있습니다. Azure는 이제 코드, 인프라, 파이프라인, 운영 등 이 모든 계층에 AI를 도입했습니다. 이 요소들이 결합되어 **배포 가속기(deployment accelerator)**를 만듭니다. 즉, 필요한 것을 설명하면 플랫폼이 이를 생성하고, 검증하며, 배포하고, 모니터링까지 수행하는 것입니다.

아래 게시물에서는 오늘날 무엇을 자동화할 수 있는지, Azure에서 이러한 플랫폼을 어떻게 구축할 수 있는지, 그리고 여전히 인간의 개입이 필요한 부분은 무엇인지 다룰 것입니다.

Azure AI로 자동화 가능한 영역

아키텍처: AI 배포 가속기

개발자 요청 (채팅 / 이슈 / PR)
$igackslash$
$ ext{AI 오케스트레이터 (Azure AI Foundry 에이전트)}$
$igackslash$
$
ightarrow$ Azure MCP 서버 (Azure 리소스 읽기/작동)
$
ightarrow$ 템플릿 라이브러리 (Azure Verified Modules, azd templates)
$
ightarrow$ 정책 엔진 (Azure Policy, Checkov, what-if)
$igackslash$
생성된 IaC + 파이프라인 $
ightarrow$ 풀 리퀘스트
$igackslash$
자동 게이트: 린트(lint), 보안 스캔, what-if, 비용 추정
$igackslash$
인간 승인 (프로덕션 환경용)
$igackslash$
GitHub Actions 배포 $
ightarrow$ Azure
$igackslash$
Azure Monitor + SRE 에이전트가 학습 내용을 피드백

단계별: 구축 방법

1. 표준화부터 시작하세요. 승인된 모듈(Bicep 또는 Terraform의 Azure Verified Modules)을 큐레이션된 라이브러리로 만드세요. AI는 사용하도록 허용하는 빌딩 블록만큼 안전합니다.

2. 자유가 아닌 도구를 에이전트에게 제공하세요. Azure AI Foundry를 사용하여 에이전트를 구축하고, 이를 Azure MCP 서버에 연결하여 제한된 권한을 통해 Azure에서 쿼리하고 작동할 수 있도록 하세요.

3. 배포가 아닌 풀 리퀘스트(PR)를 생성하도록 만드세요. 에이전트가 IaC 및 파이프라인 변경 사항을 레포지토리(repo)에 작성합니다. 모든 것이 Git을 통해 흐르므로, 히스토리 관리, 리뷰, 롤백이 가능합니다.

4. 자동화된 게이트를 추가하세요.

• 모든 PR에서 az deployment what-if 또는 terraform plan 실행
• 정책형 코드(Policy-as-code) (Azure Policy, Checkov, Azure용 PSRule)
• 시크릿 및 취약점 스캐닝
• PR 댓글에 비용 추정치 포함

5. ID를 적절하게 사용하세요. GitHub에서 Azure로의 연합 자격 증명(Federated credentials) (OIDC)과 모든 곳에서의 관리 ID(managed identities)를 사용합니다. 저장된 시크릿은 없습니다.

6. 루프를 닫으세요. 배포 및 런타임 원격 측정 데이터(telemetry)를 에이전트로 다시 보내어, 에이전트가 수정 사항을 제안하고, 크기 조정(sizing)을 최적화하며, 복구 PR을 열 수 있게 합니다.

7. 실제 데이터를 통해 게이트가 신뢰할 만하다는 것을 보여줄 때까지 프로덕션 승인은 사람에게 맡기세요.

예시: 프롬프트-투-프로덕션 흐름 (prompt-to-production flow)

역할은 스크립트 작성(writing scripts)에서 플랫폼 엔지니어링, 거버넌스, AI 지원 운영으로 변화합니다. 10명의 스크립트 작가들이 필요하지 않은 팀이라면, 강력한 플랫폼 엔지니어 두 명이 더 필요할 수 있습니다. 반복적인 작업을 하는 사람이 줄어드는 것은 현실적인 결과입니다. '엔지니어가 전혀 필요 없다'는 것은 아닙니다.

왜 이것이 Azure의 순간인가 (Why this is Azure's moment)

Microsoft는 특이한 조합을 소유하고 있습니다: GitHub(코드 및 CI/CD), Azure(인프라), Entra ID(ID), Defender(보안), Azure Monitor(운영), 그리고 Azure AI Foundry(에이전트). 다른 플랫폼 중 이처럼 아이디어부터 실행되고 모니터링되는 워크로드까지 전체 경로를 하나의 ID 및 정책 모델 아래에 두고, AI가 그 모든 영역에 걸쳐 존재하는 곳은 거의 없습니다.

핵심 요약 (Takeaways)

• 표준과 템플릿으로 시작한 다음, 위에 AI를 추가합니다.
• 풀 리퀘스트(pull requests)를 통해 생성하고, 절대 프로덕션에 직접 배포하지 않습니다.
• 정책(policy), 스캐닝, 그리고 무엇이 될지 시뮬레이션(what-if)을 통해 모든 것을 게이트(Gate) 처리합니다.
• 플랫폼 엔지니어링, 보안, AI 오케스트레이션 방향으로 재교육합니다.

질문은 'AI가 DevOps를 대체할 것인가?'가 아닙니다. 질문은 '당신이 그 가속기(accelerator)를 구축하는 사람이 될 것인가, 아니면 그것에 의해 대체되는 사람이 될 것인가?'입니다?

무엇을 가장 먼저 자동화하고 있습니까? 댓글로 알려주세요.

• Shivanna Gundanavar (MLOps 및 클라우드)