GitHub Actions에 Blacksmith를 붙인 이유 — 1,527개 작업의 성능과 비용

고객 환경과 우리 환경에 같은 CI를 억지로 넣지는 않는다. 클라이언트는 GitLab이나 CodeCommit에서 시작해 CodePipeline → CodeBuild → ECR·ECS 또는 CodePipeline → CodeBuild → CodeDeploy·EC2로 이어지는 경우가 많다. 소스, IAM, 네트워크와 배포 이력이 AWS 안에서 닫히는 구성이 중요하기 때문이다.

801플래닛이 직접 만드는 애플리케이션은 출발점이 다르다. GitHub → GitHub Actions → Blacksmith → ECR·ECS를 쓴다. GitHub Actions가 워크플로를 조정하고 Blacksmith가 작업을 실행한다. AWS 배포 권한은 장기 액세스 키 대신 GitHub OIDC로 짧게 발급한다.¹

이 글은 Blacksmith를 모든 환경의 표준으로 권하는 소개가 아니다. 실제 계정에서 무엇을 봤는지, 공개된 성능 주장에 어느 정도 근거가 있는지, CodeBuild나 직접 운영하는 BuildKit과 비교하면 선택이 어디서 갈리는지를 기록한다. 참고로 제공받은 Findy Tools 리뷰는 본문이 회원 전용이라 제목과 공개된 작성자 정보만 확인했고 정량 근거에는 쓰지 않았다.²

두 경로는 모두 AWS에 배포하지만 제어면은 다르다. 위쪽에서 CodePipeline은 GitLab 또는 CodeCommit의 변경을 받아 CodeBuild를 실행한다. 컨테이너 경로는 이미지를 ECR에 올리고 ECS가 가져가며 인스턴스 경로에서는 CodeDeploy가 릴리스를 EC2에 전달한다.

아래쪽에서는 GitHub Actions가 워크플로를 조정하고 Blacksmith가 BuildKit 작업을 실행한다. Docker 레이어 캐시는 러너 가까이에서 재사용한다. GitHub OIDC로 수명이 짧은 IAM 역할을 인수해 이미지를 ECR에 push하고 ECS는 그 이미지를 pull한다. 오른쪽 막대는 같은 커밋 태그에서 확인한 ECR 압축 이미지 네 개의 크기다.

두 파이프라인은 출발점부터 다르다

Blacksmith는 GitHub Actions를 대체하는 CI 제품이 아니다. GitHub의 워크플로와 액션 생태계는 그대로 두고 runs-on 대상만 Blacksmith의 러너로 바꾼다. 공식 빠른 시작 문서도 GitHub 조직 전용이며 개인 저장소에는 쓸 수 없다고 명시한다.³

runs-on: blacksmith-2vcpu-ubuntu-2404

바꿀 범위가 작아 도입이 가볍다. 반대로 GitLab이나 CodeCommit이 소스의 중심이면 이 장점부터 사라진다. 그런 환경에서 Blacksmith를 억지로 끼우기보다 CodeBuild나 기존 GitLab Runner를 유지하는 편이 구성과 감사 경로가 단순하다.

6개월 관측값은 무엇을 말하나

2026년 1월 23일부터 7월 23일까지 조직 전체를 선택한 Blacksmith CI Analytics 화면에는 1,527개 작업이 잡혔다. 작업 시간 p50은 255초, 곧 4분 15초였다. p90은 5분 40초, p95는 6분 46초, p99는 12분 45초, 최댓값은 27분 22초였다.

이 화면만으로 Blacksmith가 이전보다 몇 배 빨라졌다고 판단할 수는 없다. 전환 전 같은 커밋을 GitHub-hosted runner에서 반복한 기준선이 없기 때문이다. 13.75% 실패율도 Blacksmith 장애율이 아니다. 테스트 실패, 애플리케이션 오류, 설정 실수와 의도적으로 실패시킨 작업이 섞인 조직 전체 지표다. 공급자 신뢰성보다 어느 저장소와 작업부터 고칠지 찾는 운영 지표로 봐야 한다.

같은 기간 Docker Analytics에는 1,487회 빌드, 9.28% 실패율, 평균 캐시 사용량 14.8GB가 기록됐다. 빌드 대부분은 1분 안쪽에 몰렸지만 긴 꼬리는 약 7분까지 이어졌다.

