라떼군 이야기
GitHub Actions가 당신의 엔지니어링 팀을 서서히 망가뜨리는 이유 (그리고 대안)
TL;DR GitHub Actions는 높은 점유율을 자랑하지만, 끔찍한 로그 뷰어, 느린 피드백 루프, 복잡한 YAML 문법으로 개발자의 생산성을 저해하고 있습니다. 저자는 ‘거대한 Bash 스크립트’로 도피하는 것은 더 큰 재앙을 초래한다고 경고하며, Buildkite나 Nix 같은 본질에 충실한 CI 도구의 가치를 재조명합니다.
오늘날 GitHub Actions는 사실상 CI/CD의 표준이 되었습니다. 리포지토리에 기본 내장되어 있다는 압도적인 접근성 때문입니다. 하지만 우리가 이것을 사용하는 이유가 정말 ‘좋아서’일까요, 아니면 그저 거기에 ‘있어서’일까요? CircleCI 초기 멤버이자 수많은 CI 도구를 섭렵한 Ian Duncan이 GitHub Actions의 불편한 진실과 개발자 경험(DX)을 해치는 요소들을 신랄하게 비판한 글을 분석해봅니다.
핵심 내용
저자는 가장 먼저 로그 뷰어의 끔찍한 성능을 지적합니다. 브라우저를 멈추게 하고, 스크롤이 불가능하며, 에러를 찾기 위해 수많은 페이지를 클릭해야 하는 ‘관료주의적’ UX를 비판합니다. 또한, YAML 문법과 독자적인 표현식 언어는 불필요하게 복잡하고 디버깅이 어려워 개발자의 오후 시간을 낭비하게 만듭니다. 마켓플레이스는 검증되지 않은 코드를 실행하게 만드는 보안 위협(npm of CI)이며, **기본 러너(Compute)**는 느리고 비싸서 별도의 최적화 스타트업들이 생겨날 정도라고 꼬집습니다. 마지막으로, 이에 지쳐 거대한 Bash 스크립트를 짜는 것은 가드레일 없는 복잡성을 만드는 것이라며 경고합니다.
기술적 인사이트
이 글은 단순한 불평을 넘어 ‘통합의 편리함’이 ‘도구의 본질적 품질’을 어떻게 가리는지를 날카롭게 지적합니다. GitHub Actions는 접근성이 좋지만, 디버깅 용이성과 피드백 루프 속도라는 CI의 핵심 가치를 희생시켰습니다. 특히 ‘Bash 스크립트로 도피하지 말라’는 조언은 매우 중요한 기술적 통찰입니다. CI의 복잡성을 피하겠다고 거대한 Bash 스크립트를 작성하면, 테스트 프레임워크도 구조도 없는 곳으로 복잡성을 옮기는 꼴이 되어 기술 부채를 가중시키기 때문입니다. 결국 좋은 CI는 도구가 투명하게 작동하고, 로그가 정직하며, 개발자가 인프라 설정이 아닌 코드 자체에 집중하게 해줘야 한다는 원칙을 상기시킵니다.
시사점
현재 GitHub Actions를 사용 중이라면, 팀의 생산성 저하가 도구의 한계 때문일 수 있음을 인지해야 합니다. 느린 빌드 속도는 Namespace나 BuildJet 같은 서드파티 러너 도입으로 해결하고, 복잡한 YAML 로직은 신중하게 관리해야 합니다. 또한, 새로운 프로젝트를 시작하거나 CI 고통이 극심하다면, 무조건적인 GHA 도입보다는 Buildkite나 Nix 같이 개발자 경험(DX)이 우수한 대안을 진지하게 검토하여 팀의 리소스를 아끼는 전략이 필요합니다.
CI는 개발 흐름을 돕는 도구여야지, 극복해야 할 장애물이 되어서는 안 됩니다. ‘남들이 다 쓰니까’라는 이유로 팀의 소중한 시간을 낭비하고 있지는 않은지, 편리함에 속아 본질을 놓치고 있는 건 아닌지 되돌아볼 시점입니다.