[웹앱 실무 97] 배포 - CD, 자동 배포

앞 편에서 코드를 자주 합치고 자동으로 시험하는 지속 통합을 다뤘으니, 이번엔 그 확인을 통과한 코드를 실제로 내보내는 뒷부분 이야기예요. 이걸 지속 배포라 부르고, 줄여서 CD라고도 해요. 지속 통합이 합쳐도 되는지 확인하는 문지기였다면, 지속 배포는 확인된 걸 사용자한테 실어 나르는 배달부인 셈이죠. 저는 이 배달부까지 자동으로 갖추고 나서야, 배포가 진짜 버튼 하나로 끝나는 편안함을 맛봤어요.

이번 편에서는 지속 배포가 뭔지, 비슷한 말인 지속 전달이랑 뭐가 다른지, 자동 배포가 어떤 흐름으로 흘러가는지, 언제 사람 승인을 끼워 넣는지, 그리고 자동인데도 안심하려면 뭘 갖춰야 하는지를 풀어 볼게요. 자동 배포라고 하면 무섭게 들리지만, 알고 보면 사람 실수를 줄이는 가장 든든한 안전장치예요.

지속 배포가 대체 뭐예요?

지속 배포는 확인을 통과한 코드가 사람 손을 안 거치고 곧장 사용자한테 배포되는 걸 말해요. 코드를 합치면 시험이 돌고, 시험을 통과하면 자동으로 운영에까지 올라가는 거죠. 사람이 배포 버튼을 누르는 단계조차 없어요. 통과했으면 알아서 나간다는 게 지속 배포의 정신이에요. 저는 처음 이걸 봤을 때 겁도 났지만, 곧 이게 얼마나 사람을 자유롭게 하는지 알게 됐어요.

이게 가능하려면 앞의 확인을 정말 믿을 수 있어야 해요. 시험이 통과하면 안전하다는 믿음이 없으면, 자동으로 내보내는 게 도박이 되니까요. 그래서 지속 배포는 튼튼한 지속 통합 위에서만 서요. 저는 지속 배포를 지속 통합이라는 땅 위에 세우는 집이라고 봐요. 땅이 물러 있으면 집을 올릴 수 없듯, 시험이 부실하면 자동 배포로 갈 수 없죠.

지속 배포의 가장 큰 선물은 변경이 순식간에 사용자한테 닿는다는 거예요. 코드를 합치면 몇 분 안에 배포되니, 고친 걸 곧바로 세상에 내보낼 수 있어요. 급한 문제를 고쳤을 때 이 속도가 특히 빛나죠. 저는 예전에 손으로 배포하던 시절, 급한 수정을 해 놓고도 배포 절차 밟느라 한참을 흘려보낸 적이 많은데, 자동 배포는 그 시간을 확 줄여 줘요.

또 하나, 지속 배포는 작게 자주 내보내게 만들어요. 배포가 공짜에 가까우니 한 줄 고쳐도 부담 없이 내보낼 수 있고, 그럼 변경 하나하나가 작아 문제가 나도 범인 찾기가 쉽죠. 첫 편에서 말한 작게 자주가 곧 안전이라는 원리가, 지속 배포에서 자연스럽게 실현돼요. 저는 이 점 때문에 지속 배포를 속도랑 안정을 함께 주는 방식이라 여겨요.

덤으로 지속 배포는 사람의 마음도 바꿔 놔요. 배포가 큰 이벤트일 땐 다들 배포 날을 두려워하는데, 배포가 숨 쉬듯 일상이 되면 그 두려움이 사라지거든요. 저는 자동 배포를 갖춘 뒤로 팀원들이 겁 없이 작은 개선을 자주 올리는 걸 봤어요. 예전엔 이 정도 고치자고 배포까지 하며 미루던 자잘한 개선들이, 이젠 그냥 술술 나가더라고요. 이렇게 쌓인 작은 개선들이 서비스를 꾸준히 좋아지게 만들어요. 자동화가 준 건 속도만이 아니라 부담 없이 손볼 자유였던 거죠.

지속 전달이랑 지속 배포는 뭐가 달라요?

여기서 헷갈리기 쉬운 두 말을 갈라 볼게요. 둘 다 영어 약자가 CD라 더 헷갈리는데, 지속 전달이랑 지속 배포는 딱 한 군데가 달라요. 바로 운영에 올리는 마지막 단계에 사람이 끼느냐예요. 지속 전달은 언제든 배포할 수 있게 준비는 자동으로 다 해 두되, 운영에 올리는 버튼은 사람이 눌러요. 지속 배포는 그 버튼조차 없이 통과하면 저절로 올라가고요.

그러니까 지속 전달까지는 검증 환경까지 자동으로 배포되고, 운영으로 가는 마지막 한 걸음만 사람이 확인하고 승인하는 거예요. 저는 처음 자동화를 도입할 땐 지속 전달부터 시작하라고 권해요. 자동의 이점은 거의 다 누리면서, 운영에 나가는 순간만은 사람이 한 번 더 보니까 마음이 놓이거든요.

