자동매매를 24시간 운영하기 위한 클라우드 환경 점검

24시간 꺼지지 않는 수익 봇을 돌리려면 클라우드 서버가 거의 필수인데, 막상 구축하려니 어디서부터 손대야 할지 막막하거든요. AWS 프리티어부터 오라클 무료 VM까지 직접 써보고 정리한 현실적인 구축기입니다.

처음에는 그냥 집 데스크톱으로 봇을 돌렸어요. 파이썬 스크립트 하나 띄워놓고 자는 거죠. 근데 한 달쯤 지나니까 문제가 하나둘 터지기 시작하더라고요. 윈도우 업데이트가 새벽에 걸려서 재부팅된 적이 두 번, 공유기가 IP를 바꿔서 API 인증이 풀린 적이 한 번. 세 번째 사고 때 하루치 수익을 그냥 날렸거든요.

그때 클라우드 서버로 넘어가야겠다고 결심했는데, 이게 또 선택지가 너무 많아서 탈이었어요. AWS, GCP, 오라클, 가비아, Vultr, Contabo — 검색하면 할수록 더 헷갈렸습니다. 결국 세 군데를 직접 만들어보고 비교했고, 3개월간 실제로 봇을 올려서 운영한 경험을 정리해봤어요.

내 컴퓨터로 봇 돌리다가 클라우드로 넘어간 이유

로컬 환경에서 봇을 돌리는 건 시작은 쉬워요. 코드 짜고, 터미널 열고, python main.py 한 줄이면 끝이니까. 문제는 “24시간”이라는 조건이 붙는 순간 전혀 다른 게임이 된다는 거예요.

전기 요금부터 생각해야 해요. 데스크톱을 24시간 돌리면 월 전기료가 2~3만 원은 추가로 나오거든요. 거기에 소음, 발열, 그리고 가장 치명적인 건 네트워크 불안정성이에요. 가정용 인터넷은 ISP 점검이나 공유기 재부팅 같은 변수가 많잖아요. 새벽 3시에 라우터가 한 번 깜빡이면 봇이 API 연결을 잃고 멈춰버립니다.

클라우드 서버는 이 문제를 근본적으로 해결해줘요. 데이터센터급 네트워크에 UPS 전원, 그리고 99.9% 이상의 가동률 보장. 월 만 원도 안 되는 비용으로 이걸 확보할 수 있다는 게 핵심이에요.

한 가지 더. 봇을 여러 개 돌리기 시작하면 로컬 환경으론 한계가 금방 와요. 서버를 분리해서 리스크를 나누는 것도 클라우드에서만 가능한 전략이거든요.

AWS, GCP, 오라클 — 봇 운영용 클라우드 가격 비교

직접 세 곳에서 인스턴스를 만들어보고 비교한 결과를 정리했어요. 봇 운영에 필요한 최소 사양(vCPU 1~2개, RAM 1GB, 스토리지 20~30GB) 기준이에요.

항목	AWS EC2	오라클 클라우드
무료 조건	t3.micro 12개월 무료	ARM VM 평생 무료
무료 사양	vCPU 2 / RAM 1GB	최대 4 ARM VM / 총 24GB RAM
무료 후 월비용	약 $7.5~10 (온디맨드)	Always Free 유지 시 $0
봇 운영 적합도	안정적, 생태계 최대	무료 최강, ARM 호환 주의

GCP는 신규 가입 시 $300 무료 크레딧을 90일간 제공하고, e2-micro 인스턴스는 상시 무료 등급에 포함돼 있어요. 다만 e2-micro가 vCPU 0.25에 RAM 1GB라 무거운 봇에는 좀 빡빡하더라고요.

개인적으로 가장 놀랐던 건 오라클 클라우드였어요. Always Free 등급에서 ARM 기반 Ampere A1 인스턴스를 월 3,000 OCPU 시간, 18,000 GB 시간까지 무료로 줍니다. 쉽게 말하면 4코어 24GB RAM짜리 VM을 평생 무료로 쓸 수 있다는 건데, 솔직히 처음엔 의심했어요.

