GitLab CI 작성 시 AI 활용하기: 시간 절약 및 실수 방지

GitLab CI YAML은 한 시간 동안 뚫어지게 쳐다보며 95%를 정확하게 작성했더라도, 탭(tab) 문자 하나 때문에 yaml: line 12: did not find expected key 오류를 내며 실패할 수 있는 형식 중 하나입니다. AI 어시스턴트(AI assistants)는 이런 종류의 작업에 매우 빠릅니다. 하지만 무엇을 확인해야 할지 모른다면, 특정 GitLab 기능에 대해 아주 자신 있게 틀린 답을 내놓아 많은 시간을 낭비하게 만들기도 합니다.

Claude가 제 파이프라인(pipelines)의 상당 부분을 작성하도록 한 지 1년이 지난 지금, 무엇이 잘 작동하고 무엇이 그렇지 않은지에 대해 말씀드리겠습니다.

AI가 일관되게 잘하는 것

표준 작업 형태 (Standard job shapes)

"Docker 이미지를 빌드하고, GitLab Container Registry에 푸시하며, 기본 브랜치(default branch)에서 커밋 SHA와 latest 태그를 붙이는 작업을 작성해줘."라고 Claude에 입력하면 5초 만에 작동하는 작업(job)을 얻을 수 있습니다. 이 형태는 이미 잘 정립되어 있으며, 모델은 수천 가지의 변형을 학습했습니다.

다음과 같은 경우도 마찬가지입니다:

• 다양한 언어에 걸친 테스트 작업 (pytest, jest, go test 등)
• 표준 캐시(cache) 설정
• 표준 아티팩트(artifact) 패턴
• 브랜치 / 태그 / MR 파이프라인을 위한 기본적인 rules:

만약 여러분이 이러한 것들을 처음부터 직접 작성하고 있다면, 불필요한 시간을 쓰고 있는 것입니다.

다른 CI로부터의 변환

GitLab CI는 GitHub Actions, CircleCI, Jenkins 선언적 파이프라인(declarative pipelines) 등과 명백한 유사점이 있습니다. AI는 이들 사이의 변환에 매우 뛰어납니다. 구조가 유사하기 때문에 모델은 그 '사전'을 알고 있습니다.

만약 Actions에서 GitLab CI로 마이그레이션 중이라면, 워크플로(workflow)를 붙여넣고 GitLab CI에 해당하는 코드를 요청하세요. 그러면 여러분이 다듬을 수 있는, 80% 정도 정확한 결과물을 얻을 수 있습니다.

비효율적인 파이프라인 검토

이것은 과소평가된 활용 사례입니다. .gitlab-ci.yml 파일을 붙여넣고 다음과 같이 물어보세요: "이 파이프라인의 임계 경로(critical path)는 무엇이며, 무엇이 속도를 느리게 만들고 있나요?" 그러면 모델은 다음과 같은 것들을 찾아낼 것입니다:

• "테스트 작업(test job)은 캐시(cache)에서 node_modules를 다운로드하지만, install-deps는 캐시에 푸시하지 않습니다. 즉, 캐시 키(cache key)가 잘못되었습니다."
• "빌드(build)와 배포(deploy) 단계가 순차적이지만, 빌드의 아티팩트(artifacts)가 배포에서 사용되지 않습니다. needs:를 사용하여 병렬로 실행할 수 있습니다."
• "rules:changes:에 package-lock.json이 포함되어 있지 않아, 의존성(dependency) 변경 시 테스트가 다시 트리거되지 않습니다."

이것들은 제가 이미 최적화했다고 생각했던 파이프라인들에 대해 Claude로부터 직접 얻어낸 실제 결과물들입니다. 5분 정도 검토할 가치가 충분합니다.

AI가 틀리는 부분 — 그리고 이를 잡아내는 방법

rules: vs only/except 혼동

모델은 가끔 동일한 작업(job) 내에서 이 둘을 섞어서 사용하곤 합니다. GitLab은 rules:가 정의되어 있으면 only:를 조용히 무시합니다. 파이프라인은 실행되지만 동작은 예상과 다르게 나타납니다.

체크 사항: 각 작업에서 rules: 또는 only:/except: 중 하나만 사용하고 있나요? 하나만 선택하세요. (rules:를 사용하세요. only/except는 레거시(legacy) 방식입니다.)

MR 파이프라인에서 $CI_COMMIT_BRANCH가 비어 있는 문제

흔히 발생하는 버그입니다.

이 방식은 main 브랜치에서는 작동하지만, 태그(tags), 스케줄(schedules), 그리고 MR 파이프라인(MR pipelines)에서는 작업을 차단합니다. 때로는 이것이 의도한 바일 수도 있지만, 대개의 경우 그렇지 않습니다.

