Chiko IT
AWS

AWS CodeBuild GitHub Actions 비교 — 비용·성능·설정(2026)

Chiko
13min read

목차

AWS CodeBuild GitHub Actions 비교를 시작할 때 가장 먼저 보는 숫자는 분당 단가다. 2026년 5월 기준으로 GitHub Actions의 Linux 표준 2-core 러너는 분당 $0.008, AWS CodeBuild Linux Small(3GB / 2 vCPU)은 분당 약 $0.005, Medium(7GB / 4 vCPU)은 $0.01 정도다. 단가만 놓고 보면 큰 차이가 없어 보인다.

결국, 다만 청구서로 받아보면 그림이 달라진다. free tier, 동시 실행 한도, 캐시 저장 비용, 데이터 전송, IAM 통합 비용까지 더해지면 두 서비스의 결이 꽤 다르게 나온다. 5년차 즈음 되면 새로운 도구로 갈아타는 비용이 얼마나 비싼지 알게 된다. 잘 돌아가는 파이프라인은 가능한 한 안 건드리는 게 정답이다. 그럼에도 새 프로젝트에서 한 번쯤은 다시 묻게 된다. CodeBuild를 써야 하는가, GitHub Actions로 끝낼 것인가.

이 글은 두 서비스를 가격, 설정 난이도, 성능, AWS 통합, 팀 적합도 다섯 축으로 비교한다. 결론은 마지막에 짧게 덧붙인다.

분당 단가가 같다고 청구서가 같지는 않다

단가는 출발점일 뿐이다. 같은 분당 $0.008이라도 어디에 부과되는지가 다르다. GitHub Actions는 워크플로 실행 시간 전체에 분 단위로 과금된다. 큐잉, 의존성 설치, 테스트, 배포까지 합산이다. CodeBuild도 빌드 컨테이너가 살아있는 시간에 과금되지만, S3 캐시 다운로드와 ECR 푸시는 별개로 데이터 전송 비용이 잡힌다.

free tier 차이가 의외로 크다. GitHub Actions는 퍼블릭 레포에서 무제한 무료, 프라이빗 레포는 Free 플랜 기준 월 2,000분 무료다. CodeBuild는 build.general1.small 기준 월 100분이 첫 12개월 동안 무료다. 100분이면 사실상 평가용이다.

그래서 단순 토이 프로젝트라면 GitHub Actions가 압도적으로 싸다. 하지만 빌드가 무거워지면 얘기가 달라진다.

무거운 빌드에서 단가가 뒤집히는 지점

결국, 8-core 정도가 필요한 빌드에서는 단가 구조가 뒤집힌다. GitHub Actions의 8-core 러너는 분당 $0.032, CodeBuild Large(15GB / 8 vCPU)는 분당 $0.02 수준이다. 60% 정도 차이가 난다. 빌드 한 번에 10분 걸리는 작업을 하루 50회 돌리면 단순 환산으로 월 $480 vs $300이다. CI/CD 비용이 월 수백 달러대로 가는 시점부터는 CodeBuild 쪽이 점점 매력적으로 보인다.

다만 GitHub Actions의 Larger runner는 셀프 호스트와 거의 같은 사용성을 유지한다는 장점이 있다. 단가로만 결정하긴 어렵다.

동시성 한도

가격표에 잘 안 나오는 항목이 동시 실행 한도다. GitHub Actions Free 플랜은 동시 실행 20개, Linux 기준이다. Team은 60개, Enterprise는 180개. CodeBuild는 리전당 동시 빌드 한도가 기본 60개로 시작하고, AWS Service Quota 요청으로 늘릴 수 있다. (출처: AWS CodeBuild 공식 문서, 2026년 4월 기준)

CI 큐가 막히는 시점은 보통 모노레포 전환 직후다. 동시성 60개 내외에서 묶이면 PR 한 번에 빌드 12개가 동시 트리거되는 팀이 못 버틴다. 이때부터는 한도 자체가 단가보다 더 큰 변수가 된다.

