거래 탭 사용법¶

거래 탭(/operations)은 실시간 운용 화면입니다. 전략별 집계와 종목별 액션을 한 화면에서 보되, 전략 편집은 오른쪽 패널로 열고, 거래 반응은 전역 UI로 받는 구조를 사용합니다.

커뮤니티 공개 스크립트 운영 교체¶

운영자가 커뮤니티 공개 스크립트 묶음을 새 DSL 세트로 교체할 때는 DB를 직접 수정하기보다 bundle 생성 -> import 흐름을 사용합니다.

핵심 운영 규칙:

parser cache column 기준 이름은 runtime_parser_result_json 입니다.
--replace-publications는 PUBLISHED / HIDDEN 공개 스크립트만 교체합니다.
DRAFT private script는 이 모드에서 삭제하지 않습니다.
게시자를 시스템 계정으로 고정하려면 --default-author-username=quantiq를 사용합니다.
해당 username이 없으면 --create-author-if-missing로 시스템 게시자 계정을 먼저 만들 수 있습니다.

runtime helper 스크립트:

scripts/build_codex_community_bundle.py
scripts/replace_codex_community_publications.py

운영 기준으로는 Git에 있는 DSL/메타 파일을 먼저 관리하고, DB는 그 산출물을 배포하는 대상으로 보는 편이 안전합니다.

어디에 쓰는 화면인가¶

대시보드: 계좌 전체 요약과 큰 흐름을 봅니다.
거래 탭: 지금 어떤 종목을 관리해야 하는지 보고, 전략 생성/편집과 수동 주문/취소 같은 즉시 액션을 수행합니다.
기존 /monitor, /strategy 경로는 호환을 위해 남아 있지만 모두 /operations로 redirect 됩니다.

landing에서 말하는 전략은 준비되게, 운영은 이어지게는 거래 탭과 원격 운영 보조 흐름을 함께 가리킵니다.

즉, 거래 탭은 지금 무엇을 조치해야 하는가에 가장 가까운 화면입니다.

런타임 기동 대기 화면¶

브라우저가 runtime에 접속했을 때 /api/ready가 아직 false면, 로그인 화면이나 메인 앱 대신 간단한 대기 화면이 먼저 보일 수 있습니다.

문구: 런타임 기동 대기 중입니다. 완료되면 자동으로 이동합니다.
이 상태는 원장 복원, 필수 서비스 기동 같은 기본 준비가 아직 끝나지 않았다는 뜻입니다.
chart warm-up이나 background preload는 readiness를 막지 않으므로, ready가 true가 되면 자동으로 앱에 진입하고 나머지 차트 준비는 background에서 계속될 수 있습니다.

runtime을 직접 실행하는 환경이라면 시작 옵션으로 로그 레벨을 조정할 수 있습니다.

--debug: runtime 진단 로그를 DEBUG 레벨까지 포함해 남깁니다.
--log-level {debug|info|warning|error|critical}: 원하는 로그 레벨을 명시적으로 고정합니다.
overnight 점검처럼 자정 통과, reconnect, 장 시작 전후 흐름을 확인해야 하는 경우에는 --debug 또는 --log-level debug를 사용하면 됩니다.

설정 탭 업데이트 동작¶

설정 탭의 업데이트 표면은 stable channel만 대상으로 동작합니다.

현재 버전, 대상 버전, 적용 가능 여부, 적용 차단 사유를 함께 보여줍니다.
릴리즈가 필수 업데이트면 필수 업데이트로 표시됩니다.
필수 업데이트 여부는 GitHub Release body 상단의 front matter force_update: true 플래그로 지정할 수 있습니다.
화면에 보여주는 릴리즈 노트는 이 메타 블록을 제외한 나머지 본문만 사용합니다.

업데이트 적용 조건은 다음과 같습니다.

frozen 배포에서는 업데이트 확인과 업데이트 적용을 모두 사용할 수 있습니다.
dev/source 실행에서는 버전 확인까지만 가능하고, 실제 적용 요청은 거부됩니다.
엔진이 실행 중이면 업데이트를 적용할 수 없습니다. 먼저 엔진을 중지해야 합니다.

필수 업데이트는 다음처럼 동작합니다.

필수 업데이트가 감지된 상태에서 다음 runtime을 기동하면, frozen 배포는 앱 진입 전에 먼저 업데이트를 적용하려고 시도합니다.
dev/source 실행은 자동 적용을 하지 않고, 필수 업데이트 상태만 안내합니다.
따라서 운영자는 필수 업데이트 릴리즈를 배포할 때 엔진이 비활성인 재기동 시점에 맞춰 안내하는 것이 안전합니다.

