WebRTC 프로덕션 배포 완벽 가이드

WebRTC 애플리케이션을 실제 서비스 환경에 배포하기 위한 모든 과정을 다룹니다. TURN 서버 설정부터 Docker 컨테이너화, Nginx 설정, 로드밸런싱, 수평 확장, 그리고 모니터링까지 실무에 필요한 모든 내용을 초급 개발자도 쉽게 따라할 수 있도록 친절하게 설명합니다.

---

목차

1. TURN 서버 설정 (coturn)
2. Docker 컨테이너화
3. Nginx 리버스 프록시
4. 로드밸런싱 전략
5. 수평 확장
6. 모니터링 및 로깅

---

1. TURN 서버 설정 (coturn)

시작하며

여러분이 WebRTC로 화상 통화 앱을 만들어서 친구들과 테스트할 때는 잘 작동했는데, 회사 네트워크나 카페에서 사용하려니 갑자기 연결이 안 되는 경험을 해보셨나요? 이런 일은 실제로 정말 자주 발생합니다.

이런 문제는 NAT(Network Address Translation)와 방화벽 때문에 생깁니다. 마치 여러분이 아파트에 살고 있는데, 아파트 전체가 하나의 주소를 공유하는 것처럼, 많은 컴퓨터들이 하나의 공용 IP 주소를 사용하기 때문입니다.

이렇게 되면 외부에서 여러분의 컴퓨터로 직접 연결하기가 매우 어렵습니다. 바로 이럴 때 필요한 것이 TURN 서버입니다.

TURN 서버는 마치 우체국처럼 중간에서 데이터를 전달해주는 역할을 합니다. 두 사람이 직접 만날 수 없을 때, 중간 지점에서 만나는 것처럼요.

실제 통계를 보면 약 8-20%의 사용자들이 TURN 서버 없이는 연결할 수 없다고 합니다. 그래서 프로덕션 환경에서는 TURN 서버가 필수입니다.

개요

간단히 말해서, TURN(Traversal Using Relays around NAT) 서버는 방화벽이나 NAT 뒤에 있는 사용자들이 서로 통신할 수 있도록 중계해주는 서버입니다. WebRTC는 기본적으로 P2P(Peer-to-Peer) 방식으로 직접 연결을 시도합니다.

하지만 회사 네트워크처럼 보안이 강한 환경에서는 직접 연결이 차단됩니다. 이럴 때 TURN 서버가 중간에서 모든 미디어 데이터(영상, 음성)를 중계해줍니다.

마치 두 사람이 담벼락 너머로 이야기할 수 없을 때, 중간에 전령이 메시지를 전달하는 것과 같습니다. 기존에는 직접 서버를 만들어야 했다면, 이제는 coturn이라는 오픈소스를 사용하면 쉽게 TURN 서버를 구축할 수 있습니다.

coturn은 가장 널리 사용되는 TURN 서버 구현체로, 성능도 뛰어나고 설정도 비교적 간단합니다. TURN 서버의 핵심 특징은 세 가지입니다.

첫째, UDP와 TCP를 모두 지원하여 다양한 네트워크 환경에 대응할 수 있습니다. 둘째, 인증 기능이 있어 허가받은 사용자만 사용하게 할 수 있습니다.

셋째, 대역폭 제어 기능으로 서버 자원을 효율적으로 관리할 수 있습니다. 이러한 특징들이 중요한 이유는 TURN 서버가 모든 미디어 데이터를 중계하기 때문에 서버 비용이 많이 들 수 있기 때문입니다.

그래서 보안과 자원 관리가 매우 중요합니다.

코드 예제

# turnserver.conf - Coturn 설정 파일
# 서버가 수신할 포트 설정
listening-port=3478
# TLS를 위한 포트 (보안 연결)
tls-listening-port=5349

# 외부에서 접근할 공용 IP 주소
external-ip=YOUR_PUBLIC_IP

# 미디어 중계에 사용할 포트 범위
min-port=49152
max-port=65535

# 인증을 위한 realm (도메인)
realm=yourdomain.com

# 로그 파일 위치
log-file=/var/log/turnserver.log

# 사용자 인증 (장기 credential 방식)
lt-cred-mech
# 사용자 데이터베이스 사용
userdb=/var/lib/turn/turndb

설명

이것이 하는 일: 이 설정 파일은 coturn TURN 서버가 어떻게 동작할지를 정의합니다. 클라이언트의 연결을 받아들이고, 인증하고, 미디어 데이터를 중계하는 모든 과정을 제어합니다.

첫 번째로, listening-port와 tls-listening-port는 클라이언트가 TURN 서버에 연결할 때 사용하는 문의 역할을 합니다. 3478은 일반 연결용이고, 5349는 암호화된 보안 연결용입니다.

마치 건물에 일반 출입구와 보안 출입구가 따로 있는 것처럼, 두 가지 포트를 열어두면 다양한 상황에 대응할 수 있습니다. 그 다음으로, external-ip 설정이 실행됩니다.

이것은 매우 중요한데, 서버가 자신의 공용 IP 주소를 클라이언트에게 알려줘야 하기 때문입니다. 만약 서버가 AWS나 클라우드에서 실행되고 있다면, 내부 IP와 외부 IP가 다를 수 있습니다.

이 설정은 "나는 이 주소로 연결할 수 있어"라고 클라이언트에게 정확히 알려주는 역할을 합니다. min-port와 max-port는 실제 미디어 데이터(영상, 음성)가 오가는 통로를 정의합니다.

49152부터 65535까지는 "동적 포트"라고 불리는 범위로, 임시로 사용하기에 안전한 포트 번호들입니다. 여러 사용자가 동시에 연결할 때 각자 다른 포트를 할당받게 됩니다.

realm과 인증 관련 설정은 보안을 담당합니다. 인증 없이 TURN 서버를 열어두면 누구나 여러분의 서버를 사용할 수 있어서, 서버 비용이 엄청나게 올라갈 수 있습니다.

lt-cred-mech(Long-Term Credential Mechanism)은 사용자 이름과 비밀번호로 인증하는 방식으로, 안전하면서도 구현이 간단합니다. 여러분이 이 설정을 사용하면 안정적이고 안전한 TURN 서버를 운영할 수 있습니다.

특히 회사 네트워크나 모바일 네트워크에서도 끊김 없이 WebRTC 통신이 가능해집니다. 또한 로그 파일을 통해 문제가 생겼을 때 원인을 쉽게 파악할 수 있고, 포트 범위 제한으로 방화벽 설정도 명확하게 할 수 있습니다.

