Publish 또는 Update 버튼에 "Your Cloud Balance is insufficient to publish" 또는 "Your Cloud Balance is insufficient to update"가 표시되면 Cloud 지갑의 잔액이 소진된 것입니다.

해결 방법:

1. Settings > Cloud & AI로 이동해 현재 잔액을 확인합니다.

2. Top up now를 선택하고 Cloud 지갑에 금액을 충전합니다.

3. Publish 패널로 돌아가 다시 시도합니다.

참고: Cloud 지갑은 구독 크레딧과 별개입니다. Cloud 지갑은 호스팅 및 배포 서비스를 위한 것이며, 구독 크레딧은 AI 에이전트 대화에 사용됩니다.

1. 스토리지 사용량 보기를 확인하고 가장 큰 채팅, 프로젝트, 파일을 식별합니다.
2. 나중에 필요할 수 있는 항목은 다운로드하거나 백업합니다.
3. 불필요한 항목만 삭제합니다. 채팅 삭제 시 연결된 디스크 데이터를 제거하는 옵션이 있다면, 해당 데이터를 안전하게 버려도 되는지 확인한 후에만 선택하세요.
4. 페이지를 새로고침하고 사용 가능한 스토리지가 늘어났는지 확인합니다.
5. Publish로 돌아가 한 번 더 다시 시도합니다.

삭제는 영구적일 수 있으며 제거된 파일을 참조하는 프로젝트가 손상될 수 있습니다. 사용량이 줄지 않으면 스토리지 보기, 플랜, 프로젝트 링크, 게시 실패 시간을 포함해 Support에 문의하세요.

보안 스캔이 끝날 때까지 기다린 다음, 게시 전에 표시된 모든 항목을 검토하세요.

1. Resolve All을 선택하고 영향을 받는 동작을 점검하세요. 프로덕션에서 사용하기 전에 노출된 비밀 정보, 인증, 권한, 사용자 데이터 또는 안전하지 않은 외부 접근과 관련된 문제를 수정하세요.
2. 비밀 정보가 노출되었을 수 있다면 프로젝트에서 제거하고 게시 전에 관련 제공업체에서 교체하세요.
3. 스캔을 다시 실행하고 영향을 받는 흐름을 검증하세요.
4. 책임 있는 검토자가 남아 있는 비치명적 위험을 이해하고 수용하는 경우에만 Publish Anyway를 사용하세요. 이유를 기록하고 프로덕션 사이트에서 해결되지 않은 위험을 우회하지 마세요.

결과의 영향을 판단할 수 없다면 게시하지 마세요. 결과 텍스트와 민감 정보를 제거한 증거를 포함해 Support 또는 보안 책임자에게 문의하세요.

1. 플랫폼 프로덕션 URL과 사용자 지정 도메인을 각각 테스트하세요. 또한 루트 페이지와 실패하는 특정 페이지 또는 API 경로를 비교하세요.
2. 정확한 상태 코드, 전체 URL, 시간과 시간대, 그리고 실패가 지속적인지 간헐적인지 기록하세요.
3. 최신 배포 상태를 확인하고, 최근의 종속성, 환경 변수, 데이터베이스 또는 외부 서비스 변경이 실패 시작 시점과 일치하는지 확인하세요.
4. 관련 Console 및 Network 오류를 캡처하세요.

문제가 계속되면 재현 단계, 영향을 받는 버전, 민감 정보를 제거한 진단 정보를 포함해 Support에 문의하세요. HAR, 명령 출력 또는 스크린샷을 보내기 전에 쿠키, Authorization 헤더, 토큰, 비밀 쿼리 매개변수, 개인 데이터, 결제 정보를 제거하세요.

배포 시간이 초과되었거나 라이브 사이트를 일시적으로 사용할 수 없는 경우:

1. 플랫폼의 Prod 서브도메인과 Preview가 모두 접근 불가인지, 아니면 둘 중 하나만 그런지 확인하세요.

2. 현재 오류 페이지를 그대로 두세요 — Publish를 반복해서 클릭하지 마세요.

