v0.52.6 — 비교지수는 ETF의 추적지수가 아니다

라우팅 감사에서 세 모델이 전부 medium을 준 자리("TIGER 미국나스닥100 1년 수익률을 지수
수익률이랑 비교해줘")를 파 보니, 문구가 아니라 표가 거짓말을 하고 있었다. 여섯 라운드
연속으로 발견이 "값 계산은 맞는데 출력이 주장하는 사실이 API와 다른" 부류다.

고친 것

• get_etf_returns의 대상지수 수익률 컬럼은 그 ETF의 추적지수 수익률이 아니었다.
  키움 ka40001의 cntr_prft_rt는 요청 필드 etfobjt_idex_cd의 수익률을 그대로 채우고
  ETF와 대조하지 않는다. 모의·실전 양쪽에서 다시 찍었다(2026-08-21, 1년 기준):

  ETF	201(KOSPI200)	101(코스닥 종합)	999(없는 코드)	ETF 자기 수익률
  069500 KODEX 200	+156.13	+0.12	0.00	+157.86
  133690 TIGER 미국나스닥100	+156.13	+0.12	0.00	+24.72

  종목과 무관하게 지수코드만 따라간다. 즉 나스닥100 추종 ETF의 +24.72% 옆에 기본값이
  끌어온 KOSPI200 +156.13%가 "대상지수 수익률"이라는 이름을 달고 앉아 있었다.

• 컬럼명을 비교지수 수익률로 바꾸고, 각주에 비교지수와 이 ETF의 추적지수를 나란히
  찍는다(추적지수명은 비ETF 가드가 이미 부르던 ka40002 응답에 있어 호출이 늘지 않는다).
  둘이 자동으로 맞춰지지 않는다는 사실을 함께 적었다.

• 해외지수 추종 ETF는 비교 지수를 맞출 방법이 없다 — benchmark_index_code가 키움
  업종 코드(국내 지수)만 받기 때문이다. 없는 것을 없다고 description·파라미터 설명·각주
  셋에 적고, "지수를 얼마나 잘 따라갔나"는 view=daily의 추적오차율로 안내한다.

검증

게이트 넷 + 라이브 스윕(--only get_etf_returns --full, calls=4 unexpected_errors=0)으로
표·각주·비ETF 가드를 눈으로 확인했다. 새 단언 5개는 문구만 옛 상태로 되돌리는 주입으로
가짜 가드가 아님을 확인했다 — 시그니처까지 되돌리면 인자가 밀려 틀린 이유로 빨개진다.

라우팅 재실행에서 해당 문항의 sonnet 확신도가 medium → high로 올라갔고, haiku는 medium이지만
근거가 추측에서 사실로 바뀌었다("해외지수 추종 ETF는 벤치마크 비교 불가").

계산과 호출 수는 그대로다. 바뀐 것은 표의 컬럼명, 각주 두 줄, 모델이 읽는 문구다.

v0.52.5 — 두 tool이 서로를 가리키기만 하던 자리

v0.52.4에서 처음 잰 "모델이 옳은 tool을 고르는가"를 스크립트로 승격하고, 승격하자마자
첫 재실행이 짚은 두 자리를 고쳤다. 둘 다 값 계산은 맞는데 문구가 사실과 다르거나
모자란 부류다 — 이 저장소에서 다섯 라운드 연속 같은 유형이다.

고친 것

• get_order_executions ↔ get_transactions — 전자는 "과거 일자는 get_transactions로",
  후자는 "체결가는 get_order_executions로"라 적어 둬서 '어제 체결가'를 물으면 모델이 두
  tool 사이를 왕복만 했다(모델 셋이 셋 다 다른 답을 냈다). 실제로는 ka10076이 지난 일자를
  주지 않고 kt00015는 결제일(D+2) 기준이라 어제 체결분은 오늘 어느 쪽에도 없다.
  리다이렉트 대신 그 사실을 양쪽 description에 적고, 빈 결과 각주에도 같이 넣었다 —
  각주에만 있으면 라우팅이 못 읽고, description에만 있으면 빈손을 받은 사용자가 이유를
  모른다.
• get_theme_groups / get_sector_stocks — "'반도체'처럼 업종을 뜻한 것이라면
  get_sector_stocks가 맞습니다"라는 단정이 '반도체 테마에 뭐가 들어있어?'를 업종으로
  보냈다(모델이 그 문장을 근거로 인용했다). 이름이 겹친다는 사실과 사용자가 쓴 말을
  따른다는 기준으로 바꾸고, 업종 쪽에도 거울 문구를 넣었다(테마명은 받지 않는다).

감시

라우팅 시험이 scripts/routing.py 한 명령이 됐다 — 카탈로그 덤프(tools/list 응답
그대로) → 시험지 → 소스를 못 보는 별도 프로세스의 답안 → 채점. 그전까지는 손 절차라
질문·정답표가 로컬에만 있었다. 이제 데이터는 저장소에 있고, npm run check의 일곱 번째
검사가 그 정답표가 실제 tool·파라미터를 가리키는지 본다. 시험 자체는 모델을 부르므로
CI에 없어서, 그 사이 정답표만 조용히 낡기 때문이다 — 특히 param_check의 이름이 낡으면
"이 파라미터를 넘기지 말 것" 검사가 영원히 통과한다.

검증

같은 시험 재실행에서 haiku·sonnet·opus 셋 다 52/52(직전 라운드는 52·51·52).
제한은 첫 문장에 적어야 따라온다는 것도 여기서 나왔다 — 같은 사실을 문장 뒤쪽에 두면
haiku는 읽고도 그 tool을 불렀고(명령형을 붙여도 그랬다), 첫 문장으로 올리자 넘어왔다.

빈 결과 각주는 모의 스윕으로 눈으로 확인했고, 새 각주 단언은 실패 주입으로 가짜 가드가
아님을 확인했다.

동작 변화는 없다. 바뀐 것은 모델이 읽는 문구와 빈 결과 각주 한 줄, 그리고 감시다.

v0.52.4 — 모델이 tool을 고르는 근거를 처음 감사했다

이 서버의 최종 사용자는 모델이다. 그런데 지금까지의 감시는 전부 "tool이 옳은 답을
내는가"였다 — 스윕은 tool을 이름으로 직접 부르고, 포맷터 테스트는 description을 렌더조차
하지 않는다. "모델이 옳은 tool을 고르는가"는 어느 게이트에도 안 걸린다.

소스 접근을 막은 에이전트 3종(Opus·Sonnet·Haiku)에게 tools/list 응답 그대로의 카탈로그와
실제 투자자 말투 질문 52개만 주고 라우팅을 시켰다. 결과는 Opus 51/52, Sonnet 51/52,
Haiku 46/52. 라우팅 자체는 대체로 멀쩡했고, 오답 2건이 둘 다 "없는 것을 없다고 안
적어서" 생겼다.

고친 것

• get_stock_price — "기본 지표"라는 뭉뚱그린 표현에 배당수익률이 들어 있는 것처럼
  읽혔다. 실제 렌더는 PER·EPS·PBR·시가총액뿐이고 키움 REST에는 배당 TR 자체가 없다.
  지표를 열거하고 배당 미제공을 명시했다.
• get_order_executions — 기간 파라미터가 없다는 사실이 빈 결과 각주에만 있었다.
  모델이 tool을 고를 때 읽는 건 description이라, "어제 체결가"를 묻는 질문이
  get_transactions로 샜다. 조회 범위를 description으로 올리고 양쪽에 역참조를 달았다.
• get_orderbook — get_stock_quotes를 "(체결 내역)"이라고 불렀다. ka10095는
  멀티코드 시세 스냅샷이고 그 이름은 get_order_executions가 쓴다.
• 모호함이 갈린 자리 넷 — get_theme_groups에 테마명 검색이 없다는 사실(업종이면
  get_sector_stocks), get_investor_rank(매매 기준)와 get_foreign_holding(보유·한도
  기준)의 streak 충돌, get_investor_trend↔get_daily_trading 경계,
  get_valuation_rank가 지표 하나씩만 받는다는 점, get_net_buy_rank의 market 필수.

검증

고친 카탈로그로 같은 시험을 다시 봐서 Haiku 46/52 → 51/52, 오답 0을 확인했다.
덤으로 v0.52.3이 describe로 고친 자리도 재현됐다 — 장중 대차잔고 질문에서 세 모델 모두
to_date를 넘기지 않았다.

게이트

npm run check에 여섯 번째 검사가 붙었다 — description이 가리키는 tool 이름이 실존하는지.
오타·개명으로 없는 tool을 가리켜도 typecheck는 문자열 안을 안 보고 포맷터 테스트는
description을 렌더하지 않는다. 실패 주입으로 가짜 가드가 아님을 확인했다.

동작 변화는 없다. 바뀐 것은 모델이 읽는 문구와 게이트뿐이다.

v0.52.3 — 대차잔고 빈 결과 안내를 부른 방식대로 갈랐다

get_stock_lending(view=balance_rank)가 행을 못 찾았을 때, 원인이 셋인데 안내가 하나였다.
값 계산은 맞았고 문구와 가드 전제가 틀린 건이다 — 네 번째 리뷰 라운드 연속 같은 유형이다.

고친 것

① 빈 결과 안내가 부른 방식과 무관하게 하나였다 (#111)

부른 방식	실제 원인	예전 안내
기본 호출 + 후퇴 예산(5칸) 소진	긴 연휴	"그때까지는 전 거래일까지만 조회되니" — 방금 그 전 거래일들을 훑고도 빈손이었다
to_date=오늘	후퇴가 꺼져 있을 뿐, 저녁이면 열린다	(맞았다)
to_date=과거 날짜	휴장일이거나 없는 날 — 기다려도 안 열린다	"저녁에 다시 부르세요"

세 갈래로 갈랐다. 기다릴 것이 있는 사람에게만 참인 문장을 전원에게 주지 않는다.

② to_date가 자동 후퇴를 끈다는 사실이 어디에도 없었다

모델은 .describe()를 읽고 파라미터를 고르는데 "기준일은 to_date로 지정합니다"만 있어,
오늘을 직접 박아 부르면 기본 호출이 가진 자동 후퇴를 잃는다는 걸 알 방법이 없었다.
tool description과 to_date describe 양쪽에 적었다 — 생략하면 최신 집계일로 물러서고,
오늘을 박으면 저녁 집계 전까지 빈 결과다.

③ 스윕 기준일 검사가 자기 전제 밖 항목에도 돌았다

날짜를 박으면 후퇴가 꺼지므로 과거 기준일에 각주가 없는 게 정상인데 검사는 회귀로 셌다.
지금 계획엔 그런 항목이 없지만 하나 추가하는 순간 틀린 이유로 빨개진다.

검증

• 새 단언 2개가 실패 주입(git stash push -- src)에서 전부 빨개진다.
• 라이브 스윕 calls=113 unexpected_errors=0, 세 번째 경로는 실제 대체공휴일(2026-08-17)로 확인.
• v0.52.2에 붙인 기준일 자기검증이 라이브에서 실제로 판정을 돌렸다는 것도 상수 주입으로
  확인했다 — 통과 화면은 "판정하고 통과"와 "조건이 안 맞아 건너뜀"을 구별해 주지 않는다.

호환성 변화 없음. tool 49개(+ISA opt-in 1) 그대로다.

v0.52.2 — 대차잔고 순위가 언제 열리는지 알려 준다

get_stock_lending(view="balance_rank")는 ka90012가 당일 집계를 장중에 주지 않아
장중 내내 전 거래일로 물러선다. 그런데 각주가 안 준다는 사실만 말하고 언제 주는지는
말하지 않아, 사용자가 할 수 있는 선택이 "to_date로 과거를 지정한다" 하나뿐이었다.
가장 쉬운 답인 **"저녁에 다시 부르면 오늘치가 나온다"**를 아무 데서도 못 들었다.

실측으로 시각을 잡았다 (2026-08-19, 9표본)

16:38 · 16:39 · 17:07 · 17:37 · 18:26 · 18:37 · 19:07  →   0행
20:07                                                  →  50행

열림은 19:07~20:07 사이다(전날 8/18 20:52 열림과 일관). 매 표본이 대조군(직전 거래일)을
같이 불러 0행의 원인이 파라미터·서버가 아님을 배제했고, 20:07의 50행은 대조군과 50/50
전부 달라 dt가 실제로 먹는다. 열린 값은 확정치다 — 8/18치가 다음 날 저녁까지
행·필드 완전 동일이라 잠정 각주는 붙이지 않았다.

바뀐 것

• 후퇴 성공 각주("전 거래일 기준으로 보여 드립니다")에 저녁 열림을 덧붙였다.
  장중 호출이 행을 받는 경로라 빈 결과 힌트보다 이쪽을 훨씬 자주 본다.
• 빈 결과 힌트는 원인을 "장중에 안 준다"에서 "저녁 늦게(20시 무렵) 열린다"로 뒤집고
  to_date와 함께 저녁 재호출을 권한다.

사용자 문구에는 "20시 무렵"까지만 적었다 — 전이 관측이 하루치라 정확한 구간을 박으면
그 숫자가 낡는다. 구간과 근거는 소스 주석에 남겼다.

tool 수·API 계약은 그대로다 (49 + ISA 1).

v0.52.1 — 대차잔고 순위가 연휴 다음 날 빈손이던 문제

고친 것

get_stock_lending의 view=balance_rank(ka90012 대차거래잔고상위)는 이 TR이 당일
집계를 장중에 주지 않아 기준일을 하루 물러서는데, 그 후퇴가 캘린더 하루 한 칸이었다.
월요일은 전날이 일요일이고 공휴일 다음 날은 그 공휴일이라, 날짜를 지정하지 않은 호출이
그런 날 장중 내내 "데이터가 없습니다"를 냈다. 거래일의 20%가 넘는다.

2026-08-18(화) 실전 스윕에서 실제로 나갔다 — 전날 8/17이 대체공휴일(8/15 광복절이
토요일)이라 한 칸 물러서도 0행이었다. 에러가 아니라서 "그날 데이터가 없나 보다"로 읽힌다.

이제 거래일을 만날 때까지 하루씩 물러선다(최대 5칸). 연속 휴장 k일이면 k+1칸이 필요하므로
4일 연속 휴장까지 닿는다. 설·추석처럼 더 길게 닫히면 못 넘고, 그때는 어디까지 훑었는지를
문구가 밝힌다.

문구

후퇴하고도 빈손인 경우, 기존 각주 "전 거래일(X) 기준으로 보여 드립니다"는 보여 준 것이
없으므로 거짓이었다. 그 경로에서는 대신 훑은 범위를 밝힌다 — "요청일(8/18)부터 8/13까지
하루씩 물러서며 찾았지만 행이 없습니다".

그 밖

개발 의존성만 바뀐 커밋 여럿(TypeScript 7·vitest 4·@types/node 정렬, Dependabot 설정)이
v0.52.0 태그 뒤에 들어 있다. 빌드 산출물은 v0.52.0과 바이트 동일해 동작 변화는 없다.

읽기 전용 서버라는 성격은 그대로다 — 주문·정정·취소 TR은 추가하지 않는다.

v0.52.0 — Node 지원 바닥 22, 스윕 VI 자기검증

Node 20 EOL — 지원 바닥을 22로 올렸습니다

engines가 >=22가 되고 CI matrix가 [22, 24]로 바뀝니다.

• Node 20은 2026-04-30에 EOL입니다. 그동안 게이트는 이미 끝난 버전에서 돌면서,
  정작 현행 Active LTS인 24는 한 번도 보지 않고 있었습니다(24는 2028-04까지).
• 코드가 실제로 요구하는 최소치는 여전히 20.12(process.loadEnvFile)입니다.
  바닥을 올린 이유는 문법이 아니라 테스트하지 않는 버전을 지원한다고 적어 두지
  않기 위해서입니다.
• 발행 워크플로는 원래 24를 씁니다(npm trusted publishing이 >=22.14 요구) —
  이제 게이트와 발행이 같은 대역을 봅니다.

Node 20에서 쓰고 계셨다면 22 이상으로 올려 주세요. 런타임 코드 자체는 그대로라
20.12+에서도 동작하지만, 그 조합은 이제 아무도 테스트하지 않습니다.

대차잔고 상위의 전 거래일 후퇴가 요청일 기준이 아니었습니다

get_stock_lending(view="balance_rank")은 ka90012가 당일 집계를 주지 않을 때
전 거래일로 한 번 물러섭니다(v0.51.1). 그 후퇴가 요청한 날짜가 아니라 "오늘"에서
하루를 빼고 있었습니다.

날짜를 지정하지 않은 호출에서는 둘이 같은 날이라 결과가 달라지지 않지만, 함수가
전제를 강제하지 않아 인자와 실제 조회일이 갈릴 수 있는 구조였습니다. 후퇴 기준을
인자에서 직접 빼도록 고쳤고(previousDay), 월·연·윤년 경계를 테스트로 덮었습니다.

이 버그는 하루 뒤에 깨진 테스트로 드러났습니다 — 옛 단언은 조회 날짜를 응답이
돌려준 값과 맞춰 봐서 구현이 어떤 날짜를 부르든 통과했습니다. 이제 글자로 못 박습니다.

스윕의 VI 감시가 가짜였습니다 (개발 도구)

get_vi_stocks의 종목 지정 조회는 실패 모드가 rc=0 + 0행이라 라이브 스윕만
잡을 수 있는데, 감시가 고정 종목코드였습니다 — 그 종목에 VI가 없는 날이면 회귀가
되살아나도 화면이 정상과 글자까지 같습니다.

이제 직전 전체 목록의 첫 코드를 물려받아 조회하고, 그 코드가 빈손이면 회귀로
세웁니다. 발동 종목이 없는 날은 고정 코드로 대체하지 않고 건너뛴 사실을 남깁니다.

사용자에게 보이는 동작 변화는 없습니다.

---

전체 diff: v0.51.1...v0.52.0

v0.51.1 — 출력 문구가 사실과 다르던 7건

v0.48.0~v0.51.0 다섯 릴리스를 리뷰한 결과입니다. 값 계산은 전부 맞았고, 고친 것은
모두 표 아래 설명·안내 문구가 API의 실제 동작과 어긋나던 자리입니다. 숫자를 믿고
문구를 오해하던 케이스라 조용히 틀리는 쪽에 가깝습니다.

대차잔고 상위가 기본 호출에서 늘 비어 있었습니다

get_stock_lending(view="balance_rank")를 날짜 없이 부르면 장중 내내
"데이터가 없습니다"만 나왔습니다. 이 조회는 당일 집계를 장중에 주지 않는데
기준일 기본값이 오늘이었던 탓입니다(2026-08-14 실측: 8/14 0행 / 8/13 50행).
게다가 안내 문구는 거래일을 두고 "휴장일일 수 있습니다"라고 엉뚱한 원인을 댔습니다.

이제 날짜를 지정하지 않은 호출만 전 거래일로 한 번 물러서고, 물러섰다는 사실을
각주로 밝힙니다. 사용자가 지정한 날짜는 그대로 둡니다.

VI 발동횟수는 "당일 총 횟수"가 아닙니다

get_vi_stocks의 횟수 컬럼을 당일 총 발동 횟수로 설명하고 있었습니다. 실제로는
그 행의 발동 시점까지 두 거래소를 합쳐 몇 번째인지를 세는 누적 순번입니다
(영풍 000670 실측: 08:09:23 NXT→1, 09:09:09 NXT→2, 09:09:09 KRX→3).
이른 시각 행만 본 경우 3번 발동한 종목을 1번으로 읽게 됩니다.

나머지

• 대차잔고 상위의 "51위 아래는 조회되지 않습니다"는 사실과 다릅니다 — 받지 않을 뿐
  조회는 됩니다. 문구를 고치고, 잘림 각주가 기본 호출마다 뜨던 조건도 바로잡았습니다.
• 같은 조회가 stock_code·from_date를 조용히 버렸습니다. 이제 무시했다고 알리고,
  한 종목의 추이는 view=trend로 안내합니다.
• 종목 시간대별 프로그램 매매의 빈 결과 힌트가 "기준일을 확인해 주세요"였습니다.
  이 조회는 날짜를 고를 수 없어 재시도해도 달라지지 않습니다 — 안내를 고쳤습니다.
• get_program_trading(view="date_rank")의 top이 50에서 20으로 조용히 깎였습니다.
  깎았으면 출력에 밝힙니다.

검증

게이트 4종(check·typecheck·test·build) 초록, 테스트 634건. 새 테스트 12건은 전부
실패 주입으로 확인했습니다 — 옛 코드에서 12개가 모두 실패합니다. 바뀐 tool 3종은
실서버 스윕 13경로로 렌더까지 눈으로 확인했습니다(unexpected_errors=0).

tool 수는 49개 그대로입니다.

v0.51.0 — 익일 결제 예정 건별 명세

get_account_balance에 view=settlement 모드를 추가했습니다 (키움 kt00008).
다음 결제일에 결제될 체결을 종목·수량·단가·수수료·제세금·정산금액으로 쪼개 보여줍니다 —
기존 summary의 D+1/D+2 추정예수금이 왜 그 값인지를 설명하는 드릴다운입니다.

tool 수는 50 그대로입니다. 새 축을 기존 tool의 모드로 붙이는 관례를 따랐습니다.

이 조회의 시점 규칙

체결 당일에는 0행이고 다음 영업일에야 잡힙니다. 8/13 체결분이 8/13에는 0행이었고
8/14에 2행으로 왔습니다. 빈 결과는 오류가 아니라 조회 시점 안내를 함께 냅니다.

코드로 못박은 함정

• 결제일은 키움이 준 값을 그대로 씁니다. 체결일+2영업일로 계산하면 어긋납니다 —
  2026-08-13 체결의 결제일은 8/17이 아니라 8/18입니다(8/15 광복절이 토요일이라
  8/17이 대체공휴일).
• 정산금액은 매도(수취)·매수(지불)가 둘 다 양수로 옵니다. 부호로 방향을 읽으면
  틀리므로 구분 열로 읽도록 각주를 달았습니다.
• 제세금은 소득세·농어촌특별세·거래세·주민세 4갈래를 합산해 싣고 각주로 분해를 밝힙니다.

참고

지난 결제 내역 전체는 get_transactions(kt00015)를 쓰세요 — 이 모드는 다음 결제일
하루치만 보여줍니다. kt00015가 실전 전용(모의 미지원)인 것과 달리 이 모드는
모의투자에서도 동작합니다.

v0.50.0 — 날짜를 지정하는 프로그램 매매 상위, 그리고 VI 종목 조회가 늘 비어 있던 문제 (v0.49.1~v0.50.0 누적 발행)

v0.49.1이 아직 발행 전이라 두 버전을 함께 냅니다. tool 수는 49 그대로입니다.

고쳐진 것 — VI 발동 종목을 종목으로 조회하면 늘 비어 있었습니다 (v0.49.1)

get_vi_stocks에 stock_code를 주면 그 종목이 실제로 VI에 걸렸어도 언제나
"발동 내역이 없습니다"가 나왔습니다. 서버가 통합(KRX+NXT) 기준으로 조회하면서 종목코드에는
거래소 표시를 붙이지 않아, 키움이 오류 대신 빈 결과를 돌려주던 조합이었습니다.
오류가 아니었기 때문에 그동안 아무 신호도 없었습니다.

시장 전체 조회(stock_code 없이)는 원래 정상이었습니다 — 영향은 종목을 지정한 조회뿐입니다.

같이 고친 것:

• market과 종목의 시장이 어긋나도 조용히 비었습니다. 코스닥 종목에 market="kospi"를
  주면 빈 결과였습니다. 종목을 지정하면 시장 필터는 의미가 없으므로 이제 무시합니다.
• 표에 거래소 칸이 생겼습니다. 통합 조회에서는 같은 종목이 KRX와 NXT에서 따로 VI에
  걸리므로 한 종목이 여러 행으로 옵니다(발동 시각까지 같은 경우도 있습니다). 구분이 없으면
  중복 행처럼 보였습니다. 발동 횟수는 두 거래소를 합친 당일 횟수입니다.

v0.49.0 노트에서 "VI 발동 종목 조회 한 곳만 판정을 미뤘고 다음 장중에 확인한다"고 적었던
자리입니다. 확인해 보니 감사 대상 중 유일한 실제 누락이었습니다.

새 view — get_program_trading view=date_rank (v0.50.0, 키움 ka90004)

프로그램 매매 상위 종목은 지금까지 당일만 볼 수 있었습니다. "지난주 금요일에 프로그램이
무엇을 샀나"는 종목을 미리 알고 있을 때만 우회해서 답할 수 있었는데, 이제 날짜를 지정합니다.

기본 view(top)와 다른 점:

• 과거 날짜를 지정할 수 있습니다 (base_date).
• 매수와 매도가 한 행에 나옵니다 — 순매수만이 아니라 양쪽 금액과 수량을 함께 봅니다.
• 거래비중이 새로 나옵니다 — 그 종목의 전체 거래에서 프로그램 매매가 차지한 비율입니다.
  같은 순매수 규모라도 거래비중이 26%인 종목과 1%인 종목은 의미가 다릅니다.

당일 순위는 기존 view=top이 더 정확합니다. 그쪽은 키움 서버가 집계한 순위를 그대로
받지만, 이 view가 쓰는 자료는 순위가 아니라 시장 전체를 종목별로 나열한 것이라 서버가
정렬해 주지 않습니다. 그래서 이 서버가 받아 온 범위 안에서 직접 순위를 매깁니다 —
표 아래에 그 사실과 범위를 밝힙니다. 실측으로 프로그램 매매대금의 99% 이상이 조회 범위에
들어오지만, 원리상 범위 밖의 종목이 빠질 수 있어 상위 20종목까지만 보여줍니다.

시장은 코스피/코스닥 중 하나를 골라야 합니다(전체 조회를 제공하지 않는 자료입니다).
금액은 백만원, 수량은 천주 단위이며 한 행 안에서 단위가 갈리므로 표에 각주로 밝힙니다.

알아 두면 좋은 것

• view=date_rank는 시장 전체를 여러 번에 나눠 받아오므로 응답이 20초 안팎으로 느립니다.
  다른 view는 종전과 같습니다.
• 프로그램 매매가 전혀 없는 종목이 시장의 3분의 2 가까이 되는데, 이들은 순위에서 제외합니다.

전체 변경: #89 ·
#90