CI/CD란? 지속적 통합과 배포를 쉽게 설명

CI/CD는 모든 코드 변경을 자동으로 빌드하고 테스트한 뒤, 통과하면 출시를 준비하거나 실제로 출시하는 소프트웨어 배포 방식입니다. **CI(지속적 통합)**는 변경 사항을 자주 병합하고 매번 자동 테스트로 확인하는 것을 뜻합니다. **CD(지속적 전달 또는 배포)**는 통과한 변경을 패키징해 사용자에게 적은 수작업으로 전달하는 것을 뜻합니다.

핵심은 단순합니다. 실수는 몇 주 뒤 고객이 발견할 때가 아니라, 만들어진 지 몇 분 안에 잡아내는 것입니다.

AI로 만들 때 CI/CD가 중요한 이유

AI 빌더는 코드 변경을 빠르게 만듭니다. 프롬프트 한 번으로 파일 열 개를 건드릴 수도 있습니다. 이 속도는 좋지만, 결제 페이지를 고치다가 로그인 페이지가 몰래 깨지고, 사용자가 메일을 보내기 전까지 아무도 모르는 상황도 생길 수 있습니다.

CI/CD는 바로 이런 상황을 막는 안전망입니다. 각 변경을 믿는 대신, 파이프라인이 매번 같은 검사를 실행합니다.

• 앱이 여전히 오류 없이 빌드되나요?
• 자동화 테스트가 여전히 통과하나요?
• 코드가 프로젝트의 규칙(타입, 포맷, 보안 검사)을 따르나요?

어느 검사라도 실패하면 변경은 사용자에게 도달하기 전에 멈춥니다. 코드가 빠르게 바뀔수록, 지치지 않고 단계를 건너뛰지 않는 검사의 가치는 더 커집니다.

일상의 비유

매일 아침 가게에 빵을 공급하는 빵집을 떠올려 보세요.

• CI/CD가 없다면, 각 제빵사가 일주일 동안 자기만의 레시피를 조금씩 바꿉니다. 그리고 금요일 밤에 모두의 변경을 한꺼번에 합치고 빵이 잘 부풀기를 바랍니다. 실패하면 누구의 변경 때문인지 아무도 모릅니다.
• CI가 있다면, 레시피 변경 하나하나를 곧바로 테스트 빵으로 구워 맛, 무게, 모양을 확인합니다. 나쁜 변경은 같은 날 잡히고, 정확히 어떤 변경이었는지도 알 수 있습니다.
• CD가 있다면, 검사를 통과한 빵만 배달 차량에 실리는데, 매번 같은 방식으로 포장되고 라벨이 붙습니다. 새벽 5시에 누군가 손으로 상자를 싸는 일은 없습니다.

검사가 제빵사를 더 잘하게 만드는 것은 아닙니다. 대신 실수의 비용을 낮춥니다.

CI/CD 파이프라인의 작동 방식

파이프라인은 CI/CD 서비스가 어떤 일이 생겼을 때 자동으로 실행하는 단계들의 목록입니다. 보통 누군가 GitHub 같은 저장소에 코드를 푸시할 때 실행됩니다. 전형적인 파이프라인은 다음과 같습니다.

각 단계는 누군가의 노트북이 아니라 깨끗한 기계에서 실행되므로, "내 컴퓨터에서는 잘 됩니다"라는 변명이 통하지 않습니다. 단계가 실패하면 파이프라인이 멈추고 변경을 만든 사람에게 알립니다.

단계들은 코드와 함께 있는 설정 파일에 정의됩니다. 예를 들어 GitHub Actions에서는 저장소의 .github/workflows 폴더에 있는 YAML 파일입니다.

지속적 전달 vs 지속적 배포

"CD"는 모호해서 사람들이 두 가지 뜻으로 씁니다.

지속적 배포는 테스트가 충분히 좋을 때만 잘 작동합니다. 테스트가 결제 과정을 다루지 않는다면, 지속적 배포는 고장 난 결제 기능도 아무 거리낌 없이 배포해 버립니다.

실제 예시: 예약 앱의 파이프라인

미용실 예약 앱이 있고, 코드가 GitHub 저장소에 있다고 해 봅시다. AI 빌더에게 "처음 방문한 고객에게 10% 할인을 추가해 줘"라고 요청합니다.

