보안 강화 및 테스트 완벽 가이드

웹 애플리케이션의 보안 취약점을 방어하고 안정적인 서비스를 제공하기 위한 실전 보안 기법과 테스트 전략을 다룹니다. XSS, CSRF부터 DDoS 방어, Rate Limiting까지 실무에서 바로 적용 가능한 보안 솔루션을 제공합니다.

---

목차

1. XSS_방어_구현
2. CSRF_보호_설정
3. Rate_Limiting_적용
4. DDoS_방어_전략
5. Jest_테스트_환경_설정
6. API_통합_테스트
7. 에러_핸들링_및_로깅

---

1. XSS_방어_구현

시작하며

여러분이 사용자 댓글 기능을 개발했는데, 어느 날 갑자기 다른 사용자들의 화면에 이상한 팝업이 뜨기 시작했다면? 누군가 댓글에 악의적인 스크립트를 넣어서 다른 사용자들의 브라우저에서 실행되고 있는 겁니다.

이런 공격을 XSS(Cross-Site Scripting) 공격이라고 부릅니다. 마치 여러분의 집에 손님이 와서 몰래 도청 장치를 설치하고 가는 것과 비슷해요.

사용자가 입력한 데이터를 그대로 화면에 표시하면, 악의적인 코드가 다른 사용자의 브라우저에서 실행될 수 있습니다. 이런 보안 위협으로부터 사용자를 보호하기 위해 반드시 필요한 것이 XSS 방어입니다.

사용자 입력을 안전하게 처리하여 악의적인 스크립트가 실행되지 않도록 차단하는 기술이죠.

개요

간단히 말해서, XSS 방어는 사용자가 입력한 데이터에 포함된 위험한 코드를 무력화시키는 것입니다. 웹 애플리케이션에서 사용자 입력을 받는 모든 곳은 잠재적인 공격 지점이 될 수 있습니다.

댓글, 게시글, 검색어, 사용자 이름 등 어디든 악의적인 스크립트가 숨어들 수 있죠. 예를 들어, 게시판에 <script>alert('해킹!')</script> 같은 코드를 입력하면, 이를 보는 모든 사용자의 브라우저에서 경고창이 뜨게 됩니다.

기존에는 단순히 HTML 태그를 제거하는 방식을 사용했다면, 현대적인 방어 기법은 입력값을 이스케이프(escape)하거나 sanitize하여 안전하게 만듭니다. XSS 방어의 핵심은 크게 세 가지입니다: 첫째, 모든 사용자 입력을 신뢰하지 않기.

둘째, 출력 시 적절히 인코딩하기. 셋째, Content Security Policy(CSP) 헤더로 스크립트 실행 제한하기.

이러한 다층 방어 전략이 여러분의 애플리케이션을 안전하게 지켜줍니다.

코드 예제

// DOMPurify를 사용한 XSS 방어
import DOMPurify from 'dompurify';

// 사용자 입력 sanitize
function sanitizeInput(userInput) {
  // HTML을 안전하게 정제
  const clean = DOMPurify.sanitize(userInput, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a'],
    ALLOWED_ATTR: ['href']
  });
  return clean;
}

// React에서 안전하게 렌더링
function CommentDisplay({ comment }) {
  const safeComment = sanitizeInput(comment);
  // dangerouslySetInnerHTML 대신 안전한 방식 사용
  return <div>{safeComment}</div>;
}

설명

이 코드가 하는 일은 사용자가 입력한 데이터에서 위험한 요소를 제거하고 안전한 HTML만 남기는 것입니다. 첫 번째로, DOMPurify 라이브러리를 import합니다.

이 라이브러리는 수많은 XSS 공격 패턴을 알고 있어서, 위험한 코드를 자동으로 탐지하고 제거해줍니다. 마치 공항 보안 검색대처럼 위험한 물건을 걸러내는 역할을 하죠.

그 다음으로, sanitizeInput 함수에서 DOMPurify.sanitize()를 호출합니다. 여기서 ALLOWED_TAGS 옵션으로 허용할 HTML 태그를 명시합니다.

<b>, <i> 같은 안전한 서식 태그만 허용하고, <script>, <iframe> 같은 위험한 태그는 모두 제거됩니다. ALLOWED_ATTR로 허용할 속성도 제한하여, onclick 같은 이벤트 핸들러가 실행되지 않도록 막습니다.

마지막으로, React 컴포넌트에서 정제된 데이터를 안전하게 렌더링합니다. dangerouslySetInnerHTML을 사용하지 않고, 일반 텍스트로 표시하거나 sanitize된 HTML만 사용합니다.

이렇게 하면 악의적인 스크립트가 절대 실행될 수 없습니다. 여러분이 이 코드를 사용하면 사용자가 어떤 입력을 하든 안전하게 처리할 수 있습니다.

게시판, 댓글, 채팅 등 사용자 생성 콘텐츠를 다루는 모든 곳에서 데이터 유출이나 세션 탈취 같은 심각한 보안 사고를 예방할 수 있죠.

실전 팁

💡 서버와 클라이언트 양쪽에서 모두 sanitize하세요. 클라이언트 검증은 우회될 수 있으므로 서버에서 반드시 재검증해야 합니다.

