KIS API가 '체결됐다'고 해도 믿지 마라: phantom-fill과 KIS-truth 재검증
매도 주문 API가 성공 응답을 반환했다. 그런데 실제 체결이 되지 않았고, 시스템은 이미 체결로 기록했다. KIS API 응답과 실제 체결 사이의 간극, 그리고 이를 방어하는 KIS-truth 재검증 패턴을 정리했다.
매도 주문 API가 성공 응답을 반환했다. 그런데 실제 체결이 되지 않았고, 시스템은 이미 체결로 기록했다. KIS API 응답과 실제 체결 사이의 간극, 그리고 이를 방어하는 KIS-truth 재검증 패턴을 정리했다.
KIS API 클라이언트에 connect timeout을 60초로 설정했더니, 연결이 느려지는 순간 요청이 수십 개 쌓였다. 타임아웃을 길게 잡을수록 안전하다는 착각이 만든 사고다.
KIS API는 개장 직후 09:00~09:05 KST에 연결 불안정 구간이 존재한다. 이 구간에서 2-상태 서킷 브레이커는 회복하지 못하고 silent block에 빠진다. CLOSED/OPEN/HALF_OPEN 3-상태 서킷 브레이커와 에스컬레이션 open_seconds_schedule로 프로브 기반 자동 회복을 구현한 과정을 정리했다.
FastAPI lifespan에서 Telegram 봇을 시작할 때 TLS 연결 지연으로 start()가 실패했다. 예외는 잡혔고, 백엔드는 멀쩡히 돌았다. 알림은 한 건도 오지 않았다. 5분 후 봇이 살아 돌아오는 것도 몰랐다.
macOS에서 git push를 실행하면 osxkeychain 자격증명 헬퍼가 응답 없이 멈추는 현상이 간헐적으로 발생한다. gh CLI가 제공하는 git-credential 헬퍼로 교체하면 깔끔하게 해결된다.
신규 포지션을 잡은 직후 첫 번째 스케줄러 사이클에서 WebSocket 시세가 오지 않았다. 원인은 구독 동기화 함수의 호출 위치가 holdings 동기화보다 앞에 있었기 때문이다.
APScheduler job이 매주 일요일 새벽 2시에 실행됐지만 전략 파라미터는 5주 동안 한 번도 업데이트되지 않았다. 에러는 있었다. 로그에도 찍혀 있었다. 그런데 왜 아무도 몰랐을까.
증상 회사 보안 정책으로 Zscaler가 설치된 뒤, 어느 날 갑자기 Docker image pull이 실패하기 시작한다. failed to resolve reference "asia-northeast3-docker.pkg.dev/...": failed to do request: Head "https://asia-northeast3-docker.pkg.dev/...": tls: failed to verify certificate: x509: certificate signed by unknown authority macOS 키체인에 Zscaler Root CA를 신뢰하도록 등록했고, docker context ls로 보면 별 문제 없어 보인다. 그런데도 docker pull은 계속 같은 오류를 낸다. 원인: Docker daemon은 macOS가 아니라 Colima VM 안에 있다 Colima를 사용하는 환경에서 docker info를 실행해 보면 이런 결과가 나온다. ...
KST 09:00으로 설정한 스케줄러가 UTC 09:00에 실행된 실제 사고 사례와 원인 분석, 그리고 재발 방지 패턴을 정리한다.
Customer Gateway 2개, VPN Connection 2개로 총 4터널을 구성하는 Full HA 구성 절차와 멀티 클라우드 통신 테스트 시나리오를 정리한다.