🛑 2026-10-29 코인 자동매매 일지: 매매 0건, 봇이 밤새 조용히 죽은 원인과 진단 기록

📌 오늘 한 일 요약

• 매매 0건의 원인이 매수 조건 미달이 아니라 감독·작업 프로세스 중단이었음을 확인
• 마지막 정상 사이클(10/28 22:54:07, 299개 종목 판단 완료) 이후 감독 로그에 권한 오류(PermissionError)가 남고 상태 갱신이 끊긴 것을 확인. 최초 종료 원인은 오류 경로·코드가 없어 미확정
• 일일 TXT 보고서 KeyError, Upbit 조회 오류, D 진입 조건 미달은 직접적인 종료 원인이 아니라고 판단함
• 사용자가 다시 시작한 새 실행에서 프로세스 시작과 초기 복구 진입을 확인함. 정상 스캔 완료 여부는 추가 확인이 필요함
• 감독·작업자·관리 명령의 오류 단계, 오류 코드, 중지 사유를 구분해 남기는 종료 진단 기록을 추가함
• 2차 실패가 일어나도 최초 오류가 보존되도록 수정함. 파일 재시도 정책과 거래 안전 조건은 유지함
• 오프라인 테스트 418개 통과를 확인하고, Windows 테스트용 대기 시간을 조정함

📑 목차

• 🛑 매매 0건, 이번엔 조건 탓이 아니었다
• 🔍 분석하는 동안은 아무것도 건드리지 않았다
• 🧩 코드를 읽고 세운 가설, 끝내 확정하지 못한 것
• 🔄 봇은 분석과 별개로 내가 다시 켰다
• 🛠️ 분석이 끝난 뒤에야 코드를 고쳤다

🛑 매매 0건, 이번엔 조건 탓이 아니었다

오늘 매매는 0건이다. 보통 0건이면 진입 조건이 맞지 않아서 봇이 HOLD를 냈다는 뜻이다. HOLD는 사지 않고 기다린다는 판정이다. 이번에는 그 판정을 내릴 봇이 없었다. 저장해 둔 PID로 찾아봤는데 감독 프로세스도 작업 프로세스도 보이지 않았다. PID는 운영체제가 실행 중인 프로그램마다 붙이는 번호다. 내 봇은 두 겹으로 돌아간다. 감독(supervisor)이 작업자(worker)를 띄우고 지켜보고, 작업자가 실제로 시장을 훑어서 살지 말지를 정한다. 둘 다 사라졌으니 오늘 날짜 로그가 하나도 생기지 않은 건 당연했다.

상태 파일을 보고 더 찝찝해졌다. 봇이 자기 상태를 주기적으로 적어 두는 파일인데, 거기에 아직 RUNNING(실행 중)이 남아 있었다. 마지막으로 갱신된 건 10월 28일 22:54:59였다. 그 뒤로는 아무도 이 파일을 고치지 않았다는 얘기다. "자동 재시작 0회"라는 숫자도 그대로였다. 이 0은 아무 문제가 없었다는 뜻이 아니다. 재시작을 해 줄 감독이 이미 없어서 0으로 남았을 뿐이다. 숫자가 멀쩡해 보인다고 상황이 멀쩡한 건 아니라는 걸 또 배웠다.

---

🔍 분석하는 동안은 아무것도 건드리지 않았다

원인을 찾기 전에 규칙부터 정했다. 파일과 코드, 조회되는 프로세스 정보만 읽는다. 실행·재시작·종료, 상태 파일이나 잠금 파일 삭제, 권한 변경, 실제 주문은 하지 않는다. 현장을 치우면서 조사하면 증거도 같이 사라지기 때문이다. 이 단계에서 나온 건 분석 문서와 README 기록뿐이고 프로그램 코드는 그대로 뒀다. 끝나고 네트워크를 끊은 상태에서 테스트를 돌렸고 407개가 통과했다. 코드를 바꾸지 않았으니 깨진 것도 없다는 걸 확인하는 정도였다.

로그를 따라가 보면 작업 프로세스는 28일 09:01:35에 시작됐다. 바로 앞인 09:01:32~33에 재시작 요청 기록이 있었다. 다만 이건 원래 있던 요청이고, 밤에 봇이 멈출 무렵 새로 생긴 중지 요청은 아니다. 이 기록으로 말할 수 있는 건 거기까지다.

밤 22:51:28 작업 로그에는 KeyError가 하나 찍혔다. 파이썬에서 딕셔너리에 없는 키를 찾을 때 나는 오류다. 사람이 읽는 일별 TXT 보고서를 갱신하다가 났고, JSONL 기록은 그대로 유지된다는 메시지도 같이 남았다. JSONL은 거래 기록을 한 줄에 하나씩 적는 기계용 형식이다. 3분 뒤인 22:54:07에는 "299 markets, 299 strategies, 299 decisions"로 사이클이 정상 완료됐다. 마켓 299개를 보고 299개 모두에 전략을 돌려서 판정을 299개 냈다는 뜻이다. 그러니 KeyError가 봇을 멈췄다고 보기는 어렵다. 거래 판단 루프에도 치명적인 예외는 없었다.

