Hacker News 의견들

• GitHub Actions의 핵심 문제는 피드백 루프가 너무 느리다는 점임
  단순한 실패를 확인하려고 푸시 후 기다려야 하는 건 정말 답답함
  로컬에서 실행 가능한 스크립트로 CI 작업을 분리하고, Actions 기능은 점진적 향상으로만 쓰는 게 좋다고 생각함
  workflow_dispatch와 gh workflow run 조합도 괜찮지만, 후자가 실행된 워크플로의 URL을 바로 주지 않는 건 불편함

  • 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에서 그대로 실행할 수 있음
    예시 프로젝트

• GitHub Actions는 단순히 bash나 python 스크립트를 호출하는 구조여야 한다고 생각함
  bash는 한계가 많고, Python은 더 유연하며 로컬 실행도 쉬움
  이 글처럼 uv를 자동 설치하고 의존성을 관리하는 방식이 이상적임
  bash보다 복잡하지만 Actions 환경에서는 성능 문제가 크지 않음

  • 실제로 YAML은 런타임 환경 정의용이고, 실행 로직은 외부 스크립트에 두는 게 맞음

• Actions의 가장 큰 문제는 “워크플로를 조합하라”는 광고 방식임
  디버깅이 거의 불가능하고, 캐시 설정이 까다로워 빌드가 느려짐
  이런 이유로 지속 VM에서 직접 실행하는 방식이 매력적으로 느껴짐

• 나는 Depot의 창업자임
  GitHub Actions 러너를 더 빠르고 저렴하게 제공하는 서비스를 운영 중임
  많은 사람들이 느끼는 불만이 실제로 대다수의 의견임
  Actions 시스템은 구조적으로 비효율적이고, 매주 새로운 병목 현상을 발견함
  더 나은 방법이 있다고 확신하며, 이를 실험 중임
  자세한 이야기는 depot.dev에서 확인 가능함

• 지난 주말에 gg watch action이라는 도구를 만들었음
  현재 브랜치의 최신 혹은 실행 중인 액션을 찾아주는 툴임
  깃허브 링크

  • “이건 gh CLI가 되었어야 할 기능”이라며 반응이 좋았음
    다만 gg tui 명령에서 리포지토리가 안 보이는 버그가 있었음

• act 같은 도구가 도움이 될까 궁금했음
  nektos/act
  아키텍처 차이로 로컬과 온라인 실행이 다를 수는 있지만 여전히 유용해 보임

  • 예전에 봤을 땐 완전한 대체는 아니었음
    약 80% 정도의 호환성이 있었음
  • 완벽히 동일하진 않지만, 빠른 피드백 루프를 만드는 데 매우 유용함
  • 사실 가장 필요한 건 실패 후 SSH로 접근해 디버깅할 수 있는 기능임
    SourceHut은 이걸 지원해서 정말 편리함