[웹앱 실무 101] 배포 - 배포 후 검증

첫 편에서 배포가 끝난 시점이 곧 성공은 아니다라고 했잖아요. 배포 명령이 오류 없이 끝났다고 해도, 실제 사용자가 여는 화면이 정상인지는 별개의 문제라고요. 이번 편은 바로 그 별개의 확인, 배포 후 검증을 다뤄요. 다리를 놓았으면 그 위로 사람이 안전하게 건너는지 봐야 완성이듯, 배포했으면 진짜 잘 도는지 확인해야 배포가 끝나는 거예요. 저는 이 확인을 빼먹어서 배포는 성공했는데 서비스는 죽어 있던 아찔한 경험을 하고 나서, 검증을 배포의 마지막 필수 단계로 못 박았어요.

이번 편에서는 배포 후 검증이 뭔지, 배포 성공이 왜 진짜 성공이 아닌지, 무엇을 어떻게 확인하는지, 어떻게 자동으로 검증하는지, 이상할 때 어떻게 대응하는지, 그리고 검증을 거르지 않는 습관으로 만드는 법을 풀어 볼게요. 짧지만 배포를 완성하는 마지막 조각이에요.

배포 후 검증이 대체 뭐예요?

배포 후 검증은 새 버전을 올린 직후, 서비스가 진짜 정상으로 도는지를 확인하는 일이에요. 핵심 화면이 제대로 뜨는지, 중요한 기능이 잘 작동하는지, 오류가 늘지 않았는지를 실제 운영 환경에서 확인하는 거죠. 배포가 기술적으로 끝난 것과 서비스가 실제로 멀쩡한 것은 다르니, 그 사이의 틈을 메우는 확인이에요.

이게 왜 필요하냐면, 배포엔 명령은 성공했는데 서비스는 이상한 경우가 실제로 많거든요. 설정 하나가 빠졌거나, 연결이 안 됐거나, 특정 화면만 깨졌거나요. 배포 도구는 파일을 올린 것까지만 보니, 그 뒤 서비스가 어떤지는 따로 확인해야 알아요. 검증은 이 도구가 못 보는 부분을 사람이나 자동 확인으로 메우는 거예요.

검증은 배포의 안전망이기도 해요. 문제를 배포 직후에 잡으면, 아직 사용자가 많이 안 겪었을 때 되돌릴 수 있거든요. 반대로 검증을 안 하면 사용자 항의가 들어와서야 문제를 알게 되죠. 저는 검증을 사용자보다 먼저 문제를 발견하는 장치로 여겨요. 우리가 먼저 알면 조용히 고치고, 사용자가 먼저 알면 신뢰를 잃으니까요.

검증은 롤백이랑 짝을 이뤄요. 검증으로 문제를 발견하면, 앞 편에서 다룬 롤백으로 되돌리는 거죠. 검증이 없으면 되돌릴 판단 근거가 없고, 롤백이 없으면 검증으로 문제를 찾아도 손쓸 방법이 없어요. 그래서 저는 이 둘을 한 흐름으로 봐요. 배포하고, 검증하고, 이상하면 되돌린다는 흐름이요.

검증은 거창할 필요가 없어요. 핵심 화면 몇 개를 열어 보고, 중요한 기능 한둘을 눌러 보는 것만으로도 대부분의 큰 사고는 잡히거든요. 저는 완벽한 검증보다 거르지 않는 검증이 낫다고 봐요. 매번 빠짐없이 하는 가벼운 확인이, 어쩌다 한 번 하는 철저한 확인보다 서비스를 잘 지켜요.

