Vibeollio
← 블로그 목록
로깅모니터링프로덕션디버깅에러추적

로깅 및 모니터링: 콘솔 로그 vs 외부 서비스 vs 자체 로그 수집, 프로덕션 버그를 빨리 찾는 방법

프로덕션 버그를 빠르게 찾기 위한 로깅 전략을 비교합니다. 콘솔 로그, 외부 서비스, 자체 수집 방식의 장단점과 무료 도구 활용법을 실제 예시로 설명합니다.

Vibeollio 팀-

개발 단계와 프로덕션은 다르다

개발 중에는 브라우저 개발자 도구나 터미널을 열어두고 에러를 즉시 확인할 수 있습니다. 하지만 실제 사용자가 접속하는 프로덕션 환경에서는 어떤 일이 일어나는지 직접 볼 수 없습니다. 사용자가 "어제 오후 3시쯤 버튼을 눌렀는데 안 됐어요"라고 보고할 때, 그 순간 서버에서 무슨 일이 있었는지 추적할 방법이 필요합니다.

로깅과 모니터링은 단순히 에러를 기록하는 것이 아니라, 문제를 빠르게 발견하고 원인을 파악하는 체계입니다. 이 글에서는 세 가지 접근 방식을 비교하고, 각 상황에 맞는 도구를 소개합니다.

콘솔 로그: 가장 간단하지만 가장 위험한 방법

가장 흔한 실수는 console.log()를 프로덕션 코드에 남겨두는 것입니다.

// ❌ 나쁜 예
function processPayment(amount) {
  console.log('결제 시작:', amount);
  // 결제 로직
  console.log('결제 완료');
}

콘솔 로그는 세 가지 문제가 있습니다:

  1. 사용자만 볼 수 있음 — 개발자는 사용자 환경에서 콘솔을 열 수 없으므로 문제가 발생해도 알 수 없습니다.
  2. 저장되지 않음 — 페이지를 새로고침하면 로그가 사라집니다.
  3. 성능 영향 — 대량의 로그는 메모리를 소비하고 사용자 기기를 느리게 만듭니다.

콘솔 로그는 개발 단계에서 가장 유용합니다. 프로덕션의 브라우저 콘솔 로그는 개발자가 볼 수 없어 의존할 수 없고, 서버의 console.log도 호스팅 플랫폼이 로그를 보관하는 범위 안에서만 확인할 수 있습니다.

외부 서비스: 규모 있는 팀을 위한 선택

Sentry, LogRocket, Datadog 같은 외부 서비스는 에러 발생 시 자동으로 스택 트레이스, 사용자 정보, 브라우저 환경을 수집합니다.

// Sentry 예시
import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: "https://[email protected]/project-id",
  environment: "production",
});

try {
  riskyFunction();
} catch (error) {
  Sentry.captureException(error);
}

장점:

  • 자동 에러 감지 및 알림
  • 세션 재생으로 사용자 행동 추적 가능
  • 대시보드에서 실시간 모니터링

단점:

  • 유료 구독료가 듭니다 (사용량·팀 규모에 따라 증가하며, 무료 플랜을 제공하는 서비스도 있음)
  • 초기 설정에 시간 필요
  • 민감한 데이터(결제 정보 등)는 제외해야 함

언제 쓸까: 사용자가 늘어 직접 로그를 관리하기 부담스러워졌거나, 금융/의료 서비스처럼 신뢰성이 중요한 경우.

자체 로그 수집: 비용 최소화와 통제력

서버에 로그를 저장하고 직접 분석하는 방식입니다. 초기 투자는 크지만 장기적으로 비용을 절감할 수 있습니다.

// 클라이언트에서 서버로 로그 전송
function sendLog(level, message, context = {}) {
  if (process.env.NODE_ENV === 'production') {
    fetch('/api/logs', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        timestamp: new Date().toISOString(),
        level, // 'error', 'warn', 'info'
        message,
        userAgent: navigator.userAgent,
        url: window.location.href,
        context,
      }),
    }).catch(() => {}); // 로그 전송 실패는 무시
  }
}

// 사용 예시
try {
  const result = await fetchUserData();
} catch (error) {
  sendLog('error', 'Failed to fetch user data', {
    errorMessage: error.message,
    userId: currentUser?.id,
  });
}

서버 측 처리 (Node.js):

