주식이
v2.8 · 22판최종 갱신 2026-10-07api 연결 안 됨

주식이 — 서비스 구조 & 패치노트

상한가 다음 날부터 5분봉 CCI 눌림에서 사서 과매수 꺾임에 파는 매매를, 각자 본인 한투 계좌·앱키로 자동 실행하게 해주는 서비스입니다. 이 페이지는 무엇이 실제로 돌고 무엇이 아직 아닌지를 있는 그대로 적습니다.

1. 시스템 맵

브라우저jusike.kr엣지 프록시DNS · 프록시 · TLS프론트Next.js · shadcn · 화면만API 서버api · worker · DB한국투자증권REST · WebSocket오브젝트 스토리지cdn.jusike.kr · 파일리버스 프록시 :443 → api :8000 · worker(07:50~15:40) · 이벤트 테이블 → SSE

프론트에는 비밀이 없습니다. 로그인·설정·조회는 api, 장중 시세·판정·주문은 worker 프로세스가 맡고, 둘은 하나의 DB 를 공유합니다. 이미지·영상 같은 큰 파일은 오브젝트 스토리지(cdn.jusike.kr)에 둡니다.

2. 역할별 여정

👤 방문자
  1. /apply 에서 이메일·이름 제출
  2. 관리자 승인 대기
  3. 임시 비밀번호를 직접 전달받음
📈 사용자
  1. 로그인 → 비밀번호 변경
  2. 본인 한투 앱키·계좌 등록
  3. 연결 테스트 4/4
  4. 모드 선택: 관제 → 반자동 → 자동
  5. 대시보드에서 계좌 수익현황 · 보유 종목 · 매매 기록(창 안 이벤트 전부 · 규칙과 나) · 카드
  6. 매매일지에서 여태 사고판 종목과 실현손익
🛡️ 관리자
  1. 가입 승인 · 임시비밀번호 1회 표시
  2. 사용자 정지·역할
  3. 워커·WS·커버리지 감시
  4. 시세키 지정 · 전체 비상정지
  5. 알림 받는 곳(텔레그램 · 채널톡 방) 켜고 끄기 · 시험 보내기

3. 매매 파이프라인

상한가 이벤트(정규장 상한가 마감 · 대금 100억 · 배수 10)→감시목록 D+1~D+6→장세: 코스피 > 60일선 이틀 연속이면 사는 날→5분봉 (종료시각 표기)→2차신호 EMA 10/60 데드크로스 · 3차신호 RSI/OBV→CCI 과매도(<−100) → 반등 · 1차는 ≤ −150→종목당 1,500만 고정: 1차 250만 · 물타기 −1% (500만 · 750만) · 최대 10종목→필터 없는 규칙이 이미 끝난 종목은 안 삼→과매수(>100) 후 CCI 꺾임 · 순익 ≥ +1% 매도→9일째 09:00 기한청산

계산은 종목당 한 번, 판정은 계좌별. 봉·지표·신호는 시장 데이터라 누가 보든 같습니다. 규칙 정본은 원저자의 백테스트 엔진(사양 v2 · 2026-09-14)이고, 웹은 그 엔진을 그대로 불러 「다음 봉 시가에 무엇을 하나」만 묻습니다. 계좌마다 다른 건 원장입니다. 돈이 모자라 넘긴 자리는 원장에 남고, 그 다음 판정은 실제로 든 것 기준으로 갑니다.

4. 인증·키 파이프라인

  • 비밀번호는 서버에서만 argon2id 로 검증. 세션은 서버 테이블 · HttpOnly 쿠키 12시간 · 5회 실패 10분 잠금
  • 한투 앱키·시크릿은 AES-256-GCM 으로 DB 에, 마스터키는 서버 로컬 파일에만. 화면엔 끝 4자리
  • 프론트엔 어떤 비밀도 없습니다. 브라우저는 api.jusike.kr 에만 말을 겁니다

5. 모드와 안전장치

관제
신호·판정만 보여준다. 주문 0건. 페이퍼 단계.
반자동
신호가 뜨면 카드. 사람이 누르면 서버가 규칙을 다시 검증하고 보낸다.
자동
프로그램이 낸다. 확인 문구를 입력해야 켜지고, 비상정지 버튼이 항상 보인다.

비상정지는 두 겹(계좌·전체)입니다. 매도선은 「목표가」가 아니라 최저 방어선입니다 — 그 값에 미리 팔면 백테스트가 잡은 수익의 대부분을 놓칩니다.

6. 실동작 vs 준비중

기능상태설명
상한가 이벤트(정규장 종가) · 감시목록(D+1~D+6)✅ 실동작매일 07:50 정규장 일봉 → 이벤트원장 → 감시목록. 시간외에서만 상한가인 종목은 제외(2026-09-16)
매매 기록 화면 (창 전부 · 규칙과 나 · 툴팁 사다리 · 날짜 이동)✅ 실동작2026-09-15. 창 안 이벤트 전부(산다·안 산다) · 종목 툴팁에 1·2·3차 시각·가격·평단·익절선 + 내 체결 · 30일 안 지나간 날 재생 · 3년 1,424건 불변식 검사
계좌 수익현황 · 보유종목현황 (증권사 잔고 그대로)✅ 실동작2026-09-29. 총평가금액 · 평가손익 · 수익률 · 매입금액 · 평가금액 · 예수금(이틀 뒤 정산 기준). 보유 종목은 총매수금액 · 차수별 누적평단 · 보유일수. 장중 1분마다, 장 밖에는 화면을 열 때 새로 받는다
매매일지 (총 매수 · 총 매도 · 실현손익 · 수익률)✅ 실동작2026-09-29. 여태 사고판 종목을 한 줄씩. 합계와 실현손익은 증권사 매매손익 그대로 · 가를 수 없으면 「추정」이라고 적는다. 실제 원장 21줄과 증권사 18줄이 원 단위까지 맞는 것을 확인
저녁 배치 · 다음 거래일 기준 화면✅ 실동작평일 저녁 8시 10분에 다음 거래일 후보를 만든다. 저녁의 일봉은 확정 전이라 저장하지 않고, 상한가에 닿은 종목만 정규장 분봉으로 판정한다. 아침 배치가 확정된 일봉으로 다시 만든다. 9/29 첫 실행 · 9/30 아침 대조에서 후보가 같았다
시스템 알림 (관리자 텔레그램 · 채널톡 방)✅ 실동작2026-09-30. 받는 곳을 관리자가 시스템 화면에서 정한다. 켜진 곳 전부에 한 번씩 · 한 곳이 실패해도 다른 곳은 간다. 사용자별 텔레그램 연결은 없앴다
5분봉 조립(종료시각 표기) · 백필✅ 실동작실시간 틱 → 5분봉. 증권사 1분봉과 거래량까지 일치 · 빈 구간은 5분 뒤 자동 교체(R-37)
CDN 업로드 (cdn.jusike.kr)✅ 실동작API 로 올린 파일이 엣지 캐시를 거쳐 서빙. 2026-09-11 업로드→HIT 점검 통과
2차신호 · CCI 판정 (관제)✅ 실동작2026-09-11 첫 실장 완주 · 9/14 실장 2일째(감시 8종목 · 판정 600봉). 주문 0 — 페이퍼 진행 중
장세 필터 (코스피 60일선 · 사양 v2)🟡 페이퍼매일 장 마감 뒤 지수를 받아 「사는 날 / 매수 쉬는 날」을 정하고 첫 매수만 막는다. 3년 백테스트에서 최대 낙폭 19.8% → 12.3%. 실제 장은 9/15 부터(그날은 쉬는 날)
반자동 카드 → 주문⚪ 준비중카드는 원장 기준(사양 v2). 첫 매수를 체결하지 않았으면 물타기 카드는 나오지 않는다. 승인·재검증·발송·체결 반영까지 코드·자동 테스트 완료. 모의투자 키로 왕복 검증 대기
자금 배분 (종목당 고정 금액 · 넘김)✅ 실동작계좌마다 종목당 상한과 최대 보유 종목 수를 정한다(기본 1,500만 · 10종목). 1·2·3차는 상한의 1/6 · 2/6 · 3/6. 현금이 모자라면 그 자리를 넘기고 원장에 남긴다. 2026-09-29 실제 체결로 금액 확인
자동 주문✅ 실동작2026-09-22 부터 실계좌에서 소액으로 주문이 나간다. 관리자 설정을 켠 계좌만. 장 마감 때 살아 있는 당일 주문은 닫고, 취소가 실패하면 기록을 남긴다(2026-09-29)
3차신호(RSI·OBV)🟡 페이퍼사양 v2(9/14)로 기본 켜짐. 3년 백테스트·리플레이 통과. 실제 장은 9/15 부터 — 실장 3거래일 대조 후 실동작으로
결제 · 공개 가입⚪ 준비중초대제. 유사투자자문 검토 후