💡 Content Security Policy(CSP) 헤더를 설정하여 인라인 스크립트 실행을 차단하세요. Content-Security-Policy: script-src 'self' 같은 설정으로 추가 보호층을 만들 수 있습니다.

💡 React, Vue 같은 프레임워크의 기본 이스케이프 기능을 활용하세요. JSX의 중괄호 {}는 자동으로 이스케이프되므로 안전합니다.

💡 사용자 입력을 URL에 포함시킬 때는 encodeURIComponent()를 사용하여 URL 인코딩하세요. 쿼리 파라미터를 통한 XSS 공격을 막을 수 있습니다.

💡 정기적으로 npm audit을 실행하여 사용 중인 라이브러리의 보안 취약점을 점검하세요. DOMPurify도 최신 버전으로 유지해야 새로운 공격 패턴을 방어할 수 있습니다.

---

2. CSRF_보호_설정

시작하며

여러분이 은행 사이트에 로그인한 상태에서 이메일을 확인하다가, 재미있는 이미지를 클릭했는데 갑자기 계좌에서 돈이 이체되었다면? 그 이미지에는 보이지 않는 악의적인 요청이 숨어 있었던 겁니다.

이런 공격을 CSRF(Cross-Site Request Forgery) 공격이라고 합니다. 마치 여러분의 서명이 찍힌 백지 수표를 누군가 훔쳐서 마음대로 금액을 채워 넣는 것과 비슷해요.

사용자가 로그인된 상태를 악용하여 사용자 모르게 요청을 보내는 공격입니다. 이런 위협으로부터 보호하기 위해 필요한 것이 CSRF 토큰입니다.

진짜 사용자가 보낸 요청인지 확인할 수 있는 비밀 암호를 만드는 것이죠.

개요

간단히 말해서, CSRF 보호는 요청마다 고유한 토큰을 생성하여 정당한 요청인지 검증하는 것입니다. 모든 상태 변경 요청(POST, PUT, DELETE)은 CSRF 공격의 대상이 될 수 있습니다.

사용자가 의도하지 않은 계좌 이체, 비밀번호 변경, 게시글 삭제 등이 실행될 수 있죠. 예를 들어, 악의적인 사이트에서 <img src="https://yourbank.com/transfer?to=attacker&amount=1000">를 넣으면, 로그인된 사용자의 브라우저가 자동으로 이 요청을 보내게 됩니다.

기존에는 Referer 헤더를 검사하는 방식을 사용했다면, 현대적인 방어는 CSRF 토큰과 SameSite 쿠키 속성을 함께 사용합니다. CSRF 방어의 핵심 특징은 세 가지입니다: 첫째, 예측 불가능한 토큰 생성.

둘째, 토큰을 세션과 연결하여 검증. 셋째, SameSite 쿠키 속성으로 외부 사이트에서의 쿠키 전송 차단.

이 조합이 여러분의 사용자를 CSRF 공격으로부터 안전하게 지켜줍니다.

코드 예제

// Express.js에서 csurf 미들웨어 사용
const csrf = require('csurf');
const cookieParser = require('cookie-parser');

// CSRF 보호 설정
const csrfProtection = csrf({
  cookie: {
    httpOnly: true,
    sameSite: 'strict',
    secure: true // HTTPS에서만 전송
  }
});

app.use(cookieParser());
app.use(csrfProtection);

// 폼 렌더링 시 토큰 전달
app.get('/form', (req, res) => {
  res.render('form', { csrfToken: req.csrfToken() });
});

// POST 요청 시 자동 검증
app.post('/transfer', (req, res) => {
  // 토큰이 유효하지 않으면 자동으로 403 에러
  res.send('이체 완료');
});

설명

이 코드가 하는 일은 모든 상태 변경 요청에 대해 비밀 토큰을 요구함으로써, 정당한 사용자의 요청만 처리하는 것입니다. 첫 번째로, csurf 미들웨어를 설정합니다.

cookie 옵션에서 httpOnly를 true로 설정하면 JavaScript로 쿠키를 읽을 수 없어 XSS 공격과의 결합을 막습니다. sameSite: 'strict'는 다른 도메인에서 오는 요청에 쿠키를 포함하지 않도록 하여 CSRF 공격을 원천 차단합니다.

secure: true는 HTTPS 연결에서만 토큰을 전송하여 중간자 공격을 방지합니다. 그 다음으로, GET 요청으로 폼을 렌더링할 때 req.csrfToken()을 호출하여 고유한 토큰을 생성합니다.

이 토큰은 사용자의 세션과 연결되어 있어서, 다른 사용자가 복사해서 사용할 수 없습니다. 프론트엔드에서는 이 토큰을 hidden input이나 헤더에 포함시켜 전송합니다.

마지막으로, POST 요청이 들어오면 미들웨어가 자동으로 토큰을 검증합니다. 쿠키에 저장된 토큰과 요청에 포함된 토큰을 비교하여, 일치하지 않으면 403 Forbidden 에러를 반환합니다.

악의적인 사이트는 사용자의 토큰을 알 수 없으므로 요청이 차단됩니다. 여러분이 이 코드를 사용하면 사용자가 의도하지 않은 모든 요청을 차단할 수 있습니다.

금융 거래, 비밀번호 변경, 계정 삭제 같은 중요한 작업을 안전하게 보호할 수 있죠. 특히 SameSite 속성과 함께 사용하면 이중 보호가 되어 더욱 안전합니다.

