로컬 · 스테이징 · 운영 환경

로컬이란?

환경을 나누는 진짜 이유는 테스트를 한 번 더 하기 위해서가 아니라, 문제를 발견하는 시점을 앞으로 당기기 위해서입니다. 로컬에서 잡은 버그는 개발자 한 명이 10분이면 고치지만, 같은 버그가 프로덕션에서 터지면 고객센터 문의, 환불 처리, 사후 보고서까지 따라붙습니다. 환경이 하나뿐인 팀은 고칠 기회가 한 번뿐이고, 세 단계로 나눈 팀은 같은 실수를 세 번 걸러낼 기회를 갖습니다. 배포가 느려지는 게 아니라 되돌리는 비용이 싸지는 구조입니다.

조직 규모에 따라 단계 수는 달라집니다. 개발자 3~5명이면 로컬·스테이징·프로덕션 3단계로 충분하고, 20명이 넘어가면 개발(dev)·QA·스테이징을 따로 두는 4~5단계가 흔합니다. 다만 핵심은 개수가 아니라 스테이징이 운영과 얼마나 닮았는가입니다. 서버 사양, DB 버전, 결제·배송 같은 외부 API의 테스트 계정, 데이터 건수가 다르면 스테이징 통과는 도장 찍는 형식 절차로 전락합니다. 운영 데이터를 복사해 쓸 때는 주민번호·연락처·카드정보를 마스킹한 뒤 옮기는 게 원칙이고, API 키와 DB 접속 정보는 코드가 아니라 환경변수나 시크릿 저장소에 둡니다.

현장에서 제일 자주 나오는 말이 '제 로컬에서는 됐는데요'입니다. 대개 로컬에만 있던 설정 파일이나 임시 데이터에 기대고 있었다는 뜻이라, 로컬 성공은 검증이 아닙니다. 더 위험한 건 급하니까 이번만 운영에서 직접 고치자는 판단인데, 그 한 줄은 다음 배포 때 덮어써지고 원인 추적도 불가능해집니다. 스테이징을 만들어 놓고 관리하지 않는 것도 흔한 함정입니다. 라이브러리 버전이 반년째 뒤처진 스테이징은 통과해도 아무것도 보증하지 못합니다. 마지막으로 로컬 PC에서 운영 DB에 직접 접속하는 관행은 조건절 오타 한 번으로 실데이터를 날리는 사고로 이어집니다.