RetroArch 에뮬레이터 비교: 통합 vs 개별, 뭐가 나을까

레트로 게임 환경을 다시 만질 때마다 결국 같은 갈림길로 돌아오더라고요. RetroArch 에뮬레이터 비교를 진지하게 해보면 질문은 단순합니다. 설정을 표준화해서 오래 굴릴 것인가, 아니면 기종별로 최적점을 따로 잡을 것인가입니다. 저는 집 PC, 거실용 미니 PC, 휴대용 x86 장비를 오가며 두 방식을 오래 섞어 썼는데, 막상 체감 차이는 성능 숫자보다 운영 비용에서 더 크게 났습니다.

특히 세이브 파일, 세이브 스테이트, 셰이더, 입력 리맵, 비디오 드라이버, 코어 업데이트가 얽히기 시작하면 “실행된다”와 “관리 가능하다”의 간격이 꽤 벌어집니다. 그래서 이번 글은 RetroArch가 무조건 좋다, 개별 에뮬레이터가 무조건 낫다 같은 식으로 정리하지 않았습니다. 어디까지 통합해야 유지보수가 쉬운지, 반대로 어디서부터 분리해야 디버깅과 최적화가 편한지를 실전 기준으로 풀어보겠습니다.

BIOS 정리나 패드 매핑이 헷갈린다면 사이트의 관련 에뮬레이션 가이드도 함께 읽어보세요. 이 글과 같이 보면 세팅 실수가 훨씬 줄어듭니다.

RetroArch 프론트엔드와 여러 개별 에뮬레이터가 각각 게임, 입력 장치, 셰이더, 세이브를 어떻게 다루는지 보여주는 개요 이미지입니다.

RetroArch 에뮬레이터 비교의 핵심: UI보다 운영 구조

겉으로 보면 RetroArch는 메뉴 하나에 코어를 모아놓은 런처처럼 보이지만, 실제로는 공통 정책을 여러 시스템에 적용하는 실행 계층에 더 가깝습니다. 저장 위치를 통일하고, 공통 단축키를 맞추고, 셰이더 프리셋과 오버레이를 비슷한 방식으로 적용하고, 로그를 읽는 기준도 일정하게 가져갈 수 있죠. 장비가 여러 대일수록 이 장점이 진짜 크게 느껴집니다.

반대로 개별 에뮬레이터는 각 시스템에 필요한 설정을 더 직접적으로 드러냅니다. PPSSPP, Dolphin, PCSX2를 써보면 메뉴 구조가 대체로 직선적이라서 특정 기종 하나를 깊게 만질 때 덜 돌아갑니다. 저는 이 차이를 이렇게 봅니다. RetroArch는 통제 범위를 넓히는 도구이고, 개별 에뮬레이터는 시스템별 최적화 깊이를 늘리는 도구입니다.

RetroArch 에뮬레이터 비교: 무엇을 기준으로 고를까

실제로 판단할 때는 편의성만 보면 오히려 헷갈립니다. 저는 보통 다섯 가지를 먼저 봅니다. 시스템 수가 몇 개인지, 장비가 한 대인지 여러 대인지, 그래픽 옵션을 자주 만질지, 패드와 저장 경로를 표준화해야 하는지, 문제가 났을 때 로그 범위를 얼마나 빨리 좁힐 수 있는지입니다. 이 기준으로 보면 선택이 꽤 선명해집니다.

이 표만 보면 답이 뻔해 보이는데, 실제론 시스템 종류에 따라 갈립니다. 8비트, 16비트, 일부 아케이드, 일부 PS1처럼 공통 기능이 잘 먹는 영역은 RetroArch가 정말 효율적입니다. 반대로 PSP, GameCube/Wii, PS2처럼 전용 렌더러 옵션과 업스케일링, 게임별 예외 설정을 자주 만지는 시스템은 스탠드얼론이 더 직접적입니다.

제가 실제로 나누는 기준: 통합이 이득인 구간과 손해인 구간

이 부분은 운영 경험이 꽤 중요합니다. 저는 코어를 바꿔도 사용 감각이 크게 흔들리지 않는 시스템은 RetroArch로 묶습니다. 반대로 문제가 날 때 코어보다 기종 특화 옵션을 더 많이 만지게 되는 시스템은 처음부터 분리합니다. SNES, Mega Drive, GBA는 저장 정책과 셰이더만 통일해도 이득이 바로 느껴지거든요.

