무코드 앱을 위한 안정적인 Dev·Staging·Prod 환경

환경 분리가 중요한 이유(그리고 어디서 깨지는가)

사람들이 dev, staging, prod 환경에 대해 말할 때 한 가지 약속을 전제로 합니다: 실제 고객, 실제 데이터, 실제 금전적 손실을 위험에 빠뜨리지 않고 안전하게 시도할 수 있어야 한다는 것.

이 약속은 dev와 프로덕션이 중요한 어떤 것을 공유하는 순간 깨집니다. 특히 데이터베이스나 API 키를 공유할 때 그렇습니다. ‘작은 테스트’가 실제 사고로 이어지는 이유는 앱이 연습과 실전의 차이를 구분하지 못하기 때문입니다.

간단히 말하면:

• Dev는 빠르게 만들고 변경하는 곳입니다. 지저분해도 괜찮습니다.
• Staging은 프로덕션처럼 보이는 리허설 공간으로, 릴리스를 엔드투엔드로 검증합니다.
• Prod는 실제 사용자가 의존하는 환경입니다. 신중하게 변경하세요.

환경 분리는 모든 변경을 고위험 작업으로 다루는 대신 더 빠르게 움직일 수 있게 해줍니다.

현실적인 실패 예시는 이렇습니다: 누군가 새 체크아웃 흐름을 테스트했는데 앱이 프로덕션 Stripe 키를 사용하고 있었다면, ‘테스트’가 실제 결제를 만들고 실제 영수증을 트리거해 고객지원이 환불하느라 하루를 보내게 됩니다. 또는 누군가 dev에서 데이터 정리 스크립트를 실행했는데 공유된 프로덕션 데이터베이스를 가리키고 있어 고객 기록이 사라질 수 있습니다. 이메일 기능을 라이브 제공자에 연결해 수천 명의 실제 사용자에게 "환영 메일"을 보내는 일도 흔합니다.

대부분의 사고는 같은 세 가지 원인에서 옵니다: 데이터베이스 공유(테스트가 실제 레코드를 수정함), 자격증명 공유(테스트가 실제 서비스를 호출함), 통합 공유(웹훅, 이메일, SMS, 결제가 실제로 발송됨).

AppMaster 같은 플랫폼은 빠르게 빌드하기 쉽게 해주지만, 안전성은 처음부터 데이터, 시크릿, 통합을 어떻게 분리하느냐에 달려 있습니다.

지키기 쉬운 단순한 환경 모델을 선택하세요

대부분 팀은 세 환경(Dev, Staging, Prod)을 유지하는 것이 가장 실용적입니다. 설정 작업이 부수 프로젝트가 되지 않으면서도 작업을 정리해줍니다.

같은 앱을 위한 세 개의 서로 다른 “세계”로 취급하세요. 각 환경은 자체 데이터베이스, 자체 자격증명, 자체 통합 설정을 가져야 합니다. 이렇게 하면 테스트 가입, 버그 있는 자동화, 잘못된 API 호출이 프로덕션 데이터를 건드릴 수 없습니다.

아주 초기 프로토타입의 경우 두 환경(Dev와 Prod)도 허용될 수 있습니다. 속도와 비용은 확보되지만 안전한 리허설 공간을 포기하게 됩니다. 앱을 팀 외부 누군가가 사용한다면 위험은 급격히 커집니다.

사람 수, 규정 준수, 통합 복잡도가 심해지면 세 개 이상이 필요할 수 있습니다. 흔한 추가 환경은 UAT(사용자 수용 테스트), 통합 테스트 전용 sandbox, 긴급 패치를 위한 임시 hotfix 환경입니다. 환경을 추가하면 이름은 단순하고 예측 가능하게 유지하세요: dev, staging, uat, prod. "staging2", "final-final", 팀 전용 레이블처럼 다른 사람이 이해하기 어려운 이름은 피하세요.

환경이 늘어나면 비용과 시간이 늘어나지만, 프로덕션 사고 한 번의 비용보다는 훨씬 적습니다. 호스팅 추가, 데이터베이스 추가, 시크릿과 통합 설정을 위한 시간이 필요하다고 예상하세요. AppMaster 같은 무코드 플랫폼에서는 앱 로직을 유지한 채 환경 설정만 바꿀 수 있다는 장점이 있습니다.

