Day 1 - CodeCommit과 CodeBuild: AWS가 그린 CI/CD의 첫 두 칸

CI/CD라는 단어를 처음 만난 개발자들은 보통 "Jenkins 한 번 깔아본 적 있어요" 정도로 시작한다. 그러다가 빌드 서버가 죽거나, 빌드 큐가 밀리거나, 빌드 스크립트가 한 사람의 노트북에서만 돌아가는 상황을 한 번 겪고 나면 "이걸 누군가 대신 해줬으면" 하는 마음이 자연스레 든다. AWS의 Code* 시리즈는 정확히 그 지점을 노린 서비스 묶음이다. CodeCommit이 Git 호스팅을, CodeBuild가 빌드 실행을, CodePipeline이 흐름 오케스트레이션을, CodeDeploy가 배포를 맡는다. 이번 글은 그 4단 파이프라인의 앞쪽 두 칸 — 소스 보관과 빌드 실행 — 을 깊이 들여다본다.

DVA-C02 시험에서 이 두 서비스가 차지하는 비중은 적지 않다. 시험은 더 이상 CodeCommit의 신규 가입을 받지 않는 2024년 7월 이후 정책을 알면서도, 여전히 동작 원리·인증 방식·buildspec.yml 문법을 지속적으로 묻는다. 이유는 단순하다 — AWS의 IAM 통합 Git 모델과 buildspec.yml 단계 구조는 시험 합격 이후 GitHub Actions·GitLab CI·Bitbucket Pipelines 등 어디로 가도 거의 같은 개념으로 재사용되는 표준 어휘이기 때문이다.

CodeCommit이 풀려고 한 문제

2015년 7월 CodeCommit이 출시됐을 때, GitHub Enterprise는 self-hosted 라이선스 비용 부담이 컸고 GitLab은 막 self-hosted 시장에 진입하던 시기였다. AWS가 보기에 "기업 내부 코드를 외부 SaaS에 두는 게 컴플라이언스상 곤란하다"는 금융·공공·헬스케어 고객이 분명히 존재했다. CodeCommit은 "AWS 계정 안에서, IAM으로 인증하고, KMS로 암호화하고, CloudTrail로 감사 로그가 남는 Git 저장소"를 약속하며 등장했다.

핵심 가치 제안은 세 가지였다. ① 무한 확장: 저장소 크기·파일 수 제한이 (사실상) 없다. ② IAM 통합: 별도 사용자 시스템 없이 기존 IAM 정책으로 push/pull 권한 제어. ③ 자동 암호화: 전송(HTTPS/SSH) + 저장(KMS) 양쪽 모두 기본 활성화.

Git 프로토콜은 원래 SSH·HTTPS·git:// 세 가지 wire protocol을 지원한다. CodeCommit은 git:// (port 9418)을 의도적으로 막았다. 이유는 git:// 가 인증과 암호화를 모두 제공하지 않는 평문 프로토콜이기 때문이다. LAN 환경의 read-only 미러링을 위해 설계된 프로토콜이라 클라우드 환경에서는 보안 모델이 깨진다. CodeCommit이 SSH + HTTPS(SigV4) 두 가지만 지원하는 것은 이런 위협 모델 분석의 결과다.

CodeCommit의 IAM 통합은 단순히 "사용자가 IAM에 있다"가 아니라 각 git operation(push, pull, branch 생성)이 IAM action에 1:1로 매핑된다는 의미다. 예를 들어 git push origin main은 내부적으로 codecommit:GitPush action을 호출하고, 여기에 aws:ResourceTag/branch=main 조건을 걸면 특정 사용자가 main 브랜치에 직접 push 못 하게 막을 수 있다. GitHub의 branch protection rule과 달리 IAM 레이어에서 강제할 수 있다는 점이 차별점이었다.

