GitHub Actions가 팀을 죽이고 있다: CI 시스템의 진실
CircleCI 초기 직원 출신 저자가 모든 CI 시스템을 경험한 후 GitHub Actions의 문제점을 신랄하게 비판합니다
저자: Ian Duncan (CircleCI 초기 직원. Jenkins, Travis, Semaphore, Drone, Concourse, TeamCity, GitLab CI 등 거의 모든 CI 시스템 실전 경험)
- GitHub Actions는 “레포에 바로 붙어있어서” 인기일 뿐, 좋은 CI가 아닙니다
- 로그 뷰어가 브라우저를 크래시시키고, YAML은 프로그래밍 언어처럼 복잡해집니다
- 마켓플레이스 액션은 낯선 사람에게 레포 열쇠를 주는 것과 같습니다
- “GitHub Actions 더 빠르게” 스타트업이 여럿 있다는 사실 자체가 문제를 증명합니다
- Buildkite: 자체 인프라 소유 + 단순한 YAML + 동적 파이프라인 = 진짜 CI
Part I: GitHub Actions의 문제점

로그 뷰어: 브라우저를 죽이는 도구
빌드가 실패했을 때 오류를 확인하기까지의 여정은 고통스럽습니다:
- 체크 요약 페이지 -> 워크플로우 목록
- 워크플로우 클릭 -> 작업 목록
- 작업 클릭 -> 단계 목록 (모두 접혀있음)
- 단계 클릭 -> 드디어 로그… 천천히 나타남
“세계에서 가장 인기 있는 CI 시스템의 로그 뷰어가 반복적으로, 신뢰성 있게 브라우저를 크래시시킵니다.”
큰 로그에서는 스크롤바가 장식용이고, 결국 raw log를 다운로드해서 텍스트 에디터로 열게 됩니다. 2003년 스타일입니다.
YAML 지옥: 설정인가 프로그래밍인가
GitHub Actions YAML은 단순한 설정 파일이 아닙니다:
- 자체 표현 언어 (expression language)
- 자체 컨텍스트 객체 모델
- 자체 문자열 보간 규칙
- 그리고 수많은 gotchas…
조건부 환경변수 설정하려고 ${{ }} 댄스를 추다가 따옴표 하나 잘못 쓰면? 러너 시작까지 4분 기다린 후에야 오류를 발견합니다.
마켓플레이스: 낯선 사람에게 집 열쇠 주기
uses: some-stranger/cool-action@v2라고 쓸 때마다:
- 레포 접근 권한 부여
- 시크릿 접근 권한 부여
- 빌드 환경 접근 권한 부여
SHA 고정이 가능하지만 아무도 하지 않습니다. 읽지도 않은 불투명한 코드가 GITHUB_TOKEN에 접근하면서 실행됩니다.
컴퓨팅: 당신의 것이 아닙니다
GitHub Actions는 Microsoft의 러너를 임대하는 것입니다. 느리고, 자원이 제한적이며, 의미 있는 커스터마이징이 불가능합니다.
“GitHub Actions 더 빠르게” 스타트업들(Namespace, Blacksmith, Actuated, Runs-on, BuildJet)이 여럿 있다는 사실 자체가 모든 것을 말해줍니다.
”그냥 Bash 쓰면 되지?” - 함정입니다
YAML 지옥에서 벗어나려는 유혹은 이해가 됩니다. 하지만 3개월 후면 800줄짜리 bash가 wait과 PID 파일로 작업 병렬화를 재구현하고, for 루프와 sleep으로 재시도 로직을 만들게 됩니다.
“CI를 탈출한 게 아닙니다. CI 시스템을 만든 겁니다. 다른 모든 CI보다 나쁜, bash로 작성된, 아무도 따라갈 수 없는, 테스트 프레임워크도 없는 CI를.”
Part II: Buildkite - 대안

로그 뷰어: 그냥 작동합니다
- 로그를 보여주는 웹페이지. 크래시하지 않습니다
- ANSI 색상 작동, 터미널 포맷팅 유지
- 어노테이션: 테스트 실패 요약, 커버리지 리포트, 배포 링크를 빌드 페이지에 직접 표시
- 디버깅: 에이전트가 자체 인프라 -> SSH 접속 가능, 환경 재현 가능
YAML: 제 역할만 합니다
Buildkite YAML은 파이프라인을 설명할 뿐입니다. 스텝, 명령, 플러그인. 데이터 구조일 뿐, 설정 포맷을 흉내 내는 프로그래밍 언어가 아닙니다.
로직이 필요하면? 스크립트를 작성합니다. 진짜 언어로. 로컬에서 실행 가능한. 존엄성과 살고자 하는 의지를 가진 인간처럼.
인프라: 당신 것입니다
Buildkite 에이전트는 자신의 머신에서 실행되는 단일 바이너리입니다. 클라우드, 온프레미스, 특수 하드웨어 - 선택이 자유롭습니다.
“Buildkite 더 빠르게” 스타트업은 없습니다. 그냥 더 큰 머신을 돌리면 됩니다.
동적 파이프라인: 진짜 프로그래밍
Buildkite에서 파이프라인 스텝은 데이터입니다. 스크립트가 런타임에 파이프라인 스텝을 업로드하고, 모노레포에서 변경된 것만 정확히 빌드/테스트할 수 있습니다.
결론: 시작하기 쉬운 CI vs 계속 쓰기 좋은 CI
GitHub Actions가 괜찮은 경우
- 소규모 팀, 단순한 앱, 직관적인 테스트
- 공개 레포의 OSS 프로젝트 (무료 제공)
- 인프라 관리할 여력 없는 주말 사이드 프로젝트
Buildkite를 고려해야 하는 경우
- 진짜 프로덕션 시스템 운영
- 모노레포 사용
- 빌드 5분 이상
- 공급망 보안 중요
- CI를 “소유”하고 싶음

“시장 점유율을 얻는 CI는 CI로서 최고인 게 아닙니다. 시작하기 가장 쉬운 겁니다. GitHub Actions는 시작하기 가장 쉬운 CI입니다. Buildkite는 계속 쓰기 가장 좋은 CI입니다.”
NxtCloud Workshop