내 봇이 새벽에 무슨 일을 했는지, 어떻게 아나

자동매매를 시작하는 분들이 가장 늦게 신경 쓰고, 사고가 터진 다음에야 뼈아프게 후회하는 것이 하나 있습니다. 기록입니다. 봇은 새벽 세 시에 혼자 일합니다. 우리가 자는 동안 신호를 읽고, 주문을 내고, 취소하고, 다시 냅니다. 그리고 봇은 자기가 무슨 일을 했는지 나중에 말해주지 않습니다. 남겨둔 기록이 없으면 없는 겁니다. 이 글은 코딩을 몰라도 "내 봇은 어떤 기록을 남겨야 하고, 나는 그걸 어떻게 읽어야 하나"를 판단할 수 있도록, 자동매매의 기록 체계를 처음부터 끝까지 쉬운 말로 정리합니다.

1. 봇에게는 기억이 없다 — 기록이 블랙박스인 이유

비행기에는 블랙박스가 있습니다. 사고가 났을 때 조종사에게 "그때 무슨 조작을 하셨죠?"라고 물어볼 수 없기 때문입니다. 자동매매도 정확히 같은 상황입니다. 어느 날 아침 계좌를 열었더니 없어야 할 포지션이 잡혀 있고, 있어야 할 현금이 줄어 있습니다. 봇에게 물어봐도 대답이 없습니다. 이때 우리가 기댈 수 있는 건 오직 하나, 그 순간 봇이 남겨둔 기록뿐입니다.

사람이 손으로 매매할 때는 기록의 부재가 그렇게 치명적이지 않습니다. 적어도 "아, 그때 뉴스 보고 급하게 샀지"라는 기억이 남으니까요. 물론 그 기억은 사후에 편집되고 미화되기 쉽습니다. 그런데 자동매매는 아예 기억할 사람이 없습니다. 봇은 초 단위로 수십 번 판단하고, 그 판단의 근거가 된 값(그때의 가격·지표·잔고)은 다음 순간이면 이미 다른 값으로 덮여 사라집니다. 기록하지 않은 순간은 영원히 복원할 수 없습니다.

이 점이 초보자에게 잘 와닿지 않는 이유는, 대부분 "거래소 앱에 거래내역이 다 나오잖아요?"라고 생각하기 때문입니다. 맞습니다. 그런데 거래내역은 결과만 알려줍니다. "07:31에 10주 매수 체결"이라고는 나오지만, "왜 07:31이었는지", "봇이 그때 무슨 값을 보고 그 판단을 했는지"는 어디에도 없습니다. 자동매매에서 진짜로 알고 싶은 건 대부분 후자입니다. 그래서 기록은 거래내역의 복사본이 아니라, 거래내역이 절대 답해주지 않는 질문에 답하기 위한 장치입니다.

2. 기록이 없으면 못 하는 일 여섯 가지

추상적으로 "기록이 중요하다"고 하면 잘 안 와닿습니다. 기록이 없을 때 실제로 못 하게 되는 일을 나열해 보면 훨씬 분명해집니다.

이 여섯 가지를 관통하는 공통점이 하나 있습니다. 전부 "나중에" 필요해진다는 것입니다. 그리고 나중이 왔을 때는 이미 기록을 남길 기회가 지나가 있습니다. 기록은 보험과 성격이 같습니다. 필요 없을 때 들어두는 것이고, 필요해진 순간에는 가입할 수 없습니다.

3. 기록은 한 종류가 아니다 — 3층 구조

"로그 남겨주세요"라고 뭉뚱그려 말하면 서로 다른 것을 상상하게 됩니다. 실무에서 자동매매의 기록은 서로 다른 질문에 답하는 세 개의 층으로 나눠 생각하면 훨씬 명확해집니다.

① 시스템 로그 — "봇이 살아 있었나"

가장 밑바닥의 기록입니다. 봇이 언제 켜졌고, 거래소와 연결이 몇 번 끊겼고, 어떤 오류가 났고, 몇 번 재시도했는지를 담습니다. 매매 성과와 직접 관련이 없어 보여서 소홀히 다루기 쉬운데, 실은 나머지 모든 기록의 신뢰성을 결정하는 층입니다. 새벽 두 시부터 네 시까지 봇이 죽어 있었다면, 그 시간대에 "거래가 없었다"는 사실은 전략이 관망한 게 아니라 봇이 자고 있었던 것이기 때문입니다. 이 구분을 못 하면 성과 분석 전체가 엉망이 됩니다. 장애 복구 플레이북이 다루는 세계가 바로 이 층입니다.