Dev, Staging, Prod를 정상적으로 유지하는 다섯 가지 규칙

다음 규칙들은 “빠른 테스트”가 장애로 번지는 것을 막고, 배포가 잦더라도 차분함을 유지하게 해줍니다.

1. 환경 간 데이터베이스를 절대 공유하지 마세요. Dev와 Staging은 프로덕션 테이블을 가리켜서는 안 됩니다. 최소한 별도 스키마에 엄격한 권한을 두세요.

2. 모든 곳에서 다른 시크릿을 사용하세요. 데이터베이스 사용자, API 키, 웹훅 서명 시크릿, OAuth 클라이언트 시크릿, 암호화 키는 환경별로 고유해야 합니다. 만약 dev 키가 스크린샷이나 채팅으로 유출되면, 위험은 dev로만 국한되어야 합니다.

3. 통합을 테스트용과 라이브로 나누어 다루세요. 샌드박스 계정이나 테스트 모드를 사용하세요. 제공자가 이를 제공하지 않으면 안전 스위치(비프로덕션에서 아웃바운드 호출 비활성화, 더미 수신자 사용, 기능 플래그로 호출 차단)를 만드세요. 결제, 메시징, 자동화에서 특히 중요합니다.

4. 프로덕션 변경을 잠그세요. 프로덕션은 편집 권한을 가진 사람이 적고 승인 절차가 강해야 합니다. 노코드 도구에서 UI의 사소한 수정도 로직에 영향을 줄 수 있으니 프로덕션은 더 신중히 다루어야 합니다.

5. 승격은 한 방향으로만 하세요. 변경은 dev → staging → prod로만 이동해야 합니다. 프로덕션을 직접 핫픽스하는 것을 피하세요. 그렇지 않으면 수정 사항을 백포트하는 것을 잊어 다음 배포에서 덮어써질 수 있습니다.

예시: AppMaster로 서포트 포털을 만들 때 Dev는 dev PostgreSQL 데이터베이스와 테스트 Stripe 계정을 연결합니다. Staging은 스키마의 새 복사본과 스테이징 전용 API 키로 전체 테스트를 실행합니다. Staging이 통과하면 프로덕션 키와 프로덕션 데이터베이스로 Prod에 배포합니다.

데이터베이스: 분리하고 시드하며 안전하게 마이그레이션하세요

Dev, Staging, Prod가 같은 데이터베이스를 쓴다면 사실상 분리된 환경이 아닙니다. 사소한 테스트 하나가 실제 데이터를 덮어쓰고, 이메일을 트리거하며 리포팅을 망가뜨릴 수 있습니다. 데이터베이스와 파일 저장소는 환경 소유 리소스라고 생각하세요.

데이터를 분리하는 깔끔한 방법은 팀이 매번 실제로 지킬 수 있는 방식이어야 합니다:

• 별도 데이터베이스 서버(가장 강한 격리): Prod는 자체 PostgreSQL 인스턴스를 사용하고 Dev, Staging은 다른 곳에서 운영합니다.
• 한 서버의 별도 데이터베이스: 같은 PostgreSQL 호스트에 app_dev, app_staging, app_prod처럼 DB를 분리합니다.
• 별도 스키마(어쩔 수 없을 때만): 하나의 데이터베이스에 dev, staging, prod 스키마를 두는 방법은 혼동하기 쉬워 추가 안전장치가 필요합니다.

어떤 방식을 선택하든 이름과 연결 설정에서 명확하게 구분되게 하세요. 프로덕션 데이터베이스 이름과 호스트가 스테이징과 혼동되지 않도록 하세요.

시드 데이터: 테스트하기에는 현실적, 잠은 편하게

스테이징은 프로덕션처럼 동작해야 하지만 실제 개인 정보를 포함하면 안 됩니다. 보통은 제어된 소규모 시드 데이터, 프로덕션의 익명화된 스냅샷, 또는 실제 구조와 엣지 케이스를 닮은 합성 데이터를 사용합니다.

서포트 포털의 경우 "환불 요청"이나 "로그인 문제" 같은 합성 티켓으로 검색, 필터링, 권한을 테스트할 수 있습니다.

안전한 마이그레이션: 먼저 스테이징, 그다음 프로덕션

스키마 변경은 사고를 많이 일으킵니다. 안전한 패턴은 다음과 같습니다:

