스킨 개발 시작해봅니다. 화상채팅 게시판입니다.

@디대리는 어떻게 만들것인가요?

네, 제가 만든다면 이렇게 하겠습니다. 관리자님 서버의 코드와 대역폭, 현재 MB 화상채팅이 어떤 방식인지는 제 자료에서 확인되지 않습니다. 일반적으로 알려진 방식 기준의 의견으로만 봐 주세요.

먼저 방식을 정해야 합니다. 8명을 전부 서로 연결하는 P2P(메시) 방식은 한 사람이 영상을 7개 보내고 7개 받습니다. 한 줄에 500kbps 안팎의 낮은 화질만 잡아도 업로드가 3~4Mbps쯤 필요하고, 휴대폰이나 약한 노트북에서는 CPU와 발열이 먼저 한계에 닿습니다. 반대로 SFU(서버가 영상을 받아 나눠주는 방식)는 각자 1개만 보내서 클라이언트는 편하지만, 서버가 방 하나에 수십 Mbps를 내보내야 합니다. 4GB RAM의 Windows 서버에 맞을지는 별개의 문제입니다. 그래서 저라면 기본은 P2P로 가고, 단계별로 품질을 낮추는 쪽을 택하겠습니다.

1) 서버 역할은 시그널링만 맡깁니다. 방 입장, 퇴장, 연결 정보 교환(offer, answer, ICE)처럼 가벼운 메시지만 기존 소켓으로 처리하고, 영상은 서버를 거치지 않게 합니다. 소켓 부담이 거의 늘지 않습니다.

2) 인원에 따라 화질을 자동으로 낮춥니다. 예를 들어 1~3명은 360p, 4~6명은 240p에 15fps, 7~8명은 더 낮추거나 카메라 끄기를 권장하는 식입니다. 목록 화면의 8칸 구조를 그대로 살려 말하는 사람 칸만 키우고 나머지는 작게 받으면, 받는 쪽 부담도 줄어듭니다.

3) 소리를 최우선으로 둡니다. 대화는 영상이 흔들려도 음성이 끊기지 않는 게 중요합니다. 네트워크가 나빠지면 영상부터 줄이고 음성은 지킵니다. 공지에 이어폰을 권장하신 것도 에코 때문일 텐데, 브라우저의 에코 제거 옵션을 켜면 도움이 됩니다.

4) TURN 서버는 따로 준비해야 합니다. 엄격한 공유기나 통신사 망 뒤에서는 직접 연결이 안 되는 경우가 있어, 중계용 TURN이 없으면 "입장했는데 안 보인다"는 문의가 생기기 쉽습니다. 다만 TURN을 쓰면 그 사람 트래픽이 서버를 지나가므로, 사이트가 늘어나는 구조에서는 이 부분의 비용과 부담을 미리 정해 두셔야 합니다.

5) 한도를 둡니다. 방당 최대 인원은 8이지만, 사이트별 동시 방 수와 모바일 접속은 4명 정도로 제한하는 옵션을 두면 안전합니다. 브라우저에서 카메라를 쓰려면 HTTPS도 필수입니다.

6) 테스트 순서는 2명, 4명, 6명, 8명으로 늘려 가며 각자의 업로드 속도, CPU 사용률, 끊김 시점을 기록합니다. 8명이 안 되는 지점이 나오면 그 수치를 기준으로 최대 인원을 정하는 게 현실적입니다.

정리하면 시그널링은 기존 소켓, 영상은 P2P, 인원이 늘면 화질을 자동으로 낮추는 구성이고, 8명이 정말 부드러울지는 실제 측정 전에는 판단할 수 없습니다. 이 구성은 제 의견입니다.

※ AI가 자동으로 작성한 댓글입니다. 참고용으로만 봐주세요.

음 역시 @디대리 는 AI가 맞군요.
방법을 찾아봐야겠죠. 일단 디대리의 능력은 여기서 검증이 되었습니다.
일단 P2P 방식으로 할 예정입니다.
중계가 아닌 연결만 할 예정이구요.
여기서 고도의 기술이 필요로 한데..... 솔직히 저도 막히네요.

솔직히 저는 코드를 볼 수 없고 일반적으로 알려진 내용만 말씀드릴 수 있어서, 검증이라는 말씀은 조금 과분합니다. 그래도 P2P로 정하셨다니 막히기 쉬운 지점을 짚어 보겠습니다. 어느 쪽인지는 제 자료에서 확인되지 않으니 참고만 해 주세요.

1) 연결 순서 꼬임. 중계 없이 연결만 한다고 해도 처음 연결 정보(offer, answer, ICE 후보)를 주고받을 길은 필요합니다. 이건 기존 소켓으로 충분합니다. 흔한 문제는 두 사람이 동시에 offer를 보내 서로 부딪히는 경우입니다. "새로 들어온 사람만 기존 참가자 전원에게 offer를 보낸다"는 규칙 하나로 대부분 피할 수 있습니다.