실전 팁

💡 TURN 서버는 대역폭을 많이 사용하므로, AWS나 GCP 같은 클라우드에서는 데이터 전송 비용이 높을 수 있습니다. 가능하면 트래픽 비용이 저렴한 지역이나 제공자를 선택하세요.

💡 turnserver 시작 전에 꼭 방화벽에서 3478, 5349, 그리고 49152-65535 포트를 열어주세요. 하나라도 막혀있으면 연결이 실패합니다.

💡 인증 정보(username, password)는 서버에서 동적으로 생성하는 것이 안전합니다. 클라이언트에 하드코딩하지 마세요. REST API를 통해 필요할 때마다 임시 credential을 발급하는 방식을 사용하세요.

💡 처음 테스트할 때는 https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ 페이지를 사용하여 TURN 서버가 제대로 작동하는지 확인할 수 있습니다.

💡 로그 레벨을 처음에는 verbose로 설정하여 문제를 빠르게 파악하고, 안정화되면 warning 레벨로 낮춰서 디스크 공간을 절약하세요.

---

2. Docker 컨테이너화

시작하며

여러분이 로컬 컴퓨터에서는 완벽하게 작동하는 WebRTC 앱을 만들었는데, 실제 서버에 올리려니 "내 컴퓨터에서는 되는데..."라는 말을 하게 되는 상황을 겪어본 적 있나요? Node 버전이 다르거나, 설치된 패키지가 달라서 서버에서는 작동하지 않는 경우가 정말 많습니다.

이런 문제는 개발 환경과 프로덕션 환경의 차이에서 발생합니다. 개발자마다 다른 운영체제를 사용하고, 서버도 또 다른 환경입니다.

이렇게 되면 "환경 차이" 때문에 디버깅하는 데 엄청난 시간이 낭비됩니다. 바로 이럴 때 필요한 것이 Docker 컨테이너화입니다.

Docker는 애플리케이션과 그것이 필요한 모든 것(Node.js, 패키지, 설정 파일 등)을 하나의 "상자"에 담아서 어디서든 똑같이 실행되게 만들어줍니다. 마치 이사할 때 짐을 박스에 잘 정리해서 싸면, 어디로 가든 그대로 사용할 수 있는 것처럼요.

개요

간단히 말해서, Docker 컨테이너화는 애플리케이션과 그것의 실행 환경을 하나로 패키징하는 기술입니다. 컨테이너는 가상머신보다 훨씬 가볍고 빠르게 시작됩니다.

WebRTC 애플리케이션을 배포할 때 Docker를 사용하면 여러 장점이 있습니다. 첫째, 개발 환경과 프로덕션 환경을 완전히 동일하게 만들 수 있습니다.

둘째, 여러 서버에 배포할 때 일관성이 보장됩니다. 셋째, 새로운 버전을 배포하고 문제가 생기면 이전 버전으로 즉시 되돌릴 수 있습니다.

마치 게임에서 세이브 포인트를 만들어두는 것과 비슷합니다. 기존에는 서버에 직접 Node.js를 설치하고, npm install을 실행하고, 환경변수를 설정하는 등의 복잡한 과정을 거쳐야 했다면, 이제는 Dockerfile 하나로 모든 것을 자동화할 수 있습니다.

Docker의 핵심 특징은 세 가지입니다. 첫째, 이미지 레이어링으로 빌드 속도가 빠르고 저장 공간도 효율적입니다.

둘째, 컨테이너는 서로 격리되어 있어 한 애플리케이션의 문제가 다른 것에 영향을 주지 않습니다. 셋째, 이식성이 뛰어나서 개발자 노트북, 테스트 서버, 프로덕션 서버 어디서든 똑같이 작동합니다.

이러한 특징들이 중요한 이유는 현대적인 애플리케이션은 여러 서비스(시그널링 서버, TURN 서버, 미디어 서버 등)로 구성되기 때문입니다. Docker를 사용하면 이런 복잡한 시스템을 쉽게 관리할 수 있습니다.

코드 예제

# Dockerfile - WebRTC 시그널링 서버 컨테이너화
FROM node:18-alpine

# 작업 디렉토리 설정
WORKDIR /app

# package.json과 package-lock.json을 먼저 복사 (캐시 최적화)
COPY package*.json ./

# 프로덕션 의존성만 설치
RUN npm ci --only=production

# 애플리케이션 소스 복사
COPY . .

# 애플리케이션이 사용할 포트 노출
EXPOSE 8080

# 헬스체크 설정 (컨테이너가 정상 동작하는지 확인)
HEALTHCHECK --interval=30s --timeout=3s \
  CMD node healthcheck.js || exit 1

# 애플리케이션 실행
CMD ["node", "server.js"]

설명

이것이 하는 일: 이 Dockerfile은 WebRTC 시그널링 서버를 Docker 컨테이너로 만드는 레시피입니다. 각 줄은 이미지를 만드는 하나의 단계를 나타냅니다.

첫 번째로, FROM node:18-alpine은 기본이 되는 이미지를 선택합니다. node:18-alpine은 Node.js 18 버전이 설치된 경량 리눅스 이미지입니다.

alpine은 일반 Linux보다 훨씬 작아서 이미지 크기가 5MB 정도밖에 되지 않습니다. 이렇게 작은 이미지를 사용하면 다운로드도 빠르고 보안 취약점도 적습니다.

그 다음으로, WORKDIR /app과 COPY 명령들이 실행됩니다. 여기서 중요한 것은 package.json을 먼저 복사한다는 점입니다.

왜 그럴까요? Docker는 레이어 캐싱이라는 기능이 있어서, 변경되지 않은 단계는 다시 실행하지 않고 캐시를 사용합니다.

package.json은 자주 변경되지 않지만 소스 코드는 자주 변경됩니다. 그래서 package.json을 먼저 복사하고 npm ci를 실행하면, 소스 코드가 바뀌어도 패키지 설치 과정은 캐시를 사용할 수 있어 빌드가 훨씬 빨라집니다.

npm ci 명령은 npm install과 비슷하지만 프로덕션 환경에 더 적합합니다. package-lock.json의 정확한 버전을 설치하고, 기존 node_modules를 삭제하고 새로 설치하므로 더 안정적입니다.