# IAM 정책으로 main 브랜치 직접 push 차단
{
  "Effect": "Deny",
  "Action": "codecommit:GitPush",
  "Resource": "arn:aws:codecommit:ap-northeast-2:111122223333:my-repo",
  "Condition": {
    "StringEqualsIfExists": {
      "codecommit:References": ["refs/heads/main"]
    },
    "Null": {
      "codecommit:References": false
    }
  }
}

그러나 2024년 7월 25일, AWS는 CodeCommit의 신규 고객 가입을 중단했다. 기존 고객은 계속 쓸 수 있고 시험 범위에도 남아 있다. GitHub(2018년 Microsoft 인수), GitLab의 SaaS 점유율 확대, 그리고 GitHub Actions가 CI까지 흡수하면서 "Git 호스팅만 따로 하는 서비스"의 수요가 줄어든 것이 배경이다.

AWS는 CodeCommit, CodeBuild, CodePipeline 등을 하나로 묶는 통합 DevOps 플랫폼 CodeCatalyst도 내놓았다.

CodeCommit의 세 가지 인증 방식

CodeCommit으로 git을 쓰려면 인증을 통과해야 한다. 세 가지 방식이 있으며 헷갈리기 쉬우므로 차이를 정리한다.

"CodeCommit에 사용자명/비밀번호로 직접 로그인할 수 있는가?"라는 질문의 답은 No다. HTTPS Git Credentials는 IAM이 발급한 별도의 username/password이지 IAM 콘솔 로그인용 비밀번호가 아니다. 즉 IAM 사용자에게 "콘솔 패스워드만 있고 Git Credentials 발급 안 함"이면 Git push 불가. "사용자명/비밀번호 직접 입력" 같은 보기는 오답이다.

# 1) SSH 방식
ssh-keygen -t ed25519 -C "dev@example.com"
# 생성된 public key를 IAM 사용자 → Security credentials → SSH keys for AWS CodeCommit 에 업로드
# 반환된 SSH Key ID(예: APKAEIBAERJR2EXAMPLE)를 SSH config에 매핑
 
# ~/.ssh/config
Host git-codecommit.*.amazonaws.com
  User APKAEIBAERJR2EXAMPLE
  IdentityFile ~/.ssh/codecommit_rsa
 
git clone ssh://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/my-repo
 
# 2) Credential Helper (EC2/CodeBuild에서 사용)
git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true
git clone https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/my-repo
# 내부적으로 aws-cli가 SigV4 서명을 만들어 매번 새로운 임시 비밀번호처럼 git에 전달

Credential Helper의 동작은 SigV4 서명 그 자체다. git이 HTTPS basic auth 헤더로 username/password를 보낼 때, helper는 username을 IAM access key ID로, password를 AWS4-HMAC-SHA256 알고리즘으로 만든 서명 문자열로 채워 넣는다. 서명에는 timestamp가 포함되므로 매 요청마다 다른 password가 만들어진다. 이 덕분에 EC2 인스턴스 프로파일이나 Lambda 실행 역할로 CodeCommit에 자동 접근할 수 있다. 임시 자격 증명이 회전돼도 helper가 매번 새로 서명한다.

CodeBuild의 내부 구조: Docker 위에 빌드 환경 만들기

CodeBuild는 한 마디로 "buildspec.yml에 적힌 명령어를, AWS가 띄워주는 컨테이너 안에서, 빌드가 끝나면 사라지는 방식으로 실행"하는 서비스다. 그 한 마디 안에 몇 가지 설계 결정이 숨어 있다.

첫째, 각 빌드는 fresh container에서 실행된다. 빌드 호스트를 재사용하면 의존성 캐시는 빠르지만 환경 오염(다른 빌드가 남긴 파일, 환경변수)이 발생한다. CodeBuild는 격리를 우선시해 매 빌드마다 새 컨테이너를 부팅한다. 그 대가가 startup latency(보통 10-30초)다. Jenkins agent의 "long-running worker" 모델과 정반대다.

