배포는 공연장 문을 열고 관객이 들어오는 순간이에요. 영리한 팀은 그 전에, 텅 빈 객석 앞에서 전체 공연을 한 번 더 돌려봐요.
여기엔 두 세계가 있어요. 처음 시작하는 개발자 대부분은 그중 하나만 알고 있죠. 프로덕션(Production)은 진짜 세계예요. 실제 고객이 사용하는 라이브 앱이고, 실제 주문과 실제 돈이 흘러요. 스테이징(Staging)은 그 앱을 거의 똑같이 복제한 환경이에요. 실제 고객은 아무도 들어오지 않고, 팀만 들어와 리허설을 해요.
드레스 리허설이냐, 개막 공연이냐. 프로덕션은 개막 공연이에요. 객석이 꽉 찼고, 티켓은 팔렸고, 대사를 틀리면 돈 낸 관객 앞에서 틀리는 거예요. 스테이징은 같은 무대에서 진행하는 최종 드레스 리허설이에요. 같은 세트, 같은 조명, 같은 대본이지만 좌석은 비어 있어요. 소품이 부러지거나 배우가 멈추더라도 다시 하면 그만이에요. 진지한 공연이라면 드레스 리허설을 건너뛰고 바로 개막 공연에 오르지 않잖아요. 스테이징이 바로 그 리허설이에요.
왜 "조심하면 되지" 대신 복사본 전체가 필요할까요? 변경 사항이 진짜 작동하는지 확인하는 유일하게 정직한 방법은 실제 환경과 똑같이 생긴 세계에서 돌려보는 거예요. 같은 설정, 같은 데이터 구조, 같은 연결 방식 — 단, 실제 결과만 없는 곳에서요. 자기 노트북(localhost)에서만 테스트하는 건 충분하지 않아요. 내 컴퓨터는 라이브 환경과 구조가 다르고, 밖에 나가면 동작이 달라지는 일이 생기거든요. 스테이징이 그 간격을 메워줘요. 프로덕션의 쌍둥이인데, 실제 고객만 빠진 곳이에요.
그래서 배포 흐름은 세 박자로 늘어나요.
내 컴퓨터에서 빌드하고 깨뜨려 봐요. 비공개 공간이에요. 아무도 실수를 보지 않아요.
스테이징에 올려요. 드레스 리허설이에요. 전체 흐름을 눌러보고, 실제 공연처럼 돌리고, 어디가 무너지는지 잡아요.
스테이징이 깨끗할 때만 프로덕션으로 가요. 우연이 아니라 의도된 개막 공연이에요.
"스테이징에 먼저 올려"라는 말을 풀면 이렇게 돼요. 진짜 세계를 건드리기 전에 쌍둥이 세계에서 돌려보자. 관료적인 절차가 아니에요. 버전 관리나 풀 리퀘스트 뒤에 있는 본능과 같아요. 안전장치를 만들고, 작동을 증명하고, 그다음에 현실에 닿게 하는 거예요.
한 가지 솔직한 얘기를 덧붙이면, 소규모 프로젝트는 스테이징을 완전히 건너뛰는 경우가 많아요. 영향 범위가 작고 롤백이 쉽다면 그래도 괜찮아요. 진짜 고객과 진짜 돈이 걸리는 날이 오면, 빈 객석 리허설은 선택이 아니게 되죠.
프로덕션은 개막 공연이에요. 스테이징은 모든 좌석이 빈 채로 같은 무대에서 하는 드레스 리허설이고요. 거기서 리허설하고, 여기서 공연해요.