실전 팁

💡 SPA(Single Page Application)에서는 CSRF 토큰을 API 호출마다 헤더에 포함시키세요. X-CSRF-Token 같은 커스텀 헤더를 사용하면 됩니다.

💡 쿠키의 SameSite 속성을 'Strict' 또는 'Lax'로 설정하세요. 최신 브라우저에서는 이것만으로도 대부분의 CSRF 공격을 막을 수 있습니다.

💡 토큰 생성 시 암호학적으로 안전한 난수 생성기를 사용하세요. crypto.randomBytes()를 사용하면 예측 불가능한 토큰을 만들 수 있습니다.

💡 GET 요청으로 상태를 변경하지 마세요. RESTful 원칙을 지켜 POST, PUT, DELETE를 사용하면 CSRF 보호가 더 효과적입니다.

💡 CORS 설정을 엄격하게 관리하세요. credentials: 'include' 옵션과 함께 origin을 명시적으로 지정하여 신뢰할 수 있는 도메인만 허용하세요.

---

3. Rate_Limiting_적용

시작하며

여러분의 API 서버에 갑자기 초당 수천 건의 요청이 쏟아져 들어와서 정상적인 사용자들이 서비스를 이용할 수 없게 되었다면? 누군가 자동화된 봇으로 무차별 공격을 하고 있는 겁니다.

이런 상황은 서버 비용을 폭증시키고, 실제 사용자들에게 피해를 줍니다. 마치 백화점 입구에 수천 명이 한꺼번에 몰려들어 정작 물건을 사러 온 손님들이 들어갈 수 없는 것과 같아요.

무분별한 요청으로 서버 리소스가 고갈되면 서비스 전체가 마비될 수 있습니다. 이런 공격과 남용을 방지하기 위해 필요한 것이 Rate Limiting입니다.

사용자당 요청 횟수를 제한하여 서버를 보호하고 공정한 리소스 분배를 보장하는 기술이죠.

개요

간단히 말해서, Rate Limiting은 일정 시간 동안 특정 사용자가 보낼 수 있는 요청 횟수를 제한하는 것입니다. API 엔드포인트마다 적절한 제한을 설정하지 않으면 악의적인 사용자나 버그가 있는 클라이언트가 서버를 마비시킬 수 있습니다.

로그인 시도, 비밀번호 찾기, 파일 업로드 같은 민감한 작업은 특히 더 엄격한 제한이 필요하죠. 예를 들어, 로그인 API에 제한이 없으면 무차별 대입 공격(brute force)으로 사용자 계정이 뚫릴 수 있습니다.

기존에는 서버 레벨에서 단순히 연결 수를 제한했다면, 현대적인 Rate Limiting은 사용자별, IP별, API 키별로 세밀하게 제어하고 Redis 같은 빠른 저장소를 활용합니다. Rate Limiting의 핵심 전략은 네 가지입니다: 첫째, Fixed Window(고정 시간 창) - 1분에 100개 요청 허용.

둘째, Sliding Window(슬라이딩 창) - 더 정밀한 시간 계산. 셋째, Token Bucket - 일시적인 버스트 허용.

넷째, 계층적 제한 - 일반 사용자와 프리미엄 사용자 구분. 이러한 전략들이 서비스를 안정적으로 유지하면서도 사용자 경험을 해치지 않습니다.

코드 예제

// Express Rate Limit 사용
const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');
const redis = require('redis');

// Redis 클라이언트 생성
const redisClient = redis.createClient();

// API 전체 제한: 15분에 100개 요청
const apiLimiter = rateLimit({
  store: new RedisStore({ client: redisClient }),
  windowMs: 15 * 60 * 1000, // 15분
  max: 100, // 최대 100개 요청
  message: '너무 많은 요청을 보냈습니다. 나중에 다시 시도하세요.',
  standardHeaders: true, // RateLimit-* 헤더 포함
  legacyHeaders: false
});

// 로그인 엄격 제한: 15분에 5번 시도
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  skipSuccessfulRequests: true // 성공한 요청은 카운트 제외
});

app.use('/api/', apiLimiter);
app.use('/api/login', loginLimiter);

설명

이 코드가 하는 일은 각 사용자의 요청 횟수를 추적하고, 설정된 한도를 초과하면 추가 요청을 거부하는 것입니다. 첫 번째로, Redis를 Rate Limit 저장소로 설정합니다.

Redis는 메모리 기반이라 매우 빠르고, 분산 환경에서도 여러 서버가 같은 제한을 공유할 수 있습니다. 만약 서버가 여러 대라면, 각 서버가 독립적으로 카운트하는 게 아니라 Redis를 통해 전체 요청 수를 정확히 추적합니다.

그 다음으로, apiLimiter를 설정합니다. windowMs는 시간 창을 의미하고, max는 그 시간 동안 허용할 최대 요청 수입니다.

15분에 100개 요청이면 평균 초당 약 0.11개로, 정상적인 사용에는 충분하지만 봇 공격은 막을 수 있는 수준이죠. standardHeaders: true를 설정하면 응답에 RateLimit-Limit, RateLimit-Remaining 같은 헤더가 포함되어 클라이언트가 남은 요청 횟수를 알 수 있습니다.