Cloud 인증 실패¶

cloud relay 인증이 치명적으로 깨지면 단순 세션 깜빡임으로 넘기지 않고 운영 실패 상태로 취급합니다.

runtime은 엔진을 멈추고 auth_failure snapshot과 grace countdown을 노출할 수 있습니다.
grace 기간에는 다시 로그인하거나 토큰을 갱신해 복구할 기회를 주지만, 그동안 엔진 재시작은 거부될 수 있습니다.
grace가 끝나 blocked 상태가 되면 runtime API/WebSocket 접근도 막히고, 다시 로그인/로그아웃 또는 정상 토큰 갱신 전까지 운영을 이어갈 수 없습니다.
일시적인 /api/auth/session 실패나 순간적인 websocket 4401 한 번으로 바로 로그아웃시키는 흐름은 기본 정책이 아닙니다.

대시보드 자산 흐름¶

대시보드 today 자산 흐름 차트는 intraday 계좌 자산 흐름을 과도한 초단위 노이즈 없이 한눈에 보도록 고정 세션 축으로 보여줍니다.

대시보드의 미실현 포함 토글은 계좌 브리핑 카드에만 적용되지 않습니다. 같은 화면의 전략 랭킹과 종목 상세 손익 표면도 같은 기준을 따라, OFF에서는 realized-only, ON에서는 현재 평가손익이 포함된 손익 기준으로 함께 바뀝니다.
총 평가자산, today 자산 흐름, QUANTIQ 점유비중은 가능하면 브로커가 내려준 계좌 equity 를 그대로 기준 자산으로 사용합니다.
브로커 equity가 비어 있거나 0 이하인 예외적인 경우에만 runtime이 예수금 + 현재 보유 평가금액 형태의 fallback 추정을 사용할 수 있습니다.
브라우저는 이 값을 다시 예수금 + 보유 평가금액으로 재조합해 덮어쓰지 않습니다. 즉 화면의 총 평가자산은 가능하면 브로커 snapshot의 authoritative equity를 그대로 따라갑니다.
따라서 장중 전량 매도 직후에도 브로커 equity가 존재하면, 차트와 총 평가자산은 매도 종목 평가금액이 통째로 빠진 것처럼 급락하지 않아야 합니다.
X축은 항상 08:40~16:20 KST 범위를 고정으로 사용합니다. 사용자가 좌우 스크롤이나 줌으로 범위를 바꾸지 않습니다.
값은 초단위 tick이 아니라 5분 bucket의 마지막 계좌 자산값으로 집계됩니다. 같은 5분 안에서는 최신 값으로 계속 갱신되고, bucket이 바뀌면 다음 점이 이어집니다.
이 차트는 장중 모든 순간을 보간한 선이 아니라, runtime이 실제로 추적한 bucket만 연결한 intraday 시계열입니다.
runtime이 꺼져 있었거나 아직 추적을 시작하지 않은 구간은 선을 억지로 잇지 않고 whitespace gap으로 비워 둡니다. 이것은 차트 오류가 아니라 미추적 시간대를 뜻합니다.
같은 거래일/계좌 범위에서 이미 기록된 today 자산 곡선은 runtime 재기동 뒤에도 ledger projection으로 다시 이어받습니다. 따라서 재기동 직후 곡선이 최근 몇 분만 남는 것이 아니라, 이미 기록한 today 구간을 계속 이어서 봅니다.
브라우저가 보여주는 today 차트는 고정 범위용 padding(08:40~09:00, 16:00~16:20)을 포함합니다. 실제 값이 없는 padding 구간은 축만 유지하고 선은 그리지 않습니다.
상단의 추적 시작 HH:MM, 중단 후 재개 N회 문구는 오늘 실제로 추적된 시작 시점과 gap 개수를 요약합니다.
현재 actual equity point에는 점선 기준선이 함께 그려질 수 있습니다. 이 선은 마지막 실제 계좌 자산 수준을 빠르게 읽기 위한 참조선이지, 별도 계산값이 아닙니다.

브로커 계좌 요약 손익은 다음처럼 읽어야 합니다.

브로커 평가손익 / 브로커 수익률은 계좌 보유 종목의 현재가 기준 mark-to-market 결과를 다시 계산해 표시할 수 있습니다.
따라서 이 값은 캐시된 브로커 snapshot의 open_pnl, open_pnl_pct와 장중에 완전히 같지 않을 수 있습니다.
반면 기준 자산(broker_equity) 자체는 브로커가 제공한 값을 우선 유지합니다.

