[웹앱 실무 95] 배포 - 자동 배포 파이프라인

지금까지 빌드랑 배포, 환경이랑 설정 이야기를 했는데, 이걸 사람이 매번 손으로 하면 참 고달파요. 코드를 고칠 때마다 빌드 명령을 치고, 검증에 올리고, 확인하고, 다시 운영에 올리고, 그 사이에 하나라도 빠뜨리면 사고가 나죠. 이번 편에서 다룰 파이프라인은 바로 이 반복되는 절차를 기계가 대신 밟게 만드는 거예요. 저는 파이프라인을 갖추고 나서야 배포가 진짜 규율이자 일상이 됐다고 느꼈어요. 사람 손을 덜어낸 만큼 실수가 줄고, 마음이 편해졌거든요.

이번 편에서는 파이프라인이 뭔지, 왜 굳이 자동으로 만드는지, 어떤 단계로 이뤄지는지, 무엇이 그걸 시작시키는지, 그리고 처음 만들 때 뭘 챙겨야 하는지를 이야기할게요. 뒤에 나올 자동 테스트나 자동 배포는 사실 이 파이프라인의 한 조각들이라, 여기서 큰 틀을 잡아 두면 그 편들이 훨씬 잘 붙어요.

파이프라인이 대체 뭐예요?

파이프라인은 코드가 사용자한테 닿기까지 거치는 자동화된 길이에요. 코드를 저장소에 올리면, 그때부터 검사하고 빌드하고 시험하고 배포하는 일들이 미리 정해 둔 순서대로 저절로 흘러가죠. 마치 공장의 컨베이어벨트처럼, 한쪽에 코드를 올려 두면 다른 쪽으로 배포된 서비스가 나오는 거예요. 사람은 그 벨트를 지켜보고 문제가 생길 때만 손을 대면 돼요.

이 길을 여러 단계로 나눠 두는 게 핵심이에요. 각 단계는 앞 단계가 성공해야 다음으로 넘어가고, 하나라도 실패하면 거기서 멈춰 사람한테 알려요. 그래서 문제가 있는 코드는 운영까지 못 가고 중간에 걸러지죠. 저는 이 실패하면 멈춘다는 성질이 파이프라인의 가장 큰 가치라고 봐요. 사람이 깜빡해도 기계가 대신 막아 주니까요.

파이프라인은 흔히 두 부분으로 나눠 불러요. 코드를 검사하고 시험해 합쳐도 되는지 확인하는 앞부분, 그리고 확인된 걸 실제로 배포하는 뒷부분이에요. 앞부분을 지속 통합, 뒷부분을 지속 배포라 부르는데, 각각 다음 편들에서 자세히 다룰 거예요. 지금은 확인하는 길이랑 내보내는 길이 이어져 하나의 파이프라인을 이룬다는 그림만 잡아 두세요.

저는 파이프라인을 팀의 기억이라고도 불러요. 배포 절차가 사람 머릿속이 아니라 파이프라인 정의 파일에 글로 적혀 있으니, 누가 하든 똑같이 배포되고 새 사람도 금방 따라 할 수 있거든요. 절차가 사람한테 묶여 있으면 그 사람이 없을 때 마비되지만, 파이프라인으로 적어 두면 절차가 팀의 자산이 돼요.

파이프라인이라고 하면 거창한 도구를 떠올리기 쉬운데, 사실 시작은 소박해요. 요즘은 코드 저장소 서비스가 파이프라인 기능을 함께 품고 있어서, 정의 파일 하나만 저장소에 두면 바로 돌아가요. 우리가 할 일은 어떤 단계를 어떤 순서로 밟을지 글로 적어 두는 것뿐이죠. 저는 처음 이걸 봤을 때, 배포 절차를 요리법 적듯 적어 두면 기계가 그대로 따라 한다는 게 참 신기했어요. 어렵게 여기지 말고, 절차를 글로 옮긴다는 마음으로 다가가면 돼요.

왜 굳이 자동으로 만들어요?

가장 큰 이유는 사람은 실수하기 때문이에요. 손으로 배포하면 아무리 조심해도 언젠가 단계를 빠뜨리거나, 순서를 헷갈리거나, 잘못된 환경에 올려요. 특히 급하거나 피곤할 때 실수가 몰리는데, 사고는 꼭 그럴 때 나거든요. 기계는 지치지도 헷갈리지도 않으니, 정해진 걸 늘 똑같이 밟아 줘요. 저는 새벽에 급하게 손으로 배포하다 사고 낸 뒤로, 자동화가 곧 안전이라는 걸 뼈저리게 느꼈어요.

둘째 이유는 속도예요. 손으로 하면 배포 한 번에 한참 걸리니, 자연히 몰아서 크게 배포하게 돼요. 그런데 첫 편에서 말했듯, 크게 몰아 배포하면 문제가 나도 범인 찾기가 어렵죠. 자동화하면 배포가 순식간이라 작게 자주 할 수 있고, 그럼 변경 하나하나가 작아 문제를 금방 짚어요. 자동화는 단지 편한 게 아니라 배포 방식 자체를 건강하게 바꿔요.