3. 최근에 종속성, 시작 진입점 또는 데이터베이스 연결을 수정했는지 확인하세요. 이러한 변경은 배포에 영향을 줄 수 있습니다.

문제가 계속되면 Support에 문의하고 다음을 포함하세요:

- 프로젝트 링크와 라이브 URL

- 실패 시간과 사용자의 시간대

- 버전 번호와 오류 페이지 스크린샷

- Preview가 정상적으로 작동하는지 여부

- 최근에 종속성, 시작 진입점 또는 데이터베이스 연결을 수정했는지 여부

Publish 패널에 버튼이 비활성화된 상태로 "latest"가 표시되거나 "Building"에서 멈춘 경우:

1. Publish를 반복해서 클릭하지 마세요 — 속도가 빨라지지 않으며 중복 빌드 작업이 생성될 수 있습니다.

2. 몇 분 기다린 후 페이지를 새로고침하세요.

3. 새로고침 후에도 상태가 바뀌지 않으면 Support에 문의하세요.

Support에 문의할 때는 다음을 포함하세요:

- 채팅 링크

- Publish 패널 전체 스크린샷(페이지 URL, 버전 번호, 버튼 상태 포함)

- 발생 시간과 사용자의 시간대

- 현재 표시된 버전 번호

- 어느 단계에서 "Building"이 표시되기 시작했거나 버튼이 비활성화되었는지

1. 이미지가 App Viewer에서 없는지, 게시된 사이트에서 없는지, 또는 둘 다에서 없는지 확인하세요.
2. Reload App Viewer를 한 번 선택하세요. 문제가 라이브 사이트에만 있다면 최신 버전이 게시되었거나 업데이트되었는지 확인하세요.
3. 에이전트에게 페이지, 표시되어야 하는 이미지, 그리고 이미지의 원래 출처를 알려 주세요. 현재 프로젝트가 여전히 올바른 이미지 이름과 위치를 사용하고 있는지 확인해 달라고 요청하세요.
4. 원본 이미지가 제거되었거나 이름이 변경되었다면 의도한 이미지를 다시 업로드하거나 선택한 후 페이지를 다시 테스트하세요.
5. 이미지가 App 스토리지 또는 다른 연결된 서비스를 사용한다면 의도한 서비스가 연결되어 있고 파일이 여전히 այնտեղ 존재하는지 확인하세요.

이미지가 여전히 로드되지 않으면 Atoms Support에 Chat Link, 영향을 받는 페이지 URL, 이미지 이름 또는 출처, 스크린샷을 포함해 문의하세요. 비공개 접근 링크, 비밀번호, 키 또는 토큰은 포함하지 마세요.

내보낸 셀프 호스팅 패키지가 정상적으로 다운로드되었지만 실행되지 않는 경우:

1. 내보내기 패키지에 포함된 README에서 환경 요구 사항과 설정 단계를 확인하세요.

2. 실행 환경이 요구 사항(OS 버전, Docker 버전, Node.js 버전)과 일치하는지 확인하세요.

3. 시작 명령을 실행하고 오류 메시지가 있는지 전체 출력을 검토하세요.

문제가 계속되면 Support에 문의하고 다음을 포함하세요:

- 내보내기 버전과 다운로드 시간

- 실행 중인 OS와 Docker 버전

- 실행한 전체 명령과 전체 출력

- 실패한 스크립트 또는 API 경로

- 예상한 배포 방식

중요: 민감 정보를 제거한 구성 예시는 첨부하되 비밀번호, 비밀 정보 또는 토큰은 포함하지 마세요.

App Viewer와 게시된 사이트는 프로젝트의 서로 다른 단계를 보여 줍니다. 시각적 변경 사항을 저장해도 라이브 사이트는 자동으로 업데이트되지 않습니다.

