Next.js 시니어 시스템 설계 면접
새 면접Q. Next.js 애플리케이션에서 실시간 대시보드(주식 시세, 채팅, 알림 등)를 구현할 때, WebSocket 연결 관리와 서버 컴포넌트의 정적 데이터를 효율적으로 조합하는 아키텍처를 설계해주세요. 특히 WebSocket 서버의 분리 여부, 연결 풀 관리, 재연결 전략, 그리고 SSR된 초기 데이터와 실시간 업데이트의 동기화 방법을 포함해주세요.
WebSocket 서버는 Next.js API Routes와 분리하여 별도의 Node.js 서버(Socket.io, ws)로 구성하고, Redis Pub/Sub으로 수평 확장을 지원합니다. 클라이언트는 Server Component에서 초기 데이터를 SSR로 받고, Client Component에서 WebSocket 연결을 맺어 실시간 업데이트를 받습니다. 재연결 시 exponential backoff 전략을 사용하고, 연결 끊김 동안의 누락 데이터는 REST API로 보완합니다. 연결 풀은 Redis 기반 세션 스토어로 관리하며, 각 사용자의 구독 채널을 추적합니다. Next.js API Routes는 WebSocket 서버와 통신하여 메시지 발행 역할만 수행하고, 실시간 연결은 전담 서버가 처리합니다.
- • WebSocket 서버를 Next.js와 분리하여 전담 서버로 구성, Redis Pub/Sub으로 수평 확장
- • Server Component로 초기 데이터 SSR, Client Component에서 WebSocket으로 실시간 업데이트
- • Exponential backoff 재연결 전략과 REST API 기반 데이터 보완
- • Redis 기반 연결 풀 및 세션 관리로 다중 서버 환경 지원
WebSocket 서버가 다운되었을 때 사용자 경험을 유지하기 위한 폴백 전략과, 10만 명 이상의 동시 접속자를 처리하기 위한 인프라 구성은 어떻게 설계하시겠습니까?
Q. Next.js 서버리스 환경(Vercel, AWS Lambda)에서 데이터베이스 연결 풀 고갈 문제가 발생하는 원인과 해결 방안을 설명해주세요. Prisma, Drizzle 등의 ORM 사용 시 연결 풀 설정, Connection Pooling 서비스(PgBouncer, RDS Proxy) 도입, 그리고 App Router의 Server Actions에서의 연결 관리 전략을 포함해주세요.
서버리스 환경에서는 각 함수 인스턴스가 독립적으로 DB 연결을 생성하여 연결 풀이 빠르게 고갈됩니다. 해결을 위해 첫째, Prisma의 connection_limit를 낮게 설정(5-10)하고 connection_timeout을 짧게 유지합니다. 둘째, PgBouncer나 RDS Proxy 같은 연결 풀링 서비스를 중간에 배치하여 실제 DB 연결을 재사용합니다. 셋째, Vercel의 경우 Edge Runtime에서 HTTP 기반 DB(Neon, PlanetScale)를 사용하거나, Prisma Data Proxy를 활용합니다. Server Actions에서는 요청당 연결을 명시적으로 관리하고, 글로벌 싱글톤 패턴으로 Prisma Client 인스턴스를 재사용합니다. 장기 실행 작업은 별도 백엔드 서버로 분리합니다.
- • 서버리스 환경의 독립적 인스턴스로 인한 연결 풀 고갈 문제 이해
- • ORM 연결 풀 설정 최적화(낮은 limit, 짧은 timeout)
- • PgBouncer, RDS Proxy 등 연결 풀링 서비스 도입으로 연결 재사용
- • HTTP 기반 DB 또는 Prisma Data Proxy 활용, 싱글톤 패턴 적용
Prisma Client를 글로벌 싱글톤으로 관리할 때 개발 환경에서 Hot Reload 시 연결이 누적되는 문제는 어떻게 해결하시겠습니까?
Q. Next.js 기반 콘텐츠 플랫폼에서 전문 검색(Full-Text Search) 기능을 구현할 때, PostgreSQL의 Full-Text Search, Elasticsearch, Algolia 등의 선택 기준과 각각의 아키텍처 통합 방법을 설명해주세요. 특히 검색 인덱스 동기화, 자동완성, 패싯 필터링, 한글 형태소 분석을 고려한 설계를 포함해주세요.
소규모(~10만 문서)는 PostgreSQL Full-Text Search로 시작하며, tsvector와 GIN 인덱스를 활용하고 한글은 pg_trgm 확장으로 처리합니다. 중대규모(10만~1000만)는 Elasticsearch를 도입하여 nori 형태소 분석기로 한글을 처리하고, Logstash나 Change Data Capture로 DB와 동기화합니다. 대규모 또는 빠른 구현이 필요하면 Algolia를 사용하며, Webhook이나 Background Job으로 실시간 동기화합니다. 자동완성은 Edge Function에서 캐싱된 인기 검색어와 prefix 매칭을 조합하고, 패싯 필터링은 Elasticsearch의 Aggregation이나 Algolia의 Facet 기능을 활용합니다. Next.js에서는 Server Actions로 검색 요청을 처리하고, 결과는 React Server Components로 렌더링하며, 클라이언트 상태는 URL 쿼리 파라미터로 관리합니다.
- • 규모별 검색 솔루션 선택: PostgreSQL(소규모), Elasticsearch(중대규모), Algolia(대규모/빠른 구현)
- • 한글 처리: pg_trgm, Elasticsearch nori 형태소 분석기 활용
- • DB-검색엔진 동기화: CDC, Logstash, Webhook, Background Job
- • 자동완성과 패싯 필터링 구현, Server Actions와 URL 기반 상태 관리
검색 결과의 개인화(사용자 선호도 반영)와 검색 품질 측정(Precision, Recall)을 위한 A/B 테스팅 아키텍처는 어떻게 구성하시겠습니까?
Q. Next.js App Router에서 JWT 기반 인증과 세션 기반 인증의 트레이드오프를 분석하고, Server Components, Server Actions, Route Handlers에서 안전하게 인증 정보를 다루는 아키텍처를 설계해주세요. 특히 토큰 저장 위치(Cookie, LocalStorage), CSRF 방어, 토큰 갱신 전략, 그리고 XSS 방어를 포함해주세요.
JWT는 무상태로 확장성이 좋지만 즉시 무효화가 어렵고, 세션은 서버 상태 관리가 필요하지만 즉시 제어 가능합니다. Next.js에서는 HttpOnly, Secure, SameSite=Strict 쿠키에 JWT를 저장하여 XSS를 방어하고, Server Components와 Server Actions에서 cookies() API로 안전하게 읽습니다. CSRF 방어는 SameSite 쿠키와 Server Actions의 자동 CSRF 토큰으로 처리됩니다. 토큰 갱신은 Refresh Token을 별도 HttpOnly 쿠키에 저장하고, Access Token 만료 시 자동 갱신하는 미들웨어를 구현합니다. 민감한 작업은 짧은 수명의 Access Token으로 제한하고, Refresh Token은 Redis에 화이트리스트로 관리하여 즉시 무효화를 지원합니다. 클라이언트에서는 절대 LocalStorage에 토큰을 저장하지 않으며, 모든 인증 로직은 서버에서 처리합니다.
- • JWT(확장성)와 세션(즉시 제어) 트레이드오프 이해
- • HttpOnly, Secure, SameSite 쿠키로 XSS/CSRF 방어
- • Refresh Token 기반 자동 갱신, Redis 화이트리스트로 즉시 무효화
- • Server Components/Actions에서 cookies() API 사용, 클라이언트 LocalStorage 금지
마이크로서비스 아키텍처에서 여러 Next.js 애플리케이션이 동일한 인증을 공유해야 할 때, 중앙 인증 서버(OAuth2, SSO)와의 통합 방안은 무엇입니까?
Q. Next.js 프로덕션 환경에서 Core Web Vitals(LCP, FID, CLS) 모니터링, 서버 사이드 성능 추적, 에러 추적을 위한 종합 관찰성(Observability) 시스템을 설계해주세요. Sentry, DataDog, New Relic 등의 APM 도구 통합, 커스텀 메트릭 수집, 분산 추적(Distributed Tracing), 그리고 알림 전략을 포함해주세요.
클라이언트 성능은 Next.js의 reportWebVitals를 활용하여 Core Web Vitals를 수집하고, Sentry나 Google Analytics로 전송합니다. 서버 성능은 OpenTelemetry로 계측하여 DataDog이나 New Relic에 분산 추적 데이터를 전송하고, API Routes와 Server Actions의 응답 시간, 에러율을 추적합니다. 커스텀 메트릭(비즈니스 지표)은 StatsD나 Prometheus로 수집하고 Grafana로 시각화합니다. 에러 추적은 Sentry를 Server/Client 양쪽에 통합하고, 소스맵을 업로드하여 프로덕션 에러를 원본 코드로 추적합니다. 알림은 에러율 5% 초과, LCP 2.5초 초과, API 응답 시간 1초 초과 시 PagerDuty나 Slack으로 발송하며, 심각도별로 담당자를 지정합니다. 모든 로그는 구조화된 JSON 형식으로 CloudWatch나 ELK 스택에 중앙화합니다.
- • reportWebVitals로 Core Web Vitals 수집, Sentry/GA 전송
- • OpenTelemetry 기반 서버 사이드 분산 추적, APM 도구 통합
- • 커스텀 메트릭 수집(StatsD/Prometheus), Grafana 시각화
- • 구조화된 로그 중앙화, 임계값 기반 알림 전략(PagerDuty/Slack)
프로덕션에서 특정 사용자나 세션의 요청을 실시간으로 추적하고 디버깅하기 위한 Request Tracing ID 전략과 로그 상관관계(Correlation) 구현 방법을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!