남은 단서는 감독 로그 맨 끝에 있는 "관리 명령 실패 (PermissionError)" 한 줄이었다. PermissionError는 파일 접근을 거부당했을 때 나는 오류다. 그런데 이 줄에는 시각도, 어떤 파일이었는지도, 윈도우 오류 번호도, 어디서 호출됐는지(스택)도 없었다. 로그 파일의 수정 시각은 28일 22:55:04였다. 하지만 이건 파일이 마지막으로 바뀐 시각이지 그 줄이 찍힌 시각이 아니어서 판단 근거로 쓰지 않았다.

---

🧩 코드를 읽고 세운 가설, 끝내 확정하지 못한 것

코드를 따라가면서 그럴듯한 경로를 그려 봤다. 감독은 상태 파일을 원자적 교체 방식으로 저장한다. 임시 파일에 다 쓴 다음 한 번에 바꿔치기해서 반쯤 쓰인 파일이 남지 않게 하는 방식이다. 접근이 거부되면 10ms 간격으로 5번 다시 시도하고, 그래도 안 되면 오류를 위로 올린다. 오류가 나면 감독은 상태를 FAILED로 저장하려고 한다. 그런데 처음부터 상태 파일 접근이 문제였다면 이 저장도 실패하고, RUNNING이 그대로 남는다. 오늘 본 모습과 맞아떨어진다.

작업자 쪽에도 스스로 멈추는 길이 있다. 작업자는 거래하기 전에 감독이 살아 있는지 확인한다. 감독은 "나 살아 있다"는 신호를 주기적으로 갱신하는데, 이 갱신이 30초 넘게 끊기면 부모 lease가 만료됐다고 본다. 실행 식별자가 바뀌어도 멈춘다. 실행 식별자는 봇을 띄울 때마다 새로 붙는 번호인데, 이게 바뀌면 지금 작업자가 더 이상 그 실행 소속이 아니라는 뜻이다. 중지 요청이 있거나 부모 상태를 읽지 못해도 거래를 멈추고 빠져나온다. 문제는 이 경로가 정상 종료처럼 처리돼서 멈춘 이유가 따로 남지 않을 수 있다는 점이다. 작업 로그가 깔끔하게 "사이클 완료"로 끝나 있어도 이렇게 멈췄을 수 있다.

그래서 가장 유력한 그림은 이렇다. 감독이 파일 접근 오류로 죽었고, 작업자는 감독이 정리했거나 부모 lease가 끊긴 걸 보고 따라서 멈췄다. 하지만 상태 파일을 쓰다가 공유 잠금이 충돌했다는 건 어디까지나 가능성이지 입증된 게 아니다. 관리 명령의 다른 파일 작업이나 외부 종료가 끼어들었을 수도 있다. PC 재부팅이나 절전도 마찬가지다. 윈도우 이벤트를 조회했을 때 그 시간대에 충돌·종료 기록은 안 나왔다. 하지만 조회 권한에 제한이 있었기 때문에 OS 쪽에서는 아무 일도 없었다고까지 말할 수는 없다. 지금 파일 권한이 정상이라고 해서 그 순간 잠깐 잠겨 있지 않았다는 증명도 되지 않는다.

반대로 아니라고 볼 근거가 있는 것도 있었다. D 전략의 진입 조건이 안 맞으면 HOLD로 처리될 뿐 프로세스를 끄지 않는다. 업비트 조회 오류도 마지막 로그에는 정상 조회와 완료 기록만 있었다.

솔직히 답답했다. 결정적인 줄은 있는데 그 줄에 쓸 만한 정보가 없었다. 최상위 예외 처리에서 오류 내용은 빼고 종류만 찍게 해 둔 건 민감정보를 남기지 않으려던 의도였다. 그 선택이 이번에는 내 발목을 잡았다. 이 한 줄만 보고 "내가 보낸 재시작 명령이 원인"이라고 단정해서도 안 된다. 감독 내부 프로세스의 오류 출력도 같은 로그로 흘러들어가서, 이런 일반적인 실패 문장은 다른 이유로도 찍힐 수 있다.

---

🔄 봇은 분석과 별개로 내가 다시 켰다

봇은 22:40:39에 내가 직접 다시 띄웠다. 분석 작업은 이 실행을 띄우지도 멈추지도 않았고, 새로 생긴 감독 로그와 상태만 읽었다. 확인했을 때 작업 상태는 RECOVERING이었고 완료 사이클 0, 마지막 성공 기록은 없었다. RECOVERING은 시작 직후 이전 기록과 거래소 상태를 맞춰 보는 복구 단계다. 그러니 확인된 건 프로세스가 뜨고 복구에 들어갔다는 것까지다. 시장을 훑고 판정까지 냈다는 뜻은 아니다. 정상이라고 말하려면 "Startup synchronization: READY" 로그가 찍혀야 한다. READY는 초기 동기화가 끝나서 거래 판단을 시작할 수 있다는 표시다. 여기에 새 날짜 로그와 완료 사이클 증가까지 봐야 한다.

