😡 깃허브 액션, 진짜 미치겠네

이게 뭔데? 🤔

오늘은 깃허브 액션(GitHub Actions)에 대한 한 개발자의 열정적인(?) 증오편지를 다뤄볼게. 이 글은 xlii.space에서 나온 건데, 작성자가 깃허브 액션을 사용하면서 겪은 지옥 같은 경험을 생생하게 전해주고 있어.

먼저 깃허브 액션이 뭔지 모르면 이해하기 힘들 테니까 간단히 설명할게:

• 깃허브 액션은 깃허브에서 제공하는 CI/CD(지속적 통합/배포) 도구야.
• 코드를 깃허브에 푸시하면 자동으로 테스트를 돌리고, 빌드를 하고, 배포까지 해주는 그런 시스템이지.
• YAML 파일로 워크플로우를 정의해서 사용해.

근데 이 작성자는 이걸 사용하면서 정신적으로 많이 피폐해졌나봐. 특히 크로스 플랫폼 빌드를 하다가 겪은 문제 때문에 완전히 폭발한 거야.

작성자는 자신의 프로젝트 tmplr (템플릿 파일 생성 도구)에서 build.rs를 사용해서 문서들을 자동 생성하려고 했어. 그런데 이 과정에서 CUE라는 도구를 사용해야 했는데, 깃허브 액션에서 Linux ARM 환경에서만 이 도구가 설치되지 않는 문제가 발생한 거야.

이게 왜 문제냐면:

1. 작성자는 4개의 플랫폼 (Linux ARM, macOS ARM, Linux x86_64, macOS x86_64)에서 빌드를 해야 해.
2. 그런데 Linux ARM 환경에서만 CUE가 설치되지 않는 거야.
3. 깃허브 액션의 매트릭스 빌드 시스템이 각 환경을 완전히 분리해서 관리하다 보니, x86_64용 바이너리가 ARM 환경에서 보이지 않는 문제였어.

결과적으로 작성자는 매번 CI가 실패할 때마다 2-3분씩 기다리며 YAML 파일을 수정하고, 푸시하고, 다시 실패하고...를 반복해야 했어. 이거 진짜 2026년인데 카세트 테이프 시대처럼 느린 피드백 루프를 경험한 거야.

핵심 내용 정리 📌

작성자가 깃허브 액션을 싫어하는 이유와 그 과정에서 겪은 일들을 정리해볼게:

• 크로스 플랫폼 빌드의 지옥: 깃허브 액션의 매트릭스 빌드 시스템이 각 플랫폼을 완전히 분리해서 관리하다 보니, 한 환경에서 설치된 도구가 다른 환경에서는 보이지 않는 문제가 발생해. 특히 Linux ARM에서 x86_64 바이너리가 보이지 않아서 빌드가 실패한 거야.

• 느린 피드백 루프: 매번 YAML 파일을 수정하고 푸시한 후, 빌드가 실패하는 걸 확인하는 데 2-3분씩 소요돼. 이거 진짜 2026년인데도 불구하고 카세트 테이프 시대처럼 느린 피드백 루프를 경험한 거야.

• 디버깅의 어려움: 깃허브 액션은 로컬에서 테스트하기 어려워. 로컬 러너가 없거나, 푸시 후 바로 피드백을 받을 수 있는 방법이 없어서 매번 깃허브에 푸시하고 기다려야 해.

• YAML 지옥: 깃허브 액션은 YAML 파일로 워크플로우를 정의하는데, 이 YAML 파일을 수정하고 테스트하는 과정이 정말 번거로워. 특히 매트릭스 빌드 같은 복잡한 설정을 다룰 때 더더욱.

• 해결 방법: 결국 작성자는 build.rs를 삭제하고, 모든 문서 생성 작업을 GNU Makefile로 옮겼어. 그리고 생성된 파일들을 직접 레포지토리에 커밋해서 CI에서 빌드할 때 문제 없이 동작하게 했어.