둘째, 빌드 이미지는 AWS managed image 또는 custom ECR 이미지다. AWS managed는 Amazon Linux 2 / Ubuntu 기반으로 주요 런타임(Node, Python, Java, Go, .NET, Docker 등)이 미리 깔려 있다. Custom 이미지를 쓰면 ECR에서 pull 받아 빌드 시작 — 이 pull 시간이 추가되므로 작은 base image 선택이 중요하다.

셋째, 컴퓨팅 옵션이 매우 다양하다.

CodeBuild가 2023년 말 발표한 Lambda-based compute 옵션은 빌드 startup을 1초 미만으로 단축한다. 내부적으로는 Lambda의 Firecracker microVM 위에서 빌드 컨테이너를 띄우는 방식이다. Firecracker는 AWS가 2018년 오픈소스화한 microVM 모니터로, KVM 위에서 가상머신을 100ms 안에 부팅하도록 만들어졌다(Lambda·Fargate 내부에서 사용). 빌드처럼 "짧고 자주 발생하는" 작업에 적합한 격리 단위다. 단점은 메모리 상한과 디스크 제한이 있어 대형 모노레포 빌드에는 맞지 않는다는 점이다.

CodeBuild는 빌드 컨테이너에서 Docker를 쓰려면 privileged: true 플래그를 켜야 한다. 이건 컨테이너 안에서 또 컨테이너를 띄우는 Docker-in-Docker(DinD) 패턴인데, 보안 격리가 한 단계 약해진다(컨테이너 안에서 호스트 디바이스 접근 가능). 빌드 후 Docker 이미지를 ECR에 push할 때 쓰는 패턴이지만, AWS는 대신 kaniko나 buildah처럼 daemon-less 빌더 사용을 권장한다.

buildspec.yml: CI 파이프라인의 헌법

buildspec.yml은 CodeBuild의 모든 동작을 정의한다. 시험에 나오는 부분은 phase 순서와 각 phase의 책임이다.

version: 0.2   # 현재 유일한 안정 버전 (0.1은 deprecated)
 
env:
  variables:
    NODE_ENV: production
  parameter-store:
    GITHUB_TOKEN: /myapp/github/token    # SSM에서 평문/SecureString
  secrets-manager:
    DOCKER_REGISTRY_PW: prod/docker:password    # JSON 키 지정 가능
  exported-variables:
    - IMAGE_TAG    # 후속 CodePipeline 스테이지로 전달
 
phases:
  install:
    runtime-versions:
      nodejs: 20
      docker: 24
    commands:
      - npm ci
 
  pre_build:
    commands:
      - echo "Login to ECR"
      - aws ecr get-login-password | docker login --username AWS --password-stdin $REPO_URI
      - export IMAGE_TAG=$(git rev-parse --short HEAD)
      - npm test -- --reporters=default --reporters=jest-junit
 
  build:
    commands:
      - docker build -t $REPO_URI:$IMAGE_TAG .
      - docker push $REPO_URI:$IMAGE_TAG
 
  post_build:
    commands:
      - printf '[{"name":"app","imageUri":"%s"}]' $REPO_URI:$IMAGE_TAG > imagedefinitions.json
 
artifacts:
  files:
    - imagedefinitions.json
    - appspec.yml
    - taskdef.json
  discard-paths: yes
 
reports:
  jest_reports:
    files:
      - 'junit.xml'
    file-format: JUNITXML
 
cache:
  paths:
    - 'node_modules/**/*'
    - '/root/.npm/**/*'

각 phase의 책임을 명확히 분리하는 게 좋은 패턴이다.

⚠️ 함정: build phase가 실패해도 post_build는 실행된다는 점은 시험에 나온다. 이 동작 덕분에 "빌드 실패 시 슬랙 알림"을 post_build에서 처리할 수 있지만, 반대로 "build 성공 가정"으로 짠 push 명령이 잘못 동작할 수 있다. post_build에서는 반드시 CODEBUILD_BUILD_SUCCEEDING 환경변수(0/1)를 체크해 분기하는 게 안전한 패턴이다.