「실동작」은 페이퍼·소액 단계를 통과한 것만 표시합니다. 워커 상태 배지는 실시간(/api/health)입니다.

7. 배포·운영

  • 웹: 프론트 호스팅 (Next.js 16 · shadcn/ui · 퍼플/다크)
  • API·DB: 단일 서버 (FastAPI · 파일 DB(WAL) · systemd · 워커는 평일 07:50 timer 기동, 15:40 자진 종료 · 저녁 배치는 평일 20:10)
  • 파일: 오브젝트 스토리지 + 엣지 캐시 (cdn.jusike.kr)
  • 보안: 엣지 프록시 · 오리진 TLS · 방화벽 22/80/443 · fail2ban · 키 전용 SSH
  • 알림: 시스템이 관리자 텔레그램과 채널톡 방에 같이 보냄 (신호·체결·기한청산·배치·워커 이상)

8. 패치노트

v2.8 · 22판2026-10-07한 종목 비중은 총자산의 15%, 운용자산은 1억까지
이전
계좌마다 「종목당 고정 금액」(기본 1,500만)이 기본이라, 작은 계좌에서는 한 종목에 자산의 대부분이 들어갔다.
이후
매수 금액은 매수 순간 총자산(현금 + 보유 원금 · 운용자산 상한 1억까지만)의 1차 2.5% · 2차 5% · 3차 7.5%. 동시 보유 10종목 한도는 그대로. 계좌 관리에서 지금 총자산 기준 예상 금액을 바로 본다.
  • worker자금방식 「비율」이 새 계좌 기본. 총자산은 운용자산 상한(기본 1억)으로 자른다. 「종목당 고정 금액」은 옵션으로 남긴다
  • web계좌 관리: 비율이면 운용자산 상한 · 동시보유 종목 수 · 지금 총자산 기준 1 · 2 · 3차 예상 금액. 계좌 카드 문구도 같이
  • api백테스트 기본 계좌도 같은 규칙(총자산 15% · 상한 1억 · 10종목). 초기자본 1억에서는 고정 1,500만과 숫자가 같다(875건 · 승률 88.5% · 연환산 +27.6%)
v2.7 · 21판2026-09-30알림은 시스템이 보낸다. 관리자 텔레그램과 채널톡 방으로
이전
알림을 사용자마다 설정 화면에서 텔레그램으로 연결해 받았다. 누가 받는지가 사용자 칸에 흩어져 있었고, 확인해 보니 모두 한 사람의 채팅으로 가고 있었다. 잔고 불일치 알림은 같은 문구가 두 번 갔다.
이후
받는 곳을 관리자가 시스템 화면에서 한 번에 정한다. 켜진 곳 전부에 한 번씩 간다. 설정 화면은 어디로 가는지만 보여 준다.
  • worker신호 · 체결 · 기한청산 · 배치 · 워커 이상 알림이 관리자 텔레그램과 채널톡 「주식이」 방에 같이 간다. 한 곳이 실패해도 다른 곳은 간다
  • web관리자 → 시스템 → 알림: 곳마다 켜고 끄기 · 채널톡 방 고르기 · 봇 이름 · 시험으로 보내기. 곳마다 마지막으로 언제 닿았는지, 실패했으면 이유가 보인다
  • web설정 화면의 텔레그램 연결과 알림 스위치를 없앴다. 알림이 어디로 가는지 안내만 남았다
  • worker잔고 불일치 알림이 두 번 가던 것을 한 번으로
v2.6 · 20판2026-09-29계좌 수익현황 · 보유종목현황 · 매매일지. 증권사 앱과 같은 숫자로
이전
화면의 예수금이 매수해도 이틀 동안 안 줄어 증권사 앱과 달라 보였다. 수익률 · 매입금액 · 총매수금액 · 차수별 누적평단 · 보유일수가 없었다. 사고판 종목은 날짜를 넘기며 찾아야 했고 총 매수 · 총 매도 금액이 없었다. 매매 기록 표는 내가 산 종목에도 규칙대로였다면의 타점을 보여 줬다.
이후
맨 위에 계좌 수익현황 여섯 칸(총평가금액 · 평가손익 · 수익률 · 매입금액 · 평가금액 · 예수금)이 증권사 앱과 같은 순서로 나온다. 보유 종목은 표로 보고 누르면 차수별로 펼친다. 매매일지는 여태 사고판 종목을 한 줄씩, 맨 위에 네 칸. 내가 산 종목의 타점은 내 체결이다.
  • web계좌 수익현황: 예수금은 이틀 뒤 정산 기준이다. 총평가금액 = 평가금액 + 예수금이 화면에서 성립한다. 수익률은 평가손익 ÷ 매입금액
  • web보유종목현황: 총매수금액 · 보유일수(거래일 기준 · 기한청산까지 남은 날)가 생겼다. 행을 누르면 차수별 체결가 · 수량 · 매수금액 · 누적평단. 합계 줄은 수익현황과 같은 숫자다
  • web장이 아닐 때 화면을 열면 잔고를 스스로 새로 받는다. 실패해도 알림을 띄우지 않고 몇 분 전 값인지 그대로 보여 준다
  • web매매일지(옛 원장): 총 매수금액 · 총 매도금액 · 실현손익 · 수익률. 종목 한 줄씩, 누르면 차수별 체결과 증권사 매매손익 줄(수수료 · 세금). 기간을 고를 수 있다. 차수 한 줄씩 보던 원장은 아래에 접혀 있다
  • api매매일지 합계는 증권사 합계 그대로다. 끝난 종목의 실현손익은 증권사 줄의 합(매수 수수료 포함). 가를 수 없는 경우와 모의 계좌는 원장으로 계산하고 「추정」이라고 적는다
  • web매매 기록: 내가 산 종목은 매수 · 매도 타점이 내 체결이다. 규칙대로였다면의 자리는 작게 따로 나온다. 넘긴 자리도 그대로 보인다
  • worker다음 거래일 기준 화면: 평일 저녁 8시 10분에 다음 거래일 후보를 만든다. 저녁에 받는 일봉은 장 마감 뒤 거래가 섞여 정규장 종가와 다르다는 걸 확인했다(9/29 저녁 · 여덟 종목 중 여섯). 그래서 그 값은 상한가에 닿은 종목을 추리는 데만 쓰고, 판정은 그 종목의 정규장 분봉으로 한다. 아침 배치가 확정된 일봉으로 다시 만들어 확정한다. 첫 저녁 실행과 다음 날 아침 대조를 본 뒤 실동작으로 올린다
  • workerR-57: 장 마감 때 살아 있는 당일 주문을 닫는다. 취소가 실패하면 기록을 남긴다. 막판에 나간 주문이 「접수」로 남아 잔고 대조에서 빠지던 문제를 고쳤다
  • worker기한청산 날짜를 셀 때 넘기거나 취소한 자리는 첫 매수일로 치지 않는다