Blacksmith 대시보드에서는 작업 시간, 실패율, 캐시와 저장소별 비용을 한곳에서 나눠 본다.⁴ GitHub Actions 로그만 볼 때보다 p95·p99의 긴 작업과 캐시가 커진 저장소를 찾기 쉽다. 우리에게 Observability는 부가 화면이 아니라 러너를 관리형으로 선택한 이유 중 하나였다.

성능 주장의 근거를 세 층으로 나눠 봤다

“최대 40배 빠른 Docker 빌드”는 모든 빌드에 적용되는 보장이 아니다. Blacksmith 문서도 이를 고객이 보고한 2~40배 개선으로 표현한다.⁵ 각 자료의 이해관계와 실험 조건을 표에 함께 적었다.

공통 원리는 단순하다. 임시 러너가 끝날 때 BuildKit의 작업 공간까지 사라지면 RUN --mount=type=cache로 만든 의존성 캐시도 함께 사라진다. Blacksmith는 저장소별 Docker 레이어 캐시를 영속 스토리지에 두고 다음 러너에 붙인다. 직접 구성한다면 원격 buildkitd와 영속 볼륨, GC 정책, 동시성, 격리와 장애 복구를 직접 맡아야 한다.

병목이 캐시와 단일 코어 CPU에 있으면 효과가 크다. 큰 이미지를 러너로 다시 가져오는 --load, 외부 레지스트리 전송, 느린 통합 테스트가 대부분이면 러너만 바꿔도 큰 차이가 없거나 더 느려질 수 있다. 최대 몇 배라는 문구보다 같은 커밋의 p50·p95, 캐시 적중률, 성공한 작업 한 건의 비용을 비교하는 편이 정확하다.

ECR 이미지 크기도 러너 성능만큼 중요했다

실제 ECR에 올라간 네 최종 이미지는 압축 기준 79.9~330.5MB였고 runner stage에 남긴 runtime 파일과 production 의존성이 크기 차이를 만들었다.

2026년 7월 23일 서울 리전의 사내 ECR 저장소 네 곳을 읽기 전용으로 조회했다. 같은 커밋 태그를 기준으로 DescribeImages.imageSizeInBytes와 OCI manifest의 레이어 목록을 확인했다. 계정 ID와 저장소명은 공개하지 않았다. ECR 수치는 압축되어 저장된 이미지 크기다. 로컬 docker images가 표시하는 압축 해제 크기나 컨테이너가 쓰는 디스크 용량과 같지 않다.⁹

네 Dockerfile은 모두 multi-stage build를 쓴다. lockfile과 각 workspace의 package.json을 소스보다 먼저 복사한 뒤 pnpm install을 실행한다. 애플리케이션 코드만 바뀌면 의존성 설치 레이어를 재사용할 수 있는 순서다. .dockerignore는 node_modules, 기존 dist와 .next, 인프라 코드, 문서와 .github를 빌드 컨텍스트에서 뺀다. Docker도 변경 빈도가 낮고 비용이 큰 단계를 앞에 두고 빌드 컨텍스트를 작게 유지하도록 권한다.¹⁰

최종 크기는 runner stage 구성에 따라 갈렸다. 웹은 Next.js standalone 결과와 정적 파일만 복사해 81.3MB였다. API는 production 의존성과 빌드 산출물, Prisma 관련 파일을 포함해 245.2MB였다. 단일 JS 실행 이미지는 Node.js runtime과 dist/main.js만 담아 79.9MB였다. 오케스트레이터는 Temporal·database workspace의 production 의존성과 산출물을 함께 담아 330.5MB였다. builder stage의 도구를 최종 이미지에서 제외하는 multi-stage build의 이점은 같아도, runtime에 무엇을 남기느냐에 따라 결과는 4배 넘게 벌어졌다.¹¹

현재 워크플로는 docker/build-push-action에서 push: true로 ECR에 바로 보낸다. 큰 이미지를 러너의 로컬 Docker daemon으로 되가져오는 --load 경로는 쓰지 않는다. 그래도 production 의존성이 바뀌어 100MB가 넘는 레이어가 무효화되면 다시 빌드하고 전송해야 한다. Blacksmith가 캐시를 가까이 둬도 애플리케이션의 레이어 경계나 큰 runtime image까지 고쳐 주지는 않는다.