마지막으로, 로그인 엔드포인트에는 더 엄격한 제한을 적용합니다. 15분에 5번만 시도할 수 있게 하여 무차별 대입 공격을 효과적으로 차단합니다.

skipSuccessfulRequests: true 옵션으로 성공한 로그인은 카운트에서 제외하여, 정상 사용자에게는 불편을 주지 않습니다. 여러분이 이 코드를 사용하면 서버 리소스를 보호하고 비용을 절감할 수 있습니다.

DDoS 공격, 크리덴셜 스터핑, API 남용 등 다양한 위협으로부터 안전해지고, 모든 사용자에게 공정한 서비스를 제공할 수 있죠. 또한 응답 헤더를 통해 클라이언트가 적절히 재시도 로직을 구현할 수 있습니다.

실전 팁

💡 엔드포인트마다 다른 제한을 설정하세요. 조회 API는 관대하게, 쓰기 API는 엄격하게 제한하는 것이 좋습니다.

💡 인증된 사용자와 익명 사용자를 구분하여 제한하세요. API 키를 가진 프리미엄 사용자에게는 더 높은 한도를 제공할 수 있습니다.

💡 429 Too Many Requests 응답에 Retry-After 헤더를 포함시켜 클라이언트가 언제 재시도해야 하는지 알려주세요.

💡 Rate Limit 초과 이벤트를 모니터링하고 로깅하세요. 반복적으로 제한에 걸리는 IP는 공격자일 가능성이 높으므로 추가 조치를 취할 수 있습니다.

💡 슬라이딩 윈도우 알고리즘을 사용하면 더 정밀한 제어가 가능합니다. 고정 창 방식의 경계 시점 문제를 해결할 수 있죠.

---

4. DDoS_방어_전략

시작하며

여러분의 서비스가 갑자기 수백만 개의 요청에 공격받아 서버가 완전히 다운되었다면? 전 세계 수천 대의 봇넷이 동시에 공격하는 DDoS(Distributed Denial of Service) 공격을 받은 겁니다.

이런 대규모 공격은 단순한 Rate Limiting만으로는 막을 수 없습니다. 마치 거대한 쓰나미가 밀려오는데 모래주머니로 막으려는 것과 같아요.

네트워크 대역폭이 포화되면 서버에 도달하기도 전에 서비스가 마비됩니다. 이런 치명적인 공격으로부터 서비스를 보호하기 위해 필요한 것이 다층 DDoS 방어 전략입니다.

네트워크 레벨부터 애플리케이션 레벨까지 여러 단계의 방어막을 구축하는 것이죠.

개요

간단히 말해서, DDoS 방어는 정상 트래픽과 공격 트래픽을 구분하고 악의적인 요청을 필터링하는 다층 보안 체계입니다. DDoS 공격은 크게 세 가지 유형이 있습니다: 볼륨 기반 공격(대역폭 소진), 프로토콜 공격(서버 리소스 고갈), 애플리케이션 레이어 공격(특정 기능 타겟).

각 유형마다 다른 방어 전략이 필요하죠. 예를 들어, SYN Flood 공격은 TCP 핸드셰이크를 악용하여 서버의 연결 테이블을 가득 채우고, HTTP Flood는 정상적인 HTTP 요청처럼 보이지만 대량으로 발생시켜 서버를 마비시킵니다.

기존에는 하드웨어 방화벽에만 의존했다면, 현대적인 방어는 CDN, 클라우드 기반 DDoS 방어 서비스, Rate Limiting, IP 평판 시스템을 모두 결합합니다. DDoS 방어의 핵심 전략은 다섯 가지입니다: 첫째, CDN과 캐싱으로 원본 서버 숨기기.

둘째, 클라우드 스케일링으로 트래픽 흡수. 셋째, WAF(Web Application Firewall)로 애플리케이션 레이어 방어.

넷째, IP 블랙리스트와 지리적 차단. 다섯째, 트래픽 패턴 분석과 이상 탐지.

이러한 다층 방어가 여러분의 서비스를 대규모 공격으로부터 보호합니다.

코드 예제

// Cloudflare Workers를 사용한 DDoS 방어
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const ip = request.headers.get('CF-Connecting-IP');
  const country = request.headers.get('CF-IPCountry');

  // 특정 국가 차단 (필요시)
  const blockedCountries = ['XX', 'YY'];
  if (blockedCountries.includes(country)) {
    return new Response('Access denied', { status: 403 });
  }

  // 의심스러운 User-Agent 차단
  const userAgent = request.headers.get('User-Agent') || '';
  if (userAgent.length < 10 || !userAgent.includes('Mozilla')) {
    return new Response('Invalid client', { status: 403 });
  }

  // Challenge 페이지 표시 (봇 탐지)
  const threatScore = request.cf.threatScore; // 0-100
  if (threatScore > 30) {
    // 자동화된 챌린지 표시 (CAPTCHA 등)
    return new Response('Please complete challenge', {
      status: 403,
      headers: { 'X-Threat-Score': threatScore }
    });
  }

  // 정상 요청 처리
  return fetch(request);
}

설명