그런데 PS2나 Wii는 얘기가 달라집니다. 그래픽 백엔드, 내부 해상도, 게임별 호환성 우회 설정처럼 전용 메뉴를 보는 시간이 많습니다. 이런 시스템은 통합 UI 안에 억지로 넣어도 운영이 쉬워지지 않더라고요. 오히려 예외 처리만 늘어납니다.

실전 구성 1: RetroArch는 기능보다 경로 정책부터 고정해야 덜 무너집니다

RetroArch를 처음 세팅할 때 셰이더나 메뉴 테마부터 만지는 경우가 많은데, 제 경험상 그 순서는 효율이 낮았습니다. 먼저 잡아야 하는 건 디렉터리 정책과 입력 정책입니다. 나중에 코어를 바꾸거나 장비를 옮겨도 저장 위치와 BIOS 경로, 패드 규칙만 유지되면 재작업량이 확 줄어듭니다. 이거 진짜 편하더라고요.

1. ROM, BIOS, savefile, savestate, screenshot, playlist 경로를 분리합니다.
2. 전역 입력과 코어별 리맵을 섞지 말고 역할을 나눕니다.
3. 비디오 드라이버는 감으로 정하지 말고 로그 기준으로 확인합니다.
4. 플레이리스트를 만들기 전에는 코어 직접 실행으로 기본 동작부터 검증하고, 이후 메뉴의 Import Content 또는 Manual Scan으로 추가합니다.

아래 명령은 예시입니다. 실제 코어 파일 경로와 실행 파일 이름은 운영체제와 패키지 방식마다 달라질 수 있으니, 자신의 설치 환경에 맞춰 바꿔서 보시면 됩니다.

retroarch --menu
retroarch --verbose
retroarch -L /path/to/snes9x_libretro.so /srv/roms/snes/sample.sfc

여기서 --verbose는 거의 필수에 가깝습니다. RetroArch 문제의 절반은 “안 된다”가 아니라 “어느 계층에서 안 되는지 모르겠다”에서 시작하거든요. 로그를 보면 최소한 코어 로딩 실패인지, BIOS 경로 문제인지, 콘텐츠 인식 문제인지부터 갈라집니다. -L로 코어를 직접 지정하는 이유도 같습니다. 플레이리스트 메타데이터 문제를 잠깐 옆으로 치우고, 코어와 콘텐츠 조합이 실제로 되는지 먼저 보려는 겁니다.

# retroarch.cfg 예시
system_directory = "/srv/emulation/bios"
savefile_directory = "/srv/emulation/saves"
savestate_directory = "/srv/emulation/states"
playlist_directory = "/srv/emulation/playlists"
video_driver = "gl"
audio_enable = "true"
input_autodetect_enable = "true"
menu_swap_ok_cancel_buttons = "false"
quit_press_twice = "true"
config_save_on_exit = "false"
load_dummy_on_core_shutdown = "true"

여기서 중요한 건 값 자체보다 왜 이 값을 고정하는지입니다. system_directory를 따로 두면 BIOS 누락 문제를 추적할 때 경로 범위가 확 줄어듭니다. savefile_directory와 savestate_directory를 분리하면 일반 저장과 상태 저장도 덜 섞이고요. config_save_on_exit = "false"는 테스트 중 실수로 건드린 전역 설정이 그대로 남는 일을 줄이는 데 꽤 유용했습니다.

BIOS, saves, states, playlists 경로를 분리해 둔 RetroArch 설정 화면과 폴더 구조를 설명하는 이미지입니다.

실전 구성 2: 개별 에뮬레이터는 문제를 짧게 끝내는 구조가 장점입니다

개별 에뮬레이터의 장점은 단순히 옵션이 많다는 데 있지 않습니다. 더 중요한 건 문제 범위를 좁히기 쉽다는 점입니다. 예를 들어 PPSSPP에서 렌더링 이슈가 나면 PPSSPP 설정과 로그를 보면 되고, Dolphin에서 입력 충돌이 나면 Dolphin 프로필을 보면 됩니다. RetroArch처럼 프론트엔드 설정과 코어 설정, 콘텐츠 문제를 한꺼번에 의심할 필요가 적죠.

