[웹앱 실무 104] 배포 - 배포 흔한 실수

드디어 배포 시리즈의 마지막 편이에요. 배포가 뭔지부터 시작해 정적이랑 서버 배포, 환경 분리랑 시크릿, 빌드랑 파이프라인, 자동 시험이랑 자동 배포, 캐시 버스터, 무중단, 롤백, 검증, 모니터링, 사고 대응까지 참 긴 길을 함께 걸어왔네요. 마지막 자리에서 저는 새 이야기를 하나 더 얹기보다, 지금까지 이야기한 걸 관통하는 흔한 실수들을 한자리에 모아 보려 해요. 제가 현장에서 실제로 넘어졌던 지점들이라, 여러분은 저처럼 아프게 배우지 않고 미리 피해 가시면 좋겠어요.

이번 편에서는 배포에 대한 흔한 오해, 준비 없이 덤비는 실수, 자동화를 잘못 쓰는 실수, 되돌릴 준비를 안 하는 실수, 확인을 건너뛰는 실수, 그리고 배포를 대하는 마음가짐을 같이 정리해 볼게요. 앞 편들에서 흩어 놓았던 교훈들이 하나로 꿰어지는 자리라, 시리즈를 매듭짓는 마음으로 편하게 읽어 주세요.

배포에 대한 흔한 오해는요?

제가 가장 자주 본 오해는 배포는 화려한 기술이라는 생각이에요. 그런데 첫 편에서 말했듯, 배포는 반복되는 규율에 가까워요. 원리를 이해하고 절차를 다듬으면, 배포는 오히려 가장 지루하고 예측 가능한 작업이 되거든요. 저는 배포가 스릴 넘치는 순간이면 뭔가 잘못된 것이라고 봐요. 잘 갖춘 배포는 있는지도 모르게 조용히 지나가니까요.

둘째 오해는 배포는 특별한 이벤트라는 생각이에요. 배포를 큰 행사로 여기면 미루게 되고, 미루니 변경이 쌓이고, 쌓인 걸 한꺼번에 올리니 위험해지는 악순환에 빠지죠. 저는 배포를 숨 쉬듯 일상으로 만들라고 거듭 말하고 싶어요. 작게 자주 하면 변경 하나가 작아 문제도 작고 되돌리기도 쉽거든요. 배포의 두려움은 배포를 자주 함으로써만 사라져요.

셋째 오해는 배포 명령이 성공하면 끝이라는 생각이에요. 배포 성공은 파일을 잘 올렸다는 뜻일 뿐, 서비스가 진짜 멀쩡한지는 별개거든요. 검증 편에서 말했듯, 명령은 성공했는데 서비스는 죽어 있는 경우가 흔해요. 저는 배포를 확인까지가 배포라고 여겨요. 실제로 열어 보기 전엔 절반만 끝난 거예요.

또 하나 흔한 오해는 배포가 어렵기만 한 일이라는 겁을 먹는 거예요. 막상 뜯어 보면 배포는 낯선 부품 몇 개를 익숙한 개발 위에 끼우는 일이거든요. 빌드하고, 환경을 나누고, 자동으로 잇고, 되돌릴 채비를 하는 것처럼요. 부품 하나하나는 어렵지 않고, 어려운 건 이들이 함께 움직일 때의 흐름이죠. 저는 이 시리즈에서 그 흐름을 편마다 하나씩 풀어 왔으니, 이제 여러분도 겁먹지 않고 첫걸음을 뗄 수 있을 거예요.

마지막 오해는 완벽한 배포를 갖춰야 시작할 수 있다는 생각이에요. 파이프라인이랑 자동 시험이랑 모니터링을 다 갖추고 나서야 제대로 된 배포라 여기면, 시작조차 못 하고 지레 지쳐요. 저는 작게 시작해 키워 가라고 늘 말해요. 손으로 배포하되 절차를 글로 적는 것부터, 기본 시험 하나 자동화하는 것부터요. 오늘의 소박한 한 걸음이 내일의 든든한 배포로 자라거든요. 완벽을 기다리다 아무것도 안 하는 것보다, 불완전하게라도 시작하는 게 언제나 나아요.