그리고 이 22:40 실행에 아래에서 말할 새 진단 코드가 들어갔는지는 29일 기록만으로는 확인되지 않는다. 이 확인은 30일 일지로 넘겼다.

---

🛠️ 분석이 끝난 뒤에야 코드를 고쳤다

분석 문서에는 개선안을 다섯 개 적어 뒀다.

• 1. 감독 오류를 시각, 단계, 어떤 역할의 파일이었는지, 오류 종류, errno/winerror와 함께 따로 남긴다. errno/winerror는 운영체제가 돌려주는 숫자 오류 코드다.
• 2. FAILED 저장까지 실패하는 경우에도 진단 기록을 남기되, 처음 오류를 가리지 않게 한다.
• 3. 작업자가 멈춘 이유를 lease 만료, 소유권 변경, 명시적 중지, 상태 읽기 실패로 나눠서 남긴다.
• 4. 실제 윈도우 공유 충돌 오류 코드를 먼저 확보하고, 그다음에 쓰기 재시도 정책을 검토한다.
• 5. KeyError는 종료 건과 떼어서 따로 검수한다.

여기까지가 분석 범위였다. 구현은 그 뒤에 따로 요청해서 진행했다. 이제 감독·작업자·관리 명령이 오류 단계, 파일 역할, 오류 코드, 재시도 횟수, 종료 코드를 프로세스별 진단 파일에 한 줄씩 남긴다. 예외 원문, 환경변수, 자격증명은 남기지 않는다. 진단 파일 쓰기마저 실패하면 오류 출력에 대신 남기고, FAILED 저장이나 정리 작업이 연달아 실패해도 처음 오류는 보존한다. 거래 중단, 잠금, 중복 실행 방지, 거래 원장의 원자적 저장은 그대로다. 5회·10ms 재시도와 운영 진행 제한도 바꾸지 않았다.

4번은 일부러 손대지 않았다. 실제 오류 코드도 모르는 상태에서 재시도 횟수를 늘리는 건 감으로 고치는 것과 같다. 권한을 한꺼번에 풀거나 잠금 파일을 지우는 것도 하지 않는다.

테스트는 일부러 장애를 일으켜 보는 테스트 11개를 새로 넣어서 418개가 됐다. 오류 코드는 남고 민감정보는 빠지는지, 진단 파일이 실패해도 대체 기록이 남는지, 멈춘 이유가 구분되는지, 연달아 실패해도 처음 오류가 남는지를 확인한다. 중간에 한 번 꼬였다. 윈도우에서 테스트용 자식 프로세스가 1.5초 안에 초기화를 끝내지 못했고, 그 바람에 watchdog이 발동했다. watchdog은 멈춘 프로세스를 강제로 재시작시키는 감시 장치다. 그래서 재시작이 한 번 더 일어나거나 시작 횟수 기록이 빠졌다. 웃긴 건 이걸 알아챈 게 방금 넣은 진단 기록 덕분이었다는 점이다. 그래서 테스트용 진행 기한은 5초, 검증 대기는 20초로 늘렸다. 실제 운영의 900초 진행 제한과 30초 부모 lease는 그대로다.

오늘 배운 건 단순하다. 로그는 사고가 났을 때 읽으라고 남기는 건데, 정작 사고 순간의 한 줄이 비어 있었다. 민감정보를 숨기는 일과 원인을 남기는 일은 따로 설계해야 했다. 다음 할 일은 세 가지다. 다시 띄운 봇에서 READY와 사이클 증가를 확인하는 것, 다시 멈추면 진단 파일에서 실제 오류 코드를 읽고 그때 재시도 정책을 검토하는 것, 그리고 KeyError 때문에 일별 보고서에 빠진 부분이 없는지 거래 기록과 따로 확인하는 것이다.

---

📚 함께 읽으면 좋은 글

• 📉 10월 27일 코인 자동매매 일지: 판단 14만 건, 매수 0건, 새 매도 규칙 7전 7패
• 📊 10월 26일 코인 자동매매 일지: 후보 244건 진입 0건, 전부 샀다면 어땠을까 계산해봤다

---

⚠️ 이 글은 개인 자동매매 프로그램의 개발·운영 기록이며 투자 권유가 아닙니다. 암호화폐는 원금 손실 위험이 큰 자산이고, 글에 나온 전략·수치는 과거 기록일 뿐 미래 수익을 보장하지 않습니다. 투자 판단과 책임은 본인에게 있습니다.