1. 변경 사항이 새 브랜치에 푸시되고 풀 리퀘스트가 열립니다.
2. 파이프라인이 시작됩니다. 패키지를 설치하고 앱을 빌드합니다. 이 단계는 통과합니다.
3. 테스트를 실행합니다. "재방문 고객은 정상 가격을 낸다"는 테스트가 실패합니다. 할인이 모든 고객에게 적용되고 있습니다.
4. 풀 리퀘스트에 빨간 X 표시가 뜹니다. 변경은 병합될 수 없습니다.
5. AI에게 수정을 요청합니다. AI가 수정 사항을 푸시하고, 파이프라인이 다시 실행되며 모든 것이 통과합니다.
6. 변경이 병합됩니다. 파이프라인이 이를 **스테이징 환경**에 배포하고, 여러분은 테스트 예약을 해 봅니다.
7. 승인하면 운영 환경에 배포됩니다.

파이프라인이 없었다면, 3단계의 문제는 고객의 지갑에서 일어났을 것입니다.

핵심 용어

흔한 오해

• "CI/CD가 있으니 내 앱은 테스트된 것이다." 파이프라인은 여러분이 가진 테스트만 실행합니다. 테스트가 없다면 CI는 앱이 빌드된다는 것만 증명합니다. 가장 중요한 흐름에 대한 테스트를 AI에게 작성해 달라고 요청하세요.
• "CI/CD는 대기업만 쓰는 것이다." GitHub Actions 같은 호스팅 도구는 짧은 설정 파일로 구성할 수 있어서 작은 팀도 자주 씁니다. 노력이 드는 것은 도구가 아니라 테스트입니다.
• "자동 배포는 아무것도 확인하지 않는다는 뜻이다." 좋은 파이프라인은 검사를 줄이지 않고 더합니다. 많은 팀이 운영 배포 전에 사람의 승인 단계를 유지합니다.
• "파이프라인이 초록색이면 앱이 작동한다." 자동 검사가 통과했다는 뜻일 뿐입니다. 변경 사항은 미리보기나 스테이징에서 직접 시도해 보아야 합니다.
• "CI/CD가 백업을 대신한다." 그렇지 않습니다. 테스트를 통과한 잘못된 데이터베이스 마이그레이션도 실제 데이터를 망가뜨릴 수 있습니다. 백업과 롤백 방법을 유지하세요.

AI 빌더에게 요청할 내용

• "회원가입, 로그인, 결제 흐름에 대한 자동화 테스트를 작성하고, 실행 방법도 보여 줘."
• "모든 풀 리퀘스트에서 의존성 설치, 앱 빌드, 테스트 실행을 하는 GitHub Actions 워크플로를 설정해 줘."
• "파이프라인에 타입 검사와 린터를 추가하고, 오류가 나면 실패하게 해 줘."
• "파이프라인의 각 단계가 무엇을 하는지 쉬운 말로 설명해 줘."
• "배포가 중간에 실패하면 어떻게 되나요? 어떻게 롤백하나요?"
• "비밀 값이 저장소에 하드코딩되거나 파이프라인 로그에 출력되지 않는지 확인해 줘."

앱이 API 키를 사용한다면 파이프라인에도 키가 필요합니다. 이때 키는 설정 파일이 아니라 CI 도구에 암호화된 비밀 값으로 저장해야 합니다. 환경 변수와 비밀 값을 참고하세요.

Mythex에서의 CI/CD

Mythex는 여러분을 위해 CI 파이프라인을 실행하지 않지만, 같은 필요 중 몇 가지를 자체 방식으로 충족합니다.

• 체크포인트. 에이전트의 각 작업이 성공하면 Mythex가 git 체크포인트를 저장하고, 이 시점으로 되돌리기로 변경이 잘못되었을 때 프로젝트를 롤백할 수 있습니다. 채팅을 참고하세요.
• 앱 테스트. /test를 입력하면 에이전트가 라이브 미리보기에서 사용자처럼 클릭하며 흐름을 확인하고, 깨진 흐름을 보고합니다. 게시하기 전에 유용합니다. 앱 테스트를 참고하세요.
• 게시는 의도적인 단계입니다. 변경 사항은 먼저 비공개 미리보기에 나타나며, 공개 앱은 다시 게시할 때만 업데이트됩니다. 지속적 배포보다는 지속적 전달에 가깝습니다.
• GitHub 동기화(Pro). 프로젝트를 GitHub 저장소에 동기화하면, 푸시할 때마다 테스트를 실행하도록 자체 GitHub Actions 워크플로를 추가할 수 있습니다. GitHub 및 내보내기를 참고하세요.

출시 전에 직접 확인할 항목 목록은 출시 전 앱 테스트 방법을, 버전 관리 작업은 AI로 만든 앱에서 Git 사용하는 방법을 참고하세요.

자주 묻는 질문