이 코드가 하는 일은 모든 요청을 검사하여 봇과 공격자를 필터링하고, 정상 사용자만 서버에 도달하도록 하는 것입니다. 첫 번째로, Cloudflare Workers는 엣지 네트워크에서 실행되므로 요청이 원본 서버에 도달하기 전에 필터링됩니다.

CF-Connecting-IP와 CF-IPCountry 헤더로 요청자의 IP와 국가를 파악합니다. 만약 서비스 대상이 아닌 국가에서 대량 트래픽이 오면 지리적으로 차단할 수 있죠.

그 다음으로, User-Agent를 검사하여 의심스러운 클라이언트를 걸러냅니다. 정상적인 브라우저는 항상 상세한 User-Agent 문자열을 보내지만, 간단한 스크립트는 짧거나 없는 경우가 많습니다.

이 간단한 검사만으로도 많은 기초적인 봇을 차단할 수 있습니다. 세 번째로, Cloudflare의 위협 점수(threat score)를 활용합니다.

이 점수는 머신러닝으로 계산되며, IP 평판, 요청 패턴, 과거 공격 이력 등을 종합적으로 분석합니다. 점수가 높으면 CAPTCHA 같은 챌린지를 표시하여 실제 사람인지 확인합니다.

이렇게 하면 봇은 차단하면서도 정상 사용자는 약간의 불편만 감수하면 접근할 수 있습니다. 마지막으로, 모든 검증을 통과한 요청만 원본 서버로 전달됩니다.

이 시점에서 트래픽은 이미 99% 이상 감소했고, 남은 요청도 Rate Limiting으로 추가 제어됩니다. 여러분이 이 전략을 사용하면 초당 수백만 건의 공격도 견딜 수 있습니다.

CDN의 글로벌 네트워크가 트래픽을 분산하고, 엣지에서 대부분의 공격을 차단하므로 원본 서버는 안전하게 보호됩니다. 또한 정상 사용자의 경험은 거의 영향을 받지 않으면서도 강력한 보안을 유지할 수 있죠.

실전 팁

💡 CDN을 반드시 사용하세요. Cloudflare, AWS CloudFront, Fastly 같은 서비스는 자동 DDoS 방어 기능을 제공합니다.

💡 오리진 서버의 실제 IP를 숨기세요. CDN을 우회하여 직접 공격받지 않도록 방화벽에서 CDN IP만 허용하세요.

💡 Auto Scaling을 설정하여 트래픽 급증 시 자동으로 서버를 증설하세요. AWS, GCP, Azure 모두 지원합니다.

💡 정적 콘텐츠는 최대한 캐싱하세요. 캐시된 콘텐츠는 CDN에서 직접 응답하므로 서버 부하가 0입니다.

💡 모니터링과 알림을 설정하세요. 비정상적인 트래픽 패턴을 실시간으로 탐지하고 즉시 대응할 수 있어야 합니다.

---

5. Jest_테스트_환경_설정

시작하며

여러분이 코드를 수정했는데, 전혀 관계없어 보이는 다른 기능이 갑자기 망가졌다면? 사이드 이펙트를 예상하지 못했고, 테스트도 없어서 배포 전에 발견하지 못한 겁니다.

이런 상황은 개발자의 악몽입니다. 마치 연결된 도미노를 건드렸는데 어디까지 쓰러질지 모르는 것과 같아요.

특히 팀 프로젝트에서는 다른 사람의 코드를 수정할 때 더욱 위험하죠. 이런 위험을 미리 발견하고 안전하게 개발하기 위해 필요한 것이 자동화된 테스트입니다.

코드 변경이 기존 기능을 망가뜨리지 않는지 즉시 확인할 수 있는 안전망이죠.

개요

간단히 말해서, Jest는 JavaScript 테스트 프레임워크로, 코드가 예상대로 동작하는지 자동으로 검증합니다. 테스트가 없으면 코드 변경이 두렵습니다.

리팩토링을 하고 싶어도 뭔가 망가질까 봐 망설이게 되고, 결국 기술 부채가 쌓이죠. 예를 들어, 로그인 함수를 수정했는데 회원가입도 같은 유틸리티를 쓰고 있었다면, 테스트 없이는 회원가입이 망가진 것을 배포 후에야 알게 됩니다.

기존에는 수동으로 모든 기능을 일일이 클릭해보며 테스트했다면, 현대적인 개발은 코드로 테스트를 작성하고 CI/CD에서 자동 실행합니다. Jest의 핵심 특징은 네 가지입니다: 첫째, 설정이 거의 필요 없는 Zero Config.

둘째, 빠른 병렬 실행과 스마트 캐싱. 셋째, 스냅샷 테스트로 UI 변경 추적.

넷째, 코드 커버리지 측정으로 테스트 품질 확인. 이러한 기능들이 여러분의 코드를 안전하고 신뢰성 있게 만들어줍니다.

코드 예제

// jest.config.js
module.exports = {
  // 테스트 환경 설정
  testEnvironment: 'node', // 또는 'jsdom' (브라우저 환경)

  // 커버리지 수집
  collectCoverageFrom: [
    'src/**/*.{js,jsx,ts,tsx}',
    '!src/**/*.test.{js,jsx,ts,tsx}',
    '!src/index.js'
  ],

  // 커버리지 임계값 (80% 이상)
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: 80
    }
  },

  // 모듈 경로 별칭
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1'
  },

  // 테스트 파일 패턴
  testMatch: ['**/__tests__/**/*.test.js'],

  // 테스트 전 실행할 설정 파일
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js']
};

