<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Debugging on 삽질로그</title><link>https://blog.cheongbi.kro.kr/tags/debugging/</link><description>Recent content in Debugging on 삽질로그</description><generator>Hugo</generator><language>ko</language><lastBuildDate>Wed, 02 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.cheongbi.kro.kr/tags/debugging/index.xml" rel="self" type="application/rss+xml"/><item><title>KIS API가 '체결됐다'고 해도 믿지 마라: phantom-fill과 KIS-truth 재검증</title><link>https://blog.cheongbi.kro.kr/posts/troubleshooting/kis-api-phantom-fill-truth-verification/</link><pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate><guid>https://blog.cheongbi.kro.kr/posts/troubleshooting/kis-api-phantom-fill-truth-verification/</guid><description>매도 주문 API가 성공 응답을 반환했다. 그런데 실제 체결이 되지 않았고, 시스템은 이미 체결로 기록했다. KIS API 응답과 실제 체결 사이의 간극, 그리고 이를 방어하는 KIS-truth 재검증 패턴을 정리했다.</description></item><item><title>연결 타임아웃 60초가 만든 요청 적체: httpx와 KIS API의 함정</title><link>https://blog.cheongbi.kro.kr/posts/troubleshooting/kis-api-httpx-timeout-amplification/</link><pubDate>Wed, 26 Aug 2026 00:00:00 +0000</pubDate><guid>https://blog.cheongbi.kro.kr/posts/troubleshooting/kis-api-httpx-timeout-amplification/</guid><description>KIS API 클라이언트에 connect timeout을 60초로 설정했더니, 연결이 느려지는 순간 요청이 수십 개 쌓였다. 타임아웃을 길게 잡을수록 안전하다는 착각이 만든 사고다.</description></item><item><title>WebSocket 구독 타이밍: 순서 하나가 만드는 1사이클 지연</title><link>https://blog.cheongbi.kro.kr/posts/troubleshooting/websocket-subscription-timing-one-cycle-delay/</link><pubDate>Wed, 29 Jul 2026 00:00:00 +0000</pubDate><guid>https://blog.cheongbi.kro.kr/posts/troubleshooting/websocket-subscription-timing-one-cycle-delay/</guid><description>신규 포지션을 잡은 직후 첫 번째 스케줄러 사이클에서 WebSocket 시세가 오지 않았다. 원인은 구독 동기화 함수의 호출 위치가 holdings 동기화보다 앞에 있었기 때문이다.</description></item><item><title>스케줄러 작업이 5주 동안 조용히 실패하고 있었다</title><link>https://blog.cheongbi.kro.kr/posts/troubleshooting/apscheduler-silent-failure-batch-job/</link><pubDate>Wed, 22 Jul 2026 00:00:00 +0000</pubDate><guid>https://blog.cheongbi.kro.kr/posts/troubleshooting/apscheduler-silent-failure-batch-job/</guid><description>APScheduler job이 매주 일요일 새벽 2시에 실행됐지만 전략 파라미터는 5주 동안 한 번도 업데이트되지 않았다. 에러는 있었다. 로그에도 찍혀 있었다. 그런데 왜 아무도 몰랐을까.</description></item></channel></rss>