> ## Documentation Index > Fetch the complete documentation index at: https://wb-21fd5541-update-reference-docs-40.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Bring your own bucket(BYOB) > Bring your own bucket(BYOB) 기능을 사용해 자체 클라우드 저장소 버킷에 W&B 아티팩트와 데이터를 저장하세요. **이 가이드는 모든 W\&B 배포 유형에 적용됩니다.** * **Multi-tenant Cloud**: 팀 수준 BYOB * **Dedicated Cloud**: 인스턴스 및 팀 수준 BYOB * **Self-Managed**: 인스턴스 및 팀 수준 BYOB 이 가이드의 버킷 프로비저닝 지침은 배포 유형과 관계없이 동일합니다.
## 개요
Bring your own bucket (BYOB)를 사용하면 W\&B 아티팩트와 기타 민감한 데이터를 자체 클라우드 또는 온프레미스 인프라에 저장할 수 있습니다. [Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud) 또는 [Multi-tenant Cloud](/ko/platform/hosting/hosting-options/multi_tenant_cloud)의 경우, W\&B는 고객 버킷에 저장된 데이터를 W\&B 관리 인프라로 복사하지 않습니다. 이 페이지는 데이터 거버넌스, 데이터 레지던시 또는 규정 준수 요구 사항을 충족하기 위해 아티팩트 저장소에 대한 소유권을 유지해야 하는 W\&B 관리자와 플랫폼 엔지니어를 위한 것입니다. * W\&B SDK / CLI / UI와 고객 버킷 간의 통신은 [사전 서명된 URL](./presigned-urls)을 사용해 이루어집니다. * W\&B는 가비지 컬렉션 및 관련 프로세스를 사용하여 시간이 지나면서 고객 버킷에서 삭제된 **아티팩트**와 **run 데이터**를 제거합니다. 아티팩트 삭제에 대해서는 [Delete an artifact](/ko/models/artifacts/delete-artifacts)를 참조하세요. Dedicated Cloud 및 Self-Managed 배포에서 삭제된 run 데이터는 [Configure environment variables](/ko/platform/hosting/env-vars)에 설명된 `GORILLA_DATA_RETENTION_PERIOD` 설정의 영향도 받습니다. W\&B는 정리 시점을 보장하지 않습니다. 버킷 사용량과 비용을 한곳에서 확인하려면 [Manage bucket storage and costs](/ko/platform/hosting/managing-bucket-storage)를 참조하세요. * 버킷을 구성할 때 하위 경로를 지정하면 W\&B가 버킷 루트 폴더에 파일을 저장하지 않도록 할 수 있습니다. 이렇게 하면 조직의 버킷 거버넌스 정책을 더 잘 준수할 수 있습니다.
### 중앙 데이터베이스와 버킷에 저장되는 데이터
BYOB 기능을 사용하면 W\&B는 일부 데이터 유형은 W\&B 중앙 데이터베이스에 저장하고, 다른 데이터 유형은 사용자의 버킷에 저장합니다. 어떤 데이터가 W\&B 관리 인프라에 남고 어떤 데이터를 W\&B가 사용자의 자체 저장소에 기록하는지 확인하려면 다음 목록을 참조하세요.
#### 데이터베이스
W\&B 중앙 데이터베이스에는 다음 데이터가 저장됩니다: * Users, Teams, 아티팩트, 실험, 프로젝트의 메타데이터. * Reports. * 실험 로그. * 시스템 메트릭. * 콘솔 로그.
#### 버킷
저장소 버킷에는 다음 데이터가 저장됩니다: * 실험 파일 및 메트릭. * Artifact 파일. * 미디어 파일. * run 파일. * Parquet 형식으로 내보낸 이력 메트릭과 시스템 이벤트.
### 버킷 범위
저장소 버킷은 두 가지 범위 중 하나로 구성할 수 있습니다. | 범위 | 설명 | | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 인스턴스 수준 | [Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud) 및 [Self-Managed](/ko/platform/hosting/hosting-options/self-managed)에서는 조직 또는 인스턴스 내에서 필요한 권한을 가진 모든 사용자가 인스턴스의 저장소 버킷에 저장된 파일에 액세스할 수 있습니다. [Multi-tenant Cloud](/ko/platform/hosting/hosting-options/multi_tenant_cloud)에는 적용되지 않습니다. | | 팀 수준 | W\&B 팀이 팀 수준 저장소 버킷을 사용하도록 구성된 경우, 팀 구성원은 해당 버킷에 저장된 파일에 액세스할 수 있습니다. 팀 수준 저장소 버킷은 민감한 데이터를 다루거나 엄격한 규정 준수 요구 사항이 있는 팀에 더 강력한 데이터 액세스 제어와 데이터 격리를 제공합니다.