브로커 계좌 요약 손익은 다음처럼 읽어야 합니다.

브로커 평가손익 / 브로커 수익률은 계좌 보유 종목의 현재가 기준 mark-to-market 결과를 다시 계산해 표시할 수 있습니다.
따라서 이 값은 캐시된 브로커 snapshot의 open_pnl, open_pnl_pct와 장중에 완전히 같지 않을 수 있습니다.
반면 기준 자산(broker_equity) 자체는 브로커가 제공한 값을 우선 유지합니다.

화면 구성¶

1. 전략 테이블¶

상단 표는 실제 전략만 보여줍니다.

전략 상태
전략명
종목검색식을 연결한 전략은 전략명 아래에 검색식 이름이 보조 텍스트로 표시될 수 있습니다.
켜기 / 끄기, 편집, 삭제
보유 종목 수
전체 종목 수
총 보유 수량
대기 주문 수
평균 단가
평가 금액
미실현 손익
수익률
오늘 실현손익
최근 이벤트 시각

전략을 클릭하면 아래 종목 테이블이 그 전략 기준으로 좁혀집니다.

2. 종목 테이블¶

하단 표는 종목 단위 실시간 운영 표면입니다.

거래로그, 토스트, 수동 주문 알림 같은 주요 종목 표면은 종목명 우선으로 읽고, 종목코드는 필요할 때만 괄호 같은 보조 표기로 함께 보일 수 있습니다.
펼침
전략
전략 셀 아래 종목검색식 보조 텍스트
종목명
상태
작업
보유수량
미실현손익
수익률
현재가
등락률
대기주문
평균단가
평가금액
오늘 실현손익

종목 행은 버튼 영역을 제외한 아무 곳이나 클릭하면 펼침/접힘이 됩니다.

맨 앞 펼침 열의 아이콘과 행 hover 강조로 클릭 가능한 행이라는 점을 바로 확인할 수 있습니다.
종목을 펼쳐도 그 행이 표 상단으로 이동하지 않고, 같은 자리에서 바로 아래 상세 패널이 열립니다.
펼친 행과 상세 패널은 한 카드처럼 묶여 보여 여러 종목을 동시에 펼쳐도 구분하기 쉽습니다.
펼친 종목 상세 상태는 브라우저 로컬 상태로 유지될 수 있습니다. 따라서 같은 세션 안에서 다른 탭으로 이동했다가 돌아오거나, 새로고침 후에도 같은 종목 key가 남아 있으면 다시 펼쳐진 상태로 복원될 수 있습니다.
메인 행 작업 열에는 매수, 매도 같은 빠른 신규 주문 액션만 두고, 취소, 강제정리, 전략에서 제외 같은 후속 제어 액션은 펼친 상세 패널에서 확인합니다.
전략에서 제외는 종목을 전략 정의에서 지우는 기능이 아니라, 그 전략에만 적용되는 제외 목록(symbol_blacklist)에 넣는 기능입니다. 이미 보유/주문이 남아 있으면 화면에는 계속 남을 수 있지만, 이후 자동 후보 편입과 기본 감시는 blacklist 기준으로 막힙니다.
사용자/시스템 마커 표시 토글은 종목 테이블 상단의 전역 제어가 아니라, 각 종목을 펼쳤을 때 보이는 상세 차트 헤더에서 종목별 확인 맥락 안에서 조정합니다.
최근 이벤트 시각은 기본 표에서 항상 보이지 않고, 펼친 상세 패널 요약 카드에서 확인합니다.
기본 정렬은 보유+대기주문 → 보유 → 감시+대기주문 → 감시 순이며, 같은 그룹 안에서는 전략 소속 종목이 미귀속보다 먼저 옵니다.
전략, 종목명, 상태, 수치 열 헤더는 정렬 가능하며, 비활성일 때도 ↕ 표식으로 확인할 수 있습니다.
정렬을 바꾸면 우상단 메타 영역에 현재 정렬 기준이 보이고, 기본 정렬 버튼으로 언제든 기본 순서로 돌아갈 수 있습니다.

행을 펼치면 같은 표 안에서 다음 정보를 봅니다.

차트
최근 주문
정책 상태
누적 실현손익
총손익

종목 행의 현재가는 runtime live tick을 반영한 workspace_rows 갱신 결과를 기준으로 빠르게 따라올 수 있습니다.