• 마이그레이션을 먼저 스테이징에 적용하고 빠른 스모크 테스트를 실행하세요.
• 프로덕션을 건드리기 전에 백업/복구 포인트를 만드세요.
• 한적한 시간에 프로덕션에서 마이그레이션을 실행하고 롤백 계획을 준비하세요.
• 한 번에 파괴적인 변경(예: 컬럼 삭제)을 하지 마세요. 단계적으로 진행하세요.

AppMaster에서는 Data Designer 변경이 궁극적으로 PostgreSQL의 DB 변경으로 이어지므로, 게시(publish)할 때마다 마이그레이션으로 간주하세요.

비프로덕션에서 프로덕션으로의 실수 쓰기를 막으려면 환경별 자격증명을 사용하고, 네트워크 접근을 제한해 개발 머신이 프로덕션에 닿지 않게 하며, 분석용 계정은 읽기 전용으로 제한하세요.

파일과 첨부도 잊지 마세요. 환경별로 별도 버킷이나 명확히 분리된 폴더를 사용하세요. 테스트 업로드가 데이터베이스 행만큼이나 실제 사용자 레코드로 흘러들어갈 수 있습니다.

자격증명과 시크릿: 앱과 채팅에서 빼내세요

시크릿은 복사되면 피해를 주는 모든 것을 말합니다. Dev, Staging, Prod 환경에서 흔한 항목은 데이터베이스 비밀번호, OAuth 클라이언트 시크릿, Stripe 키, 이메일/SMS 공급자 키, Telegram 봇 토큰 등입니다.

시크릿은 전기가 필요한 곳에만 공급하고 노출되면 안 된다는 원칙으로 다루세요. 즉, 노코드 프로젝트에 하드코딩하지 말고 티켓에 붙여넣지 말며 채팅으로 임시 공유하지 마세요.

실용 규칙은: 환경당 하나의 시크릿 세트. 환경 변수나 플랫폼의 시크릿 저장소를 사용하고 명확한 명명 규칙을 따르세요.

• DEV_DB_PASSWORD, DEV_OAUTH_CLIENT_SECRET, DEV_STRIPE_SECRET_KEY
• STAGING_DB_PASSWORD, STAGING_OAUTH_CLIENT_SECRET, STAGING_STRIPE_SECRET_KEY
• PROD_DB_PASSWORD, PROD_OAUTH_CLIENT_SECRET, PROD_STRIPE_SECRET_KEY

AppMaster에서는 각 배포 대상의 환경별 설정에 이러한 값을 보관하세요. 앱 로직은 실제 값이 아니라 변수 이름만 참조해야 합니다.

저장만큼 접근 통제도 중요합니다. 시크릿을 볼 수 있고 편집할 수 있는 사람을 최소화하고 간단한 변경 로그(누가, 언제, 왜 변경했는지)를 남기세요. 릴리스 체크리스트에 한 줄 적어두는 것만으로도 기억에 의존하는 것보다 낫습니다.

회전(rotate)은 두렵지 않아야 하지만 일상화되어야 합니다. 팀원이 떠날 때, 값이 과도하게 공유되었을 때, 의심스러운 활동 후, 그리고 프로덕션에서는 정기적으로 키를 교체하세요.

교체 후에는 해당 시크릿에 의존하는 흐름을 재검증하세요: 로그인(OAuth 또는 비밀번호 흐름), 결제(테스트 모드 흐름), 이메일/SMS 전송(테스트 주소/번호로), 백그라운드 잡이나 서드파티 API를 호출하는 웹훅 등입니다.

마지막으로 실수로 유출되는 것을 방지하세요. 스크린샷, 문서, "빠른 예제"에 시크릿을 넣지 마세요. 설정을 보여줘야 하면 플레이스홀더(예: PROD_STRIPE_SECRET_KEY=xxxx)를 사용하세요.

통합: 실제 서비스 호출 없이 안전하게 테스트하세요

통합은 Dev, Staging, Prod가 보통 깨지는 장소입니다. 하나의 잘못된 키가 실제 결제, 실제 이메일, 실제 데이터 변경을 일으킬 수 있습니다. 비프로덕션에서는 앱이 프로덕션처럼 동작하되 피해가 불가능한 안전장치가 있어야 합니다.

