가장 쉬운 실수는 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이 올바른 레코드를 업데이트할 수 있음
앱이 팀 또는 계정 소유자에게 크레딧 사용량을 설명할 수 있음