즉, 주문/포지션 변경이 없어도 장중 현재가가 움직이면 다음 runtime view refresh에서 표의 현재가가 함께 갱신될 수 있습니다.
평가금액, 미실현손익, 수익률 같은 전략-심볼 계산값은 계속 runtime canonical row를 기준으로 봅니다.
펼친 최근 주문 요약 문구는 단순 상태 문자열만 보여주지 않고, FILLED/PARTIALLY_FILLED 주문이면 실제 체결 수량과 대표 체결 단가를 함께 보여줄 수 있습니다.
KIS order notice가 정상적으로 들어오면 주문 접수, 정정 접수, 체결 같은 상태는 periodic reconcile보다 먼저 거래 탭에 반영될 수 있습니다. 즉 화면 갱신이 빠르다고 해서 아직 비정상 상태라는 뜻은 아닙니다.

보기 모드¶

거래 탭은 두 가지 보기 모드를 제공합니다.

전체 보기¶

모든 전략 종목을 봅니다.
미귀속 종목도 함께 보입니다.

전략별 보기¶

현재 선택한 전략 종목만 봅니다.
미귀속 종목은 섞이지 않습니다.

미귀속 종목¶

전략 바인딩 없이 남아 있는 고아 포지션이나 고아 대기 주문은 종목 테이블에서 미귀속으로 표시됩니다.

전략 테이블에는 미귀속 전략 행이 따로 생기지 않습니다.
종목 테이블에서만 보입니다.
전체 보기에서는 보입니다.
전략별 보기에서는 보이지 않습니다.
remote snapshot이나 계좌 스코프 요약도 같은 기준을 재사용하므로, 원래 전략 id를 복구할 수 없는 orphan 포지션/주문은 내부 __manual__ bucket 기준 미귀속 표면으로 정리될 수 있습니다.

미귀속은 “전략과 무관한 종목”이 아니라, 현재 저장된 전략 행에 귀속되지 않은 종목/주문이라는 뜻입니다.

미귀속은 자동매매 전략 대상이 아닙니다.

전략이 자동으로 이 종목에 주문을 내지 않습니다.
사용자가 콘솔에서 확인하고 직접 주문/정리하는 대상입니다.
같은 심볼이라도 실제 전략 bucket과 미귀속 bucket이 동시에 존재할 수 있습니다.

전략 저장/삭제와 미귀속 이관¶

보유 포지션이나 대기 주문이 남아 있는 전략을 저장/삭제할 때는 단순히 “추적 해제”로 끝나지 않을 수 있습니다.

전략 삭제 확인을 완료하면 남아 있던 포지션과 대기 주문은 미귀속(__manual__)으로 이관될 수 있습니다.
전략 저장 중 종목을 전략에서 떼어내는 경우도 같은 방식으로 미귀속 이관이 일어날 수 있습니다.
이 과정은 강제 청산이 아니라 전략 bucket에서 미귀속 bucket으로 ownership을 옮기는 것입니다.

이관이 발생하면 runtime은 다음 정보를 남길 수 있습니다.

이관 종목 수
이관 손익
이관 시점 총손익

이 정보는 거래로그, 알림, 이후 UI 표면에서 확인할 수 있습니다.

전략 제외 목록¶

전략 편집 패널의 위험 종목 필터링 카드 아래에는 전략 전용 제외 목록이 따로 있습니다.

이 목록은 기본 제외 정책(KONEX, VI 등) 다음 순서의 수동 override 입니다.
조건식 전략과 고정 종목 전략 모두 같은 방식으로 사용합니다.
+ 추가를 누르면 종목 직접 선택 UI를 그대로 재사용해 blacklist에 등록할 수 있습니다.
이미 등록된 제외 종목은 태그의 × 버튼으로 바로 해제할 수 있습니다.
blacklist에 들어간 종목은 조건식 결과에서도 다시 채택되지 않고, 고정 종목 전략에서도 신규 runtime binding 대상에서 빠집니다.

차트 동작¶

전략 종목과 미귀속 종목의 차트 동작은 다릅니다.