지속 배포로 완전히 넘어갈지는 서비스 성격에 따라 달라요. 실수해도 금방 되돌릴 수 있고 시험을 깊이 믿는다면 완전 자동이 편해요. 반대로 한 번의 실수가 크게 아픈 서비스라면, 운영 배포에 사람의 눈을 남겨 두는 게 안전하죠. 저는 되돌리기가 쉬운가, 실수의 대가가 큰가 이 두 가지를 저울에 올려 정해요.

중요한 건, 둘 중 뭐가 더 낫다는 게 아니에요. 둘 다 운영 직전까지는 자동이라는 큰 이점을 공유하고, 마지막 한 걸음의 믿음 정도만 다를 뿐이거든요. 저는 팀이 자동화에 익숙해지는 정도에 맞춰, 지속 전달로 시작해 지속 배포로 천천히 옮겨 가는 걸 자연스럽게 여겨요. 처음부터 완전 자동으로 뛰어들 필요는 없어요.

자동 배포는 어떤 흐름으로 흘러가요?

흔한 자동 배포 흐름은 이래요. 코드가 중심 가지에 합쳐지면, 파이프라인이 깨어나 시험을 돌리고 빌드해 산출물을 만들어요. 그 산출물을 먼저 검증 환경에 올려, 실제와 비슷한 곳에서 잘 도는지 확인하죠. 여기서 자동 확인까지 통과하면, 같은 산출물을 운영으로 승격시켜요. 첫 편에서 말한 한 번 빌드하고 여러 번 배포가 이 흐름 안에 그대로 담겨 있어요.

운영에 올릴 땐 앞서 서버 배포 편에서 말한 조심스러운 교체가 이어져요. 새 버전을 옆에 준비하고, 준비 검사를 통과한 걸 확인한 뒤에야 요청을 새 버전으로 돌리는 거죠. 이 무중단 교체는 다음 편에서 깊이 다룰 거예요. 자동 배포는 이 교체까지 사람 손 없이 밟아 주니, 사람은 지켜보기만 하면 돼요.

배포가 끝나면 흐름은 확인으로 이어져요. 올린 직후 핵심 경로가 제대로 응답하는지 자동으로 두드려 보고, 오류가 늘거나 응답이 느려지지 않는지 지켜보죠. 여기서 이상이 감지되면, 잘 짜인 파이프라인은 자동으로 되돌리기까지 해요. 이 배포 후 확인이랑 되돌리기는 각각 뒤 편들에서 다룰 텐데, 자동 배포의 흐름은 올리고 끝이 아니라 확인까지 포함한다는 걸 기억해 두세요.

이 흐름 전체가 정의 파일 하나에 글로 적혀 있다는 게 핵심이에요. 어느 환경에 어떤 순서로 올리고, 무엇을 확인하고, 이상하면 어떻게 되돌릴지가 다 적혀 있죠. 저는 이 정의를 볼 때마다, 예전엔 사람 머릿속에만 있던 절차가 이렇게 또렷한 글이 됐다는 게 든든해요. 누가 봐도 우리가 어떻게 배포하는지를 알 수 있으니까요.

이 흐름에서 하나 강조하고 싶은 건, 검증 환경을 그냥 거쳐 가는 곳으로 두지 말라는 거예요. 검증에 올렸으면 거기서 실제로 확인이 이뤄져야 의미가 있거든요. 자동 확인이든 사람 눈이든, 검증에서 뭔가를 거른다는 실질이 있어야 해요. 저는 검증을 형식적으로만 거치고 바로 운영으로 밀어 버리는 파이프라인을 본 적이 있는데, 그건 검증이 있으나 마나였어요. 각 환경이 흐름 속에서 제 몫의 확인을 하게 두는 게 중요해요.

사람 승인은 언제 끼워 넣어요?

완전 자동이 부담스러운 자리엔 승인 관문을 둬요. 파이프라인이 앞 단계까지 다 준비해 두고, 운영에 올릴까요 하고 멈춰 사람의 승인을 기다리는 거죠. 사람이 확인하고 버튼을 눌러야 다음으로 넘어가요. 저는 이 관문을 급브레이크라 여겨요. 평소엔 자동으로 매끄럽게 흐르되, 중요한 순간엔 사람이 한 번 멈춰 서서 보게 하는 거죠.

승인 관문은 꼭 필요한 곳에만 두는 게 좋아요. 관문이 너무 많으면 자동화의 의미가 바래고, 사람들이 기계처럼 눌러 대 오히려 확인이 형식만 남거든요. 저는 운영에 나가는 순간 정도에만 관문을 두고, 그 앞은 다 자동으로 흐르게 해요. 관문이 드물어야 그 관문에서 진짜로 신중히 보게 되니까요.

관문에서 사람이 봐야 할 건 기계가 못 보는 것이어야 해요. 시험이 이미 확인한 걸 또 확인하면 낭비죠. 대신 지금 배포해도 되는 때인가, 이를테면 큰 행사를 앞뒀거나 사람이 몰리는 시간대는 아닌가 같은 맥락을 보는 거예요. 저는 승인 관문을 기계의 판단에 사람의 상황 감각을 더하는 자리로 써요. 둘의 몫이 다르거든요.