# post_build에서 안전한 분기
- |
  if [ "$CODEBUILD_BUILD_SUCCEEDING" = "1" ]; then
    aws sns publish --topic-arn $TOPIC --message "Build OK: $CODEBUILD_BUILD_ID"
  else
    aws sns publish --topic-arn $TOPIC --message "Build FAILED: $CODEBUILD_BUILD_ID"
  fi

buildspec.yml의 phase 모델은 Apache Maven의 빌드 라이프사이클(validate → compile → test → package → install → deploy)처럼 단계를 명시적으로 나눠 각 단계의 산출물과 책임을 분리한다. GitHub Actions의 jobs/steps, CircleCI의 stages도 같은 모델이다.

환경변수와 비밀의 안전한 주입

buildspec.yml에 평문으로 적힌 모든 것은 빌드 로그에 노출될 위험이 있다. CodeBuild는 세 가지 변수 소스를 지원한다.

env:
  parameter-store:
    DB_HOST: /myapp/db/host           # 평문 String 파라미터
    DB_PASSWORD: /myapp/db/password   # SecureString → KMS 복호화
  secrets-manager:
    OAUTH: prod/google-oauth:client_secret    # JSON에서 특정 필드만

secrets-manager에서 콜론 뒤에 키를 지정하면 JSON 시크릿의 특정 필드만 추출한다. 예를 들어 시크릿이 {"username":"admin","password":"abc123"}이면 myapp:password로 password만 가져온다. 추가 :AWSCURRENT:1 같은 stage·version 지정도 가능. 이 문법은 실무에서 유용하다.

CodeBuild 빌드 로그에는 환경변수가 보통 마스킹되지만, echo $SECRET 같은 명령을 실수로 실행하면 그대로 찍힌다. 또 빌드 산출물(artifact zip) 안에 환경변수가 들어간 파일이 포함되면 S3에 그대로 올라간다. AWS는 빌드 종료 후 로그를 CloudWatch Logs에 영구 저장하므로, 한 번 노출된 비밀은 사실상 회전이 유일한 대응책이다.

VPC 통합과 네트워크 격리

기본 CodeBuild 컨테이너는 AWS managed VPC에서 실행돼 인터넷 outbound는 자유롭지만 사용자 VPC의 사설 리소스(예: 사설 서브넷 RDS, 사내 NAS)에는 접근할 수 없다. 사설 리소스 접근이 필요하면 CodeBuild를 VPC 모드로 띄운다.

aws codebuild create-project \
  --name my-build \
  --vpc-config "vpcId=vpc-xxx,subnets=subnet-aaa,subnet-bbb,securityGroupIds=sg-xxx" \
  ...

VPC 모드의 trade-off: 인터넷 outbound가 사라지므로 NAT Gateway나 VPC Endpoint를 통한 명시적 라우팅이 필요하다. ECR pull, S3 artifact upload, CloudWatch Logs send, Secrets Manager fetch까지 모두 endpoint를 만들어야 한다. 빌드 startup도 ENI(Elastic Network Interface) 프로비저닝 때문에 30초~1분 더 걸린다.

가상의 사례로, 한 금융 고객은 사내 정책상 빌드 호스트가 외부 npm 레지스트리에 직접 접근할 수 없었다. 그래서 CodeArtifact에 upstream으로 npmjs.org를 등록하고 VPC endpoint를 통해 CodeArtifact만 접근하도록 구성했다. 결과: 빌드 환경의 모든 npm install이 사내 감사 로그에 남고, 외부 패키지 무단 도입이 차단됐다. CodeBuild의 VPC 모드 + CodeArtifact 조합이 supply chain security의 한 패턴.

빌드 캐시: 시간을 사는 가장 빠른 방법