1. Design에서 Save를 선택하고 현재 에이전트 작업 또는 빌드가 끝날 때까지 기다리세요.
2. Publish를 여세요. 게시는 최신 프로젝트 버전을 사용하며 Publish 패널에는 버전 선택기가 없습니다.
3. 첫 게시라면 Publish를, 이후 게시라면 Update를 선택하세요. 패널에 Up to date가 표시될 때까지 기다리세요.
4. 새 탭에서 라이브 사이트를 열고 한 번 새로고침하세요.
5. 기본 Atoms 주소에서는 변경 사항이 보이지만 사용자 지정 도메인에서는 보이지 않는다면 같은 버전을 반복해서 게시하지 말고 도메인 연결을 확인하세요.

라이브 사이트에 여전히 잘못된 버전이 표시되면 Atoms Support에 Chat Link, 라이브 URL, 게시하려던 버전, 시간과 시간대, App Viewer와 라이브 사이트의 스크린샷을 포함해 문의하세요.

1. 즉각적인 위험을 통제하세요. 릴리스가 민감한 데이터를 노출하거나 안전하지 않은 동작을 만든 경우 App Status를 열고, 해당되는 Atoms 클라우드 앱에서는 Pause를 사용하거나 Unpublish를 사용해 공개 접근을 제거하세요. 현재 위험이 없다면 불필요한 중단을 일으키지 마세요.
2. 영향을 받는 도메인, 게시 시간, 현재 버전, 의도한 버전, 비즈니스 영향을 기록하세요.
3. 현재 에이전트 작업이 중지된 후 Versions를 열고 마지막으로 정상 작동했던 버전을 선택한 다음 Restore this version을 선택하세요.
4. Preview에서 복원된 버전을 확인하고 중요한 로그인, 결제, 데이터 흐름을 포함해 검증한 후 Publish 또는 Update하세요.

프로젝트 버전을 복원해도 프로덕션 데이터베이스 변경이나 외부 작업이 되돌려지지 않을 수 있습니다. 롤백을 흉내 내기 위해 프로덕션 데이터를 덮어쓰거나 삭제하지 마세요. 데이터, 자격 증명, 결제 또는 파괴적 변경이 관련된 경우 즉시 Support에 문의하세요.

1. 현재 에이전트 작업을 중지하거나 완료될 때까지 기다리세요. 충돌하는 작업이 활성 상태이면 버전을 복원할 수 없습니다.
2. Versions를 열고 마지막으로 정상 작동했던 버전을 찾은 다음 Restore this version을 선택하세요.
3. Preview에서 복원된 프로젝트를 검토하고 변경된 중요한 흐름을 테스트하세요.
4. Preview 결과가 올바른 경우에만 Publish 또는 Update하세요.

프로젝트 버전 복원은 프로덕션 데이터베이스 레코드, 스키마 변경, 환경 변수, 결제, 이메일 또는 기타 외부 작업을 반드시 롤백하지는 않습니다. 릴리스가 프로덕션 데이터를 변경했거나 대상 버전을 사용할 수 없다면 중단하고 두 버전 번호, 영향을 받는 도메인, 필요한 데이터 보존 결과를 포함해 Support에 문의하세요.

Pause와 Unpublish는 서로 다른 두 가지 작업입니다:

Pause(Atoms 클라우드 프로젝트만 해당):

- 앱을 방문자가 사용할 수 없게 됩니다.

- 서버 리소스는 계속 할당된 상태이며 과금도 계속됩니다.

- App Status에서 언제든지 앱을 재개할 수 있습니다.

Unpublish(모든 프로젝트):

- 웹사이트가 완전히 오프라인 상태가 됩니다. 게시된 URL을 사용하는 사람은 접근할 수 없게 됩니다.

- Atoms 클라우드 프로젝트의 경우 서버 리소스가 해제됩니다.

- 나중에 프로젝트를 다시 게시할 수 있지만, 그전까지 방문자는 접근할 수 없습니다.

빠르게 다시 시작할 수 있는 일시적인 중단에는 Pause를 사용하세요. 사이트를 완전히 제거하려면 Unpublish를 사용하세요.

브라우저에 "too many redirects"가 표시되거나 콘텐츠가 표시되지 않은 채 페이지가 계속 새로고침되는 경우:

1. 플랫폼의 기본 Prod 서브도메인(사용자 지정 도메인 아님)을 시도해 리디렉션 루프의 원인이 도메인 구성인지 애플리케이션 자체인지 확인하세요.
2. 기본 Prod 서브도메인이 작동한다면 사용자 지정 도메인의 DNS 설정과 도메인 등록기관의 리디렉션 규칙이 플랫폼과 충돌하지 않는지 확인하세요.
3. 브라우저 캐시를 지우거나 시크릿 창에서 테스트해 캐시된 리디렉션 가능성을 배제하세요.

문제가 계속되면 Support에 문의하고 다음을 포함하세요:

- 리디렉션 루프가 발생하는 전체 URL

- 기본 Prod 서브도메인에 접근 가능한지 여부

- 도메인 이름과 DNS 제공업체

- 전체 오류 스크린샷

앱이 Preview에서는 작동하지만 누락되었거나 비어 있는 환경 변수 때문에 프로덕션에서 실패하는 경우:

1. 환경 변수가 마지막 게시 전과 후 중 언제 저장되었는지 확인하세요. 게시 후에 저장되었다면 변경 사항이 적용되도록 다시 게시해야 합니다.
2. 변수가 올바른 환경(Development 또는 Production)에 설정되어 있는지 확인하세요.
3. 하위 서비스의 오류 메시지가 단서를 주는지 확인하세요. 예를 들어 "unauthorized"는 해당 환경에서 API 키가 비어 있거나 잘못되었음을 의미하는 경우가 많습니다.

문제가 계속되면 Support에 문의하고 다음을 포함하세요:

- 프로젝트 링크 또는 라이브 URL

- 영향을 받는 키 이름과 문제가 있는 환경

- 하위 서비스의 전체 오류

- 민감 정보를 제거한 구성 페이지 스크린샷

- 구성이 게시 전 또는 후에 저장되었는지 여부

중요: 키 이름만 제공하세요. 비밀 값, 비밀번호 또는 토큰은 보내지 마세요.

결과는 서로 다른 위치를 가리키면서 비슷한 표현을 사용할 수 있습니다. 표현이 비슷하다고 해서 반드시 중복 결과라는 뜻은 아닙니다.

1. 각 결과의 결과 이름과 표시된 위치를 비교하세요.
2. 반복되는 표현만 보고 넘기지 말고 고유한 각 위치를 모두 검토하세요.
3. 여러 결과의 근본 원인이 같다면 그 원인을 수정한 후 각 위치를 다시 확인하세요.
4. 업데이트된 버전에서 보안 스캔을 다시 실행하세요.

같은 결과와 위치가 여전히 두 번 이상 표시되면 Atoms Support에 Chat Link, 스캔 시간과 시간대, 결과 수, 민감 정보를 가린 스크린샷을 포함해 문의하세요. 결과에 표시될 수 있는 비밀번호, 키, 토큰 또는 기타 민감한 정보는 제거하세요.

보고된 결과 없이 스캔이 완료되었다면 유용한 점검이지만, 모든 보안 또는 런타임 문제가 발견되었다고 보장할 수는 없습니다. 스캔은 선택한 프로젝트 버전을 검사하므로 앱은 실제 사용자가 사용하는 방식으로 여전히 테스트해야 합니다.

게시 전에 로그인, 사용자 역할, 비공개 데이터 접근, 결제, 연결된 서비스를 포함해 앱의 중요한 사용자 여정을 테스트하세요. 역할별로 별도의 테스트 계정을 사용하고 각 계정이 의도된 정보와 작업에만 접근할 수 있는지 확인하세요.

계정, 비공개 데이터, 결제 또는 자격 증명이 노출될 수 있는 프로덕션 문제를 발견했다면 먼저 해당 기능의 사용을 중지하거나 접근을 제한하세요. 노출되었을 수 있는 자격 증명은 교체한 다음 Atoms Support에 Chat Link, 영향을 받는 버전, 문제 재현 단계, 시간과 시간대, 민감 정보를 가린 스크린샷을 포함해 문의하세요. 노출된 자격 증명 자체는 공유하지 마세요.