결제에 대해 하나의 명확한 규칙을 두세요: 라이브 모드는 프로덕션만 사용합니다. Dev와 Staging에서는 테스트 모드와 별도의 테스트 제품, 가격, 웹훅을 사용하세요. 이렇게 하면 전체 체크아웃 흐름을 실행해도 실제 금전적 위험이 없습니다.

이메일과 SMS는 비프로덕션 메시지가 실수로 가면 안 된다고 가정하세요. 아웃바운드 메시지를 내부 인박스 한 곳으로 라우팅하거나 제어된 전화번호로 보내거나 기본적으로 보내기를 비활성화하고 특정 테스터에게만 허용하세요. AppMaster 모듈로 이메일/SMS나 Telegram을 쓰면 동일한 규칙을 적용하세요: 비프로덕션은 절대 실제 고객에게 닿지 않아야 합니다.

웹훅도 분리가 필요합니다. 환경별로 고유한 엔드포인트를 만들고, 서명 검증을 프로덕션뿐 아니라 모든 환경에서 수행하세요. 이렇게 하면 스테이징 트래픽이 프로덕션 핸들러로 가는 것을 막고 스푸핑 문제를 더 일찍 잡을 수 있습니다.

서드파티 API가 샌드박스를 제공하면 사용하세요. 제공하지 않는다면 엄격한 속도 제한과 읽기 전용 권한을 추가하고 비프로덕션 호출이 쉽게 식별되도록(예: 명확한 헤더나 태그) 하세요.

대부분의 사고를 잡아내는 안전 체크리스트:

• Dev, Staging, Prod용 별도 통합 계정/프로젝트
• 비프로덕션 자격증명이 프로덕션 리소스에 접근할 수 없음
• 예약 작업은 비프로덕션에서 기본 비활성화되거나 샌드박스 서비스만 사용
• 웹훅 URL과 서명 시크릿은 환경별로 고유
• 테스트 메시지와 테스트 결제는 명확히 표시

예시: 스테이징 서포트 포털은 가짜 결제를 생성하고 알림을 보낼 수 있지만 모든 메시지는 팀 인박스로 가고 야간 작업은 스테이징 데이터에서만 실행됩니다.

접근 제어와 승인: 누가 어디를 변경할 수 있는가

접근 제어는 Dev, Staging, Prod의 안전 레일입니다. 노코드 앱에서 선의로 프로덕션에서 무언가를 바꿔 사고가 나는 경우가 많습니다.

몇 가지 역할로 시작하고 명확히 유지하세요. 작은 팀이라도 보기 권한자, 테스트 권한자, Dev/Staging 편집자, 그리고 환경과 시크릿을 배포/관리할 수 있는 소수의 사람이 있으면 좋습니다.

프로덕션 접근 권한은 생각보다 작게 유지하세요. 사람이 매주 프로덕션 접근이 필요하지 않다면 영구적으로 권한을 주지 마세요. 필요할 때(예: 라이브 이슈 조사) 일시적으로 권한을 부여하고 작업 후 제거하세요.

프로덕션에 무언가가 닿기 전에 경량 승인 단계를 추가하세요. 실제로는 한 사람이 릴리스를 준비하고 두 번째 사람이 승인하는 식이면 충분합니다. AppMaster를 사용한다면 "프로덕션으로 게시"와 "스키마 변경 적용"을 단순 편집 권한으로 허용하지 말고 명시적 권한이 필요하게 설정하세요.

기본적인 감사 추적을 유지하면 세 가지 질문에 빨리 답할 수 있습니다: 누가, 언제, 어떤 환경에서 무엇을 바꿨는가.

롤백 계획을 미리 평이한 언어로 작성하세요. 빠르게 되돌릴 수 있는 것(이전 버전 재배포, 기능 토글 비활성화)과 되돌리기 어려운 것(데이터 삭제, 되돌릴 수 없는 마이그레이션)을 구체적으로 적고, 누가 롤백을 트리거할 권한이 있는지와 복구 확인 방법도 포함하세요.

단계별 가이드: 노코드 앱에 Dev, Staging, Prod 설정하기

먼저 어떤 것이 절대 공유되어서는 안 되는지 적어두세요: 데이터베이스, 시크릿(API 키, 토큰), 실제 이메일을 보내거나 카드를 결제하거나 고객에게 메시지를 보낼 수 있는 통합. 하나만 분리한다면 데이터베이스를 분리하세요.

