1. 프로젝트 개요
웹 기반 관제솔루션에서 현장의 TTS·마이크·비상벨 시스템을 통합 제어하는 기능을 개발했다.
이 과정에서 방송장비, 네트워크 구조, Agent 프로그램의 동작 방식 등 예상보다 복잡한 요소들이 얽혀 있었고,
정확한 이해 없이 기능 구현만으로는 해결되지 않는 문제들이 많았다.
이 글은 시스템 구조를 해석하고 문제를 해결하며 학습한 기술적 경험을 정리한 것이다.
2. 방송 시스템 기본 구조 이해하기
TTS 방송과 마이크 방송은 동일한 Agent 프로그램을 통해 송출되지만, 구조적 제약 때문에 운영 방식이 크게 다르다.
3. 문제 상황과 해결 과정 (그림 포함)
문제 #1 — USB 마이크로 방송이 되지 않는 이유
가장 처음 진행한 테스트 환경은 다음과 같았다.
원격 데스크탑 기반 + USB 마이크 연결 테스트
초기 판단은
“원격 데스크탑 환경 때문에 오디오 처리가 안 되는 것 아닐까?”
였지만, 문제의 본질은 달랐다.
❌ 원인
- 방송 시스템은 TRS 아날로그 마이크 입력만 지원한다.
- USB 마이크처럼 자체 사운드카드를 가진 입력 장치는 Agent에서 인식되지 않음.
✔ 해결
TRS 마이크를 사용해 재테스트 → 입력 정상 인식.
문제 #2 — 앰프 소리를 방송 성공으로 오해한 사례
TRS 마이크 테스트 중 다음 흐름에서 소리가 출력되었다.
물리적 앰프 증폭음을 방송 성공으로 오해한 구조
(데스크탑과 마이크 단자가 호환되지 않아 데스크탑에 연결할 수 없었다)
❌ 문제 상황
- 방송 API 호출 또는 원격데스크탑으로 방송프로그램 실행
- 앰프 ↔ 단말 연결선을 끊음
- 마이크에 대고 말함
- 스피커에서 소리가 들림
→ 실제 방송 시스템을 통한 출력이 아닌, 앰프의 증폭 기능이었다.
✔ 배운 점
- 실제 방송 신호 흐름과
- 물리 장비 증폭으로 들리는 소리를 명확히 구분해야 한다.
문제 #3 — TRS 마이크 연결 후, 왜 스피커에서 소리가 안 나왔을까?
USB 마이크를 TRS로 교체한 뒤 구조는 아래와 같았다.
TRS 마이크 연결 후 테스트
그럼에도 불구하고 스피커에서는 여전히 아무 소리도 나지 않았다.
❌ 원인
- Agent PC(여기서는 방송서버)가 마이크와 스피커가 물리적으로 연결되어 있어야만 재생 가능 상태로 판단한다.
- “입출력 장치가 없는 Agent PC에서는 방송 자체가 실패”한다.
✔ 해결
- 방송을 수행할 Agent PC에는 반드시 마이크와 스피커가 연결되어야 한다는 점 확인.
문제 #4 — 비상벨과 마이크 방송의 연계 구조를 정확히 이해해야 했다
기존 이해에서는 단순히 "마이크 방송만 되면 된다"였지만,
실제 요구사항은 비상벨 호출 → 관제 팝업 → 관제 마이크 방송 송출 흐름이었다.
비상벨 호출 구조 파악
✔ 새롭게 파악된 필수 흐름
- 비상벨 단말이 호출 신호를 서버로 전달
- 관제 UI에 “비상호출 중” 팝업 표시
- 관제센터에서 마이크 방송하면
- 현장 단말 스피커에서 음성 송출
이는 마이크 테스트와는 별개의 흐름이며, 설계를 수정해야 했다.
문제 #5 — 최종적으로 올바른 마이크 방송 구조는 이것이었다
비상벨 흐름 포함, 정확한 마이크 방송 구조는 다음과 같다.
올바른 방송 흐름 (최종 구조)
✔ 핵심 정리
- 마이크 입력은 현장 Agent PC 또는 방송단말에 연결된 TRS 마이크가 수행(스피커에 연결하면 안됨!)
- 해당 Agent PC에 마이크와 스피커가 반드시 있어야 방송 성공(특히 Windows 11)
- 관제 솔루션의 방송 API는 Agent로 메시지를 전달하는 역할만 수행
- 실제 음원 출력은 Agent PC의 물리 장비를 통해 이루어짐
4. 방송 시스템의 최종 전체 구조 요약
🔹 TTS 방송
- 방송서버의 Agent에서 처리
- 동시에 한 건만 처리 가능
- 요청이 겹치면 큐에서 순차 처리
🔹 마이크 방송
- 각 현장의 Agent PC에 설치
- TRS 마이크 + 스피커 필수
- USB 마이크 사용 불가
- 원격 데스크탑 옵션은 화면 제어일 뿐, 실제 재생 장치는 Agent PC 측
🔹 비상벨 연동
- 비상벨 → 서버 → 관제 팝업
- 관제 마이크 방송 → 해당 현장 스피커로 송출
5. 이번 프로젝트에서 배운 점 (TIL)
✔ 1) 시스템 전체 그림 없이 문제를 해결할 수 없다
문제의 원인이 소프트웨어가 아닌
LAN, 단말, 앰프, 스피커, RDP, Agent 점유 구조 등
복합적인 요소에서 발생했다.
✔ 2) "된다"와 "왜 되는지 안다"는 완전히 다른 이야기
물리적 장비 때문에 발생하는 예외 상황을 직접 확인해야 정확한 판단이 가능했다.
✔ 3) Agent 프로그램의 특성(단일 작업 점유)은 설계 단계에서 반드시 고려해야 한다
이를 고려하지 않으면 TTS·마이크·비상벨이 충돌하여 장애 발생 가능성 존재.
✔ 4) 장비와 소프트웨어의 경계에서 발생하는 문제는 문서보다 직접 흐름을 그려보는 것이 가장 빠르다
이번 프로젝트에서 모든 혼란을 정리해준 것은
손으로 그린 신호 흐름도였다.
6. 마무리
이번 프로젝트는 단순한 기능 개발이 아니라
“방송 시스템과 웹 시스템이 어떻게 연결되는지 완전히 이해해가는 과정”이었다.
물리 장비·네트워크·Agent 프로그램·웹 UI…
각 요소를 분해하고 다시 맞추는 과정에서 배운 점이 많았고,
이 경험은 향후 IoT·실시간 시스템·현장 장비 연동 개발에서도 큰 자산이 될 것이다.
😉