검증은 시간이 돈이라는 것도 알아 두면 좋아요. 문제가 배포 직후에 잡히느냐, 몇 시간 뒤 사용자 항의로 잡히느냐는 피해 크기가 완전히 달라지거든요. 직후에 잡으면 조용히 되돌려 아무 일 없던 듯 넘어가지만, 늦게 잡으면 그사이 수많은 사용자가 겪은 뒤라 수습할 게 산더미예요. 그래서 저는 검증에 드는 몇 분을 아까워하지 않아요. 그 몇 분이 나중의 몇 시간을 아껴 주니까요. 검증은 귀찮은 뒷일이 아니라 가장 값싼 보험이에요.

배포 성공이 왜 성공이 아니에요?

배포 도구가 성공이라고 초록불을 켜도, 그건 파일을 잘 올렸다는 뜻일 뿐이에요. 그 파일이 실제로 잘 도는지까지 보증하진 않죠. 그래서 배포 성공과 서비스 정상 사이엔 틈이 있어요. 이 틈을 모르고 배포 성공이니 다 됐다고 여기면, 그 틈에서 사고가 자라나요.

대표적인 게 설정이 빠진 경우예요. 코드는 잘 올라갔는데 환경 변수 하나가 안 채워져, 서버가 데이터베이스에 못 붙는 거죠. 배포는 성공인데 서비스는 모든 요청이 실패해요. 저는 이걸 여러 번 겪고 나서, 배포 성공을 절반의 완료로만 여겨요. 나머지 절반은 실제로 도는지 확인이거든요.

또 흔한 게 일부만 깨진 경우예요. 대부분 화면은 멀쩡한데 특정 기능 하나만 안 되는 거죠. 전체가 죽으면 금방 알아채지만, 일부만 깨지면 한참 모르고 지나가기 쉬워요. 그래서 검증은 대표적인 핵심 경로 여러 개를 골고루 확인해야 해요. 한 곳만 보고 다 되나 보다 하면 놓치거든요.

배포망 시차 때문에 사람마다 다르게 보이는 경우도 있어요. 새 파일이 세계 곳곳으로 퍼지는 데 잠깐 시간이 걸려서, 어떤 지역은 새것을 어떤 지역은 옛것을 받거든요. 그래서 저는 배포 직후 확인할 때 여러 조건에서 봐요. 내 자리에서만 되는 게 모두한테 되는 건 아니니까요.

그래서 저는 배포 성공이라는 초록불을 확인의 시작 신호로 받아들여요. 초록불이 켜지면 다 됐다가 아니라, 이제 진짜 잘 도는지 볼 차례라고요. 이 마음가짐 하나가, 배포 성공에 안심하다 사용자 항의로 뒤통수 맞는 일을 막아 줘요. 배포는 확인까지가 배포예요.

무엇을 확인해야 해요?

가장 먼저 볼 건 핵심 경로예요. 우리 서비스에서 이것만은 반드시 돼야 하는 몇 가지죠. 예를 들어 로그인, 첫 화면 뜨기, 글 쓰기, 결제 같은 거요. 이 핵심 경로가 정상이면 대부분 큰 문제는 없다고 봐도 돼요. 저는 서비스마다 이 핵심 경로 목록을 미리 정해 두고, 배포 후엔 그것부터 확인해요.

이렇게 중요한 몇 가지만 빠르게 훑는 확인을 연기 검사라 불러요. 전기 기기에 처음 전원을 넣고 연기가 안 나는지 보던 데서 온 말인데, 깊이 파고들기 전에 큰 불이 없는지만 빠르게 보는 거예요. 모든 걸 다 시험하는 게 아니라, 가장 중요한 것들이 살아 있는지만 확인하죠. 짧게 끝나니 매번 부담 없이 할 수 있어요.

둘째로 볼 건 오류가 늘었는지예요. 배포 직후 오류 수가 갑자기 치솟으면, 뭔가 잘못됐다는 강한 신호거든요. 배포 전이랑 후를 견줘 오류가 확 늘지 않았는지를 봐요. 특정 화면에서만 오류가 몰리면, 그 부분이 깨졌다는 걸 짐작할 수 있죠. 저는 배포 후 한동안 오류 흐름에서 눈을 안 떼요.

