들어가며
최근 면접이나 다양한 기술 이야기를 나누면서 제 졸업 작품에 대한 관심을 많이 받게 되었습니다. 이 작품에서 사용된 핵심 기술 중 하나는 바로 WebRTC를 활용한 원격 화상 통화 시스템이었습니다. 당시 프로젝트를 진행하며 P2P 통신을 구현했었는데, 그 과정에서 STUN과 TURN 서버를 접하게 되었고, 기술적으로 많은 것을 배우는 계기가 되었습니다.
이 글에서는 당시의 경험을 돌아보며 제가 왜 STUN과 TURN 서버를 선택했고, 어떤 한계와 고민이 있었는지를 정리하려 합니다. 추가로, "이런 식으로 했다면 어땠을까?"라는 개선 아이디어도 함께 담아보았습니다. 이를 통해 WebRTC 실시간 통신을 더 깊이 이해하는 데 도움이 되길 바랍니다.
프로젝트 시나리오
제가 만든 프로젝트의 시나리오는 간단히 말해 원격 의료 진단입니다. 환자와 의사가 원격으로 화상 통화를 하며 진단을 진행할 수 있는 시스템을 구상했습니다.
(당시 시나리오 만들 때 그림)
당시 제 접근 방식은 간단했습니다. WebRTC에서 제공하는 ICE(Interactive Connectivity Establishment) 를 활용해 자동으로 연결을 추적하고 P2P 통신을 설정하면 충분하다고 생각했습니다. 그러나 실제로 구현하면서 NAT(Network Address Translation) 문제와 방화벽이라는 현실적 제약에 부딪히게 되었고, 이를 해결하기 위해 STUN과 TURN 서버를 알게 되었는데 이에 대한 내용을 설명해보겠습니다.
STUN 서버: NAT 뒤에서도 P2P 연결 지원
STUN(Session Traversal Utilities for NAT) 서버는 WebRTC에서 기본적으로 사용되는 서버로, 클라이언트가 자신의 공인 IP와 포트를 파악할 수 있도록 돕습니다. STUN 서버는 클라이언트 간 직접 연결(P2P)을 지원하며, NAT(Network Address Translation) 뒤에 있어도 네트워크 경로를 설정할 수 있게 해줍니다.
초기 접근 방식으로는 STUN 서버만으로 충분하다고 생각했습니다. Google에서 제공되는 STUN 서버(예시: stun:stun.l.google.com:19302)를 사용해 P2P 연결을 설정하려 했고, 테스트도 진행했습니다.
실제로 학교 내부에서 저의 컴퓨터 2대로 정상 작동을 확인했습니다만, 중요한 것이 외부에 있는 친구나 다른 네트워크에서 이동하려니 제대로 되지 않았습니다.
문제 발생: 왜 외부 네트워크에서는 연결되지 않을까?
학교 내에서 테스트했을 때는 클라이언트 간 연결이 문제없이 이루어졌습니다. 그러나 집에 있는 친구와 테스트를 진행했을 때, 통신이 아예 이루어지지 않는 상황이 발생했습니다.
처음에는 코드나 WebRTC 설정에 문제가 있다고 생각했지만, 네트워크 환경의 차이 때문이라는 것을 알게 되었습니다. 자세히 살펴보니 다음과 같은 이유로 P2P 연결이 실패하고 있었습니다:
- Symmetric NAT 문제
집에서 사용하는 인터넷 환경이 Symmetric NAT를 사용하고 있어 STUN 서버를 통해 공인 IP를 파악해도 P2P 연결이 불가능했습니다.
- 학교 네트워크의 UDP 스트림 차단
학교 네트워크는 UDP 통신을 제한하지 않아 STUN 서버만으로도 통신이 가능했지만, 다른 네트워크 환경(특히 가정용 인터넷)에서는 UDP 스트림이 차단되거나 제대로 작동하지 않았습니다.
TURN 서버의 필요성: 데이터를 중계하여 문제 해결
STUN 서버만으로는 P2P 연결이 어려운 환경(Symmetric NAT, UDP 제한)이 있다는 것을 깨닫고, 이를 해결할 방법을 찾기 시작했습니다. 그 과정에서 WebRTC에서 사용하는 TURN 서버(Traversal Using Relays around NAT)를 알게 되었습니다.
TURN 서버는 클라이언트 간 데이터를 중계하여 직접 연결이 불가능한 상황에서도 안정적인 통신을 보장합니다. 특히, Symmetric NAT와 강력한 방화벽 환경에서 필수적인 역할을 합니다.
Coturn을 활용한 TURN 서버 도입
TURN 서버를 직접 구축하기 위해 AWS EC2에 Coturn을 설치했습니다. Coturn은 오픈소스로 제공되는 TURN 서버 구현체로, 간단한 설정만으로 TURN 서버를 실행할 수 있었습니다.
Coturn 서버 설정 예시:
# EC2에서 Coturn 설치 및 실행
sudo apt-get install coturn
sudo turnserver -a -o -v -n --realm myrealm.com --user username:passwordWebRTC 설정:
const peerConnection = new RTCPeerConnection({
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' }, // STUN 서버
{ urls: 'turn:ec2-xx-xx-xx-xx.compute.amazonaws.com:3478',
username: 'username',
credential: 'password'
} // Coturn TURN 서버
]
});
프로젝트 회고와 아쉬운 점
TURN 서버 도입의 의의
STUN 서버만으로는 해결할 수 없던 네트워크 문제를 TURN 서버를 도입함으로써 해결할 수 있었습니다. Coturn을 EC2에 설치하면서 엄청 많은 문제가 되지 않았습니다. 실제로 시연날에는 서울에 있는 팀원과 정상적으로 통신되는 결과까지 얻을 수 있었습니다.
또한 졸업작품을 만들면서 시간도 들인 노력도 있지만, 0부터 설계하고 쌓아 올렸다는 것에 많은 걸 경험했던 것 같습니다.
아쉬운 점: 인코딩 및 바이너리 데이터 처리의 부족
프로젝트에서는 서버 설계와 네트워크 연결에 대부분의 노력을 기울였지만, 실제 영상 및 오디오 데이터의 인코딩과 처리등 성능과 관련해서는 깊이 다루지 못했습니다. 어떻게 보면 웹 프론트엔지니어로서 가장 많이 봐야하는 부분이었는데 제가 잘 분석하지 못한 이유도 여기에 있을 수도 있겠다는 생각이 듭니다. WebRTC의 통신에서의 가장 중요한 인코딩 부분이 성능 최적화에 직접적인 영향을 미치기 때문에 이를 더 자세히 알아야할 필요가 있다고 생각합니다. 그래서 다음 글에서는 이 부분을 더 깊이 다뤄보고자 합니다.
마치며
STUN과 TURN 서버는 WebRTC의 핵심 기술로, 각각 P2P 연결을 지원하거나 데이터 중계를 통해 네트워크 문제를 해결합니다. 이번 프로젝트를 통해 두 기술의 역할과 한계를 명확히 이해할 수 있었습니다. 특히 TURN 서버를 도입한 경험은 실무에서도 충분히 적용 가능한 교훈을 남겼습니다.
다만, 영상 및 오디오 데이터의 처리와 인코딩 최적화에 대해 더 깊이 고민하지 못한 점은 아쉬움으로 남습니다. 앞으로 이 주제를 심화 연구해 글로 공유할 예정이니, 관심 있게 지켜봐 주시길 바랍니다.