npm ci나 pip install이 빌드 시간의 큰 부분을 차지하는 경우가 있다. CodeBuild는 세 가지 캐시 모드를 지원한다.

LOCAL 모드는 다시 세 가지 하위 옵션이 있다.

• DOCKER_LAYER_CACHE: Docker 이미지 빌드의 layer 캐시. privileged: true 필요.
• SOURCE_CACHE: git 메타데이터 캐시. shallow clone 효과.
• CUSTOM_CACHE: cache.paths에 지정한 경로.

LOCAL 캐시는 "같은 빌드 호스트가 재할당될 때만" 작동하는데, CodeBuild는 빌드 종료 후 호스트를 일정 시간 warm pool에 유지하다 재사용한다. 즉 빌드가 자주 발생하는 프로젝트는 LOCAL 캐시 hit율이 높고, 한가한 프로젝트는 거의 매번 miss다. 24/7 production CI/CD에는 LOCAL이 충분하지만, 야간/주말에만 도는 빌드라면 S3 캐시가 더 안정적이다.

CodeCommit Triggers vs Notifications

CodeCommit에서 이벤트가 발생했을 때 알리는 방법은 두 가지다.

⚠️ 함정: 시험에서 "PR이 생성됐을 때 슬랙 채널에 알림"이 나오면 Triggers가 아니라 Notifications + AWS Chatbot이 정답이다. Triggers는 SNS/Lambda만 지원하므로 Slack에 가려면 한 단계 Lambda를 거쳐 webhook을 호출해야 한다. Notifications는 Chatbot 통합으로 Slack/Chime을 네이티브로 지원한다.

다른 CI 서비스와의 비교

GitHub Actions의 부상으로 CodeBuild의 시장 지분은 줄었다. 그래도 AWS 리소스를 빌드 도중 광범위하게 만지는 워크플로(ECR push, CodeDeploy 배포, CloudFormation 스택 변경)에서는 IAM 통합이 훨씬 매끄러운 CodeBuild가 여전히 우위다. 2022년부터 GitHub Actions가 OIDC로 IAM 임시 자격증명을 받을 수 있게 되면서 격차가 줄고 있다.

CLI로 만져보기

# 1) CodeCommit 저장소 생성 (기존 고객만)
aws codecommit create-repository \
  --repository-name my-app \
  --repository-description "Sample app"
 
# 2) CodeBuild 프로젝트 생성
aws codebuild create-project \
  --name my-app-build \
  --source type=CODECOMMIT,location=https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/my-app \
  --artifacts type=S3,location=my-artifact-bucket \
  --environment type=LINUX_CONTAINER,image=aws/codebuild/standard:7.0,computeType=BUILD_GENERAL1_SMALL \
  --service-role arn:aws:iam::111122223333:role/CodeBuildServiceRole
 
# 3) 빌드 시작
aws codebuild start-build --project-name my-app-build
 
# 4) 빌드 로그 실시간 tail (CloudWatch Logs)
aws logs tail /aws/codebuild/my-app-build --follow

정리

CodeCommit이 풀려던 문제는 "엔터프라이즈 환경에 맞는 IAM 통합 Git"이었고, 그 가치는 여전히 유효하지만 시장의 흐름은 GitHub로 옮겨갔다. CodeBuild가 풀려던 문제는 "빌드 인프라를 직접 관리하지 않고 buildspec 한 장으로 끝내는 CI"였고, 이쪽은 AWS 리소스와 깊이 통합하는 워크로드에서는 지금도 합리적인 선택이다.

다음 글에서는 이 두 칸 뒤에 붙는 CodeDeploy와 CodePipeline을 본다. 빌드 결과물을 EC2·Lambda·ECS로 어떻게 안전하게 흘려보내는지, Blue/Green과 canary가 어떻게 다르게 구현되는지, 그리고 파이프라인 자체를 코드로 관리하는 패턴까지 짚는다.