--only=production 옵션은 개발용 패키지(jest, eslint 등)는 설치하지 않아 이미지 크기를 줄여줍니다. EXPOSE 8080은 컨테이너가 8080 포트를 사용한다고 선언합니다.

이것은 문서화 역할도 하지만, 실제로 포트를 여는 것은 docker run 명령에서 -p 옵션으로 합니다. HEALTHCHECK는 매우 중요한데, 컨테이너가 실행 중이지만 실제로는 응답하지 않는 "좀비 상태"를 감지할 수 있게 해줍니다.

30초마다 healthcheck.js를 실행해서 서버가 정상인지 확인하고, 실패하면 컨테이너를 재시작합니다. 여러분이 이 Dockerfile을 사용하면 docker build 명령 한 번으로 배포 가능한 이미지를 만들 수 있습니다.

이 이미지는 Docker Hub나 회사 내부 레지스트리에 저장했다가 필요할 때마다 꺼내서 사용할 수 있습니다. 또한 같은 팀의 다른 개발자도 이 이미지를 받아서 즉시 개발 환경을 구축할 수 있어, "내 컴퓨터에서는 되는데" 문제가 완전히 사라집니다.

실전 팁

💡 .dockerignore 파일을 만들어서 node_modules, .git, logs 등 불필요한 파일은 이미지에 포함되지 않도록 하세요. 이미지 크기가 수백 MB 줄어들 수 있습니다.

💡 멀티 스테이지 빌드를 사용하면 빌드 도구는 최종 이미지에 포함되지 않아 더 작은 이미지를 만들 수 있습니다. 특히 TypeScript를 사용한다면 빌드 스테이지와 런타임 스테이지를 분리하세요.

💡 환경변수는 Dockerfile에 하드코딩하지 말고 docker run -e 옵션이나 .env 파일로 주입하세요. 같은 이미지를 개발/스테이징/프로덕션에서 다르게 설정할 수 있습니다.

💡 이미지 태그를 명확히 관리하세요. latest 태그만 사용하면 어떤 버전인지 알 수 없습니다. 버전 번호나 Git 커밋 해시를 태그로 사용하면 롤백이 쉬워집니다.

💡 docker-compose를 사용하면 시그널링 서버, TURN 서버, 데이터베이스 등 여러 컨테이너를 한 번에 관리할 수 있습니다. 개발 환경을 빠르게 구축하는 데 매우 유용합니다.

---

3. Nginx 리버스 프록시

시작하며

여러분이 WebRTC 앱을 만들어서 https://myapp.com으로 접속하게 하고 싶은데, Node.js 서버는 3000번 포트에서 실행되고 있고, TURN 서버는 3478 포트를 사용합니다. 사용자들에게 "myapp.com:3000으로 접속하세요"라고 할 수는 없는 노릇입니다.

또한 HTTPS 인증서도 설정해야 하는데 어떻게 해야 할지 막막하셨나요? 이런 문제는 실제로 모든 웹 서비스가 겪는 공통적인 문제입니다.

사용자는 간단한 도메인 이름으로 접속하고 싶어 하지만, 실제 서버는 여러 개의 서비스가 다른 포트에서 실행되고 있습니다. 또한 보안을 위해 HTTPS를 사용해야 하는데, 각 서비스마다 SSL 인증서를 설정하는 것은 너무 복잡합니다.

바로 이럴 때 필요한 것이 Nginx 리버스 프록시입니다. Nginx는 마치 호텔의 프런트 데스크처럼, 외부에서 오는 모든 요청을 받아서 적절한 서비스로 안내해주는 역할을 합니다.

사용자는 하나의 주소만 알면 되고, Nginx가 내부적으로 어느 서버로 연결할지 판단합니다.

개요

간단히 말해서, Nginx 리버스 프록시는 클라이언트와 실제 서버 사이에서 중개자 역할을 하는 서버입니다. 클라이언트는 Nginx와 통신하고, Nginx는 내부 서버와 통신합니다.

WebRTC 애플리케이션에서 Nginx를 사용하면 여러 장점이 있습니다. 첫째, SSL/TLS 종료(termination)를 한 곳에서 처리할 수 있습니다.

WebRTC는 보안상 HTTPS가 필수인데, Nginx에서만 인증서를 관리하면 되므로 훨씬 편합니다. 둘째, 여러 서비스를 하나의 도메인 아래 통합할 수 있습니다.

/api는 시그널링 서버로, /turn은 TURN 서버로 라우팅하는 식입니다. 셋째, 정적 파일(HTML, CSS, JS)을 Nginx에서 직접 서비스하면 Node.js 서버의 부담을 줄일 수 있습니다.

기존에는 각 서비스마다 직접 포트를 열고 방화벽을 설정하고 인증서를 관리해야 했다면, 이제는 Nginx 설정 파일 하나로 모든 라우팅과 보안을 관리할 수 있습니다. Nginx의 핵심 특징은 세 가지입니다.

첫째, 이벤트 기반 아키텍처로 매우 높은 성능을 보여줍니다. 수만 개의 동시 연결을 처리할 수 있습니다.

둘째, WebSocket을 완벽하게 지원하여 WebRTC 시그널링에 적합합니다. 셋째, 로드밸런싱, 캐싱, 압축 등 다양한 기능을 제공합니다.

이러한 특징들이 중요한 이유는 WebRTC 애플리케이션은 실시간 통신을 다루기 때문에 성능과 안정성이 매우 중요하기 때문입니다. Nginx는 검증된 고성능 서버로, 전 세계 상위 웹사이트의 30% 이상이 사용합니다.

코드 예제

# nginx.conf - WebRTC 앱을 위한 Nginx 설정
upstream signaling_server {
    # 시그널링 서버 주소 (여러 개 가능)
    server localhost:3000;
    server localhost:3001 backup;  # 백업 서버
}