v2.5 · 19판2026-09-29장세 필터를 끌 때 만료를 고른다. 필터가 꺼져 있어도 끝난 종목은 안 산다
이전
장세 필터는 끌 때 만료 시각을 꼭 넣어야 했고, 그 시각이 지나면 스스로 켜졌다. 9/21에 26분 만에 다시 켜진 걸 모르고 꺼져 있다고 믿었다. 필터를 끄면 「끝난 종목은 안 산다」는 장치도 같이 꺼져서, 놓친 종목을 뒤늦게 살 수 있었다
이후
끌 때 만료를 고른다: 오늘 장 마감, 직접 정한 시각, 만료 없음. 만료 없음은 누가 다시 켤 때까지 꺼져 있다. 필터가 꺼져 있어도 규칙상 이미 팔고 끝난 종목은 새로 사지 않는다
  • admin장세 필터 끄기 창에 만료 선택이 생겼다. 배지에 언제 다시 켜지는지 날짜까지 보인다. 만료 없음이면 「만료 없음」으로 나온다
  • api빈 값이나 형식이 틀린 만료로는 못 끈다. 계속 꺼 두려면 「없음」을 명시해야 한다. 깨진 값이 저장돼 있으면 필터를 켠다
  • engineR-55 확장: 필터 없이 돌린 규칙이 끝난 종목은 필터가 켜져 있든 꺼져 있든 1차를 사지 않는다. 기준선(914건 · 연 +31.6% · 최대낙폭 9.5%)은 그대로다
  • worker잔고 조회가 초당 한도에 걸리면 5초 뒤 다시 받는다. 세 번 연속 실패할 때만 경고한다
v2.4 · 18판2026-09-28화면의 금액·보유종목을 한투 앱과 똑같이 맞췄다
이전
실제 계좌와 프로그램 기록은 맞았는데 화면이 틀렸다. 보유 카드의 평단을 차수별 체결가의 단순 평균으로 계산해 한투 앱과 달랐고, 예수금·평가금액은 프로그램이 켜질 때와 첫 매수 때만 바뀌었다. 감시 기간이 지난 보유 종목은 매매 기록에서 빠졌고, 원장 화면은 차수마다 %를 그냥 더했다
이후
평단·수량·현재가·평가손익·예수금·D+2 예수금은 한투 잔고 값을 그대로 보여 준다. 장중에는 1분마다, 장 밖에는 새로고침으로 받고, 몇 분 전 값인지 같이 적는다. 매매 기록의 상태와 보유 수는 내 계좌 기준이고, 원장 화면은 이벤트 단위 실현손익(원)을 보여 준다
  • worker장중 1분마다 한투 잔고를 받아 화면용으로 저장하고 원장과 비교한다. 수량이나 평단이 두 번 연속 다르면 알린다(같은 내용은 하루 한 번). 원장은 자동으로 고치지 않는다
  • api대시보드가 한투 잔고 값을 그대로 돌려준다. 장 밖 새로고침(30초에 한 번), 원장 요약(이벤트 단위 실현손익)이 생겼다
  • web대시보드 위 다섯 칸(예수금 · D+2 예수금 · 주식 평가 · 총평가 · 평가손익)과 보유 종목 카드가 한투 앱과 같은 숫자를 보여 준다. 판정용 규칙 평단·매도선·물타선은 작게 따로 둔다
  • web매매 기록에서 감시 기간이 지난 보유 종목도 보이고, 상태가 내 계좌 기준이 됐다. 규칙은 샀는데 계좌는 안 산 종목은 「규칙만」으로 나온다
  • worker시세가 계속 조용하면 재접속을 몇 번 해도 무응답 시간이 이어서 쌓인다. 동시호가 10분은 틱이 원래 없어 알림에서 뺐다
  • qa한투 잔고 · 원장 · 화면 세 벌을 한 표로 비교하는 점검 도구를 실장 전 점검에 넣었다
v2.3 · 17판2026-09-28끝난 종목은 다시 안 사고, 종목당 금액은 고정한다. 시세가 조용히 끊겨도 알아챈다
이전
쉬는 날에 1차를 미뤄 두는 동안 규칙상으로는 이미 사고팔아 끝난 종목을, 사는 날이 열리자 새로 샀다. 매수 금액은 총자산의 15%라 계좌가 커지면 한 번에 사는 돈도 따라 커졌다. 시세 연결이 끊기지 않은 채 아무것도 안 오면 상태는 「실시간」으로 남아 4시간 동안 봉과 판정이 멈췄다
이후
장세 필터 없이 돌린 규칙이 이미 팔고 끝난 종목은 1차를 사지 않는다. 이미 산 종목은 지금처럼 내 평단 기준으로 판다. 종목당 최대 1,500만(1차 250 · 2차 500 · 3차 750)으로 고정하고 동시보유는 10종목까지. 장중에 시세가 60초 넘게 안 오면 다시 붙고, 90초 넘으면 매수를 막고 알린다
  • engineR-55: 필터 없는 사이클이 익절·기한청산으로 끝났으면 그 뒤 1차를 사지 않는다. 판단은 실제로 사는 봉 기준이다. 3년 백테스트 체결 914건 · 승률 88.6% · 연 +31.6% · 최대낙폭 9.5%
  • workerR-56: 계좌마다 「종목당 고정 금액」(기본 1,500만 · 10종목)과 옛 「총자산 15%」 중 고른다. 10종목이면 새 1차는 넘기고 물타기는 산다. 주문만 나가고 아직 체결 안 된 1차도 한 종목으로 센다
  • worker시세 연결이 살아 있는 채 조용해지면 끊고 다시 붙는다. 무응답 90초면 매수 차단과 알림, 5분봉이 7분 넘게 안 닫혀도 알림. 틱이 한 건도 없던 봉은 1분봉으로 채워 판정한다
  • worker재시작할 때 감시 기간이 끝났지만 들고 있는 종목의 빈 봉도 채운다
  • web매매 기록에 「규칙상 끝남」 뱃지와 필터 없는 매도 자리를 회색으로 보여준다. 계좌 관리에 「매수 금액」(고정/비율 · 한 종목 최대 · 동시보유 최대)이 생겼다
v2.2 · 16판2026-09-21장세 필터의 기준값을 관리자가 조절한다
이전
코스피가 60일선 위로 2일 연속이어야 첫 매수를 하는 기준이 코드에 박혀 있었다. 바꾸려면 배포가 필요했고, 화면의 「EMA60」도 글자로 적혀 있었다
이후
관리자 설정에서 이동평균 기간과 연속일수를 바꾼다. 저장하는 순간 지수 표 전체를 다시 계산하고 오늘이 사는 날인지 바로 알려준다. 기본값은 그대로(60일선·2일)라 백테스트 결과는 안 바뀐다
  • web관리자 화면에 「장세 기준」 입력이 생겼다. 이동평균 기간(5~200)과 연속일수(1~10)를 넣고 저장하면 재계산 행수와 오늘 판정을 알려준다
  • web대시보드 배너가 「EMA60」 대신 설정된 기간을 그린다. 연속일수를 기본과 다르게 두면 「(기준 n일)」이 같이 붙는다
  • worker지수 표를 다시 쓸 때 설정을 읽는다. 값이 비었거나 범위 밖이면 기본값으로 계산한다
  • qa다음 거래일에 매수를 막을 수 있는 길 여섯(장세·게이트·감시목록·데이터·자금·워커)을 한 번에 세는 점검 도구를 만들었다. 오늘 결과는 「막는 것 없음」
  • test파이썬 403종 · 화면 42종 · 규칙을 일부러 틀리게 바꿔 잡히는지 보는 검사 121종. 3년치 백테스트 결과는 그대로다(972건 · 승률 87.9% · 연 +50.8%)
