XingAPI로 주식 DB를 만들 때 가장 위험한 실수는 이름이 비슷한 TR을 일봉 데이터로 가정하고 저장하는 일입니다. 요청이 성공하고 행이 돌아와도, 그 값이 시간대별 체결인지 일봉인지, 수정 기준이 무엇인지, 연속조회가 끝난 상태인지 확인하지 않으면 백테스트에 쓸 수 없는 데이터가 쌓일 수 있습니다.
이 글은 기존 XingAPI 기반의 32비트 수집 환경을 대상으로 합니다. 특정 TR을 복사해 실행하는 코드 대신 로그인·TR 명세·이벤트 응답·원본 보관을 확인하는 절차를 정리합니다. 설치 버전과 계정 권한에 따라 달라지는 실제 요청 코드는 모의 또는 소량 조회에서 직접 검증해야 합니다.
이 글의 핵심
- XingAPI 수집기는 32비트 환경을 분석 환경과 분리해 운영합니다.
- TR 이름만으로 데이터 주기를 추정하지 않고 입력·출력 명세를 먼저 확인합니다.
- 연속조회와 이벤트 수신이 끝난 뒤에만 응답을 원본으로 저장하고 품질을 검사합니다.
이 글이 다루는 범위
LS증권에는 별도의 OPEN API 서비스도 있습니다. 이 글은 App Key·OAuth 기반 OPEN API가 아니라, 기존 XingAPI 기반 수집 환경을 정리합니다. 두 방식은 인증·요청·응답 구조가 다르므로 하나의 코드 예제에 섞지 않습니다.
XingAPI 사용 등록이 OPEN API 신청의 선행 조건으로 안내되는 점은 확인할 수 있지만, 이는 두 인터페이스의 실행 방식이 같다는 뜻은 아닙니다. 신규 REST 환경이 필요한 경우에는 OPEN API의 최신 가이드를 별도로 확인합니다. LS증권 OPEN API 이용 안내
시작은 로그인보다 TR 명세 확인이다
수집할 데이터가 일봉인지, 분봉인지, 체결 데이터인지에 따라 선택해야 할 TR과 저장 방식이 달라집니다. 따라서 ‘차트처럼 보이는 응답’이 아니라 다음 항목을 도움말에서 먼저 확인합니다.
| 확인 항목 | 확인할 질문 |
|---|---|
| 데이터 주기 | 일·주·월·분·체결 중 무엇을 반환하는가 |
| 입력값 | 종목코드, 기간, 수정 기준, 연속조회 조건은 무엇인가 |
| 출력값 | 날짜·시가·고가·저가·종가·거래량 필드가 각각 무엇을 뜻하는가 |
| 정렬 순서 | 최신순인지 과거순인지, 페이지 사이에 중복이 생기는지 |
| 연속조회 | 다음 페이지 요청에 넘길 키와 종료 조건은 무엇인가 |
| 제한 | 요청 가능 횟수와 제한 초과 시 동작은 무엇인가 |
기존 글에서 특정 TR을 일봉 차트로 단정하고 거래량 필드를 확정하지 못한 채 저장하던 부분은 제거했습니다. 실제 사용 중인 XingAPI 도움말에서 TR 명세를 확인하고, 한 종목의 짧은 기간을 먼저 조회한 뒤 저장 열과 대응시키는 과정이 필요합니다.
32비트 수집 환경을 분리한다
XingAPI 기반 수집기는 기존 32비트 Python 환경을 별도로 유지합니다. 이 환경의 목적은 분석이나 전략 탐색이 아니라 로그인된 API에서 응답을 받아 원본을 남기는 일입니다.
32비트 XingAPI 환경 → 응답 원본·수집 로그 → 검증된 가격 데이터 → 분석·백테스트 환경
이 구분을 두면 API 설치·COM 등록·로그인 문제를 분석 환경과 분리할 수 있습니다. 또한 32비트 환경에서 지원이 어려운 분석 패키지를 억지로 함께 관리할 필요가 없습니다.
수집기는 다음 상태를 순서대로 확인합니다.
- XingAPI 로그인과 연결 상태
- 요청할 TR의 입력값과 응답 필드
- 요청 가능 횟수와 연속조회 종료 조건
- 이벤트 수신 뒤의 행 수·날짜 범위
- 원본 저장과 OHLCV 품질 검사
각 단계를 통과하지 못하면 다음 종목 요청으로 넘어가지 않고, 실패 사유를 로그에 남기는 것이 좋습니다.
연속조회는 ‘행 수’가 아니라 ‘끝 조건’으로 판단한다
한 번의 응답에 모든 기간이 들어오지 않는 경우가 있습니다. 이때 첫 페이지의 행 수가 충분해 보여도, 다음 페이지가 남아 있거나 반대로 이미 종료됐을 수 있습니다. 반복 수를 임의로 정하는 대신 API가 정의한 연속조회 키와 종료 신호를 기준으로 처리해야 합니다.
| 단계 | 남길 기록 | 확인할 실패 |
|---|---|---|
| 첫 요청 | 종목·기간·TR·요청 시각 | 입력값 오류, 로그인 만료 |
| 첫 응답 | 행 수·날짜 범위·연속 여부 | 빈 응답, 주기 오해 |
| 다음 요청 | 이전 연속 키·페이지 번호 | 같은 페이지 반복, 키 누락 |
| 종료 | 마지막 날짜·총 행 수 | 일부 기간 누락 |
| 저장 | 원본 경로 대신 논리적 수집 ID | 중복·덮어쓰기·수정 기준 혼합 |
본문과 로그에 개인 PC의 설치 경로나 계정 정보는 남기지 않습니다. 수집 이력은 source, symbol, requested_range, collected_at처럼 다른 환경에서도 의미가 유지되는 값으로 기록합니다.
저장 전에 반드시 비교할 네 가지
응답을 데이터베이스에 넣기 전에 아래 항목을 검사합니다.
symbol + trade_date가 중복되지 않는가- 날짜가 요청 기간 안에 있고 정렬 기준이 일정한가
low ≤ open/close ≤ high관계가 성립하는가- 거래량·가격 단위·수정 기준이 TR 도움말과 일치하는가
이 검사는 XingAPI만의 문제가 아닙니다. 데이터원별 종목코드와 수정주가 기준이 다르면 같은 회사라도 가격 그래프가 달라질 수 있습니다. yfinance로 국내 주식 데이터 받기: 수정주가·결측·티커를 먼저 확인하는 법처럼 수집 이후가 아니라 저장 전에 기준을 확인해야 합니다.
실행 전 체크리스트
- [ ] 32비트 XingAPI 수집 환경을 분석 환경과 분리했는가
- [ ] 실제 사용할 TR의 주기·필드·연속조회 조건을 현재 도움말에서 확인했는가
- [ ] 한 종목·짧은 기간으로 응답과 저장 열의 대응을 점검했는가
- [ ] 응답 원본, 요청 이력, 오류·재시도 로그를 함께 남기는가
- [ ] 개인 설치 경로, 계정·인증 정보가 코드·로그·본문에 노출되지 않는가
이 글은 XingAPI의 특정 TR을 실행 검증한 코드 안내가 아닙니다. 계정 권한, 설치 버전, 로그인 상태, API 명세에 따라 결과가 달라질 수 있으므로 실제 수집 전에는 모의 또는 소량 조회로 응답과 저장 결과를 확인해야 합니다.
이 글은 API 기반 데이터 수집의 환경과 검증 절차를 설명하기 위한 교육용 자료입니다. 서비스 사용 조건과 API 명세는 공식 안내에서 다시 확인해야 하며, 실제 투자 판단과 책임은 투자자 본인에게 있습니다.