반복 가능하면서 지저분해지지 않는 설정:

1. 환경 이름과 경계를 정하세요. 일관된 이름(Dev, Staging, Prod)을 쓰고 각 환경마다 자체 데이터베이스, 자체 시크릿, 자체 통합 계정 또는 테스트 모드가 있다고 결정하세요.

2. 별도 설정으로 앱을 복제하세요. AppMaster 같은 노코드 플랫폼에서 동일한 앱의 Dev와 Staging 버전을 만드세요. 로직은 같게 유지하되 환경 설정(데이터베이스 연결 문자열, API 키, 웹훅 URL)은 분리하세요.

3. 데이터베이스를 생성하고 시드한 뒤 경계를 증명하세요. 세 개의 데이터베이스(또는 부득이한 경우 세 개의 분리된 스키마)를 만들고 Dev와 Staging을 현실감 있는 가짜 데이터로 채우세요. 경계 확인을 해보세요: Staging에서 레코드를 만들고 Prod에 나타나지 않는지 확인한 뒤 역으로도 확인하세요.

4. 통합을 안전 모드로 설정하고 웹훅을 검증하세요. 결제는 테스트 모드, 이메일은 샌드박스 인박스로, 메시징은 테스트 채널로 설정하세요. 전체 흐름(가입, 비밀번호 재설정, 결제 시도)을 트리거하고 웹훅이 각 환경에만 도착하는지 확인하세요.

5. 스테이징 체크리스트를 실행한 뒤 동일한 변경을 승격하세요. 핵심 여정, 권한, 오류 경로를 스테이징에서 테스트하세요. 깨끗하면 동일한 변경을 Prod에 적용하세요(프로덕션에서만 하는 임시 수정은 피하세요).

릴리스 후에는 짧은 모니터링 창을 두고 로그, 실패 요청, 통합 대시보드를 관찰하세요. 트래픽이 정상일 때까지 이전 빌드, 이전 구성, 기능 토글 등으로 롤백 옵션을 준비하세요.

예시 시나리오: 실제 사용자를 위험에 빠뜨리지 않고 서포트 포털 릴리스하기

작은 운영팀이 내부 서포트 포털을 만듭니다: 상담원이 로그인하고 고객을 조회하고 Stripe로 추가 요금을 청구하며 티켓 상태가 바뀔 때 이메일로 업데이트를 보냅니다. 이들은 테스트가 실제 돈이나 실제 인박스에 닿지 않도록 세 환경으로 운영합니다.

Dev에서는 기본적으로 모든 것이 가짜입니다. 데이터베이스는 분리되어 있고 샘플 고객, 샘플 티켓, 이메일이 없는 경우 같은 문제 케이스로 시드되어 있습니다. 인증은 테스트 사용자 디렉터리나 소수의 테스트 계정을 가리킵니다. Stripe는 테스트 모드와 테스트 카드, 이메일은 샌드박스 메일박스로 가거나 비활성화되어 로그로 남깁니다.

Staging의 목표는 위험 없이 실전과 유사하게 만드는 것입니다. 데이터베이스는 별도로 두지만(예: 익명화된 프로덕션 스냅샷), 인증은 프로덕션 설정과 같게 맞추되 접근은 소수로 제한합니다. Stripe는 테스트 모드로 유지하되 현실적인 결제와 환불 흐름을 실행합니다. 이메일은 승인된 내부 주소로만 허용됩니다.

Prod에서는 포털이 잠겨 있습니다. 승인된 관리자만 통합을 변경하거나 배포할 수 있고, 실제 Stripe 키와 실제 이메일 전송이 활성화되며 감사 로그가 켜져 있습니다.

새 기능: 원클릭 환불 워크플로를 만든다고 합시다. 빌더는 AppMaster의 Business Process Editor로 Dev에서 만들고 테스트 카드로 테스트하며 UI 문구와 상태 업데이트를 확인합니다.

Staging에서는 실패가 안전하게 드러납니다: 환불 로직이 동일 상태 변경에 대해 두 단계가 동시에 실행되어 "티켓 종료" 이메일이 두 번 전송되는 문제가 발견되었습니다. 프로덕션이었다면 고객에게 스팸을 보냈을 텐데, 스테이징에서는 내부 인박스에만 도달하므로 팀이 조건을 수정하고 재검증했습니다.