app.post('/api/logs', (req, res) => {
  const log = req.body;
  
  // 클라이언트가 보낸 값은 파일 이름에 쓰기 전에 반드시 검증한다
  if (!['error', 'warn', 'info'].includes(log.level)) {
    return res.status(400).json({ ok: false });
  }
  
  // 파일에 저장 (파일 이름의 날짜는 UTC 기준)
  fs.appendFileSync(
    `logs/${log.level}-${new Date().toISOString().split('T')[0]}.log`,
    JSON.stringify(log) + '\n'
  );
  
  // 에러 레벨은 즉시 알림
  if (log.level === 'error') {
    sendSlackNotification(log);
  }
  
  res.status(200).json({ ok: true });
});

장점:

  • 완전한 데이터 소유권
  • 민감한 정보 제어 가능
  • 장기적으로 비용 저렴

단점:

  • 초기 개발 시간 필요
  • 로그 저장소(데이터베이스 또는 파일) 관리 필요
  • 대규모 트래픽 시 확장성 고려 필수

언제 쓸까: 초기 스타트업이거나 로그 데이터가 민감한 경우.

세 가지 방식 비교 표

방식 비용 설정 난이도 실시간성 데이터 제어
콘솔 로그 무료 매우 쉬움 없음 높음
외부 서비스 유료 구독 (무료 플랜도 있음) 중간 높음 낮음
자체 수집 서버 비용만 어려움 중간 매우 높음

프로덕션 버그를 빨리 찾는 체크리스트

  1. 에러 발생 시점 기록 — 타임스탬프는 필수. 서버와 클라이언트 시간이 맞는지 확인하세요.
  2. 사용자 정보 포함 — 사용자 ID나 세션 ID를 기록하면 특정 사용자의 행동 추적 가능.
  3. 환경 정보 수집 — 브라우저, OS, 네트워크 상태 등이 버그 재현에 도움이 됩니다.
  4. 민감 데이터 제외 — 비밀번호, 신용카드 번호, 개인 식별 정보는 절대 로깅하지 마세요.
  5. 로그 레벨 구분 — error, warn, info를 구분하면 중요한 문제를 빠르게 찾을 수 있습니다.

무료 또는 저비용 도구 추천

  • ELK Stack (Elasticsearch, Logstash, Kibana) — 오픈소스, 자체 서버 필요
  • Loki (Grafana) — 경량 로그 수집, Prometheus와 연동 가능
  • Winston (Node.js) — 파일 및 콘솔에 로그 저장하는 라이브러리
  • Pino — 고성능 JSON 로거

프로덕션 환경에서 로그를 남기는 것이 정말 필요한가요?

네, 필수입니다. 프로덕션 버그는 개발 단계에서 발견되지 않는 경우가 많습니다. 네트워크 지연, 특정 브라우저 호환성, 동시성 문제, 메모리 누수 등은 실제 사용자 환경에서만 나타납니다. 로그 없이는 문제를 해결할 수 없습니다.

작은 프로젝트는 외부 서비스를 써야 하나요?

아닙니다. 사용자가 적은 초기에는 자체 로그 수집으로도 충분할 수 있습니다. 무료 플랜을 제공하는 외부 서비스도 있으니 설정 부담과 비교해서 고르세요. 간단한 fetch 요청과 파일 저장만으로 기본적인 에러 추적이 가능합니다. 외부 서비스는 규모가 커질수록 가치가 높아집니다.

로그 저장소는 얼마나 오래 보관해야 하나요?

너무 짧지 않게 보관하세요. 사용자가 "지난주에 버그를 경험했다"고 보고할 때 그 시점의 로그를 조회할 수 있어야 합니다. 다만 로그에 사용자 ID 같은 개인정보가 들어간다면 필요한 기간만 보관하고 지우세요. 저장 공간이 부족하면 중요한 에러 로그만 별도로 아카이빙하세요.

결론

프로덕션 환경에서의 로깅은 사후 대응이 아니라 사전 예방입니다. 버그가 발생했을 때 빠르게 원인을 파악할 수 있으면, 사용자 이탈을 최소화하고 신뢰를 유지할 수 있습니다.

초기 단계에는 자체 로그 수집으로 시작하고, 팀이 커지거나 복잡성이 증가하면 외부 서비스로 전환하는 것이 현명합니다. 중요한 것은 지금 당장 어떤 형태든 로깅을 시작하는 것입니다.

당신이 만든 프로젝트도 배포 후 로깅 전략이 필요하다면, Vibeollio에 프로젝트를 등록하고 커뮤니티 피드백을 받아보세요. 다른 개발자들의 모니터링 경험과 팁을 댓글로 나눌 수 있습니다.

다른 글 읽기