셋째는 응답 속도예요. 오류는 안 나는데 갑자기 느려졌다면, 새 버전에 성능 문제가 생겼을 수 있어요. 사용자는 느린 것도 고장으로 느끼니, 속도 저하도 중요한 신호예요. 저는 배포 후 응답 시간이 평소랑 비슷한지를 확인해요. 느려졌으면 원인을 봐야 하죠.

넷째는 실제 사용자 눈으로 보는 거예요. 숫자만 보지 말고, 진짜 서비스에 들어가 눌러 보는 거예요. 숫자로는 안 잡히는 디자인 틀어짐이나 어색한 동작은 사람 눈에만 보이거든요. 저는 배포 후 꼭 사용자처럼 몇 번 써 봐요. 기계의 확인이랑 사람의 확인은 서로 다른 걸 잡아 주니까요.

자동으로 검증하려면요?

매번 손으로 확인하는 건 지치고 빠뜨리기 쉬워요. 그래서 검증도 자동화하면 좋아요. 배포가 끝나면 파이프라인이 핵심 경로를 자동으로 두드려 보고, 기대한 응답이 오는지 확인하게 하는 거죠. 예를 들어 첫 화면 주소랑 준비 검사 주소에 요청을 보내 정상 응답이 오는지를 보는 식이에요.

자동 검증의 좋은 점은 빠지지 않고 늘 한다는 거예요. 사람은 급하면 확인을 건너뛰지만, 자동은 매번 똑같이 확인하거든요. 그리고 문제를 발견하면 자동으로 되돌리기까지 이을 수 있어요. 검증에서 이상하면 배포를 실패로 처리하고 스스로 물러서게 하는 거죠. 저는 이 검증과 자동 롤백의 연결을 중요한 서비스엔 꼭 갖춰요.

자동 검증은 단계적으로 두면 더 좋아요. 배포 직후 기본 응답을 확인하고, 잠시 뒤 오류랑 속도가 정상인지 한 번 더 보는 식이죠. 문제가 바로 드러나는 것도 있지만, 조금 지나야 드러나는 것도 있거든요. 그래서 저는 배포 후 한동안 지켜보는 자동 확인을 붙여, 뒤늦게 터지는 문제도 잡게 해요.

다만 자동 검증이 사람 확인을 완전히 대체하진 못해요. 자동은 미리 정한 것만 확인하니, 예상 못 한 이상함은 못 잡거든요. 디자인이 틀어졌다거나 문구가 어색하다거나 하는 건 여전히 사람 눈이 필요해요. 저는 자동 검증으로 큰 사고를 거르고, 사람 확인으로 미묘한 것을 잡는 식으로 둘을 함께 써요.

자동 검증을 짤 땐 진짜 중요한 것만 골라 담아요. 너무 많이 확인하려 들면 검증이 느려지고 불안정해져, 멀쩡한 배포도 자꾸 실패로 처리하거든요. 그럼 앞서 말한 양치기 소년 문제가 생겨요. 저는 자동 검증엔 이게 안 되면 큰일 나는 핵심만 넣어, 그 빨간불이 늘 진짜이게 유지해요.

검증에서 이상하면 어떻게 해요?

검증에서 문제를 발견하면, 앞 편에서 말한 대로 일단 되돌리는 게 우선이에요. 원인부터 파헤치려 들지 말고, 사용자를 정상 상태로 먼저 돌려놓는 거죠. 되돌린 다음 여유를 갖고 무엇이 잘못됐는지 살펴요. 저는 검증에서 빨간불을 보면 고칠 수 있을 것 같아도 일단 되돌린 뒤 원인을 봐요.