server {
    listen 80;
    server_name myapp.com;
    # HTTP를 HTTPS로 리다이렉트
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name myapp.com;

    # SSL 인증서 설정
    ssl_certificate /etc/ssl/certs/myapp.crt;
    ssl_certificate_key /etc/ssl/private/myapp.key;

    # WebSocket 업그레이드를 위한 헤더
    location /socket.io/ {
        proxy_pass http://signaling_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # API 요청 프록시
    location /api/ {
        proxy_pass http://signaling_server;
        proxy_set_header Host $host;
    }

    # 정적 파일 직접 서빙
    location / {
        root /var/www/myapp;
        try_files $uri $uri/ /index.html;
    }
}

설명

이것이 하는 일: 이 Nginx 설정은 WebRTC 애플리케이션의 모든 트래픽을 관리합니다. HTTP를 HTTPS로 리다이렉트하고, WebSocket 연결을 처리하고, API 요청을 백엔드로 전달하고, 정적 파일을 서빙합니다.

첫 번째로, upstream 블록은 백엔드 서버들을 정의합니다. signaling_server라는 이름으로 두 개의 서버를 지정했습니다.

주 서버(localhost:3000)가 다운되면 자동으로 백업 서버(localhost:3001)로 전환됩니다. 이것은 마치 주 도로가 막혔을 때 우회 도로로 자동으로 안내하는 네비게이션 같은 역할입니다.

그 다음으로, 첫 번째 server 블록이 실행됩니다. 이것은 80번 포트(HTTP)로 들어오는 모든 요청을 443번 포트(HTTPS)로 리다이렉트합니다.

WebRTC는 보안상의 이유로 HTTPS에서만 작동하기 때문에, HTTP로 접속한 사용자를 자동으로 HTTPS로 안내합니다. return 301은 "영구적으로 이동했다"는 의미로, 브라우저가 이것을 기억해서 다음부터는 자동으로 HTTPS로 접속합니다.

두 번째 server 블록은 실제 HTTPS 트래픽을 처리합니다. listen 443 ssl http2는 HTTPS와 HTTP/2 프로토콜을 사용한다는 뜻입니다.

HTTP/2는 여러 요청을 동시에 처리할 수 있어 성능이 더 좋습니다. ssl_certificate와 ssl_certificate_key는 Let's Encrypt 같은 서비스에서 받은 인증서를 지정합니다.

location 블록들은 URL 경로에 따라 다르게 처리합니다. /socket.io/로 시작하는 요청은 WebSocket 업그레이드를 위한 특별한 헤더를 추가합니다.

proxy_set_header Upgrade $http_upgrade와 Connection "upgrade"는 HTTP 연결을 WebSocket으로 업그레이드하는 데 필수적입니다. WebSocket은 양방향 실시간 통신을 위해 사용되며, WebRTC 시그널링에 자주 사용됩니다.

X-Real-IP 헤더는 실제 클라이언트의 IP 주소를 백엔드 서버에 전달합니다(Nginx를 거치면 백엔드는 Nginx의 IP만 보이기 때문입니다). 여러분이 이 설정을 사용하면 사용자는 myapp.com이라는 간단한 주소로 접속할 수 있고, Nginx가 자동으로 적절한 서비스로 연결해줍니다.

또한 SSL 인증서는 Nginx에서만 관리하면 되므로, 백엔드 서버는 보안 설정 없이 간단하게 개발할 수 있습니다. 정적 파일은 Nginx가 직접 서빙하므로 Node.js 서버는 비즈니스 로직에만 집중할 수 있어 전체 성능이 향상됩니다.

실전 팁

💡 Let's Encrypt를 사용하면 무료로 SSL 인증서를 받을 수 있고, certbot이 자동으로 갱신도 해줍니다. sudo certbot --nginx 명령 하나면 Nginx 설정까지 자동으로 해줍니다.

💡 gzip 압축을 활성화하면 JavaScript 파일 같은 텍스트 기반 리소스의 전송 크기를 70-80% 줄일 수 있습니다. gzip on; gzip_types text/plain text/css application/json application/javascript;를 추가하세요.

💡 proxy_connect_timeout과 proxy_read_timeout을 적절히 설정하세요. WebRTC 시그널링은 연결이 오래 유지될 수 있으므로 기본값(60초)보다 길게 설정하는 것이 좋습니다.

💡 access_log와 error_log를 꼭 확인하세요. 연결 실패나 타임아웃 문제의 대부분은 Nginx 로그에 기록됩니다. tail -f /var/log/nginx/error.log로 실시간 모니터링할 수 있습니다.

💡 rate limiting을 설정하면 DDoS 공격이나 과도한 요청으로부터 서버를 보호할 수 있습니다. limit_req_zone과 limit_req 디렉티브를 사용하여 IP당 요청 수를 제한하세요.

---

4. 로드밸런싱 전략

시작하며

여러분의 WebRTC 화상 통화 앱이 인기를 얻어서 동시 접속자가 100명, 1000명으로 늘어나기 시작했습니다. 그런데 갑자기 서버가 느려지고, 일부 사용자는 연결조차 못 하는 상황이 발생합니다.

서버 하나로는 감당이 안 되는데, 어떻게 해야 할까요? 이런 문제는 성공하는 모든 서비스가 겪는 "행복한 고민"입니다.

사용자가 많아질수록 서버 한 대의 처리 능력은 한계에 부딪힙니다. CPU, 메모리, 네트워크 대역폭 모두 물리적인 한계가 있습니다.

또한 서버 하나만 사용하면 그 서버에 문제가 생겼을 때 전체 서비스가 다운되는 위험도 있습니다. 바로 이럴 때 필요한 것이 로드밸런싱입니다.

로드밸런싱은 마치 고속도로 톨게이트처럼, 여러 대의 서버 중에서 가장 여유로운 서버로 사용자를 안내하는 기술입니다. 한 대의 서버가 고장 나도 다른 서버들이 계속 서비스를 제공하므로 안정성도 높아집니다.

개요

간단히 말해서, 로드밸런싱은 여러 서버에 트래픽을 분산시켜 성능과 안정성을 높이는 기술입니다. 하나의 서버가 과부하되지 않도록 부하를 골고루 나눕니다.

WebRTC 애플리케이션에서 로드밸런싱은 특히 중요합니다. 시그널링 서버는 많은 WebSocket 연결을 유지해야 하고, TURN 서버는 대역폭을 많이 사용합니다.

로드밸런서를 사용하면 이러한 부하를 여러 서버에 분산시킬 수 있습니다. 또한 한 서버가 다운되어도 로드밸런서가 자동으로 다른 서버로 트래픽을 보내므로, 사용자는 서비스 중단을 느끼지 못합니다.

기존에는 DNS 라운드 로빈 같은 단순한 방법을 사용했다면, 이제는 헬스 체크, 세션 어피니티, 동적 가중치 조절 등 훨씬 정교한 로드밸런싱이 가능합니다. 로드밸런싱의 핵심 특징은 세 가지입니다.

첫째, 자동 장애 조치(failover)로 서버가 다운되면 즉시 트래픽을 다른 서버로 돌립니다. 둘째, 세션 유지(sticky session)로 같은 사용자의 요청을 같은 서버로 보낼 수 있습니다.

셋째, 헬스 체크로 서버의 상태를 실시간으로 모니터링합니다. 이러한 특징들이 중요한 이유는 WebRTC는 상태를 유지하는(stateful) 프로토콜이기 때문입니다.

한 사용자의 시그널링 메시지는 같은 서버로 계속 가야 하므로, 세션 어피니티가 필수적입니다.

코드 예제

# nginx.conf - WebRTC를 위한 고급 로드밸런싱 설정
upstream signaling_servers {
    # IP 해시: 같은 클라이언트는 항상 같은 서버로 (세션 유지)
    ip_hash;

    # 서버 목록 (가중치 설정 가능)
    server 10.0.1.10:3000 weight=3 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:3000 weight=2 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:3000 weight=1 max_fails=3 fail_timeout=30s;

    # 백업 서버 (모든 서버가 다운되면 사용)
    server 10.0.1.13:3000 backup;

    # 연결 유지 (성능 향상)
    keepalive 32;
}

# 헬스 체크를 위한 별도 location
server {
    listen 80;

    location /health {
        access_log off;
        return 200 "healthy\n";
        add_header Content-Type text/plain;
    }

    location / {
        proxy_pass http://signaling_servers;
        proxy_http_version 1.1;

        # WebSocket 지원
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # 타임아웃 설정 (WebSocket 장시간 연결 지원)
        proxy_connect_timeout 60s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;

        # 클라이언트 정보 전달
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

설명

이것이 하는 일: 이 설정은 여러 시그널링 서버에 트래픽을 지능적으로 분산합니다. 같은 클라이언트는 같은 서버로 연결하고, 서버 장애를 자동으로 감지하며, 서버마다 다른 용량을 고려합니다.

첫 번째로, ip_hash 지시어가 핵심 역할을 합니다. 이것은 클라이언트의 IP 주소를 해싱하여 항상 같은 서버로 연결되게 만듭니다.

WebRTC 시그널링은 여러 메시지가 순서대로 같은 서버로 가야 하므로, 세션 유지가 필수적입니다. 예를 들어, 사용자 A가 첫 연결에서 서버1에 연결되었다면, 이후 모든 요청도 서버1로 갑니다.

마치 은행에서 같은 창구 직원과 계속 상담하는 것처럼, 상태 정보를 공유할 수 있어 효율적입니다. 그 다음으로, 각 서버의 weight(가중치) 설정이 동작합니다.

weight=3인 서버는 weight=1인 서버보다 3배 많은 트래픽을 받습니다. 이것은 서버의 성능 차이를 반영할 때 유용합니다.

예를 들어, 새로운 고성능 서버를 추가했다면 더 높은 가중치를 주어 더 많은 부하를 처리하게 할 수 있습니다. max_fails=3과 fail_timeout=30s는 자동 장애 조치를 제어합니다.

서버가 3번 연속 응답에 실패하면 30초 동안 "다운됨"으로 표시하고, 그 서버로는 트래픽을 보내지 않습니다. 30초 후에 다시 시도해서 복구되었는지 확인합니다.

이것은 마치 가게 문이 닫혀있으면 다른 가게로 가다가, 나중에 다시 확인해서 열렸으면 다시 이용하는 것과 같습니다. backup 서버는 비상 상황을 위한 것입니다.

모든 주 서버가 다운되었을 때만 사용됩니다. 평상시에는 대기 상태로 있다가, 위기 상황에서 서비스를 유지하는 최후의 보루 역할을 합니다.

keepalive 32는 Nginx와 백엔드 서버 사이의 연결을 재사용하여 성능을 높입니다. 매번 새 연결을 만드는 것보다 기존 연결을 재사용하는 것이 훨씬 빠릅니다.

타임아웃 설정들은 WebSocket의 장시간 연결을 지원하기 위한 것입니다. 기본 타임아웃은 60초인데, WebSocket 연결은 몇 분에서 몇 시간까지 유지될 수 있으므로 300초(5분)로 늘렸습니다.

이렇게 하면 화상 통화 중에 연결이 끊기는 문제를 방지할 수 있습니다. 여러분이 이 설정을 사용하면 서버를 쉽게 추가하거나 제거할 수 있습니다.

트래픽이 늘어나면 upstream 블록에 서버를 추가하기만 하면 되고, 유지보수를 위해 서버를 내리려면 해당 줄을 주석 처리하면 됩니다. Nginx가 자동으로 새로운 설정을 적용하여 무중단으로 서버를 관리할 수 있습니다.

실전 팁

💡 least_conn 알고리즘도 고려해보세요. ip_hash는 세션 유지에 좋지만, 특정 서버에 부하가 몰릴 수 있습니다. least_conn은 현재 연결 수가 가장 적은 서버로 보내므로 부하 분산이 더 균등합니다.

💡 헬스 체크는 단순히 HTTP 200 응답만 확인하지 말고, 실제로 데이터베이스 연결, Redis 연결 등 중요한 의존성도 확인하세요. 서버가 실행 중이지만 데이터베이스에 연결 못 하면 의미가 없습니다.

💡 AWS를 사용한다면 Elastic Load Balancer(ELB)를 고려하세요. Nginx보다 설정이 간단하고, 자동 스케일링과 통합됩니다. Application Load Balancer는 WebSocket을 완벽 지원합니다.

💡 모니터링 도구(Prometheus + Grafana)를 연동하여 각 서버의 부하를 시각화하세요. 어떤 서버가 과부하인지, 로드밸런싱이 제대로 작동하는지 한눈에 볼 수 있습니다.

💡 Sticky session을 구현할 때 쿠키 기반 방식도 고려하세요. IP 기반은 같은 네트워크의 여러 사용자가 같은 서버로 몰릴 수 있지만, 쿠키 기반은 더 균등하게 분산됩니다.

---

5. 수평 확장

시작하며

여러분의 WebRTC 서비스가 대박이 나서 사용자가 폭발적으로 증가하고 있습니다. 서버를 계속 추가하고 있지만, 어느 순간부터 문제가 생깁니다.

새로운 서버를 추가해도 성능이 개선되지 않거나, 사용자들이 다른 서버에 있는 사람과 연결이 안 되는 문제가 발생합니다. 어떻게 해야 할까요?

이런 문제는 단순히 서버를 추가하는 것만으로는 해결되지 않습니다. 여러 서버가 상태를 공유하지 못하면, 서버 A에 연결된 사용자와 서버 B에 연결된 사용자는 서로를 찾을 수 없습니다.

또한 WebSocket 연결은 특정 서버에 고정되기 때문에, 단순한 로드밸런싱만으로는 부족합니다. 바로 이럴 때 필요한 것이 제대로 된 수평 확장(horizontal scaling) 전략입니다.

수평 확장은 단순히 서버를 추가하는 것이 아니라, 여러 서버가 마치 하나의 시스템처럼 동작하도록 만드는 것입니다. Redis 같은 공유 저장소를 사용하여 서버 간 메시지를 전달하고, 상태를 동기화합니다.

개요

간단히 말해서, 수평 확장은 시스템의 처리 능력을 높이기 위해 서버를 추가하는 것입니다. 한 대의 서버를 업그레이드하는 수직 확장과 달리, 여러 대의 서버를 추가하는 방식입니다.

WebRTC 애플리케이션에서 수평 확장은 특별한 도전 과제가 있습니다. 실시간 통신은 상태를 유지해야 하고, 서버 간 메시지 전달이 필요하기 때문입니다.

예를 들어, 사용자 A가 서버1에 연결되어 있고 사용자 B가 서버2에 연결되어 있다면, 서버1과 서버2가 서로 통신할 수 있어야 합니다. 이를 위해 Redis Pub/Sub이나 RabbitMQ 같은 메시지 브로커를 사용합니다.

기존에는 모든 상태를 메모리에 저장했다면, 이제는 Redis 같은 공유 저장소를 사용합니다. 세션 정보, 활성 사용자 목록, 진행 중인 통화 정보 등을 Redis에 저장하면, 어떤 서버든 이 정보에 접근할 수 있습니다.

수평 확장의 핵심 특징은 세 가지입니다. 첫째, 무상태(stateless) 설계로 각 서버는 독립적으로 동작할 수 있습니다.

둘째, 공유 저장소(Redis, PostgreSQL 등)를 통해 필요한 데이터를 공유합니다. 셋째, 메시지 브로커로 서버 간 실시간 통신이 가능합니다.

이러한 특징들이 중요한 이유는 수평 확장이 제대로 구현되면 이론적으로 무한대로 확장할 수 있기 때문입니다. 사용자가 10배 증가하면 서버도 10배 추가하면 됩니다.

클라우드 환경에서는 자동 스케일링으로 이것을 자동화할 수도 있습니다.

코드 예제

// signaling-server.js - Redis를 사용한 수평 확장 가능한 시그널링 서버
const express = require('express');
const http = require('http');
const socketIO = require('socket.io');
const redis = require('redis');
const { createAdapter } = require('@socket.io/redis-adapter');

const app = express();
const server = http.createServer(app);
const io = socketIO(server);

// Redis 클라이언트 생성 (Pub/Sub용)
const pubClient = redis.createClient({ url: 'redis://redis-server:6379' });
const subClient = pubClient.duplicate();

// Socket.IO에 Redis 어댑터 연결 (서버 간 메시지 전달)
Promise.all([pubClient.connect(), subClient.connect()]).then(() => {
  io.adapter(createAdapter(pubClient, subClient));
  console.log('Redis adapter connected');
});

// 일반 데이터 저장용 Redis 클라이언트
const dataClient = redis.createClient({ url: 'redis://redis-server:6379' });
dataClient.connect();

io.on('connection', (socket) => {
  console.log('User connected:', socket.id);

  // 사용자 정보를 Redis에 저장 (모든 서버에서 접근 가능)
  dataClient.hSet('users', socket.id, JSON.stringify({
    id: socket.id,
    connectedAt: Date.now(),
    server: process.env.SERVER_ID  // 어느 서버에 연결되었는지
  }));

  // WebRTC offer 전달 (다른 서버에 있는 사용자에게도 전달됨)
  socket.on('offer', async (data) => {
    const { to, offer } = data;
    // Redis 어댑터가 자동으로 다른 서버로 전달
    io.to(to).emit('offer', { from: socket.id, offer });
  });

  socket.on('disconnect', () => {
    // Redis에서 사용자 정보 제거
    dataClient.hDel('users', socket.id);
  });
});

server.listen(3000, () => {
  console.log('Server running on port 3000');
});

설명

이것이 하는 일: 이 코드는 여러 대의 시그널링 서버가 마치 하나의 서버처럼 동작하도록 만듭니다. Redis를 중앙 허브로 사용하여 서버 간 메시지를 전달하고 상태를 공유합니다.

첫 번째로, Redis 클라이언트 세 개를 생성합니다. pubClient와 subClient는 Pub/Sub(발행/구독) 패턴에 사용됩니다.

Redis Pub/Sub은 마치 라디오 방송처럼, 한 서버가 메시지를 발행하면 구독 중인 모든 서버가 받을 수 있습니다. 왜 두 개의 클라이언트를 사용할까요?

Redis의 Pub/Sub은 구독 모드와 일반 명령 모드를 동시에 사용할 수 없기 때문입니다. 그래서 하나는 발행용, 하나는 구독용으로 분리합니다.

dataClient는 일반 데이터 저장용으로, 사용자 정보 같은 것을 저장합니다. 그 다음으로, Socket.IO에 Redis 어댑터를 연결합니다.

이것이 마법이 일어나는 부분입니다. io.adapter(createAdapter(pubClient, subClient))를 설정하면, Socket.IO는 메시지를 보낼 때 자동으로 Redis를 통해 다른 서버로도 전달합니다.

예를 들어, 서버1에서 io.to('user123').emit('message', data)를 호출하면, user123이 서버2에 연결되어 있어도 메시지가 도착합니다. 이것은 Socket.IO가 내부적으로 Redis Pub/Sub을 사용하여 모든 서버에 메시지를 브로드캐스트하기 때문입니다.

사용자가 연결되면 dataClient.hSet으로 사용자 정보를 Redis의 해시 맵에 저장합니다. 'users'라는 키에 사용자 ID를 필드로 하여 정보를 저장합니다.

이렇게 하면 어떤 서버든 dataClient.hGetAll('users')로 모든 활성 사용자 목록을 가져올 수 있습니다. SERVER_ID 환경변수는 각 서버를 구분하기 위한 것으로, 디버깅할 때 어느 서버에 문제가 있는지 파악하는 데 유용합니다.

WebRTC offer를 전달하는 부분을 보면, io.to(to).emit() 호출이 매우 단순합니다. 복잡한 로직 없이 평범하게 메시지를 보내면, Redis 어댑터가 알아서 다른 서버에도 전달합니다.

이것이 어댑터 패턴의 장점입니다. 코드는 단일 서버처럼 작성하지만, 실제로는 여러 서버에서 작동합니다.

사용자가 연결을 끊으면 Redis에서 정보를 제거합니다. 이렇게 하지 않으면 "유령 사용자"가 쌓여서 메모리가 낭비됩니다.

실제 프로덕션에서는 expire(만료 시간)를 설정하여, 연결이 끊긴 지 일정 시간이 지나면 자동으로 삭제되게 할 수도 있습니다. 여러분이 이 코드를 사용하면 서버를 쉽게 추가할 수 있습니다.

같은 코드로 서버를 여러 개 실행하고, 모두 같은 Redis에 연결하기만 하면 됩니다. 로드밸런서가 트래픽을 분산하면, 사용자들은 여러 서버에 분산되지만 서로 통신할 수 있습니다.

Docker Compose나 Kubernetes를 사용하면 이것을 자동화할 수 있습니다.

실전 팁

💡 Redis를 단일 장애점(single point of failure)으로 만들지 마세요. Redis Sentinel이나 Redis Cluster를 사용하여 Redis 자체도 고가용성을 확보하세요. Redis가 다운되면 모든 서버가 고립됩니다.

💡 Redis의 메모리 사용량을 모니터링하세요. 모든 세션 정보를 Redis에 저장하면 메모리가 빠르게 찹니다. TTL(Time To Live)을 설정하여 오래된 데이터는 자동 삭제되게 하세요.

💡 서버 ID를 로그에 포함시키세요. console.log에 process.env.SERVER_ID를 함께 출력하면, 문제가 특정 서버에서만 발생하는지 쉽게 파악할 수 있습니다.

💡 health check 엔드포인트에서 Redis 연결 상태도 확인하세요. 서버는 살아있지만 Redis와의 연결이 끊긴 상태라면, 로드밸런서가 해당 서버를 제외해야 합니다.

💡 로컬 개발 환경에서도 Redis를 사용하세요. docker-compose로 Redis를 쉽게 실행할 수 있습니다. 개발 환경과 프로덕션 환경을 비슷하게 유지하면 예상치 못한 문제를 줄일 수 있습니다.

---

6. 모니터링 및 로깅

시작하며

여러분의 WebRTC 서비스를 프로덕션에 배포했는데, 갑자기 일부 사용자들이 "연결이 안 돼요"라고 연락합니다. 하지만 여러분이 테스트하면 잘 작동합니다.

무엇이 문제일까요? 어디서부터 찾아봐야 할까요?

로그를 보려고 하니 수천 줄의 메시지 속에서 중요한 정보를 찾기가 불가능합니다. 이런 문제는 모니터링과 로깅 시스템이 제대로 갖춰지지 않았을 때 발생합니다.

애플리케이션이 무슨 일을 하고 있는지, 어디서 문제가 생겼는지 알 수 없다면, 문제 해결은 운에 맡길 수밖에 없습니다. 특히 WebRTC처럼 실시간 통신을 다루는 서비스는 네트워크 상태, 서버 부하, 연결 품질 등 모니터링해야 할 것이 매우 많습니다.

바로 이럴 때 필요한 것이 체계적인 모니터링과 로깅 시스템입니다. 모니터링은 현재 시스템의 건강 상태를 실시간으로 보여주는 계기판 같은 것입니다.

로깅은 문제가 생겼을 때 원인을 추적할 수 있는 블랙박스 역할을 합니다. 이 둘을 제대로 갖추면 문제를 빠르게 발견하고, 사용자가 불편을 겪기 전에 미리 대응할 수 있습니다.

개요

간단히 말해서, 모니터링은 시스템의 현재 상태를 측정하고 시각화하는 것이고, 로깅은 시스템에서 일어나는 이벤트를 기록하는 것입니다. 모니터링은 "지금 무슨 일이 일어나고 있나요?"에 답하고, 로깅은 "왜 이런 일이 일어났나요?"에 답합니다.

WebRTC 애플리케이션에서는 여러 지표를 모니터링해야 합니다. 서버 측에서는 CPU, 메모리, 활성 연결 수, TURN 서버의 대역폭 사용량 등을 추적합니다.

클라이언트 측에서는 연결 품질(패킷 손실, 지터, 레이턴시), 비디오 해상도, 프레임 레이트 등을 수집합니다. 이러한 데이터를 통해 사용자 경험을 정량적으로 측정하고 개선할 수 있습니다.

기존에는 console.log로 로그를 남기고 서버에 SSH로 접속해서 텍스트 파일을 뒤지는 원시적인 방법을 사용했다면, 이제는 Prometheus + Grafana, ELK Stack(Elasticsearch, Logstash, Kibana) 같은 전문 도구를 사용합니다. 모니터링과 로깅의 핵심 특징은 세 가지입니다.

첫째, 중앙 집중화로 여러 서버의 로그와 지표를 한 곳에서 볼 수 있습니다. 둘째, 알림(alerting) 기능으로 문제가 생기면 자동으로 알려줍니다.

셋째, 시각화로 복잡한 데이터를 직관적인 차트로 표현합니다. 이러한 특징들이 중요한 이유는 프로덕션 환경에서는 예상치 못한 문제가 항상 발생하기 때문입니다.

좋은 모니터링 시스템은 문제를 조기에 발견하여 큰 장애로 번지는 것을 막아줍니다.

코드 예제

// logger.js - 구조화된 로깅 시스템 (winston + ELK Stack 연동)
const winston = require('winston');
const { ElasticsearchTransport } = require('winston-elasticsearch');

// Elasticsearch 연결 설정
const esTransport = new ElasticsearchTransport({
  level: 'info',
  clientOpts: { node: 'http://elasticsearch:9200' },
  index: 'webrtc-logs'
});

// 로거 생성
const logger = winston.createLogger({
  level: process.env.LOG_LEVEL || 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.errors({ stack: true }),
    winston.format.json()  // 구조화된 JSON 로그
  ),
  defaultMeta: {
    service: 'signaling-server',
    server_id: process.env.SERVER_ID,
    environment: process.env.NODE_ENV
  },
  transports: [
    // 콘솔 출력 (개발 환경)
    new winston.transports.Console({
      format: winston.format.simple()
    }),
    // 파일 저장 (백업용)
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' }),
    // Elasticsearch로 전송 (검색 및 분석용)
    esTransport
  ]
});

// 사용 예시
logger.info('User connected', {
  user_id: 'user123',
  connection_type: 'websocket',
  ip: '192.168.1.100'
});

logger.error('WebRTC connection failed', {
  user_id: 'user456',
  error_type: 'ICE_FAILURE',
  ice_candidates: 0,
  turn_server: 'turn.example.com'
});

// Prometheus 메트릭 수집
const promClient = require('prom-client');
const register = new promClient.Registry();

// 커스텀 메트릭 정의
const activeConnections = new promClient.Gauge({
  name: 'webrtc_active_connections',
  help: '현재 활성 WebRTC 연결 수',
  registers: [register]
});

const turnBandwidth = new promClient.Gauge({
  name: 'turn_bandwidth_mbps',
  help: 'TURN 서버 대역폭 사용량 (Mbps)',
  labelNames: ['server'],
  registers: [register]
});

// 메트릭 업데이트 (실제 값은 애플리케이션 로직에서 가져옴)
activeConnections.set(150);
turnBandwidth.set({ server: 'turn1' }, 45.3);

// Prometheus가 메트릭을 수집할 수 있는 엔드포인트
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', register.contentType);
  res.end(await register.metrics());
});