v2.1 · 15판2026-09-18장세 필터를 잠시 끌 수 있게 했다. 켜는 것은 잊어도 된다
이전
코스피가 60일선 아래면 첫 매수를 쉰다. 9월 11일부터 계속 아래여서 매수 신호가 열여섯 번 나왔는데 전부 쉬는 날로 막혔다. 주문이 나가는 길이 한 번도 실제로 돌아본 적이 없는데, 그 길을 확인할 방법도 없었다
이후
관리자가 장세 필터를 잠시 끌 수 있다. 끌 때는 언제까지인지 반드시 같이 정하고, 그 시각이 지나면 프로그램이 스스로 다시 켠다. 사람이 기억하지 않아도 된다. 꺼져 있는 동안에는 화면 위쪽에 붉게 표시된다
  • worker장세 필터를 껐다 켤 수 있다. 봉이 마감될 때마다 설정을 다시 보기 때문에 장중에 바꿔도 바로 반영되고, 프로그램을 다시 시작하지 않아도 된다
  • worker끌 때는 만료 시각을 반드시 함께 받는다. 시각이 없으면 거부한다. 손절이 없는 규칙이라 필터를 잊고 꺼두면 최대 하락폭이 12%에서 35%로 커진다
  • web필터가 꺼져 있으면 화면 위쪽 장세 표시가 붉은 「필터 꺼짐」으로 바뀌고 언제 다시 켜지는지 같이 보여준다. 계좌 화면의 모드 설명에도 한 줄 덧붙는다
  • test파이썬 387종 · 화면 41종 · 규칙을 일부러 틀리게 바꿔 잡히는지 보는 검사 116종. 3년치 백테스트 결과는 그대로다(972건 · 승률 87.9% · 연 +50.8%)
v2.0 · 14판2026-09-16상한가로 끝난 종목만 고르고, 화면은 지금 살 수 있는 것부터 보여준다
이전
상한가 판정을 「전일 대비 +29% 이상」으로만 했다. 상한가는 30%지만 호가 단위로 깎이면 29.x%가 흔해서 느슨하게 잡은 건데, 그 틈으로 장중에만 상한가를 찍고 종가는 밀린 종목이 들어왔다. 실제로 한 종목이 그렇게 매수 대상에 잘못 올랐다. 그리고 표에는 이미 팔린 종목과 지금 살 수 있는 종목이 같은 무게로 섞여 있었다
이후
상한가로 마감한 종목만 고른다. 상한가로 끝났다면 종가가 그날 고가와 같을 수밖에 없다는 점을 조건으로 넣었다. 화면은 기본이 「후보」다. 이미 익절이나 기한청산으로 닫힌 종목은 접어 두고, 프로그램이 지금 사려는 것만 먼저 보인다. 접힌 것도 칩 하나로 다시 본다
  • worker상한가 판정에 「종가 = 그날 고가」를 더했다. 장중에 상한가를 찍고 밀린 종목은 대상이 아니다. 전체 346건 중 6건이 여기 걸리고, 매수 대상이던 건 1건이다
  • web표의 「산다?」 열을 「상태」로 바꿨다. 후보·보유·끝남·안 산다 넷이고, 필터도 같은 다섯 칩(전체 포함)이다. 처음 열면 「후보」가 선택돼 있다
  • web한 줄 요약 맨 앞에 「매수 후보 N (보유 M)」을 넣었다. 보유 중인 종목도 물타기로 더 살 수 있어서 후보에 포함한다
  • web후보가 하나도 없는 날은 「지금 매수 후보가 없습니다 — 이 창의 이벤트는 다 끝났거나 대상이 아닙니다」라고 말한다
  • test파이썬 377종 · 화면 39종 · 규칙을 일부러 틀리게 바꿔 잡히는지 보는 검사 114종. 3년치 백테스트 결과는 그대로다(972건 · 승률 87.9% · 연 +50.8%)
v1.9 · 13판2026-09-16상한가를 정규장 종가로 판정한다. 그리고 「최고」는 물타기까지 끝낸 평단 기준으로
이전
종목을 고를 때 쓰던 일봉이 정규장과 시간외를 합친 종가였다. 그래서 정규장에서는 +26% 에 그친 종목이 상한가로 잡혀 매수 대상에 들어왔다. 실제로 09월 14일 두 종목이 그랬다. 「타점 후 최고」는 1차 매수가를 기준으로 계산해서, 물을 탄 종목은 실제보다 낮게 나왔다
이후
상한가 판정을 정규장(9시~3시 30분) 종가로만 한다. 시간외에서만 상한가인 종목은 대상에서 빠진다. 「평단 대비 최고」는 물타기까지 다 끝낸 평단에서 최고 몇 % 올랐는지를, 마지막 물타기 이후 구간에서 본다. 종목에 마우스를 올리면 그 최고와 「우리 매도 타점에 팔면 몇 %」가 한 줄에 나란히 보인다
  • worker일봉을 증권사에서 정규장 기준으로 받는다. 전 종목 하루 한 번, 약 3분. 예전에 쓰던 무료 시세는 정규장과 시간외를 합친 값이라 상한가 판정에는 쓰지 않는다
  • worker상한가 판정식은 한 줄도 바꾸지 않았다. 들어가는 값만 정규장이 됐다. 하한가 계산에 쓰는 전일 종가도 같은 이유로 맞아졌다
  • web표의 「타점 후 최고」를 「평단 대비 최고」로 바꿨다. 툴팁에 「최종 평단 → 최고 (+n%) · 규칙 매도 (+n%)」 한 줄을 넣어, 얼마까지 갈 수 있었는지와 실제로 어디서 파는지를 같이 본다
  • worker상한가 판정에 상한을 뒀다. 상한가는 제도상 +30%가 최대인데, 액면분할이나 주식 병합이 일어난 당일은 전일 종가와 이어지지 않아 등락률이 수백 %로 계산된다(한 종목 실측 +140%). 그런 행을 걸러낸다
  • qa원저자 상한가 자료와 직접 대조했다. 8월 2일~9월 10일 구간에서 239건이 일치하고 저희에게만 있는 건 0건이다. 차이 나는 행을 파 보니 원저자 자료는 수정주가(분할 전 과거 가격이 보정된 값)를 쓰고 있어 등락률이 부풀려지거나 반대로 진짜 상한가를 놓친 경우가 있었다. 상한가는 거래소가 그날 원주가로 정하므로 저희는 원주가로 받는다
  • test파이썬 367종 · 화면 38종 · 규칙을 일부러 틀리게 바꿔 잡히는지 보는 검사 112종(신규 6). 3년치 재생 1,424건 전부 일치
