웹 개발

운영 중 상태가 꼬였을 때 초기화하는 법

배포 후 데이터나 캐시 상태가 이상할 때 안전하게 리셋하고 원인을 찾는 방법.

2026년 6월 24일·2분 읽기

Next.js 프로젝트를 운영하다 보면 배포 후 상태가 꼬이는 경험을 한다. 사용자가 "최신 내용이 안 보여요"라고 하거나, "아까는 된 기능이 지금 안 돼요"라고 말한다.

문제의 경계를 먼저 그어라

"상태가 꼬였다"는 것이 구체적으로 뭔지 파악해야 한다.

화면에 표시되는 데이터가 틀렸나?
기능 자체가 작동 안 하나?
데이터베이스 상태는 맞은데 화면만 틀렸나?
캐시 때문인가?

이 4가지를 먼저 구분한다.

첫 번째: 로그 확인

# 빌드 로그 확인
npm run build  # 에러 없나?

# 배포 후 로그
sudo journalctl -u nextjs-app -n 50

# 에러가 있었나?
sudo journalctl -u nextjs-app | grep -i error

로그가 가장 정직한 증거다. 화면에 뭔가 보이지 않아도 로그에는 이유가 남아있을 가능성이 높다.

두 번째: 공개 URL에서 확인

curl -s https://example.com | grep -Ei 'title|description|og:'

HTML 메타데이터를 직접 확인한다. 빌드가 제대로 되었는지 알 수 있다.

캐시 문제인지 확인

Next.js는 여러 곳에서 캐싱한다.

# 1. 빌드 캐시
rm -rf .next
npm run build

# 2. CDN 캐시 (있다면)
# Cloudflare나 다른 CDN 대시보드에서 캐시 비우기

# 3. 브라우저 캐시
# Incognito 모드에서 테스트
curl -s https://example.com | head

데이터베이스 상태 확인

# 마이그레이션이 제대로 됐나?
npm run migrate

# 특정 테이블의 데이터
psql -U username -d dbname -c "SELECT COUNT(*) FROM users;"

# 최근 수정된 데이터
psql -U username -d dbname -c "SELECT * FROM users ORDER BY updated_at DESC LIMIT 5;"

canonical과 정적 생성 확인

# 페이지가 정적으로 생성되었나?
ls -la .next/server/pages/

# ISR이 제대로 설정되었나?
# next.config.js에서:
// revalidate: 60  # 60초마다 갱신

만약 revalidate가 없거나 너무 길면, 오래된 데이터를 보여준다.

환경 변수 확인

# 배포 환경의 변수가 맞나?
echo $NEXT_PUBLIC_API_URL
echo $DATABASE_URL  # 이건 로그에 노출되면 안 됨

# 로컬과 비교
cat .env.local  # 로컬
# vs
# 배포 환경의 설정

데이터베이스 URL이 달라도 조용히 실패한다.

안전하게 초기화하기

1단계: 현재 상태 백업

# 데이터 백업
pg_dump -U username dbname > backup-$(date +%Y%m%d-%H%M%S).sql

2단계: 한 가지씩만 시도

# 캐시만 비우기
rm -rf .next
npm run build  # 재빌드

# 다시 배포
redeploy

# 테스트
curl -s https://example.com | grep 'title'

결과가 변했나?

변했다면 원인은 캐시였다
안 변했다면 다음 시도

3단계: 데이터 확인

# 정말 필요하면 데이터 초기화
npm run migrate:reset  # 위험! 데이터 삭제됨

# 대신 특정 테이블만 확인
psql -c "SELECT * FROM sessions ORDER BY created_at DESC LIMIT 10;"

마지막: 원인 기록

# 공개 URL 상태
echo "URL: https://example.com"
echo "Meta tags: $(curl -s https://example.com | grep 'og:title')"
echo "Build time: $(date)"
echo "Database: OK/FAIL"
echo "Cause: Cache/Data/Config issue"

# 로그 파일로 저장
echo "State check" >> /var/log/deployments.log

체크리스트

빌드 로그 확인 (에러 있나?)
공개 URL의 HTML 확인
캐시 비우기
데이터 상태 확인
환경 변수 확인
한 번에 한 가지만 수정
원인 기록

결국 상태가 꼬인 건 한 순간이 아니고, 빌드→배포→데이터 같은 여러 단계가 안 맞은 것이다. 각 단계를 다시 한 번 차근차근 확인하면 대부분 찾을 수 있다.