# 나는 GitHub Actions가 정말 싫어요 > Clean Markdown view of GeekNews topic #25828. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25828](https://news.hada.io/topic?id=25828) - GeekNews Markdown: [https://news.hada.io/topic/25828.md](https://news.hada.io/topic/25828.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-15T09:42:52+09:00 - Updated: 2026-01-15T09:42:52+09:00 - Original source: [xlii.space](https://xlii.space/eng/i-hate-github-actions-with-passion/) - Points: 10 - Comments: 3 ## Summary **GitHub Actions**의 느린 피드백 루프와 플랫폼별 격리 환경이 개발자의 생산성을 크게 저하시킵니다. **tmplr** 프로젝트에서는 `build.rs`를 통한 자동 문서 생성이 Linux ARM 빌드에서만 실패하며 원인 파악에 수십 분이 소요되었습니다. 결국 CI 로직을 Actions에 맡기지 않고 **GNU Makefile**로 직접 제어하는 방식으로 전환해 문제를 해결했으며, 이는 복잡한 CI 환경에서 단순한 스크립트 제어가 오히려 더 효율적일 수 있음을 보여줍니다. ## Topic Body - **GitHub Actions**의 느린 피드백 루프와 복잡한 디버깅 과정에 대한 개발자의 좌절 경험 공유 - **tmplr** 프로젝트에서 `build.rs`를 통해 CUE로 문서를 생성했으나, CI 빌드가 실패하면서 문제 시작 - 4개 플랫폼 중 **Linux ARM**만 빌드 실패, 원인은 cross build 시 x86_64 바이너리가 arm64 러너에서 숨겨지는 GitHub Actions의 동작 방식 - 단일 변경 사항 테스트에 **2~3분**이 소요되는 비효율적인 피드백 루프 반복 - 해결책으로 `build.rs`를 삭제하고 **GNU Makefile**로 전환, CI 로직을 직접 제어하는 방식으로 문제 해결 --- ### 문제 발생 배경 - **tmplr**은 사람이 읽고 작성할 수 있는 템플릿 파일을 사용하는 파일/프로젝트 스캐폴딩 도구 - `build.rs`에서 **CUE**를 사용해 `README.md`, `CHANGELOG.md`, 버전/도움말 파일을 생성하여 일관성 보장 - 작업 자체는 약 1.5시간 만에 완료되었고, 관련 글도 작성완료 - 로컬에서는 정상 작동했으나, GitHub Actions의 CI 환경에서 **CUE 바이너리 미설치로 빌드 실패** ### 빌드 실패 원인 - 4개 플랫폼(Linux ARM, macOS ARM, Linux x86_64, macOS x86_64) 중 **Linux ARM만 “command not found” 오류** 발생 - 원인: matrix cross build가 강하게 격리되어, CUE는 **x86_64 Linux 호스트**와 **macOS ARM 호스트**에만 설치됨 - macOS는 x86_64 바이너리 실행에 문제없음 - Linux x86_64도 x86_64 바이너리 실행에 문제없음 - 그러나 GitHub Actions는 **arm64 러너에서 x86_64 바이너리를 숨겨** 실행 불가 상태로 만듦 ### 비효율적인 피드백 루프 - 문제 해결을 위해 반복한 과정: 1\. 가능한 수정 방법 검색 2\. `ci.yml` 변경 3\. 커밋 및 푸시 (`jj squash --ignore-immutable && jj git push`) 4\. "Actions" 탭 열기 5\. 최신 실행 열기 6\. Linux ARM 실행 열기 7\. 몇 초 대기 8\. 좌절 9\. 반복 - 단일 변경 사항당 **2~3분** 소요 - 이상적으로는 GitHub가 **모든 기능을 갖춘 로컬 러너**를 제공하거나, 또는 푸시 후 빠르게 진행 상황을 확인할 수 있는 기능을 제공 가능 - **"scratch commit"** 같은 기능: Git 히스토리와 Action 실행 기록을 오염시키지 않고 다양한 실행을 테스트할 수 있는 방법 - 그러나 현재 그런 기능은 존재하지 않음 ### 해결 방법 - 30분간 루프를 반복한 후 중단 - 인터넷에서 알려진 방법 적용: "**GitHub Actions가 로직을 관리하게 하지 말고, 스크립트를 직접 제어하고 Actions는 그 스크립트를 호출만 하게 할 것**" - `build.rs` 삭제 (아쉬움이 있었으나 희생 필요) - 모든 생성 작업을 **GNU Makefile**로 이동 - 생성된 파일들을 저장소에 커밋하고, CI 변경 사항 되돌림 - 문제 해결 완료 ### 결론 - GitHub Actions는 일부 좋은 것들을 가질 수 없게 만드는 원인임 - 러너 디버깅이나 빌드 프로세스 최적화에 많은 시간 손실 - 그러나 다른 방법으로는 얻기 어려운 **macOS 빌드** 같은 이점도 존재함 - 물론, GitHub Actions보다 설정하기 쉬운 다른 시스템은 알려지지 않음 > We are all doomed to GitHub Actions. …but at least I dodged the bullet early. ## Comments ### Comment 49276 - Author: iolothebard - Created: 2026-01-15T22:57:01+09:00 - Points: 2 깃합 액션은 환경 셋업(OS, 빌드툴체인, …)과 스크립트(셸, 파이썬, bat, ps1…) 실행만 해야함. 깃헙이 다운되도 환경만 갖춰지면 어디서나 빌드할 수 있어야 함. 요즘 깃헙 액션 워크플로 보고 있으면 이런거 까지 굳이 찾아서 써야하나 싶음. 먼 옛날(?) ansible이 그러다 망했음. ### Comment 49247 - Author: neo - Created: 2026-01-15T09:42:52+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46614558) - GitHub Actions의 **핵심 문제**는 피드백 루프가 너무 느리다는 점임 단순한 실패를 확인하려고 푸시 후 기다려야 하는 건 정말 답답함 로컬에서 실행 가능한 스크립트로 CI 작업을 분리하고, Actions 기능은 점진적 향상으로만 쓰는 게 좋다고 생각함 `workflow_dispatch`와 `gh workflow run` 조합도 괜찮지만, 후자가 실행된 워크플로의 URL을 바로 주지 않는 건 불편함 - [nektos/act](https://github.com/nektos/act)를 쓰면 로컬에서 Actions를 실행할 수 있음 빠른 피드백을 얻는 데 꽤 성공적이었음 - 나는 Actions가 **도커 이미지**를 빌드하고 테스트하도록 표준화했음 문제가 생기면 GitHub Actions 환경과 거의 동일한 상태에서 디버깅할 수 있음 - CI 단계를 로컬에서 실행할 수 없는 게 말이 안 된다고 생각함 모든 CI 시스템의 **기본 요구사항**이어야 함 - 로컬 실행이 가능한 CI 도구를 직접 만들까 고민한 적 있음 결국 중요한 건 큐잉, 출력 분석, 그리고 **빌드 히스토리 텔레메트리** 같은 기능임 - `gh workflow run`을 쓸 때 URL을 얻으려면 GitHub API로 워크플로 실행 목록을 다시 불러와야 했음 동시에 여러 실행이 있으면 꼬일 수 있지만, 지금은 그럭저럭 잘 작동함 - CI 설계 팁을 정리해봤음 1. bash 대신 **pwsh** 같은 CI 친화적 스크립트 언어 사용 2. 워크플로에는 로직을 넣지 말고 단순하게 유지 3. 독립된 스크립트로 만들어 로컬에서 테스트 가능하게 4. 디버깅을 쉽게 하기 위해 상태 출력과 버전 정보를 남길 것 5. 디버깅 기능이 좋은 서드파티 러너 고려 - (1)은 동의하지 않음. 빌드나 테스트 과정이 복잡해지는 건 **냄새**라고 봄 단순한 셸로 충분해야 함 - (1)에는 동의하지 않지만 (2)는 맞다고 생각함 `Makefile`에 CI 타깃을 정의하고, `make ci-test`처럼 간단히 호출하는 게 좋음 - 예전에 **Jenkins 플러그인 지옥**을 겪은 적 있음 그 이후로는 모든 CI를 `make build` 같은 단순한 래퍼로 관리함 - 단일 스크립트로 모든 빌드를 감싸면 CI 시스템이 **세부 단계 인사이트**를 잃음 `BeginStep("Step Name")` 같은 마커로 구분할 수 있으면 좋겠음 - 결국 이런 구조라면, 스크립트를 직접 실행하는 **새로운 CI 도구**가 필요하지 않을까 생각함 - 문제는 GitHub Actions 자체보다, 그 위에 **엉망으로 얹은 자동화**임 로직은 Python 같은 언어로 스크립트화해서 로컬에서도 실행 가능하게 해야 함 - 많은 사람들이 불만인 건 실패한 VM에 **SSH로 직접 접근해 디버깅**할 수 없다는 점임 매번 워크플로를 수정하고 푸시하고 기다려야 함 - “그런 스크립트화 작업은 돈 받고 할 수 있는 몇 주짜리 일거리”라며 농담하는 사람도 있음 - 배포, 릴리스, 캐싱 같은 **CI 전용 기능**은 로컬에서 완전히 재현하기 어려움 - 이 접근은 마치 **systemd가 init.d 스크립트를 호출**하던 시절의 느낌이지만, 나쁘지 않음 - 어떤 사람은 “이건 100% GitHub Actions의 잘못”이라고 단언함 - 나는 모든 CI를 **컨테이너 안에서** 처리함 CI 플랫폼은 단지 그 컨테이너를 실행할 뿐이라 로컬에서도 동일하게 돌릴 수 있음 플랫폼들은 이런 방식을 싫어함, **벤더 락인**이 깨지니까 - **SourceHut CI**를 좋아함 실패 시 SSH로 바로 접속해 디버깅할 수 있고, 브랜치 푸시 없이 매니페스트를 수정해 재실행 가능함 다만 셀프호스팅이 필요함 - GitLab CI에서도 비슷하게 **전용 도커 이미지**를 만들어 사용했음 표준화는 쉬워지지만 이미지 유지보수라는 트레이드오프가 생김 - 단점은 **macOS 빌드**를 컨테이너화하기 어렵다는 점임 - GitHub의 웹훅은 매우 상세함 사실상 락인은 없는데, 사람들은 **CI/CD 카고컬트**에 빠져 있음 - “이 내용을 뉴스레터로 보내달라”는 반응도 있었음 - 나는 GitHub Actions를 좋아함 예전에 쓰던 Travis보다 낫고, OSS 프로젝트에는 **무료 리소스**로서 매우 유용함 **Nix**를 도입한 이후로 환경 재현성이 높아져서 Actions와의 궁합이 훨씬 좋아졌음 - 나도 Nix 접근법에 동의함 flake로 만든 컨테이너를 Actions에서 그대로 실행할 수 있음 [예시 프로젝트](https://github.com/anttiharju/compare-changes) - GitHub Actions는 단순히 **bash나 python 스크립트를 호출**하는 구조여야 한다고 생각함 bash는 한계가 많고, Python은 더 유연하며 로컬 실행도 쉬움 [이 글](https://paulw.tokyo/standalone-python-script-with-uv/)처럼 uv를 자동 설치하고 의존성을 관리하는 방식이 이상적임 bash보다 복잡하지만 Actions 환경에서는 성능 문제가 크지 않음 - 실제로 YAML은 **런타임 환경 정의용**이고, 실행 로직은 외부 스크립트에 두는 게 맞음 - Actions의 가장 큰 문제는 “워크플로를 조합하라”는 **광고 방식**임 디버깅이 거의 불가능하고, 캐시 설정이 까다로워 빌드가 느려짐 이런 이유로 **지속 VM에서 직접 실행**하는 방식이 매력적으로 느껴짐 - 나는 **Depot**의 창업자임 GitHub Actions 러너를 더 빠르고 저렴하게 제공하는 서비스를 운영 중임 많은 사람들이 느끼는 불만이 실제로 대다수의 의견임 Actions 시스템은 구조적으로 비효율적이고, 매주 새로운 **병목 현상**을 발견함 더 나은 방법이 있다고 확신하며, 이를 실험 중임 자세한 이야기는 [depot.dev](https://depot.dev/)에서 확인 가능함 - 지난 주말에 `gg watch action`이라는 도구를 만들었음 현재 브랜치의 최신 혹은 실행 중인 액션을 찾아주는 툴임 [깃허브 링크](https://github.com/frankwiles/gg) - “이건 `gh` CLI가 되었어야 할 기능”이라며 반응이 좋았음 다만 `gg tui` 명령에서 리포지토리가 안 보이는 버그가 있었음 - `act` 같은 도구가 도움이 될까 궁금했음 [nektos/act](https://github.com/nektos/act) 아키텍처 차이로 로컬과 온라인 실행이 다를 수는 있지만 여전히 유용해 보임 - 예전에 봤을 땐 완전한 대체는 아니었음 약 **80% 정도의 호환성**이 있었음 - 완벽히 동일하진 않지만, **빠른 피드백 루프**를 만드는 데 매우 유용함 - 사실 가장 필요한 건 실패 후 **SSH로 접근해 디버깅**할 수 있는 기능임 SourceHut은 이걸 지원해서 정말 편리함 ### Comment 49400 - Author: anyflow - Created: 2026-01-18T06:29:55+09:00 - Points: 1 yaml안에 로직을 넣어야만 하는 구조이기에 피할 수 없는 이슈인듯 보이네요. 위 글이 답안을 아래와 대강 낸 듯 한데, 스크립트 부분을 Dagger로 치환하면 이게 정답이 아닌가 싶기도. "GitHub Actions가 로직을 관리하게 하지 말고, 스크립트를 직접 제어하고 Actions는 그 스크립트를 호출만 하게 할 것"