v1.8 · 12판2026-09-15텔레그램 연결을 버튼 하나로 바꿨다. 번호를 찾거나 적을 일이 없다
이전
알림을 받으려면 텔레그램의 내부 번호(chat id)를 찾아 붙여넣어야 했다. 「찾기」는 봇에게 말을 건 사람 전부를 목록으로 보여줬고, 그 목록에서 남의 번호를 고를 수 있었다. 실제로 사용자 셋이 같은 번호를 갖게 돼 한 사람의 신호가 다른 사람 폰으로 갔다. 저장된 번호가 본인 것인지는 아무도 확인하지 않았고, 누구와 연결됐는지도 화면에 없었다
이후
「텔레그램으로 연결」을 누르면 텔레그램이 열리고, 「시작」을 누르면 끝난다. 서버가 본인만 아는 일회용 코드를 발급하고, 그 코드가 본인 채팅에서 돌아왔을 때만 연결한다. 남의 번호를 고를 길이 없다. 연결되면 이름과 @아이디가 보이고, 해제 버튼이 있다. 알림 스위치는 누르는 순간 저장된다
  • web설정 화면의 텔레그램 부분을 다시 짰다. 상태는 미연결·대기 중·연결됨·만료 넷이고 각각 한 문장으로 말한다. 번호 입력칸과 「찾기」 목록은 없앴다
  • web텔레그램이 안 열리는 환경을 위해 「봇에게 이 문장을 보내세요」 폴백과 복사 버튼을 뒀다. 같은 서버 로직으로 잡힌다
  • api일회용 코드(10분)를 발급하고 텔레그램 대화에서 그 코드가 적힌 개인 채팅만 찾는다. 그룹·채널·다른 말은 무시한다. 연결되면 코드를 폐기해 다시 쓸 수 없다. 응답에 봇 토큰이나 다른 사람의 정보를 싣지 않는다
  • api「찾기」 API 를 삭제했다. 봇에게 말을 건 모든 사람의 이름이 보이는 통로였다
  • test파이썬 362종 · 화면 38종 · 규칙을 일부러 틀리게 바꿔 잡히는지 보는 검사 106종(신규: 그룹 채팅도 연결한다 · 코드 만료를 무시한다)
v1.7 · 11판2026-09-15대시보드에 매매 기록을 넣었다. 창 안 이벤트 전부, 규칙이 한 일과 내가 한 일을 한 줄에
이전
감시 목록은 규칙을 통과한 종목 여덟 개만 보였고, 「왜 저 종목은 안 사는지」는 화면 어디에도 없었다. 1차를 언제 얼마에 샀는지, 물을 탈 때마다 평단과 익절선이 어떻게 움직였는지는 들고 있는 동안만 카드에 보였고, 팔고 나면 원장 표를 뒤져야 했다. 관제 모드에서는 규칙이 무엇을 했을지 알 길이 없었다
이후
상한가 D+1~D+6 창 안 이벤트 44건이 전부 표에 오른다. 산다·안 산다를 구분하고, 안 사는 이유(동전주·대금·배수)를 그 자리에 적는다. 종목에 마우스를 올리면 「규칙대로 담았다면」 사다리 — 1·2·3차마다 시각·가격·평단·익절선 — 와 「내 계좌는」이 두 단으로 뜬다. 날짜를 되돌리면 지나간 이벤트도 그날까지의 봉으로 다시 재생해 같은 표로 본다. 표 위 한 줄이 「이 창에서 규칙이 몇 건 끝났고 나는 몇 건 체결했는지」를 말한다
  • web대시보드의 감시 목록을 매매 기록 표로 바꿨다. 열은 종목 · D+n · 매수 타점 · 매도 타점 · 산다? · 나 · 현재가 · 상한가 대비 · 타점 후 최고 · 규칙/내 순익. CCI·시그널·gap 은 「지표」 버튼 뒤로 접었다
  • web매수 타점에 상태를 적는다 — 「14:00 1차」 · 「매매 전」 · 「아직 안 나옴」 · 「5분봉 없음」 · 「쉬는 날 — 오늘 1차 안 삼」 · 「안 산다 · 대금<100억」
  • web종목 툴팁 2단. 위는 규칙 사다리(반등 확인 봉 종가 → 진입, 1·2·3차 시각·가격·평단·익절선·조건), 아래는 내 계좌(체결·넘김·카드 대기·청산). 규칙 순익은 신호가 기준, 내 순익은 체결가 기준 — 나란히 두되 섞지 않는다
  • web장세를 문장으로 적는다. 「오늘은 매수 쉬는 날. 새로 사지 않는다(장은 열린다). 들고 있는 종목의 물타기·매도는 평소대로」 와 코스피 종가·60일선·여유 퍼센트
  • web날짜 이동. 거래일 단위로 되돌려 지나간 이벤트를 그날까지의 봉으로 본다. 봉은 30일 보관이라 그 밖은 이유를 말하고 막는다. 좁은 화면에서는 카드 목록과 아래에서 올라오는 시트
  • worker「안 산다」 종목의 5분봉도 받는다(첫날 약 2분 · 이후 하루 3분의 1). 다만 그 종목들은 판정도 알림도 하지 않는다 — 감시 목록은 그대로 여덟 개다. 실시간 시세 구독에 한도가 있어 안 사는 종목의 현재가는 5분 봉마다 따로 물어 오고, 화면에 ⏱ 로 지연을 표시한다
  • api규칙 사다리는 백테스트 엔진이 낸 의도를 그대로 받아 적은 것이다. 엔진 코드는 한 줄도 손대지 않았고, 3년치 이벤트 1,424건 전부에서 사다리의 결말·순익·차수·진입·청산이 일괄 백테스트와 같다
  • api화면이 요청 두 개를 동시에 보내자 데이터베이스 연결 하나를 두 스레드가 나눠 쓰다 세션 확인이 깨져 「로그인이 필요합니다」가 뜨는 결함을 찾았다. 예전엔 요청을 하나씩만 보내서 드러나지 않았다. 스레드마다 연결을 따로 쓰게 고치고, 40개를 동시에 보내는 테스트로 고정했다
  • test화면 테스트 37종(신규 6) · 파이썬 356종 · 규칙을 일부러 틀리게 바꿔 잡히는지 보는 검사 102종(신규 13)
