스테이징 환경이란? 공개 전에 테스트하기

스테이징 환경은 실제 사용자가 보기 전에 변경 사항을 테스트하는, 앱의 비공개 복사본이며 라이브 버전과 가능한 한 똑같이 설정되어 있습니다. 자체 데이터베이스, 테스트 데이터, 테스트 API 키를 사용하므로 여기서 기능이 깨지거나 데이터 변경이 잘못되어도 팀 바깥의 누구도 영향을 받지 않습니다. 스테이징에서 변경이 올바르게 보이면, 고객이 사용하는 라이브 앱인 운영(프로덕션) 환경에 배포합니다.

AI로 만들 때 스테이징이 중요한 이유

AI로 만들면 변경이 빠릅니다. 기능을 추가하고, 페이지를 다시 쓰고, 데이터 구조를 바꾸는 일이 몇 분이면 끝납니다. 이 속도는 훌륭하지만, 겉보기에 괜찮아 보였던 변경이 조용히 결제를 망가뜨리거나 "작은 정리"가 고객 데이터의 열 하나를 지워 버리기 전까지만 그렇습니다.

라이브로 나가기 전에 변경을 확인할 공간은 다음에 도움이 됩니다.

• 고객보다 먼저 문제 발견. 중요한 변경을 할 때마다 회원가입, 결제, 핵심 흐름을 시험해 보세요.
• 실제 환경과 비슷한 설정으로 테스트. 스테이징은 운영처럼 동작해야 합니다. 같은 스택, 비슷한 설정을 쓰면 문제가 나중이 아니라 그곳에서 드러납니다.
• 실제 데이터 보호. 데이터베이스 변경, 가져오기, 일괄 편집은 먼저 테스트 데이터로 연습할 수 있습니다.
• 작업 중인 내용 보여 주기. 클라이언트나 팀원이 공개하지 않고도 변경 사항을 검토할 수 있습니다.

일상적인 비유

극장의 총연습(드레스 리허설)을 떠올려 보세요.

• 개발은 연습실입니다. 배우들이 대사를 시험해 보고, 멈추고, 다시 시작하고, 실험합니다.
• 스테이징은 총연습입니다. 의상, 실제 무대, 실제 조명까지 모든 것이 개막 공연과 똑같지만, 돈을 내는 관객만 없습니다.
• 운영은 개막 공연입니다. 실수는 모든 사람 앞에서 일어납니다.

개막 공연에서 나타나면 곤란한 문제 대부분은 총연습에서 드러납니다. 의상 교체가 너무 오래 걸리거나, 조명 큐가 잘못되어 있는 식입니다. 바로 그것이 스테이징의 역할입니다.

흔히 쓰는 세 가지 환경

각 환경은 주로 설정에서 다릅니다. 어떤 데이터베이스에 연결하는지, 어떤 키를 쓰는지, 어떤 URL에 있는지가 다르죠. 그래서 좋은 앱은 이런 설정을 코드에 고정하지 않고 환경 변수와 시크릿에서 읽어 옵니다. 그러면 같은 코드가 환경마다 다른 설정으로 실행될 수 있습니다.

실제 예: 예약 앱의 취소 규칙 바꾸기

유료 고객이 있는 미용실 예약 앱을 운영한다고 해 봅시다. 고객이 48시간 전이 아니라 24시간 전까지 취소할 수 있도록 규칙을 바꾸고, 환불은 자동으로 처리하려고 합니다.

1. 개발 환경에서 만들기. AI 빌더에게 변경을 요청합니다. 취소 로직과 결제 제공업체에 대한 환불 호출을 업데이트해 줍니다.

2. 스테이징에 배포하기. 스테이징은 같은 코드를 실행하되, 테스트 예약이 들어 있는 스테이징 데이터베이스와 결제 제공업체의 테스트 모드 키에 연결되어 있습니다.

3. 실제 흐름 테스트하기. 본인과 동료가 함께 다음을 확인합니다.

• 내일 날짜로 테스트 예약을 잡고 30시간 전에 취소하면, 환불이 되어야 합니다.
• 10시간 전에 취소를 시도하면, 분명한 메시지와 함께 거부되어야 합니다.
• 환불 내역이 결제 제공업체의 테스트 대시보드에 나타나는지 확인합니다.
• 확인 이메일에 48시간이 아니라 24시간이라고 적혀 있는지 확인합니다.

4. 버그 찾기. 스테이징에서 규칙이 미용실이 아닌 서버의 시간대를 쓰고 있어서 마감 시간이 한 시간 어긋난다는 것을 발견합니다. 이를 고친 뒤 다시 테스트합니다.

5. 운영에 배포하기. 이제서야 변경 사항이 실제 고객에게 닿습니다. 시간대 버그는 이미 잡힌 상태입니다.