거래 탭은 기본 정렬 상단 종목부터 background chart warm-up을 진행할 수 있습니다.
종목 테이블 상단 차트 워밍업 progress bar는 현재 세션에서 미리 준비된 종목 family 수를 보여줍니다.
warm-up은 사용자가 종목을 직접 펼치는 동작보다 낮은 우선순위로 진행되며, runtime이 바쁠 때는 천천히 채워질 수 있습니다.
일반 전략 종목
전략 스크립트가 선언한 scale과 overlay를 함께 볼 수 있습니다.
strategy.order_on 기준 차트는 선언 여부와 무관하게 항상 자동 포함됩니다.
자동 포함된 canonical 차트에는 주문발행기준 배지와 강조 스타일이 붙습니다.
주문발행기준 배지에 마우스를 올리면 왜 이 차트가 자동 포함되었는지 tooltip으로 확인할 수 있습니다.
strategy.order_on="tick"인 전략은 거래 탭에서 canonical 차트를 1T로 대표 표시합니다.
여러 scale이나 sub pane을 함께 띄우면 크로스헤어와 시점이 함께 동기화되고, sub pane도 자체 시간축을 표시합니다.
차트 상단 OHLCV 레전드는 시가/고가/저가/종가/거래량 한글 표기로 통일합니다.
시스템 주문 marker는 canonical 차트에만 표시됩니다.
사용자 marker는 선언한 chart/timeframe에만 남고, 다른 scale로 복제되지 않습니다.
실시간 overlay patch는 현재 진행 중인 봉 marker를 최신 실행 결과로 교체합니다. 이번 실행에서 빠진 현재 봉 사용자 marker는 차트에서도 제거됩니다.
닫힌 과거봉 사용자 marker는 차트 이력으로 유지됩니다. websocket patch에 과거 marker가 다시 모두 오지 않아도 브라우저가 즉시 지우지 않습니다.
같은 봉에서 동일한 사용자/status marker를 반복 등록하면 하나로 upsert됩니다. 같은 봉이라도 text, color, position, shape 중 하나가 다르면 함께 표시될 수 있습니다.
펼친 상세 차트 헤더의 [사용자 | 시스템] 마커 토글은 기본 ON이며, render layer만 숨기고 원본 overlay payload는 유지합니다.
사용자 marker는 시스템 marker보다 작게 표시되어 시각적 위계를 둡니다.
intent와 submitted는 같은 주문 marker 계열로 표시합니다. 취소 여부는 차트보다 최근 주문 패널과 거래 로그가 authoritative surface입니다.
미귀속 종목
전략 DSL overlay를 전제로 하지 않습니다.
기본 candle 차트 fallback으로 확인합니다.
저장된 전략 id가 남아 있어도 실제 전략 객체가 없으면 전략 차트가 아니라 심볼 candle 차트로 확인합니다.
미귀속(__manual__) row에 보유 포지션, 대기/미확정 주문, 또는 broker cached holding이 있으면 일반 전략 종목처럼 실시간 candle 갱신을 계속 받습니다.
websocket이 끊겼다가 다시 붙은 직후에는, 현재 열려 있는 차트가 patch만 이어붙이지 않고 최신 snapshot을 한 번 다시 받아 OHLCV를 재정합할 수 있습니다.
이 재정합은 단순 idle 시간보다 reconnect/gap 같은 resync 근거가 생겼을 때 우선 수행합니다.
이 재정합 과정에서는 중복 timestamp candle을 제거한 뒤 다시 그리므로, reconnect 직후 같은 봉이 겹쳐 보이거나 malformed candle shape가 남지 않도록 하는 쪽을 우선합니다.
overlay가 없다는 이유만으로 오류로 보지 않습니다.

차트 데이터가 비어 있거나 일시 오류가 있으면 다시 불러오기로 재시도할 수 있습니다.

수동 액션¶

종목 테이블 작업 열에서 즉시 액션을 수행합니다.

수동매수
수동매도

수동 매수/매도¶

주문 모달에서 다음을 확인하고 전송합니다.

현재가
보유수량
가능수량
주문 가능 금액 또는 평가 금액
시장가 / 지정가
주문수량

시장가 주문은 화면에 보이는 현재가를 참고값으로 보여줄 수 있지만, 브로커 전송 본문은 시장가 규칙에 맞춰 0원으로 제출됩니다. 즉 화면의 현재가 숫자가 지정가처럼 그대로 들어가는 것은 아닙니다.

주문 결과는 raw 500 대신 사용자 메시지로 해석해서 보여줘야 합니다. 예를 들면:

브로커 미연결
주문 거부
전송 실패
전송 불확실(재조정 대기)

전략에 바인딩된 종목에서 QUANTIQ 콘솔로 내는 수동 주문은 별도 인수 대기 단계 없이 그 전략 주문으로 바로 생성됩니다.