v1.6 · 10판2026-09-15계좌 화면을 다시 짰다. 가진 것이 주인공이고, 돈이 나가는 버튼은 다르게 생겼다
이전
계좌를 등록하고 연결까지 끝낸 뒤에도 화면 절반을 빈 입력칸 여섯 개가 차지했다. 실제로 「이거 계좌가 등록된 화면이 맞냐」는 질문을 받았다. 모드 셋과 연결 테스트 버튼이 똑같이 생겨서, 알림만 받는 상태와 실제로 돈이 나가는 상태를 생김새로 구분할 수 없었다
이후
계좌 추가는 버튼을 눌러야 열리는 창으로 보내고, 등록된 계좌가 화면의 주인공이 됐다. 예수금과 평가금액이 큰 숫자로 먼저 보인다. 모드 셋은 한 테두리 안에 묶어 「하나를 고르는 것」임을 형태로 말하고, 자동만 다른 색으로 구분한다. 알림 설정은 번호를 붙여 세 단계로 나눴다
  • web계좌 추가 폼을 창으로 옮겼다. 계좌가 하나도 없으면 그 자리에 「아직 연결한 계좌가 없습니다」와 큰 버튼이 나오고, 앱키 발급 안내도 거기 함께 있다
  • web모드 셋(관제·반자동·자동)을 한 테두리 안에 묶었다. 자동만 다른 색과 테두리로 구분하고, 선택한 모드가 무엇을 하는지 바로 아래 한 줄로 적는다. 자동으로 바꿀 때 확인 문구를 요구하는 것은 그대로다
  • web계좌 카드에서 예수금·평가금액을 큰 숫자로 올렸다. 연결 상태는 초록 점 하나와 「어제 17:47」 같은 상대 시각으로 접었고, 실패했을 때만 어느 단계에서 막혔는지 펼친다
  • web알림 설정을 세 단계로 나눴다. ① 봇에게 말 걸기 ② 내 chat id 찾기 ③ 테스트 메시지 보내기. 예전에는 「숫자를 넣으세요」 한 칸뿐이라, 사용자 셋이 전부 같은 값을 넣고 있었다 — 남의 폰으로 알림이 가고 있었다는 뜻이다
  • apichat id 를 서버가 찾아 준다. 다만 자동으로 저장하지는 않는다. 봇에게 말을 건 사람이 여럿이면 그 목록을 보여 주고 본인이 고른다
  • web좁은 화면에서 상단 막대가 화면 밖으로 밀려나 가로 스크롤이 생기던 것을 고쳤다. 폭이 좁아지면 덜 중요한 글자부터 줄인다
  • order주문 가능 금액을 물을 때 쓰던 구분값이 틀렸다. 증권사 공식 문서가 「지정가로 물으면 종목별 증거금 비율이 반영되지 않는다」고 못박고 있다. 우리 감시 종목은 전날 상한가를 친 종목이라 증거금 비율이 높게 잡히는 쪽이고, 그대로 두면 실제보다 큰 금액이 나와 주문이 과하게 커진다. 새 규칙에서는 이 값이 주문 수량을 직접 정하기 때문에 더 중요해졌다
  • test화면 테스트 29종(신규 6) · 파이썬 331종 · 규칙을 일부러 틀리게 바꿔 잡히는지 보는 검사 89종. 키보드로 모드를 옮기는 것, 좁은 화면에서 가로 스크롤이 없는 것, 연결 실패 화면까지 자동으로 확인한다
  • test테스트용 가짜 증권사가 「실패했는데 네 단계가 전부 성공」이라는, 실제로는 없는 상태를 주고 있었다. 그래서 실패 화면을 검증할 수 없었다. 실패를 현실적으로 고쳤다
  • qa화살표 키로 모드를 옮길 때 끝에서 감싸 돌면 「자동」으로 넘어가 확인 창이 열렸다. 키 한 번에 돈이 나가는 자리로 가면 안 되므로 끝에서 멈추게 했다
  • web계좌 카드에 「관리」를 넣었다. 등록할 때 넣은 값(별칭·계좌번호·환경·시드·HTS ID·등록일)을 보고 고칠 수 있다. 앱키와 시크릿만은 예외 — 암호화돼 있어 서버도 원문을 돌려주지 않는다. 바꾸려면 새로 넣는다
  • web계좌 삭제를 만들었다. 되돌릴 수 없어서 무엇이 함께 지워지는지(원장·주문·판정로그 건수) 먼저 보여 주고, 계좌 별칭을 그대로 입력해야 버튼이 눌린다
  • api삭제가 안전하지 않았다. ① 매도 주문을 이미 보낸 상태(청산대기)를 막지 않아 주문은 증권사에 남고 기록만 사라질 수 있었다 ② 거래 기록이 하나라도 있으면 삭제가 실패했고, 판정로그·이벤트는 주인 없는 행으로 남았다(예찬 계좌 기준 2,281건). 살아 있는 것이 있으면 거부하고, 아니면 기록까지 한 번에 정리한다
  • qa리플레이 전수 대조 1,424건 전부 일치. 봉을 하나씩 밟아 낸 판단이 3년 내내 일괄 백테스트와 어긋나지 않는다 — 실시간 경로가 백테스트 숫자를 보증한다는 뜻이다
v1.5 · 9판2026-09-14사양 v2. 장세 필터·3차신호·자금 배분을 원저자의 새 사양대로 바꿨다
이전
2차신호만 보고, 슬롯 2개에 예산을 나눠 담았다. 시장이 내려가는 날에도 상한가 종목이 나오면 샀다. 옛 규칙으로 돌린 3년 백테스트는 587건 · 승률 89.4% · 연환산 +133.8% · 최대 낙폭 35.2% 였다
이후
원저자가 2026-09-14 에 낸 새 사양(v2)대로 전부 옮겼다. 같은 3년 데이터로 돌리면 972건 · 승률 87.9% · 연환산 +50.8% · 최대 낙폭 12.3%. 거래 단위 통계(승률·최악 손실)가 원저자 문서의 4.7년 결과와 같아 규칙을 맞게 옮겼다고 본다. 실제 장에서는 내일(9/15)부터 돌고, 그날은 시장이 60일선 아래라 「매수 쉬는 날」로 시작한다
  • engine판정 엔진을 봉 하나씩 밟는 상태기계로 바꿨다. 백테스트와 실시간이 문자 그대로 같은 클래스를 밟는다. 옛 규칙으로 돌리면 옛 숫자(587건)가 그대로 나오는 것을 먼저 확인하고 나서 새 규칙을 넣었다
  • engine팔지 말지 따질 때 빼는 비용을 수수료만(0.227%)에서 수수료+세금(0.377%)으로. 매도선이 그만큼 올라간다
  • worker장세 필터. 코스피 종가가 60일 지수이동평균 위에서 이틀 연속이면 「사는 날」, 아니면 「매수 쉬는 날」이다. 쉬는 날엔 첫 매수만 쉬고 물타기·매도·기한청산은 평소대로 돈다. 상단 배지와 대시보드에 오늘 장세가 보인다. 지수 자료가 없으면 쉬는 날로 본다
  • worker3차신호(RSI·OBV 골든크로스)가 기본으로 켜졌다. 2차신호와 함께 감시를 연다. 3년 데이터에서 진입 봉이 바뀌는 이벤트는 4건이다
  • order돈이 모자라 못 산 자리를 「넘김」으로 원장에 남긴다. 첫 매수를 넘겼으면 다음 반등은 물타기가 아니라 다시 첫 매수이고, 물타기를 넘겼으면 그 뒤 물타기는 안 한다. 프로그램이 다시 켜져도 원장만 보고 같은 상태를 복원한다
  • order슬롯이 없어졌다. 한 종목에 총자산(현금+투입 원금)의 15%까지, 첫 매수 2.5% · 두 번째 5% · 세 번째 7.5%. 살 때마다 그 순간의 총자산으로 계산한다. 동시에 몇 종목을 들든 상관없고, 현금이 모자라면 일부만 사지 않고 그 자리를 넘긴다
  • order반자동 카드도 원장 기준이다. 첫 매수 카드를 승인·체결하지 않았으면 두 번째 카드는 나오지 않는다. 들고 있지도 않은 물타기를 승인하라는 카드가 없어졌다
  • admin관리자 설정에 주문방식(지정가·시장가)이 생겼다. 새 사양은 시장가인데 기본은 지금까지의 지정가다. 바꾸는 건 사람이 정한다
  • test새 사양 흐름 두 벌을 끝까지 자동으로 돌린다. 쉬는 날에 첫 매수가 막히는 것, 돈이 모자라 넘긴 뒤 다음 반등에서 다시 사는 것, 물타기를 넘긴 뒤 첫 매수 평단으로 파는 것, 다시 켜진 뒤 같은 판정이 나오는 것, 세 종목 동시 진입과 현금 부족 넘김. 화면 테스트 20종, 파이썬 316종, 규칙을 일부러 틀리게 바꿔 테스트가 잡는지 보는 검사 86종
  • test테스트 파일 하나가 시작할 때 데이터베이스 경로를 덮어써서, 최종 테스트의 앱이 남의 데이터베이스를 열고 있었다. 이번에 장세 자료를 넣으면서 드러났다. 고치고 같은 유형을 상설 검사에 넣었다
  • order증권사 주문번호는 날마다 처음부터 다시 매겨진다. 체결을 붙일 때 살아 있는 주문만 보도록 고쳤다. 안 고치면 어제 같은 번호의 매수에 오늘 매도 체결이 붙는다
