밤새 빌드가 끝나지 않을 때 게임 개발 PC 예산별 선택법

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

퇴근 전에 시작한 전체 빌드가 다음 날 아침까지 이어진다면 문제는 단순히 컴퓨터가 느리다는 데 있지 않습니다. 코드 수정과 테스트 사이의 간격이 길어져 게임 프로그래밍의 반복 속도가 떨어지고, 개발자는 큰 변경을 피하거나 검증을 미루게 됩니다.

그렇다고 최고가 부품으로 게임 개발 PC를 구성하는 것이 항상 정답은 아닙니다. 엔진 소스 컴파일, 셰이더 빌드, 에셋 변환, 라이트 베이크는 서로 다른 부품을 요구하므로 실제 병목에 예산을 집중하는 구성이 훨씬 경제적입니다.

100만 원대에서는 화려한 GPU보다 빌드 대기 시간을 줄인다

개인 프로젝트와 게임잼에 맞는 최소 투자 순서

약 100만~160만 원의 예산이라면 CPU 코어 수만 보고 부품을 선택하기보다 메모리와 저장장치까지 균형을 맞춰야 합니다. Unity나 소규모 자체 엔진을 사용하는 개인 개발자는 6~8개의 고성능 CPU 코어, 32GB 메모리, 1TB 이상 NVMe SSD를 우선 확보하는 편이 좋습니다. 그래픽카드는 목표 게임을 안정적으로 실행하고 프로파일링할 정도면 충분합니다.

이 구간에서 16GB 메모리는 편집기, IDE, 브라우저, 그래픽 도구를 동시에 열었을 때 쉽게 한계에 도달합니다. 메모리가 부족해 운영체제가 SSD를 임시 메모리처럼 사용하면 컴파일러와 에셋 임포터의 체감 속도가 급격히 떨어집니다. 그래서 같은 예산이라면 GPU 등급을 한 단계 낮추고 32GB 메모리와 빠른 개발용 SSD를 확보하는 선택이 실용적입니다.

• CPU: 높은 단일 코어 성능과 6~8개 성능 코어를 우선합니다. 작은 소스 파일을 자주 컴파일하는 작업은 코어 수만 많다고 빨라지지 않습니다.
• 메모리: 32GB를 기본선으로 잡습니다. 대형 텍스처나 여러 엔진 인스턴스를 다룬다면 나중에 64GB로 확장할 수 있는 슬롯 구성이 유리합니다.
• 저장장치: 운영체제와 프로젝트를 NVMe SSD에 둡니다. 남은 용량이 지나치게 적으면 캐시 및 임시 파일 성능이 흔들릴 수 있으므로 여유 공간도 비용에 포함합니다.
• GPU: 플레이하려는 게임이 아니라 개발 중인 타깃 해상도와 렌더링 기능을 기준으로 고릅니다. CPU 중심의 2D 게임이나 툴 개발이라면 과투자를 피할 수 있습니다.

중고 부품을 섞고 싶다면 그래픽카드는 비교적 선택지가 넓지만 SSD와 전원공급장치는 사용 이력을 확인하기 어렵습니다. 작업 파일을 담는 SSD의 신뢰성과 전원 안정성은 빌드 속도뿐 아니라 데이터 안전에도 연결되므로 새 제품을 우선하는 편이 낫습니다.

예산이 빠듯할수록 평균 프레임보다 ‘코드를 고친 뒤 다시 실행할 때까지 몇 분이 걸리는가’를 측정하세요. 개발 PC의 가성비는 플레이 성능이 아니라 반복 한 번의 비용으로 판단해야 합니다.

업그레이드 전에 30분만 측정해야 하는 이유

