Next.js 리드·아키텍트 CS 기초 면접
새 면접Q. Next.js 서버를 운영 중인데 특정 시간대에 응답 속도가 급격히 느려지는 현상이 발생했습니다. 네트워크 레이어에서 발생할 수 있는 병목 지점을 TCP 관점에서 설명하고, TCP Slow Start, Congestion Window, Time Wait 상태가 대규모 트래픽 환경에서 어떤 영향을 미치는지 분석해주세요. 또한 HTTP Keep-Alive와 Connection Pooling이 이 문제를 어떻게 완화할 수 있는지 설명해주세요.
TCP 연결 수립과 종료 과정에서 발생하는 오버헤드와 커널 리소스 사용을 고려해보세요.
TCP Slow Start는 새 연결마다 초기 전송 속도를 낮게 시작하므로, 연결이 빈번하게 생성되면 대역폭을 충분히 활용하지 못합니다. Congestion Window는 네트워크 혼잡 시 전송량을 조절하는데, 패킷 손실이 발생하면 급격히 줄어들어 처리량이 감소합니다. Time Wait 상태는 연결 종료 후 일정 시간(보통 60초) 동안 소켓을 유지하므로, 짧은 연결이 많으면 포트 고갈과 메모리 부족이 발생합니다. HTTP Keep-Alive는 연결을 재사용하여 TCP 핸드셰이크 오버헤드를 제거하고 Slow Start를 우회합니다. Connection Pooling은 미리 생성된 연결을 재사용하여 연결 수립 비용을 최소화하고 Time Wait 상태의 소켓 수를 줄여 시스템 리소스를 효율적으로 관리합니다.
- • TCP Slow Start로 인한 초기 전송 속도 제한
- • Time Wait 상태로 인한 포트 고갈 및 메모리 부족
- • Keep-Alive를 통한 연결 재사용으로 핸드셰이크 오버헤드 제거
- • Connection Pooling으로 연결 수립 비용 최소화
대규모 API 서버에서 짧은 HTTP 요청이 많을 때 연결 관리 전략을 수립하는 상황
로드밸런서 환경에서 Connection Pooling을 구성할 때 upstream과 downstream 각각에서 고려해야 할 설정값은 무엇인가요?
Q. Next.js API Route에서 PostgreSQL 데이터베이스에 복잡한 트랜잭션을 처리하는 중 데드락이 자주 발생합니다. 데이터베이스 레벨에서 데드락이 발생하는 근본 원인을 4가지 필요조건으로 설명하고, 2PL(Two-Phase Locking)과 MVCC(Multi-Version Concurrency Control)의 차이점을 비교한 후, PostgreSQL의 Serializable 격리 수준에서 데드락을 방지하기 위한 실무적 전략을 제시해주세요.
데드락의 필요조건과 락 획득 순서, 그리고 MVCC의 스냅샷 격리 메커니즘을 생각해보세요.
데드락의 4가지 필요조건은 상호배제(동시 접근 불가), 점유와 대기(락을 보유한 채 다른 락 대기), 비선점(강제로 락을 빼앗을 수 없음), 순환 대기(락 요청이 순환 구조)입니다. 2PL은 락을 획득하는 Growing Phase와 해제하는 Shrinking Phase로 나뉘며 락 기반으로 동시성을 제어하지만, MVCC는 각 트랜잭션이 데이터의 스냅샷을 보므로 읽기 작업에 락이 필요 없어 동시성이 높습니다. PostgreSQL의 Serializable 격리 수준은 SSI(Serializable Snapshot Isolation)를 사용해 충돌을 감지하지만, 데드락 방지를 위해서는 모든 트랜잭션에서 테이블 접근 순서를 일관되게 유지하고, 트랜잭션 범위를 최소화하며, 명시적인 SELECT FOR UPDATE를 사용해 락 순서를 명확히 해야 합니다. 또한 데드락 타임아웃 설정을 적절히 조정하고 재시도 로직을 구현하는 것이 중요합니다.
- • 데드락 4가지 필요조건: 상호배제, 점유와 대기, 비선점, 순환 대기
- • 2PL은 락 기반, MVCC는 스냅샷 기반으로 동시성 제어
- • 테이블 접근 순서 일관성 유지로 순환 대기 방지
- • 트랜잭션 범위 최소화와 명시적 락 순서 지정
결제 시스템이나 재고 관리 같이 복잡한 트랜잭션이 동시에 발생하는 환경에서 데드락을 예방하는 상황
Optimistic Locking과 Pessimistic Locking의 트레이드오프를 고려할 때 어떤 상황에서 각각을 선택하시겠습니까?
Q. Next.js 애플리케이션에서 실시간 채팅 기능을 구현하는데, 메시지를 시간순으로 정렬하면서 특정 우선순위 메시지(공지사항, 긴급 알림)는 항상 상단에 고정해야 합니다. 이 요구사항을 만족하는 자료구조 설계를 제안하고, 삽입과 조회의 시간 복잡도를 분석해주세요. 또한 메시지가 수천 개로 증가할 때 메모리 효율성을 고려한 최적화 방안도 함께 설명해주세요.
우선순위와 시간순이라는 두 가지 정렬 기준을 동시에 만족해야 하는 점을 고려하세요.
우선순위별로 분리된 이중 연결 리스트 구조를 사용하는 것이 적합합니다. 최상위에 우선순위 메시지용 리스트, 하위에 일반 메시지용 리스트를 두고 각각 시간순으로 정렬합니다. 삽입 시 우선순위를 확인해 해당 리스트의 적절한 위치에 O(1) 또는 O(n)으로 삽입하며, 최신 메시지는 항상 끝에 추가되므로 tail 포인터를 사용하면 O(1)입니다. 조회는 두 리스트를 순차적으로 순회하므로 O(n)입니다. 메모리 최적화를 위해 Circular Buffer를 적용해 오래된 메시지를 자동으로 제거하고, 고정 크기 배열로 구현하면 메모리 할당 오버헤드를 줄일 수 있습니다. 추가로 Virtual Scrolling과 결합해 화면에 보이는 메시지만 렌더링하면 DOM 메모리도 절약할 수 있습니다.
- • 우선순위별 분리된 연결 리스트로 두 가지 정렬 기준 동시 만족
- • tail 포인터 활용으로 최신 메시지 O(1) 삽입
- • Circular Buffer로 오래된 메시지 자동 제거
- • Virtual Scrolling으로 렌더링 메모리 최적화
실시간 협업 도구나 메신저에서 일반 메시지와 시스템 알림을 함께 표시하는 상황
만약 우선순위가 3단계 이상으로 늘어나고 각 우선순위 내에서도 다양한 정렬 기준이 필요하다면 어떤 자료구조를 선택하시겠습니까?
Q. Next.js 서버를 컨테이너 환경에서 운영 중인데, CPU 사용률은 낮은데도 응답 시간이 길어지는 현상이 발생했습니다. Context Switching과 Interrupt가 성능에 미치는 영향을 설명하고, Node.js의 이벤트 루프가 싱글 스레드임에도 불구하고 Context Switching이 발생하는 시나리오를 제시해주세요. 또한 컨테이너 환경에서 CPU Throttling과 CFS(Completely Fair Scheduler)가 이 문제를 어떻게 악화시킬 수 있는지 분석해주세요.
Node.js의 libuv 스레드 풀과 커널 레벨의 스케줄링을 함께 고려해보세요.
Context Switching은 프로세스나 스레드 전환 시 레지스터 상태 저장 및 복원으로 인한 오버헤드가 발생하며, Interrupt는 하드웨어 이벤트 처리를 위해 현재 작업을 중단시켜 지연을 유발합니다. Node.js는 메인 스레드는 싱글이지만 libuv의 기본 4개 워커 스레드가 파일 I/O, DNS 조회, crypto 등을 처리하므로, 이들 간의 Context Switching이 발생합니다. 컨테이너에 CPU 제한(예: 0.5 core)을 설정하면 CFS는 프로세스가 할당량을 초과하면 강제로 대기시키는데, Node.js 워커 스레드들이 짧은 CPU 버스트를 반복하면 빈번한 throttling이 발생합니다. 또한 여러 컨테이너가 같은 물리 코어를 공유하면 CFS의 공정성 알고리즘으로 인해 우선순위가 낮아진 프로세스는 더 긴 대기 시간을 겪게 됩니다. 해결을 위해서는 적절한 CPU 리소스 할당, UV_THREADPOOL_SIZE 조정, 그리고 CPU affinity 설정을 고려해야 합니다.
- • Context Switching으로 인한 레지스터 상태 저장/복원 오버헤드
- • Node.js libuv 워커 스레드에서의 Context Switching 발생
- • 컨테이너 CPU 제한 시 CFS throttling으로 대기 시간 증가
- • UV_THREADPOOL_SIZE와 CPU affinity 조정 필요
컨테이너 오케스트레이션 환경에서 리소스 제한으로 인한 성능 저하를 진단하고 해결하는 상황
Kubernetes 환경에서 CPU limits와 requests의 차이가 Node.js 애플리케이션 성능에 어떤 영향을 미치나요?
Q. Next.js 애플리케이션에서 사용자별 권한 체크를 위해 복잡한 규칙 엔진을 구현해야 합니다. 규칙은 AND, OR, NOT 조합으로 중첩될 수 있으며, 각 규칙 평가는 비용이 큰 데이터베이스 조회를 포함합니다. Short-circuit Evaluation을 활용한 최적화 전략을 설명하고, 규칙 평가 순서를 결정하는 휴리스틱 알고리즘을 제안해주세요. 또한 메모이제이션을 적용할 때 캐시 키 설계와 무효화 전략도 함께 설명해주세요.
논리 연산의 특성과 각 규칙의 실행 비용 및 성공 확률을 고려한 평가 순서 최적화를 생각해보세요.
Short-circuit Evaluation은 AND 연산에서 첫 false를 만나면 나머지를 평가하지 않고, OR 연산에서 첫 true를 만나면 즉시 반환하는 최적화입니다. 규칙 평가 순서는 실행 비용이 낮고 실패 확률이 높은 규칙을 AND에서 먼저 배치하고, 성공 확률이 높은 규칙을 OR에서 먼저 배치하는 휴리스틱을 사용합니다. 각 규칙에 예상 비용과 과거 성공률을 메타데이터로 저장하고, 이를 기반으로 동적으로 정렬합니다. 메모이제이션 캐시 키는 사용자 ID, 규칙 ID, 관련 리소스 ID를 조합하여 생성하며, 권한 변경이나 리소스 업데이트 시 해당 키를 무효화합니다. TTL 기반 만료와 이벤트 기반 무효화를 병행하고, LRU 캐시로 메모리를 관리하면 효율적입니다.
- • Short-circuit Evaluation로 불필요한 평가 제거
- • 실행 비용과 성공 확률 기반 규칙 평가 순서 최적화
- • 사용자/규칙/리소스 조합으로 캐시 키 설계
- • TTL과 이벤트 기반 무효화 병행
복잡한 RBAC(Role-Based Access Control)나 ABAC(Attribute-Based Access Control) 시스템에서 권한 평가 성능을 최적화하는 상황
규칙이 수천 개로 증가하고 의존성이 복잡해질 때 규칙 컴파일러를 구현한다면 어떤 최적화 기법을 적용하시겠습니까?
Q. Next.js 애플리케이션에서 CDN을 통해 정적 자산을 배포하는데, 사용자가 특정 지역에서 간헐적으로 오래된 콘텐츠를 보는 문제가 발생했습니다. DNS의 동작 원리와 TTL, Anycast 라우팅이 CDN과 어떻게 연동되는지 설명하고, Cache Invalidation과 Cache Purge의 차이점을 비교한 후, 즉각적인 콘텐츠 업데이트를 보장하기 위한 Cache Busting 전략을 제시해주세요.
DNS 캐싱 계층과 CDN 엣지 캐싱이 독립적으로 동작한다는 점을 고려하세요.
DNS는 도메인을 IP로 변환하는데 TTL 동안 결과를 캐싱하므로, CDN IP가 변경되어도 TTL이 만료될 때까지 이전 IP로 접속할 수 있습니다. Anycast 라우팅은 여러 CDN 엣지 서버가 같은 IP를 공유하며 네트워크 거리가 가장 가까운 서버로 자동 라우팅하지만, 라우팅 변경 시 다른 엣지 서버로 연결되어 캐시 불일치가 발생할 수 있습니다. Cache Invalidation은 특정 콘텐츠를 무효 표시하여 다음 요청 시 origin에서 재조회하고, Cache Purge는 즉시 삭제하여 모든 엣지에서 제거합니다. 즉각적 업데이트를 위해서는 파일명에 해시나 버전을 포함하는 Cache Busting을 사용하여 URL 자체를 변경하면 캐시를 우회할 수 있습니다. Next.js의 assetPrefix와 빌드 해시를 활용하면 자동으로 적용됩니다.
- • DNS TTL로 인한 IP 캐싱 지연
- • Anycast 라우팅의 엣지 서버 변경으로 캐시 불일치
- • Cache Invalidation은 무효화, Purge는 즉시 삭제
- • Cache Busting으로 URL 변경하여 캐시 우회
글로벌 서비스에서 정적 자산 배포 시 모든 사용자에게 최신 버전을 빠르게 전달해야 하는 상황
HTTP Cache-Control 헤더의 max-age, s-maxage, stale-while-revalidate의 차이와 CDN에서의 동작 방식을 설명해주세요.
Q. Next.js API에서 대량의 사용자 활동 로그를 데이터베이스에 저장하는데, 쓰기 성능이 병목이 되고 있습니다. B-Tree 인덱스와 LSM-Tree 인덱스의 구조적 차이를 설명하고, 각각의 읽기/쓰기 성능 특성을 비교해주세요. 또한 Write Amplification 문제와 이를 완화하기 위한 Batch Insert, WAL(Write-Ahead Logging)의 역할을 설명하고, 시계열 데이터 특성을 고려한 파티셔닝 전략을 제시해주세요.
쓰기 중심 워크로드에서 인덱스 구조가 성능에 미치는 영향과 순차 쓰기의 이점을 생각해보세요.
B-Tree는 정렬된 트리 구조로 제자리 업데이트(in-place update)를 하므로 쓰기 시 랜덤 I/O가 발생하고, LSM-Tree는 메모리에 쓰기를 모아 순차적으로 디스크에 flush하므로 쓰기 성능이 우수합니다. B-Tree는 읽기가 빠르지만(O(log n)), LSM-Tree는 여러 레벨을 검색해야 하므로 읽기가 상대적으로 느립니다. Write Amplification은 하나의 논리적 쓰기가 여러 물리적 쓰기를 유발하는 현상으로, LSM-Tree의 compaction과 B-Tree의 페이지 분할에서 발생합니다. Batch Insert는 여러 쓰기를 묶어 한 번에 처리하여 I/O 횟수를 줄이고, WAL은 먼저 로그에 순차 쓰기한 후 비동기로 실제 데이터를 업데이트하여 쓰기 지연을 감소시킵니다. 시계열 데이터는 시간 기반 파티셔닝(일/월 단위)을 적용하여 오래된 파티션은 읽기 전용으로 전환하고, 최신 파티션만 쓰기를 받아 인덱스 유지 비용을 최소화합니다.
- • B-Tree는 제자리 업데이트로 랜덤 I/O, LSM-Tree는 순차 쓰기로 쓰기 성능 우수
- • Write Amplification은 논리적 쓰기가 여러 물리적 쓰기로 증폭
- • Batch Insert와 WAL로 쓰기 I/O 최적화
- • 시간 기반 파티셔닝으로 쓰기 부하 집중 및 오래된 데이터 분리
대규모 이벤트 로깅, 모니터링 메트릭, 사용자 행동 분석 등 쓰기 중심 워크로드를 처리하는 상황
ClickHouse나 TimescaleDB 같은 시계열 전용 데이터베이스가 범용 RDBMS보다 로그 데이터 처리에 유리한 이유를 인덱스와 압축 관점에서 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!