기관계 수급 세부 주체별 자동 수집, 무료로 가능한 경로가 있을까?
기관 수급을 볼 때 연기금, 사모, 금융투자, 투신처럼 세부 주체가 나뉘어 보이면 훨씬 해석이 쉬워집니다. 그래서 종목별·날짜별 데이터가 계속 쌓이도록 구글 스프레드시트에 자동 반영하고 싶다는 수요가 자연스럽게 생깁니다. 다만 실제 구현에서는 pykrx가 원하는 형태로 안 나오거나, 일부 API는 값이 이상하게 들어가거나, 어떤 API는 아예 그 항목을 주지 않는 경우가 있어 막히기 쉽습니다.
이 글에서는 “기관계 수급의 세부 주체별 원자료를 공짜로, 끊김 없이, 자동으로 시트에 붙이는 지름길”이 있는지에 초점을 맞춰, 어떤 방식이 현실적인지 차근차근 정리해 보겠습니다. 특히 무료 여부, 데이터가 실제로 어디서 나오는지, 구글 스프레드시트 자동 업데이트가 가능한지를 중심으로 보시면 됩니다.
먼저, 원하는 출력 형태를 분명히 해두는 것이 중요합니다
질문에서 원하는 결과는 대체로 다음과 같은 형태로 이해할 수 있습니다. 날짜, 종목, 연기금, 사모, 금투, 투신 같은 열이 있고, 종목별로 날짜가 쌓이면서 계속 업데이트되는 구조입니다. 즉 단순히 “기관 합계”가 아니라, 기관 내부의 세부 주체를 구분해 저장하는 파이프라인이 필요합니다.
| 날짜 | 종목 | 연기금 | 사모 | 금투 | 투신 |
|---|---|---|---|---|---|
| 2024-01-02 | 예시 종목 | 값 | 값 | 값 | 값 |
이런 구조를 만들려면 단순히 “값을 가져오는 것”보다 어디서 가져오고, 어떤 단위로 정제하며, 어디에 저장할지가 더 중요합니다. 한 번만 조회하는 방식이 아니라 주기적으로 쌓이는 방식이어야 하므로, 데이터 구조와 자동화 방식이 같이 설계돼야 합니다.
무료로 가능한지 볼 때, 먼저 확인할 포인트
현재 상황에서 핵심은 공식적으로 접근 가능한 공개 경로가 있느냐입니다. 한국거래소 관련 문서와 연구자료에는 금융기관과 시장 관련 맥락이 보이지만, 질문에서 원하는 수준의 세부 주체별 수급 데이터를 그대로 무료로 안정 제공하는지까지는 이 자료만으로 단정하기 어렵습니다. 그래서 실제 구현 가능성은 “공식 공개 페이지나 제공 방식이 있는지”를 먼저 확인하고, 그 다음에 자동화 가능성을 판단하는 순서가 안전합니다.
질문에 적어주신 것처럼 pykrx가 원하는 형태로 잘 안 맞을 수 있고, 키움 REST API에서 값이 이상하게 들어가거나, 다른 증권사 계열 API에서 아예 해당 항목이 제공되지 않는 경우도 있을 수 있습니다. 이런 경우에는 API 자체보다 웹페이지 공개 데이터나 데이터 제공 페이지를 다시 살펴보는 방식이 더 현실적일 수 있습니다.
가능한 경로는 보통 세 가지로 나뉩니다
세부 주체별 수급 데이터를 시트에 자동 반영하려면 보통 아래 세 가지 경로를 비교하게 됩니다. 각각 장단점이 다르기 때문에, “무료”와 “안정성”을 동시에 만족하는지 살펴보는 것이 중요합니다.
- 공식 API나 공개 데이터: 구조가 명확하면 가장 다루기 쉽지만, 원하는 세부 항목이 빠져 있을 수 있습니다.
- 웹페이지 크롤링: 화면에 보이는 값은 얻을 수 있을 가능성이 있지만, 페이지 구조 변경이나 차단에 취약할 수 있습니다.
- 중간 서버 + 스프레드시트 연동: 파이썬으로 수집한 뒤 시트에 쓰는 방식이라 유연하지만, 실행 환경과 주기 관리가 필요합니다.
즉, “무료로 된다/안 된다”보다 어디까지 공개돼 있고 어떤 방식으로 안정화할 수 있느냐가 더 핵심입니다. 예를 들어 구글 앱스 스크립트만으로 끝내려 하면 간단해 보이지만, 동적 페이지나 복잡한 파싱이 필요한 경우에는 한계가 생길 수 있습니다.
반대로 파이썬 중간 서버를 쓰면 수집과 정제는 자유로워지지만, 무료 범위에서 운영하려면 실행 주기, 저장소, 실패 재시도 같은 부분을 같이 설계해야 합니다. 이런 이유로 실제 운영에서는 수집은 파이썬, 표시와 공유는 구글 스프레드시트 조합이 자주 거론됩니다.
구글 스프레드시트 자동 반영은 어떻게 붙이나요?
구글 스프레드시트에 자동 반영하는 방법은 대체로 두 갈래입니다. 하나는 앱스 스크립트로 직접 받아오는 방식이고, 다른 하나는 외부 파이썬 프로그램이 시트에 써 넣는 방식입니다. 질문하신 IMPORTXML 같은 방식은 간단한 정적 페이지에서는 도움이 될 수 있지만, 실제 금융 데이터처럼 구조가 자주 바뀌거나 동적 로딩이 섞인 경우에는 안정성이 떨어질 수 있습니다.
그래서 실무적으로는 다음 흐름이 많이 거론됩니다. 먼저 공개 페이지나 API에서 데이터를 가져온 뒤, 날짜와 종목 기준으로 정리합니다. 그 다음 이미 들어간 행은 건너뛰고, 새 날짜나 새 종목만 추가하는 식으로 시트에 누적합니다. 이렇게 하면 종목별·날짜별 업데이트가 비교적 깔끔해집니다.
- 1단계: 수집 대상 페이지 또는 API 확인
- 2단계: 연기금·사모·금투·투신 항목 분리
- 3단계: 날짜·종목 기준으로 정규화
- 4단계: 시트에 append 방식으로 기록
- 5단계: 주기 실행으로 갱신
이때 앱스 스크립트는 편리하지만, 외부 사이트 구조가 복잡하면 직접적인 HTML 파싱만으로는 한계가 있습니다. 반면 파이썬은 requests, pandas, BeautifulSoup 같은 도구로 정리하기가 쉬워서, 수집·정제는 파이썬, 공유와 확인은 스프레드시트로 나누는 편이 더 안정적일 수 있습니다.
안정성은 데이터 소스보다 운영 방식에서 갈리는 경우가 많습니다
무료로 구현할 때 가장 자주 부딪히는 문제는 데이터 자체보다 차단, 페이지 구조 변경, 빈값 또는 이상값입니다. 질문에서 언급하신 키움 REST API의 값 이상 문제도 이런 범주로 볼 수 있습니다. 따라서 “한 번 돌아가는 코드”보다 “계속 유지되는 구조”를 목표로 잡는 것이 좋습니다.
안정성을 높이려면 몇 가지 습관이 도움이 됩니다. 첫째, 원본을 바로 덮어쓰기보다 원본 저장 시트와 정리 시트를 분리합니다. 둘째, 수집 실패 시 이전 값을 유지하고 로그를 남깁니다. 셋째, 날짜 형식과 종목 코드 형식을 통일합니다. 넷째, 가능하면 공식 공개 페이지나 문서형 소스를 우선합니다.
또한 무료 환경에서는 실행 횟수 제한이나 외부 호출 제한을 고려해야 합니다. 앱스 스크립트만으로 자동화하면 편리하지만, 장기적으로는 중간 서버가 더 유연할 수 있습니다. 반대로 파이썬 서버를 무료로 돌리더라도, 서비스가 휴면되거나 실행 시간이 제한되면 누락이 생길 수 있으니 주기와 재시도 로직을 함께 넣는 편이 좋습니다.
실제로 물어봐야 할 질문을 정리하면 더 빨리 답이 나옵니다
이 주제는 “가능하냐”보다 “어떤 경로가 현재도 안정적으로 돌아가느냐”가 중요합니다. 그래서 구현 방향을 찾을 때는 아래 질문으로 쪼개서 보면 좋습니다. 이런 식으로 나누면 pykrx, 크롤링, 앱스 스크립트, 중간 서버 중 무엇이 맞는지 판단이 쉬워집니다.
- 세부 주체별 수급이 공식 또는 공개 페이지에 실제로 표시되는가
- 그 값이 API 형태로 열려 있는가, 아니면 화면 파싱이 필요한가
- 구글 스프레드시트에 바로 넣을지, 중간 서버를 둘지
- 주기 갱신 시 차단이나 구조 변경에 어떻게 대응할지
- 무료 범위에서 어느 정도까지 유지 가능한지
이 질문에 답이 모이면, 원하는 열 구조에 맞춰 종목별·날짜별로 쌓는 방식도 훨씬 구체화됩니다. 즉 “기관 합계” 대신 “연기금/사모/금투/투신”을 분리해 넣는 작업은 데이터 소스 확인, 정제, 저장 방식이 맞물려 있어야 합니다.
마지막으로 정리하면, 무료로 구현할 가능성은 있지만 핵심은 단순한 API 유무보다 세부 주체별 원자료를 어디서 어떻게 얻느냐에 달려 있습니다. 가장 현실적인 흐름은 공개 데이터 확인 → 파싱 가능성 검토 → 파이썬 정제 → 구글 스프레드시트 자동 반영 순서로 접근하는 방식입니다. 원하시면 다음 단계로는 시트 컬럼 설계 예시나 파이썬→구글시트 연결 절차를 더 구체적으로 정리해 볼 수 있습니다.
0 댓글