Hacker News 의견

• GHA(GitHub Actions)를 옹호하고 싶진 않지만, 문서에는 안정성과 보안을 위해 커밋 SHA 고정을 권장한다고 명시되어 있음
  직접 lock 파일처럼 구현할 수는 있지만, transitive dependency는 제어 불가능하므로 완전하지 않음
  결국 보안 패치 추적과 해시 갱신의 부담이 생기며, 이런 이유로 해시 기반 고정이 널리 쓰이지 않는 듯함

  • GitHub은 Actions 출시 직후부터 이 문제를 알고 있었음에도, 버전 고정 기능을 실질적으로 개선하지 않았음
    대부분의 사용자는 문제를 인식하지 못하고, 인식한 사람도 SHA를 거의 사용하지 않음
    나는 개인적으로 Actions를 좋아하고 몇 가지를 유지보수하지만, 공개 저장소를 보면 90%가 @v1, 9%가 @v1.2, 1%만 커밋 SHA를 씀
    GitHub이 조금만 투자해도 lock 파일 솔루션을 만들 수 있었을 것임
  • 문서의 전략은 transitive dependency 문제를 해결하지 못하므로, 실제로는 근본적인 해결책이 아님
  • 커밋 SHA 고정이 안정적이라는 말은 현실적으로 틀림
    종종 특정 Node 버전이나 API 버전에 의존하기 때문에, 오히려 @main을 쓰는 게 더 나았던 경험이 있음
  • SHA를 쓰는 건 오히려 안티 패턴이라고 생각함
    “고정된 버전”을 얻는다고 착각하지만 실제로는 그렇지 않음
    두 번이나 문제를 겪고 나서 깨달았음 — lock 파일이 있거나 없거나 둘 중 하나임

• GitHub이 자체 Actions를 거의 유지보수하지 않고, 기본 기능조차 비공식 포크에 의존하게 됨
  생태계 전체가 임시방편으로 유지되는 느낌임

  • 이런 상황은 당분간 나아지지 않을 듯함
    GitHub이 기능 개발보다 Azure 마이그레이션을 우선시한다고 발표했기 때문임
    관련 기사
  • 흥미로운 점은 GitHub이 꽤 비싼 서비스라는 것임
    우리 소규모 회사도 매달 200달러 이상을 지불함
    Windows보다 GitHub 구독이 더 중요한 신규 수익원으로 여겨지는 듯함
  • setup- actions*의 품질이 눈에 띄게 떨어졌고, 이상한 결정이 많아짐
    아마 원 저자들이 이미 회사를 떠난 듯함
  • 이런 얘기는 처음 들었는데, 혹시 구체적인 예시가 있는지 궁금함
  • 최근 GitHub이 AI 개발에 집중하기 위해 일반 기능 개발 속도를 늦춘다고 발표하지 않았는지?

• 혹시 ArgoCD를 CI 파이프라인으로 써본 사람이 있는지 궁금함

• GHA는 ‘less is more’ 철학의 실패 사례라고 생각함
  업계 표준이 된 게 가장 큰 문제임
  조금만 투자해도 훨씬 나은 CI를 만들 수 있었는데, MS가 IE6 시절의 실수를 반복한 느낌임
  이제는 비교 경험이 없는 젊은 엔지니어 세대가 그 한계를 인식하지 못함

  • GHA가 정말 형편없다는 데 모두 동의하지만, 무료 컴퓨팅 리소스가 제공된다는 점 때문에 다들 계속 씀
    나는 은퇴한 노트북을 Woodpecker 서버로 돌려볼 생각임. 사람들이 싫어하지 않는 CI가 어떤지 궁금함
  • 예전에는 VSS를 써야 했던 세대라서, 지금의 GitHub조차 그때보단 훨씬 나은 환경이라고 느낌
  • 나는 대부분의 작업을 로컬에서 직접 수행하는 편임
    GHA는 그에 비해 별다른 가치가 없는 것 같음

• 회사가 Jenkins/Ansible에서 GHA로 옮기려 했을 때 반대했는데, 지금 보니 잘한 선택 같음
  CI는 항상 유지보수 부담이 크고, 특히 Mac 환경은 여전히 다루기 까다로움

• “GitHub이 올바른 SHA 코드를 제공한다고 믿는가?”라는 질문에,
  대부분이 GitHub 호스팅 러너를 쓰는 현실을 보면, 그걸 믿지 못한다면 이미 더 큰 문제가 있는 셈임

• 만약 GitHub Actions가 로컬 우선(local-first) 구조로, Nix 기반 잠금(locking) 을 지원한다면 어떨까 하는 생각이 듦
  cachix/cloud.devenv.sh

  • 아이러니하게도 그 코드조차 GitHub에 호스팅되어 있음

• 많은 서드파티 Actions가 문서나 예제에서 master 브랜치를 직접 참조함
  악의적인 푸시 한 번이면 수많은 저장소에서 데이터 유출이 가능함
  태그를 써도 이동 가능하므로 완전한 방어는 아님

• 연구자들이 말한 CI/CD의 네 가지 핵심 보안 속성(인증, 실행, 코드, 비밀 접근)을 보며 의문이 생김
  CI/CD가 정말 비밀(secrets) 에 접근할 필요가 있을까?
  API 호출 권한만 있으면 충분하다고 생각함
  이상적인 시스템은 비밀을 직접 다루지 않고, 보안 엔클레이브 같은 어댑터를 통해 간접적으로 처리해야 함

  • “좋은 CI는 비밀을 지원하지 않아야 한다”는 말은 결국 복잡한 비밀 관리 방식을 제안하는 셈임
    현실적으로 고객 대부분은 여전히 비밀을 필요로 함
  • 이론적으로는 맞지만, 실제로 사람들은 CI/CD에 비밀을 넣을 수밖에 없음
    플랫폼이 최소한 안전한 비밀 관리 메커니즘을 제공해야 함
    특히 오픈소스 프로젝트는 CI에서 직접 배포를 원하기 때문임
  • 우리 회사는 QNX 컴파일러나 Coverity 같은 상용 도구를 쓰는데, 이들은 라이선스 서버 접근을 위해 비밀이 필요함
    “보안 엔클레이브 방식”이 구체적으로 어떻게 다른지 궁금함
  • CI/CD가 인프라와 완전히 통합되어 있다면 비밀 없이도 배포가 가능하겠지만,
    현실적으로는 환경마다 다르고 구현 비용이 커서 대부분은 컨테이너 + 환경변수 방식으로 정착됨
  • 여러 클라우드 DB와 호환성을 테스트하려면 각 DB에 접근할 자격 증명이 필요함
    이런 테스트를 자동화하려면 비밀이 불가피함

• lock 파일을 저장소에 커밋해야 한다면, 처음 생성 시점에 부트스트래핑 문제가 생김
  이를 해결하려면 Actions를 로컬에서 실행할 수 있는 기능이 필요함
  nektos/act 같은 도구가 있지만, 이는 주로 디버깅용임
  아마도 정적 분석 기반의 별도 메커니즘이 필요할 것임