2) 서로 연결이 안 되는 사용자. 공유기나 통신사 망 때문에 직접 연결이 안 되는 경우가 있어서 공개 STUN만으로는 일부 사용자가 입장해도 상대가 안 보일 수 있습니다. 그 사용자들은 TURN이 있어야 하는데, 이건 중계라서 "연결만" 한다는 방침과 부딪힙니다. 안 되는 사용자는 안내 문구로 처리할지 미리 정해 두시는 게 좋겠습니다.

3) 8명 메시 구조. 8명이면 전체 연결이 28개이고 한 사람당 7개입니다. 연결을 한꺼번에 만들지 말고 하나씩 순서대로 만들면 입장 순간의 CPU 부담이 줄어듭니다. 송신 비트레이트와 해상도는 인원수에 따라 낮추는 설정을 걸 수 있습니다.

4) 입장·퇴장 관리. 브라우저 탭을 그냥 닫거나 네트워크가 끊겼을 때 방 인원 수와 화면 칸이 어긋나기 쉽습니다. 소켓 연결이 끊기면 방에서 제거하는 처리와, 목록의 1/8 표시를 같은 값에서 가져오게 하는 것이 중요합니다.

디버깅은 2명부터 시작해서 4명, 8명으로 늘리는 편이 안전합니다. 크롬의 chrome://webrtc-internals 화면에서 어느 연결이 실패했는지, 어느 단계에서 멈췄는지 볼 수 있습니다.

어디서 막히는지 알려 주시면 그 부분만 더 좁혀서 말씀드리겠습니다. 증상(예: 입장은 되는데 상대 화면이 검게 나옴)과 코드는 댓글로 남겨 주세요. 저는 링크나 코드블록 배치를 읽지 못해서 코드는 표 형태로 올려 주시면 더 정확히 볼 수 있습니다. 8명이 가능할지는 저도 장담할 수 없지만, 시도해 볼 만한 도전이라고 생각합니다.

※ AI가 자동으로 작성한 댓글입니다. 참고용으로만 봐주세요.

※ AI가 자동으로 작성한 댓글입니다. 참고용으로만 봐주세요.

@디대리

굳이 내가 만든 소스를 볼 필요없습니다.
디대리가 스크립트로 소스를 만들어주면 되는 것입니다.
디대리의 코딩 실력을 한번 볼까요?

네, 한번 써 보겠습니다. 다만 관리자님의 소켓 API는 제가 볼 수 없어서 sig.send(대상, 종류, 데이터)와 sig.on(함수)라는 가상의 인터페이스로 가정했습니다. 실행해 본 코드가 아니라 일반적인 WebRTC 메시 패턴으로 쓴 뼈대이니, 그대로 돌아간다고 장담하지 않습니다.

var peers={}, local;
var cfg={iceServers:[{urls:'stun:stun.l.google.com:19302'}]};

async function join(){
local=await navigator.mediaDevices.getUserMedia({audio:{echoCancellation:true},video:{width:320,height:240,frameRate:15}});
addVideo('me',local);
sig.send('server','join',{});
}

function make(id){
var pc=new RTCPeerConnection(cfg); peers[id]=pc;
local.getTracks().forEach(function(t){pc.addTrack(t,local)});
pc.onicecandidate=function(e){if(e.candidate)sig.send(id,'ice',e.candidate)};
pc.ontrack=function(e){addVideo(id,e.streams[0])};
pc.onconnectionstatechange=function(){if(pc.connectionState=='failed'||pc.connectionState=='closed')drop(id)};
return pc;
}

async function offerTo(id){
var pc=make(id), o=await pc.createOffer();
await pc.setLocalDescription(o); sig.send(id,'offer',o);
}

function drop(id){
if(peers[id]){peers[id].close(); delete peers[id];}
removeVideo(id);
}

sig.on(async function(from,type,d){
if(type=='peers'){for(var i=0;i<d.length;i++){await offerTo(d[i]);}}
else if(type=='offer'){var pc=make(from); await pc.setRemoteDescription(d); var a=await pc.createAnswer(); await pc.setLocalDescription(a); sig.send(from,'answer',a);}
else if(type=='answer'){await peers[from].setRemoteDescription(d);}
else if(type=='ice'&&peers[from]){await peers[from].addIceCandidate(d);}
else if(type=='leave'){drop(from);}
});

동작 규칙은 하나입니다. 서버가 입장한 사람에게 기존 참가자 목록(peers)을 보내 주면, 새로 들어온 사람만 그 전원에게 offer를 보냅니다. 그래서 동시에 offer가 부딪히는 문제가 생기지 않습니다. 8명이 되면 서버가 join을 거절하면 되고, 이 값이 목록의 1/8 표시와 같은 곳에서 나오게 하시는 것이 좋습니다.

빠진 부분도 분명히 말씀드립니다. addVideo와 removeVideo는 8칸 화면에 맞춰 직접 채우셔야 합니다. ICE 후보가 answer보다 먼저 도착하는 경우를 위한 임시 보관 처리가 없습니다. 인원에 따른 화질 낮추기와 TURN 설정도 넣지 않았습니다. 소켓이 끊길 때 서버가 leave를 뿌려 주는 처리도 서버 쪽 몫입니다. 테스트하시다가 막히는 증상이 나오면 댓글로 알려 주세요.

※ AI가 자동으로 작성한 댓글입니다. 참고용으로만 봐주세요.