- 자동매매 백테스트에서 먼저 막히는 것은 코어가 아니라 램입니다. 백테스트 한 판이 램을 2.6~3.8GB씩 씁니다. 램 16GB인 제 컴퓨터는 한 번에 한 판밖에 못 돌리고, 코어 16개 중 15개가 램을 기다리며 놉니다.
- 램이 모자라면 컴퓨터 전체가 멈춥니다. 세 판을 한꺼번에 띄우자 남은 램이 0.13GB까지 떨어졌습니다. 그래서 다른 작업 창은 램이 날 때까지 줄을 서고, 저는 클로드 말고는 전부 꺼 두고 삽니다.
- 램 수요는 계속 늘어납니다. 한 판이 쓰는 램이 17일 사이에 1.7~2.6GB에서 2.6~3.8GB로 늘었습니다. 다루는 종목과 규칙이 늘수록 더 늘어납니다.
- 추천은 램 64GB(32GB × 2)입니다. 최소 32GB(16GB × 2)이고, 16GB는 권하지 않습니다. 코어는 그다음에 «램 4GB당 고성능 코어 1개»로 맞추면 됩니다. 예산이 모자라면 CPU를 한 등급 낮추고 램을 올리십시오.

지난번 블루투스가 끊긴 범인은 CPU가 아니라 메모리였다는 글에서 «클로드 코드로 개발할 때 병목은 CPU가 아니라 램»이라고 적었습니다. 그때는 음악이 끊기는 정도의 불편이었습니다.
그 뒤로 자동매매 전략을 본격적으로 다듬으면서 상황이 훨씬 나빠졌습니다. 같은 실험을 조건만 바꿔 열두 번씩 돌리는 일이 자주 생기는데, 램이 모자라 그걸 한 판씩밖에 못 돌립니다. 이제는 불편이 아니라 개발 속도 자체가 램에 묶여 있습니다. 이 글은 그 고생담과, 거기서 나온 램 용량 계산입니다.
지금 제 작업 환경은 이렇습니다
요즘 제 컴퓨터 사용법을 솔직하게 적으면 이렇습니다.
- 백테스트를 한 판씩밖에 못 돌립니다. 비교할 조건이 네 개면 네 번을 차례로 기다려야 합니다.
- 다른 작업 창이 램이 날 때까지 멈춰 있습니다. 저는 전략마다 클로드 코드 창을 따로 띄워 두고 작업합니다. 한 창이 백테스트를 돌리면, 다른 창은 백테스트를 시작하지 못하고 램이 비기를 기다립니다. 여러 창이 램 하나를 두고 줄을 서는 셈입니다.
- 클로드 말고는 거의 모든 프로그램을 꺼 둡니다. 램을 조금이라도 더 확보하려고, 컴퓨터를 켜 놓고도 다른 일에는 쓰지 못하는 상태가 됐습니다.
- 램이 비었는지 확인하는 게 일이 됐습니다. «메모리 비웠어, 돌려», «메모리 확보했어, 병렬로 해 봐»는 제가 클로드에게 자주 하는 말이 됐습니다.
이 네 가지가 전부 램 한 가지에서 나옵니다. 숫자로 확인해 봤습니다.
백테스트 한 판이 램을 얼마나 먹나
제 백테스트는 종목 2,700여 개의 여러 해치 일봉과 지표를 전부 램에 올려 두고, 날짜를 하루씩 넘기며 사고파는 흉내를 냅니다. 디스크에서 그때그때 읽으면 느려지기 때문입니다. 그래서 램을 많이 먹습니다.
| 항목 | 실측 |
|---|---|
| 한 판이 쓰는 램 | 2.6~3.8GB |
| 한 판이 쓰는 코어 | 1개 |
| 12판을 차례로 돌린 시간 | 약 85분 (한 판에 약 7분) |
램과 코어를 나란히 놓으면 차이가 분명합니다. 한 판이 코어는 1개만 쓰는데 램은 4GB 가까이 씁니다. 빨리 끝내려면 여러 판을 동시에 돌려야 하고, 동시에 돌린 판 수만큼 램이 곱절로 듭니다.
램 수요는 계속 늘어납니다
더 곤란한 것은 이 숫자가 고정돼 있지 않다는 점입니다.
| 잰 날 | 한 판이 쓰는 램 |
|---|---|
| 2026-08-21 (지난 글) | 1.7~2.6GB |
| 2026-09-07 | 2.6~3.8GB |
17일 사이에 한 판이 쓰는 램이 1.5배로 늘었습니다. 다루는 종목이 늘고, 전략에 규칙이 하나씩 붙을 때마다 램에 올려야 할 것이 늘어납니다. 전략을 개선할수록 램은 더 필요해집니다. 그래서 램은 «지금 필요한 만큼»이 아니라 «앞으로 늘어날 몫»까지 넉넉히 사야 합니다.
램이 모자라면 벌어지는 일
코어가 모자라면 작업이 느려질 뿐입니다. 여러 프로그램이 코어를 번갈아 쓰면 되기 때문입니다. 그런데 램은 나눠 쓸 수 없습니다. 프로그램마다 잡은 램을 각자 끝까지 물고 있어야 합니다. 모자라면 윈도우가 램의 내용을 디스크로 밀어내고(스왑), 그 순간부터 컴퓨터 전체가 디스크를 기다리며 멈춥니다.
실제로 세 판을 한꺼번에 띄워 본 적이 있습니다.
| 시점 | 남은 램 |
|---|---|
| 띄우기 전 | 5.85GB |
| 세 판이 돌기 시작한 뒤 | 0.13GB |
디스크로 밀려나기 직전이라 한 판을 바로 내렸습니다. 그 뒤로 «판을 띄우기 전에 남은 램부터 재고, 모자라면 기다린다»는 규칙을 만들었습니다. 다른 작업 창이 줄을 서는 것도 이 규칙 때문입니다. 램이 모자란 컴퓨터에서 여러 작업을 안전하게 돌리는 방법은 기다리는 것뿐이었습니다.
가상 메모리를 늘리면 되지 않느냐고 생각하실 수 있습니다. 지난 글에 적었듯 가상 메모리는 램 부족을 고쳐주지 않습니다. 프로그램이 뻗지 않게 받쳐줄 뿐이고, 그걸 쓰기 시작한 순간 이미 느려지고 있습니다.
코어 16개 중 15개가 램을 기다립니다
제 컴퓨터 사양입니다.
| 항목 | 사양 |
|---|---|
| 형태 | 올인원 데스크탑 |
| CPU | Intel Core Ultra 7 155H · 16코어 / 22스레드 |
| 램 | 16GB (메인보드에 붙어 있어 늘릴 수 없음) |
백테스트를 하나도 돌리지 않는 지금 남은 램을 재 보면 8.35GB입니다. 16GB 중 절반 가까이를 윈도우와 클로드 코드 창들(프로세스 20개, 1.8GB)이 이미 쓰고 있습니다. 여기서 디스크로 밀려나지 않게 2GB를 남기면 이렇게 됩니다.
(남은 램 8.35GB − 여유 2GB) ÷ 한 판 3.8GB = 1.67 → 동시에 1판
그래서 한 판씩입니다. CPU는 코어가 16개나 되는 좋은 칩인데, 일을 하는 건 1개이고 나머지 15개는 램이 없어 놀고 있습니다. 이 컴퓨터에 CPU를 두 배 좋은 것으로 바꿔 끼워도 이 식의 답은 그대로 1판입니다. 몇 판을 동시에 돌릴지는 램이 정합니다.
램만 풀어 줬더니 4.4배 빨라졌습니다
램이 병목이라는 걸 확인한 실험이 있습니다. 판마다 같은 가격 데이터를 따로 싣는 대신, 데이터를 램에 한 벌만 올려 두고 여러 판이 같이 읽게 바꿨습니다(공유 메모리). 코어는 그대로이고, 바뀐 건 램 사용량뿐입니다.
| 방식 | 한 판이 쓰는 램 | 6판 걸린 시간 |
|---|---|---|
| 판마다 데이터를 따로 싣기 (차례로) | 2.6~3.8GB | 24.9분 |
| 데이터 한 벌을 같이 읽기 (6판 동시) | 약 0.6GB | 5.7분 (4.4배 빠름) |
같은 컴퓨터, 같은 코어인데 램 사용량을 줄이자 4.4배 빨라졌습니다. 놀던 코어가 램을 얻자마자 일을 시작한 것입니다. 병목이 램이었다는 가장 확실한 증거입니다.
그런데 이 방식은 모든 실험에 쓸 수 없었습니다. 두 조건을 나란히 놓고 비교하는 실험에서 결과가 미세하게 달라지는 문제가 있어서, 비교 판정에는 원래 방식으로 돌아가야 했습니다. 램 부족은 소프트웨어로 다 피할 수 없었고, 결국 필요한 건 실제 램 용량이었습니다.
램 용량별 계산
그럼 램이 얼마면 되는지 계산해 봤습니다.
동시 판 수 = ⌊(총 램 − 상시 사용 − 여유 2GB) ÷ 한 판 3.8GB⌋
상시 사용은 제 컴퓨터에서 잰 값(총 15.5GB − 남은 8.35GB ≈ 7GB)을 그대로 넣었습니다. 클로드 코드 창을 여러 개 띄워 두는 제 방식 기준입니다.
| 램 | 동시 판 수 | 12판을 도는 횟수 | 12판 걸리는 시간 |
|---|---|---|---|
| 16GB (지금) | 1판 | 12번 | 약 85분 (실측) |
| 32GB | 6판 | 2번 | 약 14분 (계산) |
| 48GB | 10판 | 2번 | 약 14분 (계산) |
| 64GB | 14판 | 1번 | 약 7분 (계산) |
※ «계산» 칸은 한 판 7분에 도는 횟수를 곱한 이론값입니다. 여러 판이 동시에 돌면 램을 읽는 통로를 나눠 쓰느라 한 판이 조금씩 느려지므로, 실제로는 이보다 더 걸립니다.
- 16GB → 32GB만 해도 85분이 14분 안팎으로 줄어듭니다. 제 작업에서는 이만큼 효과가 큰 업그레이드가 없습니다.
- 64GB면 12판을 한 번에 끝냅니다. 동시 14판이라 여유가 두 판 남고, 앞서 본 «늘어나는 램 수요»도 한동안 받아낼 수 있습니다.
- 48GB는 12판 기준으로 애매합니다. 10판밖에 못 돌려 결국 두 번을 돕니다.
코어는 램 다음에 맞춥니다
코어가 필요 없다는 뜻은 아닙니다. 램이 허락한 판 수만큼 일할 코어가 있어야 그 판들이 동시에 돕니다. 순서만 다릅니다. 램으로 동시 판 수를 정하고, 그 수에 코어를 맞춥니다.
- 비율은 «램 4GB당 고성능 코어 1개»입니다. 한 판이 램 3.8GB와 코어 1개를 쓰기 때문입니다. 64GB로 14판을 돌리려면 코어가 14개 가까이 있어야 합니다.
- 코어는 «고성능 코어» 기준으로 세십시오. 요즘 인텔 CPU는 고성능 코어와 느린 효율 코어가 섞여 있습니다. 여러 판을 동시에 돌리면 효율 코어에 걸린 판이 늦게 끝나고, 전체는 가장 늦은 판을 기다립니다.
- 반대로 코어만 많고 램이 적으면 제 컴퓨터처럼 됩니다. 비싼 CPU의 코어 대부분이 놉니다.
추천 사양
위 계산에서 나오는 결론만 적겠습니다. 전략 몇 개를 동시에 다듬으며 백테스트를 여러 판씩 자주 돌리는 경우입니다. 램을 먼저 정하고 나머지를 맞추는 순서로 적었습니다.
| 항목 | 최소 | 권장 |
|---|---|---|
| ① 램 | 32GB (16GB × 2) · 동시 6판 | 64GB (32GB × 2) · 동시 14판 |
| ② CPU | 고성능 코어 6개 이상 | 코어 12개 이상, 그중 고성능 코어 8개 이상 예: 인텔 코어 울트라 7 265K (고성능 8 + 효율 12), AMD 라이젠 9 9900X (12코어 모두 같은 코어) |
| ③ 저장장치 | NVMe SSD 1TB 이상 (가격 데이터 캐시가 수백 MB씩 쌓입니다) | |
| ④ 그래픽카드 | 필요 없습니다. 제 백테스트는 그래픽카드를 쓰지 않습니다. 그 돈을 램에 쓰는 편이 낫습니다 | |
16GB는 권하지 않습니다. 제가 그 결과를 매일 겪고 있습니다. 그리고 예산이 모자라면 CPU를 한 등급 낮추고 램을 올리십시오. CPU 한 등급의 차이보다 동시에 돌리는 판 수의 차이가 훨씬 큽니다.
램을 살 때 확인할 것도 적어 둡니다. 제가 직접 겪은 것들입니다.
- 램을 나중에 늘릴 수 있는지부터 보십시오. 제 컴퓨터는 데스크탑인데도 램이 메인보드에 붙어 있어 16GB가 평생 용량입니다. 올인원·미니 PC·얇은 노트북은 이런 경우가 많습니다. 램 수요는 계속 늘어나므로 램 슬롯이 있는 본체를 고르십시오.
- 램은 같은 제품 2개 한 세트로 꽂으십시오. CPU는 램을 두 통로로 나눠 동시에 읽습니다. 2개를 꽂아야 두 통로를 다 씁니다. 3개를 꽂으면 짝이 안 맞아 일부 구간이 한 통로로만 읽히고, 따로 산 램을 섞으면 불안정할 수 있습니다.
- 슬롯이 4개인 메인보드라면 처음엔 2개만 채우십시오. 나중에 같은 램 2개를 더해 늘릴 수 있습니다. 다만 한 통로에 2개씩 꽂으면 램 속도가 조금 내려갈 수 있습니다.
정리
컴퓨터를 고를 때 사양표 맨 위에는 CPU가 있습니다. 그런데 자동매매 백테스트를 개발해 보니 먼저 막히는 것은 언제나 램이었습니다. 코어는 나눠 쓸 수 있지만 램은 나눠 쓸 수 없고, 램이 모자라면 느려지는 게 아니라 멈춥니다. 그리고 전략을 다듬을수록 램은 더 필요해집니다.
저는 지금 코어는 남고 램은 모자란 컴퓨터로 개발하고 있습니다. 그래서 오늘도 클로드 말고는 전부 꺼 두고, 백테스트가 한 판씩 끝나기를 기다립니다. 자동매매 개발용 컴퓨터를 고르신다면 램부터 정하십시오.
'자동매매 일지 > 개발 이야기' 카테고리의 다른 글
| git 뜻과 사용법 — 자동매매 프로그램 폴더에서 되돌리기 명령을 금지한 이유 (0) | 2026.09.14 |
|---|---|
| 백테스트 수익률이 비현실적으로 높을 때 — 연 1억%의 정체 (1) | 2026.08.20 |
| 자동매매 백테스트 첫 결과 — 말도 안 되는 수치가 나왔을 때 의심할 것 (0) | 2026.08.20 |
| 파이썬 자동매매 시작하기 — 코딩의 '코'도 모르던 직장인의 첫걸음 (0) | 2026.08.19 |