셋째 이유는 기록이 남는다는 거예요. 파이프라인은 언제 누가 무엇을 올렸고, 어느 단계에서 무슨 일이 있었는지를 죄다 남겨 둬요. 문제가 생겼을 때 이 기록을 되짚으면 원인을 훨씬 빨리 찾죠. 손으로 하면 이런 기록이 사람 기억에만 남아 흐릿한데, 자동화하면 또렷한 흔적이 남아요. 저는 사고를 파헤칠 때 이 파이프라인 기록에 여러 번 구원받았어요.

물론 자동화에도 초기 비용은 들어요. 파이프라인을 처음 만드는 데 품이 들고, 배워야 할 것도 있죠. 그런데 이건 한 번 들이면 계속 돌려받는 투자예요. 저는 배포를 몇 번 이상 할 프로젝트라면 초반에 파이프라인부터 갖추라고 권해요. 처음엔 느려 보여도, 배포가 쌓일수록 손으로 하던 시간이랑 사고를 아껴 주니 금방 본전을 뽑아요.

파이프라인은 어떤 단계로 이뤄져요?

흔한 파이프라인은 대략 이런 단계를 밟아요. 먼저 코드를 가져오고, 딸린 꾸러미를 내려받고, 코드 모양이 규칙에 맞는지 검사하고, 시험을 돌리고, 빌드하고, 그렇게 만든 산출물을 배포해요. 각 단계가 앞 단계의 결과를 이어받아 다음으로 넘기죠. 이 순서는 프로젝트마다 조금씩 다르지만, 검사가 배포보다 앞이라는 큰 흐름은 어디나 같아요.

여기서 중요한 원칙은 싸고 빠른 검사를 앞에 두는 거예요. 코드 모양 검사처럼 금방 끝나는 건 앞에 두고, 오래 걸리는 무거운 시험은 뒤에 둬요. 그래야 사소한 문제는 빨리 걸러지고, 무거운 시험까지 갈 필요도 없이 멈추거든요. 저는 파이프라인을 짤 때 이 빨리 실패하기를 늘 염두에 둬요. 30분 걸려 실패하는 것보다 1분 만에 실패하는 게 훨씬 친절하니까요.

단계를 나눌 땐 각 단계가 무슨 책임을 지는지를 또렷이 해요. 검사 단계는 코드 품질만, 시험 단계는 동작만, 배포 단계는 올리는 것만 맡게요. 이렇게 나눠 두면 어느 단계가 실패했는지만 봐도 문제의 성격을 짐작할 수 있어요. 뭉뚱그린 한 덩어리로 만들면, 실패했을 때 대체 뭐가 문제인지 파헤치기가 어려워져요.

단계 사이엔 산출물을 넘겨 주는 장치도 필요해요. 빌드 단계가 만든 산출물을 배포 단계가 받아 써야 하는데, 이걸 보관해 뒀다 넘기는 거죠. 첫 편에서 말한 한 번 빌드하고 여러 번 배포가 여기서 실제로 구현돼요. 빌드는 한 번만 돌고, 그 산출물을 검증이랑 운영이 나눠 받아 쓰는 식이에요.

무엇이 파이프라인을 시작시켜요?

파이프라인은 어떤 사건에 반응해 시작해요. 가장 흔한 건 코드를 저장소에 올리는 순간이에요. 누군가 변경을 밀어 넣으면 파이프라인이 자동으로 깨어나 검사부터 시작하죠. 이걸 방아쇠, 그러니까 트리거라 불러요. 사람이 버튼을 누르지 않아도 코드 변경 자체가 신호가 되는 거예요. 저는 이 자동 시작이 없던 시절, 배포하는 걸 깜빡해 고친 게 반영 안 된 채 며칠을 보낸 적도 있어요.

모든 변경에 다 같은 파이프라인을 돌리는 건 아니에요. 흔히 작업 가지에 올릴 땐 검사랑 시험까지만 돌려 합쳐도 되는지 확인하고, 중심 가지에 합쳐질 땐 배포까지 이어지게 나눠요. 그래야 실험 중인 코드가 실수로 배포되는 일이 없죠. 저는 이 어디에 올리면 어디까지 가는지를 명확히 정해 두는 걸 중요하게 여겨요. 이게 흐릿하면 원치 않는 배포가 튀어나오거든요.

사람이 직접 시작시키는 방아쇠도 있어요. 운영 배포처럼 신중해야 할 건, 자동으로 흘러가게 두지 않고 사람이 버튼을 눌러 승인해야 진행되게 하는 거죠. 앞 단계까지는 자동으로 준비해 두되, 마지막 한 걸음은 사람이 확인하고 누르게요. 저는 검증까지는 자동, 운영으로 올리는 건 사람 승인으로 두는 방식을 즐겨 써요. 자동화랑 신중함을 둘 다 챙기는 절충이에요.