실제로 써보니까 진짜 무료 맞더라고요. 다만 ARM 아키텍처라서 일부 파이썬 라이브러리가 호환 안 되는 경우가 있었어요. numpy 같은 건 문제없는데 특정 바이너리 의존 패키지는 빌드 에러가 나서 수동 컴파일이 필요했거든요. 이게 은근 시간 잡아먹습니다.

AWS는 프리티어 12개월이 끝나면 t3.micro 기준 온디맨드 요금이 시간당 약 $0.0104예요. 월 환산하면 대략 $7.5, 한화로 만 원 안팎이죠. 가격 자체는 부담 없는데, 실수로 EBS 스토리지나 데이터 전송량을 초과하면 예상 외 요금이 붙을 수 있어요.

처음부터 끝까지, 클라우드 서버 세팅 과정

AWS 기준으로 설명할게요. 다른 클라우드도 큰 흐름은 비슷하거든요. 먼저 EC2 대시보드에서 인스턴스를 생성해요. OS는 Ubuntu 22.04 LTS를 권장합니다. 가볍고, 커뮤니티 자료가 압도적으로 많아서 문제 생겼을 때 검색 한 번이면 대부분 해결돼요.

인스턴스 생성할 때 키페어(.pem 파일)를 꼭 다운로드해두세요. 이거 잃어버리면 서버 접속 자체가 안 됩니다. 저는 한 번 날려먹고 인스턴스를 새로 만들었어요. 키페어는 로컬 + 클라우드 스토리지에 이중으로 백업해두는 게 좋아요.

SSH로 접속한 다음에 해야 할 일은 순서가 있어요. 시스템 업데이트가 먼저고, 그 다음 파이썬(또는 Node.js) 환경 구성, 봇 코드 업로드, 그리고 프로세스 매니저 설치 순서입니다. sudo apt update && sudo apt upgrade -y부터 치고 시작하면 돼요.

보안 그룹 설정도 빠뜨리면 안 돼요. SSH 포트(22번)는 내 IP에서만 접속 가능하도록 제한하고, 봇이 외부 API만 호출하는 거라면 인바운드 포트는 SSH만 열어두면 됩니다. 웹 대시보드를 띄울 거라면 80번이나 443번을 추가로 열되, 가능하면 특정 IP만 허용하세요.

GCP에서는 VM 인스턴스를 Compute Engine 메뉴에서 만들고, 오라클은 OCI 콘솔에서 인스턴스를 생성합니다. 오라클은 ARM 이미지를 선택해야 무료 등급에 포함되니까 이 부분만 주의하면 돼요.

봇이 죽지 않게 만드는 안정화 도구들

서버를 세팅하는 건 절반이에요. 진짜 중요한 건 봇이 멈추지 않게 만드는 장치를 까는 거거든요. SSH 접속 끊으면 프로세스도 같이 죽잖아요. 이걸 해결하는 게 프로세스 매니저입니다.

Node.js 봇이라면 PM2가 거의 표준이에요. pm2 start bot.js 한 줄이면 백그라운드 실행되고, 크래시가 나면 자동으로 재시작해줘요. pm2 startup 명령어를 등록해두면 서버가 재부팅되더라도 봇이 자동으로 살아납니다. 파이썬 봇도 pm2로 돌릴 수 있어요. pm2 start bot.py –interpreter python3 이런 식으로요.

리눅스 네이티브로 가고 싶다면 systemd 서비스로 등록하는 방법이 있어요. /etc/systemd/system/ 아래에 .service 파일을 만들어서 Restart=always 옵션을 넣어두면 PM2 없이도 자동 재시작이 가능합니다. 저는 둘 다 써봤는데, 모니터링 편의성은 PM2가 앞서고 시스템 안정성은 systemd가 더 단단하다고 느꼈어요.

cron도 빠뜨리면 안 돼요. 봇 자체가 아니라 봇의 건강 상태를 체크하는 스크립트를 cron에 걸어두는 거예요. 5분마다 봇 프로세스가 살아있는지 확인하고, 죽었으면 재시작하는 셸 스크립트를 만들어서 crontab -e에 등록하면 이중 안전망이 되거든요.