우리는 러너 시간만으로 실험을 평가하지 않는다. 같은 커밋의 콜드·웜 빌드 시간과 함께 ECR 압축 크기, 가장 큰 변경 레이어, push 시간, ECS에서 새 task가 준비될 때까지 걸린 시간을 기록해야 한다. 캐시가 빠른지와 배포할 이미지가 가벼운지는 별개의 질문이다.

단가 계산과 실제 청구는 다르다

2026년 7월 23일 공개 가격에서 GitHub-hosted Linux 2코어 러너는 분당 0.006달러, Blacksmith Ubuntu x64 2 vCPU는 0.004달러다.¹²¹³ AWS CodeBuild 가격 페이지의 general1.small 예시는 분당 0.005달러를 쓴다.¹⁴

무료 분, GitHub 요금제, 캐시와 로그 비용을 빼고 같은 10,000분이 청구됐다고 가정한 컴퓨트 비용은 아래와 같다.

이 표는 단가를 분리해서 보는 계산일 뿐 TCO 순위가 아니다. CPU 세대와 메모리, 분 단위 반올림, 실제 실행 시간, 네트워크와 캐시 방식이 서로 다르다. CodeBuild는 공유 레이어 캐시를 쓰는 Docker image server도 제공하며 실행 중 서버와 대기 캐시에 별도 과금한다.¹⁴ Blacksmith에서 관측한 평균 캐시 14.8GB를 현재 단가로 단순 환산하면 월 7.40달러다.

실제 청구서는 더 작았다. 2026년 3월부터 7월까지 다섯 번의 청구는 각각 4.31달러, 6.26달러, 22.13달러, 4.65달러, 9.97달러였다. 합계는 47.32달러, 월평균은 9.46달러다.

청구 기간은 37월이고 Analytics 화면은 17월이라 두 자료의 기간이 일치하지 않는다. p50은 평균 실행 시간이 아니므로 1,527 × 255초로 총 사용 시간을 추정하지도 않았다. 이 기록으로 확정할 수 있는 것은 현재 규모의 실제 지출뿐이다.

CodeBuild와 Blacksmith의 선택이 갈리는 곳

CodeBuild는 VPC ID, 서브넷과 보안 그룹을 프로젝트에 지정해 사설 RDS, ElastiCache, 내부 ECS와 사설 아티팩트 저장소에 접근할 수 있다.¹⁵ Blacksmith는 외부 서비스 접근용 고정 IP를 제공하지만 현재 공개 가격은 IP 하나에 월 100달러다.¹⁶ 사설망 접근이 필수라면 러너 분당 가격보다 네트워크 설계와 보안 심사가 먼저다.

Blacksmith의 보안 문서는 SOC 2 Type 2, GDPR 준수, ISO 27001 데이터센터를 명시하고 작업마다 Firecracker microVM을 만든다고 설명한다. GitHub App은 워크플로 수정과 JIT 러너 토큰 발급에 필요한 권한을 요청한다.¹⁷ 이 정보는 검토의 출발점이지 고객사 보안 심사를 대신하지 않는다.

우리가 Blacksmith를 선택한 기준

우리 환경의 소스와 코드 리뷰는 GitHub에 있다. Docker 이미지를 자주 만들어 ECR과 ECS로 보낸다. 소규모 팀이 Actions Runner Controller나 EC2 러너 풀의 스케일링, 패치, 디스크와 BuildKit GC까지 운영하는 것보다 관리형 실행 계층을 쓰는 편이 맞았다. 배포 권한은 GitHub OIDC로 짧게 열고 AWS 역할의 sub 조건을 저장소와 브랜치에 묶었다.

이 선택은 클라이언트 파이프라인에도 Blacksmith를 넣겠다는 뜻이 아니다. GitLab·CodeCommit, 사설 VPC, AWS 서비스 역할이 기준인 프로젝트에서는 CodePipeline과 CodeBuild를 유지한다. 실제로 소스와 빌드를 사설망 안으로 가져간 사례는 NKS 현대화의 GitLab·Jenkins 파이프라인에 따로 기록했다.