가격 모델 — 청구서 기준으로 환산하면

말로만 비교하면 손에 잘 안 잡힌다. 같은 워크로드를 두 서비스에 올렸을 때 월 청구서가 어떻게 나오는지 환산해본다. 빌드 1회 8분, 하루 30회, 영업일 22일 기준이다.

항목 GitHub Actions (2-core) CodeBuild Small GitHub Actions (8-core) CodeBuild Large
분당 단가 $0.008 $0.005 $0.032 $0.02
월 빌드 시간 5,280분 5,280분 5,280분 5,280분
컴퓨트 비용 $42.24 $26.40 $168.96 $105.60
캐시·전송 추정 거의 무시 $3~8 거의 무시 $5~12
사실상 청구액 ~$42 ~$30 ~$170 ~$115

(가격은 us-east-1 기준 2026년 5월 1일 조회. 환율과 리전에 따라 달라진다.)

게다가, 작은 빌드에서 CodeBuild가 약 30% 싸고, 큰 빌드에서는 약 32% 싸다. 단순 환산만 보면 CodeBuild가 우위인 것처럼 보이지만, 운영 비용은 컴퓨트만이 아니다. CodeBuild는 IAM 정책, VPC 설정, S3 캐시 버킷, CloudWatch 로그 보존 기간 같은 부수 설정을 다 직접 만지게 된다. 그 시간이 곧 인건비다.

그런데, :::tip 빌드 시간이 분당 0.001달러 차이라도 월 1만 분이면 $10이지만, 엔지니어 1시간 = $50~80 환산하면 설정 단순화로 월 2~3시간을 아끼는 쪽이 보통 더 이득이다. 청구서 기반 비교는 인건비를 같이 계산해야 의미가 있다. :::

설정 난이도 — buildspec과 workflows의 결

실제로, YAML 구조 자체는 둘 다 비슷한 수준의 진입 장벽이다. 물론 결이 다르다.

GitHub Actions의 .github/workflows/*.yml은 이벤트 트리거가 1급 시민이다. PR 열림, push, 라벨 추가, 이슈 코멘트, 스케줄까지 거의 모든 GitHub 이벤트에 바로 묶을 수 있다. 마켓플레이스 액션을 가져다 쓰는 문화가 있어 5분이면 새 파이프라인이 돌아간다.

# .github/workflows/build.yml
name: build
on:
  push:
    branches: [main]
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'  # 의존성 캐시 자동 처리
      - run: npm ci && npm test

CodeBuild의 buildspec.yml은 더 단순하지만 그만큼 노출되는 면적도 작다. 트리거는 외부에서 따로 묶어줘야 한다. CodePipeline, EventBridge, GitHub 웹훅, 또는 자체 람다.

# buildspec.yml
version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 20
  build:
    commands:
      - npm ci
      - npm test
cache:
  paths:
    - 'node_modules/**/*'  # S3 캐시로 저장됨

물론, 코드 줄 수만 보면 비슷하다. 그러나 GitHub Actions는 위 파일 하나로 끝나고, CodeBuild는 프로젝트 정의(IAM Role, 소스 연결, 환경, 캐시 버킷)를 콘솔이나 Terraform으로 따로 만들어야 한다.

학습 곡선

GitHub Actions는 작성 시점 기준 마켓플레이스에 등록된 액션이 2만 개를 넘는다. 거의 모든 흔한 작업에 누군가 만들어둔 액션이 있다고 보면 된다. 단점은 검증되지 않은 서드파티 액션을 무심코 끌어다 썼다가 시크릿 유출 같은 사고가 종종 보고된다는 점이다 (참고: GitHub Security Advisories, 2024~2025년 다수 사례).

CodeBuild는 마켓플레이스 같은 생태계가 없다. 빌드 명령어를 직접 쓰는 게 기본이다. 이게 단점처럼 보이지만, 의존이 단순해서 "이 빌드는 정확히 무슨 일을 한다"가 더 명확해진다. 보수적인 팀에는 이쪽이 마음 편할 수 있다.

