제품 가격표보다 먼저 현재 병목을 측정한다. 음성이 끊기면 카메라보다 오디오 경로, 신호가 불안하면 케이블·전원·캡처, 인코딩이 밀리면 PC와 설정, 업로드가 부족하면 네트워크를 우선한다. 구매 전 현장 대여 또는 반품 가능한 방식으로 실제 예배 장면을 테스트한다. 가격은 지역·시점에 따라 달라지므로 이 글에서는 확인되지 않은 금액을 제시하지 않는다.
신뢰성부터 화질까지
예산표보다 먼저 병목을 기록한다
최근 세 번의 방송에서 발생한 문제를 음성, 영상 신호, 인코딩, 네트워크로 분류합니다. 문제 발생 시각과 OBS 통계, 업로드 속도, 케이블·전원 상태를 기록하면 구매가 필요한지 설정과 운용이 필요한지 구분할 수 있습니다.
돈보다 먼저 측정
1순위는 들리는 예배와 끊기지 않는 경로
시청자는 영상이 조금 단순해도 메시지를 들을 수 있지만 음성이 끊기면 예배를 따라가기 어렵습니다. 마이크에서 믹서, PC, OBS까지 한 경로씩 확인하고 예비 케이블·전원·로컬 녹화를 먼저 준비합니다.
필수·안정화·확장
PC와 네트워크는 목표 출력으로 시험한다
OBS의 최소 사양 통과는 안정적 스트리밍 보증이 아닙니다. 실제 장면 수와 자막, 오디오를 켜고 목표 해상도·FPS로 비공개 테스트합니다. 인코더 과부하가 있으면 장면을 줄이고 60fps를 30fps로 낮추는 등 설정부터 검증합니다.
대여·테스트·기록
구매 결정을 세 단계로 나눈다
필수 복구는 방송 중단을 막는 항목, 안정화는 반복 장애를 줄이는 항목, 확장은 카메라 각도·조명처럼 경험을 높이는 항목입니다. 견적은 모델명, 연결 규격, 포함 액세서리, 보증, 조사일을 함께 기록하고 확인되지 않은 가격을 채우지 않습니다.
한 번에 하나씩
FAQ
카메라부터 바꾸면 화질이 좋아지나요?
조명, 렌즈, 캡처, 인코딩, 업로드가 병목이면 카메라만 바꿔도 체감이 작습니다.
예비 장비는 낭비 아닌가요?
예배 중단 비용이 큰 케이블·어댑터·전원처럼 저비용 단일 장애 지점부터 예비를 둡니다.
실행 체크리스트
담당자와 완료 시각을 정했는가?
공식 문서에서 바뀔 수 있는 설정을 다시 확인했는가?
실제 데이터와 테스트 결과를 기록했는가?
개인정보와 저작권을 점검했는가?
실패할 때 되돌릴 방법이 있는가?
결론
교회 방송 장비 예산, 무엇부터 써야 할까｜실패를 줄이는 우선순위 설계의 핵심은 도구를 늘리는 것이 아니라, 현재 문제를 작게 정의하고 확인 가능한 순서로 실행하는 것입니다. 한 번에 하나씩 적용하고 기록을 남기면 다음 담당자도 같은 결과를 재현할 수 있습니다.
입력 규격은 장치가 받을 수 있는 신호, 패스스루는 모니터로 보낼 수 있는 신호, 캡처 규격은 컴퓨터에 전달되는 신호, 송출 규격은 OBS가 인코딩하는 결과다. “4K 지원”이 4K 입력과 1080p 캡처를 뜻할 수도 있으므로 제조사 표에서 네 값을 따로 확인해야 한다.
HDMI와 SDI
교회 방송 환경
HDMI는 카메라와 소비자 장비에서 흔하고 짧은 구간에 경제적이다. 커넥터가 잠기지 않고 긴 구간에서 설치 품질의 영향을 크게 받는다. SDI는 잠금식 BNC와 장거리 배선에 유리하지만 카메라·스위처·캡처 장치 전체가 같은 SDI 표준을 지원해야 한다. 예배당 뒤편에서 방송실까지 고정 배선이 길다면 SDI 또는 검증된 변환 경로가 관리하기 쉽고, 카메라와 노트북이 가까운 소형 환경은 HDMI가 단순하다.
USB, Thunderbolt, PCIe
연결 방식 비교
USB UVC 장치는 별도 제조사 드라이버 없이 표준 비디오 장치로 보이는 경우가 많아 이동형 노트북에 적합하다. 다만 “USB 3.x”라는 이름만으로 실제 포트 대역폭과 컨트롤러 공유 여부를 알 수 없다. 허브에 저장장치와 카메라를 함께 연결하면 끊김이 생길 수 있다. PCIe는 데스크톱에서 여러 입력과 높은 지속 처리량에 유리하지만 설치와 이동성이 떨어진다. Thunderbolt는 외장형 고대역폭 장치에 유리하되 컴퓨터와 케이블 호환을 별도로 확인한다.
OBS 인증 기준이 알려주는 것
캡처 신호 흐름
OBS의 인증 장치 기준은 단순히 화면이 잡히는지를 넘어 평균 추가 지연, 모드 전환, 장시간 오디오 동기, 패스스루, HDR 톤매핑을 본다. 인증 목록에 없다고 사용할 수 없다는 뜻은 아니지만, 장시간 예배 방송에서는 5분 데모보다 수 시간의 동기와 재연결 동작이 더 중요한 평가 항목이라는 점을 보여준다.
상황별 선택표
환경
우선 방식
확인할 핵심
카메라 1대·노트북
HDMI + UVC USB
1080p 캡처, 전용 USB 포트, 재연결
장거리 고정 배선
SDI
표준 일치, 변환기 전원, 케이블 품질
여러 카메라
스위처 또는 다입력 PCIe
입력별 동기, 오디오 경로, PCIe 대역폭
4K 촬영·1080p 송출
4K 입력 + 1080p 캡처
다운스케일 품질, 발열, 실제 출력 모드
오디오는 별도의 경로다
HDMI 오디오를 쓸지 믹서의 USB/오디오 인터페이스를 쓸지 먼저 정한다. 영상은 캡처보드, 음성은 믹서에서 받으면 두 장치의 시간 기준이 달라 장시간에 걸쳐 동기가 움직일 수 있다. 실제 구성으로 최소 한 번의 전체 예배 길이만큼 녹화해 입 모양과 소리를 확인한다.
구매 전에는 사양표보다 신호표를 만든다
카메라 모델과 출력 해상도·프레임레이트, 케이블 종류와 길이, 컴퓨터 포트, 운영체제, OBS 목표 해상도, 오디오 출처를 한 장에 적는다. 제조사 지원표에서 정확히 일치하는 모드를 확인하고, 반품 가능 기간 안에 재부팅·절전 복귀·케이블 재연결·장시간 녹화를 시험한다.
공식 사양으로 보는 실제 제품 예시
추천 순위가 아니라 연결 방식별 차이를 이해하기 위한 예시입니다. 구매 전 정확한 모델의 최신 공식 사양을 다시 확인하세요.
이 표에서 중요한 차이는 단자보다 host 연결과 운용 규모입니다. USB/UVC는 이동성과 설치 편의가 강점이고, Thunderbolt·PCIe는 긴 SDI 배선이나 다중 입력에서 선택지가 넓어집니다. *Cam Link의 2160p 지원 모드는 모델과 카메라 조건에 따라 달라지므로 최신 공식 사양을 확인해야 합니다.
이 표에서 중요한 차이는 단자보다 host 연결과 운용 규모입니다. USB/UVC는 이동성과 설치 편의가 강점이고, Thunderbolt·PCIe는 긴 SDI 배선이나 다중 입력에서 선택지가 넓어집니다. *Cam Link의 2160p 지원 모드는 모델과 카메라 조건에 따라 달라지므로 최신 공식 사양을 확인해야 합니다.
두 가지 교회 환경을 가정해 보면
카메라 1대, 5m 배선, 1080p60, 노트북이라면 HDMI/UVC 구성과 전용 USB 포트가 단순합니다. 카메라 3대, 30m 고정 배선이라면 SDI·스위처 또는 다입력 PCIe와 오디오 동기를 함께 설계하는 편이 관리하기 쉽습니다. 이는 실제 사례가 아니라 선택 원리를 설명하기 위한 가정입니다.
용어 설명
UVC는 표준 USB 비디오 장치 규격, 패스스루는 입력 신호를 모니터로 다시 보내는 출력, EDID는 지원 해상도와 프레임 정보를 알리는 데이터입니다. HDCP가 적용된 신호는 캡처가 제한될 수 있으며, Latency는 입력부터 표시까지의 지연입니다.
영상으로 보는 캡처 입력
2분 43초부터 UltraStudio Recorder 3G를 OBS에서 사용하는 흐름과 Thunderbolt 조건을 확인할 수 있습니다.
5분 35초부터 Video Source 추가, 17분 14초부터 테스트 녹화 흐름을 볼 수 있습니다.
다음 학습 경로
카메라 출력 확인 → 캡처 장치 선택 → 방송 PC 부하 확인 → 오디오 경로 설계 → OBS 녹화 검증 순으로 읽으면 전체 신호 경로를 연결하기 쉽습니다.
교회 음향을 OBS에 연결한다는 것은 Cable 하나를 꽂는 일이 아니다. 예배당에서 들리는 Main PA Mix와 Online 시청자가 필요한 Broadcast Mix는 청취 환경이 다르며, Mixer의 어느 Bus가 어떤 Level과 Channel로 PC에 들어오는지 알아야 한다.
핵심은 `Microphone → Mixer Input → Channel Processing → Broadcast Bus → USB/Line Output → Audio Interface → OS Device → OBS Source → Stream Track`을 하나의 신호 경로로 보는 것이다. 무음, 한쪽 Audio, 왜곡, Echo는 이 경로의 서로 다른 지점에서 생긴다.
USB 직결과 Audio Interface는 같은 경로가 아니다
Microphone에서 YouTube까지 이어지는 Audio 신호 경로
USB Audio 기능이 있는 Mixer는 Digital 신호를 PC로 직접 보낼 수 있다. 하지만 어떤 Bus가 USB로 나가는지, Stereo 2-channel인지 Multiple channel인지, Driver가 필요한지는 Model마다 다르다. Yamaha MG-XU처럼 USB Audio Interface 기능을 제공하는 제품도 실제 Routing은 Manual을 확인해야 한다.
Line Output을 별도 Audio Interface로 받으면 Mixer의 AUX, Matrix, Group 또는 Record Output을 방송용으로 선택할 수 있다. 대신 Output Level과 Interface Input mode, Cable wiring, 추가 Gain stage를 관리해야 한다.
연결 방식
Signal Path
장점
반드시 확인할 항목
Mixer USB 직결
Mixer Bus → USB → PC
Cable과 변환 단계가 적음
USB로 나가는 Bus, Channel 수, Driver, Sample Rate
Stereo Line → Interface
Mixer Output → Interface Line Input → USB
Broadcast Bus를 명확히 분리 가능
Line Level, Balanced 여부, Input 1/2 Gain
Analog Record Out → Interface
Fixed/Record Output → Interface
단순한 기존 Mixer에 적용 가능
Level 조정 가능 여부와 Main Mix 의존성
Network Audio
Mixer/Stagebox → Network → PC
다중 Channel과 먼 거리
Protocol, Clock, Network 분리, Driver
USB가 있다는 사실만으로 독립 Broadcast Mix가 생기는 것은 아니다. USB가 Main Stereo만 보내면 예배당 Mix의 Balance가 그대로 Online에 전달될 수 있다.
Gain은 신호가 만들어지는 순서대로 본다
Mixer USB와 Audio Interface의 서로 다른 Routing
Microphone preamp에서 충분하고 clipping 없는 신호를 만들고, Channel fader와 Broadcast Bus를 지나, Output과 Interface Input, OBS fader로 이동한다. 뒤쪽 OBS fader를 올려 앞단의 매우 작은 신호를 보상하면 Noise도 함께 커진다. 앞단이 clipping된 신호는 OBS에서 fader를 낮춰도 복구되지 않는다.
관찰 지점
정상적으로 확인할 것
문제가 있을 때 앞단 확인
Mixer Input Meter
평소 말소리와 큰 소리의 여유
Microphone, Cable, Preamp Gain
Broadcast Bus Meter
말·찬양의 Online Balance
Send Level, Pre/Post Fader, Mute
Interface Meter
Line Input에 맞는 Level
Output Type, Pad, Input Gain
OS Input
올바른 Device와 Channel
Driver, Privacy permission, Sample Rate
OBS Meter
실제 Program에 포함된 신호
Source 선택, Monitor/Output, Track
YouTube Watch Page
시청자가 듣는 최종 결과
Encoder Audio Track, Platform input
OBS Audio Meter의 빨간 영역에 계속 닿으면 Digital clipping 위험이 있다. Limiter는 예상하지 못한 peak를 제한하는 마지막 안전장치일 수 있지만, 과도한 Preamp Gain과 잘못된 Bus Routing을 해결하지는 않는다.
Mono와 Stereo는 Channel 수가 아니라 의미의 문제다
Mono·Stereo Channel을 구분하는 구조
한 개 Microphone은 보통 Mono Source다. Interface Input 1에만 들어온 신호가 Stereo Source의 Left에 배치되면 한쪽 귀에서만 들릴 수 있다. Cable을 Y로 임의 분배하기보다 OBS Advanced Audio Properties에서 Source의 실제 성격을 확인해 Downmix to Mono를 적용한다.
반면 Piano, Playback, Stereo Main Mix처럼 Left/Right 정보가 있는 Source를 무조건 Mono로 합치면 공간감이 사라지거나 위상 문제로 일부 소리가 줄 수 있다. 어떤 Source가 Mono이고 어떤 Source가 Stereo인지 Mixer와 OBS에서 같은 기준으로 정한다.
같은 Device를 두 번 Capture하면 Echo가 생긴다
OBS는 Settings → Audio에서 Global Audio Device를 활성화할 수 있고, Scene에 Audio Input Capture Source를 추가할 수도 있다. 같은 Mixer USB 또는 Interface를 두 경로에서 동시에 Capture하면 중복 신호, comb filtering, Echo처럼 들릴 수 있다.
Scene마다 Audio 구성이 필요하면 Global Device를 Disable하고 Source로 명시한다. 모든 Scene에서 같은 신호를 공유하려면 Source를 복제하기보다 기존 Source를 참조해 Gain과 Sync 설정이 갈라지지 않게 한다.
Monitoring도 구분해야 한다. `Monitor Only`, `Monitor and Output`, `Monitor Off`는 담당자 Headphone과 Stream으로 보내는 경로를 바꾼다. PC Speaker로 Monitor한 소리가 다시 Microphone에 들어오면 Acoustic Echo가 생길 수 있으므로 Closed Headphone을 사용한다.
Sample Rate와 Clock은 장시간 Sync에 영향을 준다
Mixer, Interface, OS, OBS의 Sample Rate를 가능한 한 공통 값으로 맞춘다. 서로 다른 Clock을 가진 Capture Video와 USB Audio는 짧은 Test에서는 맞아도 시간이 지나며 Drift가 생길 수 있다. 숫자를 임의로 보정하지 말고 시작·20분·40분 지점의 Clap 또는 명확한 transient를 Recording에서 비교한다.
증상
우선 조사할 구간
구분 방법
OBS Meter가 전혀 움직이지 않음
Mixer Output → OS Device → OBS Source
각 지점에서 신호를 한 단계씩 확인
한쪽만 들림
Cable, Interface Channel, Mono/Stereo
Input 1/2 Meter와 Downmix 비교
소리가 찌그러짐
Preamp, Bus, Interface, OBS
최초로 Peak가 잘리는 지점 탐색
겹치거나 Echo
Duplicate Capture, Monitoring, Acoustic return
Source를 하나씩 Mute해 중복 확인
일정한 Lip Sync 차이
Video/Audio 처리 지연
Local Recording에서 Offset 측정
시간이 갈수록 Sync가 변함
Device Clock, Sample Rate, Driver
장시간 Marker로 Drift 측정
Noise Suppression, Gate, Compressor는 신호 경로가 정상인 뒤 필요한 Source에 제한적으로 적용한다. Gate로 작은 설교 음성을 잘라 버리거나 Suppression으로 음악을 손상시키지 않도록 실제 찬양과 말소리로 비교한다.
Stream과 Recording을 함께 들어야 한다
Mixer·OBS·Recording·Watch Page를 함께 듣는 검증
Mixer Headphone, Interface Direct Monitor, OBS Monitor, Local Recording, YouTube Watch Page는 서로 다른 지점이다. 앞의 세 곳에서 정상이어도 Stream Track에서 Source가 제외되면 시청자는 듣지 못한다. Multiple Recording Track을 쓰더라도 YouTube로 보내는 Track에는 필요한 모든 Source가 들어 있어야 한다.
예배와 같은 60분 Test에서 설교, 찬양, Playback, 무음 구간을 포함한다. Local Recording과 다른 기기의 YouTube Watch Page를 같은 구간에서 비교하고, OBS Stats와 Stream Health의 시각도 함께 남긴다.
좋은 OBS Audio 연결은 Cable 종류보다 신호가 어느 Bus와 Level, Channel, Clock을 지나 시청자에게 도착하는지 설명할 수 있는 구조다. 이 구조가 보이면 무음·한쪽·왜곡·Echo·Sync 문제를 Filter가 아니라 원인 지점에서 고칠 수 있다.
“OBS 1080p가 되는 PC”는 하나의 고정 사양으로 정의할 수 없다. Camera 한 대와 단순 자막을 1080p30으로 보내는 구성, 여러 Camera와 Browser Source를 합성하며 1080p60으로 방송·녹화하는 구성은 같은 해상도여도 부하가 다르다.
PC를 고를 때는 CPU·GPU 이름보다 먼저 Scene 합성, Encoding, Recording, 입력 장치, 운영 시간을 적어야 한다. OBS 공식 System Requirements도 호환 가능한 OS와 GPU만으로 실제 Stream 또는 Recording 능력을 보장하지 않으며 Encoder, Resolution, FPS, Scene 복잡성에 따라 요구량이 달라진다고 설명한다.
1080p는 Workload의 한 항목일 뿐이다
1080p 안에서 달라지는 OBS Workload Profile
OBS는 각 Source를 Canvas에 그린 뒤 최종 Frame을 Encoder로 넘긴다. Camera 수, Scaling, Color 변환, Browser Source, Animated Graphic, Filter가 늘면 GPU 합성 부담이 커진다. Encoding은 같은 Frame을 압축하는 별도 작업이며, 동시에 고품질 Recording을 하면 Storage 쓰기와 추가 Encoder 부담이 생길 수 있다.
Workload Profile
Scene 구성
출력
추가 작업
주요 위험
단순 1080p30
Camera 1대, Logo, 고정 자막
Stream 1개
기본 MKV Recording
여유 없는 오래된 PC, USB 충돌
다중 Camera 1080p30
Capture 2~4개, 전환, Caption
Stream 1개
Program Recording
GPU 합성, USB bandwidth
움직임 많은 1080p60
Camera·Graphic·Transition
Stream 1개
Recording
Rendering·Encoding 부하 상승
Stream + 고품질 Recording
복합 Scene
서로 다른 품질 목표
Multiple Audio Track
Encoder session, Storage 지속 쓰기
Browser Source 중심
Web Caption, Animation, Remote feed
Stream 1개
Plugin·Network Source
Memory, GPU, Source 장애
따라서 “i5 이상” 같은 이름만으로는 판단이 부족하다. 동일한 CPU 계열도 세대와 Encoder 기능이 다르고, GPU가 있어도 사용하려는 Codec과 Resolution을 지원하는지 별도로 확인해야 한다.
CPU·GPU·Memory·Storage는 서로 다른 일을 맡는다
CPU·GPU·Memory·Storage가 맡는 서로 다른 처리
Component
OBS에서 맡는 일
부족할 때 보이는 증거
구매·설정 판단
CPU
Source 처리, Plugin, 일부 Encoding, OS 작업
전체 사용률, x264 overload
Hardware Encoder 사용 여부와 함께 판단
GPU
Scene 합성, Scaling, Color, Hardware Encoding
Rendering Lag, GPU overload
게임 성능보다 OBS 합성과 Encoder 지원 확인
Memory
OBS, Browser Source, OS, 보조 App 유지
Swap, Source reload, 전체 반응 저하
실제 동시 실행 App으로 측정
Storage
Recording 지속 쓰기, Media 읽기
녹화 중단, File 지연, 용량 부족
지속 쓰기 속도와 보존 용량 분리
I/O
Capture·Audio·Control 장치 연결
Device disconnect, Frame 불안정
USB Controller와 Port 배치 확인
Network
YouTube로 지속 Upload
Dropped Frames
PC 성능과 별도의 경로로 진단
OBS의 Rendering Lag가 증가하면 GPU 합성이나 Scene 복잡성을 먼저 보고, Encoding Lag는 Encoder 부하를 본다. Dropped Frames는 Network 경로다. 세 값을 모두 “PC가 느리다”로 묶으면 불필요한 부품을 교체할 수 있다.
Hardware Encoder는 CPU를 비우지만 무한한 여유는 아니다
Rendering·Encoding·Dropped Frames로 읽는 병목
NVIDIA NVENC와 Intel Quick Sync 같은 Hardware Encoder는 전용 Video Encoding 기능으로 CPU 기반 x264의 부담을 줄일 수 있다. 그러나 지원 Codec, 동시 session, 해상도, 품질 기능은 GPU·iGPU 세대와 Driver에 따라 다르다. 공식 지원 Matrix와 현재 Driver를 확인한다.
Hardware Encoder를 선택해도 Scene 합성은 GPU 자원을 사용한다. Game, Presentation, Browser Animation이 GPU를 가득 채우면 OBS가 Frame을 제때 그릴 여유가 줄 수 있다. OBS는 GPU Overload 문제에서 Frame Rate, Output Resolution, Scene 복잡성과 다른 GPU 사용량을 함께 줄여 보라고 안내한다.
Capture와 USB 구조가 숨은 사양이 된다
Camera가 여러 대라면 CPU와 GPU가 충분해도 USB Controller bandwidth와 전원 문제가 발생할 수 있다. 외형상 다른 Port가 내부에서는 같은 Controller를 공유할 수 있다. Capture 장치를 연결한 상태에서 Resolution/FPS를 확인하고, Port를 옮겼을 때 장치가 사라지거나 Frame이 흔들리는지 시험한다.
여러 HDMI 입력을 Hardware Switcher에서 하나의 Program feed로 만들어 PC에 넣으면 USB 입력과 Scene 합성 부담을 줄일 수 있지만, 현장 전환이 Program에 바로 반영되고 개별 Camera를 OBS에서 다시 자르기 어렵다는 trade-off가 있다.
Memory와 Storage는 최대치보다 운영 Pattern으로 계산한다
Browser Source, Presentation, Remote control, Web dashboard를 함께 실행하면 Memory 사용량이 늘어난다. 부팅 직후 수치가 아니라 예배 후반의 사용량과 Swap을 관찰한다. 여유가 적어 Source가 reload되거나 OS가 느려지면 용량뿐 아니라 불필요한 App과 Browser Source를 정리한다.
Recording 용량은 bitrate × 시간으로 추정할 수 있다. 예를 들어 20Mbps Video는 Audio와 Container overhead를 제외해도 시간당 약 9GB에 가까운 Data를 만든다. 실제 Encoder 설정으로 60~90분 Sample을 만들어 File 크기와 지속 쓰기를 측정하고, 보존 기간과 backup까지 계산한다.
같은 Scene Collection으로 후보 PC를 비교한다
실제 Scene Collection을 이용한 60~90분 Benchmark
Benchmark 구간
실행 조건
기록할 값
PASS 판단
10분 Baseline
Camera 1, Audio 1, 고정 Scene
Render·Encode·Dropped Frame
증가 없이 안정
30분 실제 Scene
모든 Camera, Caption, Graphic
GPU/CPU, Memory, 온도
지속적인 Lag 없음
60~90분 Stream+Record
실제 bitrate와 MKV
Stats, File, Audio Sync
중단·Drift·손상 없음
Scene 전환 Peak
가장 복잡한 두 Scene 반복
Frame Time, Rendering Lag
전환 후 안정 회복
재부팅 복구
PC·Capture 전원 재투입
장치 인식과 복구 시간
동일 Source가 다시 연결
OBS Log File에는 실행 환경과 Encoder, Source, overload 관련 정보가 담긴다. Password나 Stream Key가 포함되지 않도록 확인한 뒤 Log Analyzer와 운영 기록을 함께 사용한다. 후보 PC는 Demo 영상이 아니라 교회의 실제 Scene Collection과 Capture 장치로 비교해야 한다.
구매 우선순위는 측정된 병목에서 나온다
Rendering Lag가 없고 Hardware Encoding도 안정적이라면 더 높은 GPU 등급이 방송 결과를 바꾸지 않을 수 있다. 반대로 여러 Browser Source와 Scaling에서 Rendering Lag가 반복되면 GPU 여유와 Scene 단순화가 중요하다. Recording File 쓰기에서만 문제가 생기면 Storage와 Recording 설정이 우선이다.
PC 비용에는 Capture 확장, Monitor, UPS, Storage, OS와 Driver 유지, Spare, 교육과 복구 시간도 포함한다. 한 대의 고성능 PC에 모든 입력과 Recording을 집중하면 단순하지만 단일 장애점도 커진다. 교회 규모에 따라 Hardware Switcher나 별도 Recording으로 역할을 나누는 편이 더 안정적일 수 있다.
좋은 방송용 PC는 사양표에서 가장 높은 제품이 아니라, 실제 Scene을 예배 시간만큼 실행해 Rendering·Encoding·Network·Recording의 병목이 분리되고, 다른 담당자도 같은 설정을 복구할 수 있는 PC다.
OBS 예배방송 설정은 인터넷에서 찾은 bitrate와 preset을 그대로 복사하는 일이 아니다. 안정적인 baseline은 Camera와 Mixer가 실제로 보내는 신호, OBS가 장면을 만드는 방식, Encoder가 처리할 수 있는 부하, 교회 Network가 지속할 수 있는 전송량을 맞추는 데서 시작한다.
이 글은 단일 “최적값” 대신 입력부터 YouTube 시청 화면과 로컬 녹화까지의 관계를 설명한다. 설정을 바꿀 때 어느 구간이 달라졌는지 알 수 있어야 문제를 재현하고 복구할 수 있다.
먼저 OBS 안팎의 신호 경로를 구분한다
Camera·Mixer에서 YouTube까지 이어지는 OBS 신호 경로
영상은 Camera → HDMI/USB → Capture Device → OBS Video Source로 들어온다. 음향은 Microphone → Mixer → USB/Audio Interface → OBS Audio Source로 들어온다. OBS는 Scene에서 두 신호와 자막을 합성하고 Encoder가 압축한 뒤 YouTube로 전송한다. Recording은 같은 Program을 로컬 File로 남기는 별도 출력이다.
설정 Layer
바꾸는 대상
관찰할 곳
잘못 맞을 때의 현상
Input Source
Camera·Audio 장치의 실제 mode
Source Properties, Audio Meter
검은 화면, 무음, 한쪽 소리
Scene·Canvas
Source 배치와 제작 공간
Preview, Rendering Lag
잘린 화면, 비율 오류, 합성 지연
Output Video
시청자에게 보낼 frame
Output Resolution, recording
과도한 scaling, 흐린 자막
Encoding
Video/Audio 압축
Encoding Lag, bitrate
Frame 누락, 화질 붕괴
Network
Platform까지 전송
Dropped Frames, Stream Health
끊김, 재연결
Recording
로컬 보존 File
녹화본 재생
손상 File, audio track 누락
OBS Auto-Configuration Wizard는 PC와 Network에 맞는 출발점을 제안한다. 이후 교회가 실제 사용하는 Camera, Scene, 자막, 찬양 음량으로 검증해야 한다.
Camera 입력은 장치가 실제 지원하는 mode로 맞춘다
Base Canvas와 Output Resolution의 서로 다른 역할
Video Capture Device Source에서 Device를 선택한 뒤 화면이 나오면, Resolution/FPS Type을 무조건 Custom으로 바꾸기 전에 Device Default를 확인한다. OBS 공식 문서는 장치가 지원하지 않는 Resolution과 FPS를 지정하면 출력이 실패할 수 있다고 설명한다.
Camera 메뉴와 battery icon, focus frame이 남으면 Camera 쪽 Clean Output 설정을 확인한다. 색이나 밝기가 OBS에서만 달라지면 Video Format, Color Space/Range와 Capture Driver를 원인 후보로 분리한다. 한 번에 여러 값을 바꾸지 말고 Preview와 짧은 Recording을 비교한다.
Canvas와 Output은 같은 숫자가 아니라 서로 다른 역할이다
Rendering·Encoding·Dropped Frames의 원인 구분
Base Canvas는 Scene을 설계하는 좌표 공간이고, Output Resolution은 Encoder로 전달할 최종 크기다. 4K Camera가 있다고 Canvas와 Output을 모두 4K로 둘 필요는 없다. 모든 Camera·Graphic·Caption을 1080p 기준으로 만들고 1080p로 전송한다면 불필요한 scaling과 GPU 부하를 줄일 수 있다.
목표
Base Canvas
Output
FPS 판단
설명
안정적 기본 방송
제작 자산 기준
Platform 목표 기준
30fps부터 검증
설교·고정 장면 중심
움직임 많은 찬양
제작 자산 기준
회선·Encoder가 감당하는 값
60fps 이점과 부하 비교
Camera와 Capture도 같은 FPS 필요
낮은 성능/회선
장면 비율 유지
낮은 Resolution 검토
30fps
Frame 지속성을 해상도보다 우선
YouTube는 H.264 live encoding에서 Resolution/FPS별 권장 bitrate, CBR과 2초 Keyframe을 안내한다. 이 값은 출발점이며, 실제 회선과 Encoder에서 안정적으로 유지되는지 시험해야 한다.
Audio는 한 번만 Capture하고 Meter를 신호 지도처럼 읽는다
같은 Audio Device를 Settings → Audio의 Global Device와 Scene의 Audio Input Capture에 동시에 넣으면 중복이나 Echo가 생길 수 있다. 운영 구조를 하나로 정한다. Scene별 제어가 필요하면 Global Input을 Disable하고 Source로 명시하는 편이 추적하기 쉽다.
Mixer의 방송용 출력, Audio Interface input, 운영체제 Device, OBS Source 순서로 신호를 확인한다. Meter가 움직이지 않으면 앞단으로 돌아가고, 빨간 영역에 계속 닿으면 Filter보다 앞단 Gain과 Bus Level을 먼저 조정한다. 한쪽만 들리면 Cable과 Channel을 확인한 뒤 Mono Source인 경우 Downmix to Mono를 적용한다.
Monitoring은 담당자가 듣기 위한 경로이고 Stream Output과 다를 수 있다. Headphone에서 들린다는 사실만으로 YouTube에 들어갔다고 결론내리지 말고, OBS Recording과 실제 Watch Page를 재생한다.
Encoding과 Network 문제는 Stats에서 분리한다
Local Recording과 Watch Page를 함께 보는 검증 구조
증가하는 값·현상
우선 조사할 구간
첫 조정
Rendering Lag
Scene 합성, GPU, Canvas
Browser Source·Filter·Scene 복잡도 축소
Encoding Lag
Encoder 부하
Hardware Encoder, Output/FPS, preset 검토
Dropped Frames
PC 이후 Network
Ethernet, bitrate, router, ingest 비교
YouTube만 전체 지연
Platform processing과 player
Stream Health와 다른 기기 재생 비교
Local recording도 sync 오류
Capture·Audio clock·OBS
입력별 delay와 장시간 drift 측정
Dropped Frames가 늘 때 GPU를 바꾸고, Encoding Lag가 늘 때 회선만 증설하는 것은 원인과 해결이 어긋난다. OBS Stats와 YouTube Stream Health를 같은 시간축에 기록하면 어디서 문제가 시작됐는지 좁힐 수 있다.
Stream Key는 비밀번호처럼 취급한다. Screenshot, 교육 영상, Log, 승인 Package와 공개 Visual에 포함하지 않는다. YouTube 연결은 공식 Live Control Room에서 새 Stream 또는 예약 Event의 정확한 Key와 ingest를 확인한다.
Recording은 방송 확인과 복구를 위한 두 번째 증거다
OBS는 비정상 종료 시 전체 File 손상 위험을 줄이기 위해 MKV 같은 안전한 Recording Container를 권장하며, 필요하면 File → Remux Recordings에서 MP4로 변환할 수 있다. 편집용 Multiple Audio Track을 사용하더라도 Stream Track에는 시청자가 들어야 할 Source가 모두 포함돼야 한다.
로컬 Recording이 정상인데 YouTube가 끊기면 Network 이후를 우선 조사한다. Recording부터 Frame이 빠지거나 Audio가 어긋나면 Capture, Scene, Encoder, Audio Clock을 먼저 본다. 이 차이가 로컬 녹화를 단순 backup 이상으로 만든다.
첫 방송은 기능보다 Baseline을 고정한다
한 Camera, 한 Audio Source, 한 Scene으로 Local Recording을 만든다. 다음으로 YouTube 제한 공개 Stream을 열어 Watch Page에서 영상, 좌우 Audio, Sync를 확인한다. 이후 Caption, 두 번째 Camera, Filter, 복잡한 Transition을 하나씩 추가한다.
시험은 실제 예배와 비슷한 길이와 움직임, 찬양 음량으로 진행한다. 시작·20분·40분 지점에서 OBS Stats, Stream Health, Audio/Video Sync를 남기고, OBS와 Camera를 다시 시작한 뒤 같은 Scene이 복구되는지 확인한다.
좋은 OBS 설정은 많은 숫자를 외운 구성보다 입력 mode, 합성, 압축, Network, Recording의 관계가 분명한 구성이다. 이 관계를 고정하면 PC나 Camera가 달라져도 새 환경에 맞는 baseline을 다시 만들 수 있다.
이 섹션은 FaithAX의 직접 현장 경험을 주장하지 않습니다. 공개된 OBS 사용자 사례 5건에서 반복된 실패 지점을 분류하고, OBS 공식 문서 2건과 대조해 예배 순서에서 복구까지 이어지는 운영 모델로 재구성했습니다.
FaithAX Worship Broadcast Workflow Model
단계
운영 질문
확인 신호
실패 시 다음 행동
예배 순서
지금 어떤 순서인가?
큐시트의 현재 행
다음 순서와 비상 순서를 함께 표시
OBS Scene
순서에 맞는 장면인가?
선택된 Scene 이름
복구 Scene으로 전환
Source
필요 영상·음향이 모두 있는가?
Source 표시·OBS meter
전역 Source와 Scene Source를 분리 확인
Preview
전환 전 구성이 안전한가?
Preview 영상·meter
문제 Source를 숨기고 재확인
Transition
전환 시점과 방식이 맞는가?
Preview/Program 차이
Cut으로 단순화하거나 복구 Scene 사용
Program
송출 출력이 의도와 같은가?
Program 화면·Track 1
마지막 정상 Scene으로 복귀
Monitoring
운영자와 시청자가 같은 신호를 듣는가?
Monitor·로컬 녹화·비공개 재생
Monitor Only/Output routing 비교
Recovery
30초 안에 안전한 화면·음향으로 돌아갈 수 있는가?
복구 Scene·복구 담당
원인 추적보다 먼저 송출 안정화
OBS Worship Workflow Sheet
예배 전에 한 행씩 작성하고, 리허설에서는 한 번에 한 변수만 바꿉니다. 실제 운영 시 이 표를 인쇄하거나 복사해 사용할 수 있습니다.
예배 순서
장면명
필요 Source
운영자 확인
전환 시점
복구 장면
오프닝
찬양
설교
광고/헌금
비상
RECOVERY
안전 이미지·기본 음향
즉시
RECOVERY
사례에서 반복된 패턴
장면 전환 때 Scene-local Source와 전역 Source가 섞여 누락·중복이 발생
OBS meter에는 신호가 있지만 Monitor Only 또는 Track routing 때문에 송출·녹화가 무음
예배 직전 Source·filter 변경 뒤 전체 경로를 다시 확인하지 않아 장애가 확대
문제 발생 시 돌아갈 복구 Scene이 없어 원인 조사 중 잘못된 화면이 계속 노출
이 자료를 만든 방법
공식 커뮤니티 사례 5건을 장면·Source·오디오 routing·동기화·복구 관점으로 분류했습니다. 사례의 해결 결과가 명확하지 않은 경우에는 가능한 원인으로만 표시했고, 제품 동작과 OBS 기능은 공식 문서를 우선했습니다. 공개 사례는 통제 실험이 아니므로 모든 교회 환경에 동일하게 적용되지 않습니다.
Source
Type
Verification
Limitation
No sound while live streaming
OFFICIAL_COMMUNITY_FORUM
PLAUSIBLE_PUBLIC_EXPERIENCE
게시자가 최종 해결 결과를 회신하지 않아 원인 확정 불가
Lost audio in live stream when changing scenes
OFFICIAL_COMMUNITY_FORUM
PLAUSIBLE_PUBLIC_EXPERIENCE
특정 OBS 버전·구성 사례이며 전체 환경에 일반화 불가
Audio Issues During Church Live Streams
OFFICIAL_COMMUNITY_FORUM
PLAUSIBLE_PUBLIC_EXPERIENCE
정확한 필터 설정과 후속 측정값은 공개되지 않음
A small church needs help: dropped frames and sync
예배방송 카메라는 화소 수가 가장 높은 제품을 고르는 문제가 아니다. 같은 카메라도 강단까지의 거리, 필요한 장면, 조명, 배선, 운영 인원에 따라 적합성이 달라진다. 미러리스는 lens 선택과 화질 표현에 강점이 있고, camcorder는 긴 촬영과 zoom 운용이 단순하며, PTZ는 원격 제어와 preset을 제공하지만 제어·network·설치 부담을 함께 가져온다.
이 글은 특정 모델의 승자를 정하지 않는다. 설치 위치에서 필요한 그림을 만들고, OBS까지 안정적으로 전달하며, 매주 반복 운영할 수 있는 유형을 고르는 비교 기준을 제공한다.
첫 기준은 Sensor가 아니라 거리와 화각이다
설치 거리와 화각에서 시작하는 Camera 선택
Camera 설치점에서 강단까지의 거리를 재고, 같은 위치에서 필요한 두 장면을 정한다. 보통 강단 전체와 설교자 상반신처럼 넓은 장면과 좁은 장면이 모두 필요하다. Lens의 초점거리 숫자는 Sensor 크기와 함께 봐야 하며, “몇 배 zoom”만으로 실제 화각을 알 수 없다.
조명도 함께 기록한다. 어두운 공간에서 gain을 지나치게 올리면 noise가 늘고, 밝은 창과 어두운 얼굴이 함께 있으면 자동 노출이 흔들릴 수 있다. 먼저 조명과 설치 위치를 조정한 뒤 Camera 성능을 비교해야 한다.
세 유형의 차이는 화질보다 운용 구조에서 커진다
미러리스·Camcorder·PTZ의 운용 구조 비교
비교 축
미러리스
캠코더
PTZ
Lens·화각
교환 Lens로 선택 폭이 큼
일체형 광학 Zoom이 편리
고정 Lens와 광학 Zoom 범위 확인
장시간 운용
연속 전원·발열·자동 종료 확인
긴 영상 운용에 맞춘 조작계
상시 설치와 원격 운용에 유리
조작 인력
Camera 옆 조작 또는 별도 제어 필요
물리 Zoom과 기록 조작이 단순
원격 Pan·Tilt·Zoom과 preset
출력
모델별 HDMI 규격 확인
HDMI, 일부 모델 SDI·UVC
HDMI·SDI·IP 조합이 다양
설치 부담
삼각대·전원·짧은 HDMI에 적합
삼각대와 긴 운용에 익숙
천장·벽 고정, 제어·Network 설계
대표 위험
발열, 작은 HDMI, Lens 비용
Sensor·저조도·출력 차이
제어 복잡성, 지연, 단일 담당자 의존
미러리스는 사진과 영상 겸용, Lens 선택, 얕은 심도에 유리할 수 있다. 그러나 예배방송에서는 연속 전원, 화면 정보가 사라지는 clean HDMI, 자동 절전, 발열, HDMI 단자 고정이 더 직접적인 운영 조건이다.
Camcorder는 일체형 Zoom과 영상용 조작계로 긴 예배를 다루기 편하다. 다만 같은 제품군에서도 SDI가 있는 모델과 없는 모델이 다르고, USB UVC와 HDMI가 제공하는 해상도·Frame Rate가 같다고 가정할 수 없다.
PTZ는 한 사람이 여러 구도를 반복 호출하고 Camera 근처에 서기 어려운 환경에 적합하다. 대신 Controller, Network, 전원, mounting, preset 관리, 비상 수동 운용까지 하나의 System으로 봐야 한다.
출력은 Camera에서 OBS까지 하나의 조합이다
HDMI·SDI·IP가 OBS까지 이어지는 출력 경로
Camera가 4K를 촬영해도 실제 출력이 1080p이거나, Capture 장치가 선택한 Frame Rate를 받지 못하면 OBS 화면이 나오지 않을 수 있다. OBS 공식 문서도 Video Capture Device에서 장치가 지원하지 않는 해상도와 FPS를 지정할 경우 출력이 실패할 수 있다고 설명한다.
출력 경로
장점
확인할 제한
어울리는 환경
HDMI → USB Capture
구성 단순, 일반 PC에 연결
단자 크기, cable 거리, clean output
Camera 한두 대, 가까운 방송석
HDMI → Switcher → USB
여러 입력을 하나의 Program으로 전달
입력 규격 통일, 전환 담당, sync
Camera 2~4대의 현장 전환
SDI → Capture/Switcher
잠금식 connector와 설치 배선에 유리
Camera·Converter·Capture 전체 비용
먼 거리, 상시 배선
IP Video
영상과 제어를 Network로 통합 가능
지연, bandwidth, protocol, 분리 설계
다수 PTZ와 원격 제어
USB UVC 직결
별도 Capture가 필요 없을 수 있음
USB 거리, 제공 mode, driver
Camera와 PC가 가까운 단순 구성
Clean output은 메뉴, battery icon, focus frame이 없는 영상 출력을 뜻한다. 제조사와 Capture 업체의 호환 안내에서 실제 모델과 출력 mode를 확인하고, 현장에서는 20분 미리보기보다 예배 길이만큼 시험한다.
공식 사양 예시는 읽는 방법을 보여줄 뿐 정답이 아니다
Sony ZV-E10 II 공식 사양은 APS-C E-mount, micro HDMI와 구체적인 HDMI 출력 mode, USB 전원 공급을 명시한다. 이 예시는 미러리스에서 Lens, 작은 connector, 전원, 출력 mode를 함께 읽어야 한다는 뜻이다.
Canon XA60 공식 페이지는 20배 optical zoom, HDMI mini, USB-C UVC와 전원 관련 사양을 제시한다. 같은 XA 계열이라는 이름만 보고 SDI를 가정하지 말고 정확한 모델의 단자를 확인해야 한다.
Sony SRG-X120 공식 자료는 12배 optical zoom과 3G-SDI·HDMI·IP interface를 명시한다. PTZ 비교에서는 화질뿐 아니라 제어 protocol, PoE 여부, preset 반복 정확도, 설치점에서의 실제 zoom을 함께 본다.
구매 전 시험은 한 시간짜리 현장 비교다
같은 위치에서 수행하는 60~90분 현장 비교
후보를 실제 설치점에 놓고 강단 전체, 설교자 상반신, 찬양팀 장면을 만든다. Camera output을 계획한 Cable·Capture·Switcher에 연결하고 OBS에서 목표 Resolution/FPS로 확인한다. 화면 정보가 숨겨지는지, Audio Sync가 유지되는지, 전원과 발열이 안정적인지 본다.
시험 항목
기록할 증거
실패하면 돌아갈 결정
실제 화각·Zoom
같은 위치의 Wide/Close Frame
Lens, 설치 위치, Camera 유형
Clean output
OBS Screenshot
Camera 설정 또는 모델
출력 호환
Resolution/FPS와 Capture mode
출력·Capture 조합
장시간 안정성
60~90분 온도·중단 기록
전원, 냉각, 운용 방식
운영 난이도
다른 담당자의 장면 전환 시간
preset, controller, 입력 수
전원 재투입
재부팅 후 영상 복구 시간
자동 설정, 비상 Scene
제품 설명서의 “지원”은 교회 전체 경로의 호환을 보장하지 않는다. Camera, Cable, Converter, Switcher, Capture, OBS가 공통으로 지원하는 mode가 실제 mode다.
예배방송 Camera 선택은 미러리스·Camcorder·PTZ의 추상적 우열이 아니라, 실제 거리에서 필요한 장면을 만들고, 계획한 출력 경로로 예배 내내 전달하며, 현재 운영자가 반복할 수 있는지를 비교하는 일이다.
소형 교회 방송 시스템의 품질은 가장 비싼 카메라 한 대가 아니라 말과 영상이 온라인 시청자에게 도착할 때까지 끊기지 않는 전달 사슬에서 결정된다. 카메라가 좋은데 음성이 작거나, 믹서는 충분한데 PC가 장면을 제때 그리지 못하거나, 모든 장비가 정상인데 업로드 경로가 흔들리면 결과는 좋지 않다.
따라서 장비 목록보다 먼저 `음원·피사체 → 입력 → 변환 → OBS → 인코딩 → 네트워크 → 플랫폼 → 시청자`를 그려야 한다. 이 글은 특정 구매 목록이나 변동 가격을 제시하지 않고, 현재 장비와 운영 인력으로 어디부터 보강할지 설명한다.
예배방송은 여섯 구간의 전달 시스템이다
예배방송의 여섯 구간을 잇는 전체 전달 경로
카메라와 마이크는 시작점일 뿐이다. 영상은 카메라 출력과 캡처 장치를 통과하고, 음향은 믹서의 방송용 bus와 USB 또는 audio interface를 거친다. 두 신호는 OBS에서 합쳐지고 encoder와 network를 거쳐 YouTube에 도착한다.
전달 구간
맡는 역할
대표적인 실패 현상
먼저 확인할 관찰값
현장 입력
설교자·찬양·카메라 장면을 취득
작은 말소리, 흔들림, 어두운 화면
마이크 거리, 조명, 실제 화각
신호 전달
HDMI·SDI·USB·audio line으로 이동
검은 화면, 잡음, 한쪽 소리
출력 규격, cable, channel
장면 합성
OBS가 Source와 자막을 한 frame으로 구성
화면 지연, 장면 끊김
Rendering Lag, canvas와 output
인코딩
합성 frame과 audio를 압축
Encoding Lag, 화질 붕괴
encoder 부하, bitrate, preset
Network
지속적으로 platform에 전송
Dropped Frames, 재연결
유선 여부, upload 여유, ingest
Platform·시청
YouTube가 처리해 기기에 전달
전체 지연, 재생 품질 변화
Stream Health, watch page, 녹화본
문제는 뒤에서 보이지만 원인은 앞에 있을 수 있다. YouTube 화면이 흐리다고 카메라부터 바꾸기 전에 OBS 출력 해상도, encoder 상태, bitrate와 platform 변환을 분리해 봐야 하는 이유다.
먼저 음성을 안정시키고 영상은 실제 거리에서 정한다
Camera·Switcher·PTZ/IP 구조와 운영 부담 비교
예배방송에서 설교 내용을 이해하지 못하면 높은 해상도는 가치를 회복하지 못한다. 마이크는 원하는 음원에 가깝게 두고, loudspeaker의 직접 경로에서 벗어나게 배치하며, mixer 입력부터 방송 bus까지 clipping 없이 신호를 만든다. 회중용 main mix는 공간의 실제 소리를 전제로 하므로 온라인 방송에는 말소리와 음악의 균형이 다르게 필요할 수 있다.
카메라는 sensor나 해상도만으로 고르지 않는다. 설치 위치에서 강단 전체와 설교자 상반신이 모두 가능한지, clean output을 제공하는지, 예배 시간 동안 전원과 발열이 안정적인지, 실제 출력 resolution/FPS가 capture 장치와 맞는지 확인한다.
구조
적합한 운영
장점
함께 생기는 부담
Camera 1대 + USB capture
고정 장면, 담당자 1명
단순한 신호와 빠른 복구
구도 변화가 적고 backup이 필요
Camera 2~4대 + HDMI switcher
찬양·설교 장면 전환
PC의 capture 입력을 단순화
cable, 전환 담당, audio sync 관리
PTZ·SDI·IP 기반
긴 거리, 반복 preset, 원격 운영
먼 설치와 구도 반복에 유리
network·제어·설치·비상 운용 복잡성
다중 camera가 항상 더 낫지는 않다. 한 명이 자막, 음향, 장면 전환, Stream Health를 동시에 맡는다면 입력 수보다 조작 부담이 먼저 병목이 된다.
OBS는 장비를 고쳐 주는 곳이 아니라 상태를 모아 보여주는 곳이다
OBS 통계로 Rendering·Encoding·Network 병목을 구분하는 지도
OBS의 Auto-Configuration Wizard는 출발점이며, 실제 Source가 지원하는 resolution과 frame rate를 선택해야 한다. Base Canvas는 장면 제작 공간이고 Output Resolution은 실제 송출 frame이다. 둘의 차이, scene 수, browser source, filter가 늘면 rendering 부하가 달라진다.
OBS Stats에서 Rendering Lag, Encoding Lag, Dropped Frames는 같은 문제가 아니다. Rendering Lag는 장면 합성/GPU 쪽, Encoding Lag는 압축 처리 쪽, Dropped Frames는 송출 network 경로를 우선 조사하게 한다. 숫자를 하나의 “컴퓨터가 느림”으로 묶으면 장비 교체 방향이 틀어진다.
Audio도 같은 장치를 Settings의 global input과 Scene의 Audio Input Capture에 동시에 넣으면 echo 또는 중복이 생길 수 있다. 한쪽 channel만 들어오면 원래 source가 mono인지 확인한 뒤 필요한 경우 Downmix to Mono를 사용한다. Filter는 잘못된 routing과 gain을 숨기는 대체물이 아니다.
Network는 최고 속도보다 지속 가능한 여유가 중요하다
YouTube는 encoder 설정에서 CBR, 2초 keyframe과 해상도별 권장 bitrate를 안내한다. 이 수치는 회선 보장이 아니라 platform 입력 기준이다. 송출 bitrate가 순간 측정 upload 속도보다 낮다는 사실만으로 안정성을 보장할 수 없다.
송출 PC는 가능하면 Ethernet으로 연결하고, 예배 시간대에 다른 기기가 사용하는 traffic을 포함해 시험한다. YouTube Stream Health와 OBS Dropped Frames를 같은 시간축에 기록하면 교회 내부 network 문제와 platform 또는 경로 문제를 구분하기 쉬워진다.
예산은 제품군이 아니라 가장 약한 구간에 배분한다
기존 camera가 clean output과 연속 전원을 제공한다면 audio와 network를 먼저 보강하는 편이 결과를 더 크게 바꿀 수 있다. 반대로 음향과 network가 안정적이지만 camera가 예배당 거리에서 필요한 화각을 만들지 못하면 lens·camera·설치 위치가 우선이다.
판단 질문
값이 낮을 때 먼저 투자할 곳
구매 밖의 비용
온라인에서 말을 또렷하게 이해할 수 있는가
microphone 배치, 방송 bus, monitoring
mix 교육, rehearsal 시간
장면이 예배 내내 안정적으로 들어오는가
전원, cable, capture, camera output
고정 장치, spare, 복구 절차
OBS가 frame을 제때 처리하는가
scene 단순화, hardware encoder, PC
template 관리, software 유지
송출이 지속되는가
Ethernet, router, 회선, backup 경로
network 관리, 장애 대응
다른 봉사자가 같은 결과를 만들 수 있는가
control 단순화, labeling, monitor
문서화와 훈련
총소유비용에는 본체 가격 외에 lens, cable, 전원, mounting, monitor, storage, software, 설치, 교육, 예비 장비와 매주 드는 운영 시간이 포함된다. 현재 판매가를 고정 예산표로 제시하기보다 후보의 공식 사양과 현장 시험 결과를 같은 표에 기록하는 편이 오래 유효하다.
확장은 한 구간씩, 리허설은 전체 경로로 한다
한 구간씩 확장하고 전체 경로로 검증하는 순서
첫 단계는 한 camera, 한 방송용 audio path, 한 scene으로 로컬 녹화와 비공개 Stream을 완주하는 것이다. 그다음 자막, 두 번째 camera, switcher, 독립 mix를 한 번에 하나씩 추가한다. 변경 전후의 OBS Stats, YouTube Stream Health, 로컬 recording과 watch page를 비교하면 어떤 추가가 실제 품질을 높였는지 알 수 있다.
리허설은 정지 화면 5분이 아니라 실제 예배와 비슷한 길이, camera 움직임, 찬양 음량, 자막 전환으로 진행한다. 시작 직후와 20분·40분 지점의 영상·음성 sync, 온도, frame loss를 남기고 전원을 다시 켰을 때 복구되는지도 확인한다.
좋은 소형 교회 방송 시스템은 장비가 많은 시스템이 아니다. 각 신호가 어디서 시작해 어디서 합쳐지고, 어떤 관찰값으로 문제 구간을 찾으며, 담당자가 바뀌어도 복구할 수 있는지가 분명한 시스템이다.
