최근 개인 포트폴리오를 조금 더 일관된 기준으로 점검하기 위해 키움 REST API를 사용하는 작은 서비스를 만들었습니다. 흔히 이런 프로젝트를 자동매매라고 부르지만, 현재 시스템의 중심은 주문 자동화가 아니라 투자 판단 보조입니다. 계좌와 시장 데이터를 모으고, 정해 둔 규칙으로 분석한 뒤, 사람이 최종 결정을 내릴 수 있도록 결과를 정리하는 데 초점을 맞췄습니다.
구성 목표
- 보유 종목, 예수금, 최근 체결 내역을 한 번에 조회한다.
- NAVER 4주를 하나의 기준 단위로 삼아 후보 종목과의 비중 변화를 비교한다.
- 규칙 기반 분석과 선택적인 AI 분석을 분리한다.
- 분석 결과는 웹 화면과 Discord에서 확인하되 실제 주문은 기본적으로 실행하지 않는다.
전체 요청 흐름
사용자
→ Nginx HTTPS
→ FastAPI
→ 키움 REST API 조회
→ SQLite 스냅샷 저장
→ 전략 및 리스크 분석
→ 웹 화면·Discord 결과 전송애플리케이션은 Amazon Linux 2023 ARM64 EC2에서 동작합니다. Nginx가 HTTPS와 리버스 프록시를 담당하고 FastAPI는 로컬 포트에서만 요청을 받습니다. 데이터베이스는 개인용 규모에 맞춰 SQLite를 사용했습니다. 별도 RDS나 Redis를 추가하지 않아 고정 비용과 운영 복잡도를 줄였습니다.
HTTP 계층과 판단 로직을 분리한 이유
API 라우터 안에서 계좌 조회, 전략 계산, 알림, 주문 판단을 모두 처리하면 변경 범위가 빠르게 커집니다. 그래서 HTTP 요청은 api, 업무 흐름은 service, 투자 규칙은 strategy, 주문 안전장치는 trading 계층으로 나눴습니다. 이 구조에서는 키움 API 응답 형식이 바뀌더라도 전략 코드를 최대한 건드리지 않을 수 있습니다.
NAVER 4주를 기준 단위로 사용한 이유
보유 수량과 후보 종목 가격이 매번 달라 단순 수익률만으로 교환 판단을 설명하기 어려웠습니다. 그래서 NAVER 4주를 1 Unit으로 정의하고, 같은 기간에 매수·매도한 후보 종목을 체결일과 금액 기준으로 연결합니다. 키움 체결 데이터에 사용자의 실제 의도가 담긴 연결 ID가 있는 것은 아니므로 결과는 어디까지나 교환 이력 추정입니다.
AI는 보조 수단으로만 사용
Bedrock 또는 OpenAI 분석을 선택적으로 실행할 수 있지만, AI 응답이 주문 실행 조건이 되지는 않습니다. 수집하지 못한 재무·뉴스 데이터는 임의로 채우지 않고 누락 상태로 표시합니다. 규칙 기반 결과와 AI 설명을 분리해 어느 단계에서 판단이 만들어졌는지 추적할 수 있도록 했습니다.
운영하면서 중요했던 점
/health를 제외한 API는 Bearer Token 인증을 적용했습니다.- 토큰과 계좌 정보는 URL이나 Git 저장소에 남기지 않습니다.
- EC2 배포는 브랜치명이 아닌 정확한 Git 커밋 SHA를 사용합니다.
- 웹 콘솔은 비밀번호, TOTP, CSRF, 서버 측 세션으로 보호합니다.
- 웹 화면에서는 주문 실행 기능을 제공하지 않습니다.
마무리
개인 프로젝트일수록 기능을 많이 넣는 것보다 경계를 분명히 하는 것이 중요했습니다. 현재 시스템은 데이터를 모으고 판단 근거를 정리하는 도구이며, 실제 투자 결정과 주문 책임은 사용자에게 있습니다. 다음 글에서는 이 구조에 주문 기능을 추가하면서도 실계좌 오주문을 막기 위해 어떤 안전장치를 겹겹이 배치했는지 정리하겠습니다.
이 글은 시스템 설계 기록이며 특정 종목의 매수·매도를 권유하지 않습니다.