팀 수준 저장소는 하나의 인스턴스를 공유하는 여러 사업부나 부서가 인프라와 관리 리소스를 효율적으로 활용하도록 도와줍니다. 또한 서로 다른 프로젝트 팀이 개별 고객 업무를 위한 AI 워크플로를 관리할 수 있게 해줍니다. 모든 deployment 유형에서 사용할 수 있습니다. 팀을 설정할 때 팀 수준 BYOB를 구성합니다. | 이 설계는 조직의 요구 사항에 따라 다양한 저장소 토폴로지를 지원합니다. 예를 들면 다음과 같습니다. * 동일한 버킷을 인스턴스와 하나 이상의 팀에 사용할 수 있습니다. * 각 팀은 별도의 버킷을 사용할 수 있고, 일부 팀은 인스턴스 버킷에 쓰도록 선택할 수 있으며, 여러 팀이 하위 경로에 기록해 하나의 버킷을 공유할 수도 있습니다. * 서로 다른 팀의 버킷은 서로 다른 클라우드 인프라 환경이나 리전에 위치할 수 있으며, 서로 다른 저장소 관리자 팀이 이를 관리할 수도 있습니다. 예를 들어, 조직에 Kappa라는 팀이 있다고 가정해 보겠습니다. 조직(및 팀 Kappa)은 기본적으로 인스턴스 수준 저장소 버킷을 사용합니다. 다음으로 Omega라는 팀을 생성합니다. 팀 Omega를 생성할 때 해당 팀에 팀 수준 저장소 버킷을 구성합니다. 팀 Kappa는 팀 Omega가 생성한 파일에 액세스할 수 없습니다. 그러나 팀 Omega는 팀 Kappa가 생성한 파일에 액세스할 수 있습니다. 팀 Kappa의 데이터를 격리하려면 해당 팀에도 팀 수준 저장소 버킷을 구성해야 합니다.
### 가용성 매트릭스
시작하기 전에 사용 중인 배포 유형과 저장소 공급자에서 BYOB를 사용할 수 있는지 확인하세요. W\&B는 다음 저장소 제공업체에 연결할 수 있습니다: * [CoreWeave AI Object Storage](https://docs.coreweave.com/products/storage/object-storage): AI 워크로드에 최적화된 고성능 S3 호환 객체 저장소 서비스입니다. * [Amazon S3](https://aws.amazon.com/s3/): 업계 최고 수준의 확장성, 데이터 가용성, 보안, 성능을 제공하는 객체 저장소 서비스입니다. * [Google Cloud Storage](https://cloud.google.com/storage): 비정형 데이터를 대규모로 저장할 수 있는 관리형 서비스입니다. * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs): 텍스트, 바이너리 데이터, 이미지, 비디오, 로그 등 대량의 비정형 데이터를 저장하기 위한 클라우드 기반 객체 저장소 솔루션입니다. * [MinIO Enterprise (AIStor)](https://min.io/product/aistor)와 같은 S3 호환 저장소 또는 클라우드나 온프레미스 인프라에서 호스팅되는 기타 엔터프라이즈급 솔루션. 다음 표는 각 W\&B deployment type에서 각 범위별 BYOB 가용성을 보여줍니다. | W\&B deployment type | 인스턴스 수준 | 팀 수준 | Additional information | | -------------------- | ------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Dedicated Cloud | ✓ | ✓ | 인스턴스 수준 및 팀 수준 BYOB는 클라우드나 온프레미스 인프라에서 호스팅되는 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, 그리고 [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor)와 같은 S3 호환 저장소에서 지원됩니다. | | Multi-tenant Cloud | 해당 없음 | ✓1 | 팀 수준 BYOB는 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage에서 지원됩니다. | | Self-Managed | ✓ | ✓ | 인스턴스 수준 및 팀 수준 BYOB는 클라우드나 온프레미스 인프라에서 호스팅되는 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, 그리고 [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor)와 같은 S3 호환 저장소에서 지원됩니다. | 1.Multi-tenant Cloud에서는 팀 수준 BYOB에 Azure Blob Storage가 지원되지 않습니다. 다음 섹션에서는 BYOB 설정 방법을 안내합니다.
## 버킷 프로비저닝
[가용성 확인](#availability-matrix)을 마치면 액세스 정책과 CORS를 포함한 저장소 버킷을 프로비저닝할 수 있습니다. 프로비저닝을 수행하면 W\&B가 기록할 버킷이 생성되고, W\&B 플랫폼이 사용자를 대신해 사전 서명된 URL을 생성하는 데 필요한 권한이 부여됩니다. 계속하려면 탭을 선택하세요. **요구 사항**: * **Multi-tenant Cloud**, 또는 * **Dedicated Cloud** v0.73.0 이상 또는 * **Self-Managed** v0.73.0 이상, Helm chart v0.33.14+로 배포된 경우 * AI Object Storage가 활성화되어 있고 버킷, API 액세스 키, 시크릿 키를 생성할 권한이 있는 CoreWeave 계정. * W\&B 인스턴스는 CoreWeave 네트워크 엔드포인트에 연결 가능해야 합니다. 자세한 내용은 CoreWeave 문서의 [Create a CoreWeave AI Object Storage bucket](https://docs.coreweave.com/docs/products/storage/object-storage/buckets/create-bucket)을 참조하세요. 1. **Multi-tenant Cloud**: 버킷 정책에 필요한 조직 ID를 획득하세요. 1. [W\&B App](https://wandb.ai/site)에 로그인합니다. 2. 왼쪽 내비게이션에서 **새 팀 만들기**를 클릭합니다. 3. 열리는 드로어에서 **팀 구성원 초대** 위에 있는 W\&B 조직 ID를 복사합니다. 4. 이 페이지는 열린 상태로 둡니다. 이 페이지를 사용해 [W\&B를 구성](#configure-byob)합니다. 2. **Dedicated Cloud** / **Self-Managed**: 버킷 정책에 필요하므로 고객 네임스페이스를 획득하세요. 1. W\&B App에서 사용자 프로필 아이콘을 클릭한 후 **System Console**을 클릭합니다. 2. **Authentication** 탭을 클릭합니다. 3. 페이지 하단에서 **Customer Namespace** 값을 복사합니다. 이 값은 버킷 정책을 구성할 때 필요하므로 보관해 두세요. 4. System Console을 닫아도 됩니다. 3. CoreWeave에서 원하는 CoreWeave 가용 영역에 원하는 이름으로 버킷을 생성합니다. 필요에 따라 모든 W\&B 파일의 하위 경로로 사용할 폴더를 W\&B용으로 생성할 수 있습니다. 버킷 이름, 가용 영역, API 액세스 키, 시크릿 키, 하위 경로를 기록해 둡니다. 4. 버킷에 다음 CORS(Cross-Origin Resource Sharing) 정책을 설정합니다: ```json theme={null} [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "HEAD", "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "ETag" ], "MaxAgeSeconds": 3000 } ] ``` CoreWeave 저장소는 S3 호환입니다. CORS에 대한 자세한 내용은 AWS 문서의 [교차 출처 리소스 공유(CORS) 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html)을 참조하세요. 5. W\&B 배포 환경이 버킷에 액세스하고, 클라우드 인프라의 AI 워크로드 또는 사용자 브라우저가 버킷에 액세스하는 데 사용하는 [사전 서명된 URL](./presigned-urls)을 생성하는 데 필요한 권한을 부여하는 버킷 정책을 구성하세요. 자세한 내용은 CoreWeave 문서의 [Bucket Policy Reference](https://docs.coreweave.com/docs/products/storage/object-storage/auth-access/bucket-access/bucket-policies)를 참고하세요. ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowWandbUser", "Action": [ "s3:GetObject*", "s3:GetEncryptionConfiguration", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObject", "s3:GetBucketCORS", "s3:GetBucketLocation", "s3:GetBucketVersioning" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::/*", "arn:aws:s3:::" ], "Principal": { "CW": "arn:aws:iam::wandb:static/" }, "Condition": { "StringLike": { "wandb:OrgID": [ "" ] } } }, { "Sid": "AllowUsersInOrg", "Action": "s3:*", "Effect": "Allow", "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::/*" ], "Principal": { "CW": "arn:aws:iam:::*" } }] } ``` `"Sid": "AllowUsersInOrg"`로 시작하는 절은 조직의 사용자에게 버킷에 직접 액세스할 수 있는 권한을 부여합니다. 이 권한이 필요하지 않다면 정책에서 해당 절을 생략할 수 있습니다. 6. 버킷 정책에서 플레이스홀더를 바꾸세요: * ``: 버킷 이름입니다. * ``: * **Multi-tenant Cloud**: `arn:aws:iam::wandb:static/wandb-integration-public` * **Dedicated Cloud** 또는 **Self-Managed**: `arn:aws:iam::wandb:static/wandb-integration` * ``: * **Multi-tenant Cloud**: [Provision your bucket](#coreweave-org-id)에서 확인한 조직 ID입니다. * **Dedicated Cloud** 또는 **Self-Managed**: [Provision your bucket](#coreweave-customer-namespace)에서 확인한 고객 네임스페이스입니다. 7. **Dedicated Cloud**: 추가 step을 마치려면 [지원팀](mailto:support@wandb.ai)에 문의하세요. 8. **Self-Managed**: W\&B 배포를 업데이트하여 환경 변수 `GORILLA_SUPPORTED_FILE_STORES`를 정확히 `cw://`로 설정한 후 W\&B를 다시 시작하세요. 그렇지 않으면 팀 저장소를 설정할 때 CoreWeave가 옵션으로 표시되지 않습니다. 다음으로, [W\&B를 설정](#configure-byob)합니다. 자세한 내용은 AWS 문서의 [S3 버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)을 참조하세요. 1. KMS 키를 생성합니다. W\&B를 사용하려면 S3 버킷의 데이터를 암호화 및 복호화할 KMS 키를 프로비저닝해야 합니다. 키 사용 유형은 `ENCRYPT_DECRYPT`여야 합니다. 키에 다음 정책을 할당하세요: ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid" : "Internal", "Effect" : "Allow", "Principal" : { "AWS" : "" }, "Action" : "kms:*", "Resource" : "" }, { "Sid" : "External", "Effect" : "Allow", "Principal" : { "AWS" : "" }, "Action" : [ "kms:Decrypt", "kms:Describe*", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*" ], "Resource" : "" } ] } ``` `` 및 ``을 해당 값으로 바꾸세요. [Multi-tenant Cloud](/ko/platform/hosting/hosting-options#w%26b-multi-tenant-cloud) 또는 [Dedicated Cloud](/ko/platform/hosting/hosting-options#w%26b-dedicated-cloud)를 사용하는 경우 ``을 해당 값으로 바꾸세요: * **Multi-tenant Cloud**: `arn:aws:iam::725579432336:role/WandbIntegration` * **Dedicated Cloud**: `arn:aws:iam::830241207209:root` 이 정책은 AWS 계정에 키에 대한 전체 액세스 권한을 부여하고, W\&B 플랫폼을 호스팅하는 AWS 계정에도 필요한 권한을 부여합니다. KMS 키 ARN을 기록해 두세요. 2. S3 버킷을 생성하세요. AWS 계정에서 S3 버킷을 프로비저닝하려면 다음 단계에 따라 진행하세요: 1. 원하는 이름으로 S3 버킷을 생성합니다. 필요하면 폴더를 만들어 모든 W\&B 파일을 저장할 하위 경로로 설정할 수 있습니다. 2. 이전 단계의 KMS 키를 사용해 서버 측 암호화를 활성화합니다. 3. 다음 정책으로 CORS를 설정합니다. ```json theme={null} [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "HEAD", "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "ETag" ], "MaxAgeSeconds": 3000 } ] ``` 버킷의 데이터가 [객체 수명 주기 관리 정책](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)으로 인해 만료되면 일부 run의 이력을 조회하지 못할 수 있습니다. 4. W\&B platform을 호스팅하는 AWS 계정에 필요한 S3 권한을 부여합니다. 이 권한은 클라우드 인프라의 AI 워크로드나 사용자 브라우저가 버킷에 액세스할 때 사용하는 [사전 서명된 URL](./presigned-urls)을 생성하는 데 필요합니다. ```json theme={null} { "Version": "2012-10-17", "Id": "WandBAccess", "Statement": [ { "Sid": "WAndBAccountAccess", "Effect": "Allow", "Principal": { "AWS": "" }, "Action" : [ "s3:GetObject*", "s3:GetEncryptionConfiguration", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObject", "s3:GetBucketCORS", "s3:GetBucketLocation", "s3:GetBucketVersioning" ], "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::/*" ] } ] } ``` ``을 알맞게 바꾸고 버킷 이름을 기록해 두세요. 다음으로, [W\&B를 설정합니다](#configure-byob). [Multi-tenant Cloud](/ko/platform/hosting/hosting-options/multi_tenant_cloud) 또는 [Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud)를 사용하는 경우 ``을 해당 값으로 바꾸세요. * [Multi-tenant Cloud](/ko/platform/hosting/hosting-options/multi_tenant_cloud)의 경우: `arn:aws:iam::725579432336:role/WandbIntegration` * [Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud)의 경우: `arn:aws:iam::830241207209:root` 자세한 내용은 [AWS Self-Managed 호스팅 가이드](/ko/platform/hosting/hosting-options)를 참조하세요. 자세한 내용은 Google Cloud 문서의 [버킷 만들기](https://docs.cloud.google.com/storage/docs/creating-buckets)를 참조하세요. 1. GCS 버킷을 프로비저닝합니다. Google Cloud 프로젝트에서 GCS 버킷을 프로비저닝하려면 다음 단계를 따르세요. 1. 원하는 이름으로 GCS 버킷을 생성합니다. 필요에 따라 모든 W\&B 파일을 저장할 하위 경로로 사용할 폴더를 생성할 수도 있습니다. 2. 암호화 유형을 `Google-managed`로 설정합니다. 3. 소프트 삭제를 켭니다. [버킷의 소프트 삭제 정책 수정](https://docs.cloud.google.com/storage/docs/use-soft-delete)을 참조하세요. 4. `gsutil`로 CORS 정책을 설정합니다. 이는 UI에서는 할 수 없습니다. 1. 로컬에 `cors-policy.json` 파일을 생성합니다. 2. 다음 CORS 정책을 파일에 복사한 후 저장합니다. ```json theme={null} [ { "origin": ["*"], "responseHeader": ["Content-Type"], "exposeHeaders": ["ETag"], "method": ["GET", "HEAD", "PUT"], "maxAgeSeconds": 3000 } ] ``` 버킷의 데이터가 [객체 수명 주기 관리 정책](https://cloud.google.com/storage/docs/lifecycle)에 따라 만료되면 일부 run의 이력을 조회하지 못할 수 있습니다. 5. ``을 올바른 버킷 이름으로 바꾼 후 `gsutil`을 실행합니다. ```bash theme={null} gsutil cors set cors-policy.json gs:// ``` 6. 버킷의 정책을 확인합니다. ``을 올바른 버킷 이름으로 바꿉니다. ```bash theme={null} gsutil cors get gs:// ``` 2. [Multi-tenant Cloud](/ko/platform/hosting/hosting-options/multi_tenant_cloud) 또는 [Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud)를 사용하는 경우, W\&B Platform에 연결된 Google Cloud 서비스 계정에 `storage.admin` 역할을 부여합니다. W\&B는 버킷의 CORS 설정과 객체 버전 관리 활성화 여부 등의 속성을 확인하기 위해 이 역할이 필요합니다. 서비스 계정에 `storage.admin` 역할이 없으면 이러한 확인 과정에서 HTTP 403 오류가 발생합니다. * [Multi-tenant Cloud](/ko/platform/hosting/hosting-options/multi_tenant_cloud)의 계정은 다음과 같습니다: `wandb-integration@wandb-production.iam.gserviceaccount.com` * [Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud)의 계정은 다음과 같습니다: `deploy@wandb-production.iam.gserviceaccount.com` 버킷 이름을 기록해 두세요. 다음으로 [BYOB용 W\&B를 설정하세요](#configure-byob). 자세한 내용은 Azure 설명서의 [blob storage 컨테이너 만들기](https://learn.microsoft.com/en-us/azure/storage/blobs/blob-containers-portal)를 참조하세요. **Instance level BYOB**: 1. Azure Blob Storage 컨테이너를 프로비저닝합니다. Self-Managed 배포와 [이 Terraform module](https://github.com/wandb/terraform-azurerm-wandb/tree/main/examples/byob)을 사용하지 않는 Dedicated Cloud 배포의 경우, 다음 단계에 따라 Azure 구독에 Azure Blob Storage 컨테이너를 프로비저닝하세요. 1. 원하는 이름으로 컨테이너를 생성합니다. 필요하면 모든 W\&B 파일을 저장하는 하위 경로로 설정할 폴더를 만들 수도 있습니다. 2. 컨테이너에 CORS 정책을 구성합니다. UI에서 CORS 정책을 설정하려면 blob storage로 이동한 다음 아래로 스크롤하여 `Settings/Resource Sharing (CORS)`로 이동하고, 다음과 같이 설정하세요. | 매개변수 | 값 | | ------ | -------------------- | | 허용된 원본 | `*` | | 허용된 방법 | `GET`, `HEAD`, `PUT` | | 허용된 헤더 | `*` | | 노출된 헤더 | `*` | | 최대 기간 | `3000` | [객체 lifecycle 관리 정책](https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-policy-configure?tabs=azure-portal)으로 인해 버킷의 데이터가 만료되면 일부 run의 이력을 조회하지 못할 수 있습니다. 2. 저장소 계정 액세스 키를 생성하고, 해당 키 이름과 저장소 계정 이름을 기록해 두세요. [Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud)를 사용하는 경우에는 안전한 공유 메커니즘을 사용해 저장소 계정 이름과 액세스 키를 W\&B 팀과 공유하세요. **Team level BYOB**: Dedicated Cloud 배포의 경우, W\&B는 필요한 액세스 메커니즘과 권한을 갖춘 Azure Blob Storage 컨테이너를 프로비저닝하기 위해 [Terraform](https://github.com/wandb/terraform-azurerm-wandb/tree/main/examples/secure-storage-connector)을 사용할 것을 권장합니다. Terraform을 사용하지 않는 Dedicated Cloud 배포 또는 Self-Managed 배포의 경우에는 인스턴스 수준 저장소 프로비저닝 단계에 따라 버킷을 프로비저닝하세요. 인스턴스의 OIDC issuer URL을 제공하세요. 다음 세부 정보를 기록해 두세요. * 저장소 계정 이름 * 저장소 컨테이너 이름 * 관리형 ID 클라이언트 ID * Azure 테넌트 ID S3 호환 버킷을 생성하세요. 다음 항목을 기록해 두세요. * 액세스 키 * 시크릿 액세스 키 * URL 엔드포인트 * 버킷 이름 * 해당하는 경우 폴더 경로 * 리전 다음으로 [저장소 주소를 확인하세요](#determine-the-storage-address).
## 저장소 주소 확인
버킷을 프로비저닝한 후에는 W\&B가 해당 버킷을 찾고 인증하는 데 사용할 저장소 주소가 필요합니다. 이 섹션에서는 W\&B Team을 BYOB 저장소 버킷에 연결할 때 사용하는 구문을 설명합니다. 예시에서는 꺾쇠괄호(`<>`) 안의 자리 표시자 값을 버킷 세부 정보로 바꾸세요. 자세한 지침은 탭을 선택해 확인하세요. 이 섹션은 **Dedicated Cloud** 또는 **Self-Managed**의 팀 수준 BYOB에만 해당합니다. instance level BYOB 또는 Multi-tenant Cloud의 경우 [W\&B 구성](#configure-byob)으로 바로 진행하면 됩니다. 다음 형식에 따라 전체 버킷 경로를 확인합니다. 꺾쇠괄호(`<>`) 안의 자리 표시자를 버킷 값으로 바꾸세요. **Bucket 형식**: ```text theme={null} cw://:@cwobject.com/?tls=true ``` `cwobject.com` HTTPS 엔드포인트를 지원합니다. TLS 1.3이 필요합니다. 다른 CoreWeave 엔드포인트에 관심이 있다면 [지원팀](mailto:support@wandb.com)에 문의하세요. **Bucket 형식**: ```text theme={null} s3://:@/?region= ``` 주소에서 `region` 매개변수는 W\&B 인스턴스와 저장소 버킷이 모두 AWS에 배포되어 있고, W\&B 인스턴스의 `AWS_REGION`이 버킷의 AWS S3 리전과 일치하는 경우를 제외하면 필수입니다. **Bucket 형식**: ```text theme={null} gs://:@ ``` **Bucket 형식**: ```text theme={null} az://:@/ ``` **Bucket 형식**: ```text theme={null} s3://:@/?region=&tls=true ``` 주소에서 `region` 매개변수는 필수입니다. 이 섹션은 [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor) 또는 온프레미스에서 호스팅되는 기타 엔터프라이즈급 S3 호환 솔루션처럼, S3에 호스팅되지 않은 S3 호환 저장소 버킷에 해당합니다. AWS S3에 호스팅된 저장소 버킷은 대신 **AWS** 탭을 참조하세요. MinIO Open Source는 활성 개발이나 사전 컴파일된 바이너리 제공 없이 [maintenance mode](https://github.com/minio/minio) 상태입니다. 프로덕션 배포에는 엔터프라이즈급 S3 호환 솔루션을 사용하세요. 선택적 S3 호환 모드를 제공하는 클라우드 네이티브 저장소 버킷은 가능하면 클라우드 네이티브 프로토콜 지정자를 사용하세요. 예를 들어 CoreWeave 버킷에는 `s3://` 대신 `cw://`를 사용하세요. 저장소 주소를 확인했다면 이제 [팀 수준 BYOB 구성](#configure-team-level-byob)으로 진행할 수 있습니다.
## W\&B 설정
[버킷을 프로비저닝](#provision-your-bucket)하고 [저장소 주소를 확인](#determine-the-storage-address)한 후에는 [인스턴스 수준](#instance-level-byob) 또는 [팀 수준](#team-level-byob)에서 BYOB를 설정할 수 있습니다. 이 마지막 단계에서는 아티팩트, run 파일, 기타 대용량 객체의 저장소가 사용자의 버킷으로 라우팅되도록 W\&B에 지정합니다. 저장소 버킷 레이아웃은 신중하게 계획하세요. W\&B에서 저장소 버킷을 설정한 후에는 해당 데이터를 다른 버킷으로 마이그레이션하는 작업이 복잡하며 W\&B의 도움이 필요합니다. 이는 Dedicated Cloud 및 Self-Managed의 저장소뿐 아니라 Multi-tenant Cloud의 팀 수준 저장소에도 적용됩니다. 문의 사항이 있으면 [지원팀](mailto:support@wandb.com)에 문의하세요.
### 인스턴스 수준 BYOB
인스턴스 수준 CoreWeave AI Object Storage의 경우, 이 안내를 따르지 말고 [W\&B 지원팀](mailto:support@wandb.com)에 문의하세요. 셀프서비스 설정은 아직 지원되지 않습니다. **Dedicated Cloud**의 경우: 버킷 세부 정보를 담당 W\&B 팀에 공유하면 담당 팀에서 Dedicated Cloud 인스턴스를 설정합니다. **Self-Managed**의 경우, W\&B App을 사용해 인스턴스 수준 BYOB를 설정할 수 있습니다: 1. `admin` 역할이 있는 사용자로 W\&B에 로그인합니다. 2. 상단의 사용자 아이콘을 클릭한 다음 **System Console**을 클릭합니다. 3. **Settings** > **System Connections**로 이동합니다. 4. **Bucket Storage** 섹션에서 **Identity** 필드의 ID에 새 버킷에 대한 액세스 권한이 부여되어 있는지 확인합니다. 5. **공급자**를 선택합니다. 6. **Bucket Name**을 입력합니다. 7. 필요에 따라 새 버킷에서 사용할 **Path**를 입력합니다. 8. **Save**를 클릭합니다. 저장한 후에는 W\&B가 인스턴스 수준에서 새 아티팩트와 run 파일의 기본 저장소 대상으로 설정된 버킷을 사용합니다.
### 팀 수준 BYOB
W\&B App에서 팀을 만들 때 또는 [SCIM API](/ko/platform/hosting/iam/scim#create-team)(선택적 `storageBucket`이 포함된 POST Groups)를 사용할 때 팀 수준 BYOB를 설정할 수 있습니다. 옵션은 두 가지입니다. * **기존 버킷 사용**: 먼저 버킷의 [저장소 위치를 확인](#determine-the-storage-address)해야 합니다. * **새 버킷 생성**(Multi-tenant Cloud 전용): 팀을 만들 때 W\&B가 클라우드 공급자에 버킷을 자동으로 생성할 수 있습니다. W\&B는 CoreWeave, AWS, Google Cloud에서 이를 지원합니다. - 팀을 생성한 후에는 저장소를 변경할 수 없습니다. - 인스턴스 수준 BYOB는 [Instance level BYOB](#instance-level-byob)를 참고하세요. - 팀에 CoreWeave 저장소를 설정할 계획이라면 [CoreWeave requirements](#coreweave-requirements)를 검토하고, [지원팀](mailto:support@wandb.com)에 문의해 CoreWeave에서 버킷이 올바르게 설정되었는지와 팀 설정이 유효한지를 확인하세요. 팀을 생성한 후에는 저장소 세부 정보를 변경할 수 없습니다. 계속하려면 배포 유형을 선택하세요. 1. **Dedicated Cloud**: 팀에서 저장소 버킷을 사용하려면, 아래 나머지 단계를 진행하기 전에 버킷 경로를 담당 account team에 **반드시** 제공하여 인스턴스의 지원 파일 저장소에 추가하도록 해야 합니다. 2. **Self-Managed**: 팀에서 저장소 버킷을 사용하려면, 아래 나머지 단계를 진행하기 전에 버킷 경로를 `GORILLA_SUPPORTED_FILE_STORES` 환경 변수에 **반드시** 추가한 다음 W\&B를 재시작해야 합니다. 3. `admin` 역할이 있는 사용자로 W\&B에 로그인한 다음, 왼쪽 상단의 아이콘을 클릭해 왼쪽 내비게이션을 열고 **협업할 팀 만들기**를 클릭합니다. 4. 팀 이름을 입력합니다. 5. **Storage Type**을 **External storage**로 설정합니다. 팀 저장소로 인스턴스 수준 저장소를 사용하려면(내부/외부 여부와 관계없이), 인스턴스 수준 버킷이 BYOB로 설정되어 있더라도 **Storage Type**은 **Internal**로 그대로 두세요. 팀에 별도의 외부 저장소를 사용하려면 팀의 **Storage Type**을 **External**로 설정하고 다음 단계에서 버킷 세부 정보를 구성하세요. 6. **Bucket location**을 클릭합니다. 7. 기존 버킷을 사용하려면 목록에서 선택합니다. 새 버킷을 추가하려면 하단의 **Add bucket**을 클릭한 다음 버킷 세부 정보를 입력합니다. **Cloud 공급자**를 클릭하고 **CoreWeave**, **AWS**, **Google Cloud**, 또는 **Azure**를 선택합니다. 클라우드 제공업체가 목록에 없으면 [Provision your bucket](#set-environment-variable)의 안내에 따라 인스턴스의 지원 파일 저장소에 버킷 경로를 추가했는지 확인하세요. 저장소 제공업체가 여전히 표시되지 않으면 [지원팀에 문의](mailto:support@wandb.ai)하세요. 8. 버킷 세부 정보를 지정합니다. * **CoreWeave**의 경우 버킷 이름만 입력합니다. * Amazon S3, Google Cloud 또는 S3 호환 저장소의 경우 [앞서 확인한](#determine-the-storage-address) 전체 버킷 경로를 입력합니다. * W\&B Dedicated 또는 Self-Managed의 Azure에서는 **Account name**을 Azure 계정으로, **Container name**을 Azure blob storage 컨테이너로 설정합니다. * 필요에 따라 추가 연결 설정을 입력합니다. * 해당하는 경우 **Path**를 버킷 하위 경로로 설정합니다. * **CoreWeave**: 추가 연결 설정이 필요하지 않습니다. * **AWS**: **KMS key ARN**을 KMS 암호화 키의 ARN으로 설정합니다. * **Google Cloud**: 추가 연결 설정이 필요하지 않습니다. * **Azure**: **Tenant ID**와 **Managed Identity Client ID** 값을 지정합니다. `GORILLA_SUPPORTED_FILE_STORES`로 연결 문자열을 구성하지 않았다면 이 필드는 필수입니다. 9. **Create team**을 클릭합니다. W\&B가 버킷에 액세스하는 중 오류가 발생하거나 잘못된 설정을 감지하면 페이지 하단에 오류 또는 경고가 표시됩니다. 그렇지 않으면 W\&B가 팀을 생성합니다. 1. 이전에 새 팀 생성을 시작하면서 W\&B 조직 ID를 확인했던 브라우저 창으로 전환합니다. 해당 창이 없다면, `admin` 역할이 있는 사용자로 W\&B에 로그인한 다음 왼쪽 상단의 아이콘을 클릭해 왼쪽 내비게이션을 열고 **협업할 팀 만들기**를 클릭합니다. 2. 팀 이름을 입력합니다. 3. **Storage Type**을 **External storage**로 설정합니다. 4. **Bucket location**을 클릭합니다. 5. 기존 버킷을 사용하려면 목록에서 선택합니다. 6. 새 버킷을 만들려면 하단의 **Add bucket**을 클릭한 다음 다음을 수행합니다. 1. **Cloud 공급자**를 클릭하고 **CoreWeave**, **AWS**, 또는 **Google Cloud**를 선택합니다. 2. 버킷 세부 정보를 입력합니다. * **Name**: 버킷 이름을 입력합니다. * **Path** (선택): 버킷 내에서 사용할 하위 경로를 입력합니다. 3. 선택한 클라우드 제공업체에 대한 추가 연결 설정을 입력합니다. * CoreWeave: 추가 설정이 필요하지 않습니다. * AWS: 필요에 따라 암호화를 위한 **KMS key ARN**을 입력합니다. * Google Cloud: 추가 설정이 필요하지 않습니다. **Create team**을 클릭하면 W\&B가 지정한 설정으로 클라우드 제공업체에 버킷을 자동으로 생성합니다. 7. 팀에 구성원을 초대합니다. **Invite team members**에 쉼표로 구분된 이메일 주소 목록을 입력합니다. 또는 팀이 생성된 후에 구성원을 초대할 수도 있습니다. 8. **Create team**을 클릭합니다. W\&B가 버킷에 액세스하는 중 오류가 발생하거나 잘못된 설정을 감지하면 페이지 하단에 오류 또는 경고가 표시됩니다. 그렇지 않으면 W\&B가 팀을 생성합니다.
## 문제 해결
W\&B에서 버킷을 검증하거나 연결하는 중 오류가 발생하는 경우, 다음 섹션을 참고하여 저장소 공급자별로 가장 일반적인 원인을 진단하세요.
### CoreWeave
이 섹션은 CoreWeave AI Object Storage에 연결할 때 발생하는 문제를 해결하는 데 도움이 됩니다. * **연결 오류** * W\&B 인스턴스가 CoreWeave 네트워크 엔드포인트에 연결할 수 있는지 확인하세요. * CoreWeave는 버킷 이름이 경로 시작 부분의 서브도메인으로 들어가는 virtual-hosted 스타일 경로를 사용합니다. 예를 들어 `cw://bucket-name.cwobject.com`은 올바르지만 `cw://cwobject.com/bucket-name/`은 올바르지 않습니다. * 버킷 이름에는 밑줄(`_`)이나 DNS 규칙과 호환되지 않는 다른 문자가 포함되면 안 됩니다. * 버킷 이름은 CoreWeave의 모든 위치에서 전역적으로 고유해야 합니다. * 버킷 이름은 예약된 접두사인 `cw-` 또는 `vip-`로 시작하면 안 됩니다. * **CORS 검증 실패** * CORS 정책이 필요합니다. CoreWeave는 S3 호환입니다. CORS에 대한 자세한 내용은 AWS 문서의 [교차 출처 리소스 공유(CORS) 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html)을 참조하세요. * `AllowedMethods`에는 `GET`, `PUT`, `HEAD`가 포함되어야 합니다. * `ExposeHeaders`에는 `ETag`가 포함되어야 합니다. * CORS 정책의 `AllowedOrigins`에는 W\&B 프런트엔드 도메인이 포함되어야 합니다. 이 페이지에 제공된 예시 CORS 정책은 `*`를 사용해 모든 도메인을 포함합니다. * **LOTA 엔드포인트 문제** * W\&B는 아직 LOTA 엔드포인트 연결을 지원하지 않습니다. 관심이 있으시면 [지원팀에 문의하세요](mailto:support@wandb.com). * **액세스 키 및 권한 오류** * CoreWeave API 액세스 키가 만료되지 않았는지 확인하세요. * CoreWeave API 액세스 키와 시크릿 키에 `GetObject`, `PutObject`, `DeleteObject`, `ListBucket` 권한이 충분한지 확인하세요. 이 페이지의 예시는 이 요구 사항을 충족합니다. 자세한 내용은 CoreWeave 문서의 [액세스 키 생성 및 관리](https://docs.coreweave.com/docs/products/storage/object-storage/auth-access/manage-access-keys/about)를 참조하세요.
### Google Cloud
이 섹션은 Google Cloud Storage 연결 문제를 해결하는 데 도움이 됩니다. * `Bucket does not have soft deletion enabled` Google Cloud Storage 버킷에서 소프트 삭제가 활성화되어 있는지 확인하세요. [버킷의 소프트 삭제 정책 수정](https://docs.cloud.google.com/storage/docs/use-soft-delete)을 참조하세요.