콘솔 vs 코드

반면, GitHub Actions는 거의 모든 설정이 YAML 한 곳에 모인다. CodeBuild는 콘솔에서 클릭으로도 만들 수 있고, IaC로도 만들 수 있다. 양쪽 다 가능한 게 양날의 정의는 아니지만 — 클릭으로 만든 프로젝트는 결국 추적이 안 돼서 다음 사람이 헤맨다. 그래서 실무에서는 Terraform이나 CloudFormation으로 못 박는 게 좋다.

성능과 캐시 전략

빌드 시간을 좌우하는 건 단일 코어 성능보다 캐시와 콜드 스타트다.

콜드 스타트

GitHub Actions의 호스티드 러너는 매 잡마다 새 VM이 뜬다. 부팅 시간은 보통 5~15초. CodeBuild도 마찬가지로 매 빌드마다 새 컨테이너가 뜨지만, "재사용 가능한 빌드 환경(reserved capacity)" 옵션으로 콜드 스타트를 줄일 수 있다. 단 reserved capacity는 시간당 단가가 따로 붙으니 빌드가 충분히 자주 돌아야 본전이 나온다.

대안으로 CodeBuild의 Lambda 컴퓨트 옵션이 있다. 1GB 환경에서 초당 $0.00004 수준으로 과금되고, 부팅이 빠르다. 작은 단위 작업에는 매력적이다. 그런데 메모리 10GB 이상 필요한 빌드에는 못 쓴다.

Docker 레이어 캐시

결국, 이게 가장 큰 변수다. GitHub Actions에서 Docker 빌드 캐시를 제대로 쓰려면 보통 actions/cache나 docker/build-push-action의 cache-from 옵션을 쓴다. GitHub의 Actions Cache는 기본 10GB 한도라서 멀티 스테이지 빌드 큰 거 한두 개 굴리면 금방 찬다. 한도를 넘으면 LRU로 오래된 캐시가 사라진다.

CodeBuild는 S3 또는 ECR을 캐시 백엔드로 쓴다. S3는 한도가 사실상 무제한, ECR도 한도 신경 쓸 일이 거의 없다. 대신 캐시 다운로드/업로드 속도는 GitHub의 내장 캐시가 더 빠른 편이다. (체감상 1~2초 정도 차이 나는 경우가 많다.)

큰 빌드에서의 안정성

