CI/CD

배포가 한 사람의 일이던 시절이 있었습니다. 개발자가 자기 노트북에서 고친 파일을 서버에 직접 밀어 넣었고, 어떤 파일을 어떤 순서로 올리는지, 무엇을 지우고 무엇을 다시 켜야 하는지가 전부 그 사람의 머릿속에 있었습니다. 순서를 하나 건너뛰면 서비스가 멈췄고, 그 사람이 휴가를 가면 팀 전체가 배포를 못 했습니다.

합치는 일도 사람의 일이었습니다. 각자 자기 컴퓨터에서 2~3주씩 코드를 들고 있다가 마감 직전에 한꺼번에 모았습니다. 세 사람이 같은 파일을 고쳐 두었으니 어느 줄을 살릴지 한 줄씩 손으로 골라야 했고, 그 작업에만 이틀이 갔습니다. 겨우 합쳐 놓으면 각자 돌릴 때는 멀쩡하던 기능이 함께 있을 때 깨지는 일이 또 흔했습니다. 이 구간을 두고 통합 지옥이라는 말이 생겼습니다.

두 가지가 겹치면 악순환이 생깁니다. 합치는 것도 올리는 것도 무서우니 드물게 합니다. 드물게 하니 한 번에 들어가는 변경 덩어리가 커집니다. 덩어리가 크니 뭔가 깨졌을 때 어느 변경 탓인지 찾기 어렵고, 찾기 어려우니 다음번엔 더 무서워집니다. 분기에 한 번 배포하는 팀은 그 한 번에 커밋 300개를 올립니다. 화면이 하얗게 뜨면 용의자가 300명인 셈입니다.

페이지덱도 초기에는 그랬습니다. 태오가 금요일 저녁에 고친 파일을 서버로 올리고 화면이 뜨는 것만 확인한 뒤 퇴근합니다. 월요일 아침에 수아가 고객사에서 결제가 안 된다는 연락을 받아 옵니다. 지난주에 무엇이 바뀌었는지부터 알아내야 하는데 바꾼 사람의 기억 말고는 남은 기록이 없습니다. 되돌리려 해도 되돌릴 지점이 없어서, 결국 태오가 기억을 더듬어 한 줄씩 원래대로 고칩니다.

CI/CD 는 이 두 가지를 사람 손에서 떼어 기계에 넘기자는 발상입니다. 합치는 일을 2주에 한 번이 아니라 하루에 여러 번으로 잘게 쪼갭니다. 한 번에 부딪히는 양이 적어야 충돌이 이틀이 아니라 5분짜리 일이 되기 때문입니다. 그리고 합칠 때마다 기계가 대신 검사하고, 검사를 통과하면 그대로 서버까지 잇습니다. 배포를 사람이 마음먹고 치르는 행사가 아니라, 코드를 올리면 저절로 따라오는 일로 바꾼 것입니다.

CI/CD 아래 묶인 말은 세 갈래로 나뉩니다. 자동 흐름이 어디까지 가느냐가 단계, 그 흐름을 이루는 부품이 구성, 마지막 한 걸음에서 사용자 쪽을 어떻게 갈아 끼우느냐가 배포 전략입니다.

단계는 이름이 서로 닮아서 가장 자주 헷갈리는 갈래입니다. 셋은 경쟁하는 방식이 아니라 자동화가 뻗는 거리의 차이입니다.

1. 지속적 통합 — 각자 고친 코드를 하루에 한 번 이상 공용 가지에 합치고, 합칠 때마다 기계가 빌드와 테스트를 돌립니다. 영어 머리글자를 따 CI 라고 부릅니다. 여기까지는 검사만 하고 사용자 쪽으로는 아무것도 나가지 않습니다.
2. 지속적 전달 — 검사를 통과한 결과물을 언제든 내보낼 수 있는 상태로 늘 준비해 둡니다. 실제로 내보내는 순간에는 사람이 버튼을 누릅니다. 고객사에 미리 공지해야 하거나 마케팅 일정에 맞춰야 하는 팀이 여기서 멈춥니다.
3. 지속적 배포 — 그 버튼마저 없앱니다. 검사를 통과하면 사람 손 없이 운영 서버까지 갑니다. 하루에 열 번씩 나가는 팀이 이 모양인데, 대신 문제를 빨리 알아채고 되돌리는 장치가 먼저 갖춰져 있어야 합니다.