미귀속 종목 수동 주문은 미귀속 bucket에서 계속 관리됩니다. 전략 자동주문으로 되돌아가지 않습니다.

브로커 submit이 성공하면 주문 모달은 runtime 전체 refresh가 끝나기 전이라도 바로 닫힐 수 있습니다.
이후 화면 재동기화가 늦거나 실패하면, 주문 성공 자체를 되돌리지 않고 주문은 접수됐지만 화면 갱신에 실패했습니다 같은 후속 경고만 별도로 보여줍니다.

수동 주문 가능 시간은 한국 주식 정규장 연속매매 세션인 09:00 <= t < 15:20 기준입니다. 15:20~15:30 종가 동시호가와 장 마감 후에는 콘솔에서 새 수동 주문을 차단하고, 같은 사유 문구를 운영 알림에도 남깁니다.

대기 주문 취소¶

대기 주문 취소는 메인 행 버튼이 아니라 펼친 상세 패널의 주문 이력에서 수행합니다.

운영 탭은 브라우저가 status만 보고 추정하지 않고, runtime order payload의 cancel_allowed, cancel_reason, repair_required, repair_reason, status_source, status_confidence, status_detail를 기준으로 취소 버튼과 안내 문구를 결정합니다.
repair_required 주문은 일반 pending과 같은 뜻이 아니므로 별도 문구를 같이 봐야 합니다. legacy reconcile_required는 같은 의미의 호환 alias입니다.
status_source는 최소한 WS 반영, repair 대기, reconcile 보정, 브로커 응답, 로컬 상태를 구분하므로, 운영자는 같은 SUBMITTED라도 어떤 근거로 보이는 상태인지 바로 확인할 수 있습니다.
행을 펼치면 주문 이력 목록에서 주문별로 직접 취소할 수 있습니다.
펼친 주문 목록은 최근 일부가 아니라 현재 종목/전략 스코프의 전체 주문 이력을 스크롤 형태로 보여줍니다.
목록은 주문일 역순으로 정렬되고, 각 주문 시각은 월/일 시:분:초 형식으로 표시됩니다.
FILLED, REJECTED, FAILED 주문에는 취소 액션이 나타나지 않습니다.
PENDING 주문은 브로커 submit 전이면 로컬에서 바로 취소될 수 있습니다.
UNKNOWN, RECONCILE_UNRESOLVED 같은 미확정 주문도 가능한 한 취소를 시도합니다. 브로커 주문번호가 없더라도 미체결 주문 조회에서 대상을 찾으면 그 주문번호로 취소를 시도합니다.
조회로도 대상을 찾지 못하면, 화면은 거짓된 취소 완료 대신 주문 접수 또는 체결 여부를 재확인하세요 같은 메시지로 안내합니다.
브로커가 취소 REST 요청을 수락해도, 화면은 먼저 취소 요청 접수 중간 상태를 거칠 수 있습니다.
이후 CANCEL_ACCEPTED 체결통보가 도착하면 정상 success path에서는 reconcile 주기를 기다리지 않고 곧바로 취소 완료로 닫힙니다.
브로커가 정정/취소할 수량이 없습니다를 반환해도 바로 실패로 단정하지 않고, 화면은 취소 재조정 중으로 유지한 뒤 다음 repair가 최종 체결 또는 취소 완료를 확정합니다.
정정이나 취소 과정에서 브로커 주문번호가 새로 발급돼도 거래 탭은 이를 새 독립 주문으로 끊어 보여주지 않고, 같은 주문 이력 안에서 이어진 상태 변화로 추적합니다.
따라서 취소 요청 직후에는 주문 마커가 잠시 남아 있을 수 있지만, CANCEL_ACCEPTED 이후에는 zero-fill 주문 마커가 곧바로 정리됩니다.
주문/취소 요청은 브로커 hashkey 생성이 먼저 성공해야 전송됩니다. 이 단계가 실패하면 거래 탭은 요청을 보내지 않고 전송 실패로 안내합니다.

강제 정리와 자동 정리¶

브로커가 주문번호의 존재를 명확히 부정하거나, 모의투자 환경에서 장시간 실체를 복원할 수 없는 phantom order가 남을 수 있습니다.

강제정리는 브로커 취소 성공과 같은 의미가 아닙니다.
이 액션은 브로커 원장에 더 이상 실재 주문이 없다고 판단될 때, 로컬 운영 대상을 명시적으로 종료하는 정리 동작입니다.
확인 모달은 강한 주의 문구를 포함하며, 일반 취소와 구분된 결과로 기록됩니다.