v1.4 · 8판2026-09-14새 규칙 첫 실장 — 사고 2건을 같은 날 고쳤다
이전
주말에 넣은 규칙 7건이 실제 장에서 한 번도 돈 적이 없었다. 프로세스가 하루 종일 도는 동안 무엇이 새는지도 몰랐다
이후
감시 8종목 · 판정 600봉 · 최대 지연 3.41초(금요일 12.06초). 여섯 기준 중 다섯 통과. 실패 하나는 아래 사고가 원인이고 원인 규명·수정까지 끝났다. 첫 페이퍼 매매가 종료됐다(1건 · +3.0%)
  • worker봉 검증 스레드가 데이터베이스 연결을 닫지 않았다. 봉마다 종목마다 하나씩 쌓여 14:30 에 프로세스가 열 수 있는 파일 한도(1,024개)를 다 썼다 — 그 순간부터 알림과 증권사 조회도 같이 막힌다. 연결을 닫고, 한도를 8배로 올리고, 5시간 돌아야 드러나는 이 버그를 테스트로 고정했다
  • ops엣지 프록시가 설정 리로드 중 런타임 오류로 죽었고 자동 재시작이 없어 **공개 주소 전체가 6분간 다운**됐다. 내부 주소만 보던 배포 확인이 그걸 놓쳤다. 자동 재시작을 걸고, 설정이 바뀔 때만 리로드하며, 이제 사용자가 지나는 길로 살아 있는지 묻는다
  • worker단일가 전환 검사가 조회 한 번 실패로 한 종목을 종일 막았다. 1분 뒤 같은 조회는 정상이었다. 두 번 시도하고, 08:50 에 다시 확인해 깨끗하면 푼다. 실제로 그날 08:50 에 풀렸다
  • web계좌 추가에서 API 열쇠 칸에 로그인 이메일을 넣는 실수가 실제로 있었다. 이 열쇠가 무엇이고 어디서 받는지 안내를 넣고, 제출 전에 형식을 한글로 알려 준다. 서버 오류 문구도 한글로
  • test이벤트 종류 11개 중 넷이 서버에서 나가지 않고 있었고, 알림 검증 테스트는 다른 파일이 갈아끼운 가짜를 보고 있었다. 둘 다 고쳤다. 로그 회전·이벤트 표 보존(30일)처럼 무한히 쌓이던 자리를 정리했다. 테스트 292건 · 규칙 회귀 77종
v1.3 · 7판2026-09-13검증 커버리지 — 「테스트가 있다」와 「그 기능을 부른다」는 다르다
이전
테스트 숫자와 통과율만 봤다. 어떤 기능이 한 번도 불리지 않는지는 아무도 세지 않았다
이후
API 37개와 화면 12개를 테스트 소스와 대조해 **한 번도 불리지 않는 것**을 센다. 지금 둘 다 0개. 실장 전 점검에 들어가 있어, 기능을 새로 만들고 테스트를 빠뜨리면 그 자리에서 걸린다
  • testAPI 37개 중 둘이 한 번도 안 불리고 있었다 — 가입 거절, 알림 설정(텔레그램·on/off). 둘 다 화면에서는 호출 중이라 「참조됨」으로 세면 통과했다. 알림 설정이 조용히 저장되지 않으면 켰다고 믿는데 알림이 오지 않는다
  • test화면 12개 중 셋을 브라우저 테스트가 한 번도 열지 않았다 — 설정·판정로그·**전체 비상정지 화면**. 네 건을 새로 써서 화면 테스트가 12 → 16건이 됐다
  • api가입 거절이 「없는 신청」과 「이미 처리된 신청」을 둘 다 같은 오류로 뭉쳤다. 승인 쪽은 둘을 구분한다. 같은 모양으로 맞춰 관리자가 화면에서 원인을 알 수 있게 했다
  • test스키마를 두 번 바꾼 뒤 다시 돌리지 않았던 화면 테스트(16건)와 API 시나리오(26건)를 재실행했다. API 시나리오는 계정을 실제로 바꾸는 물건이라 임시 저장소에서 도는 판을 따로 만들었다
  • test커버리지 도구 자체의 매칭을 두 번 고쳤다. 느슨한 대조는 가짜 안심을 준다 — 화면의 한 경로가 다른 기능의 근거로 세어졌고, 주석에 적어 둔 이름까지 세고 있었다. 지금은 실제 호출 형태만 인정한다
v1.2 · 6판2026-09-13설계 조항 감사 — 「문서에는 있는데 코드에 없던」 규칙 5건
이전
규칙 번호가 코드 주석에 한 번 적혀 있으면 추적 도구가 「구현됨」으로 셌다. 규칙 하나가 조항 넷이어도 한 번만 세어졌다
이후
설계서의 규칙 60개를 **조항 단위로** 코드와 대조한다. 체크리스트에 항목이 없는 번호도 따로 센다(지금 0개). 규칙을 일부러 틀리게 바꿔 테스트가 깨지는지 보는 회귀 검사는 52종
  • worker감시 기간(D+1~D+6)이 지나도 **들고 있는 종목은 계속 판정**한다. 규칙 엔진은 감시 기간을 매수에만 적용하는데 실행부가 매도까지 막고 있었다. 3년 검증 586건 중 85건(14.5%)이 D+6 뒤에 청산되고 그중 21건이 익절이다
  • worker기한 청산 주문 가격을 **거래소가 알려주는 하한가로** 낸다. 직접 계산하던 값은 87종목 중 12건(14%)이 실제 하한가보다 낮아 주문이 거부될 값이었다
  • worker정규장이 30분 단일가로 바뀐 종목(단기과열 지정·정리매매·관리종목)은 신규 진입을 막는다. 5분봉이 성립하지 않아 지표가 시장이 아닌 제도를 읽는다. 투자경고는 제외 사유가 아니다
  • worker배당락·권리락·액면분할이 낀 구간도 신규 진입을 막는다. 권리 조정으로 내려간 가격을 「눌림」으로 읽고 더 사는 일을 막는다
  • worker주문가가 하한가 이하거나 기준가 −25% 이하면 사지 않는다(물타기 포함). 규칙은 −1% 단위로 담으므로 정상 흐름에서는 닿지 않는 줄이다
  • worker증권사 접근토큰 재발급에 백오프를 넣었다. 토큰은 24시간짜리라 매 거래일 아침 반드시 한 번 재발급되는데, 그 한 번이 실패하면 그날이 통째로 날아갔다. 시세가 끊긴 동안에는 매수만 멈추고 매도는 계속한다
  • test테스트 201건 · 규칙 회귀(돌연변이) 52종. 검사 도구가 **같은 문장이 여러 곳에 있으면 거부**한다 — 조용히 엉뚱한 곳을 바꾸면 보고서 전체를 믿을 수 없다
v0.1 · 2판2026-09-11주문 실행 코드와 안전장치 — 실계좌 게이트 · 반자동 재검증 · 환경파일
이전
관제만 있었다. 카드는 만들어지지만 주문은 나가지 않았다
이후
모드=자동 이면 워커가 주문을 낸다 — 단 실계좌는 관리자 설정 실계좌주문허용=1 일 때만(R-35). 반자동 승인은 서버가 규칙을 다시 계산해 같을 때만 발송(R-29). 체결은 30초 폴링(R-36)
  • worker주문실행기 — 수량(1:2:3 · 미수없는매수금액 캡 · 0주 스킵) · 봉 넘긴 매수 취소(R-1) · 부분체결(R-4) · 08:20 기한청산 접수(D-8)
  • api반자동 카드 승인 → 명령큐 → 워커 재검증 → 발송. 만료·모드·정지·차수 조작 전부 거부
  • web대시보드·원장·판정로그·계좌·설정·관리자 3·/about — Next.js 16 · shadcn 퍼플 다크 · SSE + 폴링 폴백
  • infra환경변수는 web/.env.production 파일이 정본(공개값 커밋). 프론트 프로덕션 배포
  • qaPlaywright 12/12 · pytest 44 · 오브젠 골든 · 리플레이 24/24 · 실서버 curl 26/26