보안 설정과 예상 밖 요금 폭탄 방지법

클라우드 서버 보안은 솔직히 처음에 대충 넘겼어요. “어차피 봇만 돌리는 건데 뭐” 하고요. 근데 서버 띄운 지 이틀 만에 SSH 브루트포스 공격 로그가 수백 줄 찍혀 있는 걸 보고 정신이 번쩍 들었습니다.

반드시 해야 할 보안 설정을 정리하면 이래요. 첫째, SSH 포트를 22번에서 다른 번호로 변경합니다. /etc/ssh/sshd_config에서 Port 번호만 바꾸면 돼요. 이것만으로 자동화된 공격의 90%가 걸러져요. 둘째, 패스워드 인증을 끄고 키페어 인증만 남겨요. PasswordAuthentication no 한 줄이면 끝. 셋째, fail2ban을 설치해서 로그인 실패가 반복되면 자동으로 IP를 차단하게 합니다.

요금 폭탄은 또 다른 공포예요. AWS에서 흔히 당하는 케이스가 Elastic IP를 할당해놓고 인스턴스를 중지한 채로 두는 거예요. 인스턴스에 연결 안 된 Elastic IP는 시간당 과금이 됩니다. 한 달 내버려두면 $3~4 정도인데, 모르고 넘어가면 꽤 쌓여요.

오라클 클라우드는 Always Free 등급을 넘는 리소스를 만들지만 않으면 요금이 안 나와요. 하지만 한 가지 함정이 있는데, 유휴 상태의 인스턴스를 오라클이 자동으로 회수할 수 있다는 거예요. 봇이 일정한 CPU 사용량을 유지하고 있다면 문제없지만, 가끔 정말 낮은 사용률로 장기간 방치하면 위험해요.

3개월 운영 후 솔직한 비용 정산과 운영 수칙

3개월간 AWS와 오라클 두 곳에서 봇을 병렬 운영했어요. AWS에서는 프리티어 기간이라 EC2 자체 비용은 0원이었고, 실제로 나간 비용은 Elastic IP + 추가 EBS 스냅샷 비용으로 총 $4.2 정도였어요. 오라클은 진짜 $0이었습니다.

그렇다고 오라클이 무조건 좋다는 건 아니에요. ARM 호환 이슈로 삽질한 시간이 체감상 AWS보다 3배는 많았거든요. 시간을 돈으로 환산하면 오히려 AWS가 쌌을 수도 있다는 생각이 들었어요. 특히 특정 암호화 라이브러리 하나가 ARM에서 빌드 안 돼서, 이것만 해결하는 데 하루 반나절을 날렸습니다.

3개월간 운영하면서 자리 잡은 운영 수칙이 있어요. 봇 코드는 반드시 GitHub 프라이빗 리포에 올려두고, 서버에서는 git pull로만 업데이트합니다. 서버에서 직접 코드를 수정하면 나중에 어디서 뭘 바꿨는지 추적이 안 돼서 사고 나요. API 키 같은 민감 정보는 .env 파일에 분리하고, 이 파일은 절대 Git에 올리지 않아요.

결국 봇 자체의 수익성보다 서버의 안정성이 수익을 결정한다는 걸 깨달았어요. 아무리 좋은 전략이어도 서버가 죽어있으면 수익은 제로니까요. 주 1회 서버 상태를 점검하고, 월 1회 OS 패키지를 업데이트하고, 분기 1회 서버를 깨끗하게 재구성하는 루틴을 만들어두면 대부분의 사고는 예방할 수 있어요.

흔한 오해 하나 짚고 갈게요. “클라우드 서버는 비싸다”는 인식이 있는데, 봇 운영 정도의 경량 워크로드라면 월 만 원 안팎이면 충분합니다. 오히려 집 데스크톱을 24시간 돌릴 때의 전기료 + 하드웨어 마모 + 정신적 스트레스를 생각하면 클라우드가 더 싸요.