② 매매 기록 — "무엇을, 왜, 얼마에 샀나"

사람들이 "매매일지"라고 부르는 것에 가장 가까운 층입니다. 다만 손으로 쓰는 일지와 결정적으로 다른 점이 있습니다. 봇은 판단의 순간에 자기가 본 숫자를 그대로 박제할 수 있습니다. "20일 이동평균 62,340을 종가 62,700이 상향 돌파, 거래량 조건 충족, 잔고 대비 배분 3% → 매수 주문"처럼요. 사람이 나중에 회상해서 쓰는 일지는 이미 결과를 아는 상태에서 쓰기 때문에 왜곡되지만, 봇의 기록은 결과를 모르는 시점에 남습니다. 이게 자동매매가 가진 조용한 장점 중 하나입니다.

③ 성과 기록 — "그래서 어떻게 됐나"

일별 잔고, 보유 포지션 스냅샷, 실현·평가 손익, 누적 곡선 같은 요약값입니다. 매매 기록에서 계산해 낼 수도 있지만, 하루 한 번 '그날의 사진'을 따로 찍어두는 편이 훨씬 안전합니다. 나중에 매매 기록이 일부 유실되거나 계산 방식이 바뀌어도, 스냅샷은 그대로 남기 때문입니다. 여기서 보는 숫자를 어떻게 해석하는지는 백테스트 리포트 읽는 법과 상당 부분 겹칩니다. 다만 실거래 성과 기록은 백테스트 리포트와 달리 '다시 돌릴 수 없다'는 점이 다릅니다. 그날 안 찍어두면 그날의 사진은 영영 없습니다.

4. 한 번의 매매가 남기는 흔적 — 신호에서 정산까지

이제 층이 아니라 시간축으로 봅시다. 봇이 한 번 사고파는 동안, 기록해 둘 만한 지점이 여러 번 지나갑니다. 이 지점들을 놓치면 나중에 "어디서 어긋났는지"를 좁힐 수 없습니다.

이 그림에서 가장 중요한 대목은 오른쪽 아래 빨간 상자입니다. 자동매매의 사고 중 상당수는 "주문을 보냈는데 응답을 못 받은 상황"에서 생깁니다. 네트워크가 잠깐 끊기면 봇은 주문이 접수됐는지 알 수 없습니다. 이때 봇이 "실패했나 보다" 하고 다시 보내면 같은 주문이 두 번 들어갑니다. 반대로 "들어갔겠지" 하고 넘어가면 사야 할 걸 못 삽니다. 어느 쪽이든, 나중에 무슨 일이 있었는지 밝히려면 내가 보낸 주문마다 붙인 고유번호와 거래소가 돌려준 주문번호가 짝지어 기록돼 있어야 합니다. 이 두 개가 없으면 계좌에 찍힌 두 건이 "봇이 두 번 보낸 것"인지 "한 번 보낸 게 두 번 체결된 것(부분체결)"인지 영원히 알 수 없습니다.

5. 거래소 내역이 있는데 왜 내 기록도 필요한가 — 대조의 힘

여기서 한 걸음 더 들어가 봅시다. "봇도 기록하고 거래소도 기록하면 중복 아닌가요?"라는 질문이 나올 차례입니다. 답은 중복이 아니라 대조입니다. 그리고 이 대조가 실무에서 봇의 이상을 가장 빨리 잡아내는 방법입니다.

둘 다 불완전합니다. 그래서 실무에서는 매일 한 번 둘을 맞춰봅니다. 회계에서 장부와 통장을 대조하는 것과 똑같은 개념입니다. 봇이 생각하는 보유 수량과 거래소가 알려주는 실제 보유 수량이 같은가? 봇이 기록한 오늘의 체결 건수와 거래소 내역의 건수가 같은가? 현금 잔고는 어떤가?