module.exports = logger;

설명

이것이 하는 일: 이 코드는 두 가지 핵심 기능을 제공합니다. 첫째, winston을 사용하여 구조화된 로그를 여러 곳에 기록합니다.

둘째, Prometheus 클라이언트로 시스템 메트릭을 수집하여 모니터링 시스템에 제공합니다. 첫 번째로, winston 로거를 설정합니다.

winston은 Node.js에서 가장 인기 있는 로깅 라이브러리로, 다양한 "운송 수단(transports)"을 지원합니다. 운송 수단이란 로그를 어디에 기록할지를 의미합니다.

이 코드는 세 가지 운송 수단을 사용합니다: 콘솔(개발할 때 바로 보기 위해), 파일(백업용), Elasticsearch(검색하고 분석하기 위해). 마치 중요한 편지를 원본은 금고에 보관하고, 사본은 파일에 넣고, 디지털 사본은 클라우드에 올리는 것과 비슷합니다.

format 설정이 매우 중요합니다. winston.format.json()은 로그를 JSON 형식으로 저장합니다.

왜 JSON일까요? JSON은 구조화된 데이터이기 때문에 나중에 검색하고 필터링하기가 훨씬 쉽습니다.

예를 들어, "user_id가 user123인 모든 에러 로그를 찾아줘"라는 쿼리를 Elasticsearch에서 간단히 실행할 수 있습니다. 텍스트 로그였다면 정규표현식으로 파싱해야 해서 복잡하고 느립니다.