정해진 시각에 도는 방아쇠도 있어요. 매일 밤 무거운 검사를 돌리거나, 주기적으로 뭔가를 정리하는 일은 시간표에 맞춰 저절로 돌게 해요. 이런 건 배포랑 직접 이어지진 않지만, 같은 자동화 도구로 관리하면 편해요. 저는 이렇게 사건에 반응하는 것이랑 시각에 맞춰 도는 것을 잘 섞어, 손 안 대도 굴러가는 흐름을 만들어요.

파이프라인이 실패하면 어떻게 해요?

파이프라인이 중간에 멈추는 건 사실 좋은 일이에요. 문제 있는 코드를 운영까지 안 보내고 걸러 냈다는 뜻이니까요. 그러니 파이프라인이 빨개졌다고 당황하기보다, 제 할 일을 했구나 하고 침착하게 어느 단계에서 왜 멈췄는지부터 봐요. 파이프라인은 대개 실패한 단계랑 이유를 또렷이 보여 주니, 거기서부터 실마리를 잡으면 돼요.

다만 파이프라인이 자주, 별것 아닌 걸로 실패하면 곤란해요. 사람들이 또 실패했네 하고 무시하게 되거든요. 이걸 양치기 소년 문제라 하는데, 진짜 문제일 때도 대충 넘겨 버리는 위험을 낳아요. 그래서 저는 파이프라인이 믿을 만하게 유지되는 걸 아주 중요하게 여겨요. 어쩌다 운으로 실패하는 불안정한 시험은 찾아서 고치거나 걷어 내요. 파이프라인의 빨간불은 늘 진짜 문제여야 힘을 가져요.

실패했을 때 빨리 알아채는 것도 중요해요. 파이프라인이 멈췄는데 아무도 모르면, 그 사이 배포가 막혀 다른 사람 작업까지 밀리거든요. 그래서 저는 파이프라인 실패를 팀이 바로 보는 곳으로 알림이 가게 해 둬요. 특히 중심 가지가 깨진 건 팀 전체의 일이니, 누구 하나가 아니라 다 같이 얼른 고치는 문화를 만들려 해요.

가끔은 실패가 코드가 아니라 파이프라인 자체의 문제이기도 해요. 바깥 서비스가 잠깐 먹통이거나, 자동화 환경이 흔들려 멀쩡한 코드도 실패하는 거죠. 이럴 땐 무작정 코드를 뒤지지 말고, 다시 한 번 돌려 보는 게 답일 때가 많아요. 저는 실패를 볼 때 내 코드 탓인지 환경 탓인지부터 가르는데, 이 구분만 빨라도 헛수고를 크게 줄여요.

파이프라인을 처음 만들 땐 뭘 챙겨요?

처음부터 완벽하게 갖추려 애쓰지 마세요. 저는 작게 시작하라고 권해요. 우선 코드를 올리면 빌드랑 기본 시험만 자동으로 도는 것부터 만들고, 익숙해지면 검사랑 배포를 하나씩 붙여 가는 거죠. 처음부터 온갖 단계를 다 넣으려다 복잡함에 질려 포기하는 것보다, 단순한 걸 굴리며 키워 가는 게 훨씬 오래가요.

파이프라인 정의는 코드랑 같은 저장소에 두는 게 좋아요. 그래야 코드가 바뀔 때 파이프라인도 같이 버전 관리되고, 누가 언제 절차를 바꿨는지 기록에 남거든요. 저는 파이프라인을 코드처럼 다뤄요. 검토받고, 기록 남기고, 함부로 안 흔들죠. 배포 절차가 몰래 바뀌어 사고 나는 걸 막으려면 이게 꼭 필요해요.

비밀은 절대 파이프라인 정의에 적지 마세요. 앞 편에서 말한 시크릿은 파이프라인에서도 바깥 보관함에서 꺼내 쓰게 해야 해요. 정의 파일에 열쇠를 적으면, 그게 저장소에 올라가 고스란히 노출되거든요. 저는 파이프라인을 만들 때마다 혹시 비밀이 정의에 섞여 있나를 꼭 한 번 훑어요. 자동화 편하자고 만든 게 보안 구멍이 되면 안 되니까요.

마지막으로 파이프라인이 너무 오래 걸리지 않게 살펴 주세요. 배포 한 번에 30분씩 걸리면, 사람들이 배포를 귀찮아 미루게 되거든요. 그럼 애써 만든 자동화가 작게 자주라는 목적을 잃어요. 저는 파이프라인이 느려지면 어느 단계가 발목을 잡는지 재 보고, 아껴 둘 수 있는 건 아껴 두고 나눠 돌릴 수 있는 건 동시에 돌려 시간을 줄여요. 빠른 파이프라인이라야 사람들이 기꺼이 자주 쓰고, 자주 써야 자동화가 제값을 하니까요.

정리하면, 파이프라인은 코드가 사용자한테 닿는 길을 기계가 대신 밟게 만든 거예요. 사람 손을 덜어 실수를 줄이고, 작게 자주 배포하게 돕고, 또렷한 기록을 남기죠. 실패하면 침착하게 원인을 가르고, 처음엔 작게 시작해 키워 가면 돼요. 다음 편에서는 이 파이프라인의 앞부분, 그러니까 코드가 안전한지 자동으로 시험하는 지속 통합 이야기로 들어가 볼게요.