LLM 통합¶

AI Studio — 현재 사용 가능한 기능¶

Studio 에디터에 내장된 AI 어시스턴트는 다음 기능을 제공합니다:

기능	설명
자연어 전략 생성	매매 아이디어를 말로 설명하면 실행 가능한 DSL 코드 생성
코드 자동 적용	생성된 코드를 에디터에 바로 반영 (한 번 클릭)
AI 백테스트 루프	백테스트 실행 → 결과 분석 → 개선 제안 → 재검증 반복
차트 오버레이 적용	전략의 매매 시점과 지표를 차트에 시각화
코드 설명 및 수정	기존 전략에 대한 질문, 파라미터 수정, 기능 추가

처음 사용한다면

AI 어시스턴트 사용법에서 단계별 안내를 확인하세요.

출시 예정: AI 어드바이저¶

전략 스크립트에서 AI에 직접 질의하여 매매 판단을 보조하는 기능을 준비 중입니다.

adviser.session() — AI 세션 생성 (쿨다운, 프로바이더 선택)
ai.advice() — 시장 데이터를 전달하고 매수/매도/관망 의견 수신
ai.ask() — 자유 형식 질의

현재는 에디터의 LLM Studio(AI 어시스턴트 채팅)를 통해 전략 작성을 지원받을 수 있습니다.

ChatGPT GPTs 체험과 runtime AI의 차이¶

cloud landing/docs surface에는 필요 시 ChatGPT GPTs 체험 링크가 함께 노출될 수 있습니다. 이 표면은 설치 전에 전략 아이디어를 설명해 보고, 제한된 DSL 초안/대화 흐름을 먼저 체험해 보는 용도입니다.

혼동하면 안 되는 기준:

ChatGPT GPTs 체험은 아이디어 정리, 설명 보조, 제한된 초안 생성에 초점을 둡니다.
runtime AI는 Studio editor/apply, chart apply, backtest loop, runtime entitlement 같은 runtime-coupled 기능과 함께 동작합니다.
따라서 landing/help에서 GPTs 체험을 보더라도, 실제 전략 검증과 적용은 runtime Studio가 canonical path입니다.
cloud의 GPTs 체험 진입 surface는 anonymous 또는 FREE 사용자에게 더 눈에 띄게 노출될 수 있고, BASIC/PRO 사용자는 도움말/비교 문맥에서 보조적으로 보게 되는 구성이 자연스럽습니다.

capability boundary를 더 직접적으로 보면:

capability	ChatGPT GPTs 체험	runtime AI
일반 상담 / 아이디어 정리	가능	가능
제한형 DSL 초안	가능	가능
editor apply / chart apply	불가	가능
runtime backtest / optimization loop	불가	가능
구독/세션 기반 privileged action	불가	명시적 사용자 확인 하에서만 가능

즉 GPTs 체험은 "runtime 미연동 / 백테스트 불가 / 적용 불가" 표면으로 이해하면 됩니다. 반대로 runtime AI는 Studio와 연결된 canonical path이며, 검증과 적용은 여기서만 수행합니다.

운영 관점에서도 둘은 같은 prompt 자산을 공유하지 않습니다. runtime Studio prompt는 cloud relay 내부 canonical 자산이고, GPTs 체험용 prompt/knowledge/starter prompt는 별도 asset pack으로 관리합니다.

현재 canonical 경로¶

현재 runtime LLM 기능의 canonical owner는 quantiq-cloud relay 입니다.

runtime과 브라우저는 외부 LLM provider API key를 직접 저장하지 않습니다.
authenticated runtime session은 cloud의 POST /api/runtime/llm/chat relay 경로로만 LLM 요청을 보냅니다.
Studio system prompt/profile은 cloud relay 내부에서만 canonical하게 관리되고, runtime은 이를 별도 fetch/cache 하지 않습니다.
cloud는 server-side OpenAI 설정을 사용해 upstream 호출을 수행합니다.
cloud subscription entitlement snapshot이 runtime LLM plan gate의 canonical source이며, 현재 Studio LLM은 BASIC 이상에서만 허용됩니다.
relay가 unavailable, timeout, auth failure 상태이면 runtime은 local direct provider로 자동 우회하지 않고 명시적 오류(fail-closed) 를 반환합니다.
Studio LLM 패널은 local provider selector를 canonical UX로 두지 않고, cloud relay 단일 경로를 기준으로 동작합니다.
cloud relay 응답이 한 번에 도착하더라도 runtime/browser는 기존 SSE transcript, option_list quick action, editor/chart apply 흐름을 유지하도록 적응시킵니다.

현재 Studio 응답 형식 계약도 cloud relay prompt 안에서 함께 관리합니다. 따라서 사용자가 실제로 보게 되는 기본 형식은 다음을 기대하면 됩니다.