준비 없이 덤비면 어떻게 돼요?

배포 초보가 가장 많이 하는 실수가 준비 없이 손으로 배포하는 거예요. 절차가 사람 손이랑 기억에 의존하면, 아무리 조심해도 언젠가 단계를 빠뜨리거나 순서를 헷갈려요. 특히 급하거나 피곤할 때 사고가 몰리는데, 하필 사고는 그럴 때 나죠. 저는 배포 절차를 글로 적고 자동화하라고 강하게 권해요. 사람 손을 덜어낼수록 실수가 줄거든요.

둘째는 환경을 안 나누는 실수예요. 실험이랑 실전을 갈라 두지 않으면, 개발자가 뭔가 고칠 때마다 사용자가 인질이 돼요. 환경 분리 편에서 말했듯, 실수가 곧바로 사용자한테 가는 구조는 규모랑 상관없이 위험해요. 저는 혼자 하는 작은 프로젝트에도 최소한의 경계는 두라고 해요. 적어도 운영에 직접 손대지 않는 습관 하나만은요.

셋째는 설정이랑 비밀을 코드에 박는 실수예요. 시크릿 편에서 길게 다뤘듯, 열쇠를 코드에 넣으면 저장소에 올라가는 순간 고스란히 노출돼요. 한번 올라간 비밀은 지워도 기록에 남아 없애기 어렵죠. 저는 변하는 값이랑 비밀은 코드 밖에 둔다는 원칙을 어떤 프로젝트에서도 제일 먼저 세워요. 특히 브라우저에 가는 건 다 공개라는 걸 잊으면 안 돼요.

넷째는 재현성을 안 챙기는 실수예요. 환경마다 다시 빌드하거나 버전을 안 고정하면, 검증에선 됐는데 운영에선 깨지는 사고가 나요. 첫 편에서 말한 한 번 빌드하고 여러 번 배포를 지켜, 검증한 그 산출물이 글자 하나 안 틀리고 운영으로 가게 해야 해요. 저는 이 원칙을 불확실성을 줄이는 장치로 여겨요. 산출물이 같아야 문제가 났을 때 환경만 의심하면 되거든요.

자동화를 잘못 쓰면 어떻게 돼요?

자동화를 배우면 빠지는 함정이 확인 없이 자동으로 밀어붙이는 거예요. 시험이 부실한데 완전 자동 배포로 가면, 확인 안 된 코드가 자동으로 나가 사고가 자동으로 반복돼요. 자동 배포 편에서 말했듯, 자동화는 믿을 수 있는 확인 위에서만 서요. 저는 자동화의 정도를 팀의 성숙도에 맞춰 정하고, 무리하게 앞서가지 않아요.

둘째는 불안정한 시험을 방치하는 거예요. 됐다 안 됐다 하는 시험을 두면, 사람들이 또 걔 그러네 하고 빨간불을 무시하게 되죠. 그러다 진짜 문제도 놓쳐요. 자동 시험 편에서 강조했듯, 저는 빨간불의 권위를 지키려 애써요. 믿을 수 있는 시험 열 개가 못 믿을 시험 백 개보다 나아요. 알림도 마찬가지라, 울리면 진짜여야 힘을 가져요.

셋째는 파이프라인에 비밀을 적는 실수예요. 자동화 편하자고 정의 파일에 열쇠를 적으면, 그게 보안 구멍이 돼요. 저는 파이프라인을 만들 때마다 혹시 비밀이 섞였나를 꼭 훑고, 시크릿은 바깥 보관함에서 꺼내 쓰게 해요. 편하자고 만든 게 위험이 되면 안 되니까요.

