비개발자 자동매매 만들기, 코드는 AI가 규칙은 사람이

이 블로그의 자동매매 시스템은 개발자가 아닌 사람이 AI와 함께 만들었습니다. 코드는 AI가 작성했지만, 무엇을 만들지, 언제 멈출지, 어떻게 검증할지는 처음부터 끝까지 사람이 정했습니다. "AI가 다 해준다"는 광고와 실제로 해 본 과정이 어떻게 다른지, 만든 순서대로 정리했습니다.

사람이 정한 것, AI가 한 것

먼저 역할을 나눠 보면 이렇습니다.

• 사람이 정한 것: 시스템이 지켜야 할 한 문장의 원칙, 어떤 계좌에서 무엇을 거래할지, 각 단계의 판단 기준, 실계좌로 넘어갈지 말지, 문제가 생겼을 때 멈출지 말지
• AI가 한 것: 요구사항을 단계로 나눈 계획, 코드 작성, 테스트 작성과 실행, 작성한 코드에 대한 검토, 진행 기록 정리

정리하면 AI는 "어떻게"를 맡고, 사람은 "무엇을"과 "언제 멈출지"를 맡았습니다. 코드를 직접 짜지 않아도, 이 시스템이 무엇을 해야 하고 무엇을 하면 안 되는지는 사람이 가장 잘 알고 있어야 했습니다.

비개발자가 자동매매를 만든 순서

시스템 A를 기준으로, 실제로 거친 순서는 다음과 같습니다.

첫째, 한 문장의 원칙을 정했습니다. "시장이 나쁠 때 계좌를 지키는 것이 시장이 좋을 때 수익을 내는 것보다 우선한다." 이후의 모든 결정은 이 문장과 부딪히는지로 판단했습니다.

둘째, 요구사항을 적고 단계를 나눴습니다. 데이터 수집, 판단과 백테스트, 거래소 연결과 주문, 장부와 잔고 대조, 안전장치, 스케줄과 알림, 설정 관리까지 일곱 단계였습니다. 이 블로그에서 말하는 여섯 칸의 뼈대가 여기서 나왔습니다.

셋째, 단계마다 사람이 정할 것을 먼저 정했습니다. 예를 들어 백테스트 단계에 들어가기 전에 거래 비용을 얼마로 가정할지, 사양서 숫자와 결과가 다르면 어떻게 할지를 먼저 결정해 문서로 남겼습니다. "숫자에 맞춰 규칙을 고치지 않는다"는 원칙도 이때 되돌릴 수 없는 결정으로 적어 두었습니다. AI는 이 결정 문서를 기준으로 계획을 세우고 코드를 짰습니다.

넷째, AI가 계획, 구현, 테스트, 검토를 돌렸습니다. 단계 하나가 끝날 때마다 무엇을 만들었고 어떤 테스트가 통과했는지 요약이 남았고, 사람은 그 요약을 읽고 다음 단계로 넘어갈지 정했습니다. 테스트 코드는 AI가 짜지만, 무엇을 테스트해야 하는지는 위험한 상황을 말로 설명하는 데서 나옵니다. 예를 들어 "과거를 돌리는 백테스트 코드가 실수로 실제 주문 기능을 불러올 수는 없는가"라는 질문은 백테스트 코드가 주문·장부·안전장치 쪽 코드를 아예 불러오지 못하게 막고, 그것을 매번 검사하는 테스트가 됐습니다. 코드를 읽지 못해도 위험한 상황을 말로 설명할 수는 있고, 그 설명이 곧 테스트가 됩니다.

다섯째, 모의, 테스트넷, 소액, 정식 운용 순서로 실계좌에 넣었습니다. 단계를 넘길지는 매번 사람이 결정했습니다. 단타 시스템은 실계좌 첫 주를 금액과 종목 수를 제한한 운용으로 돌렸는데, 이 제한 운용과 해제도 사람이 승인한 기록이 남아 있습니다.

비개발자가 AI와 자동매매를 만든 순서

실제로 있었던 일: AI가 틀린 결론을 자신 있게 냈다

AI와 함께 만들 때 가장 조심해야 하는 순간은 AI가 그럴듯한 설명을 내놓을 때였습니다. 폐기한 모멘텀 스윙 시스템에서 이런 일이 있었습니다.

백테스트 결과가 참고한 명세보다 훨씬 나쁘게 나오자, AI 세션은 "코드에는 문제가 없고, 과거에 사라진 종목까지 포함해 계산했기 때문"이라고 결론을 냈습니다. 설명은 그럴듯했고, 실제로 그런 편향은 흔한 원인이기도 합니다. 그런데 그 결론을 그대로 받아들이지 않고 다시 확인을 요청했습니다. 원인을 하나씩 다시 뜯어보니 구현 결함이 네 개 나왔습니다. 특정 조건에서 들어간 포지션이 영원히 빠져나오지 못하는 문제, 명세에 없던 매도 지연, 걸러지지 않은 종목, 빠진 거래량 조건이었습니다. 이 중 매도 지연은 AI가 명세의 규칙을 임의로 해석해 넣은 것이었습니다. (근거: 폐기한 모멘텀 스윙 시스템의 백테스트 괴리 분석 기록)

이 일 이후로 AI의 설명은 결론이 아니라 가설로 다룹니다. "왜 그런가"에 대한 AI의 답이 나오면, 그 답을 확인할 수 있는 테스트나 재현을 함께 요구합니다. 코드를 읽지 못해도 "그 설명이 맞다는 것을 무엇으로 확인했는가"는 물을 수 있습니다.

코딩을 몰라도 알아야 하는 것

"코딩을 몰라도 된다"는 말은 "공부하지 않아도 된다"는 뜻이 아니었습니다. 코드 대신 알아야 하는 것이 따로 있었습니다.

• 내 계좌의 구조: 어떤 계좌를 어떤 시스템이 쓰는지, 같은 계좌를 두 시스템이 쓰고 있지 않은지 (장부와 잔고 대조도 이 구조가 분명해야 의미가 있습니다)
• 규칙의 의미: 시스템이 언제 사고 언제 팔고 언제 쉬는지를 말로 설명할 수 있는지
• 숫자를 읽는 법: 백테스트의 연 수익률보다 최대 낙폭과 비용 가정을 먼저 보는 습관
• 멈추는 조건: 어떤 상황에서 시스템이 스스로 멈추고, 누가 다시 켜는지

이 네 가지는 AI에게 물어서 배울 수 있지만, 판단은 대신해 주지 않습니다. 결국 실계좌의 손실은 사람이 지기 때문입니다.

정리: AI와 자동매매를 만들 때 점검 질문

• 시스템이 지켜야 할 원칙을 한 문장으로 적었는가
• 단계를 나누고, 단계마다 사람이 정할 것을 먼저 문서로 남겼는가
• 결과에 맞춰 바꾸면 안 되는 결정을 미리 정해 두었는가
• AI의 설명을 확인할 테스트나 재현을 함께 요구하는가
• 실계좌로 넘어가는 결정과 멈추는 결정을 사람이 쥐고 있는가

다음 글에서는 시리즈의 네 번째 칸인 주문을 다룹니다. 주문은 반드시 실패한다는 전제로 만든 장치들을 정리합니다. 같은 기록을 카드로 정리한 요약은 인스타그램 @wealthgrid.lab 에 올립니다.

※ 특정 종목·수익을 권유하지 않는 개인 시스템 개발 기록입니다. 투자 판단과 책임은 본인에게 있습니다.