급하게 고객과 화면을 보며 이야기해야 할 때가 있습니다. 기존 회의 도구를 써도 되지만, 필요한 기능만 있는 작은 공간이 하나쯤 있으면 좋겠다는 생각이 들었습니다. 그래서 별도 설치 없이 링크로 들어오는 화상회의 도구를 만들었습니다.
필요한 것만 남기기
회의에 들어가기 전 카메라와 마이크를 확인하고, 초대받은 사람은 대기실을 거쳐 입장합니다. 회의 중에는 채팅과 화면 공유를 쓸 수 있고, 인원이나 대화 방식에 따라 화면 배치도 바꿀 수 있습니다.
페이지를 열기만 해서는 카메라나 마이크 권한을 요청하지 않습니다. 미리 확인하고 싶으면 장치 테스트 시작을 누르고, 테스트를 건너뛰었다면 입장을 누를 때 처음 권한을 요청합니다.
기능을 더 붙이는 것보다 회의를 여는 과정이 짧아야 한다는 쪽에 더 신경을 썼습니다. 방을 만들고 링크를 건네는 데 설명이 필요 없을 정도가 목표였습니다.
회의를 여는 순서
- 호스트가 이름을 입력하고, 필요하면 장치 테스트 시작과 스피커 테스트로 카메라·마이크·스피커 상태를 확인합니다.
- 회의방에 들어가 제목을 정한 뒤 초대 링크를 복사해 전달합니다.
- 초대받은 사람은 별도 계정 없이 링크를 열고 표시 이름만 입력합니다.
- 호스트가 대기실에서 입장을 승인하면 바로 영상과 음성이 연결됩니다.
회의가 시작된 뒤에는 갤러리·발표자·자유 배치 화면을 상황에 맞게 고를 수 있습니다. 호스트가 현재 배치를 모든 참가자에게 적용하거나, 특정 참가자를 중심 화면으로 지정하는 것도 가능합니다.
작은 회의에 필요한 운영 기능
- 대기실과 초대 링크 — 초대받지 않은 사람이 바로 들어오지 않도록 호스트가 참가자를 확인하고 승인합니다.
- 화면 공유와 채팅 — 문서나 제품 화면을 함께 보면서 필요한 주소와 내용을 채팅으로 남길 수 있습니다.
- 저대역폭 모드 — 연결이 느릴 때 영상 크기와 프레임을 낮춰 대화를 이어갑니다.
- 자막과 녹화 — 지원하는 브라우저에서는 음성 자막을 켜고, 내 카메라나 공유 화면을 WebM 파일로 저장할 수 있습니다.
- 후속 조치 메모 — 고객 요청, 약속한 일정과 담당자를 회의방별로 기록합니다.
브라우저끼리 연결하기
회의 참가와 대기실·채팅 같은 상태는 WebSocket으로 전달하고, 영상과 음성은 WebRTC로 참가자끼리 연결합니다. 현재 공개 서비스의 ICE 설정은 STUN만 제공하며 TURN 중계 서버는 구성하지 않았습니다. 그래서 일반 가정망에서는 연결되더라도, 직접 연결이 막힌 사내망·대칭 NAT·엄격한 방화벽 환경에서는 영상과 음성이 연결되지 않을 수 있습니다.
제한된 네트워크까지 안정적으로 지원하려면 짧게 만료되는 자격증명을 발급하는 TURN 서버와 TCP·TLS 중계 경로를 별도로 운영해야 합니다. 이 글은 그 구성을 완료한 프로덕션 회의 시스템이라고 주장하지 않습니다.
왜 소규모 전용인가 — 숫자로 보면 분명합니다
이 회의실은 중계 서버 없이 브라우저끼리 직접 연결합니다. 이런 구조를 메시(mesh) 라고 하는데, 참가자가 늘면 부담이 급격히 커집니다. 이유는 산수입니다.
내가 보내는 영상은 상대마다 따로 나갑니다. 서버가 한 번 받아서 나눠 주는 구조가 아니니까요. 참가자가 N명이면 나는 N−1명에게 각각 올려야 합니다.
720p 영상 한 줄기를 1.5Mbps로 잡고 계산하면 이렇게 됩니다.
| 참가자 | 전체 연결 수 | 내 업로드 | 내 다운로드 |
|---|---|---|---|
| 2명 | 1개 | 1.5Mbps | 1.5Mbps |
| 3명 | 3개 | 3.0Mbps | 3.0Mbps |
| 4명 | 6개 | 4.5Mbps | 4.5Mbps |
| 6명 | 15개 | 7.5Mbps | 7.5Mbps |
| 8명 | 28개 | 10.5Mbps | 10.5Mbps |
두 가지가 눈에 띕니다.
첫째, 연결 수는 제곱으로 늘어납니다. N명이면 N×(N−1)÷2개입니다. 4명이면 6개, 8명이면 28개입니다.
둘째, 병목은 업로드입니다. 가정용 인터넷은 대개 내려받기가 올려보내기보다 훨씬 빠릅니다. 다운로드 10Mbps는 여유롭지만 업로드 10Mbps는 빠듯한 회선이 많습니다. 그리고 한 명만 업로드가 부족해도 그 사람의 영상이 모두에게 끊깁니다.
여기에 영상 인코딩 부담도 더해집니다. 상대별로 화질을 맞추다 보면 노트북 팬이 도는 이유가 이것입니다.
사람이 많아지면 왜 서버를 두나
큰 화상회의 서비스가 중계 서버(SFU)를 쓰는 이유가 이 표에 다 있습니다. 서버가 있으면 내 영상은 한 번만 올리고, 서버가 나머지에게 나눠 줍니다. 8명이어도 내 업로드는 1.5Mbps로 고정입니다.
대신 서버 비용과 운영이 붙습니다. 이 도구는 그 반대편을 골랐습니다 — 서버를 두지 않는 대신 인원을 적게. 소규모 전용이라는 말은 취향이 아니라 구조에서 나온 결론입니다.
연결 자체가 실패할 수도 있습니다
또 하나 짚어야 할 것이 있습니다. 브라우저끼리 직접 연결하려면 서로의 실제 주소를 찾아야 하는데, 양쪽 다 공유기 뒤에 있으면 쉽지 않습니다.
- STUN — "인터넷에서 내 주소가 뭐로 보이니?"를 알려주는 서버입니다. 가벼워서 이 도구도 제공합니다. 두 서버의 역할은 RFC 8835에 정리돼 있습니다.
- TURN — 직접 연결이 끝내 안 되면 모든 영상을 대신 중계해 주는 서버입니다. 트래픽을 전부 떠안으므로 비용이 큽니다.
이 도구는 STUN만 제공하고 TURN은 두지 않았습니다. 그래서 회사 방화벽처럼 직접 연결이 막힌 환경에서는 연결 자체가 실패할 수 있습니다. 아래 "연결이 안 될 때"에서 다루는 상황 대부분이 여기 해당합니다.
그래서 이 도구가 맞는 자리
위의 두 계산을 합치면 이 도구의 자리가 분명해집니다. 서너 명이 급하게 화면을 함께 보는 상황입니다. 웨비나나 전사 회의에는 맞지 않습니다. 기능을 덜 넣은 게 아니라 감당할 범위를 좁게 잡은 것입니다.
인원이 많거나 연결이 자주 실패하는 환경이라면, 중계 서버를 운영하는 서비스를 쓰는 편이 맞습니다. 이 도구는 그 대안이 아니라 다른 크기의 문제를 푸는 도구입니다.
연결이 안 될 때 확인할 순서
영상이 보이지 않는다고 카메라 고장부터 의심할 필요는 없습니다. 연결은 다음 경계를 차례로 통과합니다.
- 브라우저에서 카메라·마이크 권한이 허용됐는지 확인합니다.
- 같은 기기에서 미리보기가 나오면 장치 읽기까지는 성공한 것입니다.
- 참가자 목록과 채팅이 되면 WebSocket 시그널링은 연결된 것입니다.
- 영상만 실패하면 ICE 후보 교환과 STUN 연결 기록을 확인합니다.
- 회사망에서만 실패한다면 현재 서비스에는 TURN이 없다는 점을 확인하고, TURN이 구성된 별도 환경이라면 TCP·TLS 중계 경로를 점검합니다.
이 순서로 보면 장치 권한, 회의 상태 전달, 실제 미디어 경로를 섞지 않고 확인할 수 있습니다. 저대역폭 모드는 이미 성립한 연결의 부담을 낮추는 기능이지, 막힌 방화벽을 통과시키는 기능은 아닙니다.
사용 범위에 대한 안내
이 도구는 사내와 고객 상담용으로 만든 개인 제작 도구입니다. 통화 내용은 참가자 브라우저 사이에서 암호화되어 오가지만, 규제 대상 정보나 법적 보존이 필요한 회의를 위해 설계·검증한 시스템은 아닙니다. 그런 용도에는 해당 요건을 명시적으로 지원하는 상용 서비스를 쓰는 것이 맞습니다.
초대 링크와 대기실은 편의를 위한 입장 절차이지 계정 기반 신원 확인이 아닙니다. 링크를 받은 사람은 입장을 요청할 수 있으므로 공개 채널에 링크를 올리지 말고, 호스트는 표시 이름만 믿지 말고 참가자를 별도로 확인해야 합니다. 브라우저가 연결 경로를 찾는 동안 현재 설정된 STUN 서버 운영자가 참가자의 IP 주소와 연결 메타데이터를 처리할 수 있습니다. TURN을 별도로 설정한 사용자는 해당 TURN 운영자의 처리 방침도 확인해야 합니다. 자세한 범위는 사이트의 개인정보처리방침에 적었습니다.