스테이징이 없었다면 4단계의 문제는 실제 고객의 환불에서 일어났을 것입니다.

핵심 용어

흔한 오해

• "스테이징이 운영 데이터베이스를 공유해도 된다." 이것은 가장 위험한 지름길입니다. 레코드를 삭제하거나 수정하는 테스트가 실제 고객에게 영향을 줄 수 있습니다. 스테이징에는 자체 데이터베이스를 주세요.
• "스테이징에서 작동하면 운영에서 깨질 수 없다." 스테이징은 위험을 줄여 줄 뿐 없애지는 못합니다. 실제 트래픽, 실제 데이터, 외부 서비스는 여전히 예상치 못한 일을 일으킬 수 있습니다. 롤백할 방법을 준비해 두세요.
• "스테이징은 비싸야 한다." 작아도 됩니다. 운영과 같은 크기가 아니라 같은 구성이면 충분합니다.
• "현실적이도록 스테이징에서 라이브 결제 키를 쓰자." 제공업체의 테스트 모드를 쓰세요. 현실적이라는 것이 실제 돈을 쓴다는 뜻은 아닙니다.
• "스테이징은 큰 팀만 쓰는 것이다." 먼저 안전한 곳에서 테스트한다는 발상은 혼자서 하는 사람에게도 유용합니다. 격식의 수준은 걸린 위험에 맞춰 조절할 수 있습니다.
• "사람들이 써 볼 수 있게 스테이징을 공개해야 한다." 비공개로 두거나 보호하고, 검색엔진이 색인하지 못하게 하세요. 그래야 아무도 그것을 실제 앱으로 착각하지 않습니다.

AI 빌더에게 무엇을 요청할까요

• "데이터베이스, API 키, 사이트 URL처럼 환경마다 다른 모든 설정은 환경 변수에서 가져오게 해 줘."
• "운영이 아닌 데이터베이스를 현실적인 테스트 데이터로 채우는 시드 스크립트를 추가해 줘."
• "출시한다고 말하기 전까지는 결제 제공업체의 테스트 모드를 사용해 줘."
• "이 변경을 라이브로 내보내기 전에, 내가 테스트해야 할 흐름과 각 흐름에서 일어나야 할 일을 나열해 줘."
• "이 변경이 기존 데이터에 영향을 주나요? 먼저 마이그레이션을 보여 줘."
• "운영이 아닌 사이트 복사본이 검색엔진에 색인되지 않도록 해 줘."

단계별 설정은 스테이징 환경을 설정하는 방법을 참고하세요. 릴리스가 잦아지면, 코드에서 스테이징을 거쳐 운영으로 가는 과정을 자동화하는 것이 CI/CD의 역할입니다.

Mythex에서 출시 전 테스트하기

Mythex에는 별도의 "스테이징 대 운영" 전환 스위치가 없습니다. 게시하면 공개 라이브 URL이 하나 생기며, 문서에도 이를 분명히 설명하고 있습니다(다중 서비스 앱). 대신 만드는 일과 라이브로 나가는 일을 명확히 나눠 줍니다.

• **미리보기(Preview)**는 만드는 동안 앱을 비공개 클라우드 샌드박스에서 실행합니다. 변경 사항은 라이브 앱이 아니라 여기에 먼저 나타납니다.
• **공유(Share)**는 미리보기 링크를 만들어, 클라이언트나 팀원이 Mythex 계정 없이, 그리고 여러분이 게시하지 않고도 작업 중인 내용을 검토할 수 있게 합니다. 링크는 빌드 중인 변경 사항을 포함해 샌드박스의 현재 상태를 보여 주며, 언제든 삭제할 수 있습니다.
• **게시(Publish)**는 프로젝트의 스냅샷을 찍고 배포합니다. 다시 게시하기 전까지 라이브 앱은 이전 상태 그대로 유지됩니다.
• **체크포인트(Checkpoints)**는 에이전트가 턴을 성공적으로 마칠 때마다 저장되므로, 변경이 잘못되었을 때 프로젝트 파일을 되돌릴 수 있습니다.

미리보기를 리허설로 생각하세요. 출시 전까지는 결제 제공업체를 테스트 모드로 두고, 게시할 때마다 핵심 흐름을 한 번씩 점검하세요. 실제 고객이 관여하기 시작하면, 데이터를 쓰거나 지우는 것을 테스트하기 전에 에이전트에게 미리보기가 어떤 데이터베이스와 키를 쓰는지 확인하세요. 자체 데이터베이스를 갖춘 완전히 분리된 스테이징 구성이 필요하다면, 에이전트에게 프로젝트에 맞는 선택지를 설명해 달라고 하거나, Pro 요금제에서는 프로젝트를 내보내거나 GitHub에 동기화해서 직접 관리하는 인프라에서 실행하세요.

자주 묻는 질문