설명

이 설정이 하는 일은 Jest가 프로젝트에 맞게 테스트를 실행하고, 어느 부분이 테스트되지 않았는지 추적하는 것입니다. 첫 번째로, testEnvironment를 설정합니다.

'node'는 서버 사이드 코드를 위한 것이고, 'jsdom'은 React 같은 브라우저 환경 코드를 위한 것입니다. jsdom을 사용하면 실제 브라우저 없이도 DOM API를 사용할 수 있어, 컴포넌트가 올바르게 렌더링되는지 테스트할 수 있습니다.

그 다음으로, collectCoverageFrom으로 커버리지를 측정할 파일을 지정합니다. src 폴더의 모든 JavaScript 파일을 포함하되, 테스트 파일 자체와 엔트리 포인트는 제외합니다.

커버리지는 각 코드 줄이 실제로 실행되었는지, 모든 분기(if-else)가 테스트되었는지 추적하죠. 세 번째로, coverageThreshold로 최소 커버리지 기준을 설정합니다.

80%는 함수, 분기, 라인, 구문의 80% 이상이 테스트되어야 한다는 의미입니다. 이 기준에 못 미치면 테스트가 실패하므로, 팀원들이 테스트를 작성하도록 강제할 수 있습니다.

네 번째로, moduleNameMapper로 경로 별칭을 설정합니다. '@/'를 'src/'로 매핑하면, import 시 상대 경로 대신 '@/components/Button'처럼 깔끔하게 작성할 수 있습니다.

테스트에서도 동일한 방식으로 import하므로 일관성이 유지됩니다. 마지막으로, setupFilesAfterEnv로 전역 설정 파일을 지정합니다.

여기서 testing-library를 import하거나, 모든 테스트에서 공통으로 사용할 모킹(mocking) 설정을 할 수 있습니다. 여러분이 이 설정을 사용하면 프로젝트 전체에서 일관된 테스트 환경을 구축할 수 있습니다.

CI/CD에서 자동으로 테스트가 실행되고, 커버리지가 떨어지면 머지가 차단되어 코드 품질을 유지할 수 있죠. 새로운 팀원이 합류해도 설정을 고민할 필요 없이 바로 테스트를 작성할 수 있습니다.

실전 팁

💡 watch 모드로 개발하세요. jest --watch를 실행하면 파일 변경 시 관련 테스트만 자동 재실행되어 빠른 피드백을 받을 수 있습니다.

💡 스냅샷 테스트를 활용하세요. UI 컴포넌트의 렌더링 결과를 저장하고, 의도치 않은 변경을 즉시 발견할 수 있습니다.

💡 각 테스트는 독립적이어야 합니다. 테스트 순서에 의존하거나 전역 상태를 공유하면 간헐적으로 실패하는 flaky test가 됩니다.

💡 describe로 테스트를 그룹화하고, 명확한 테스트 이름을 작성하세요. "should return user when valid ID is provided"처럼 무엇을 테스트하는지 명확히 하세요.

💡 beforeEach, afterEach 훅을 사용하여 테스트 간 격리를 보장하세요. 데이터베이스 모킹, 타이머 리셋 등을 수행합니다.

---

6. API_통합_테스트

시작하며

여러분이 프론트엔드를 개발했는데, 백엔드 API와 연결하니까 전혀 작동하지 않았다면? API 스펙이 변경되었거나 에러 처리가 빠져있었던 겁니다.

이런 문제는 단위 테스트만으로는 발견할 수 없습니다. 마치 자동차 부품들이 각각 완벽해도 조립하면 제대로 작동하지 않을 수 있는 것처럼, 개별 함수는 정상이어도 API 통신에서 문제가 발생할 수 있어요.

이런 통합 문제를 사전에 발견하기 위해 필요한 것이 API 통합 테스트입니다. 실제 HTTP 요청을 시뮬레이션하여 API가 예상대로 작동하는지 검증하는 것이죠.

개요

간단히 말해서, API 통합 테스트는 실제 API 호출을 모방하여 요청과 응답이 올바른지 확인하는 것입니다. 실제 프로덕션 환경에서는 네트워크 지연, 타임아웃, 예상치 못한 에러 응답 등 다양한 상황이 발생합니다.

단위 테스트는 이런 실제 상황을 반영하지 못하죠. 예를 들어, 사용자 생성 API가 중복 이메일로 409 Conflict를 반환해야 하는데, 테스트 없이는 이런 엣지 케이스를 놓칠 수 있습니다.

기존에는 Postman으로 수동 테스트했다면, 현대적인 개발은 Supertest나 MSW(Mock Service Worker)로 자동화된 테스트를 작성합니다. API 통합 테스트의 핵심은 네 가지입니다: 첫째, 실제 HTTP 요청/응답 시뮬레이션.

둘째, 다양한 시나리오 커버(성공, 실패, 엣지 케이스). 셋째, 응답 구조와 데이터 타입 검증.

넷째, 에러 처리와 상태 코드 확인. 이러한 검증이 프론트엔드와 백엔드의 계약(contract)을 보장합니다.

코드 예제

// API 통합 테스트 (Supertest + Express)
const request = require('supertest');
const app = require('../app');

