Programmatic ON · Console OFF · API Key 자체관리 OFF · 이메일 미입력
고객사용
API 호출 전용 (org당 1개)
{고객사명} 예: custA
{고객사명} 예: custA
Programmatic ON · Console OFF · API Key 자체관리 OFF · 이메일 미입력
네이밍 규칙 요약: Project 이름과 IAM User 이름은 {고객사명}으로 동일하게 설정합니다. 예: 고객사 A → Project custA, IAM User custA
01
사전 준비물
시작 전 확인
항목
설명
서브 관리자 계정 정보
ModelArk 콘솔 접근 권한 (Console + Programmatic 둘 다 가능한 IAM 서브 관리자)
org 계약 정보
회사명, 요금제(Basic/Standard/Premium), 계약 기간, 계약금액
고객사 식별 코드
Project / IAM User 이름으로 사용할 영문 코드 (예: custA) — 네이밍 규칙: {고객사명}, Project와 IAM User 이름이 동일하게 설정됨
사용 예정 모델 목록
해당 org가 사용할 모델 (예: Seedance 2.0, Seedream 등) — Endpoint를 모델별로 만들어야 하므로 사전 확정 필요
계약 Concurrency 기준값
요금제별 동시 처리(Concurrency) 수치 — Endpoint Rate Limit 설정에 사용
02
Project 생성
org 1개당 1회
org 전용 작업 공간을 만드는 단계입니다. 이후 모든 자원(API Key, Endpoint, IAM User)이 이 Project 안에 소속됩니다.
ModelArk 콘솔 서브 관리자 계정으로 로그인 Console → Projects
"Create Project" 클릭
Project 이름 입력 — 네이밍 규칙: {고객사명} (예: custA)
생성 완료 후 Project ID를 기록 (플랫폼 등록 시 필요)
네이밍 규칙: Project 이름은 {고객사명} 그대로 사용합니다. 이후 생성하는 IAM User 이름과 동일하게 맞춰 Project ↔ IAM User를 한눈에 대응할 수 있도록 합니다.
03
고객사용 IAM User 생성
Programmatic Only · 콘솔 차단
고객사별 IAM User를 생성합니다. 고객사가 ModelArk 콘솔에 직접 접근하지 못하도록 Access Method를 엄격하게 제한해야 합니다.
IAM 메뉴로 이동 Console → IAM → Users → Create User
사용자 이름 입력 — 네이밍 규칙: {고객사명} (예: custA) — Project 이름과 동일하게
이메일 입력하지 않음 — 이메일을 넣으면 콘솔 가입/초대 경로가 열리므로 반드시 공란 유지
아래 Access Method 기준에 따라 설정
생성 완료
Access Method 설정 기준
Console Access
OFF
콘솔 로그인 원천 차단 — 고객사가 ModelArk 콘솔에 직접 접근하는 것을 막는 핵심 설정
API Key 자체관리
OFF
AccessKeySelfManageAccess 정책 미부여 — 고객사가 AK/SK를 임의로 생성하거나 삭제하지 못하도록 차단
Programmatic Access
ON
API(AK/SK) 호출만 허용 — 플랫폼 백엔드가 사용량 조회 등 관리 API를 호출하기 위해 필요
보안 원칙: 이메일 미입력 + Console OFF + API Key 자체관리 OFF — 이 세 가지가 모두 충족되어야 고객사의 콘솔 접근 경로가 완전히 차단됩니다. 하나라도 빠지면 의도치 않은 접근이 발생할 수 있습니다.
04
IAM User 권한 부여
Global + Project 세트
고객사용 IAM User에게는 반드시 "Global 권한 1개 + Project 권한 1개" 세트로 부여합니다. Project 권한은 해당 고객사의 Project만 스코핑해야 합니다.
Global 권한
1개 부여
IAM 기본 인증 및 공통 리소스 접근을 위한 최소 권한 원칙 적용 모든 고객사 IAM User에게 공통으로 부여되는 기본 권한 세트
Project 권한
해당 Project만 스코핑
해당 고객사의 Project에만 한정된 접근 권한 부여 다른 고객사 Project에 대한 Cross-project 접근은 반드시 금지
Cross-project 접근 금지: Project 권한의 스코핑이 잘못 설정되면 고객사 A의 IAM User가 고객사 B의 사용량이나 자원에 접근할 수 있습니다. 권한 부여 후 반드시 해당 IAM User 권한 현황을 재확인하세요.
05
Project별 API Key 발급
inference 호출용
org가 실제 이미지/영상 생성을 요청할 때 사용되는 키입니다. Project 단위로 발급하며, Endpoint와 공유됩니다.
방금 생성한 Project로 진입 Project → API Keys
"Create API Key" 클릭
발급된 키 값을 즉시 안전한 곳에 복사 (재조회 불가능한 경우가 많으므로 발급 즉시 보관)
플랫폼 등록 항목으로 표시: provider_api_key
참고: API Key는 Project 안의 모든 Endpoint가 공유하여 사용합니다 — Endpoint마다 별도의 API Key가 필요한 것은 아닙니다.
06
모델별 Endpoint 생성
모델 1개당 1개
org가 사용할 모델마다 Endpoint를 하나씩 만들어야 합니다. 예를 들어 Seedance 2.0과 Seedream을 둘 다 사용하는 org라면 Endpoint도 2개 필요합니다.
Project 내 Endpoint 메뉴로 이동 Project → Endpoints → Create Endpoint
사용할 모델 선택 (예: Seedance-2.0, Seedream 등)
Endpoint 이름 입력 (예: org-{고객사코드}-seedance2)
생성 완료 후 Endpoint ID를 모델별로 각각 기록
사용 모델 수만큼 반복
07
Endpoint Rate Limit (Concurrency) 설정
요금제별 필수
Endpoint를 생성하면 Rate Limit이 기본적으로 Unset 상태입니다 — 그대로 두면 제한 없이 호출되므로, 계약된 요금제 기준의 동시 처리(Concurrency)로 반드시 제한을 걸어야 합니다.
방금 만든 Endpoint의 Basic information 화면으로 진입
"Endpoint rate limit" 항목에서 edit 클릭 (기본값 Unset)
아래 요금제별 기준값으로 Concurrent tasks(동시 작업 수)를 입력
모델별 Endpoint가 여러 개라면 Endpoint마다 동일하게 반복 설정
요금제
계약금액
Concurrent tasks
Basic
3,000만원
(계약 기준값 입력)
Standard
5,000만원
(계약 기준값 입력)
Premium
1억원
(계약 기준값 입력)
주의: 정확한 Concurrency 수치는 계약 조건에 따라 확정되어야 합니다. 계약서 또는 영업 담당자에게 확정값을 받아 위 표를 채운 뒤 진행하세요.
참고: 이 값은 BytePlus 측에서 강제하는 1차 제한(Endpoint rate limit)입니다. 플랫폼 내부의 org별 동시성 제어(2차 제한)와 별도이며, 더 낮은 쪽이 실제 한도가 됩니다 — 둘을 같은 기준으로 맞춰두는 것을 권장합니다.
08
IAM User AK/SK 발급
사용량 조회·관리용
앞서 생성한 IAM User(Programmatic Only)에서 AK/SK를 발급합니다. 이 키는 플랫폼 백엔드가 사용량 조회(GetUsage) 등 관리 API를 호출하는 데 사용합니다.
방금 생성한 고객사용 IAM User로 이동 Console → IAM → Users → {해당 IAM User}
"Access Keys" 탭 → "Create Access Key" 클릭
Access Key(AK) / Secret Key(SK) 발급
SK는 발급 즉시 1회만 노출되는 경우가 많으므로 바로 안전하게 보관
발급된 AK/SK는 플랫폼에 등록하거나 비밀번호 관리 도구를 통해 전달
보안 주의: AK/SK와 API Key는 절대 평문으로 메일/메신저에 남기지 않습니다. 플랫폼에 바로 등록하거나 비밀번호 관리 도구를 통해 전달하세요. AK/SK는 서브 관리자만 생성·폐기할 수 있으며, 유출 의심 시 즉시 폐기 후 재발급합니다.
09
Split Bill (비용 분리) 확인
정산 정확도 핵심
여러 org가 같은 Owner 계정을 공유하기 때문에, org별 실제 사용 비용을 분리해서 추적해야 합니다. Split Bill은 Owner 계정에서 기능을 1회 활성화하면 이후 발생하는 사용량부터 자동으로 분리 집계됩니다. Project를 개별 등록하는 방식이 아닙니다.
Billing 메뉴로 이동 Console → Billing → Split Bills
Split Bill이 비활성화 상태라면 Enable(활성화) — Owner 계정에서 1회만 설정
활성화 이후 발생한 사용량부터 split item 단위로 자동 분리 집계됨
신규 org의 Endpoint가 정상 집계되는지 첫 사용량 발생 후 확인
반드시 사전 활성화: Split Bill은 활성화 이후 발생한 소비분만 조회 가능합니다. 활성화 전 사용량은 소급 적용되지 않으므로, org 온보딩 및 Endpoint 생성 전에 반드시 활성화 여부를 확인하세요.
이미 활성화된 경우: Owner 계정에서 Split Bill이 이미 Enable 상태라면 신규 org 추가 시 별도 작업 없이 자동 반영됩니다. 활성화 상태만 확인하면 됩니다.
10
운영 기준
상시 준수
IAM User 및 AK/SK에 대한 일상 운영 정책입니다. 서브 관리자가 상시 준수해야 합니다.
🔑 AK/SK 관리
서브 관리자만 생성 및 폐기 가능
유출 의심 시 즉시 폐기 후 재발급
발급 이력은 관리 대장에 기록
📋 정기 점검 (월 1회)
IAM User 목록 및 권한 현황 점검
미사용 AK/SK 식별 및 정리
권한 과다 부여 여부 확인
Onboarding 순서
계약 체결→Project 생성→IAM User 생성→권한 부여→Endpoint/API Key 설정→플랫폼 연동
Offboarding 순서
AK/SK 비활성화→API Key 폐기→Endpoint 삭제→IAM User 비활성화→Project 보존
Offboarding 주의: IAM User와 Project는 물리 삭제하지 않습니다 — 비활성화 후 보존하여 감사(audit) 추적이 가능하도록 유지합니다.
11
발급 정보 정리 및 플랫폼 등록 전달
운영팀 전달
아래 표를 채워서 플랫폼 운영팀에 전달하면, 플랫폼에 org 자격증명으로 등록됩니다.
항목
값
org 식별 코드
Project ID / 이름
IAM User 이름
API Key
Endpoint ID (모델별로 각각)
Endpoint Concurrency 설정값
AK
SK
Split Bill 활성화 확인
활성화됨 / 미확인
12
완료 체크리스트
Project가 org 네이밍 규칙에 맞게 생성되었는가
IAM User가 Programmatic Only로 생성되었는가 (Console OFF, 이메일 미입력, API Key 자체관리 OFF)
IAM User 권한이 Global 1개 + 해당 Project 스코핑 권한 1개로 부여되었는가 (Cross-project 접근 없는지 확인)
API Key가 발급되어 안전하게 보관되었는가
사용할 모델 수만큼 Endpoint가 모두 생성되었는가
모든 Endpoint의 Rate Limit(Concurrency)이 계약 요금제 기준으로 설정되었는가 (Unset 상태로 남아있지 않은가)
IAM User에서 AK/SK가 발급되어 안전하게 보관되었는가
Split Bill(비용 분리)이 Owner 계정에서 활성화(Activate)되어 있는가 — 신규 org Endpoint의 split 집계 여부 확인