Azure Fundamentals · 강의

처음부터 끝까지의 개발자 작업 흐름

GitHub Actions CI/CD, Azure Container Registry, Container Apps, Application Insights를 연결해 커밋부터 관측 가능한 프로덕션 환경까지 완전한 개발자 내부 순환을 구성합니다.

처음부터 끝까지의 개발자 작업 흐름은(는) CoddyKit의 무료 Azure Fundamentals 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Azure Fundamentals 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Azure Fundamentals 강의에는 총 4개의 강의가 포함되어 있습니다.

현대적인 애저 개발자 순환 과정

현대적인 애저 개발자 워크플로는 소스 제어, CI/CD, 컨테이너 인프라, 관찰 가능성을 연결하여 코드 커밋부터 운영 환경에서의 가시성 확보까지 매끄러운 내부 순환 과정을 구성합니다. 핵심 구성 요소는 다음과 같습니다. GitHub(소스), GitHub 작업(빌드 및 배포 pipeline), 애저 Container 레지스트리(이미지 저장소), 애저 Container Apps(런타임), 애플리케이션 Insights(관찰 가능성)입니다. 각 변경 사항은 모든 단계의 품질 게이트를 거치며 개발자의 노트북에서 운영 환경까지 몇 분 안에 자동으로 이동합니다.

1단계: 소스 제어 및 브랜칭 전략

GitHub 저장소에서 트렁크 기반 개발 또는 GitFlow 브랜칭 전략을 사용하여 코드를 구성하세요. 대부분의 마이크로서비스에서는 트렁크 기반 개발 방식(수명이 짧은 기능 브랜치를 매일 main에 병합)이 통합 충돌을 줄이고 pipeline을 단순하게 유지합니다. 병합 전에 풀 리퀘스트 검토와 CI 검사 통과를 요구하도록 main에 브랜치 보호 규칙을 사용하세요. CODEOWNERS file을 사용하면 중요한 서비스의 변경 사항에 관련 팀의 선임 엔지니어 승인이 필요하도록 할 수 있습니다.

# Example .github/CODEOWNERS
# Require payments-team review for any changes under /src/payments/
/src/payments/ @payments-team
/infrastructure/   @platform-team

2단계: GitHub 작업을 사용한 CI

CI pipeline은 모든 풀 리퀘스트에서 실행됩니다. 일반적인 워크플로는 다음과 같습니다. 코드 체크아웃 → 종속성 복원 → 단위 테스트 실행 → 통합 테스트 실행 → Docker 이미지 빌드 → 애저 Container 레지스트리로 푸시. 추적이 가능하도록 이미지에는 git 커밋 SHA가 태그로 지정됩니다. GitHub 작업에서 애저로 인증할 때는 OIDC 기반 인증(페더레이션된 ID를 통해)을 사용하여 애저 서비스 주체의 비밀을 GitHub에 저장하지 마세요. 이는 CI pipeline을 위한 관리형 ID와 같은 방식입니다.

