나는 Github Actions를 열정적으로 싫어한다
Source: Dev.to
GitHub Actions를 얼마나 싫어하는지 과장해서 말할 수 없습니다. 제가 사용했던 다른 어떤 기술을 싫어했던 기억도 없습니다. 물론 PHP 4 시절을 떠올리면 아직도 PHP를 비웃지만1, 그때조차도 싫어한 것은 아니었습니다—그저 Ruby on Rails나 Django 같은 신생 프레임워크에 비해 수준이 낮다고 생각했을 뿐이죠. 그런데도 저는 GitHub Actions를 싫어합니다.
열정적으로2.
지옥으로 가는 길
이 글을 쓰기 전날 나는 내 tmplr 프로젝트를 위해 build.rs를 구현하고 있었다. 클릭을 한 번 덜어드리자면—이 도구는 사람이 읽을 수 있고(그리고 만들 수 있는) 템플릿 파일을 제공하는 파일/프로젝트 스캐폴드 툴이다. 나는 (개인적으로) 새 템플릿을 손으로 만들든 도구의 도움을 받든 매우 쉽게 만들 수 있기 때문에 자주 사용한다. 비슷한 유틸리티가 필요하면 한 번 살펴보라.
build.rs는 CUE를 사용해 README.md, CHANGELOG.md, 그리고 버전/도움말 파일을 생성해 일관성을 보장했다. 재미있는 작업이었고 약 1.5시간 정도 걸렸으며, 나는 심지어 이에 대해 글을 썼다 — 나 자신과 미래 세대를 위해.
결과에 만족했지만 CI 출력은 확인하지 않았고, 예상대로 실패했다. 나는 build.rs 안에서 cue 바이너리를 사용하고 있었고, 그것이 없으면 빌드가 진행될 수 없었다. 다음 날 일어나서 CI가 보낸 빌드 실패 알림 이메일을 보자마자, 오늘이 강아지와 무지개로 시작되지 않을 것이라는 걸 바로 알았다.
몇 차례 시도 끝에 CUE를 설치하는 GitHub Action을 찾아 푸시했지만, 최악의 결과를 맞았다: 매트릭스 안의 한 시스템이 빌드에 실패했다.
설명 한 마디
나는 tmplr를 네 가지 플랫폼용으로 빌드하고 있다:
- Linux ARM
- macOS ARM
- Linux x86_64
- macOS x86_64
이해가 되지? 내 사용자 기반이 한 팔도 없는, 두 번째 팔에 갈고리가 달린 해적의 손가락으로 셀 수 있을 정도라고 해도, “해야 할 일”은 여전히 존재한다.
그런데 Linux ARM 작업이 “명령을 찾을 수 없습니다”라는 오류로 실패했다. CUE는 다른 세 대상에서는 정상적으로 설치되고 실행됐지만, 이유는 알 수 없게도 Linux ARM에서는 실패했다.
왜 내가 GitHub을 싫어하는지 왜가 궁금하지 않을 수도 있지만, “무슨 일이 있었나”가 궁금하다면 알려주겠다—왜냐면 나는 알고 있기 때문이다.
매트릭스에서 일어나는 교차 빌드는 매우 격리되어 있다. CUE를 설치할 때 나는 x86_64 Linux 호스트와 macOS ARM 호스트에만 설치한다. macOS는 x86_64 바이너리를 실행하는 데 전혀 문제가 없고, Linux x86_64도 x86_64 바이너리를 실행할 때 문제가 발생하지 않는다. 하지만 GitHub Actions는 arm64 러너에게 x86_64 바이너리를 숨겨 주어 깨지는 일을 방지한다.
고마워, GitHub Actions. 당신 없이는 내가 무엇을 했을까?
깨진 루프
그리고 내 가장 싫어하는 피드백 루프가 시작되어 이렇게 진행되었습니다:
- 가능한 해결책을 검색한다
ci.yml을 변경한다jj squash --ignore-immutable && jj git push3- Actions 탭을 연다
- 최신 실행을 연다
- Linux ARM 실행을 연다
- 몇 초 기다린다
- 삶을 혐오한다
- 우주에 곧 잊히지 않을 선택의 말을 건넨다
- 반복한다
나는 8번과 9번 단계에서는 꽤 효율적이었지만, 전체 루프는 단일 변경당 약 2~3분 정도 걸렸다.
네—단일 변경에 대해. 마치 저장 지연이 2분인 편집기를 쓰는 것, 카세트 테이프 위에서 실행되는 프로그램으로 커밋을 푸시하는 것4, 혹은 우편으로 체스를 두는 것과 같다. 2026년이니, 제발, 우리는5 이런 행동을 용납하지 않는다!
물론, 이상적인 세상이라면 GitHub에 모든 기능을 갖춘 로컬 러너가 있거나, 푸시 시 진행 상황을 빠르게 확인할 수 있는 무언가6, 혹은 “스크래치 커밋”—Git과 Action 실행 기록을 오염시키지 않고 다양한 실행을 테스트할 수 있는 방법이 있을 것이다.
하지만 그런 완벽한 세상은 존재하지 않으며, 우리는 냉혹한 YAML 기반 시스템의 변덕에 휘둘리고 있다.
Breaking Off
나는 그런 루프를 30분만 겪었다. 더 오래 할 수도 있었지만, 색다른 표현이 부족해졌고, 그게 없으면 과정이 똑같이 느껴지지 않는다.
인터넷에 현명한 말이 있다:
신성한 모든 것을 위해, GitHub Actions가 당신의 로직을 관리하게 하지 마라. 스크립트를 직접 제어하고, Actions는 그 스크립트를 호출하도록 하라!
이것이 모두가 해야 할 일이다. 이것이 내가 한 일이다.
나는 build.rs를 슬프게도 삭제했다(정말 멋졌지만—희생은 필요했다). build.rs에서 하던 모든 생성을 GNU Makefile로 옮겼고, 새로운 파일들을 저장소에 커밋한 뒤 CI 변경 사항을 되돌렸다. 그리고 하루를 마무리했다. 문제 해결.
Exit Code: 0
GitHub Actions, 친구들, 그리고 신사숙녀들은 우리가 (일부) 좋은 것을 가질 수 없는 이유다. 러너를 디버깅하거나 빌드 과정을 최적화하려다 잃어버린 시간을 셀 수가 없다. 매번 안타까운 과정이며, 그 시간은 다른 곳에 더 잘 쓰일 수 있다.
그럼에도 macOS 빌드처럼 다른 방법으로는 얻기 힘든 이점도 있다. GitHub Actions보다 설정이 더 쉬운 시스템을 나는 모른다(알고 있다면 알려 주세요), 하지만 탈출구는 없는 것 같다.
우리는 모두 GitHub Actions에 운명 지워졌다…
…하지만 적어도 나는 일찍 총알을 피했다.