실행 예시도 구조가 단순합니다. 다만 아래 명령 역시 배포판, AppImage, Flatpak, 운영체제에 따라 실제 실행 파일 이름이 조금씩 다를 수 있습니다.

ppsspp --fullscreen /srv/roms/psp/sample.iso
pcsx2 -fullscreen -- /srv/roms/ps2/sample.iso
dolphin-emu --exec=/srv/roms/gc/sample.iso

이 구조는 특히 “오늘 특정 게임 하나를 맞춰야 하는 상황”에서 강합니다. 기종별 전용 설정이 눈앞에 바로 보이고, 저장 위치와 로그 위치도 보통 앱 기준으로 정리되기 때문이죠. 반면 단점도 분명합니다. 패드를 바꾸면 앱마다 다시 확인해야 하고, 단축키 철학이 달라서 장비를 바꿀수록 관리 피로가 쌓입니다.

제가 실제로 나누는 대상

• RetroArch로 묶는 편: 패미컴, 슈퍼패미컴, 메가드라이브, PC Engine, GBA, 일부 PS1
• 개별로 분리하는 편: PSP, PS2, GameCube/Wii
• 혼합 운용: 메인 런처는 RetroArch, 시스템별 예외가 많은 기종은 개별 에뮬레이터

이 혼합 구성이 중요한 이유는, 모든 것을 한 메뉴에 넣는 것과 운영이 편한 것이 같지 않기 때문입니다. 통합은 목적이 아니라 수단입니다. 예외가 늘어날수록 그 수단이 오히려 비용이 됩니다.

선택 기준을 더 좁혀보면: 이럴 땐 RetroArch, 저럴 땐 개별입니다

RetroArch 에뮬레이터 비교에서 자주 겪는 문제와 트러블슈팅

이 섹션은 기능 나열보다 원인 분리가 중요합니다. 같은 “실행 안 됨”이라도 근본 원인이 다르면 접근도 완전히 달라집니다. 저는 문제를 볼 때 항상 코어 계층, 콘텐츠 계층, 환경 계층, 입력 계층으로 나눠서 봅니다. 이 분류만 해도 삽질 시간이 꽤 줄어듭니다.

1. 코어는 보이는데 게임이 안 켜질 때

RetroArch에서는 코어 목록에 뜬다고 해서 실행 가능성이 바로 보장되지는 않습니다. 코어 파일이 존재하는지, 필요한 BIOS가 있는지, 콘텐츠 형식이 맞는지는 다 따로 봐야 합니다. 그래서 먼저 로그를 열고 키워드로 분기하는 게 빠릅니다.

• failed to open libretro core: 코어 파일 경로, 권한, 손상 여부를 먼저 봅니다.
• missing BIOS: system_directory 경로와 BIOS 파일명, 확장자, 대소문자 불일치를 확인합니다.
• failed to load content: 압축 포맷, 지원 확장자, 콘텐츠 손상 여부를 의심합니다.
• 플레이리스트에서는 보이는데 직접 실행은 안 됨: 스캔 결과보다 실제 콘텐츠 인식 쪽 문제일 가능성이 큽니다.

retroarch --verbose 2>&1 | grep -Ei "core|content|bios|failed|error"
retroarch -L /path/to/beetle_psx_hw_libretro.so /srv/roms/ps1/sample.cue

특히 PS1 계열은 .bin만 던져 넣고 왜 안 되지 싶을 때가 많습니다. 실제로는 .cue 기반 로딩 여부, BIOS 존재 여부, 멀티트랙 구조가 더 중요할 때가 많거든요. 저도 이 부분에서 시간을 꽤 썼습니다.

2. 소리는 나오는데 화면이 끊길 때

이 증상은 무조건 사양 부족으로 몰아가면 안 됩니다. 모든 코어에서 동일하면 비디오 드라이버나 동기화 계층을 먼저 의심해야 하고, 특정 코어에서만 재현되면 코어별 렌더링 방식이나 셰이더 체인을 먼저 보는 편이 맞습니다. 결국 증상 자체보다 재현 범위가 더 중요한 정보입니다.

• 모든 코어에서 끊김: video_driver, 디스플레이 동기화, 출력 계층을 먼저 봅니다.
• 특정 코어에서만 끊김: 해당 코어 옵션, 셰이더 적용, 해상도 스케일을 먼저 확인합니다.
• 셰이더 적용 후만 끊김: 셰이더를 끄고 증상이 사라지는지 먼저 봅니다.
• 전체 화면에서만 끊김: 창 모드와 비교해 출력 경로 문제인지 분리합니다.