넷째는 자동화했으니 손 놓아도 된다는 착각이에요. 오히려 자동이라 한 번 잘못 설정하면 그 실수가 자동으로 반복되니, 지켜보는 눈을 더 촘촘히 둬야 해요. 저는 자동화를 사람을 대체하는 것이 아니라 사람이 더 잘 지켜보게 돕는 것으로 여겨요. 손 대는 일은 기계한테 맡기되, 무슨 일이 벌어지는지 아는 것은 끝까지 사람의 몫이에요.

되돌릴 준비를 안 하면 어떻게 돼요?

가장 뼈아픈 실수가 되돌릴 준비 없이 배포하는 거예요. 나가는 길만 있고 물러설 길이 없으면, 사고가 났을 때 손쓸 방법 없이 발만 동동 구르게 되죠. 롤백 편에서 말했듯, 저는 배포 전에 이번 배포는 이렇게 되돌린다는 걸 손에 쥐고 나서야 새 버전을 올려요. 되돌릴 수 있다는 확신이 배포의 두려움을 없애 주거든요.

둘째는 급할 때 앞으로 고치려 드는 거예요. 사고가 나면 얼른 고쳐 배포하고 싶지만, 급하게 짠 수정은 충분히 검증 안 된 채 나가 문제를 더 키워요. 저는 일단 되돌려 사용자 고통을 멈춘 뒤, 안전해진 상태에서 제대로 고쳐요. 새것으로 앞서가기보다 옛것으로 물러서는 게 급할수록 확실하거든요.

셋째는 데이터를 되돌릴 수 없게 바꾸는 거예요. 무중단이랑 롤백 편에서 말했듯, 데이터를 지우기부터 해 버리면 옛 버전으로 돌아갈 데이터가 없어 롤백이 막혀요. 저는 더하고 나중에 지우는 순서로만 데이터를 바꾸고, 지우기는 정말 안 쓰는 게 확실할 때 마지막에만 해요. 코드는 되돌리면 그만이지만 데이터는 되돌리기 어렵거든요.

넷째는 되돌리기를 연습 안 하는 거예요. 되돌리기 기능이 실제론 고장 나 있는 걸 사고 때 처음 알면 정말 아찔해요. 저는 아무 일 없는 평온한 날에 일부러 되돌려 보고, 팀 모두가 돌아가며 해 보게 해요. 소화기를 사 두고 작동하는지 안 보면 정작 불날 때 안 터지듯, 되돌리기도 미리 점검해 둬야 진짜 힘을 발휘하거든요.

확인을 건너뛰면 어떻게 돼요?

바쁠 때 가장 먼저 건너뛰는 게 확인이에요. 배포까지 했으니 얼른 다음 일 하고 싶어서요. 그런데 검증 편에서 말했듯, 문제가 배포 직후에 잡히느냐 몇 시간 뒤 항의로 잡히느냐는 피해 크기가 완전히 달라요. 저는 확인에 드는 몇 분을 가장 값싼 보험으로 여겨요. 그 몇 분이 나중의 몇 시간을 아껴 주거든요.

둘째는 내 자리에서만 확인하는 거예요. 강제 새로고침한 내 브라우저에선 잘 되는데, 정작 일반 사용자는 옛 화면을 보는 캐시 문제가 대표적이죠. 저는 배포 확인을 평범한 방문 상태로도, 여러 조건에서도 해요. 나는 되는데 사용자는 안 된다는 함정에 여러 번 빠져 봤거든요.

셋째는 지켜보지 않고 떠나는 거예요. 배포하자마자 자리를 뜨면, 배포 직후 서서히 드러나는 문제를 놓쳐요. 모니터링 편에서 말했듯, 저는 배포 후 한동안 오류랑 속도에서 눈을 안 떼요. 배포는 올리고 끝이 아니라 한동안 지켜보는 것까지예요.

