수고하십니다..

# 예스스탁 지원팀 추가 문의

## A. 틱봉(N틱) 카운팅 기준 (신호값이 실제 차트와 다른 문제 확인용)

1. `ReqChartEx`로 `period=CHART_PERIOD_TICK, cycle=N`을 요청해서 받는 과거 이력 틱봉의 "N틱" 카운팅 기준이, 사용자가 차트 화면에서 직접 "N틱봉"으로 설정했을 때와 완전히 동일한 기준입니까?

2. 이때 "1틱"으로 세는 기준은 모든 체결 이벤트 1건입니까, 아니면 가격이 실제로 변동된 체결만 1틱으로 셉니까? (같은 가격 연속체결도 각각 별도 틱으로 카운트되는지)

3. `chartEx.GetHigh(1, idx)` / `GetLow(1, idx)` / `GetSDate(1, idx)` / `GetSTime(1, idx)`에서 `idx=0`이 가장 최근(마지막) 봉이 맞습니까, 아니면 가장 오래된 봉입니까? (인덱스 방향 확인)

4. 같은 종목·같은 N틱 설정이라도, 실시간 체결로 로컬에서 직접 합성한 봉(TickBarBuilder 방식)과 `ReqChartEx`로 받아온 과거이력 봉이 경계 부근(워밍업→실시간 전환 시점)에서 미세하게 어긋날 가능성이 있습니까? 이런 경우 두 소스를 일치시키는 권장 방법이 있습니까?

## B. 객체 수 1000개 제한과 크래시 관련

5. 이전 답변에서 "스팟은 하나의 전략식에서 총 1000개까지 객체 사용 가능"이라고 하셨는데, 여기서 "객체"의 정확한 기준이 무엇입니까? (예: `ReqChartItem` 인스턴스, `SetTimer` 등록 개수, 스크립트 내 생성한 모든 JS 객체 포함 여부 등)

6. `ReqChartEx` 요청을 반복적으로(예: 2초 주기로 계속) 보내고 응답을 받아 처리한 뒤, 해당 `ReqChartItem`/응답 객체를 스크립트에서 더 이상 참조하지 않게 되면 자동으로 해제(GC)되는지, 아니면 명시적으로 해제하는 API가 별도로 있습니까?

7. 하나의 스크립트에서 틱데이터를 실시간으로 계속 수신하면서, 동시에 주기적으로 과거 이력(`ReqChartEx`)을 반복 재조회하는 구조를 쓸 경우, 장시간(수십 분~수시간) 실행 시 알려진 메모리 누수나 크래시 사례가 있습니까? 권장하는 안전한 재조회 주기/방식이 있습니까?

8. 스크립트가 특별한 에러 로그 없이 HTS 프로세스 자체가 다운되는 경우, 원인을 추적할 수 있는 별도의 크래시 덤프/시스템 로그가 있습니까? (저희 쪽 스크립트 로그에는 마지막 정상 동작만 남고 에러 메시지가 없어서 원인 파악이 어렵습니다)

감사합니다...