저는 리눅스 박스에서 gl와 vulkan를 바꿔가며 원인을 분리한 적이 많았습니다. 중요한 건 어떤 쪽이 더 빠르다고 단정하는 게 아니라, 동일 ROM, 동일 코어, 동일 셰이더 상태에서 변수 하나씩만 바꾸는 것입니다. 이 원칙을 안 지키면 해결돼도 이유가 안 남습니다.

3. 패드 버튼이 메뉴와 게임에서 다르게 먹을 때

이 문제는 단순 매핑 오류보다 계층 충돌인 경우가 많습니다. RetroArch에는 메뉴 입력, 전역 입력, 코어별 리맵, 핫키 조합이 따로 있습니다. 그래서 한 군데만 고치고 끝내면 다른 층에서 다시 어긋나기 쉽습니다. 특히 메뉴의 OK/Cancel 전환이나 핫키 버튼 중복이 자주 문제를 만듭니다.

retroarch --verbose 2>&1 | grep -Ei "joypad|input|autoconfig|remap|bind|hotkey"

이 명령으로 확인할 때는 단순히 패드가 잡혔는지만 보지 말고, 어떤 autoconfig 프로파일이 적용됐는지, 리맵 파일이 로드됐는지, 핫키 바인딩이 일반 입력을 덮는지까지 같이 봐야 합니다. 메뉴는 정상인데 게임 안에서만 어색하면 전역 설정보다 코어 리맵 쪽을 먼저 의심하는 편이 효율적이었습니다.

4. 플레이리스트는 있는데 썸네일이 안 붙을 때

이건 설치가 망가졌다기보다 데이터 정규화 문제로 보는 편이 맞습니다. 스캔 이름, 데이터베이스 이름, 파일명 규칙이 어긋나면 썸네일이 비어 보일 수 있습니다. 이럴 때 다시 설치부터 하면 시간만 더 걸립니다. 먼저 플레이리스트 항목명과 실제 스캔 방식이 맞는지 보세요.

5. 세이브는 했는데 다음 실행에 안 보일 때

이 문제도 생각보다 자주 나옵니다. 원인은 보통 세 가지입니다. 일반 세이브와 세이브 스테이트를 혼동했거나, 저장 위치가 코어별과 전역으로 갈라졌거나, 쓰기 권한이 없는 경로를 보고 있는 경우입니다. 특히 테스트 중 경로를 여러 번 바꿔둔 환경에서 잘 터집니다.

코어 로드 실패, BIOS 누락, 패드 리맵 충돌을 로그 기준으로 분기해 해결하는 트러블슈팅 흐름도입니다.

검증: 세팅이 끝났는지 확인하는 기준은 켜짐이 아니라 재현성입니다

세팅 검증에서 가장 흔한 실수는 한 번 게임이 켜졌다는 이유로 완료 처리하는 겁니다. 그런데 실제 운영 단계에서는 첫 실행 성공보다 같은 조건에서 다시 성공하는지가 더 중요합니다. 그래서 저는 최소한 아래 항목은 꼭 묶어서 확인합니다.

1. 같은 패드로 메뉴 진입, 게임 플레이, 저장/불러오기가 모두 되는지
2. 세이브 파일과 세이브 스테이트가 의도한 디렉터리에 실제로 생성되는지
3. 코어를 바꿔도 공통 핫키가 유지되는지
4. 종료 후 다시 실행했을 때 설정과 저장 위치가 그대로 유지되는지
5. 로그에 치명적인 오류 없이 종료되는지

find /srv/emulation/saves -maxdepth 2 -type f | sort
find /srv/emulation/states -maxdepth 2 -type f | sort
retroarch --verbose 2>&1 | grep -Ei "save|state|error|warning"

검증도 애매하게 하면 안 됩니다. 예를 들어 세이브가 안 남았는데 게임 문제라고 넘기면, 나중에 경로 권한 문제를 놓친 채 환경 전체를 다시 손보게 되거든요. 셰이더 적용 후 끊김이 생기면 셰이더를 끄고 동일 ROM, 동일 코어에서 재현되는지부터 다시 보는 편이 좋습니다. 결국 핵심은 기능을 하나씩 빼가며 원인을 좁히는 겁니다.

