작동 방식

MasterOS는 control plane(제어 플레인: auth, 조직, billing/ledger, model catalog, admin)과 execution plane(실행 플레인: chat, model gateway, retrieval, 그리고 — 이후에는 — agent/workflow runtime)을 분리합니다. 오늘은 두 plane이 하나의 API 서비스 안에서 함께 동작하지만, 이런 분리 덕분에 보안과 확장의 경계가 깔끔하게 유지됩니다.

채팅 메시지 보내기

1. 서버는 사용자 조직의 활성 플랜을 확인하고, 요청된 모델 등급이 허용 목록에 있는지 검사합니다 — 이는 서버 측에서 강제되며, UI에서만 숨겨져 있는 것이 아닙니다.
2. 메시지가 기존 대화를 이어가는 경우, 다른 어떤 일이 일어나기 전에 소유권(ownership)이 먼저 확인됩니다 — 유효하지 않거나 다른 사용자의 conversation id는 quota가 건드려지기 전에 거부됩니다.
3. 모든 채팅 request와 함께 전송되는 idempotency key가 예약(reserve)됩니다. 동일한 key로 재시도된 request는 절대 다시 청구되거나 model provider를 다시 호출하지 않습니다. 진행 중인 중복 request는 즉시 거부됩니다.
4. 모델이 호출되기 전에 예상 비용이 일일 quota bucket에 **예약(reserve)**됩니다.
5. 사용자의 메시지가 저장되고, 모델은 토큰 단위로 답변을 스트리밍하며, 답변은 실제 토큰 수 및 비용과 함께 저장됩니다 — 이 모든 과정은 하나의 원자적(atomic) database transaction으로 이루어지므로, crash가 발생해도 청구된 메시지에 대응하는 ledger entry가 없는 상태(또는 그 반대)가 절대 발생하지 않습니다.
6. quota 예약은 실제 비용으로 **정산(settle)**되며(실제로 청구된 것이 없다면 전액 해제됩니다), ledger는 동일한 금액만큼 차감됩니다.

Billing은 ledger — 대변/차변 entry의 연속 — 이며, 직접 차감되는 단일 잔액 숫자가 절대 아닙니다. 이 덕분에 도중에 실패한 request, 환불, 또는 사용자에게 정확히 무엇이 청구되었는지 정산(reconciling)하는 것에 대해 올바르게 추론할 수 있습니다.

파일 업로드하기

Upload → validate type/size → malware scan → store → extract text → available for citation in chat

malware 검사나 텍스트 추출에 실패한 파일은 실패로 표시되며 chat에서 사용할 수 없습니다. 권한 필터링(어떤 파일을 볼 수 있는지)은 어떤 내용이든 모델에 도달하기 전에 이루어집니다 — 이는 단순한 검색 필터가 아니라 보안 경계입니다.