CI 설정을 YAML로 짜는 건 이제 그만 고통받자는 얘기

• 글쓴이의 핵심 주장은 간단함. CI/CD 파이프라인에 YAML을 쓰는 건 실패하기 쉬운 구조라는 것임

  • YAML은 처음 보면 선언적이고 쉬워 보임
  • 그래서 GitHub Actions 같은 CI 시스템에서 표준처럼 굳어졌음
  • 그런데 실제로는 조건 분기, 재사용, 데이터 흐름, 작업 순서 같은 프로그램 로직을 YAML 안에 계속 우겨 넣게 됨

• 문제는 YAML이 프로그래밍 언어가 아니라는 데 있음

  • CI 설정이 작을 때는 checkout, install, test 정도라서 별 문제가 없어 보임
  • 하지만 프로젝트가 커지면 매트릭스 빌드, 캐시, 조건부 배포, 환경별 분기, 재사용 워크플로가 들어감
  • 이쯤 되면 YAML은 설정 파일이 아니라 테스트하기 힘든 미니 프로그램이 됨. 근데 디버거도 타입 시스템도 빈약함

• 글쓴이는 대안으로 Pkl과 Dhall을 언급함

  • 둘 다 아직 엄청 mainstream은 아니라고 선을 긋고 있음
  • 대신 YAML이나 JSON을 출력할 수 있어서, 기존 CI 시스템을 그대로 두고 설정 작성 방식만 바꿀 수 있음
  • 즉 GitHub Actions가 YAML을 요구해도, 사람이 직접 YAML을 다 쓰지 않고 더 나은 언어에서 생성하는 접근이 가능함

• 이 접근이 CI의 모든 문제를 해결하는 건 아님

  • 글쓴이도 오늘날 CI 시스템 자체의 복잡성은 별도 문제라고 봄
  • 그래도 YAML이 가진 많은 문제를 줄이면서, 선언적이고 제한적인 설정 언어의 장점은 유지할 수 있다고 평가함
  • 완전한 혁명보다는 “지금 있는 CI를 덜 고통스럽게 쓰는 현실적 개선”에 가까움

• 참고할 만한 다른 논의들도 같이 제시됨

  • Alexey Kladov의 CI Dream, CI in a Box 글
  • Gregory Szorc의 Modern CI is Too Complicated and Misdirected
  • YAML을 쓰지만 더 나은 기본 구성 요소를 제공한다는 RWX
  • 빌드 시스템 논의에서 자주 언급되는 논문 Build Systems à la Carte

• 한국 개발팀에도 바로 와닿는 얘기임

  • 스타트업이든 대기업이든 GitHub Actions, GitLab CI, CircleCI 같은 YAML 기반 파이프라인을 굴리는 곳이 많음
  • 처음엔 복붙으로 빨리 시작하지만, 몇 년 지나면 CI 파일이 팀의 암묵지 저장소가 됨
  • 그 상태에서 장애가 나면 애플리케이션 코드보다 CI YAML 읽는 시간이 더 오래 걸리는 황당한 상황도 충분히 생김

---

기술 맥락

• 이 글에서 말하는 선택은 “CI를 바꾸자”가 아니라 “CI가 먹는 YAML을 사람이 직접 쓰는 방식을 바꾸자”에 가까워요. 기존 CI 서비스는 그대로 두되, Pkl이나 Dhall 같은 언어로 설정을 작성하고 결과만 YAML로 뽑는 방식이거든요.

• 왜 이런 얘기가 나오냐면 CI 설정은 시간이 지날수록 로직이 되기 때문이에요. 브랜치별 조건, 배포 환경, 캐시 키, 테스트 매트릭스가 쌓이면 단순 설정이 아니라 작은 프로그램인데, YAML은 그런 프로그램을 안전하게 다루도록 만들어진 도구가 아니에요.

• Pkl이나 Dhall 같은 대안은 타입, 재사용, 구조화를 통해 실수를 줄이려는 쪽이에요. 사람이 최종 YAML을 손으로 만지는 대신 더 검증 가능한 원본을 두면, 반복되는 CI 패턴을 함수나 모듈처럼 관리할 수 있어요.

• 다만 이 방식도 공짜는 아니에요. 팀원이 새 언어를 배워야 하고, 생성된 YAML과 원본 설정 사이를 디버깅해야 하거든요. 그래서 작은 프로젝트보다는 CI 파일이 이미 길고, 여러 저장소에서 비슷한 파이프라인을 복붙하고 있는 팀에 더 잘 맞아요.