그들은 몇 가지 기본을 문서화해서 나중에 추측할 필요가 없게 했습니다: 환경 이름과 담당자, 키가 어디에 저장되는지와 누가 회전시키는지, 각 환경에 속한 데이터베이스, 릴리스 체크리스트, "Dev에 실제 데이터 금지" 규칙 등입니다.

생산 사고를 일으키는 흔한 실수들

여기서 대부분 사고는 신비한 버그가 아닙니다. 잘못된 데이터베이스, 잘못된 키, 잘못된 엔드포인트 같은 실수에서 옵니다.

가장 큰 함정은 환경 간 공유 데이터베이스입니다. 초기에는 현실적인 데이터가 편리해 보여 쓰기 쉽지만, 나중에는 조용한 위험이 됩니다: 테스트 스크립트가 레코드를 삭제하거나, 마이그레이션이 너무 일찍 실행되거나, 새 필드가 프로덕션 코드가 읽을 수 없는 형식으로 쓰이는 식입니다.

또 다른 빈번한 원인은 스테이징에서 프로덕션 API 키를 사용하는 것입니다. 결제와 이메일이 주된 문제입니다. 한 번의 스테이징 체크아웃이 실제 결제를 만들고 스테이징 이메일 테스트가 실제 고객에게 메일을 보낼 수 있습니다. 도구가 환경 변수나 배포별 별도 구성을 지원한다면(많은 노코드 플랫폼이 그렇고 AppMaster도 포함) 키는 앱의 일부가 아니라 환경의 일부로 취급하세요.

웹훅 혼동도 유사한 문제입니다. 팀이 웹훅 엔드포인트를 재사용하면 스테이징과 프로덕션이 같은 이벤트를 받게 되어 주문 중복, "계정 생성" 흐름 반복, 풀기 어려운 지원 티켓이 발생합니다.

백그라운드 작업은 조용히 실행되기 때문에 추가 주의가 필요합니다. 야간 동기화, "알림 전송" 워크플로우, 자동 종료 프로세스는 스테이징에서 활성화되어 있으면 실서비스를 건드릴 수 있습니다.

출하 전 체크리스트 및 다음 단계

배포 직전에는 잘못된 데이터베이스 지정, 잘못된 API 키 붙여넣기, 위험한 웹훅 활성화 같은 흔한 실수를 잡는 빠른 점검이 필요합니다.

10분 안에 할 수 있는 빠른 체크리스트:

• 데이터베이스 대상이 올바른지(호스트 및 데이터베이스 이름 포함) 확인하고 비프로덕션에서 프로덕션 연결 문자열을 사용하지 않았는지 점검하세요.
• 각 시크릿이 프로덕션 전용인지(API 키, OAuth 클라이언트 시크릿, 결제 키) 확인하고 비프로덕션 키가 프로덕션 리소스에 접근할 수 없는지 확인하세요.
• 웹훅과 콜백 설정을 확인해 프로덕션 엔드포인트가 스테이징 이벤트를 받지 않게 하세요.
• 아웃바운드 메시지가 실고객에게 가는지 검증하세요.
• 스테이징 스모크 테스트 실행: 로그인, 레코드 하나 생성, 핵심 워크플로우 하나를 엔드투엔드로 실행한 뒤 로그에서 프로덕션 서비스 호출을 확인하세요.

그다음 사람 관련 체크: 프로덕션 접근자 목록을 검토하고 필요 없는 사람은 제거하세요. 도구가 역할을 지원한다면, 팀이 작더라도 프로덕션 변경에 대해 승인 단계를 요구하세요.

시간이 지나도 이걸 유지하려면 이름과 변수명(DEV, STAGING, PROD)을 표준화하고 시크릿과 접근 권한을 월간으로 검토하세요. 사고가 났을 때 하는 것보다 정기적으로 하는 것이 훨씬 쉽습니다.

AppMaster로 빌드하면 환경별로 별도 PostgreSQL 구성을 유지하고, auth, Stripe, email/SMS 같은 모듈을 각 배포 대상의 키로 가리키며 앱 로직을 바꾸지 않고도 다른 타깃(AppMaster Cloud나 주요 클라우드 제공자)에 배포할 수 있습니다. 더 자세한 플랫폼 정보는 AppMaster의 홈페이지인 appmaster.io를 참고하세요.