# .github/workflows/ci.yml (abbreviated)
name: CI
on: [pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login to ACR
        uses: azure/docker-login@v1
        with:
          login-server: myacr.azurecr.io
          username: ${{ secrets.AZURE_CLIENT_ID }}
          password: ${{ secrets.AZURE_CLIENT_SECRET }}
      - name: Build and push image
        run: |
          docker build -t myacr.azurecr.io/myapi:${{ github.sha }} .
          docker push myacr.azurecr.io/myapi:${{ github.sha }}

3단계: STAGING으로 CD

main으로 병합된 후 CI pipeline이 성공하면 CD pipeline이 자동으로 스테이징 환경에 배포합니다. pipeline은 Container App의 이미지 태그를 새로 빌드된 SHA로 업데이트하고, 새 리비전이 정상 상태가 될 때까지 기다린 다음 스테이징 URL에 대해 스모크 테스트를 실행합니다. 스모크 테스트는 중요한 API 엔드포인트가 예상된 응답을 반환하는지 확인합니다. 스모크 테스트가 실패하면 pipeline은 수동 개입 없이 수신 트래픽을 이전 리비전으로 다시 전환하여 롤백합니다.

# CD stage: update Container App to new image
- name: Deploy to staging
  uses: azure/cli@v2
  with:
    azcliversion: latest
    inlineScript: |
      az containerapp update \
        --name myapi-staging \
        --resource-group myRG \
        --image myacr.azurecr.io/myapi:${{ github.sha }}

- name: Run smoke tests
  run: |
    STAGING_URL=$(az containerapp show --name myapi-staging \
      --resource-group myRG \
      --query 'properties.configuration.ingress.fqdn' -o tsv)
    curl -f https://$STAGING_URL/health || exit 1

4단계: 운영 환경 승인 게이트

스테이징 검증이 끝나면 CD pipeline은 승인 게이트에서 일시 중지됩니다. GitHub 작업의 환경 보호 기능을 사용하면 production 환경에 필요한 검토자를 구성할 수 있습니다. pipeline은 대기 중인 엔지니어에게 Slack 알림을 보내며, 대기 중인 엔지니어는 승인하기 전에 스테이징 테스트 결과, 변경 내용, 아직 해결되지 않은 장애를 검토합니다. 승인된 경우에만 pipeline이 동일한 이미지 SHA를 운영 환경에 배포합니다. 이러한 사람 검토 단계는 트래픽이 많거나 규제를 받는 서비스에 매우 중요합니다.

# In GitHub: create 'production' environment with required reviewers
# .github/workflows/cd.yml (abbreviated)
jobs:
  deploy-production:
    environment:
      name: production
      url: https://myapi.contoso.com
    needs: deploy-staging
    steps:
      - name: Deploy to production
        uses: azure/cli@v2
        with:
          inlineScript: |
            az containerapp update \
              --name myapi \
              --resource-group myRG \
              --image myacr.azurecr.io/myapi:${{ github.sha }}

5단계: 운영 환경 관찰 가능성

운영 환경에 배포되면 애플리케이션 Insights가 실시간 가시성을 제공합니다. App Insights SDK(또는 지원되는 런타임의 자동 계측)는 다음을 추적합니다. 요청률, 실패율, 지연 시간(세 가지 핵심 신호), 종속성 호출(데이터베이스, Service Bus, 다른 API로의 호출), 전체 스택 추적이 포함된 예외입니다. 애플리케이션 맵은 서비스 간 호출 관계를 시각화하고, 실패 또는 지연 시간에 가장 크게 기여하는 종속성을 강조 표시합니다.

# Python: Add Application Insights SDK
from opencensus.ext.azure.log_exporter import AzureLogHandler
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer

tracer = Tracer(
  exporter=AzureExporter(connection_string='InstrumentationKey=<key>'),
  sampler=ProbabilitySampler(1.0)
)

배포를 추적 정보에 연결하기

애플리케이션 Insights Annotate를 사용하여 메트릭 차트에 배포 이벤트를 표시하세요. 릴리스 주석이 생성되면(GitHub 작업의 azure/appinsights-annotation Add를 통해) 모든 App Insights 메트릭 차트에 세로선으로 표시됩니다. 이를 통해 지연 시간 급증이나 오류율 증가가 최근 배포와 관련이 있는지 즉시 확인할 수 있으며, 장애 발생 시 평균 진단 시간(MTTD)을 크게 줄일 수 있습니다.

# Create a release annotation in Application Insights
- name: Annotate release in App Insights
  uses: azure/appinsights-annotation@v1
  with:
    appInsightsResourceName: myAppInsights
    resourceGroupName: myRG
    releaseName: '${{ github.run_id }}-${{ github.sha }}'

오류율 급증 시 자동 롤백

복원력이 가장 뛰어난 pipeline을 위해서는 자동 롤백을 구현하세요. 운영 환경에 배포한 후 pipeline은 10분간 기다린 다음 애플리케이션 Insights에서 오류율을 Query합니다. 오류율이 구성 가능한 임계값(예: 5% 초과)을 넘으면 pipeline은 Container App의 수신 트래픽을 이전 리비전으로 100% 전달하도록 업데이트하여 자동으로 롤백합니다. 이 점진적 배포 패턴은 잘못된 배포의 영향 범위를 줄이고, 복잡하거나 민감한 변경 사항도 팀이 확신을 갖고 배포할 수 있도록 합니다.

# Query App Insights error rate via REST (abbreviated)
QUERY='requests | where timestamp > ago(10m) | summarize failed = countif(success == false), total = count() | extend errorRate = round(100.0 * failed / total, 2)'
RESULT=$(az monitor app-insights query \
  --apps myAppInsights \
  --resource-group myRG \
  --analytics-query "$QUERY" \
  --query 'tables[0].rows[0][2]' -o tsv)
if [ $(echo '$RESULT > 5' | bc -l) -eq 1 ]; then
  echo 'Error rate $RESULT% - rolling back!'
  az containerapp ingress traffic set --name myapi --resource-group myRG --revision-weight stable=100
fi

개발자 생산성: 에뮬레이터를 사용한 로컬 개발

개발자는 운영 애저 리소스에 연결하지 않고도 전체 스택을 로컬에서 실행하고 테스트할 수 있어야 합니다. 로컬 Blob 및 큐 저장소에는 애저 Storage 에뮬레이터(Azurite)를, 로컬 데이터베이스 테스트에는 Cosmos DB 에뮬레이터를, 로컬 메시징에는 Service Bus 에뮬레이터를 사용하세요. AZURE_ENVIRONMENT=local 환경 변수는 DefaultAzureCredential이 에뮬레이터를 가리키는 연결 문자열을 사용하도록 전환할 수 있으며, 동일한 코드는 애저에서 관리형 ID를 사용합니다. Docker Compose는 하나의 docker compose up으로 모든 로컬 종속성을 조정합니다.

# docker-compose.yml for local development
services:
  azurite:
    image: mcr.microsoft.com/azure-storage/azurite
    ports:
      - '10000:10000'
      - '10001:10001'
  cosmos-emulator:
    image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator
    ports:
      - '8081:8081'

개발자 워크플로의 보안

개발자 워크플로의 모든 단계에 보안을 통합하세요. Dependabot은 풀 리퀘스트에서 취약한 종속성을 검색하고, GitHub Advanced Security(CodeQL을 사용한 코드 검사)는 SQL 삽입 및 하드코딩된 비밀과 같은 취약성을 탐지합니다. Microsoft Defender for DevOps는 GitHub와 통합되어 코드 변경 사항과 함께 애저 보안 권장 사항을 표시하며, ACR Defender 취약성 검사는 푸시할 때마다 컨테이너 이미지에서 OS 및 애플리케이션 계층 CVE를 확인합니다. 보안 결과는 풀 리퀘스트 댓글로 표시되므로 병합 전에 해결할 수 있습니다.

모든 요소 연결하기

완전한 개발자 워크플로는 지속적인 피드백 순환입니다. 개발자가 코드를 커밋하면 CI가 컨테이너 이미지를 빌드하고 테스트하고, 커밋 SHA를 태그로 사용하여 이미지를 ACR에 푸시합니다. CD는 스테이징에 배포하고 스모크 테스트를 실행하며, 사람이 운영 환경 배포를 승인합니다. 그런 다음 pipeline은 운영 환경에 배포하고 릴리스 주석을 생성하며, 애플리케이션 Insights는 오류율을 모니터링하고 임계값을 초과하면 자동으로 롤백합니다. 동일한 저장소의 코드형 인프라(Bicep 또는 Terraform)는 pipeline, Container App, 모니터링 구성이 애플리케이션 코드와 함께 모두 버전 제어되도록 합니다.

빠른 확인

이 단원에서 다룬 Microsoft 애저 기초(AZ-900) 개념에 대한 이해도를 확인해 보세요.

단원 요약

이 단원에서는 다음을 배웠습니다. 엔드투엔드 개발자 워크플로는 GitHub 소스 제어, GitHub 작업 CI/CD, 애저 Container 레지스트리, Container Apps, 애플리케이션 Insights를 연결합니다. 릴리스 주석은 더 빠른 장애 진단을 위해 배포와 메트릭 변경의 상관관계를 보여 주며, 오류율 Query에 기반한 자동 롤백은 잘못된 배포로 인한 영향 범위를 줄입니다. 다음 단원에서는 클라우드 개념과 애저 아키텍처를 종합적으로 복습하며 시험 준비를 시작합니다.

자주 묻는 질문

“처음부터 끝까지의 개발자 작업 흐름” 강의는 무료인가요?

네 — “처음부터 끝까지의 개발자 작업 흐름” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Azure Fundamentals 강의 전체를 잠금 해제할 수 있습니다. Azure Fundamentals 강의에는 총 4개의 강의가 포함되어 있습니다.

“처음부터 끝까지의 개발자 작업 흐름”에서 뭘 배우나요?

GitHub Actions CI/CD, Azure Container Registry, Container Apps, Application Insights를 연결해 커밋부터 관측 가능한 프로덕션 환경까지 완전한 개발자 내부 순환을 구성합니다. 브라우저에서 직접 실행하는 실습 코드로 Azure Fundamentals을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Azure Fundamentals을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Azure Fundamentals은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“처음부터 끝까지의 개발자 작업 흐름” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Azure Fundamentals 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Azure Fundamentals 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Azure Fundamentals(으)로 돌아가기