🟨 2-32. 실제 서비스 적용 사례 — Next.js + Vercel + Sentry + Slack으로 자동화 구축하기

---

이 구성이 왜 필요한가

프론트엔드 프로젝트는 배포 자체보다 배포 이후 상태를 계속 추적하는 일이 더 어렵습니다.

실제 운영에서는 이런 문제가 자주 생깁니다.

• 배포는 정상적으로 끝났는데 성능이 갑자기 떨어짐
• 특정 환경에서만 렌더링 오류가 발생함
• 사용자 경험 지표가 나빠졌는데 개발자가 늦게 알아차림
• 에러는 쌓이는데 누가 언제 확인해야 하는지 흐려짐

이런 상황을 줄이려면 배포, 성능 측정, 오류 추적, 알림이 하나의 흐름으로 연결되어 있어야 합니다.

이번 글에서는 Next.js + Vercel + Lighthouse CI + Sentry + Slack 조합으로, 배포 이후 상태를 자동으로 확인하고 팀에 바로 공유할 수 있는 프론트엔드 모니터링 파이프라인을 구성하는 방법을 정리합니다.

---

1. 전체 구조 개요

이번에 구축할 시스템은 다음 흐름으로 작동합니다.

1️⃣ GitHub에 코드 푸시
2️⃣ GitHub Actions에서 빌드 및 테스트 실행
3️⃣ Lighthouse CI로 배포 전 성능 점검
4️⃣ Vercel로 자동 배포
5️⃣ 배포된 서비스에서 Web Vitals와 Sentry로 성능·에러 모니터링
6️⃣ 결과 요약을 Slack으로 자동 전송

이 구조의 핵심은 “배포 후 사람이 직접 확인하지 않아도 상태를 바로 알 수 있게 만드는 것”입니다.

즉, 단순 자동 배포가 아니라 배포 → 측정 → 알림 → 개선까지 이어지는 운영 루프를 만드는 것이 목적입니다.

---

2. 어떤 역할을 누가 맡는가

도구가 많아 보이지만, 역할을 나누면 구조는 생각보다 단순합니다.

• GitHub Actions: 빌드, 테스트, 자동화 파이프라인 실행
• Lighthouse CI: 배포 전 성능 품질 점검
• Vercel: 실제 서비스 배포
• Sentry: 런타임 에러 및 프론트엔드 성능 추적
• Web Vitals: 실제 사용자 기준 핵심 성능 지표 수집
• Slack: 결과를 팀이 바로 볼 수 있도록 알림 전송

이 역할 분리가 잘 되어 있어야, 나중에 문제가 생겼을 때 어디에서 확인해야 하는지도 명확해집니다.

---

3. 프로젝트 준비

1) Next.js 설치

npx create-next-app@latest performance-monitoring-demo
cd performance-monitoring-demo

2) 의존성 추가

npm install @sentry/nextjs web-vitals @slack/web-api
npm install -D @lhci/cli

각 패키지의 역할은 아래와 같습니다.

• @lhci/cli: Lighthouse CI 자동 실행
• @sentry/nextjs: 에러 및 성능 추적
• web-vitals: 실제 사용자 기준 성능 지표 수집
• @slack/web-api: Slack 자동 리포트 전송

---

4. Sentry 설정

Sentry는 이 구조에서 “문제가 생겼을 때 가장 먼저 보는 곳”이 됩니다. 배포 후 오류 추적뿐 아니라 성능 문제의 원인을 좁히는 데도 유용합니다.

sentry.client.config.js

import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 1.0,
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0,
});

여기서 tracesSampleRate는 성능 데이터 수집 비율이고, 너무 높게 잡으면 데이터량이 많아질 수 있으므로 운영 단계에서는 트래픽 규모를 보고 조정하는 편이 좋습니다.

next.config.js

const { withSentryConfig } = require("@sentry/nextjs");

const moduleExports = {
  reactStrictMode: true,
  swcMinify: true,
};

const sentryWebpackPluginOptions = {
  silent: true,
};

module.exports = withSentryConfig(moduleExports, sentryWebpackPluginOptions);

DSN 값은 환경변수로 분리하고, 실제 운영 환경에서는 민감 정보가 클라이언트에 노출되는 범위를 꼭 점검해야 합니다.

---

5. Web Vitals 측정

Lighthouse는 테스트 환경 기준 성능을 보여주지만, 실제 사용자 환경은 또 다릅니다. 그래서 Web Vitals를 함께 수집해야 배포 후 상태를 더 현실적으로 볼 수 있습니다.

_app.tsx에 추가

import { getCLS, getFID, getLCP } from 'web-vitals';

export function reportWebVitals(metric) {
  fetch('/api/vitals', {
    method: 'POST',
    body: JSON.stringify(metric),
    keepalive: true,
  });
}

이렇게 하면 브라우저가 페이지를 렌더링할 때 LCP, FID, CLS 같은 핵심 지표를 수집해 서버로 전송할 수 있습니다.

---

6. Web Vitals 수집 API

/pages/api/vitals.js