describe('POST /api/users', () => {
  // 성공 케이스
  it('should create user with valid data', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({
        email: 'test@example.com',
        password: 'securePassword123',
        name: 'John Doe'
      })
      .expect(201); // 상태 코드 검증

    // 응답 구조 검증
    expect(response.body).toHaveProperty('id');
    expect(response.body.email).toBe('test@example.com');
    expect(response.body).not.toHaveProperty('password'); // 비밀번호는 반환 안 됨
  });

  // 실패 케이스
  it('should reject duplicate email', async () => {
    await request(app)
      .post('/api/users')
      .send({ email: 'duplicate@example.com', password: 'pass123', name: 'User' })
      .expect(409) // Conflict
      .expect((res) => {
        expect(res.body.error).toContain('already exists');
      });
  });

  // 유효성 검사
  it('should reject invalid email format', async () => {
    await request(app)
      .post('/api/users')
      .send({ email: 'invalid-email', password: 'pass123' })
      .expect(400); // Bad Request
  });
});

설명

이 테스트가 하는 일은 API 엔드포인트에 다양한 입력을 보내고, 예상한 대로 응답하는지 확인하는 것입니다. 첫 번째로, Supertest는 Express 앱을 실제 서버로 띄우지 않고도 HTTP 요청을 보낼 수 있게 해줍니다.

request(app).post()는 실제 POST 요청과 동일하게 동작하지만, 네트워크를 거치지 않아 빠르고 안정적입니다. .send()로 요청 바디를 전달하고, .expect(201)로 상태 코드가 201 Created인지 확인합니다.

그 다음으로, 응답 본문을 상세히 검증합니다. toHaveProperty('id')로 id 필드가 존재하는지 확인하고, email이 요청한 값과 일치하는지 검증합니다.

중요한 것은 password가 응답에 포함되지 않았는지도 확인하는 것입니다. 실수로 민감한 정보를 노출하는 것을 방지하죠.

세 번째로, 실패 케이스를 테스트합니다. 중복 이메일로 회원가입을 시도하면 409 Conflict를 반환해야 합니다.

expect() 콜백으로 에러 메시지도 검증하여, 클라이언트가 사용자에게 적절한 안내를 할 수 있도록 합니다. 마지막으로, 유효성 검사 케이스를 추가합니다.

잘못된 이메일 형식, 짧은 비밀번호 등 다양한 잘못된 입력에 대해 400 Bad Request를 반환하는지 확인합니다. 이렇게 하면 프론트엔드 개발자가 어떤 상황에서 어떤 에러가 발생하는지 명확히 알 수 있습니다.

여러분이 이 테스트를 작성하면 API 변경 시 자동으로 문제를 발견할 수 있습니다. 백엔드 개발자가 응답 구조를 바꾸면 테스트가 실패하므로, 프론트엔드와 백엔드가 항상 동기화됩니다.

CI/CD에서 자동 실행되므로 배포 전에 문제를 잡을 수 있죠.

실전 팁

💡 테스트 데이터베이스를 사용하세요. beforeEach에서 DB를 초기화하고, afterEach에서 정리하여 테스트 간 격리를 보장합니다.

💡 인증이 필요한 API는 테스트용 토큰을 생성하세요. .set('Authorization', Bearer ${token})으로 헤더를 추가할 수 있습니다.

💡 비동기 작업(이메일 발송, 파일 업로드)은 모킹하세요. 실제로 이메일을 보내면 테스트가 느려지고 불안정해집니다.

💡 엣지 케이스를 철저히 테스트하세요. 빈 문자열, null, 매우 긴 입력, 특수문자 등 예상치 못한 입력에 대한 처리를 검증합니다.

💡 API 문서와 테스트를 동기화하세요. Swagger나 OpenAPI 스펙을 사용하면 문서에서 테스트를 자동 생성할 수 있습니다.

---

7. 에러_핸들링_및_로깅

시작하며

여러분의 서비스에서 에러가 발생했는데, 사용자는 "뭔가 잘못되었습니다"라는 메시지만 보고, 개발자는 무슨 일이 일어났는지 전혀 모른다면? 에러가 제대로 처리되지도, 기록되지도 않은 겁니다.

이런 상황은 디버깅을 거의 불가능하게 만듭니다. 마치 범죄 현장에 증거가 하나도 없는 것과 같아요.

사용자는 계속 같은 에러를 겪고, 개발자는 재현조차 할 수 없어서 고칠 수 없죠. 이런 블랙홀 같은 상황을 방지하기 위해 필요한 것이 체계적인 에러 핸들링과 로깅입니다.

에러를 적절히 처리하여 사용자 경험을 보호하고, 상세히 기록하여 문제를 신속하게 해결하는 것이죠.

개요

간단히 말해서, 에러 핸들링은 예외 상황을 우아하게 처리하는 것이고, 로깅은 무슨 일이 일어났는지 기록하는 것입니다. 모든 애플리케이션은 에러를 경험합니다.

네트워크 실패, 데이터베이스 연결 끊김, 잘못된 사용자 입력, 예상치 못한 버그 등 수없이 많은 이유로 에러가 발생하죠. 예를 들어, 결제 API 호출이 실패했을 때 사용자에게 "서버 에러"만 보여주면 사용자는 재시도해야 하는지, 카드가 문제인지, 나중에 다시 와야 하는지 알 수 없습니다.