일반 설명과 진행 안내는 한글 중심의 Markdown 응답으로 옵니다.
코드 제안은 가능한 한 ```dsl fenced block 안에 정리됩니다.
설명/예시는 DSL 코드블록 대신 일반 텍스트나 다른 fenced block을 사용합니다.
선택지가 필요한 경우 응답 마지막에 [llm option] 섹션과 llm_option(...) 형식이 붙어, Studio quick action UI가 이를 읽어 버튼으로 바꿉니다.

중요:

runtime 사용자 표면은 더 이상 local provider 등록, direct provider CRUD, legacy direct chat/generate 경로를 노출하지 않습니다.
설계 기준과 운영 기준은 cloud relay 단일 경로를 canonical path로 봅니다.

Cloud relay 설정¶

runtime과 브라우저가 직접 외부 LLM provider key를 들고 호출하지 않도록, cloud는 server-side relay 경로에서 OpenAI API key를 읽을 수 있어야 합니다.

Spring 설정 키: llm.openai.api-key
선택 모델 설정 키: llm.openai.chat-model
OpenAI connect timeout 설정 키: llm.openai.connect-timeout-sec
OpenAI read timeout 설정 키: llm.openai.read-timeout-sec
기본 env 바인딩: OPENAI_API_KEY
timeout env 바인딩: OPENAI_CONNECT_TIMEOUT_SEC, OPENAI_READ_TIMEOUT_SEC
이 값은 quantiq-cloud 서버 환경에서만 읽고, 브라우저나 로컬 runtime client bundle에는 넣지 않습니다.
예제 env 파일에는 placeholder만 두고, 실제 secret은 .env.dev, .env.prod 같은 실제 환경 파일 또는 배포 secret store에만 둡니다.
현재 기본값은 connect 10초, read 90초입니다. 일반 CRUD HTTP client와 달리 LLM relay는 응답 생성 시간이 길 수 있으므로 별도 timeout을 사용합니다.
timeout 오류가 반복되면 provider/network 상태를 먼저 점검하고, 실제 prompt 길이나 응답 길이가 긴 운영 환경에서는 read timeout을 조정할 수 있습니다.

Relay contract 개요¶

고급 사용자나 통합 관점에서 보면 runtime↔cloud LLM 경계는 다음 contract를 기준으로 동작합니다.

request 최소 필드: surface, conversationId, messages[], runtimeVersion
messages[*] 필드: role, content
허용 role: system, user, assistant
response 최소 필드: requestId, surface, conversationId, provider, model, message, finishReason, cached, usage
usage 최소 필드: promptTokens, cachedPromptTokens, meteredPromptTokens, completionTokens, totalTokens, meteredTotalTokens, requestCount, meteringSource
entitlement snapshot 필드: can_live, can_llm, live_mode, runtime_llm, 각 feature별 allowed/code/message/required_plan
오류 응답 필드: code, message, upstreamStatus, retriable

cached input이 적용되는 경우 cloud는 cachedPromptTokens를 별도로 관측하고, 실제 비용 구조를 더 잘 반영한 meteredPromptTokens / meteredTotalTokens를 함께 계산합니다. provider가 token usage를 주지 않는 경우에는 meteringSource=request_count fallback을 사용합니다.

prompt caching 관점에서는 cloud가 system prompt를 canonical하게 조립합니다. 현재는 Studio/runtime-chat이 같은 prompt bundle을 재사용하고, 역할/응답규칙/few-shot 같은 stable prefix를 앞에 둔 뒤 generated DSL reference를 뒤쪽 tail에 배치해 prefix 재사용 가능성을 높입니다.

주요 오류 매핑:

upstream 401/403 인증 실패: cloud는 이를 그대로 통과시키지 않고 HTTP 503 + code: llm_upstream_auth_error + retriable: false 로 정규화합니다.
일반 upstream rate limit / provider 오류: cloud는 보통 HTTP 502/503 + llm_upstream_error 또는 llm_upstream_unreachable로 정규화합니다.
relay 자체가 설정되지 않은 경우: HTTP 503 + code: llm_relay_unavailable
runtime Studio 표면은 위 구조화된 오류를 바탕으로 permission denied, relay unavailable, timeout, cloud auth/server configuration failure를 서로 다른 사용자 메시지로 보여줍니다.
permission denied는 현재 기준으로 BASIC 미만 plan 또는 runtime LLM entitlement 부족을 의미하며, runtime은 입력 잠금 + Cloud 업그레이드 안내로 연결합니다.

현재 prompt/profile override 정책:

plan override: 미지원
user override: 미지원
runtime version override: 미지원
runtimeVersion 필드는 현재 prompt fetch key가 아니며, relay request 호환성과 운영 관찰용 메타데이터에 가깝습니다.

즉 runtime은 “어떤 대화 맥락을 cloud에 전달할지”까지만 담당하고, provider secret ownership과 upstream 오류 정규화는 cloud가 담당합니다.

LLM Studio DSL 생성 규칙¶

LLM Studio가 생성하거나 수정하는 DSL 코드는 현재 canonical 파라미터 문법으로 param(name, description, default) 를 사용합니다.

param("rsi_period", "RSI 계산 기간", 14)
param("oversold", "과매도 기준선", 30)

새로 생성되는 코드와 자동완성/시그니처 도움말은 이 3인자 형식을 기준으로 동작합니다.
기존 2인자 param(name, default) 스크립트도 런타임에서 계속 실행되지만, 새 코드 작성과 LLM 생성 결과는 3인자 형식으로 정리하는 것을 권장합니다.
파라미터 설명은 운영 화면과 문서화된 DSL 계약에서 함께 사용되므로, 의미가 드러나는 설명 문자열을 넣는 편이 좋습니다.

자세한 파라미터 계약은 메타데이터를 참고하세요.