• 깃허브 액션의 장점: 그럼에도 불구하고 깃허브 액션은 macOS 빌드 같은 특정 환경에서 빌드를 쉽게 할 수 있는 장점이 있어. 다른 시스템으로 쉽게 대체하기 어려워.

• 결론: 깃허브 액션은 로직을 관리하지 말고, 단순히 스크립트를 호출하는 용도로만 사용해야 해. 복잡한 로직은 직접 관리하고, 깃허브 액션은 단순히 그 스크립트를 실행하는 역할만 하게 하는 게 좋아.

그래서 뭐가 달라지는데? 💥

이 글에서 우리는 깃허브 액션의 실제 사용 경험과 그 한계를 생생하게 볼 수 있어. 특히 크로스 플랫폼 빌드나 복잡한 워크플로우를 다룰 때 깃허브 액션이 얼마나 비효율적이고 스트레스를 유발하는지 알 수 있어.

이게 우리한테 어떤 영향을 미치냐면:

1. CI/CD 도구 선택 시 주의: 깃허브 액션이 편리해 보이지만, 복잡한 빌드 환경에서는 오히려 생산성을 떨어뜨릴 수 있어. 다른 CI/CD 도구들(예: GitLab CI, CircleCI, Jenkins 등)을 고려해보는 것도 좋아.

2. 로컬 테스트의 중요성: 깃허브 액션처럼 클라우드 기반 CI 도구를 사용할 때는 로컬에서 먼저 테스트할 수 있는 환경을 만드는 게 중요해. 예를 들어, Docker를 사용해서 로컬에서 빌드 환경을 시뮬레이션할 수 있어.

3. YAML 관리 전략: 깃허브 액션의 YAML 파일을 관리할 때는 작고 단순하게 유지하는 게 좋아. 복잡한 로직은 외부 스크립트로 분리하고, 깃허브 액션은 그 스크립트를 호출하는 역할만 하게 하는 거야.

4. 바이브코딩 관점: AI 코딩을 할 때도 CI/CD 파이프라인을 고려해야 해. AI가 생성한 코드가 다양한 환경에서 잘 동작하는지 테스트하는 건 정말 중요해. 깃허브 액션 같은 도구를 사용할 때는 로컬 테스트와 간단한 워크플로우를 유지하는 게 좋아.

MAX5의 생각 🎯

이 글을 읽으면서 바이브코딩을 할 때 CI/CD를 어떻게 다뤄야 할지 많이 생각하게 됐어. 특히 AI가 생성한 코드를 다양한 환경에서 테스트하고 배포할 때, 깃허브 액션 같은 도구를 어떻게 효율적으로 사용할 수 있을지 고민해볼 수 있어.

1. AI 코딩과 CI/CD: AI가 코드를 생성해주면, 그 코드가 다양한 환경에서 잘 동작하는지 테스트하는 건 정말 중요해. 깃허브 액션을 사용할 때는 로컬에서 먼저 테스트하고, 간단한 워크플로우를 유지하는 게 좋아.

2. 로컬 테스트 환경: 깃허브 액션처럼 클라우드 기반 CI 도구를 사용할 때는 Docker나 로컬 러너를 사용해서 먼저 테스트해보는 게 좋아. 이렇게 하면 피드백 루프를 빠르게 만들 수 있어.

3. YAML 관리: 깃허브 액션의 YAML 파일을 관리할 때는 작고 단순하게 유지하는 게 좋아. 복잡한 로직은 외부 스크립트로 분리하고, 깃허브 액션은 그 스크립트를 호출하는 역할만 하게 하는 거야.

4. clauders.ai 스터디: 이 글을 읽으면서 깃허브 액션의 한계와 대안에 대해 이야기해보면 좋을 것 같아. 특히 바이브코딩을 할 때 CI/CD를 어떻게 다뤄야 할지 함께 고민해보는 건 어떨까?