운영자가 보게 되는 대표 흐름은 다음과 같습니다.

브로커 취소 성공: 정상 경로에서는 CANCEL_ACCEPTED 체결통보가 즉시 취소 완료를 확정하고, WS miss나 zero-qty 같은 예외만 repair가 보정합니다.
브로커가 원주문번호가 존재하지 않습니다를 반환: runtime은 이를 강한 negative evidence로 보고 로컬 주문을 정리할 수 있습니다.
모의투자에서 open inquiry 미지원, filled no-match, zero-fill 상태가 반복: runtime은 paper phantom order로 판단해 자동 정리할 수 있습니다.

즉 강제정리와 자동 정리는 모두 운영 표면 정리를 위한 장치이며, 브로커 취소 체결 응답과 같은 뜻으로 읽으면 안 됩니다.

주문 상태 해석 팁¶

운영 탭의 주문 라벨은 단순한 대기/완료만 뜻하지 않습니다.

전송 불확실 · 재조정 대기: broker submit 자체가 불확실하거나, startup/reconnect/WS miss 때문에 repair가 필요한 주문입니다.
취소 재조정 중: REST 취소 요청은 들어갔지만 CANCEL_ACCEPTED WS가 아직 없거나, 브로커가 취소 가능 수량 0 같은 애매한 응답을 줘서 최종 체결/취소 상태를 아직 확정하지 못한 상태입니다.
취소 가능 수량 0 응답: 브로커가 취소 가능한 잔량이 없다고 답했으며, 다음 재조정이 최종 상태를 정합니다.
강제정리 또는 phantom cleanup 결과: 브로커 취소 성공이 아니라, 운영상 더 이상 추적할 실체가 없다고 보고 로컬 주문을 종료한 상태입니다.

전역 UI¶

거래 탭에는 페이지 본문 밖의 전역 보조 UI가 있습니다.

탑바¶

탑바는 엔진 제어, 거래 모드, KIS 연결, 활성 전략 수 같은 전역 제어/상태를 빠르게 확인하는 compact surface입니다.

포지션, 누적 손익처럼 계좌 스코프와 전략 스코프가 섞이기 쉬운 숫자는 기본 탑바에서 직접 보여주지 않습니다.
손익과 계좌 상태는 하단 운영 스트립의 추적 요약과 계좌 현황 펼치기 패널에서 나눠 확인합니다.
즉, 탑바는 제어와 상태 확인에 집중하고, 숫자 해석이 필요한 계좌/손익 정보는 하단 영역으로 분리되어 있습니다.

탑바 아래 연결 경고 배너는 ws, kis, cloud_relay 세 채널의 연결 이상을 요약해서 보여줍니다.

동시에 여러 채널이 끊겨 있어도 화면에는 가장 우선순위가 높은 경고 하나만 노출됩니다. 현재 우선순위는 cloud_relay → kis → ws 순서입니다.
닫기를 누르면 현재 코드의 경고만 숨기고, 해당 채널 상태가 복구될 때까지는 같은 코드를 다시 띄우지 않습니다. 다른 disconnected 채널이 남아 있으면 우선순위에 따라 다음 경고가 바로 이어서 표시될 수 있습니다.
Cloud 인증 오류처럼 별도 auth failure 배너가 활성화된 동안에는 연결 경고 배너를 겹쳐서 보여주지 않습니다.
연결 상태는 단순 설정 여부만 보지 않습니다. structured WebSocket notification이 오면 해당 채널 상태를 즉시 갱신하고, 폴링 응답에 broker.connected / llm.connected가 있으면 그 값을 authoritative 상태로 사용합니다. configured 값은 초기 상태가 아직 없을 때만 fallback으로 사용합니다.

하단 운영 스트립¶

세션 수준 상태를 빠르게 보여줍니다.

엔진 상태
장 상태
추적 보유
추적 평가금액
추적 미실현손익
오늘 손익
대기주문 수
오늘 체결
증권 연결 상태

위 기본 bar는 QUANTIQ가 현재 추적 중인 운영 대상 기준 숫자만 compact하게 보여줍니다.

오늘 손익은 account_summary.daily_pnl를 기준으로 봅니다.
대기주문 수는 recent 주문 subset이 아니라 pending_order_count 같은 canonical summary field를 우선 사용합니다.
오늘 체결처럼 전체 주문 이력이 필요한 숫자는 recent window가 아니라 full order history 기준으로 봅니다.
추적 보유와 계좌 전체 보유는 다를 수 있으므로, 기본 bar는 브로커 계좌 전체 숫자를 섞어 보여주지 않습니다.