기존에는 console.log로 에러를 출력하고 try-catch를 산발적으로 사용했다면, 현대적인 애플리케이션은 중앙화된 에러 핸들러와 구조화된 로깅 시스템을 사용합니다. 에러 핸들링과 로깅의 핵심은 다섯 가지입니다: 첫째, 에러를 레벨별로 분류(Error, Warning, Info).

둘째, 사용자에게 친절한 메시지 vs 개발자용 상세 정보 분리. 셋째, 구조화된 로그(JSON)로 검색과 분석 용이.

넷째, 중앙화된 로그 수집(Sentry, CloudWatch). 다섯째, 에러 알림으로 즉각 대응.

이러한 체계가 서비스 안정성과 사용자 신뢰를 높여줍니다.

코드 예제

// Winston + Sentry를 사용한 에러 핸들링
const winston = require('winston');
const Sentry = require('@sentry/node');

// Winston 로거 설정
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  defaultMeta: { service: 'user-service' },
  transports: [
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' })
  ]
});

// 개발 환경에서는 콘솔 출력
if (process.env.NODE_ENV !== 'production') {
  logger.add(new winston.transports.Console({
    format: winston.format.simple()
  }));
}

// Sentry 초기화
Sentry.init({ dsn: process.env.SENTRY_DSN });

// Express 에러 핸들러 미들웨어
app.use((err, req, res, next) => {
  // 에러 로깅
  logger.error('API Error', {
    error: err.message,
    stack: err.stack,
    url: req.url,
    method: req.method,
    userId: req.user?.id
  });

  // 심각한 에러는 Sentry로 전송
  if (err.statusCode >= 500) {
    Sentry.captureException(err);
  }

  // 사용자에게 친절한 메시지
  res.status(err.statusCode || 500).json({
    error: process.env.NODE_ENV === 'production'
      ? '서비스 처리 중 문제가 발생했습니다'
      : err.message
  });
});

설명

이 코드가 하는 일은 모든 에러를 캐치하여 적절히 로깅하고, 사용자에게는 안전한 메시지를, 개발자에게는 상세한 정보를 제공하는 것입니다. 첫 번째로, Winston 로거를 설정합니다.

level: 'info'는 info 레벨 이상의 로그만 기록한다는 의미입니다(debug < info < warn < error). format.json()으로 모든 로그를 JSON 형태로 저장하여 나중에 파싱하고 검색하기 쉽게 만듭니다.

defaultMeta로 모든 로그에 서비스 이름을 자동으로 추가하여, 마이크로서비스 환경에서 로그 출처를 구분할 수 있습니다. 그 다음으로, 두 개의 파일 트랜스포트를 설정합니다.

error.log에는 에러만, combined.log에는 모든 로그를 저장합니다. 이렇게 분리하면 에러만 빠르게 찾아볼 수 있죠.

개발 환경에서는 콘솔에도 출력하여 실시간으로 확인할 수 있게 합니다. 세 번째로, Sentry를 초기화합니다.

Sentry는 에러 모니터링 서비스로, 에러를 자동으로 수집하고 그룹화하며, 이메일이나 Slack으로 알림을 보냅니다. 에러가 발생하면 스택 트레이스, 브라우저 정보, 사용자 행동 등을 모두 기록하여 디버깅을 쉽게 만들죠.

마지막으로, Express 에러 핸들러 미들웨어를 설정합니다. 네 개의 파라미터(err, req, res, next)를 받는 함수는 에러 핸들러로 인식됩니다.

여기서 에러를 Winston으로 로깅하고, 500번대 에러는 Sentry로도 전송합니다. 사용자에게는 프로덕션에서는 안전한 메시지만 보여주고, 개발 환경에서는 실제 에러 메시지를 보여줍니다.

여러분이 이 시스템을 사용하면 에러가 발생해도 당황하지 않을 수 있습니다. 로그를 검색하여 언제, 누가, 어떤 작업을 했을 때 에러가 발생했는지 즉시 파악할 수 있고, Sentry 대시보드에서 에러 추이를 분석하여 가장 빈번한 문제부터 해결할 수 있습니다.

사용자는 친절한 안내를 받고, 개발자는 빠르게 문제를 수정할 수 있죠.

실전 팁

💡 로그에 컨텍스트를 충분히 포함시키세요. 사용자 ID, 요청 ID, 타임스탬프 등을 함께 기록하면 나중에 추적이 쉽습니다.

💡 민감한 정보는 로그에 절대 포함하지 마세요. 비밀번호, 신용카드 번호, 개인정보 등은 마스킹하거나 제외해야 합니다.

💡 에러 코드를 체계적으로 관리하세요. USER_001, AUTH_002 같은 코드를 사용하면 클라이언트가 에러를 구분하여 처리할 수 있습니다.

💡 로그 보관 정책을 설정하세요. 오래된 로그는 압축하거나 삭제하여 스토리지 비용을 절감합니다. 법적 요구사항도 고려하세요.

💡 성능 모니터링도 함께 설정하세요. 응답 시간, 처리량, 메모리 사용량 등을 로깅하면 성능 저하를 조기에 발견할 수 있습니다.

---