CI · CD

CI이란?

CI/CD가 들어오면 가장 먼저 바뀌는 것은 코드가 아니라 팀의 일정표입니다. 배포가 '금요일 밤에 다 같이 모여서 치르는 행사'에서 '평일 낮에 스무 번쯤 지나가는 일'로 내려앉습니다. 한 번에 나가는 변경 덩어리가 작아지니 장애가 나도 원인 후보가 몇 줄로 좁혀지고, 되돌리는 데 걸리는 시간도 짧아집니다. 달라지는 건 속도보다 '되돌릴 수 있다'는 감각이고, 그때부터 개발자가 손대기 무서웠던 코드를 손대기 시작합니다.

CD는 두 갈래로 갈립니다. Continuous Delivery는 언제든 내보낼 수 있는 상태까지 자동화하되 마지막 출고 버튼은 사람이 누르고, Continuous Deployment는 검사를 통과하면 승인 없이 그대로 운영에 올립니다. 규제 심사나 변경관리 대장이 걸린 금융·의료 쪽은 대개 앞쪽을 택합니다. 현실적인 조건도 하나 있습니다. 빌드부터 테스트까지 10분 안에 끝나야 개발자가 결과를 기다리지, 30분씩 걸리면 다들 다음 작업으로 넘어가 버려 CI는 껍데기만 남습니다. 잘 돌아가는지는 배포 빈도, 변경 리드타임, 변경 실패율, 복구 시간 네 가지로 봅니다. CI/CD는 도구이고, 데브옵스는 그 도구를 굴리는 일하는 방식이라는 경계도 헷갈리지 않는 편이 좋습니다.

처음부터 전 구간을 자동화할 필요는 없습니다. 보통 자동 빌드 → 자동 테스트 → 스테이징 자동 배포 → 운영 배포 순으로 한 칸씩 올리고, 운영 단계에는 카나리(일부 사용자에게만 먼저 열기)나 블루·그린(구버전을 켜둔 채 전환)을 붙여 사고가 미치는 범위 자체를 줄입니다. 바이브 코딩처럼 호스팅 서비스에 저장소를 연결해 쓰는 환경이라면 CD 절반은 이미 기본으로 딸려 오는 셈이라, 남은 숙제는 검사 단계를 채우는 일입니다.

가장 자주 어긋나는 지점은 '자동화했으니 안전하다'는 착각입니다. 테스트가 비어 있는 파이프라인은 불량품을 더 빠르게 내보내는 장치일 뿐입니다. 빨간 빌드를 방치한 채 '급하니 강제 병합'을 몇 번 반복하면 두 달 뒤엔 아무도 테스트 결과를 믿지 않고, 브랜치를 2주씩 묵혔다가 한꺼번에 합치면 이름만 통합이지 충돌 지옥은 그대로입니다. 배포 키나 DB 비밀번호를 설정 파일에 박아둔 채 저장소를 공개로 돌려 운영 DB 접속 정보가 통째로 새는 사고도 드물지 않습니다. 롤백을 한 번도 연습해 보지 않은 조직은 첫 장애 때 결국 새벽에 서버로 직접 붙습니다.