AI 시대를 선도하는 조코딩의 코딩 철학: 비전공자도 가능한 수익 자동화 시스템

저는 2024년 3월, 반복해서 확인하던 코인 시세 알림을 줄여 보겠다는 생각으로 파이썬 공부를 시작했습니다. 비전공자인 제가 처음부터 자동매매를 만들겠다고 하니 주변에서는 너무 큰 목표 아니냐는 반응을 보였지만, 당시에는 매일 저녁 30분씩 가격을 확인하는 일이 더 답답했습니다. 조코딩님의 영상을 보며 특히 와닿았던 부분은 문법을 많이 아는 사람보다 문제를 구체적으로 설명하는 사람이 AI를 더 잘 활용한다는 관점이었습니다. 저도 그 말을 믿고 처음부터 거대한 프로그램을 만들기보다, 가격을 가져와 화면에 표시하는 작은 작업부터 시작했습니다.

1. AI에게 코드를 맡기기 전에 제가 먼저 한 일

처음에는 ChatGPT에 “업비트 자동매매 봇을 만들어 줘”라고만 입력했습니다. 돌아온 코드는 그럴듯했지만 실행하자마자 인증 오류가 발생했고, 저는 어디를 고쳐야 하는지 전혀 몰랐습니다. 2024년 3월 18일 밤에만 같은 질문을 열두 번 반복했는데, 답변이 조금씩 달라져 오히려 혼란이 커졌습니다. 그 뒤부터는 요구사항을 한 문장씩 쪼갰습니다. “1분봉 가격을 한 번만 조회하고 화면에 출력한다”, “API 키는 코드에 직접 적지 않는다”처럼 조건을 적으니 오류 원인을 추적하기가 한결 수월했습니다. AI가 대신 생각해 주는 도구가 아니라, 제가 생각한 내용을 코드 형태로 바꾸는 보조자라는 점을 그때 배웠습니다.
API 키를 다루는 과정에서도 아찔한 실수가 있었습니다. 3월 23일, 테스트용 개인 저장소에 키가 포함된 .env 파일을 잘못 올렸고 약 40분 뒤에야 알아차렸습니다. 다행히 출금 권한을 꺼 둔 키였지만, 저는 곧바로 키를 폐기하고 새로 발급했습니다. 이후에는 환경변수와 읽기 전용 권한을 사용하고, 깃허브에 올리기 전 파일 목록을 확인하는 습관을 만들었습니다. AI가 작성한 예제에는 편의를 위해 키 문자열을 코드에 넣는 경우가 있었는데, 그 부분을 그대로 복사하면 안 된다는 사실도 체감했습니다. 코딩 실력보다 먼저 챙겨야 할 것은 실수했을 때 피해를 줄이는 설계라는 생각이 들었습니다.

2. 첫 자동화는 매매가 아니라 기록부터

저는 곧바로 주문 기능을 붙이지 않고 2024년 4월 한 달 동안 시세 기록 프로그램만 돌렸습니다. 매 5분마다 비트코인 가격과 거래량을 CSV 파일에 저장하고, 텔레그램으로 “정상 수집” 메시지를 보내도록 구성했습니다. 처음 이틀은 잘 작동했지만 사흘째 새벽에 프로그램이 멈췄습니다. 거래소 응답이 잠시 늦어졌는데 예외 처리를 하지 않아 전체 프로세스가 종료된 탓이었습니다. 당시에는 코드가 열 줄만 늘어나도 복잡해 보여 미뤘던 부분이었지만, 실제로는 재시도 횟수와 대기 시간을 넣는 간단한 수정으로 해결했습니다. 이 경험 이후 저는 기능을 추가하기 전에 네트워크 단절, 빈 응답, 잘못된 숫자 같은 상황을 일부러 시험했습니다.
처음 만든 매매 규칙은 전일 고가를 넘으면 매수하고 다음 날 오전 9시에 매도하는 방식이었습니다. 과거 6개월치 기록으로 계산했을 때 수익률이 18%로 나타나 꽤 기대했지만, 수수료와 슬리피지를 넣자 4% 아래로 떨어졌습니다. 더 당황스러웠던 부분은 제가 매수 신호가 발생한 캔들의 종가를 사용하면서도 실제 주문은 그다음 가격에 체결된 것처럼 계산했다는 점입니다. 이른바 미래의 정보를 몰래 사용한 셈이었습니다. 4월 27일에 백테스트 코드를 다시 작성하고 신호 발생 시점과 주문 체결 시점을 분리하자 결과가 크게 달라졌습니다. 숫자가 보기 좋게 나온다는 이유만으로 전략을 믿으면 안 된다는 교훈을 얻었습니다.

3. AI가 만든 전략을 의심하는 습관