뒤의 두 말은 영어 약자가 둘 다 CD 라서 글로 볼 때 구분이 안 됩니다. 어느 쪽인지는 마지막에 사람이 누르는 버튼이 있느냐로 갈립니다. 대화에서 애매하면 "운영까지 자동으로 나가나요" 하고 물으면 됩니다.

구성은 무엇으로 굴러가느냐를 다루는 갈래입니다. 여섯 가지가 여기 들어갑니다.

1. 파이프라인 — 빌드·테스트·배포를 순서대로 엮어 둔 자동 흐름입니다. 코드가 올라오면 1단계부터 차례로 밟고, 한 단계가 실패하면 뒷단계로 넘어가지 않고 그 자리에서 멈춥니다. 테스트가 깨진 코드가 서버까지 가지 못하게 막는 것이 이 멈춤입니다.
2. 빌드 — 사람이 읽으라고 쓴 소스 코드를 기계가 실행할 수 있는 형태로 바꾸는 과정입니다. 이 과정이 실패하면 문법이 틀렸거나 필요한 부품이 빠진 것이라 테스트까지 갈 것도 없이 끝납니다.
3. 아티팩트 — 빌드가 뱉어 낸 결과물 덩어리입니다. 검사한 물건과 서버에 올라가는 물건이 같아야 하므로, 한 번 만든 아티팩트를 스테이징에도 운영에도 그대로 씁니다. 환경마다 새로 빌드하면 검사를 통과한 것과 다른 물건이 올라갈 수 있습니다.
4. 환경 — 개발·스테이징·운영처럼 목적이 다른 실행 공간입니다. 스테이징은 운영과 최대한 비슷하게 꾸며 두고 진짜 사용자 대신 팀이 들어가 봅니다. 여기서 걸러진 문제는 고객이 겪지 않습니다.
5. 환경 변수 — 환경마다 다르게 꽂아 주는 설정 값입니다. 코드는 한 벌인데 스테이징은 시험용 결제 서버를 보고 운영은 진짜 결제 서버를 보게 만드는 것이 이 값입니다.
6. 시크릿 관리 — 그 설정 값 중에서도 새면 안 되는 것, 그러니까 결제 키나 데이터베이스 비밀번호를 따로 금고에 넣고 필요한 순간에만 꺼내 쓰게 하는 일입니다. 코드 저장소에 키를 적어 두면 저장소를 열 수 있는 사람 전부가 그 키를 갖게 됩니다.

배포 전략은 파이프라인이 마지막 한 걸음에서 고르는 방법입니다. 사용자가 쓰고 있는 도중에 갈아 끼우는 일이라, 도중에 화면이 멈추는지와 잘못됐을 때 얼마나 빨리 되돌리는지가 여기서 갈립니다.

1. 블루-그린 배포 — 같은 규모의 환경을 두 벌 두고, 새 코드를 놀고 있는 쪽에 통째로 올린 다음 사용자 통로를 한 번에 그쪽으로 돌립니다. 문제가 보이면 통로를 원래 쪽으로 되돌리면 끝이라 복구가 몇 초입니다. 대신 서버 비용이 두 배로 듭니다.
2. 롤링 배포 — 서버가 열 대라면 두 대씩 새 코드로 갈아 끼우며 다섯 번에 걸쳐 넘어갑니다. 여분 환경이 필요 없어 비용이 싸지만, 넘어가는 중간에는 옛 코드와 새 코드가 동시에 돌고 있어 둘이 같이 있어도 괜찮게 만들어 두어야 합니다.
3. 프리뷰 배포 — 사용자에게 가기 전 단계입니다. 변경 하나마다 임시 주소를 띄워 그 변경만 반영된 화면을 보여 줍니다. 디자이너와 기획자가 코드를 읽지 않고도 확인할 수 있어서, 합치기 전에 되돌리는 값이 가장 싼 자리가 여기입니다.

