단위
1. DevOps 및 Cloud AI 소개: 역할, 경계, 인증, 보안 및 비밀 2. 인공 지능을 사용한 CI/CD 파이프라인 설계: GitHub Actions 및 GitLab CI 3. 코드형 인프라 관리: Terraform 및 IaC를 사용한 인공 지능 4. 컨테이너화: 인공 지능을 통한 Dockerfile 및 이미지 최적화 5. Kubernetes: 매니페스트, Helm 및 AI 기반 오케스트레이션 6. 모니터링 및 관찰 가능성: 지표, 로그, 추적 및 경보 규칙 7. 사고 관리 및 사후 분석: 인공 지능을 통한 근본 원인 분석 8. 클라우드 비용 최적화(FinOps): 인공 지능으로 폐기물 찾기 9. 스크립트 및 자동화 생성: Bash, Python 및 PowerShell 10. 보안 및 비밀 관리: DevSecOps 및 인공 지능 11. 제품 검증, 출시 전략 및 엔드투엔드 AI 워크플로우
단위 2 / 11

인공 지능을 사용한 CI/CD 파이프라인 설계: GitHub Actions 및 GitLab CI

이득:

  • CI/CD 개념, 파이프라인 구조(트리거, 작업, 단계, 실행기, 아티팩트) 및 GitHub Actions와 GitLab CI 간의 차이점을 이해하고 인공 지능이 올바른 컨텍스트로 파이프라인을 생성하도록 하는 능력
  • 인공 지능이 생성한 파이프라인에서 비밀 참조, 권한 및 호출된 구성 요소의 존재를 확인하고 보호하는 기능
  • 비밀을 일반 텍스트로 작성하지 않고, 최소한의 권한을 부여하고, CI와 분리하여 배포를 제어하는 원칙을 적용하는 기능

최신 소프트웨어의 핵심은 코드가 고객에게 안전하게 도달할 때까지 개발자의 컴퓨터를 떠나는 자동화된 파이프라인입니다. 이 파이프를 CI/CD라고 합니다. CI(지속적 통합)는 모든 코드 변경을 자동으로 컴파일하고 테스트하는 것입니다. 그 목적은 개발자가 키보드를 떠나기도 전에 버그를 잡는 것입니다. CD(지속적 전달/배포)는 테스트된 코드의 자동 준비 또는 릴리스입니다. CI/CD 파이프라인은 이러한 단계를 순서대로 정의하는 구성 파일로, 일반적으로 YAML(사람이 읽을 수 있는 구성 텍스트 형식)로 작성됩니다.

이러한 YAML 파일을 직접 작성하는 것은 지루하고 장황하며 오류가 발생하기 쉽습니다. 들여쓰기가 한 칸씩 미끄러지면 전체 파이프라인이 끊어집니다. 이것이 바로 AI가 등장하는 곳입니다. 올바른 컨텍스트를 사용하면 몇 초 만에 작업 초안을 생성합니다. 그러나 생성된 각 단계가 수행하는 작업을 이해하고 확인하는 것이 귀하의 임무입니다. 이는 코드를 프로덕션으로 전달하는 파이프이기 때문입니다.

CI/CD 파이프라인 분석

각 파이프라인은 몇 가지 기본 개념으로 구성됩니다. 다음 사항을 모르면 AI 출력을 제어할 수 없습니다.

  • 트리거: 파이프라인을 시작하는 것은 무엇입니까? 일반적으로 브랜치로의 푸시, 풀 요청(병합 요청) 또는 일정입니다.
  • 작업: 일련의 단계를 실행하는 논리적 단위입니다. 예를 들어 "테스트", "빌드", "배포"입니다.
  • 단계: 작업 내의 단일 명령 또는 작업입니다.
  • 실행기: 작업이 실행되는 가상 머신 또는 컨테이너입니다.
  • 아티팩트: 한 작업에서 생성되고 후속 작업에서 사용되는 출력(예: 컴파일된 파일)입니다.
  • 비밀: 파이프라인이 사용하지만 저장소에 일반 텍스트로 남아 있어서는 안 되는 기밀 정보입니다.

