플레이스테이션 2 시대의 엔진 최적화는 추상화보다 하드웨어 이해에서 출발했다
플레이스테이션 2는 지금 기준으로 보면 제한이 많은 하드웨어다. 메모리는 작았고, CPU와 그래픽 처리 흐름도 지금처럼 추상화되어 있지 않았다. 그런데 바로 그 제약 때문에, 이 시기의 엔진 프로그래밍은 대충 빠르게가 아니라 어디가 병목인지 정확히 아는 일에 가까웠다.
PS2를 설명할 때 자주 언급되는 Emotion Engine은 단순한 CPU 이름이 아니라, 벡터 연산과 데이터 이동을 어떻게 다뤄야 하는지를 개발자에게 강하게 요구한 구조였다. 이 시대의 최적화는 오늘날에도 의미가 있다. 왜 느린지 모른 채 추상 계층만 쌓는 대신, 실제 비용이 어디서 생기는지 보는 습관을 남겼기 때문이다.
PS2 최적화의 핵심은 벡터 연산과 데이터 이동이었다
기술 문서와 분석 자료를 보면 PS2에는 두 개의 벡터 유닛인 VU0, VU1이 있고, 이를 어떻게 활용하느냐가 성능과 직결됐다. 렌더링과 애니메이션, 기하 처리 같은 작업은 단순히 코드를 더 잘 짠다고 해결되지 않았다. 데이터를 어떤 순서로 배치하고, 언제 전송하고, 어떤 유닛에 맡길지까지 함께 설계해야 했다.
이 점은 오늘날 GPU 프로그래밍과도 닮아 있다. 하드웨어가 달라졌을 뿐, 계산과 이동을 분리해서 본다는 감각은 여전히 유효하다.
제약이 심할수록 설계가 더 구체적이어야 했다
PS2는 메모리 여유가 크지 않았기 때문에, 자산 관리와 스트리밍, 압축, 캐시 친화적인 데이터 배치가 중요한 문제였다. 즉, 최적화는 마지막에 붙이는 마법이 아니라 구조 선택의 결과였다.
그래서 PS2 시대의 엔진 프로그래머는 보통 이런 질문을 먼저 던졌을 것이다.
- 이 데이터는 연속적으로 읽히는가
- 계산보다 전송 비용이 더 큰가
- 이 처리는 CPU보다 벡터 유닛에 맡기는 편이 나은가
- 지금 편한 구조가 실제 하드웨어에서는 더 비싼가
이 질문들은 지금도 유효하다. 플랫폼이 바뀌었을 뿐, 병목은 여전히 메모리와 전송, 동기화에서 자주 생긴다.
지금 다시 PS2를 보는 이유
오늘날 Unity나 Unreal Engine 같은 게임 엔진을 쓰면 PS2 시대보다 훨씬 많은 부분이 자동화된다. 그래서 오히려 왜 느린지를 잊기 쉽다. PS2를 돌아보는 가치는 복고 감성보다 여기에 있다. 제한이 선명한 시스템은 성능이 추상 개념이 아니라 구체적인 비용이라는 사실을 다시 보여 준다.
PS2 최적화를 그대로 따라 할 필요는 없다. 대신 그 시대가 남긴 태도는 배울 만하다. 최적화는 막연한 장인정신이 아니라, 하드웨어와 데이터 흐름을 구체적으로 이해하는 일이라는 점이다.
마치며
플레이스테이션 2 시대의 엔진 개발은 지금보다 불편했지만, 그만큼 비용 구조가 잘 보였다. 벡터 유닛, 메모리 제약, 데이터 전송, 렌더링 파이프라인이 모두 코드와 직접 연결되어 있었기 때문이다.
그래서 PS2는 오래된 콘솔이면서도 여전히 좋은 교재가 된다. 성능 문제를 추상적인 불만이 아니라, 구조와 흐름의 문제로 보게 만들기 때문이다.