defaultMeta는 모든 로그에 자동으로 추가되는 정보입니다. 서비스 이름, 서버 ID, 환경(개발/스테이징/프로덕션)을 기록합니다.

여러 서버에서 로그가 섞일 때, 어느 서버에서 나온 로그인지 구분할 수 있어야 합니다. 마치 회사에서 메일을 보낼 때 부서와 이름을 자동으로 서명에 포함하는 것과 같습니다.

로그를 남길 때는 구조화된 데이터를 함께 기록합니다. logger.error('WebRTC connection failed', { user_id, error_type, ice_candidates })처럼 에러 메시지와 함께 관련 컨텍스트를 JSON 객체로 전달합니다.

이렇게 하면 나중에 "ICE_FAILURE 타입의 에러가 얼마나 자주 발생하나?"를 쉽게 분석할 수 있습니다. Prometheus 메트릭은 다른 방식으로 동작합니다.

로그는 개별 이벤트를 기록하는 반면, 메트릭은 숫자 값을 측정합니다. Gauge는 현재 값을 나타내는 메트릭 타입입니다(온도계처럼).

활성 연결 수나 대역폭 사용량처럼 오르락내리락하는 값에 적합합니다. Counter(계속 증가하는 값), Histogram(분포를 측정) 같은 다른 타입도 있습니다.

