---
title: "CRT 모니터의 마법을 되살리기 위해 게임 엔진을 직접 만든 이야기"
published: 2026-03-22T23:15:03.000Z
canonical: https://jeff.news/article/924
---
# CRT 모니터의 마법을 되살리기 위해 게임 엔진을 직접 만든 이야기

Unreal/Unity 10년차 개발자가 $35 CRT 모니터를 사고 난 뒤, 기존 엔진의 포스트프로세싱 한계를 깨닫고 CRT 물리 시뮬레이션을 위한 자체 게임 엔진(Retro Game Engine)을 D3D12로 만든 이야기.

## $35짜리 CRT에서 시작된 집착

- 저자는 Unreal과 Unity를 10년 가까이 사용한 3D 아티스트 출신 개발자임. CRT 필터나 포스트프로세스 머터리얼을 만들어봤고, 기억 속 어린 시절과 비교하면 "괜찮네" 수준이었음

- 전환점은 **1998년산 Sharp CRT를 $35에 사와서 SNES를 꽂은 날**. 모션이 프로즌 프레임의 빠른 재생이 아니라 자연스럽게 흘렀고, 밝은 물체가 진짜 유리 아래의 물리적 빛처럼 행동했고, 픽셀이 현대 디스플레이가 훈련시킨 "픽셀"과 다른 뭔가였음

- 어린 시절 추억이 없는 오래된 콘솔 게임을 해봐도 같은 마법이 느껴졌음. "우리가 잃어버린 건 해상도나 충실도가 아니라, **하드웨어와 아트 디렉션과 플레이어 사이의 관계** 전체였다"

## 왜 기존 엔진으로는 안 되는가

- 현대 게임 엔진의 렌더링 모델: 가상 카메라 → 3D 월드 촬영 → 프레임버퍼 → 포스트프로세싱 → 출력. Unity는 포스트프로세싱을 카메라/필름 속성으로 설명하고, Unreal도 톤매핑과 TAA 이후의 최종 LDR 컬러에서 작업함

- **CRT는 카메라가 아님**. 물리적 프로세스의 결과로 이미지를 생성하는 디바이스임:
  - 전자빔이 화면을 시간에 걸쳐 스캔함
  - 형광체가 빔에 의해 여기(excite)되어 빛을 방출
  - 형광체가 시간에 따라 흥분을 잃으면서 감쇠(decay)
  - 마스크 기하(섀도 마스크, 애퍼처 그릴 등)가 빛의 착지와 혼합에 영향
  - 프레임이 단일 순간이 아니라 **시간에 걸친 통합의 결과**

- 이 근본적인 차이 때문에 기존 엔진에 볼트온 하려고 하면 한계에 부딪힘. Unreal의 포스트프로세싱은 톤매핑 이후라서 파이프라인 초반에 개입하기 어렵고, 스왑 체인은 엔진이 추상화해놓아서 건드릴 수가 없음

## 자기 엔진을 만드는 이점

- **Retro Game Engine**은 D3D12 + Win32 프로토타입에서 시작해서 풀 파이프라인으로 성장함. CRT "효과"가 아니라 CRT의 물리적 동작 각 부분을 연구하고 구현한 **디스플레이 시뮬레이션**임

- 입력 신호가 뭔지, 디스플레이가 그걸 어떻게 처리하는지, 시간이 어떻게 영향을 주는지, 뭘 언제 출력하는지를 전부 소유함. 스왑 체인의 버퍼 수명, 프레젠트 타이밍, 프레임 간 보존되는 것과 시간에 걸쳐 누적되는 것을 직접 제어할 수 있음

- "예전 게임은 플레이어의 상상력과 협업해야 했음. 대담한 실루엣, 강렬한 컬러, 노이즈는 적고 정체성은 높은 세계. '제한의 부재가 예술의 적이다'라는 격언이 시간이 지날수록 더 맞는 것 같다"

- Unreal이나 Unity를 대체하려는 게 아님. 필립스 드라이버처럼 한 가지만 잘하는 도구. 정확성과 리얼리즘을 쫓는 대신 **제한을 의도적으로 받아들이는 게임**을 만들 수 있는 도구를 목표로 함

## 핵심 포인트

- CRT는 카메라 모델이 아니라 전자빔+형광체의 물리적 디스플레이 시뮬레이션
- 기존 엔진은 톤매핑/TAA 이후의 최종 LDR에서 포스트프로세싱하므로 CRT 동작 재현에 한계
- 스왑 체인 제어가 CRT의 시간적 에너지 축적 시뮬레이션에 핵심
- Unreal/Unity 대체가 아니라 필립스 드라이버처럼 한 가지를 잘하는 도구 목표

## 인사이트

CRT 필터와 CRT 시뮬레이션의 근본적 차이를 기술적으로 설명하는 부분이 인상적. '제한이 예술의 적'이라는 철학과 기술적 구현이 만나는 지점.