확인 사항: 이 작업이 실행되기를 기대하는 파이프라인 소스(pipeline sources)는 무엇입니까? 이를 나열한 다음, 작성한 규칙(rules)이 각각을 포함하는지 확인하십시오.

가상의 GitLab 기능들

이것은 가장 비용이 많이 드는 AI 실패 모드(failure mode)입니다. 모델은 때때로 존재하지 않는 기능에 대한 구문을 생성하곤 합니다:

• GitLab CI가 아니라 실제로는 OPA/Conftest인 condition: 필드
• GitLab이 아니라 GitHub Actions인 auto_retry: 블록
• 존재하기는 하지만 모델이 주장하는 것과는 다른 의미론(semantics)을 가진 before_script: 키워드

확인 사항: GitLab 문서에서 본 적 없는 키워드가 보인다면, 실제로 존재하는지 확인하십시오. 린트(lint) 엔드포인트(/api/v4/ci/lint)가 이러한 문제의 대부분을 잡아내지만, 일부는 린트를 통과하고도 그냥 이상하게 동작할 수 있습니다.

실패를 저렴하게 잡아내는 워크플로(workflow)

저는 이제 사소하지 않은 모든 파이프라인 변경 사항에 대해 다음과 같이 수행합니다:

1. AI로 초안 작성. 원하는 동작을 평이한 영어로 설명하고, 모델이 YAML을 작성하게 합니다.
2. 모든 줄을 읽기. 출력물을 직접 작성한 초안처럼 취급하십시오.
3. API를 통해 린트(Lint) 수행.

   curl -s --header "PRIVATE-TOKEN: $TOKEN" \
       --header "Content-Type: application/json" \
       --data "{\"content\": $(cat .gitlab-ci.yml | jq -Rs .)}" \
...

4. 샌드박스(sandbox) 브랜치에서 실행. 배포를 트리거하지 않는 브랜치에 푸시하여, 파이프라인이 예상한 시점에 예상한 작업들을 실행하는지 확인하십시오.
5. 기존 파이프라인과 차이점(diff) 비교. 만약 AI가 요청하지 않은 변경 사항(다른 캐시 키(cache key), 삭제된 interruptible: 등)을 도입했다면, 이를 되돌리십시오.

5단계는 대부분의 사람들이 건너뛰는 단계입니다. 모델은 YAML을 작성하는 데는 능숙하지만, 사용자의 이전 결정 사항을 보존하는 데는 능숙하지 않습니다. 차이점(diff)을 비교하지 않으면, 기존의 캐시 전략을 잃게 될 것입니다.

실질적인 예시

지난달에 저는 모든 MR에서 terraform plan을 실행하고 그 결과를 댓글로 게시하는 작업을 추가해야 했습니다. Claude를 사용하여 2분 만에 초안을 작성했고, 다음과 같은 결과물이 나왔습니다:

terraform-plan:
  image: hashicorp/terraform:1.9
  stage: plan
...

이것은 거의 맞았습니다. 두 가지 문제가 있었습니다:

1. CI 변수로서의 PRIVATE-TOKEN — CI에 개인 액세스 토큰 (Personal Access Token)을 사용하는 것은 구식 패턴입니다. 현대적인 접근 방식은 인스턴스 내부 API 호출 시 $CI_JOB_TOKEN을 사용하는 것입니다. 이렇게 하면 토큰 교체 (Rotation)의 번거로움을 줄일 수 있습니다.
2. terraform init -backend-config 누락 — 백엔드가 코드 내에 구성되어 있다면 작동하겠지만, 동일한 모듈을 사용하는 여러 환경이 있는 경우 어떤 백엔드를 사용할지 지정해야 합니다.

두 가지 수정 사항 모두 30초면 충분합니다. AI가 없었다면 curl 호출문을 작성하는 데만 15분을 썼을 것입니다.

결론

AI가 GitLab CI에 대한 지식을 대체하는 것은 아닙니다. AI는 타이핑과 상용구 (Boilerplate)를 제거하여, 여러분이 중요한 부분인 rules: 로직, 캐시 키 (Cache keys), 비밀 정보 (Secrets), 환경 승격 (Environment promotion)에 집중할 수 있게 해줍니다.

위에서 언급한 실패 모드 (Failure modes)를 내재화하고 나면, 워크플로우는 대부분 자동화됩니다. 상용구를 읽는 대신 규칙 (Rules)을 읽기 시작하게 됩니다. 버그는 바로 그곳에 존재합니다.

GitLab CI에 특화되어 우리가 사용하는 프롬프트 세트는 GitLab CI/CD 카테고리 — 특히 gitlab-pipeline-optimization 및 gitlab-ci-rules-debugging을 참조하세요.

이 기사는 원래 DevOps AI ToolKit — 클라우드 엔지니어를 위한 실용적인 AI 워크플로우 — 에 게시되었습니다.