GitHub Actions이 엔지니어링 팀을 서서히 망치고 있다

• GitHub Actions의 구조적 비효율성과 불안정한 사용자 경험이 개발자 생산성을 저하시킴
• 로그 뷰어의 느린 로딩과 브라우저 충돌, 복잡한 YAML 구문과 표현식 오류가 반복적인 디버깅을 초래
• Marketplace의 불투명한 서드파티 액션과 제한된 컴퓨트 제어권이 보안과 성능 모두에 부담으로 작용
• 이에 비해 Buildkite은 단순한 YAML 구조, 자가 호스팅 가능한 에이전트, 안정적인 로그 뷰어로 대안 제시
• CI 시스템 선택에서 편의성보다 유지 가능성과 개발자 경험의 질이 중요함을 강조

GitHub Actions의 문제점

• 로그 뷰어의 비효율성으로 인해 단순한 오류 확인에도 여러 단계의 클릭과 페이지 로딩이 필요

  • 긴 로그를 열면 브라우저가 멈추거나 충돌하며, 스크롤이 제대로 작동하지 않음
  • 로그를 직접 다운로드해 텍스트 편집기로 열어야 하는 경우가 빈번함
  • 뒤로 가기 버튼이 일관되지 않아 탐색이 혼란스러움

• 디버깅 과정의 비생산성

  • 단일 변경 사항 확인에도 수차례 커밋과 대기 시간이 필요
  • 20분 단위의 피드백 루프가 반복되어 하루 업무가 CI 대기 시간으로 소모됨

• YAML 구성의 복잡성

  • GitHub Actions의 YAML은 자체 표현식 언어와 문법적 함정이 많음
  • ${{ }} 구문 오류나 문자열 처리 문제로 인해 반복적인 실패 발생
  • 설정 언어가 지나치게 복잡해 실제 프로그래밍 언어처럼 작동하지만 기능은 제한적임

• Marketplace의 보안 위험

  • uses: 구문으로 외부 액션을 불러올 때, 레포지토리와 시크릿 접근 권한을 타인에게 위임
  • 대부분의 액션이 검증되지 않은 쉘 스크립트 형태로 제공되어 신뢰성 낮음
  • 의존성 관리가 불투명하며, 안전하지 않은 코드 실행 가능성 존재

• 컴퓨트 환경의 제약

  • GitHub Actions의 기본 러너는 느리고, 자원 제한이 심하며, 환경 커스터마이징이 불가능
  • 이를 보완하기 위한 서드파티 러너 서비스(Namespace, BuildJet 등)가 다수 등장
  • 자체 호스팅 러너를 사용해도 YAML과 UI 문제는 여전히 남음

세부 기능상의 불편함

• 캐시 관리 불투명성

  • actions/cache의 키 관리가 복잡하고, 캐시 미스나 제거가 명확히 표시되지 않음

• 워크플로 재사용의 한계

  • 중첩 깊이 제한, 컨텍스트 접근 제약, 독립 테스트 불가 등으로 유지보수 어려움

• GITHUB_TOKEN 권한 모델의 혼란

  • 세밀한 권한 설정이 복잡하며, 저장소·워크플로·잡 단위 설정 간 상호작용이 불명확

• 비밀값(Secrets) 처리 제약

  • if 조건문에서 시크릿 사용 불가로 인해 조건부 실행이 어렵고, 우회 로직 필요

• 동시 실행 제어의 단순함

  • 브랜치 단위 취소 외의 세밀한 동시성 제어 불가

Bash 스크립트로의 회귀 문제

• CI 복잡성을 피하려고 모든 작업을 Bash로 처리하려는 시도가 발생
  • 초기에는 단순하지만, 점차 조건문·함수·병렬 처리 등으로 복잡도가 급증
  • 결국 자체 CI 시스템을 Bash로 재구현하게 되어 유지보수 불가능 상태로 전락

Buildkite의 대안적 접근

• 안정적인 로그 뷰어

  • ANSI 색상과 터미널 출력 형식을 그대로 표시하며, 브라우저 충돌 없음
  • 빌드 단계별 주석(Annotations)으로 테스트 요약·배포 링크 등 정보를 직접 표시

• 단순한 YAML 구조

  • YAML은 단순히 파이프라인을 기술하는 데이터 구조로 사용
  • 논리 처리는 별도의 스크립트에서 수행 가능, 구성과 코드의 경계가 명확

• 컴퓨트 환경의 완전한 제어권

  • 에이전트를 자체 인프라에서 실행 가능, 캐시·스토리지·네트워크 모두 직접 관리
  • 대형 EC2 인스턴스나 커스텀 하드웨어 등 다양한 환경에서 실행 가능

• 동적 파이프라인 지원

  • 스크립트가 런타임에 파이프라인 단계를 생성 가능
  • 변경된 파일이나 조건에 따라 빌드 단계를 자동 구성

• 플러그인 구조의 단순성

  • GitHub Actions와 유사하지만, 대부분 얇은 쉘 훅 형태로 구현되어 검토 용이
  • 실행은 자체 인프라에서 이루어져 보안 위험이 상대적으로 낮음

• 사용자 경험 중심의 세부 기능

  • 파이프라인 단계에 커스텀 이모지를 추가할 수 있어 시각적 피드백 제공
  • 개발자가 실제로 사용하는 환경을 고려한 세심한 설계

결론: CI 시스템 선택의 기준

• GitHub Actions는 기본 제공과 접근성 덕분에 시장 점유율을 확보했지만, 품질은 낮음
• Buildkite은 지속적 사용성과 개발자 경험 측면에서 우수함
• 단순한 오픈소스 프로젝트에는 GitHub Actions가 충분하지만,
  대규모 프로덕션 환경에서는 Buildkite이 더 적합
• CI 도구가 개발자의 시간을 소모시키는 구조라면, 문제는 개발자가 아니라 도구 자체임
• “다른 방식으로 일할 수 있다”는 메시지로 글이 마무리됨