최근 개발자들이 공개한 데이터에 따르면, Helldivers 2의 HDD 사용자(지난주 기준 11%)도 미션 로딩 시간이 최악의 경우 몇 초 정도만 늘어나는 수준임을 확인했음
로딩의 대부분은 레벨 생성 과정 때문이며, 이는 디스크에서 에셋을 읽는 것과 병렬로 진행된다고 함
그런데도 설치 용량이 150GB 이상이었다는 건 납득하기 어렵고, 왜 이런 최적화가 가능했는데도 허용됐는지 의문이 남음
개발사 입장에서는 비용을 부담하지 않기 때문에 이런 상황이 생긴다고 봄
대부분의 유저는 게임 구매 전 디스크 요구 용량을 자세히 보지 않으므로 매출에 영향이 거의 없고, 반면 수정에는 개발 리소스가 필요함
만약 유저당 150GB의 클라우드 저장소 비용을 감당해야 했다면 즉시 해결됐을 것임
예전 성능 엔지니어로 일했을 때, 실제로 측정해보면 사람들이 잘못된 부분을 최적화하는 경우가 많았음
진짜 병목은 측정하면 금방 드러나고, 해결도 간단했음
하지만 이런 작업은 지루하고 비용이 드는 일이라 조직 내에서 우선순위가 낮았음
아직도 HDD로 HD2를 하는 사람이 11%나 된다는 게 놀라움
아마 설치 용량이 너무 커서 SSD 대신 보조 HDD에 설치하는 악순환이 있는 듯함
이런 일은 전혀 놀랍지 않음
많은 개발자들이 실제 데이터보다 감(감각) 으로 최적화를 진행함
기술적으로 보면 콘솔 버전은 처음부터 설치 용량이 작았음
콘솔은 SSD를 전제로 빌드되어 중복 데이터가 없었기 때문임
PC 버전의 154GB는 대규모 에셋 중복의 결과였고, 초기에는 40~60GB 수준이었음
이후 엔진(Bitsquid/Stingray, 위키 링크)가 단종된 상태에서 계속 개발을 이어가며 점점 커진 것임
지난 2년간 이 문제로 낭비된 하드웨어 자원이 최소 1,000만 달러에 달한다고 계산함
개발사는 수십만 달러의 엔지니어링 비용을 아끼기 위해 사용자에게 비용을 떠넘긴 셈임
이런 낭비를 막는 유일한 방법은 소프트웨어 품질을 중시하는 문화라고 생각함
Steam은 게임을 최대한 압축해서 배포하기 때문에 Helldivers 2의 경우 다운로드는 30~40GB였지만, 설치 후 150GB로 풀렸음 (SteamDB 링크)
사실 버그가 아니라 잘못된 HDD 로딩 시간 추정치에 기반한 오판된 최적화 결정이었음
개인적으로는 2TB 게임용 드라이브가 있어서 용량은 신경 쓰지 않았음
SSD 저장 공간의 월간 한계비용을 2.5달러/TB로 계산한 근거가 궁금하다는 질문이 나왔음
소비자 입장에서 이런 개념이 실질적인 비용인지 의문이라는 반응도 있었음
또 다른 사람은 “게임 하나 덜 설치하는 정도의 불편함일 뿐”이라고 덧붙였음
2014년 Titanfall도 비슷한 사례였음
전체 48GB 중 35GB가 비압축 오디오였는데, 듀얼코어 CPU를 위한 조치였다고 함 (관련 기사)
하지만 어떤 이는 “그건 변명”이라며, Half-Life 2도 MP3로 충분히 처리했음을 지적함
MP3 디코딩은 CPU 부하가 거의 없고, Titanfall의 오디오 포맷(160kbps OGG)은 손실 압축이었음
또 다른 사용자는 Opus 디코딩조차 30MHz 수준의 CPU만으로 가능하다고 하며, 당시 기술로도 문제없었음을 설명함 (성능 비교 링크)
AWS 계정에서 사용되지 않는 리소스를 정리해 월 1만 달러를 절약하는 사례와 비슷하다고 느낌
하지만 이번 경우는 단순히 잊힌 데이터가 아니라 접근 시간 최적화를 위한 중복 저장이었음
최근 Monster Hunter: Wilds 모드에서는 반대로 GPU 디컴프레션 병목을 줄이기 위해 텍스처를 미리 풀어 저장하는 방식이 쓰였음 (영상 링크)
우리 모두 이런 경험이 있지만, 이번엔 단순한 실수가 아니라 HDD 탐색 시간을 줄이려는 시도였음
나도 이제 클라우드 계정 정리하러 가야겠음
어떤 최적화가 있었는지 궁금했음
HDD는 물리적 배치가 일정하지 않아 중복 저장으로 탐색 시간을 줄이는 게 효과적이지 않을 수도 있음
혹시 단순히 빌드 시 ‘해시 기반 중복 제거’ 옵션을 꺼둔 게 원인이었을지도 모름
실제로는 여러 위치에 동일 파일을 복사해 HDD 탐색 시간을 줄이려 했던 것 같음
중복 제거 후 설치 용량이 크게 줄었고, 업데이트 파일이 오히려 전체 게임보다 컸음
이제는 SSD가 기본인데, HDD 최적화를 위해 이런 노력을 한 건 과한 감이 있음
HDD는 회전판과 읽기 헤드가 있어 광학 미디어와 유사한 최적화가 가능함
각 스테이지별로 필요한 공통 리소스를 중복 포함시켜 한 번에 읽어들이는 방식임
이는 대역폭을 위한 용량 희생 전략으로, 과거 CD 시절에도 쓰였던 기법임
최근 Hunt: Showdown을 다운로드했는데 70GB였고, 한 달 뒤 업데이트가 동일한 크기로 다시 다운로드됨
아마 전체 덮어쓰기 방식으로 업데이트를 처리한 듯함
반대로 일부 게임은 패치 용량은 작지만 패치 과정이 너무 느려서, 차라리 전체 재설치를 택하는 유저도 있음
나도 다른 게임에서 이런 경험이 있었음
수십 GB를 다시 받게 되는 건 정말 비효율적임
이런 문제는 Steam이 커지기 전 이미 대부분의 게임이 해결했던 부분임
Helldivers 2는 오래된 엔진(Bitsquid 기반)으로 만들어졌지만, 최신 기술이 아니어도 훌륭한 게임을 만들 수 있음을 보여줌
개발이 시작될 당시에는 엔진이 아직 단종되지 않았고, 처음부터 다시 만드는 것보다 계속 사용하는 게 합리적이었을 것임
Vermintide, Darktide에서도 같은 엔진 계열을 사용했으며, 여전히 충분히 쓸 만한 기술임
다만 이 엔진은 버그가 많고, 사운드 엔진 문제나 호스트-클라이언트 동기화 버그가 자주 발생함
커뮤니티가 직접 캠페인을 벌여 수정 요청을 해야 할 정도였음
지원이 중단된 엔진을 쓰지 않았다면 훨씬 안정적이었을 것임
예전에 게임 최적화 작업을 하며 런타임 기준으로 용량을 1/4로 줄였는데, 겉보기엔 똑같아서 프로듀서가 감흥이 없었던 기억이 있음
이번에도 내부 반발이 있었을지 궁금함
Steam이 SSD 용량이 부족하다고 판단해 HDD를 캐시로 사용하면서, 업데이트보다 전체 재설치가 더 빨랐던 경험이 있음
5분 다운로드 후 8시간 업데이트라니 황당했음
이번 업데이트로 이런 문제들이 개선되길 바람
예전에 사전 다운로드(preload) 가 오히려 느렸던 이유도 비슷했음
이미 암호화된 파일을 디스크에서 다시 복호화하느라 랜덤 액세스 부하가 커졌기 때문임
PC에서 중복 파일이 실제로 사용됐는지 궁금했음
HDD에서 특정 복제본이 더 빠른지 판단할 수 있을 정도로 파일 시스템 접근이 제한적인가 의문이었음
사실은 어떤 복제본을 쓰느냐가 아니라, 각 레벨 파일에 필요한 리소스를 중복 포함시켜 한 번에 읽게 하는 구조였음
이렇게 하면 HDD의 탐색 없이 연속 읽기가 가능해짐
이는 Crash Bandicoot 시절부터 쓰이던 방식이며, 2024년에 HDD 최적화를 한 이유는 단순히 엔진 제약 때문이었을 것임
또 다른 사람은 파일 시스템 자체가 이미 큰 아카이브처럼 동작하므로, 필요한 데이터를 순차적으로 묶어 저장하면 성능 저하 없이 간단히 해결할 수 있다고 설명함
Hacker News 의견
최근 개발자들이 공개한 데이터에 따르면, Helldivers 2의 HDD 사용자(지난주 기준 11%)도 미션 로딩 시간이 최악의 경우 몇 초 정도만 늘어나는 수준임을 확인했음
로딩의 대부분은 레벨 생성 과정 때문이며, 이는 디스크에서 에셋을 읽는 것과 병렬로 진행된다고 함
그런데도 설치 용량이 150GB 이상이었다는 건 납득하기 어렵고, 왜 이런 최적화가 가능했는데도 허용됐는지 의문이 남음
대부분의 유저는 게임 구매 전 디스크 요구 용량을 자세히 보지 않으므로 매출에 영향이 거의 없고, 반면 수정에는 개발 리소스가 필요함
만약 유저당 150GB의 클라우드 저장소 비용을 감당해야 했다면 즉시 해결됐을 것임
진짜 병목은 측정하면 금방 드러나고, 해결도 간단했음
하지만 이런 작업은 지루하고 비용이 드는 일이라 조직 내에서 우선순위가 낮았음
아마 설치 용량이 너무 커서 SSD 대신 보조 HDD에 설치하는 악순환이 있는 듯함
많은 개발자들이 실제 데이터보다 감(감각) 으로 최적화를 진행함
콘솔은 SSD를 전제로 빌드되어 중복 데이터가 없었기 때문임
PC 버전의 154GB는 대규모 에셋 중복의 결과였고, 초기에는 40~60GB 수준이었음
이후 엔진(Bitsquid/Stingray, 위키 링크)가 단종된 상태에서 계속 개발을 이어가며 점점 커진 것임
지난 2년간 이 문제로 낭비된 하드웨어 자원이 최소 1,000만 달러에 달한다고 계산함
개발사는 수십만 달러의 엔지니어링 비용을 아끼기 위해 사용자에게 비용을 떠넘긴 셈임
이런 낭비를 막는 유일한 방법은 소프트웨어 품질을 중시하는 문화라고 생각함
개인적으로는 2TB 게임용 드라이브가 있어서 용량은 신경 쓰지 않았음
소비자 입장에서 이런 개념이 실질적인 비용인지 의문이라는 반응도 있었음
또 다른 사람은 “게임 하나 덜 설치하는 정도의 불편함일 뿐”이라고 덧붙였음
2014년 Titanfall도 비슷한 사례였음
전체 48GB 중 35GB가 비압축 오디오였는데, 듀얼코어 CPU를 위한 조치였다고 함 (관련 기사)
MP3 디코딩은 CPU 부하가 거의 없고, Titanfall의 오디오 포맷(160kbps OGG)은 손실 압축이었음
AWS 계정에서 사용되지 않는 리소스를 정리해 월 1만 달러를 절약하는 사례와 비슷하다고 느낌
최근 Monster Hunter: Wilds 모드에서는 반대로 GPU 디컴프레션 병목을 줄이기 위해 텍스처를 미리 풀어 저장하는 방식이 쓰였음 (영상 링크)
나도 이제 클라우드 계정 정리하러 가야겠음
어떤 최적화가 있었는지 궁금했음
HDD는 물리적 배치가 일정하지 않아 중복 저장으로 탐색 시간을 줄이는 게 효과적이지 않을 수도 있음
혹시 단순히 빌드 시 ‘해시 기반 중복 제거’ 옵션을 꺼둔 게 원인이었을지도 모름
중복 제거 후 설치 용량이 크게 줄었고, 업데이트 파일이 오히려 전체 게임보다 컸음
이제는 SSD가 기본인데, HDD 최적화를 위해 이런 노력을 한 건 과한 감이 있음
각 스테이지별로 필요한 공통 리소스를 중복 포함시켜 한 번에 읽어들이는 방식임
이는 대역폭을 위한 용량 희생 전략으로, 과거 CD 시절에도 쓰였던 기법임
최근 Hunt: Showdown을 다운로드했는데 70GB였고, 한 달 뒤 업데이트가 동일한 크기로 다시 다운로드됨
아마 전체 덮어쓰기 방식으로 업데이트를 처리한 듯함
수십 GB를 다시 받게 되는 건 정말 비효율적임
이런 문제는 Steam이 커지기 전 이미 대부분의 게임이 해결했던 부분임
Helldivers 2는 오래된 엔진(Bitsquid 기반)으로 만들어졌지만, 최신 기술이 아니어도 훌륭한 게임을 만들 수 있음을 보여줌
커뮤니티가 직접 캠페인을 벌여 수정 요청을 해야 할 정도였음
지원이 중단된 엔진을 쓰지 않았다면 훨씬 안정적이었을 것임
예전에 게임 최적화 작업을 하며 런타임 기준으로 용량을 1/4로 줄였는데, 겉보기엔 똑같아서 프로듀서가 감흥이 없었던 기억이 있음
이번에도 내부 반발이 있었을지 궁금함
Steam이 SSD 용량이 부족하다고 판단해 HDD를 캐시로 사용하면서, 업데이트보다 전체 재설치가 더 빨랐던 경험이 있음
5분 다운로드 후 8시간 업데이트라니 황당했음
이번 업데이트로 이런 문제들이 개선되길 바람
이미 암호화된 파일을 디스크에서 다시 복호화하느라 랜덤 액세스 부하가 커졌기 때문임
PC에서 중복 파일이 실제로 사용됐는지 궁금했음
HDD에서 특정 복제본이 더 빠른지 판단할 수 있을 정도로 파일 시스템 접근이 제한적인가 의문이었음
이렇게 하면 HDD의 탐색 없이 연속 읽기가 가능해짐
이는 Crash Bandicoot 시절부터 쓰이던 방식이며, 2024년에 HDD 최적화를 한 이유는 단순히 엔진 제약 때문이었을 것임