교회 방송 예산은 “카메라 몇 대를 살 수 있는가”보다 “어디에서 예배 전달이 끊기는가”에서 시작해야 한다. 시청자가 설교를 듣지 못하는 문제, HDMI 신호가 사라지는 문제, OBS가 frame을 제때 만들지 못하는 문제, upload가 막히는 문제는 체감은 비슷해도 해결 장비가 다르다.
OBS는 공식 최소 사양을 충족해도 안정적인 streaming이나 recording이 보장되지는 않는다고 밝힌다. CPU·GPU 요구량은 encoder, resolution, FPS, scene 복잡도에 따라 달라진다. 따라서 spec 표만 보고 PC를 사는 대신 실제 예배 scene으로 부하를 측정해야 한다.
예산의 단위는 제품이 아니라 전달 경로다
| 전달 구간 | 실패가 보이는 방식 | 먼저 측정할 것 | 구매 전에 시험할 것 |
|---|---|---|---|
| 말소리 → mixer | 작거나 울리고 불명료함 | mic 거리, gain, room reflection | mic 위치와 입력 gain |
| mixer → capture/PC | 무음, hum, 한쪽 channel | cable, connector, level, sample rate | 예비 cable과 local recording |
| camera → capture | 검은 화면, 끊김, 색 변화 | output format, cable 길이, capture 호환 | 목표 resolution/FPS 60분 |
| OBS render/encode | rendering·encoding lag | OBS Stats, GPU/CPU load | 실제 scene·caption·filter |
| encoder → YouTube | dropped frames, reconnect | upload headroom, route, stream health | 비공개 장시간 stream |
| 담당자 → 복구 | 장애가 오래 지속됨 | runbook, labeling, spare, 교대 가능성 | 다른 담당자의 복구 test |
새 camera가 마지막 네 구간의 문제를 해결하지 못하듯, 고성능 PC도 mic 거리나 불안정한 upload를 고치지 못한다.
시청 영향과 단일 장애 지점으로 먼저 순위를 매긴다
음성은 설교와 찬양의 의미를 직접 전달하므로 작은 화질 개선보다 앞설 때가 많다. Shure의 예배 공간 audio guide도 microphone과 loudspeaker의 선택·배치를 intelligibility 관점에서 다룬다. 말소리가 이미 충분하고 안정적이라면 그다음 실제로 자주 끊기는 구간을 찾는다.
단일 장애 지점은 하나가 고장 나면 전체 방송이 멈추는 요소다. 전용 power supply, 한 개뿐인 adapter, 긴 HDMI cable, 유일한 network path가 예다. 저렴한 예비 cable과 labeling이 새 lens보다 더 큰 중단을 막을 수도 있다.
| 우선순위 기준 | 질문 | 높은 우선순위의 예 |
|---|---|---|
| 시청 영향 | 실패하면 말씀을 이해할 수 있는가 | 반복되는 무음·심한 왜곡 |
| 발생 빈도 | 최근 예배에서 얼마나 자주 나타났는가 | 세 번 중 두 번 reconnect |
| 복구 시간 | 예배 중 몇 분을 잃는가 | 원인을 몰라 10분 이상 중단 |
| 단일 장애 | 대체 경로가 있는가 | 예비 없는 capture adapter |
| 운영 복잡도 | 한 사람만 다룰 수 있는가 | 설정이 문서화되지 않은 system |
PC 예산은 scene 부하와 encoder에서 결정한다
OBS는 rendering에 GPU 자원을 사용하며 scene과 source, filter가 복잡해질수록 부하가 늘어난다고 설명한다. 4K source를 작은 1080p frame에 표시하거나 많은 browser source를 유지하면 불필요한 자원을 쓸 수 있다. Hardware encoder는 CPU 부담을 전문 encoder block으로 옮길 수 있지만, 세대와 platform에 따라 품질·지원 범위가 다르다.
비교할 때는 후보 PC에서 같은 scene collection, 같은 source, 같은 caption, 같은 recording을 실행한다. OBS Stats의 missed frames due to rendering lag, skipped frames due to encoding lag, dropped frames를 서로 섞지 않는다. 각각 GPU composition, encoder, network 쪽의 다른 병목을 가리킨다.
Network 예산은 최고 속도보다 지속 가능한 upload 여유다
YouTube는 connection에 맞는 품질을 선택하고 실제 행사와 비슷한 audio와 movement로 사전 test하며, 행사 중 stream health를 보라고 안내한다. 권장 bitrate 표의 숫자를 그대로 설정하는 것보다, 예배 시간 전체에 upload가 안정적으로 유지되는지와 다른 사용자 traffic이 생겨도 여유가 있는지가 중요하다.
유선 Ethernet, 관리 가능한 router, 방송용 traffic 분리, backup connection의 필요성은 측정 결과로 판단한다. 속도 test 한 번은 장시간 안정성이나 packet loss를 증명하지 못한다.
구매 가격과 운영 비용을 분리한다
| 비용 종류 | 포함할 항목 | 놓치기 쉬운 비용 |
|---|---|---|
| 초기 구매 | 본체, lens, capture, cable, mount | adapter, storage, 배송·세금 |
| 도입 | 설치, 배선, scene 재구성 | 기존 장비 호환 확인 |
| 반복 운영 | license, cloud, battery, media | 주간 setup과 file 정리 시간 |
| 신뢰성 | spare, UPS, backup recording | 고장 시 예배 중단 시간 |
| 교육 | manual, labeling, rehearsal | 한 담당자 의존과 교체 비용 |
가격은 지역과 시점에 따라 변하므로 이 글은 확인되지 않은 금액을 제시하지 않는다. 견적에는 모델명, 연결 규격, 포함 accessories, warranty, 조사일을 함께 적는다.
세 단계로 예산을 배치한다
첫째는 복구 가능성이다. 말소리, 전원, cable, local recording처럼 방송 전체를 살리는 요소를 확보한다. 둘째는 반복 병목 제거다. OBS log와 stream health에서 확인된 문제에 예산을 쓴다. 셋째는 경험 확장이다. 추가 camera angle, 조명, motion graphic처럼 전달이 이미 안정된 뒤 체감 품질을 높이는 항목이다.
최종 결정은 후보 장비를 실제 예배와 같은 60~90분 동안 시험하고, 문제가 생겼을 때 다른 담당자도 복구할 수 있는지 확인한 뒤 내린다. 좋은 예산안은 비싼 장비 목록이 아니라 어느 실패를 얼마나 줄이는지 설명하는 운영 설계다.