세 갈래는 따로 고르는 메뉴가 아니라 한 줄로 이어집니다. 통합이 자주 일어나야 파이프라인이 자주 돌고, 파이프라인이 아티팩트를 하나 만들어 두어야 환경을 옮겨 다니며 같은 물건을 검사할 수 있고, 검사가 끝난 그 물건을 어떤 방식으로 갈아 끼울지가 배포 전략입니다.

"이 PR 은 CI 가 빨간불이라 아직 못 합칩니다. 테스트 두 개가 깨져 있어요."

자동 검사가 실패했으니 리뷰를 부탁하기 전에 만든 사람이 먼저 고쳐야 한다는 뜻입니다.

"이번 건은 자동 배포 말고 전달까지만 걸어 둘게요. 고객사 공지가 수요일이라서요."

파이프라인을 운영 직전까지만 돌리고 마지막 버튼은 수요일에 사람이 누르겠다는 뜻입니다.

"프리뷰 링크 붙여 뒀어요. 합치기 전에 거기서 먼저 봐 주세요."

이 변경만 반영된 임시 주소가 떠 있으니 코드 대신 화면으로 확인해 달라는 요청입니다.

페이지덱에서 태오가 문서 목록의 정렬 방식을 고쳐 올립니다. 올린 지 3분 만에 파이프라인이 돌아 테스트 412개 중 하나가 깨졌다고 알려 옵니다. 고쳐서 다시 올리면 8분 뒤에 초록불이 뜨고, 이 변경만 반영된 프리뷰 주소가 자동으로 붙습니다. 민서가 그 주소를 열어 간격을 확인하고 지현이 빈 목록일 때 나오는 문구를 봅니다. 승인이 붙어 합쳐지면 같은 파이프라인이 스테이징을 거쳐 운영까지 이어 놓습니다. 태오가 서버에 직접 접속하는 일은 한 번도 없습니다.

되돌리는 일도 같은 절차를 씁니다. 배포 30분 뒤에 오류율이 튀면 직전 아티팩트를 다시 올리는 것으로 끝나서, 원인을 다 밝히기 전에 화면부터 원래대로 돌려놓을 수 있습니다. 금요일 저녁에 태오가 기억을 더듬어 한 줄씩 고치던 시절과 갈리는 지점이 여기입니다.

도구를 깔면 CI/CD 가 갖춰진다고 여기는 경우가 가장 많습니다. 설정 파일 하나를 저장소에 올리면 곧바로 초록 체크가 뜨니 다 된 것처럼 보이기 때문입니다. 그러나 자동 검사가 걸러 주는 양은 도구가 아니라 테스트가 얼마나 덮고 있느냐로 정해집니다. 테스트를 하나도 안 써 둔 저장소에서 파이프라인이 확인하는 것은 "빌드는 된다" 하나뿐이고, 로그인이 깨져 있어도 초록불이 뜹니다. 이 상태를 그대로 두면 팀은 초록불을 믿고 합치는데 깨진 기능은 사용자가 먼저 찾아냅니다. 그런 일을 두어 번 겪고 나면 아무도 초록불을 믿지 않게 되고, 자동화를 돌려 놓은 채로 다시 손으로 확인하는 상태가 됩니다.

자주 자동으로 내보내면 사고가 늘어난다는 오해도 흔합니다. 사람이 한 번 더 들여다보는 단계를 빼는 것처럼 들리니 그렇게 생각하기 쉽습니다. 실제로는 반대쪽 결과가 나옵니다. DORA 지표로 개발 조직을 비교해 보면 배포가 잦은 쪽이 변경 실패율도 낮고 복구도 빠릅니다. 한 번에 들어가는 변경이 작기 때문입니다. 커밋 3개를 올린 배포가 깨지면 볼 곳이 세 군데지만 300개를 올린 배포가 깨지면 어디부터 봐야 할지부터 정해야 합니다. 이 오해를 그대로 두면 팀은 안전을 이유로 배포를 분기에 한 번으로 묶고, 그 한 번은 온 팀이 밤을 새우는 행사가 됩니다. 위험이 줄어든 것이 아니라 한곳에 몰린 것뿐입니다.