export default async function handler(req, res) {
  const metric = JSON.parse(req.body);

  console.log('Received Web Vital:', metric);

  // 예시: Sentry에 함께 전송
  await fetch('https://sentry.io/api/YOUR_PROJECT_ID/store/', {
    method: 'POST',
    headers: {
      'Authorization': `DSN ${process.env.NEXT_PUBLIC_SENTRY_DSN}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      message: `Web Vital: ${metric.name}`,
      level: 'info',
      extra: metric,
    }),
  });

  res.status(200).json({ success: true });
}

이 API는 단순 로그 수집용으로 시작해도 충분합니다. 중요한 건 “배포 후 실제 사용자 성능 데이터를 계속 쌓는다”는 점입니다.

초기에는 서버 로그만 남기고, 이후에 Sentry나 별도 저장소로 확장하는 방식도 현실적입니다.

---

7. Lighthouse CI 설정

Lighthouse CI는 배포 전 단계에서 성능 이상 징후를 미리 발견하는 역할을 합니다. 특히 큰 이미지, 불필요한 스크립트, 렌더링 차단 리소스 같은 문제를 조기에 볼 수 있어 유용합니다.

.github/workflows/lighthouse.yml

name: Lighthouse CI
on: [push]

jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/cli
          lhci autorun --upload.target=temporary-public-storage

이렇게 설정하면 푸시 시점마다 Lighthouse를 자동 실행해 배포 전 성능 품질을 확인할 수 있습니다.

---

8. Slack 알림 연동

측정 데이터를 수집해도 팀이 안 보면 의미가 없습니다. 그래서 최종 결과를 Slack으로 보내면, 개발자나 팀원이 배포 직후 상태를 빠르게 공유할 수 있습니다.

/pages/api/report.js

import { WebClient } from '@slack/web-api';
const slack = new WebClient(process.env.SLACK_TOKEN);

export default async function handler(req, res) {
  const { performance, errors } = JSON.parse(req.body);

  const msg = `
🚀 *배포 완료 알림*
- 성능 점수: ${performance.score}
- 주요 오류: ${errors.length ? errors.join(', ') : '없음'}
`;

  await slack.chat.postMessage({
    channel: '#performance-alerts',
    text: msg,
  });

  res.status(200).json({ success: true });
}

Slack 알림의 장점은 단순합니다. 누군가 직접 대시보드를 열어보지 않아도 상태를 빠르게 알 수 있다는 점입니다.

---

9. Vercel 환경변수

NEXT_PUBLIC_SENTRY_DSN	Sentry DSN
SLACK_TOKEN	Slack API 토큰
SLACK_CHANNEL	알림 채널명
VERCEL_ENV	Vercel 환경값 (production/staging 등)

이 구조에서 민감 정보는 반드시 환경변수로 분리해야 합니다. 특히 Slack 토큰과 DSN, 외부 API 키는 Git에 직접 커밋하지 않는 것이 기본입니다.

---

10. 자동 보고 파이프라인 완성

GitHub Actions + Slack 연동

- name: Send Slack Report
  run: |
    curl -X POST https://yourdomain.com/api/report \
    -H "Content-Type: application/json" \
    -d '{"performance": {"score": 95}, "errors": []}'

이제 배포가 끝나면 자동으로 Slack 리포트가 전송되고, Lighthouse 결과와 Sentry 에러 정보를 함께 확인할 수 있습니다.

---

11. 결과 예시

Slack 메시지는 아래처럼 구성할 수 있습니다.

🚀 배포 완료 알림
- 성능 점수: 97
- 주요 오류: 없음
- Lighthouse: LCP 1.8s, FID 75ms, CLS 0.03

이렇게 되면 프론트엔드 배포 이후 상태를 바로 확인할 수 있는 루프가 생깁니다. 문제가 생기면 Slack에서 먼저 징후를 보고, 자세한 원인은 Sentry에서 추적하는 흐름으로 이어집니다.

---

12. 실무에서 자주 하는 개선 포인트

• Slack 메시지에 Lighthouse Report 링크 추가
• LCP > 3s, CLS > 0.1 같은 기준치 초과 시 경고 메시지 분리
• Vercel Preview와 Production 채널을 분리해 알림 노이즈 줄이기
• 성능 추이를 Notion이나 별도 DB에 기록해 추세 관리하기

처음부터 완벽한 파이프라인을 만들 필요는 없습니다. 가장 중요한 건 배포 후 상태를 눈으로 볼 수 있는 구조를 먼저 만드는 것입니다.

---

13. 이런 팀에 특히 잘 맞는다

• 배포 후 문제가 생겨도 나중에야 발견하는 팀
• 성능과 오류를 수동으로 확인하고 있는 팀
• 프론트엔드 운영 품질을 조금 더 체계적으로 관리하고 싶은 팀
• 배포 자동화는 되어 있지만 관측 가능성은 부족한 팀

특히 스타트업이나 소규모 팀에서는 대규모 관측 인프라를 처음부터 만들기 어렵기 때문에, 이런 조합이 현실적인 출발점이 될 수 있습니다.

---

14. 마무리

프론트엔드 운영은 이제 단순히 “배포되었는가”만 확인하는 단계로는 부족합니다.

중요한 것은 배포 이후 성능이 유지되는지, 오류가 생기지 않는지, 사용자 경험이 나빠지지 않는지를 계속 확인하는 것입니다.

이 글에서 다룬 Next.js + Vercel + Lighthouse CI + Sentry + Slack 조합은 그런 운영 루프를 비교적 가볍게 만드는 방법입니다.

빠른 페이지를 만드는 것은 기술이지만,
빠른 상태를 유지하는 것은 시스템입니다.

즉, 프론트엔드 개발도 이제는 개발 → 배포 → 측정 → 피드백 → 개선으로 이어지는 구조를 갖추는 쪽이 훨씬 더 현실적인 운영 방식입니다.