전체 빌드를 한 번 실행하면서 작업 관리자나 운영체제 모니터링 도구로 CPU 사용률, 메모리 점유율, 디스크 활성 시간과 GPU 사용률을 기록해 보세요. CPU가 절반도 사용되지 않는데 디스크가 계속 100%라면 더 비싼 프로세서보다 프로젝트 저장장치 교체가 먼저입니다. 반대로 모든 코어가 장시간 가득 차고 메모리에 여유가 있다면 CPU 투자의 효과가 분명합니다.

1. 캐시를 유지한 증분 빌드 시간을 세 번 측정합니다.
2. 캐시를 지운 전체 빌드와 셰이더 컴파일 시간을 따로 기록합니다.
3. 에디터 실행부터 테스트 맵 진입까지 걸린 시간을 잽니다.
4. 가장 자주 반복하면서도 가장 오래 걸리는 구간에 예산을 배정합니다.

200만~350만 원대는 CPU·메모리·SSD를 작업별로 분리한다

상용 엔진과 중형 프로젝트의 가성비 구성

Unreal Engine 소스 빌드, 대량 셰이더 컴파일, 고해상도 에셋 처리가 일상이라면 약 200만~350만 원 구간에서 생산성이 크게 달라집니다. 이때는 12~16개급의 강한 CPU 코어, 64GB 메모리, 운영체제와 프로젝트를 분리할 수 있는 NVMe SSD 구성이 중심입니다. GPU는 렌더링 기능과 VRAM 요구량을 확인한 뒤 남은 예산에서 정합니다.

저장장치를 두 개로 나누는 목적은 보기 좋은 드라이브 구성이 아닙니다. 운영체제와 각종 애플리케이션이 사용하는 디스크에서 프로젝트 소스, 중간 산출물, 셰이더 캐시를 분리하면 동시에 발생하는 작은 읽기·쓰기 요청의 충돌을 줄일 수 있습니다. 원본 에셋과 자동 백업은 별도 대용량 저장장치나 NAS로 보내면 개발용 SSD 공간도 안정적으로 유지됩니다.

게임 개발 예산은 구매 가격만으로 계산하면 부족합니다. 컴파일 대기 시간, 전력, 백업 장치, 냉각 소음과 부품 고장 시 중단 시간까지 포함해야 합니다. 예산을 목적과 성과에 연결하는 개념은 계획예산 제도의 설명에서도 참고할 수 있습니다. 장비 한 대를 사는 일이 아니라 어떤 개발 시간을 단축할지 정하는 과정으로 접근하는 것입니다.

그래픽카드 예산을 높여야 하는 명확한 신호

GPU 투자는 실시간 레이 트레이싱, 복잡한 셰이더, 높은 해상도의 가상 텍스처, GPU 컴퓨트 기반 시뮬레이션을 직접 개발할 때 효과가 큽니다. 뷰포트가 자주 끊기거나 VRAM 부족으로 텍스처가 축소되고, 그래픽 디버거 캡처가 작업 자체를 방해한다면 GPU와 VRAM을 올릴 이유가 충분합니다.

반면 CPU 빌드가 20분 걸리는 동안 GPU 사용률이 거의 없다면 고가 그래픽카드는 그 20분을 줄여주지 못합니다. 기획과 프로그래밍을 함께 맡는 작은 팀이라면 장비 요구사항을 혼자 추측하지 말고 실제 제작 흐름을 나눠 적어보세요. 직무 간 역할을 살펴볼 때는 게임 기획자 관련 설명처럼 기획 업무의 범위를 확인하면 프로그래밍 장비와 공용 제작 장비의 예산을 구분하는 데 도움이 됩니다.

• 그래픽 기능 검증이 주업무라면 GPU와 VRAM 비중을 높입니다.
• C++ 엔진 개발이 중심이면 CPU 냉각 성능과 지속 부하 성능을 확인합니다.
• 월드 제작과 라이트 베이크를 병행하면 64GB 이상의 메모리 여유를 둡니다.
• 노트북이 필요하다면 최고 순간 성능보다 장시간 부하에서 유지되는 전력과 소음을 봅니다.
• 여러 플랫폼을 지원한다면 개발 PC 가격 외에 실기기와 테스트 장비 비용을 별도로 잡습니다.