이 대조가 강력한 이유는, 봇의 오작동이 손실로 드러나기 전에 먼저 신호를 준다는 데 있습니다. 봇이 "나는 3주를 들고 있다"고 믿는데 실제로는 6주를 들고 있다면, 그 자체로는 아직 손실이 아닙니다. 하지만 그 상태로 계속 돌면 손절 계산도, 추가 매수 계산도 전부 틀린 수량으로 이뤄집니다. 대조는 이 어긋남을 손실이 되기 전에 잡습니다.

6. 좋은 기록의 일곱 가지 요건

그냥 많이 남긴다고 좋은 기록이 아닙니다. 정작 필요할 때 못 찾는 기록은 없는 것과 같습니다. 실무에서 통용되는 요건을 일곱 가지로 추려 봅니다.

① 시간 — 언제인지, 어느 시간대인지

모든 기록의 첫 칸은 시각입니다. 그런데 여기서 놀랍도록 자주 사고가 납니다. 시간대(타임존)를 안 적어두는 것입니다. 서버는 세계 표준시(UTC)로, 화면은 한국시간(KST)으로 보여주는 구성이 흔한데, 기록에 "09:31"이라고만 적혀 있으면 이게 아침 9시 31분인지 저녁 6시 31분인지 나중엔 아무도 모릅니다. 코인처럼 24시간 돌아가는 시장이나 한국 시간으로 밤에 열리는 미국 시장에서는 이 혼선 하나로 손익 집계일이 하루씩 밀리기도 합니다. 기록의 시각은 시간대를 함께 적거나, 전부 하나의 기준으로 통일해야 합니다.

② 고유 번호 — 주문 하나를 끝까지 따라갈 실

앞에서 본 '송장번호'입니다. 봇이 주문을 만들 때 자기만의 번호를 붙이고, 그 번호를 신호·요청·응답·체결·청산까지 모든 줄에 함께 적어두면, 나중에 그 번호 하나로 한 거래의 일생을 통째로 뽑아볼 수 있습니다. 이게 없으면 수천 줄 로그에서 시각만 보고 눈으로 짜맞춰야 합니다.

③ 원인과 결과의 연결

"매수 주문 전송"만 적힌 기록은 절반짜리입니다. 그 순간 봇이 본 값이 함께 있어야 합니다. 가격, 지표값, 조건 충족 여부, 계산된 수량, 사용한 잔고 비율. 이게 있어야 나중에 "그때 그 판단이 설계대로였나"를 검증할 수 있습니다. 기록이 곧 규칙이 제대로 작동했는지에 대한 증거가 되는 셈입니다.

④ 사람도 읽고, 기계도 읽게

기록은 두 가지 용도로 쓰입니다. 사람이 눈으로 훑어보는 용도(사고 났을 때), 그리고 표 계산 프로그램이나 분석 도구로 불러들이는 용도(성과 분석·세금 정리)입니다. 그래서 줄글 형태의 로그 파일과 표 형태의 거래 파일(CSV 등)을 함께 남기는 구성이 편합니다. 하나만 있으면 다른 용도에서 매번 고생합니다.

⑤ 남기면 안 되는 것 — 열쇠는 절대 기록하지 않는다

⑥ 보관과 백업 — 서버가 날아가면 기록도 날아간다

기록이 봇과 같은 서버에만 있으면, 그 서버가 죽는 순간 사고의 원인과 증거가 함께 사라집니다. 그리고 서버가 죽는 사고야말로 원인을 가장 알고 싶은 사고입니다. 그래서 매매 기록과 일별 요약만큼은 다른 곳(다른 저장소·클라우드 드라이브·메일 등)으로 주기적으로 복사해 두는 편이 좋습니다. 24시간 서버 운영을 설계할 때 함께 정해두면 자연스럽습니다.

⑦ 용량 관리 — 기록이 봇을 죽이지 않게

기록은 계속 쌓입니다. 관리하지 않으면 디스크가 가득 차고, 디스크가 가득 차면 프로그램이 파일을 쓰지 못해 멈춥니다. 그래서 일정 크기나 기간마다 새 파일로 갈아 끼우고 오래된 것은 압축·삭제하는 회전(rotation) 설정이 필요합니다. 이건 비개발자가 직접 할 일은 아니지만, "로그 회전 설정돼 있나요?"라고 물어볼 줄은 알아야 합니다. 이 질문 하나가 몇 달 뒤의 새벽 정지 사고를 막습니다.