반대로 개별 에뮬레이터 쪽은 검증 범위가 비교적 명확합니다. 실행된다, 전용 설정이 먹는다, 저장 위치가 예상대로다, 로그에 이상이 없다. 이 네 가지만 맞아도 대부분 바로 사용 단계로 넘어갈 수 있습니다.

에뮬레이션 환경 구축 후 세이브 경로, 컨트롤러 입력, 셰이더 적용 여부를 점검하는 체크리스트 이미지입니다.

상황별 추천: 누구에게 RetroArch가 맞고, 누구는 개별이 낫나

여기서는 애매하게 돌려 말리지 않겠습니다. 실제 운영 관점에서 보면 사용 패턴에 따라 답이 꽤 선명합니다.

• 기기 여러 대를 운영한다: RetroArch가 더 낫습니다. 설정 표준화와 백업 구조를 통일하기 쉽습니다.
• 한두 기종만 깊게 판다: 개별 에뮬레이터가 편합니다. 옵션 접근과 디버깅이 짧습니다.
• CRT 셰이더, 오버레이, 통합 UI가 중요하다: RetroArch 쪽 강점이 큽니다.
• PS2, Wii, PSP처럼 기기 특화 설정을 자주 건드린다: 스탠드얼론이 덜 답답합니다.
• 초보라서 세팅 스트레스를 줄이고 싶다: 개별 에뮬레이터로 시작한 뒤, 익숙해지면 RetroArch로 통합하는 순서가 안전합니다.
• 운영은 편해야 하지만 모든 기종을 한 UI에 넣고 싶지는 않다: 혼합 구성이 가장 실용적입니다.

저는 마지막 경우를 가장 자주 권합니다. 메인 런처는 RetroArch로 두고, 예외가 많은 시스템만 분리하는 방식이죠. 이렇게 하면 통합의 이점은 챙기면서도 기종별 예외 처리 때문에 전체 환경이 복잡해지는 걸 막을 수 있습니다.

자주 묻는 질문

RetroArch 하나만 익히면 모든 시스템을 다 커버할 수 있나요?

그렇게 기대하면 오히려 실망하기 쉽습니다. 공통 기능은 분명 편해지지만, 기종별 특화 이슈까지 사라지지는 않습니다. 오히려 코어라는 층이 하나 더 생기기 때문에 어떤 문제는 개별 에뮬레이터보다 생각할 게 늘어납니다.

개별 에뮬레이터가 항상 더 빠르거나 더 안정적인가요?

항상 그렇다고 보긴 어렵습니다. 다만 특정 시스템에 맞는 옵션 노출과 문제 추적 동선은 대체로 더 직접적입니다. 체감 차이는 순수 성능보다도, 어떤 설정을 어디서 만져야 하는지가 명확하다는 점에서 더 크게 납니다.

처음부터 혼합 구성을 잡아도 괜찮을까요?

괜찮습니다. 오히려 현실적입니다. 다만 기준 없이 섞으면 나중에 경로와 저장 방식이 뒤엉키기 쉽습니다. 적어도 저장 경로 정책, BIOS 위치, 패드 운용 원칙은 먼저 정해두는 편이 좋습니다.

마무리: RetroArch 에뮬레이터 비교의 결론은 예외 관리입니다

RetroArch 에뮬레이터 비교를 오래 해보면 답은 하나로 고정되지 않습니다. 기준은 의외로 단순합니다. 여러 시스템을 같은 감각으로 오래 굴리고 싶으면 RetroArch, 특정 콘솔 하나를 깊게 만지고 전용 옵션과 호환성 조정을 자주 할 거면 개별 에뮬레이터가 맞습니다.

한 줄로 압축하면 이렇습니다. 관리 일관성이 우선이면 RetroArch, 시스템별 완성도와 디버깅 속도가 우선이면 스탠드얼론입니다. 다만 실제로 가장 덜 지치는 선택은 둘 중 하나를 맹목적으로 고르는 게 아니라, 통합이 이득인 구간만 RetroArch에 맡기고 예외가 많은 기종은 분리하는 혼합 운용입니다. 저는 이 구성이 레트로 게임을 오래 즐길 때 가장 현실적이라고 봅니다.