네 명의 인디 팀이 500만 원으로 빌드 시간을 되찾은 과정

고사양 PC 한 대 대신 개발 흐름을 바꾼 실제형 사례

네 명이 협업하는 가상의 인디 팀을 따라가 보겠습니다. 이 팀은 Unreal Engine 기반의 3D 액션 데모를 제작하며 프로그래머 두 명, 아티스트 한 명, 기획 겸 레벨 디자이너 한 명으로 구성돼 있습니다. 사용 가능한 장비 예산은 500만 원이고, 가장 큰 불만은 프로그래머의 전체 빌드가 38분, 아티스트의 프로젝트 첫 실행이 14분 걸린다는 점입니다.

처음에는 500만 원을 최고 사양 PC 한 대에 모두 투입하려 했습니다. 하지만 하루 동안 로그를 수집해 보니 프로그래머 PC는 CPU가 계속 포화됐고, 아티스트 PC는 16GB 메모리가 가득 차면서 느린 보조 드라이브를 사용하고 있었습니다. 저장소에서 새 브랜치를 받은 뒤 각자 셰이더를 다시 만드는 중복 작업도 컸습니다.

1. 1단계: 230만 원으로 다코어 CPU, 64GB 메모리, 프로젝트 전용 NVMe SSD를 갖춘 메인 프로그래밍 PC를 구성했습니다. 전체 빌드는 38분에서 17분 수준으로 줄었습니다.
2. 2단계: 95만 원을 사용해 아티스트 PC의 메모리를 64GB로 늘리고 프로젝트 SSD를 교체했습니다. 에디터 첫 실행은 14분에서 6분대로 줄었고 대형 레벨을 열 때 발생하던 멈춤도 감소했습니다.
3. 3단계: 120만 원으로 화면 출력이 필요 없는 중고 기반 빌드 노드를 마련했습니다. 야간 전체 빌드, 패키징과 자동 테스트를 이 장비로 보내 구성원 PC가 장시간 점유되는 일을 막았습니다.
4. 4단계: 남은 55만 원은 백업 저장장치, 네트워크 장비와 예비 부품에 배정했습니다. 자동화 서버가 만든 검증된 결과물과 캐시를 내부 네트워크에서 공유하도록 설정했습니다.

이 사례의 핵심은 가장 비싼 PC가 아니라 팀 전체에서 반복되는 대기 시간을 제거한 것입니다. 메인 개발자는 더 빠르게 코드를 검증하고, 아티스트는 메모리 부족 없이 레벨을 열며, 자동 빌드는 사람이 쓰지 않는 장비에서 실행됩니다. 여러분의 팀에서도 한 사람이 10분을 아끼는 장비와 네 사람이 매일 5분씩 아끼는 장비 중 어느 쪽이 더 큰 효과를 내는지 계산해 볼 필요가 있습니다.

컨퍼런스에서 본 대형 스튜디오의 장비 구성을 그대로 복제하지 마세요. GDC의 성격과 배경을 이해하되, 발표 사례는 팀 규모와 제작 파이프라인이 자신의 환경과 같은지 확인한 뒤 적용해야 합니다.

세 달 뒤 이 팀은 절약된 반복 시간을 이용해 매일 자동 테스트 빌드를 만들고, 금요일마다 외부 플레이테스트 버전을 배포할 수 있게 됐습니다. 마지막 남은 예산을 새 그래픽카드에 쓰지 않고 백업과 네트워크에 남긴 덕분에 SSD 오류가 발생했을 때도 반나절 안에 작업을 복구했습니다. 결국 500만 원의 성과는 벤치마크 점수가 아니라 38분짜리 기다림을 개발 가능한 시간으로 바꾼 것으로 기록됐습니다.