스캔에서 관리자 전용 작업이 보호되지 않았을 수 있다고 보고하면, 권한 없는 사용자가 해당 작업을 사용할 수 없다는 것을 확인할 때까지 해결되지 않은 결과로 취급하세요. 관리자 버튼을 숨기는 것만으로는 해당 작업을 다른 방식으로 요청할 수 있다면 충분하지 않습니다.

1. 결과를 열고 거기에 명시된 작업 또는 위치를 확인하세요.
2. 로그인한 어떤 역할이 해당 작업을 사용할 수 있어야 하는지 결정하세요.
3. 버튼이 표시될 때만이 아니라 작업이 요청될 때 사용자의 권한을 확인하도록 에이전트에게 요청하세요.
4. 로그아웃 상태, 일반 테스트 계정, 권한이 있는 관리자 테스트 계정으로 각각 작업을 테스트하세요.
5. 거부된 시도가 비공개 데이터를 노출하지 않고 변경도 일으키지 않는지 확인한 다음 보안 스캔을 다시 실행하세요.

권한 없는 계정이 여전히 해당 작업을 사용할 수 있다면 영향을 받는 기능을 게시하지 마세요. 해결할 수 없다면 Atoms Support에 Chat Link, 결과 텍스트, 영향을 받는 버전, 민감 정보를 가린 스크린샷을 포함해 문의하세요.

HTTPS는 사용자와 서비스 사이를 오가는 정보를 보호합니다. 스캔에서 HTTPS 문제를 보고하면 정확한 결과 내용을 사용해 영향을 받는 주소, 리소스, 콜백 또는 도메인 구성을 식별하세요.

1. 결과를 열고 보고된 정확한 위치와 주소를 기록하세요.
2. 해당 제공업체가 지원하는 보안 주소로 그 특정 연결을 교체하거나 관련 도메인 구성을 수정하도록 에이전트에게 요청하세요.
3. 외부 서비스가 보안 대체 주소를 문서화하지 않았다면 인증서 경고를 무시하거나 주소를 임의로 변경하지 마세요.
4. 영향을 받는 사용자 여정을 다시 테스트하고 비밀번호, 토큰, 결제 정보 또는 비공개 정보가 안전하지 않은 연결을 통해 전송되지 않는지 확인하세요.
5. 업데이트된 버전에서 보안 스캔을 다시 실행하세요.

결과가 수정할 수 없는 사용자 지정 도메인 또는 인증서와 관련되어 있다면 Atoms Support에 Chat Link, 영향을 받는 URL, 결과 텍스트, 시간과 시간대, 민감 정보를 가린 스크린샷을 포함해 문의하세요.

Row Level Security 또는 RLS는 각 사용자가 어떤 데이터베이스 행을 읽거나 변경할 수 있는지 제어하는 Supabase 기능입니다. 이 결과는 프로젝트가 Supabase를 사용하고 있으며 스캔에서 접근 규칙 검토가 필요한 테이블을 식별한 경우에만 관련이 있습니다.

1. 결과를 열고 거기에 명시된 테이블을 확인하세요.
2. 누가 해당 테이블의 데이터를 조회, 추가, 편집 또는 삭제할 수 있어야 하는지 적어 두세요.
3. 그 사용자 여정을 지원하는 최소 권한의 Supabase 정책을 만들도록 에이전트에게 요청하세요.
4. 로그아웃 상태와 역할별 별도 테스트 계정으로 테스트하세요. 각 계정이 의도된 행과 작업에만 접근할 수 있는지 확인하세요.
5. 정책이 적용된 후 보안 스캔을 다시 실행하세요.

경고를 없애기 위해 RLS를 비활성화하거나 모든 사용자에게 허용하지 마세요. 기존 데이터에 영향을 줄 수 있는 변경을 하기 전에 계획을 확인하고, 적절한 경우 안전한 백업 또는 내보내기를 유지하세요. Chat이나 스크린샷에 Supabase 키 또는 데이터베이스 자격 증명을 절대 공유하지 마세요.