GitHub Actions는 이 정의를 .github/workflows/*.yml 파일에 유지합니다. 단위는 워크플로 → 작업 → 단계 계층입니다. 반면 GitLab CI는 .gitlab-ci.yml 파일에서 stage → job 구조를 사용합니다. AI는 두 가지 구문을 모두 알고 있지만 어느 구문을 원하는지 명시적으로 말해야 합니다.

팁: AI에게 파이프라인을 요청할 때 항상 플랫폼(GitHub Actions 또는 GitLab CI), 언어/프레임워크(노드, .NET, Python…), 트리거 및 배포 여부를 지정하세요. 이 네 가지 정보는 출력의 유용성을 두 배로 늘립니다.

단계별: AI를 사용한 파이프라인 설계

  1. 목표를 명확히 하세요. "메인으로 푸시할 때 테스트를 실행하고 이미지를 빌드하지만 태그가 던져질 때만 배포합니다"와 같습니다.
  2. 해골을 생산해 보세요. 기본적인 작업흐름은 AI에게 물어보세요.
  3. 단계를 읽고 이해하십시오. 각 실행 및 사용 행의 기능을 확인하십시오.
  4. 비밀 참조를 확인하세요. ${{ secrets.NAME }}로 호출된 비밀이 있습니까, 아니면 코드에 포함되어 있습니까?
  5. 로컬/CI를 사용해 보세요. 소규모 테스트 저장소에서 실행하고 빨간색-녹색(실패-통과) 동작을 확인하세요.
  6. 점차적으로 확장하십시오. 먼저 CI(테스트)를 추가한 다음 빌드하고 마지막으로 배포를 추가합니다.

보안: 파이프라인의 비밀 및 권한

CI/CD는 비밀이 가장 많이 유출되는 곳 중 하나입니다. 세 가지 황금률:

  1. YAML에서 일반 텍스트로 비밀을 작성하지 마세요. 플랫폼의 비밀 저장소(GitHub Secrets, GitLab CI/CD 변수)를 사용하고 ${{ secrets.X }}로 호출하세요.
  2. 최소 권한. Pipeline에 제공하는 토큰은 필요한 만큼만 권한을 갖습니다. GitHub Actions에서 권한: 차단을 사용하여 범위를 좁힙니다.
  3. 로그에서 비밀을 누르지 마십시오. echo $TOKEN과 같은 줄은 로그의 비밀을 드러냅니다. 플랫폼 마스크도 조심하세요.
주의: 편의를 위해 AI는 때때로 비밀번호: 123456 또는 지나치게 광범위한 권한: write-all과 같은 포함된 값을 샘플 파이프라인에 넣습니다. 항상 이 문제를 해결하세요. 비밀을 참조로 변경하고 권한을 축소하세요.

비교 차트

개념

GitHub 작업

GitLab CI

구성 파일

.github/workflows/*.yml

.gitlab-ci.yml

건물 단위

작업 흐름 → 작업 → 단계

무대 → 직업

방아쇠

10:

규칙: /만:

소환 비밀

${{ 비밀.NAME }}

$NAME(CI/CD 변수)

준비된 구성 요소

용도: action@v4

포함: /템플릿

주자

실행:

태그:

세 개의 미니 케이스

사례 1 — 6시간 40분으로 단축되었습니다. 팀에서는 수동 테스트-빌드-배포 프로세스를 자동화하고 싶었지만 누구도 YAML에 익숙하지 않았습니다. 그들은 YZ를 "Node.js 프로젝트, GitHub Actions, npm 테스트 및 npm 빌드를 메인으로 푸시하고 v* 태그에만 배포"라고 설명했습니다. AI는 40줄의 작동 뼈대를 생성했습니다. 팀은 모든 단계를 확인하고 40분 만에 실행에 나섰습니다. 손으로 썼다면 하루가 걸렸을 것입니다.

사례 2 — 인증에서 보안 취약점이 발견되었습니다. 엔지니어는 AI에게 워크플로 배포를 요청했습니다. 출력에는 다음과 같은 권한이 포함되었습니다. write-all - 토큰이 저장소, 패키지, 모든 항목에 쓸 수 있음을 의미합니다. 엔지니어는 이를 알아차리고 {contents: read, packages: write } 권한으로 범위를 좁혔습니다. 이를 통해 하이재킹된 종속성이 전체 저장소를 대체하는 위험이 제거되었습니다.

사례 3 — 환각 행동. 한 팀은 AI 제안 사용: actions/deploy-to-aws@v3 라인을 실행했습니다. 그러한 공식적인 조치는 없었으며 AI가 이름을 만들었습니다. "작업을 찾을 수 없습니다"라는 메시지와 함께 파이프라인이 폭발했습니다. Lesson: 다음을 사용하여 호출된 각 구성 요소가 실제로 존재하는지 Marketplace에서 확인합니다.

복사 가능한 템플릿 4개

1) 기본 CI 워크플로:

GitHub Actions용 CI 워크플로를 작성합니다. 프로젝트: [LANGUAGE/FRAMEWORK].트리거: 기본 분기에 대한 푸시 및 풀 요청. 단계: 종속 항목 설치, 테스트 실행, 린트 실행. 아니요 Deploy.Runner 우분투-최신. 비밀은 필요하지 않습니다. YAML에 주석을 답니다.

2) 배포된 CD 작업 흐름(보안):

[PLATFORM]에 대한 배포 워크플로를 작성합니다. 'v*' 태그에서만 작동해야 합니다. 대상: [미디어/클라우드]. 규칙: - 절대 일반 텍스트로 비밀을 작성하지 말고 ${{ 비밀로 호출하세요.

3) 기존 파이프라인을 설명합니다.

다음 [플랫폼] 파이프라인을 한 줄씩 설명하십시오. 각 작업은 무엇을 수행하고, 어떤 순서로 실행되며, 어떤 비밀을 사용하며, 가장 위험한 두 가지 지점은 무엇입니까? 마지막으로 3가지 개선 사항을 제안합니다.파이프라인: [YAML CONTENT]

4) 파이프라인 속도 향상:

다음 CI 파이프라인이 느리게 실행되고 있습니다(기간: [X분]). 캐시 사용량, 병렬 작업 및 불필요한 단계를 검사합니다. 구체적이고 실행 가능한 가속화 제안 5개를 제시하고 각각의 예상 영향을 기록해 보세요. 파이프라인: [YAML]

약한 프롬프트 / 강한 프롬프트

약함: "GitHub Actions 워크플로 작성"

결과: 어떤 언어, 어떤 트리거, 배포 여부가 명확하지 않습니다. AI는 일반 Node 인스턴스를 제공하지만 프로젝트에 적합하지 않을 수 있으며 비밀을 하드코딩할 수 있습니다.

Strong: "GitHub Actions 워크플로 작성. Python 3.12 프로젝트, 풀 요청 및 기본 푸시에서 pytest + ruff 실행, 배포 없음, pip 캐시로 종속성 가속화, 비밀 필요 없음. 주석과 함께 YAML 내보내기."

차이점: 두 번째 프롬프트는 언어, 트리거, 범위(배포 없음), 성능 기대치 및 보안 제약 조건을 제공합니다. 출력이 직접 작동합니다.

일반적인 실수

  • YAML에 비밀을 삽입합니다. 일반 텍스트 비밀번호/토큰은 가장 일반적인 CI 취약점입니다.
  • 지나치게 광범위한 허가. 모두 쓰기 대신 필요한 최소 권한을 부여하십시오.
  • 존재하지 않는 작업/템플릿에 의존합니다. AI가 만든 용도를 확인하세요: Marketplace의 라인.
  • CI와 배포를 혼동합니다. 푸시할 때마다 테스트를 실행할 수 있지만 배포를 제어하고 승인해야 합니다.
  • 캐시를 사용하지 않습니다. 각 실행 시 처음부터 종속성을 설치하면 파이프라인이 몇 분씩 느려집니다.
  • 기본 저장소에서 직접 첫 번째 워크플로를 시도합니다. 먼저 테스트 저장소에서 실행하세요.

요약하면

CI/CD 파이프라인은 코드를 프로덕션으로 안전하게 이동하고 YAML로 정의되는 자동화된 파이프입니다. AI는 GitHub Actions 및 GitLab CI에 대한 작업 청사진을 신속하게 생성하지만 플랫폼, 언어, 트리거 및 배포 범위를 명확히 해야 합니다. 보안에는 세 가지 규칙이 있습니다. 참조로 비밀 호출, 최소 권한 부여, 로그에 비밀을 인쇄하지 않음. 각 use:/include: 구성 요소가 실제로 존재하는지와 각 단계의 기능을 확인하는 것은 귀하의 책임입니다.

응용과제

간단한 샘플 프로젝트를 선택하세요(귀하의 언어로 "hello world"도 가능합니다). 위의 "기본 CI 워크플로" 템플릿을 사용하여 AI가 워크플로를 생성하도록 하세요. 그런 다음 (1) 각 단계의 역할을 자신의 말로 적어 보십시오. (2) 비밀이 포함되어 있지 않고 권한이 좁은지 확인합니다. (3) 가능하다면 시험탱크에 넣고 적록색의 거동을 관찰한다.

체크리스트

  • [ ] 프롬프트에 플랫폼, 언어/프레임워크, 트리거 및 배포 범위를 추가했습니다.
  • [ ] 생성된 YAML에서 각 작업과 단계가 수행하는 작업을 이해합니다.
  • [ ] 어떤 비밀도 일반 텍스트가 아닙니다. 모든 ${{ secrets.X }} / CI 변수.
  • [ ] 권한을 최소한의 권한으로 좁혔습니다.
  • [ ] 호출된 모든 액션/템플릿이 실제로 존재하는지 확인했습니다.
  • [ ] 배포 단계를 승인/보호로 제어하도록 만들었습니다.
이전 다음