가장 쉬운 실수는 Rivya API와 Rivya Studio를 서로 경쟁하는 경로처럼 보는 것입니다.

둘은 같은 제품의 두 단계로 이해하는 편이 더 좋습니다. Studio는 사람이 탐색하고, 선택하고, 검토하고, 시각적으로 작업을 이어 가는 곳입니다. API는 안정된 워크플로가 다른 제품, 스크립트 또는 백엔드 프로세스의 일부가 되는 곳입니다.

아직 API 범위를 배우는 중이라면 Rivya API란 무엇인가?부터 읽으세요. 이 페이지는 더 좁습니다. 특정 작업이 Studio에 속하는지 API에 속하는지 결정하는 방법을 다룹니다.

한 표로 보는 결정

질문	Studio를 쓸 때	API를 쓸 때
출력이 아직 탐색 중인가?	예	아니요, 워크플로가 이미 반복 가능함
사람이 결과를 비교해야 하는가?	예	앱이 결과를 받은 뒤에만 비교하면 됨
모델 선택이 안정적인가?	아직 아님	예, 또는 API 모델 목록에서 선택 가능
작업에 참조 미디어가 필요한가?	사람이 아직 준비 중임	앱이 Files API로 업로드할 수 있음
결과가 다른 시스템을 업데이트해야 하는가?	아직 아님	예, 폴링 또는 webhooks로
크레딧 사용량이 보여야 하는가?	예, 테스트 중 특히 필요	예, 하지만 계정 수준 API 컨트롤로 처리

이것은 어느 작업 영역이 더 고급인지의 문제가 아닙니다. 작업이 자동화될 준비가 되었는지의 문제입니다.

작업이 아직 변하고 있다면 Studio 사용하기

사람의 판단이 아직 핵심 작업이라면 Studio가 맞는 장소입니다.

포함되는 경우:

image, video, audio 또는 chat 모델 사이에서 선택
프롬프트 방향을 유지할 가치가 있는지 테스트
시각 결과를 나란히 비교
참조 미디어가 도움이 되는지 방해되는지 결정
저장된 기록에서 이전 결과를 이어가기

창의적 작업에서는 특히 그렇습니다. 브리프가 안정되지 않았다면 요청을 자동화해도 혼란이 줄어들기보다 더 빨라지는 경우가 많습니다.

워크플로가 반복 가능하다면 API 사용하기

입력과 다음 단계가 충분히 예측 가능할 때 API가 더 나은 경로가 됩니다.

좋은 신호:

제품이 이미 필요한 모델 또는 모델 카테고리를 알고 있음
사용자 입력을 안정적인 요청 본문으로 매핑할 수 있음
백엔드 작업이 사람이 화면을 보지 않아도 상태를 폴링할 수 있음
작업이 끝났을 때 webhook이 올바른 레코드를 업데이트할 수 있음
앱이 팀 또는 계정 소유자에게 크레딧 사용량을 설명할 수 있음

이 시점에서는 매번 Studio를 사용하는 것이 더 느린 경로가 될 수 있습니다. API는 제품이 작업을 직접 시작하게 해 줍니다.

실용적 경계: 발견과 통합

발견에는 Studio를 사용하세요.

통합에는 API를 사용하세요.

발견은 다음을 뜻합니다.

"어떤 모델을 써야 하지?"
"어떤 프롬프트 형태가 작동하지?"
"참조 미디어가 이 작업을 개선하나?"
"이 사용 사례에 충분한 출력 품질인가?"

통합은 다음을 뜻합니다.

"이 사용자 행동은 생성 작업 하나를 만들어야 한다."
"이 작업은 멱등하게 재시도되어야 한다."
"이 파일은 업로드된 뒤 모델 요청에 첨부되어야 한다."
"완료된 작업은 우리 제품 레코드를 업데이트해야 한다."

이 경계는 API가 숨은 실험 작업 영역이 되는 일을 막아 줍니다.

크레딧이 결정에 미치는 영향

Studio와 API 사용은 모두 같은 Rivya 계정 크레딧에서 차감됩니다.

따라서 크레딧 동작은 나중에 붙이는 설명이 아니라 제품 설계의 일부여야 합니다.

팀이 아직 비용 형태를 배우는 중이라면 Studio를 먼저 사용하세요. 크레딧이 언제 예약되거나 소비되는지 제품이 설명할 수 있을 만큼 작업이 안정되면 API를 사용하세요.

현재 공개 규칙은 API Credits를 읽으세요. 계정 소유자에게 설명하기 어려울 만큼 비싼 워크플로라면 아직 API 자동화 준비가 되지 않은 것입니다.