보너스 — 어디에 저장하나 (파일·표 파일·데이터베이스)

"기록을 어디에 담느냐"는 개발자가 정할 문제 같지만, 발주자가 알아두면 대화가 훨씬 편해집니다. 실무에서 쓰는 선택지는 대개 세 가지입니다.

정답은 없고, 거래 빈도와 전략 개수에 따라 갈립니다. 하루 몇 건 수준이면 로그 파일과 CSV 조합으로 충분한 경우가 많고, 초 단위로 매매하거나 여러 전략을 한 계좌에서 돌린다면 데이터베이스 쪽이 편해집니다. 여기서 발주자가 할 일은 방식을 고르는 게 아니라, "제가 나중에 이 기록을 엑셀로 열어볼 수 있나요?"라고 확인하는 것입니다. 이 한 질문이 실질적으로 가장 중요합니다. 아무리 정교한 구조라도 내가 열어볼 수 없으면, 내 봇의 기록이 아니라 업체의 기록입니다.

덧붙여, 봇이 여러 대이거나 계좌가 여럿이라면 기록에 "어느 봇·어느 계좌·어느 전략"을 반드시 함께 남겨야 합니다. 나중에 합쳐서 볼 때 이 세 칸이 없으면 거래들이 뒤섞여 분리가 불가능해집니다. 실제로 전략을 하나 더 붙인 뒤에야 이걸 깨닫고, 그동안의 기록을 통째로 못 쓰게 되는 경우가 꽤 있습니다.

7. 로그 레벨 — 비개발자를 위한 번역

업체가 보내준 로그를 열면 줄마다 앞에 대문자 단어가 붙어 있습니다. INFO, WARNING, ERROR 같은 것들입니다. 이걸 로그 레벨이라고 부르는데, 쉽게 말해 "이 줄이 얼마나 급한 이야기인가"를 표시한 등급입니다. 뜻만 알면 로그를 훨씬 덜 무섭게 볼 수 있습니다.

여기서 초보가 가장 자주 하는 질문이 있습니다. "ERROR가 매일 몇 줄씩 나오는데 정상인가요?" 답은 "종류에 따라 다르다"입니다. 네트워크가 잠깐 흔들려 재접속하는 정도는 24시간 돌아가는 시스템에서 드물지 않고, 대부분 자동으로 회복됩니다. 문제는 새로운 종류의 오류이거나 빈도가 갑자기 늘어난 오류입니다. 그래서 실무에서 봐야 할 것은 "오류가 있느냐"가 아니라 "어제와 달라진 게 있느냐"입니다. 이 기준을 잡아두면 로그 공포증이 사라집니다.

8. 실전에서 기록이 무너지는 다섯 가지 방식

"기록 남기고 있습니다"라는 말을 들었는데도 정작 필요한 순간 아무 도움이 안 되는 경우가 있습니다. 다음 다섯 가지가 대표적입니다.

이 중에서 특히 ③번은 되짚어볼 만합니다. 기록을 파일로 남기지 않고 프로그램 메모리에만 들고 있으면, 평소에는 아무 문제가 없어 보입니다. 화면에도 잘 나오고 조회도 됩니다. 그런데 봇이 비정상 종료되는 순간 그 직전 몇 분의 기록이 통째로 증발합니다. 하필 그 몇 분이 우리가 가장 알고 싶은 구간입니다. 그래서 "기록이 되나요"보다 "봇이 죽어도 남나요"가 더 정확한 질문입니다.

9. 기록을 '읽는' 법 — 매일·매주·매월 점검 루틴

기록을 남겨두는 것과 읽는 것은 별개입니다. 대부분은 남겨만 두고 안 봅니다. 현실적으로 지킬 수 있는 수준으로 주기를 나눠보면 이렇습니다.

성과 기록에서 먼저 볼 것은 수익률이 아니다

여기서 중요한 태도 하나. 성과 기록을 열면 누구나 제일 먼저 손익 숫자로 눈이 갑니다. 하지만 기록의 일차적 용도는 "설계대로 작동했는가"를 확인하는 것이지 성적표를 확인하는 게 아닙니다. 실제로 더 유용한 질문은 이런 것들입니다.