자사 환경에서는 GitHub Actions 파일을 거의 그대로 유지했고 Docker 캐시를 직접 운영하지 않았다. 작업·캐시·실패·비용도 한 대시보드에서 봤다. 6개월 지표는 이 구성이 작동한다는 운영 기록이다. 다른 러너보다 몇 배 빠르다는 증명은 아니다.

도입 전에 2주 실험으로 확인할 것

1. Docker 비중이 큰 워크플로 두 개를 고르고 기존 러너의 p50·p95, 대기 시간, 성공률과 월 비용을 기록한다.
2. 같은 커밋을 GitHub-hosted runner와 Blacksmith에서 반복해 콜드 캐시와 웜 캐시를 따로 비교한다.
3. max-cache-size-mb로 Docker 캐시 상한을 정하고 캐시 적중률과 월 GB를 함께 본다. ECR 압축 이미지 크기와 가장 큰 변경 레이어도 기록한다.⁵
4. AWS OIDC 역할의 aud와 sub, GitHub App 권한, 외부 액션 버전 고정, 고정 IP 필요 여부를 검토한다.
5. 무료 한도를 하드 캡으로 가정하지 말고 예산 경보와 중단 조건을 확인한다. 2026년에는 무료 한도 초과 뒤 1,081달러 청구서를 받았다는 공개 사례도 있었다.¹⁸

파일 한 줄을 바꾸는 도입은 쉽다. 판단은 그 다음부터다. 빌드가 빨라졌는지보다 리뷰가 기다리는 시간이 줄었는지, 분당 가격보다 성공한 변경 한 건을 운영팀 손대지 않고 통과시키는 비용이 낮아졌는지를 봐야 한다.

자주 묻는 질문

Blacksmith는 무엇인가

Blacksmith는 GitHub Actions용 관리형 러너다. 워크플로 제어는 GitHub가 맡고 Blacksmith는 격리된 실행 환경과 콜로케이션 캐시, Docker 레이어 캐시, CI Analytics를 제공한다. GitHub 조직에서 runs-on 태그를 바꾸는 방식으로 도입한다.

Blacksmith가 AWS CodeBuild를 대체할 수 있나

항상 그렇지는 않다. GitHub Actions가 기준이고 러너 운영을 줄이려면 Blacksmith가 맞다. GitLab·CodeCommit, CodePipeline, VPC 내부 접근과 AWS 서비스 역할이 기준이면 CodeBuild가 더 단순하다. 둘은 같은 위치의 제품이라기보다 서로 다른 제어면에 붙는 실행 계층이다.

Blacksmith에서 ECR로 이미지를 보내고 ECS를 배포할 수 있나

가능하다. GitHub Actions에서 AWS OIDC로 제한된 IAM 역할을 인수하고 ECR push와 ECS 배포 권한을 준다. 장기 AWS 액세스 키를 GitHub Secret에 저장하지 않고 역할의 sub 조건으로 허용 저장소와 브랜치를 좁히는 것이 핵심이다.

Blacksmith의 속도를 직접 구성으로 재현할 수 있나

핵심 원리는 재현 가능하다. 영속 볼륨을 가진 원격 BuildKit daemon과 가까운 캐시를 두면 임시 러너에서도 캐시를 재사용한다. 대신 GC, 동시 빌드, 격리, 패치, 장애 복구와 비용 관측을 직접 운영해야 한다. Blacksmith의 가치는 캐시 원리보다 실행 계층을 운영해 주는 데 있다.

GitHub 기반 애플리케이션의 CI 병목을 측정하거나 CodeBuild·관리형 러너·자체 BuildKit의 경계를 정해야 한다면 클라우드 & 인프라에서 현재 워크플로와 AWS 네트워크부터 함께 검토한다. AWS 내부 트래픽과 ECR 비용 경로는 AWS 보이지 않는 비용에서 이어서 볼 수 있다.

참고 자료

가격과 제품 동작은 2026년 7월 23일 공개 페이지를 다시 확인했다. 801플래닛 수치는 첨부한 조직 전체 대시보드와 결제 내역에서 읽었으며 저장소별 원자료와 전환 전 A/B 기준선은 이 글에 포함하지 않았다.