저는 AI에게 이동평균선, 변동성 돌파, 손절 조건을 조합한 코드를 만들어 달라고 여러 차례 요청했습니다. 그때마다 코드 자체는 빠르게 나왔지만, 어떤 시장에서 약한지에 대한 설명은 제가 직접 확인해야 했습니다. 2024년 5월에는 상승장 데이터만 골라 테스트한 결과가 32%까지 나왔습니다. 그런데 2022년 하락장 구간을 넣자 손실 폭이 커졌고, 횡보장에서는 잦은 매매로 수수료가 누적됐습니다. 저는 이후 기간을 임의로 나누어 한 구간에서 규칙을 조정하고, 다른 구간에서 결과를 확인했습니다. 과거 한 시기에 잘 맞는 숫자를 찾는 일과 앞으로도 견디는 규칙을 만드는 일은 전혀 다르다는 사실을 그 과정에서 배웠습니다.
실전 주문은 더 늦게 시작했습니다. 6월 3일부터 2주 동안은 실제 돈을 쓰지 않고 주문 수량을 0.001개로 가정한 모의 기록만 남겼습니다. 그래도 문제가 이어졌습니다. 프로그램이 같은 신호를 두 번 읽어 두 번 주문한 것으로 기록했고, 텔레그램 알림은 전송 실패 후에도 오류를 알려 주지 않았습니다. 저는 주문 ID를 저장하고 이미 처리한 캔들을 다시 읽지 않도록 수정했으며, 알림 전송이 실패하면 로그 파일에 남기도록 바꿨습니다. AI가 제시한 코드가 실행된다는 사실과 운영 환경에서 믿고 맡길 만하다는 판단 사이에는 상당한 간격이 있었습니다.

4. 집 컴퓨터를 떠나 서버로 옮긴 날

2024년 6월 22일에는 프로그램을 집 데스크톱에서 클라우드 서버로 옮겼습니다. 집에서 실행할 때는 컴퓨터가 켜져 있으니 별 문제가 없었지만, 외출 중 절전 모드에 들어가면 봇도 멈췄습니다. 서버에 우분투를 설치하고 파이썬 가상환경을 만든 뒤 처음에는 크론으로 5분마다 실행했습니다. 그런데 실행이 끝나지 않은 상태에서 다음 작업이 시작되어 프로세스가 겹치는 문제가 발생했습니다. 이후에는 단순한 크론 대신 실행 중인 프로세스를 확인하는 장치와 로그 파일을 추가했습니다. 서버 비용, 시간대 설정, 로그 용량까지 신경 쓸 부분이 늘어났지만, 그제야 자동화가 버튼 하나로 끝나는 작업이 아니라 계속 관찰하고 관리하는 운영 업무라는 점을 실감했습니다.
서버에 올린 뒤에는 매매보다 장애 알림을 먼저 확인했습니다. API 호출 제한에 걸리지 않도록 조회 간격을 10초에서 20초로 늘렸고, 연속 세 번 응답이 없으면 주문을 중단하도록 설정했습니다. 7월 8일에는 거래소 점검 시간과 프로그램 재시작 시간이 겹쳐 잔고 조회가 실패했는데, 예외 처리가 주문 단계까지 넘어가지 않게 막아 둔 덕분에 추가 주문은 발생하지 않았습니다. 반대로 7월 15일에는 서버 시간이 한국 시간과 맞지 않아 오전 9시 매도 조건이 한 시간 늦게 작동했습니다. 시간을 UTC 기준으로 통일하고 로그에 타임스탬프를 함께 남긴 뒤에야 원인을 찾았습니다. 이런 실패를 겪으면서 저는 수익률 그래프보다 언제, 왜, 어떤 조건으로 주문이 실행됐는지를 기록하는 일이 더 앞선다고 판단했습니다.

5. 제가 지금도 지키는 작은 원칙

현재 제 시스템은 거창한 수익 자동화 장치라기보다 반복 확인을 줄여 주는 개인 도구에 가깝습니다. 매매 금액에는 생활비를 섞지 않고, 하루 손실 한도를 넘으면 프로그램이 스스로 멈추도록 설정했습니다. 매주 일요일에는 로그와 거래 내역을 대조하면서 실제 체결 가격, 수수료, 누락된 알림을 확인합니다. AI에게 새 기능을 요청할 때도 한 번에 전체 코드를 바꾸지 않고 작은 함수 하나만 수정하게 한 뒤 테스트 결과를 비교합니다. 제가 조코딩식 코딩 철학에서 얻은 가장 현실적인 배움은 AI를 많이 쓰는 데 있지 않았습니다. 내가 해결하려는 문제를 좁게 정의하고, 실패 기록을 남기며, 작은 자동화를 반복해서 개선하는 태도에 있었습니다. 처음 시작하는 분이라면 매매부터 서두르기보다 자신의 반복 업무 하나를 골라 기록 자동화부터 시도해 보시길 권합니다.