/metrics 엔드포인트는 Prometheus 서버가 주기적으로 방문하여 메트릭을 수집하는 곳입니다. Prometheus는 "pull" 방식으로 동작합니다.

애플리케이션이 Prometheus에 데이터를 보내는 것이 아니라, Prometheus가 주기적으로(예: 15초마다) 각 서버의 /metrics를 방문하여 데이터를 가져갑니다. 이렇게 수집된 데이터는 Grafana 같은 도구로 시각화할 수 있습니다.

여러분이 이 시스템을 사용하면 실시간으로 서비스 상태를 파악할 수 있습니다. Grafana 대시보드에서 활성 연결 수가 갑자기 떨어지는 것을 발견하면, Kibana에서 해당 시간대의 에러 로그를 검색하여 원인을 찾을 수 있습니다.

또한 알림 규칙을 설정하여, 에러 발생률이 1분에 10건을 넘으면 Slack이나 이메일로 자동 알림을 받을 수 있습니다.

실전 팁

💡 로그 레벨을 적절히 사용하세요. debug는 개발 중에만, info는 중요한 이벤트, warn은 잠재적 문제, error는 실제 문제입니다. 프로덕션에서 debug 레벨을 켜두면 디스크가 금방 찹니다.

💡 민감한 정보(비밀번호, 토큰, 개인정보)는 절대 로그에 남기지 마세요. logger.info('User login', { password: '...' })는 보안 사고입니다. 로그는 누구나 볼 수 있다고 가정하세요.

💡 correlation ID를 사용하세요. 하나의 요청이 여러 서버를 거쳐갈 때, 같은 ID를 모든 로그에 포함시키면 전체 흐름을 추적할 수 있습니다. 마치 택배 송장번호로 배송 과정을 추적하는 것처럼요.

💡 알림 피로(alert fatigue)를 조심하세요. 너무 많은 알림을 설정하면 중요한 알림을 놓치게 됩니다. 정말 중요한 것만 알림을 설정하고, 나머지는 대시보드에서 확인하세요.

💡 로그 로테이션을 설정하세요. 로그 파일이 무한정 커지면 디스크가 가득 차서 서버가 다운됩니다. 매일 또는 파일 크기가 일정 이상이면 새 파일을 만들고, 오래된 파일은 압축하거나 삭제하세요.

---