v0.1 · 1판2026-09-11서버·API·워커 골격과 실서버 배치
이전
설계서와 백테스트 엔진만 있었다
이후
api.jusike.kr 에 FastAPI 가 뜨고, 워커 배치가 오늘 감시목록을 실데이터로 만든다 (관제 모드)
  • infra서버 정비 — Asia/Seoul · 방화벽 22/80/443 · 키 전용 SSH · fail2ban · venv · 리버스 프록시
  • engine꾸러미 3 반영 · 청산기한 8일 · 백테스트 587매매/승률 89.4%/연 +133.8%/MDD 35.2% 재현 (2차+3차 합산)
  • engine2차신호 전용 정답지 586/89.1%/+96.2%/33.0% (1차 릴리스 기준)
  • worker봉 조립: 증권사 1분봉(시작시각) → 5분봉(종료시각 표기). 4종목-일 308봉 OHLC 100% 일치
  • worker어댑터 리플레이 24/24 이벤트 = 엔진 일괄 백테스트 (기한청산 케이스 포함)
  • worker무거래 구간(hollow) 봉은 엔진 입력에서 제외 — 기준 데이터이 그런 봉을 내지 않는다 (R-34)
  • api가입 신청→관리자 승인→임시비밀번호(1회 표시) · 계좌 등록(앱키 AES-GCM 암호화) · 연결 테스트 · 모드 · 비상정지 · SSE
  • qa실서버 curl E2E 26/26 · api 테스트 14 · core 11 · worker 7
v0.3 · 3판2026-09-11도메인 실연결 · CDN(cdn.jusike.kr) · 3차신호 스위치
이전
임시 주소와 SSH 터널로만 접근했다. 대용량 파일을 둘 곳이 없었다
이후
https://jusike.kr · https://api.jusike.kr 이 엣지 프록시를 거쳐 실제 도메인으로 뜬다. 이미지·영상은 cdn.jusike.kr 에 올린다
  • infra도메인 jusike.kr 실연결 · 네임서버 이전 · DNS api(프록시)/cdn(프록시)/@·www(프론트) · 엣지↔오리진 TLS 검증 · Always HTTPS · TLS 1.2+
  • infra오리진 리버스 프록시가 Let's Encrypt 인증서를 http-01 로 발급(엣지 경유) · api.jusike.kr HSTS · CORS 는 jusike.kr·www 만
  • infracdn.jusike.kr = 오브젝트 스토리지 + 엣지 규칙 3건(경로 재작성 · 내부 헤더 제거+CORS · 엣지 30일/브라우저 1년 캐시). 스토리지→엣지 전송료 0원
  • api저장소 모듈(S3 SigV4 · 표준 라이브러리) · POST /api/me/upload(200MB · 확장자 화이트리스트) · 관리자 목록/삭제. 점검 도구 tools/cdn_점검.py (HIT 확인)
  • engine설정 신호모드 = 2차 | 2차+3차 스위치(관리자). 3차 켠 리플레이 24/24 일치. 실장 전환은 페이퍼 뒤 사용자 승인
  • admin관리자 시스템 설정에 실계좌주문허용(R-35) · 신호모드 노출 — 바꾸면 이벤트로 남는다
v1.0 · 4판2026-09-111차 릴리스 — 첫 실장 하루(관제) 완주
이전
모든 검증이 과거 데이터 재생과 가짜 증권사였다
이후
살아 있는 장에서 07:50~15:40 하루를 돌았다. 5분봉 539개를 틱으로 조립해 531번 판정했고, 규칙상 매수 신호 4건이 엔진 일괄 결과와 전부 일치했다(주문은 0건 · 관제)
  • worker실장 결과: 감시 7종목 · 판정 531(봉당 7) · 정상 봉 지연 평균 0.71초 · 최대 3.2초 · 신호 4(샘표식품 1·2·3차 물타기, 머큐리 1차) · 텔레그램 신호·마감 리포트
  • worker자가 치유: 봉이 닫히면 5분 뒤 직전 봉을 증권사 1분봉과 대조해 다르면 교체(R-37) · 거래량이 희박한 봉은 판정 전에 즉시 재구성(R-37b) · 재기동이 걸친 봉은 기동 전 1분봉 + 기동 후 틱 병합
  • worker내성: 주기 작업·틱 처리 예외로 죽지 않음(R-38) · 늦게 도착한 틱은 폐기 · 같은 봉은 한 번만 판정(R-39) · 장중 강제 종료 7회 전부 자동 복귀(다운 20~25초)
  • engine실측 확인: 증권사 당일 1분봉 첫 봉은 전일 종가를 시가로 찍는다(틱 조립이 정답) · 실시간 체결 스트림은 드물게 통째로 비는 구간이 있다(09:20·11:20) → R-37 이 메운다
  • qaTC-LIVE-1 실장 판정 == 엔진(7종목) · E2E-WORKER-1/2 · TC-3-5 지연 · 강제마감 2초 유예로 봉을 첫 틱이 닫게 함
  • qa남은 게이트: 모의투자 키(주문 왕복 E2E) · 페이퍼 2주 · 소액/전액 승인 · 3차신호 전환 · 가정 시가 봉의 주문 방식(R-40)
v1.1 · 5판2026-09-12주문 경로 감사 — 결함 9건 수정
이전
관제로 하루를 완주했지만, 주문을 실제로 내보내는 코드는 한 줄도 실행된 적이 없었다
이후
주문·체결·자금 경로를 처음부터 훑어 결함 9건을 찾아 고쳤다. 전부 관제 모드라 실제 손해는 없었고, 모의투자나 자동 매매를 켜는 순간 만났을 것들이다
  • order기한청산 가격이 호가 단위 아래라 **주문이 거부될 값**이었다(표본 4건 전부). 8거래일째 청산은 마지막 안전장치인데 실패할 뻔했다 → 올림으로 수정
  • order부분 체결로 판 경우에도 포지션 전체를 청산 처리했다. 남은 수량이 장부 밖으로 새어 영영 안 팔릴 수 있었다 → 전량 체결일 때만 청산
  • order부분 체결된 매수의 잔량이 봉을 넘겨도 살아남아, 규칙이 정하지 않은 가격에 뒤늦게 붙을 수 있었다 → 잔량도 취소
  • order익절 주문은 당일 주문이라 안 팔리면 장 마감에 사라지는데 장부는 '매도 중'으로 남아, 그 종목을 기한까지 다시 못 팔았다 → 아침마다 자동 복구
  • engine동시 보유 종목 수 제한이 실전에만 없었다. 세 번째 종목이 들어와 기존 종목의 물타기 현금을 가져갈 수 있었다 → 백테스트와 같은 제한 적용
  • engine예수금이 아침 값으로 고정돼, 나중에 진입하는 종목의 예산이 최대 47% 부풀었다 → 새 종목 진입 때 잔고 재조회
  • worker5분봉이 무한정 쌓이고 있었다(30일 정리 미구현) · 장이 1시간 늦게 여는 날 처리가 연결되지 않아 그날 판정이 어긋날 뻔했다
  • qa테스트 63 → 106개. 주문 생애 통합 테스트를 운영과 같은 경로(증권사가 주는 누적 체결량)로 다시 만들었다 — 부분 체결 결함 셋이 여기서 샜다
  • qa규칙을 일부러 틀리게 바꿔 테스트가 잡는지 검사하는 도구 도입(18종). 실계좌 주문 차단·권한 검사는 잘 지켜지고 있었으나, **종목 선별 기준 4개와 무거래 봉 제외 규칙은 테스트가 하나도 없었다** → 8건 추가해 18/18 전부 잡힘