• 백테스트에서 기대한 거래 횟수와 실제 거래 횟수가 비슷한가? (크게 다르면 신호 조건이 실전에서 다르게 작동하고 있다는 뜻)
• 신호가 발생한 값과 실제 체결된 값의 차이가 가정보다 크지 않은가? (슬리피지가 예상보다 크면 전략의 기대치 자체가 흔들립니다)
• 미체결로 놓친 신호가 얼마나 되는가? (주문 유형 선택이 실전과 안 맞는다는 신호일 수 있습니다)
• 수수료와 세금을 뺀 뒤에도 가정했던 구조가 유지되는가?

이 항목들은 전부 "돈을 얼마 벌었나"가 아니라 "내 봇이 내가 만든 설계대로 굴러가고 있나"를 묻습니다. 그리고 이 질문에 답할 수 있어야, 손실이 났을 때 참을지·끌지·고칠지를 감이 아니라 근거로 결정할 수 있습니다. 기록이 없으면 그 결정은 결국 그날의 기분으로 내려집니다.

직접 볼까, 맡길까 — 현실적인 타협점

여기까지 읽고 "매일 로그를 들여다볼 자신이 없다"고 느끼셨다면, 그게 정상입니다. 대부분의 발주자는 본업이 따로 있고, 자동매매를 맡기는 이유 자체가 시간을 아끼기 위해서입니다. 그래서 현실적인 타협점은 "모든 걸 직접 보기"와 "아예 안 보기" 사이에 있습니다.

핵심은 "내가 볼 것"과 "받아만 볼 것"을 처음부터 나눠두는 것입니다. 이 구분 없이 "다 보내주세요"라고 하면, 첫 주에는 열심히 보다가 둘째 주부터 안 열게 되고, 결국 알림도 기록도 무용지물이 됩니다. 반대로 하루 한 줄짜리 요약만이라도 꾸준히 확인하면, 봇이 조용히 죽어 있는 상황은 거의 확실하게 하루 안에 잡힙니다. 점검을 통째로 넘기고 싶다면 사후관리 형태로 위탁하는 방법도 있지만, 그 경우에도 "이상이 있으면 나에게 언제 어떻게 알려주는가"는 계약서에 남겨두시길 권합니다.

10. 세금과 정산에 쓰이는 기록

운영 목적 외에 기록이 반드시 필요해지는 순간이 또 있습니다. 세금과 정산입니다. 자동매매는 사람 손매매보다 거래 건수가 훨씬 많아질 수 있어서, 연말에 몰아서 정리하려 들면 생각보다 큰 작업이 됩니다.

실무에서 미리 챙겨두면 좋은 것은 세 가지입니다. 첫째, 거래소·증권사의 공식 거래내역을 주기적으로 내려받아 보관하는 것. 조회 가능 기간이나 다운로드 범위에 제한이 있을 수 있으므로, 시간이 한참 지난 뒤에 찾으면 곤란해질 수 있습니다. 둘째, 내 봇의 매매 기록을 표 형태로 함께 남겨두는 것. 공식 내역에 없는 맥락(어떤 전략의 거래였는지, 어떤 계좌·어떤 봇인지)을 붙일 수 있습니다. 셋째, 수수료를 따로 집계해 두는 것입니다.

11. 업체를 바꿀 때, 기록이 곧 자산이다

의외로 많이 겪는 상황입니다. 처음 만든 업체와 연락이 끊기거나, 다른 곳에 개선을 맡기게 됩니다. 이때 새 담당자가 가장 먼저 요구하는 게 무엇일까요? 소스코드도 물론이지만, 실무에서 더 결정적인 건 실제 운영 기록입니다.

코드는 "이렇게 작동하도록 만들어졌다"를 보여주지만, 기록은 "실제로 이렇게 작동했다"를 보여줍니다. 둘은 자주 다릅니다. 어떤 오류가 반복되는지, 어떤 조건에서 미체결이 잦은지, 어느 시간대에 응답이 느린지는 코드만 봐서는 알 수 없고 기록에만 남아 있습니다. 그래서 기록이 잘 남아 있는 봇은 인수인계가 며칠이면 끝나고, 없는 봇은 새로 몇 주를 관찰해야 합니다. 그 관찰 기간은 고스란히 비용입니다.

