AI 조직 실험 노트
튜토리얼약 9분 읽기

자동매매 클라우드 서버 24시간 배포 — 개인 PC로는 안 되는 이유와 무중단 운영 설계

노트북으로 자동매매를 돌리다 겪은 일

처음에는 그냥 쓰던 노트북에서 자동매매 코드를 돌렸다. 장중에 화면만 켜두면 되는 줄 알았다. 그런데 절전모드로 화면이 꺼지면서 프로세스가 함께 멈췄고, OS 자동 업데이트가 새벽에 컴퓨터를 재부팅시켜버린 적도 있었다. 노트북을 들고 이동하느라 와이파이가 잠깐 끊긴 순간에 하필 주문이 나가야 했던 적도 있다. 사람이 컴퓨터 앞에 없어도 돌아가야 하는 프로그램을, 사람이 계속 신경 써야 하는 기기 위에 올려둔 게 문제였다.

이 글은 특정 클라우드 업체나 인스턴스 사양·가격을 비교하지 않는다. 대신 개인 PC와 클라우드 서버의 차이가 왜 생기는지, 그리고 24시간 무인 운영을 위해 최소한 갖춰야 할 구조가 무엇인지를 개념 수준에서 정리한다. 실제로 운영 중인 서버의 사양이나 설정 값은 이 글에 없다.

왜 개인 PC로는 부족한가 — 24시간 무인 운영의 전제조건

개인 PC와 클라우드 서버의 결정적 차이는 "사람이 관여하지 않아도 계속 켜져 있는가"다. 개인 PC는 애초에 그렇게 설계되지 않았다.

이런 요인 하나하나는 평소엔 아무 문제가 안 된다. 그런데 자동매매처럼 "특정 시각에 반드시 살아 있어야 하는" 프로그램에는 치명적이다. 장이 열리는 순간 프로세스가 죽어 있으면, 그 사실을 사람이 알아채기 전까지는 아무 일도 일어나지 않는다. 클라우드 서버를 쓰는 이유는 성능이 아니라 "사람 없이도 계속 켜져 있는 환경"을 확보하기 위해서다.

클라우드 서버 선택의 기본 개념

클라우드 서버를 고를 때 실무적으로 따지는 축은 대략 이렇다. 다만 이 글에서는 특정 업체나 구체적인 스펙·가격을 단정하지 않고, 무엇을 고려해야 하는지 개념만 짚는다.

여기서 중요한 건, 서버 선택 자체보다 "이 서버가 죽었을 때 어떻게 되는가"를 먼저 설계해두는 것이다. 그게 다음 절의 주제다.

무중단 실행 — 프로세스가 죽었을 때 다시 살아나는 구조

파이썬 스케줄러로 자동매매 돌리기에서는 "언제 무엇을 실행할지"를 스케줄러가 판단하는 구조를 다뤘다. 그런데 그 스케줄러 프로세스 자체가 죽어버리면 어떻게 될까. 스케줄러가 아무리 잘 짜여 있어도, 스케줄러를 실행하는 프로세스 자체가 서버 재부팅이나 예외로 죽어버리면 그 순간부터는 아무것도 실행되지 않는다. 이 문제는 스케줄러보다 한 단계 위, 즉 "프로세스를 감시하고 죽으면 다시 띄우는" 별도의 계층이 필요하다는 뜻이다.

이런 역할을 하는 도구를 흔히 프로세스 매니저(process manager)라고 부른다. 운영체제에 기본 내장된 서비스 관리자를 쓰기도 하고, 별도의 프로세스 관리 도구를 쓰기도 한다. 이 글은 특정 도구의 설정 파일 문법을 다루지 않는다 — 도구마다 표기법이 다르고, 그 내용을 그대로 옮기는 건 이 블로그의 원칙에도 맞지 않는다. 대신 이런 도구들이 공통으로 하는 일의 개념만 정리한다.

프로세스 매니저가 하는 일을 의사코드로 단순화하면 이렇다.

코드 보기
watch(process):
    while True:
        if not is_running(process):
            log("프로세스 종료 감지, 재시작 시도")
            start(process)
        sleep(check_interval)

여기서 중요한 건 "감시하는 주체"와 "감시당하는 프로세스"를 분리한다는 개념이다. 자동매매 프로그램 자체가 자기 자신의 생사를 판단할 수는 없다 — 이미 죽어버린 프로세스는 스스로를 되살릴 수 없기 때문이다. 그래서 별도의 상위 프로세스(또는 서비스)가 감시자 역할을 맡고, 감시 대상이 죽으면 자동으로 다시 띄우는 구조가 있어야 한다. 대부분의 프로세스 매니저는 "서버가 재부팅돼도 이 프로그램을 자동으로 다시 켠다"는 옵션도 함께 제공하는데, 이걸 켜두지 않으면 재부팅 후 프로그램이 영영 안 켜진 채로 방치되는 사고가 난다(자주 하는 실수 참고).