넷째는 사고에서 안 배우는 거예요. 사고를 수습하고 돌아보기 없이 넘어가면, 같은 사고를 또 겪어요. 사고 대응 편에서 말했듯, 저는 사람이 아니라 시스템을 돌아보며 구체적인 할 일을 뽑아 실제로 고쳐요. 아팠던 만큼 배워야 본전이고, 그렇게 쌓인 개선이 서비스를 점점 튼튼하게 만들거든요.

이 실수들을 쭉 늘어놓고 보면, 공통점이 하나 보여요. 다들 당장 편하려다 나중에 크게 데는 것들이거든요. 손으로 하는 게 당장 편하고, 확인을 건너뛰는 게 당장 빠르고, 되돌릴 준비를 안 하는 게 당장 일이 적죠. 그런데 그 당장의 편함이 꼭 나중에 몇 배의 고생으로 돌아와요. 저는 배포에서만큼은 조금 귀찮아도 제대로 하는 쪽을 택해요. 그 작은 수고들이 쌓여, 결국 밤잠 편히 자는 배포를 만들어 주거든요.

배포를 어떤 마음으로 대해야 할까요?

긴 시리즈를 마치며, 제가 배포를 대하는 태도를 몇 가지로 추려 볼게요. 첫째는 재현성이에요. 한 번 빌드해 여러 번 배포하며, 검증한 그대로가 운영으로 가게 하는 거죠. 산출물이 같아야 믿음이 서고, 문제가 나도 의심 범위가 좁아져요. 이 재현성이 안정적인 배포의 밑바탕이에요.

둘째는 자동화예요. 사람 손을 덜어낸 만큼 실수가 줄고, 작게 자주 배포할 수 있고, 또렷한 기록이 남죠. 다만 자동화는 믿을 수 있는 확인 위에서만 서고, 자동일수록 지켜보는 눈을 더 촘촘히 둬야 해요. 저는 자동화를 팀이 감당할 만큼 천천히 넓혀 가라고 권해요.

셋째는 되돌릴 채비예요. 언제든 이전으로 돌아갈 수 있으면, 배포는 돌이킬 수 없는 도박이 아니라 편안한 일상이 돼요. 급할 땐 앞으로 고치기보다 일단 되돌려 사용자 고통을 먼저 멈추고, 데이터는 되돌릴 수 있는 순서로 다뤄요. 그리고 그 되돌리기를 평소에 연습해 둬야 해요.

넷째는 관측이에요. 지금 무슨 일이 벌어지는지 들여다보고, 배포 후 실제로 잘 도는지 확인하며, 이상하면 사용자보다 먼저 알아채는 거죠. 저는 확인까지가 배포라는 말을 마지막으로 다시 새기고 싶어요. 올린 게 아니라 제대로 도는 걸 확인한 것이 배포의 완성이거든요.

이 네 가지, 재현성, 자동화, 되돌릴 채비, 관측은 사실 첫 편에서 밝힌 네 개의 기둥 그대로예요. 편마다 도구랑 기법은 달랐지만, 밑에 흐르는 태도는 하나였던 거죠. 저는 여러분이 구체적인 기술은 시간이 지나 잊더라도, 이 네 기둥만은 오래 지니면 좋겠어요. 새 배포 도구가 나와도 이 넷으로 바라보면 중심이 흔들리지 않거든요.

이렇게 배포 이야기를 매듭지어요. 정적부터 서버까지, 빌드부터 파이프라인까지, 무중단부터 사고 대응까지 편마다 하나씩 짚어 왔네요. 밑에 흐르는 태도는 결국 하나였어요. 배포를 두려운 이벤트가 아니라 안정적인 규율로 보는 것이요. 여러분이 이 시리즈에서 기술만큼이나 그 차분한 감각을 가져가면 좋겠어요. 현장에서 부딪히며 배운 것들을 이렇게 수다 떨듯 나눌 수 있어 즐거웠어요. 긴 여정 함께해 주셔서 고마워요. 다음 서브영역에서 또 반갑게 만나요.