운영 스트립 계좌 현황 펼치기¶

트레이더가 계좌 전체 상태를 계속 확인하고 싶다면, 운영 스트립 오른쪽의 계좌 현황 펼치기를 사용할 수 있습니다.

펼치면 같은 위치에서 다음 계좌 전체 기준 값이 추가로 보입니다.

계좌 보유
총 평가자산
예수금
계좌 평가손익
수동 현금 추정

이 패널은 브로커 계좌 스냅샷 기준 값이며, 기본 운영 bar의 추적 숫자와 의도적으로 분리되어 표시됩니다.

계좌 현황과 거래로그를 둘 다 열면, 거래로그 패널은 실제 하단 strip 높이에 맞춰 바로 위에 붙어 열립니다.
따라서 두 패널 사이에 의도하지 않은 빈 틈이 생기거나, 닫힌 거래로그 헤더가 계좌 현황 아래로 비쳐 보이지 않아야 합니다.

거래로그¶

하단 바에서 열리는 슬라이드업 패널입니다.

INFO 이상 이벤트만 표시합니다.
지우기로 현재 목록을 비웁니다.
닫기로 패널을 내립니다.

토스트¶

우측 하단 토스트는 즉시성 이벤트용입니다.

주문 발행
체결
거부
연결 오류
기타 짧은 결과 알림

토스트 우측 닫기 영역을 눌러 빠르게 여러 개를 닫을 수 있습니다.

텔레그램과 원격 운영¶

텔레그램 연동이 설정된 환경에서는 거래 탭에서 보던 일부 경고/상태를 원격으로 이어서 확인할 수 있습니다.

warning/critical 운영 알림은 화면과 텔레그램에 같은 본문으로 전달됩니다.
원격 제어가 활성화된 환경에서는 일부 명령을 텔레그램에서 이어서 수행할 수 있습니다.
텔레그램은 운영 보조 채널이지, runtime을 대체하는 실행 엔진은 아닙니다.

즉 실제 자동매매 실행은 계속 로컬 runtime이 담당하고, 텔레그램은 자리 밖에서 운영 흐름을 이어 주는 수단으로 이해하면 됩니다.

계좌/전략 단위 손익절¶

landing에서 소개하는 계좌·전략 단위 손익절은 runtime 리스크 관리 범위를 뜻합니다.

계좌 단위 기준은 세션 전체 손익 또는 보호 한도를 다룹니다.
전략 단위 기준은 특정 전략 bucket에 묶인 포지션/주문의 손익 기준을 다룹니다.
실제 적용 방식과 우선순위는 runtime 리스크 설정 및 계좌 상태에 따라 달라질 수 있습니다.

문서와 화면에 공통으로 중요한 점은, 이 손익절이 단순 시각화가 아니라 runtime 운영 규칙과 연결된다는 점입니다.

전략 편집 패널¶

전략 생성/편집은 별도 페이지 이동이 아니라 오른쪽 overlay 패널에서 수행합니다.

새 전략은 기본적으로 비활성 상태로 저장됩니다.
저장은 설정 초안 확정 단계이고, 실제 runtime 편입은 사용자가 전략 테이블에서 처음 활성화할 때 시작됩니다.
즉 저장 직후 바로 실행되지 않으며, 상단 전략 테이블의 켜기 버튼을 눌러야 실제 실행이 시작됩니다.
생성 또는 편집을 누르면 오른쪽에서 패널이 열립니다.
기존 전략 편집에서는 스크립트 변경이 막혀 있을 수 있습니다.
저장 또는 취소 시 패널이 닫힙니다.

기억할 점¶

전략 테이블은 실제 전략만 보여줍니다.
종목 테이블은 실제 전략 종목 + 미귀속 종목을 함께 보여줄 수 있습니다.
미귀속은 숨기지 말고, 전체 보기에서 확인해야 합니다.
거래 탭의 숫자는 브라우저 재계산보다 runtime canonical field를 우선 사용합니다.
현재 구현에서 미귀속으로 바로 보이는 주 대상은 삭제된 전략의 잔여 포지션/주문, legacy orphan 원장, 그리고 승격 조건을 만족한 broker-only 보유입니다.
거래 탭 상태 라벨은 내부 import 플래그를 직접 보여주지 않고 보유, 주문대기, 차단, 감시, 비활성 같은 직접 상태를 우선 사용합니다.