OBS 33의 Legacy 플러그인, 계속 써도 될까?

세 줄 요약

OBS 33의 Legacy 표시는 플러그인이 구 설치 위치나 구조를 사용한다는 뜻이다.
구 경로 지원은 34부터 끝나며, 33에서도 개별 플러그인의 버전 호환성은 따로 확인해야 한다.
설치형과 포터블은 경로가 다르며, 안전 모드에서는 서드파티 플러그인을 불러오지 않는다.

Legacy 표시만으로 고장 난 플러그인은 아니다

10월 23일 공개된 OBS Studio 33.0.0은 플러그인을 불러오는 구조를 바꿨다. 릴리스 노트는 기존 서드파티 플러그인의 옛 경로를 34.0 전까지 계속 읽는다고 명시한다. 33으로 올렸다는 이유만으로 기존 설치가 모두 차단되는 것은 아니다.

플러그인 관리자의 Legacy 표시는 앞으로 지원이 끝날 위치나 폴더 구조에 설치됐다는 알림이다. ‘지금 로딩에 실패했다’는 결과와 구분해야 한다. 실제로 Lua Bridge 개발자는 10월 20일 공개 이슈에서 OBS 33 RC2의 Windows 포터블 환경에서 OBS_LEGACY_PLUGINS_PATH 환경변수로 구 경로를 지정해 플러그인을 불러온 시험을 보고했다. 특정 플러그인의 출시 후보 버전 시험이며, 모든 플러그인의 호환성을 보장하는 결과는 아니다.

DLL이 bin\64bit 밖으로 나온다

Windows 일반 설치의 새 구조에서는 플러그인 이름을 붙인 폴더 바로 아래에 DLL을 둔다. OBS의 이전 문서가 제시하는 예시는 다음과 같다.

C:\ProgramData\obs-studio\plugins\example-plugin\
  example-plugin.dll
  data\

예전 ProgramData 구조의 bin\64bit 단계가 빠진다. 한편 OBS 자체 모듈이 이동한 core 폴더는 외부 플러그인을 넣을 곳이 아니다.

제작자의 새 설치 패키지를 먼저 확인한다

파일 위치와 플러그인 호환성은 서로 다른 조건이다. 공식 플러그인 가이드는 운영체제, CPU 아키텍처, OBS 버전이 맞지 않으면 플러그인이 호환되지 않을 수 있다고 설명한다. 경로가 맞아도 x86_64용과 ARM64용을 혼용하거나 지원하지 않는 OBS 버전을 쓰면 문제가 남을 수 있다.

ProgramData의 단순한 구 구조는 파일을 위로 옮겨 해결되는 경우가 있지만, OBS는 Program Files 설치와 복잡한 의존성이 있는 플러그인에는 그 방법이 통하지 않는다고 명시한다. 제작자의 설치 프로그램이나 배포 안내를 확인하는 편이 우선이다. 폴더 이동만으로 모든 로딩 오류가 해결된다고 볼 수 없다.

포터블이라면 ProgramData에 넣어도 읽지 않는다

OBS 33의 포터블 실행은 설치 루트의 plugins\플러그인명\을 사용하고 ProgramData의 플러그인은 무시한다. 반면 macOS의 설치 위치는 이번에 바뀌지 않았다. 실행 방식에 맞는 안내를 골라야 한다.

안전 모드에서는 서드파티 플러그인을 아예 불러오지 않는다. 33부터는 WebSocket 서버도 시작하지 않으므로, 외부 제어 프로그램이 연결되지 않는 현상까지 설치 경로 문제로 판단해서는 안 된다.

확인 순서는 실행 모드, 플러그인 제작자의 지원 버전과 설치 안내, 정상 모드에서의 로딩 여부다. Legacy는 이전 준비가 필요하다는 신호다. 실제 실패 원인은 버전·아키텍처·실행 모드까지 나눠 확인해야 한다.