파일이 선택을 바꾸는 곳

참조 미디어는 통합이 더 진지해지는 지점인 경우가 많습니다.

Studio에서는 사람이 업로드하고, 확인하고, 재시도하고, 파일이 충분히 좋은지 결정할 수 있습니다. API에서는 제품이 Files API를 통해 파일 경로를 의도적으로 다루어야 합니다.

Studio를 사용할 때:

참조 이미지, 영상 또는 오디오에 아직 사람의 정리가 필요함
팀이 어떤 참조가 모델을 안내해야 할지 확신하지 못함
파일 규칙이 아직 사용자에게 명확하지 않음

API를 사용할 때:

앱이 파일을 안전하게 수집할 수 있음
모델의 참조 요구 사항을 알고 있음
생성 또는 chat 요청 전에 파일을 업로드할 수 있음
오류를 숨기지 않고 자체 제품에서 보여 줄 수 있음

Files API는 유용한 다리지만, 파일 경험을 설계해야 하는 필요를 없애지는 않습니다.

Chat이 선택을 바꾸는 곳

Chat은 양쪽 모두에 속할 수 있습니다.

사람이 탐색, 작성, 검토 또는 결정 중이라면 Rivya Chat을 직접 사용하세요.

채팅 턴이 자체 제품 또는 서버 워크플로 안에 있어야 한다면 Chat API를 사용하세요. 여기에는 비스트리밍 턴, 선택적 SSE 스트리밍, API가 만든 세션, 지원되는 파일 첨부가 포함될 수 있습니다.

핵심 질문은 대화가 어디에서 살아야 하는가입니다. 대화가 Rivya 작업의 일부라면 Rivya를 사용하세요. 대화가 제품 경험의 일부라면 API를 사용하세요.

Webhook이 신호가 되는 때

워크플로에 API Webhooks가 필요하다면 보통 수동 Studio 단계를 지난 상태입니다.

Webhooks는 다른 시스템이 완료된 생성 작업에 반응해야 할 때 유용합니다.

자산을 준비 완료로 표시
사용자에게 알림
검토 단계를 앞으로 이동
실패한 작업을 지원 또는 재시도 로직으로 이동

이것은 통합 작업입니다. Studio는 여전히 모델 경로 테스트에 유용할 수 있지만, 프로덕션 루프는 API에 속합니다.

안전한 마이그레이션 패턴

전체 워크플로를 한 번에 API로 옮기지 마세요.

이 순서를 사용하세요.

Studio에서 작업을 수동으로 테스트합니다.
안정된 모델, 프롬프트 형태, 입력 파일, 예상 결과를 적습니다.
API Models와 모델 레퍼런스를 읽습니다.
API Quickstart로 생성 하나를 제출합니다.
모델에 참조 미디어가 필요할 때만 Files API를 추가합니다.
폴링이 작동한 뒤에만 Webhooks를 추가합니다.
제품에 Studio 밖의 채팅 턴이 필요할 때만 Chat API를 추가합니다.

각 단계는 워크플로를 단순히 더 자동화하는 것이 아니라 더 운영하기 쉽게 만들어야 합니다.

Studio에 머물러야 할 때

작업에 아직 다음이 필요하다면 Studio에 머무르세요.

주관적 검토
프롬프트 다듬기
시각 비교
모델 탐색
저장된 창의적 기록
사람이 다음 단계가 image, video, audio 또는 chat인지 결정

이것은 약점이 아닙니다. Studio는 그 단계를 위해 설계되었습니다.

API로 옮겨야 할 때

다음 경우에는 API로 이동하세요.

같은 작업이 자주 반복됨
입력을 구조화할 수 있음
모델을 알고 있음
앱이 자체 UI에서 작업을 만들어야 함
상태, 오류, 크레딧을 명확히 처리할 수 있음
폴링 또는 webhooks가 제품 백엔드에 맞음

API가 가장 강한 순간은 이미 이해된 Rivya 워크플로를 신뢰할 수 있는 제품 동작으로 바꿀 때입니다.

Rivya에서 다음 단계

API 범위를 미리 보려면 Developers를 사용하세요.
production 코드를 쓰기 전에 Rivya API Quickstart를 읽으세요.
API key를 저장하기 전에 API Authentication을 읽으세요.
다음 질문이 모델, 파일, chat, webhooks를 연결하는 방법이라면 Rivya API로 멀티모달 AI 워크플로 구축하기를 읽으세요.
프로젝트가 아직 사람이 주도하는 Studio 작업에 속한다면 Rivya Chat, Image, Video, Audio 사이에서 작업 옮기기를 사용하세요.

Studio 대신 Rivya API를 써야 하는 경우