다만 승인 관문이 병목이 되지 않게 조심해요. 승인할 사람이 자리를 비우면 배포가 줄줄이 밀리거든요. 그래서 저는 승인 권한을 여러 사람한테 나눠 두고, 급할 때 누구든 볼 수 있게 해요. 관문은 신중함을 위한 거지 한 사람한테 묶여 마비되라고 있는 게 아니니까요. 승인이 자꾸 밀린다 싶으면, 그 관문이 정말 필요한지부터 다시 물어보는 것도 좋아요. 습관처럼 남겨 둔 관문이 실은 아무 확인도 못 하고 시간만 잡아먹는 경우가 의외로 많거든요.

자동인데도 왜 안심이 안 돼요?

배포를 자동으로 만들었다고 손 놓고 있어도 되는 건 아니에요. 오히려 자동이라 한 번 잘못 설정하면 그 실수가 자동으로 반복되니, 안전장치를 더 촘촘히 갖춰야 해요. 첫째 안전장치는 배포 후 자동 확인이에요. 올린 직후 핵심 경로를 두드려 봐서, 기대한 응답이 오는지를 기계가 확인하게 하는 거죠. 여기서 어긋나면 배포를 실패로 처리해요.

둘째는 자동 되돌리기예요. 배포 후 오류가 확 늘거나 응답이 느려지면, 사람이 손대기 전에 스스로 이전 버전으로 돌아가게 해 두는 거예요. 자동으로 나간 만큼 자동으로 물러설 길도 있어야 안심이 되거든요. 저는 자동 배포를 갖출 때 이 자동 되돌리기를 짝으로 꼭 함께 만들어요. 나가는 길만 있고 물러설 길이 없으면 무서우니까요.

셋째는 조금씩 내보내기예요. 새 버전을 한꺼번에 모두한테 주지 말고, 일부한테 먼저 흘려보고 괜찮으면 점점 넓히는 거죠. 문제가 있어도 일부만 겪으니 피해가 작아요. 이 조금씩 내보내기는 무중단이랑 롤백 편에서 더 다룰 텐데, 자동 배포의 든든한 안전장치라 여기서 미리 짚어 둬요.

넷째는 지켜보는 눈이에요. 자동이라도 지금 무슨 일이 벌어지는지를 사람이 볼 수 있어야 해요. 오류가 늘면 알림이 오고, 배포 현황이 한눈에 보이게요. 저는 자동화를 사람을 대체하는 것이 아니라 사람이 더 잘 지켜보게 돕는 것으로 여겨요. 손 대는 일은 기계한테 맡기되, 무슨 일이 벌어지는지 아는 것은 끝까지 사람의 몫이거든요.

지속 배포로 가는 길은 어때요?

지속 배포는 하루아침에 되는 게 아니에요. 저는 늘 단계를 밟아 가라고 권해요. 처음엔 손으로 배포하되 절차를 글로 적어 두고, 다음엔 그 절차를 파이프라인으로 자동화하고, 시험을 쌓아 믿을 만해지면 검증까지 자동으로, 마지막에 운영까지 자동으로 넓혀 가는 거죠. 각 단계에서 충분히 익숙해진 뒤 다음으로 가면 돼요.

이 길에서 가장 중요한 건 믿음을 쌓는 거예요. 자동 배포는 결국 시험이랑 안전장치를 얼마나 믿느냐의 문제거든요. 시험이 통과하면 안전하다는 믿음, 이상하면 자동으로 물러선다는 믿음이 쌓여야 손을 뗄 수 있어요. 저는 이 믿음을 작은 성공을 반복하며 쌓아요. 자동으로 배포한 게 여러 번 탈 없이 지나가면, 그만큼 다음 단계로 갈 자신이 생기거든요.

서두르지 않는 것도 중요해요. 아직 시험이 부실한데 완전 자동으로 밀어붙이면, 확인 안 된 코드가 자동으로 나가 사고가 자동으로 반복돼요. 저는 자동화의 정도를 팀의 성숙도에 맞춰 정해요. 무리하게 앞서가기보다, 지금 팀이 편안하게 감당할 만큼만 자동화하고 천천히 넓혀요. 남들이 완전 자동을 한다고 우리도 따라야 하는 건 아니에요. 우리 서비스랑 우리 팀에 맞는 지점이 어디인지가 답이거든요.

정리하면, 지속 배포는 확인을 통과한 코드를 자동으로 사용자한테 내보내는 거예요. 운영 직전에 사람 승인을 두면 지속 전달, 그마저 없으면 지속 배포죠. 자동일수록 배포 후 확인, 자동 되돌리기, 조금씩 내보내기, 지켜보는 눈 같은 안전장치를 촘촘히 갖춰야 하고, 그 길은 믿음을 쌓으며 단계를 밟아 가면 돼요. 다음 편에서는 배포할 때 옛 파일과 새 파일이 얽히는 캐시 버스터와 정적 자산 이야기로 넘어가 볼게요.