다만 되돌릴 만큼 심각한지는 가늠해야 해요. 서비스가 크게 깨졌으면 두말없이 되돌리지만, 사소한 화면 틀어짐 정도면 되돌리지 않고 다음 배포로 고치는 게 나을 수도 있거든요. 되돌리는 것도 비용이 있으니, 문제의 심각도를 보고 판단해요. 저는 사용자한테 실제로 얼마나 아픈가를 기준으로 삼아요.

이상한데 원인이 애매할 땐, 되돌려서 문제가 사라지는지 봐요. 되돌렸더니 정상이면 새 버전이 원인이라는 게 확실해지죠. 되돌려도 여전히 이상하면 다른 데 원인이 있는 거고요. 이렇게 되돌리기를 원인을 가르는 도구로도 써요. 되돌림으로써 범인이 새 버전인지 아닌지를 빠르게 확인하는 거예요.

문제를 겪고 나면 기록을 남겨 둬요. 무엇이 어떻게 잘못됐는지, 어떻게 알아챘고 어떻게 대응했는지를 적어 두면, 다음에 같은 일이 생겼을 때 훨씬 빨리 대처하거든요. 저는 검증에서 잡은 문제도 사고 기록에 남겨, 검증 항목을 보강하는 데 써요. 이 이야기는 뒤 사고 대응 편에서 더 다룰게요.

무엇보다 검증에서 문제를 잡았으면, 그건 검증이 제 역할을 한 거예요. 사용자보다 먼저 발견했으니 잘된 일이죠. 저는 검증에서 빨간불이 떠도 당황하기보다 다행이다, 사용자 전에 잡았다고 여겨요. 검증의 목적이 바로 이거니까요. 우리가 먼저 아는 것 말이에요.

검증을 습관으로 만들려면요?

검증은 바쁘면 가장 먼저 건너뛰는 단계예요. 배포까지 다 했으니 얼른 다음 일 하고 싶은 마음에, 확인은 대충 넘기게 되거든요. 그래서 저는 검증을 사람 의지에 안 맡기고 절차로 박아 둬요. 자동 검증을 파이프라인에 넣어, 확인 없인 배포가 안 끝나게 만드는 거죠. 습관은 구조로 받쳐야 오래가요.

손으로 하는 확인도 목록으로 만들어 두면 좋아요. 배포 후 이 다섯 개를 확인한다는 목록이 있으면, 급해도 그것만은 빠짐없이 하게 되거든요. 머릿속으로만 하면 바쁠 때 빠지지만, 목록이 눈앞에 있으면 하나씩 지워 가며 챙겨요. 저는 이 배포 후 확인 목록을 팀이 함께 쓰게 해요.

검증 결과를 팀이 함께 보는 곳에 남기는 것도 좋아요. 누가 배포하고 무엇을 확인했는지가 남으면, 확인을 건너뛴 게 드러나 자연스럽게 챙기게 되거든요. 저는 배포랑 검증을 같이 기록해, 배포만 하고 검증을 안 한 게 눈에 띄게 해요. 보이면 챙기게 되니까요.

검증 항목은 사고를 겪을 때마다 늘려 가요. 어떤 문제가 검증을 빠져나가 사용자한테 갔다면, 그걸 잡는 확인을 검증에 추가하는 거죠. 그러면 검증이 우리 서비스의 약한 곳을 점점 촘촘히 덮어 가요. 저는 검증을 고정된 목록이 아니라 자라나는 목록으로 봐요. 겪은 아픔만큼 든든해지는 거죠.

정리하면, 배포 후 검증은 배포 성공과 서비스 정상 사이의 틈을 메우는 마지막 단계예요. 핵심 경로랑 오류랑 속도를 빠르게 훑는 연기 검사로 확인하고, 자동이랑 사람 확인을 함께 쓰며, 이상하면 일단 되돌려요. 무엇보다 검증을 절차로 박아 거르지 않는 습관으로 만들어야 해요. 다음 편에서는 배포 이후에도 계속 서비스를 지켜보는 모니터링과 알림 이야기로 넘어가 볼게요.