빌드 머신이 4~5분 이상 도는 작업이라면 CodeBuild Large가 안정적이다. GitHub Actions의 큰 러너도 좋지만 Marketplace 액션을 깊이 끼우면 가끔 "Disk space full" 에러가 나는 사례가 보고된다(GitHub #56689 등). 디스크 14GB 한도가 빠듯해서다. CodeBuild는 디스크 크기를 직접 늘릴 수 있다.

AWS 통합과 권한 — IAM이 만드는 분기점

이게 두 서비스 비교에서 가장 본질적인 갈림길이다.

실제로, CodeBuild는 IAM Role을 직접 끼고 돈다. 빌드 컨테이너 안에서 aws s3 cp나 aws ecr push를 호출하면 별도 자격 증명 없이 그대로 동작한다. 이 점이 보안적으로 가장 깨끗하다. 키를 어디에도 저장하지 않는다.

GitHub Actions에서 같은 일을 하려면 두 가지 길이 있다. 옛날 방식은 액세스 키를 시크릿에 박아 넣는 것. 시크릿 회전이 귀찮고, 유출 리스크가 있다. 권장 방식은 OIDC 페더레이션이다.

permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gh-actions-deploy
          aws-region: us-east-1
      - run: aws s3 cp ./dist s3://my-bucket/ --recursive

특히, OIDC를 한 번 설정하면 키 없이도 깔끔하게 IAM Role을 가정해 쓸 수 있다. 단 처음 설정할 때 IAM Identity Provider 등록, Trust Policy의 sub claim 매칭, 리포지터리 단위 권한 분리 같은 걸 손으로 해야 한다. 익숙하지 않으면 한나절은 잡힌다.

CodeBuild는 그냥 Role 하나 붙여서 끝이다. 이 차이가 AWS 의존도가 큰 팀에서 CodeBuild가 여전히 살아남는 이유다.

VPC 접근

실제로, 내부망 RDS, ElastiCache, 사설 ECR을 빌드 중에 쓰고 싶다면 CodeBuild가 거의 유일한 선택이다. CodeBuild는 VPC 안에서 직접 돌릴 수 있다. GitHub Actions는 호스티드 러너로는 불가능하고, 셀프 호스트 러너를 EC2/ECS에 띄워야 한다. 그러면 결국 운영 부담이 GitHub Actions에서 사라지지 않는다.

반면, 이 경계 하나로 결정 나는 팀이 꽤 있다. 사내 RDS에서 마이그레이션 테스트를 매 PR에 돌리는 팀이라면 CodeBuild가 자연스럽다.

어디에 어느 도구가 맞나

그런데, 같은 자에 둘을 놓고 보면 결정이 그리 어렵지 않다. 팀 상황별로 정리하면 이렇다.

GitHub Actions가 자연스러운 경우는 코드가 GitHub에 있고, 빌드가 가볍고, 배포 대상이 AWS 외부거나 IAM 통합이 필수가 아닐 때. 스타트업, 오픈소스, 풀스택 작은 팀이 대체로 여기에 들어간다. 셋업 30분이면 끝이다.

한편, CodeBuild가 자연스러운 경우는 AWS 의존도가 깊고, VPC 안에서 돌려야 하고, 빌드가 무겁고, 컴플라이언스 때문에 키를 외부에 두기 어려울 때. 보통 5년 이상 운영된 AWS 중심 조직에 맞다.

하이브리드가 가장 흔한 답이다. 트리거와 PR 검증은 GitHub Actions로, 프로덕션 배포처럼 IAM이 깊게 얽힌 단계만 CodeBuild나 CodePipeline으로 넘기는 구조. 두 도구의 강점을 따로 쓴다는 점에서 합리적이다. 물론 파이프라인이 두 곳에 흩어지면 디버깅 동선이 길어지는 단점이 있다.

소규모 팀이라면 GitHub Actions 하나로 끝내는 게 운영 비용이 가장 작다. 빌드비가 월 $200을 넘기 전까지는 단가 차이가 인건비를 못 따라잡는다.

액션 — 이번 주 안에 결정 내리려면

한편, 세 가지로 좁혀서 보면 된다.

먼저 한 달치 워크플로 실행 시간을 GitHub Actions의 Billing 페이지나 CodeBuild의 CloudWatch 메트릭에서 뽑아본다. 8분 × 30회 × 22일 같은 추정 말고, 실제 분 단위로. 이 숫자가 월 5,000분 미만이면 가격은 더 볼 필요가 없다. GitHub Actions로 끝내라.

다음으로 빌드가 VPC 내부 자원에 접근해야 하는지 확인한다. 그렇다면 CodeBuild 또는 셀프 호스트 러너 둘 중 하나다. 셀프 호스트 운영 여력이 없다면 CodeBuild로 가는 게 맞다.

마지막으로 AWS 자격 증명이 빌드 어디에 들어가는지 본다. 시크릿에 액세스 키를 박아둔 상태라면 둘 중 어느 쪽으로 가든 OIDC 또는 IAM Role 마이그레이션이 우선이다. 도구를 바꾸는 것보다 키를 빼는 게 더 급한 작업이다.

또한, 단 두 서비스 모두 가격 정책과 동시성 한도가 분기마다 조금씩 바뀐다. 2026년 5월 기준 수치로 결정한 후에도, 6개월에 한 번씩은 청구서를 다시 환산해보는 게 안전하다. 1년 전 기준으로 잡은 임계치가 지금도 유효하다고 단정하긴 어렵다.

관련 글

More posts