배포 완료와
서비스 완성은 왜 다른가

코드를 서버에 올리고 서비스 화면이 정상적으로 열리면 우리는 흔히 “완성됐다”고 말합니다. 하지만 배포가 성공했다는 것은 새로운 버전이 실행되기 시작했다는 뜻일 뿐, 그 서비스가 안정적으로 운영될 준비를 마쳤다는 뜻은 아닙니다.

배포 완료가 알려주는 것

배포 과정은 새 버전이 운영 환경에 도착했는지를 확인합니다. 파일이나 컨테이너가 배치되고, 애플리케이션 프로세스가 실행되며, 사용자가 서비스에 접속하고 기본 기능을 사용할 수 있다면 배포는 성공했다고 판단할 수 있습니다.

이 확인은 반드시 필요합니다. 그러나 이것만으로는 실제 운영에서 발생할 질문에 답할 수 없습니다. 지금 실행 중인 버전이 무엇인지, 핵심 기능이 정말 정상인지, 사용자가 겪는 오류를 발견할 수 있는지, 문제가 생겼을 때 안전하게 되돌릴 수 있는지는 별도로 검증해야 합니다.

서비스 완성에 필요한 여섯 가지 확인

프로세스가 살아 있다는 것과 서비스가 정상이라는 것은 다릅니다

애플리케이션 프로세스가 실행 중이어도 Database 연결이 끊겼거나 외부 API가 응답하지 않을 수 있습니다. 인증 설정이 잘못되어 보호해야 할 자료가 공개되거나, 반대로 정상 사용자가 접근하지 못할 수도 있습니다.

그래서 단순한 프로세스 상태와 함께 핵심 의존성을 확인하는 Health Check가 필요합니다. 서비스의 대표 기능을 실제 사용자와 같은 경로로 호출하는 Smoke Test도 필요합니다. “서버가 켜져 있다”가 아니라 “사용자가 필요한 기능을 사용할 수 있다”를 확인해야 합니다.

문제는 발견할 수 있을 때 대응할 수 있습니다

운영 중인 서비스는 응답 시간, 오류율, 자원 사용량과 주요 기능의 성공 여부를 관찰할 수 있어야 합니다. 로그도 단순히 많이 남기는 것이 목적이 아닙니다. 발생 시각, 요청 경로, 버전과 오류 원인을 연결해 문제를 재현하고 설명할 수 있어야 합니다.

관찰할 수 없는 서비스는 사용자가 문제를 알려줄 때까지 장애를 알기 어렵습니다. 원인을 찾는 동안 어떤 변경이 영향을 주었는지도 확인하기 어렵습니다. 모니터링과 로그는 장애 이후에 추가하는 부가 기능이 아니라 서비스를 운영하기 위한 기본 조건입니다.

Rollback은 파일을 되돌리는 명령 하나가 아닙니다

새 버전에 문제가 생겼을 때 이전 파일을 다시 복사하는 것만으로 복구된다고 보장할 수 없습니다. 애플리케이션 코드와 설정, Database 변경, 인증 정책과 외부 서비스의 상태가 함께 맞아야 하기 때문입니다.

Rollback에는 돌아갈 기준 버전, 실행 조건, 복구 순서와 검증 방법이 있어야 합니다. 백업은 생성했다는 기록만으로 충분하지 않습니다. 체크섬으로 무결성을 확인하고, 격리된 위치에서 실제로 풀어 보며, 복원된 서비스가 정상인지 확인해야 합니다.

실제 사용자에게 제공하기 전에 답해야 할 질문

• 현재 배포할 버전과 운영 중인 버전은 무엇입니까?
• 이번 배포에서 변경된 파일, 설정과 권한은 무엇입니까?
• 배포 전에 백업했고 그 백업을 실제로 복원해 보았습니까?
• 배포 성공과 서비스 정상 상태를 무엇으로 판단합니까?
• 기존 기능, 공개 URL과 사용자 인증은 그대로 동작합니까?
• 오류와 성능 저하를 확인할 로그와 모니터링이 있습니까?
• 장애가 발생하면 무엇부터 확인하고 누가 판단합니까?
• 어떤 조건에서 Rollback하며 이전 버전은 어떻게 검증합니까?

서비스 완성은 운영 가능성을 포함합니다

서비스 구현은 기능을 만드는 일입니다. 배포는 그 기능을 운영 환경에 전달하는 일입니다. 서비스 완성은 전달된 결과를 확인하고, 문제가 생겼을 때 원인을 찾으며, 안전하게 정상 상태로 되돌릴 수 있는 상태를 만드는 일입니다.

잘 배포된 서비스보다 더 중요한 것은 계속 책임질 수 있는 서비스입니다.