지속적 전달·배포

약자가 같아 섞이지만 다른 것이다.

전달의 핵심은 "언제든 가능한 상태"

지속적 전달이 보장하는 것은 배포 빈도가 아니라 준비 상태다. 릴리스를 한 달에 한 번 하더라도, 그 한 번이 "며칠간 준비해서" 가 아니라 "버튼 한 번" 이면 전달이 되고 있는 것이다.

반대로 배포할 때마다 손으로 설정을 고치고 파일을 옮긴다면, 아무리 자주 배포해도 전달이 아니다. 자동화 여부가 아니라 재현 가능성이 기준이다.

배포는 그 승인마저 없앤 것

지속적 배포는 사람의 판단을 파이프라인이 대신한다는 뜻이다. 그러려면 자동 검증이 사람의 눈을 대신할 만큼 촘촘해야 한다. 테스트가 얇은 상태에서 승인만 없애면 그건 지속적 배포가 아니라 지속적 사고다.

그래서 순서가 있다 — 전달을 먼저 확립하고, 검증에 대한 신뢰가 쌓인 뒤에 승인을 걷어 낸다. 대신 되돌리는 길을 확실히 마련해 둔다. 자동 롤백이나 카나리 없이 지속적 배포로 가는 것은 안전망 없이 외줄을 타는 것과 같다.

되돌리는 길이 먼저다

배포를 자동화하기 전에 답해야 할 질문이 있다 — 잘못됐을 때 몇 분 만에 되돌릴 수 있나.

• 이전 버전의 산출물이 그대로 남아 있나
• DB 마이그레이션이 되돌릴 수 있는 형태인가 (컬럼 삭제는 되돌리기 어렵다)
• 되돌리는 절차가 자동화돼 있나, 아니면 문서에만 있나

앞으로 가는 속도만 올리고 되돌아오는 길을 안 만들면, 사고가 났을 때 자동화가 피해를 더 빨리 퍼뜨리는 장치가 된다.

스키마 변경은 배포와 분리한다

코드는 되돌려도 DB 는 안 되돌아간다. 그래서 스키마 변경은 여러 단계로 쪼갠다.

① 새 컬럼 추가 (기존 코드는 모른다)      → 배포해도 안전
② 양쪽에 쓰는 코드 배포                  → 되돌려도 안전
③ 읽기를 새 컬럼으로 전환
④ 한참 뒤 옛 컬럼 삭제

각 단계가 앞뒤 버전과 모두 호환되므로 어느 시점에 되돌려도 깨지지 않는다.

어느 쪽을 골라야 하나

기술 성숙도만의 문제가 아니다.

• 규제 산업 — 승인 기록 자체가 요구사항일 수 있다 → 전달
• 내부 도구·SaaS — 되돌리기 쉽고 영향 범위가 작다 → 배포
• 모바일 앱 — 스토어 심사가 끼어 자동화 자체가 제한된다

파이프라인의 표준 모양

커밋 → 빌드 → 단위 테스트 → 아티팩트 생성
     → 스테이징 배포 → 통합·E2E → [승인] → 운영 배포 → 관측

아티팩트 생성 지점이 경계다. 그 앞은 "만드는 일", 그 뒤는 "옮기는 일" 이다. 이 경계가 흐려져 배포 단계에서 다시 빌드하면 앞의 검증이 무의미해진다.

마지막 관측 단계를 빼놓기 쉬운데, 배포는 나가는 것으로 끝나지 않는다. 오류율과 지연이 배포 전과 같은지 확인해야 그 배포가 성공한 것이다. 이 확인이 자동이면 카나리·자동 롤백으로 이어진다.

면접 함정

• ❌ "CD 는 하나다" → 전달과 배포는 다르다. 갈리는 지점은 승인 단계다.
• ❌ "지속적 배포가 더 발전된 형태" → 되돌릴 수단과 검증 신뢰도가 전제다. 상황에 따라 전달이 정답이다.
• ❌ "자주 배포하면 전달이 되고 있는 것" → 매번 손이 들어가면 아니다.