같은 이유로, 제작을 맡길 때 기록의 소유와 접근 권한도 함께 정해두는 게 좋습니다. 로그가 업체 서버에만 쌓이고 내가 볼 수 없다면, 그건 내 봇의 블랙박스를 남이 들고 있는 상태입니다. 계약 관점의 논의는 소스코드 소유권·에스크로 편과 외주 체크리스트에서 함께 보시면 좋습니다.

12. 명세서에 넣을 '기록 사양' 8줄

여기까지 읽으셨다면, 이제 명세서에 무엇을 적어야 할지가 꽤 분명해졌을 겁니다. 아래 여덟 줄을 그대로 채워서 전달하면, 기록 때문에 나중에 곤란해질 확률이 크게 줄어듭니다.

이 여덟 줄이 특별히 어려운 요구가 아니라는 점이 중요합니다. 대부분 제작 단계에서 처음부터 넣으면 추가 비용이 크지 않은 항목들입니다. 반대로 완성된 뒤에 "기록을 추가해 주세요"라고 하면, 이미 흘러간 데이터는 복구할 수 없는 데다 구조를 손봐야 해서 유지보수 비용이 붙습니다. 순서가 곧 비용입니다.

13. 자주 하는 실수 6가지

14. 시나리오 3가지 — 기록이 결과를 갈랐던 순간

시나리오 A. 새벽에 두 번 산 봇

아침에 계좌를 열었더니 같은 종목이 두 번 매수돼 있습니다. 기록이 없는 경우, 할 수 있는 일은 추측뿐입니다. "전략이 두 번 신호를 냈나?" 하고 조건을 바꿨다가 오히려 전략을 망가뜨립니다. 기록이 있는 경우는 다릅니다. 로그를 열면 03:12에 주문을 보냈고, 03:12:04에 응답 대기 시간이 초과됐고, 03:12:09에 재시도했으며, 결국 두 건 다 접수됐음이 보입니다. 원인은 전략이 아니라 통신 타임아웃과 재시도 처리였습니다. 고칠 곳이 전혀 다릅니다. 이 차이가 기록의 값어치입니다.

시나리오 B. "성과가 나쁘다"는 착각

한 달 성과가 기대에 못 미쳐 전략을 바꾸려 합니다. 그런데 시스템 로그를 보니 그 달의 절반은 봇이 꺼져 있었습니다. 서버가 재부팅된 뒤 봇이 자동 실행되지 않았고, 아무도 몰랐던 것입니다. 이 경우 성과가 나쁜 게 아니라 애초에 전략이 실행된 적이 없는 겁니다. 기록이 없었다면 멀쩡한 전략을 버리고 새로 만들었을 상황입니다. 백테스트와 실거래의 괴리를 진단할 때, 가장 먼저 배제해야 할 원인이 바로 이런 '실행 자체의 공백'입니다.

시나리오 C. 업체와의 다툼

손실이 나자 발주자는 "봇이 잘못 매매했다"고 하고, 업체는 "시장이 그랬을 뿐 설계대로 작동했다"고 합니다. 기록이 없으면 이 논쟁은 영원히 끝나지 않습니다. 반대로 신호 근거와 주문·체결이 모두 남아 있으면 판정은 대개 몇 시간이면 끝납니다. 설계대로였다면 발주자가 납득하고, 아니었다면 업체가 고칩니다. 기록은 어느 한쪽 편이 아니라 양쪽 모두를 지키는 장치입니다.

15. 흔한 오해 5가지

16. 한 장 요약

자동매매를 맡기는 분들이 가장 많이 물어보는 것은 "얼마나 벌 수 있나요"입니다. 하지만 몇 달 뒤 실제로 발목을 잡는 것은 거의 언제나 "그때 무슨 일이 있었는지 모르겠다"는 문제입니다. 기록은 화려하지 않고, 성과에 직접 보태지도 않습니다. 그저 이상이 생겼을 때 원인을 찾을 수 있게 해줄 뿐입니다. 그런데 자동으로 돌아가는 시스템에서는 바로 그 능력이, 오래 살아남는 봇과 몇 달 만에 방치되는 봇을 가릅니다.

자주 묻는 질문