배포·설정 분리 — 코드와 설정값을 나눠서 올린다

시크릿·설정값 안전하게 관리하기에서 API 키 같은 민감한 값을 코드에서 분리해 환경변수나 별도 파일로 관리해야 한다는 원칙을 다뤘다. 이 원칙은 서버에 배포하는 순간부터 훨씬 중요해진다. 개인 PC에서는 코드와 설정이 뒤섞여 있어도 그 PC를 쓰는 사람 외에는 볼 일이 없지만, 서버는 배포·백업·복제 과정에서 코드가 여러 경로로 옮겨 다닌다. 그 코드 안에 설정값이 박혀 있으면 옮겨질 때마다 유출 경로가 하나씩 늘어난다.

배포·설정 분리의 기본 원칙은 다음과 같다.

이렇게 나누면 "같은 코드를 여러 서버에 그대로 복제해도 안전하다"는 게 핵심 이득이다. 코드 자체에는 민감한 정보도, 서버마다 다른 값도 없기 때문에, 배포 과정에서 실수로 잘못된 서버에 잘못된 설정이 섞여 들어갈 위험이 줄어든다.

자주 하는 실수

  1. 서버와 로컬의 시간대(타임존)가 다르다는 걸 잊는다. 클라우드 서버는 기본값으로 로컬 PC와 다른 시간대로 설정된 경우가 많다. 개발할 때 로컬 PC 시간 기준으로 짜둔 스케줄이, 서버에 그대로 올라가면 몇 시간씩 어긋난 시각에 실행되는 사고로 이어진다. 서버의 시간대를 코드가 기대하는 기준과 명시적으로 맞추거나, 아예 코드 안에서 시간대를 명시적으로 지정해 시스템 기본값에 의존하지 않는 편이 안전하다.
  2. 재부팅 후 자동 기동 설정을 빼먹는다. 프로세스 매니저로 프로그램을 띄워도, "서버가 재시작되면 이 프로그램도 자동으로 다시 켠다"는 옵션을 별도로 켜지 않으면 정기 점검이나 예기치 못한 재부팅 후 프로그램이 그냥 꺼진 채로 남는다. 사람이 매일 서버 상태를 확인하지 않는 게 무인 운영의 목적인데, 이 설정을 빼먹으면 무인 운영의 전제 자체가 깨진다.
  3. 비용 관리를 소홀히 한다. 로그가 계속 쌓이며 디스크를 채우거나, 테스트용으로 띄운 서버를 끄지 않고 방치하거나, 필요 이상으로 큰 사양을 계속 쓰는 경우가 흔하다. 클라우드는 켜져 있는 만큼, 쌓이는 만큼 비용이 발생하는 구조이므로, 주기적으로 실제 사용량과 청구 내역을 확인하는 습관이 필요하다.

오늘의 정리

  1. 자동매매를 24시간 무인으로 돌리려면, 개인 PC가 아니라 사람 개입 없이도 계속 켜져 있는 클라우드 서버 환경이 필요하다.
  2. 서버 선택은 사양·리전·가용성·접근 제어를 개념적으로 따지는 문제이고, 그보다 먼저 "죽었을 때 어떻게 되는가"를 설계해두는 게 우선이다.
  3. 프로세스 매니저는 감시자와 감시 대상을 분리해, 프로그램이 죽으면 자동으로 재시작하고 서버가 재부팅돼도 자동으로 다시 켜지게 하는 계층이다.
  4. 코드는 저장소로, 설정값은 서버에만 별도로 두는 배포·설정 분리 원칙을 지키면 같은 코드를 여러 서버에 안전하게 복제할 수 있다.
  5. 서버-로컬 시간대 불일치, 재부팅 후 자동 기동 누락, 비용 관리 소홀은 무인 운영에서 특히 자주 나는 실수다.

이 글은 클라우드 서버 배포의 일반적인 개념을 정리한 것이며, 실제 운영 중인 서버의 구체적인 사양이나 설정은 포함하지 않습니다. 투자 조언이 아니며 특정 종목이나 매매기법을 추천하지 않습니다. 수익을 보장하지 않으며, 투자 손실에 대한 책임은 투자자 본인에게 있습니다.

함께 보면 좋은 글

← 전체 글 목록