Node.js 시니어 CS 기초 기술면접
새 면접Q. Bloom Filter의 동작 원리와 False Positive가 발생하는 이유를 설명하고, 실시간 URL 중복 체크 시스템에서 Bloom Filter를 활용할 때 해시 함수 개수(k)와 비트 배열 크기(m)를 결정하는 공식을 설명해주세요. 또한 Node.js 환경에서 수억 개의 URL을 메모리 효율적으로 처리하기 위해 Counting Bloom Filter나 Scalable Bloom Filter 같은 변형을 고려할 때 트레이드오프는 무엇인가요?
확률적 자료구조의 특성과 해시 충돌, 그리고 공간 효율성과 정확도 사이의 트레이드오프를 중심으로 생각해보세요.
Bloom Filter는 k개의 독립적인 해시 함수를 사용해 원소를 m개 비트 배열의 여러 위치에 매핑하는 확률적 자료구조입니다. False Positive는 서로 다른 원소들이 우연히 동일한 비트 위치들을 공유할 때 발생하며, False Negative는 절대 발생하지 않습니다. 최적의 해시 함수 개수는 k = (m/n) * ln(2)이며, False Positive 확률은 (1-e^(-kn/m))^k로 계산됩니다. Counting Bloom Filter는 각 비트를 카운터로 대체해 삭제 연산을 지원하지만 메모리 사용량이 증가하며, Scalable Bloom Filter는 동적으로 필터를 추가해 확장 가능하지만 조회 시간이 증가합니다. Node.js에서는 Buffer나 TypedArray를 사용해 비트 연산을 효율적으로 처리하고, Worker Thread로 해시 계산을 병렬화할 수 있습니다.
- • k개 해시 함수로 m비트 배열에 매핑하는 확률적 자료구조
- • False Positive는 발생 가능하나 False Negative는 불가능
- • 최적 해시 함수 개수 k = (m/n) * ln(2), FP 확률 (1-e^(-kn/m))^k
- • Counting/Scalable 변형은 기능 확장과 메모리/성능 트레이드오프 존재
- • Node.js에서 Buffer 기반 비트 연산과 Worker Thread 병렬화 활용
대용량 웹 크롤러에서 이미 방문한 URL을 메모리 효율적으로 체크하거나, 캐시 시스템에서 존재하지 않는 키에 대한 불필요한 DB 조회를 방지하는 데 사용됩니다.
대규모 분산 시스템에서 여러 노드가 각자의 Bloom Filter를 유지할 때, 전체 시스템의 False Positive 확률을 어떻게 계산하고 관리하시겠습니까?
Q. TLS/SSL 핸드셰이크 과정에서 대칭키를 안전하게 교환하기 위한 전체 과정을 설명하고, RSA 방식과 Diffie-Hellman(DHE/ECDHE) 방식의 차이점을 Forward Secrecy 관점에서 비교해주세요. Node.js HTTPS 서버에서 cipher suite 설정 시 보안과 성능을 균형있게 고려하는 전략과, TLS 1.3에서 개선된 점을 설명해주세요.
비대칭 암호화로 대칭키를 교환하는 과정과, 키 교환 방식에 따른 보안 특성 차이를 중심으로 생각해보세요.
TLS 핸드셰이크는 Client Hello(지원 cipher suite 전송), Server Hello(cipher suite 선택 및 인증서 전송), 키 교환, Finished 메시지 순으로 진행됩니다. RSA 방식은 클라이언트가 pre-master secret을 서버 공개키로 암호화해 전송하지만, 서버 개인키가 유출되면 과거 세션이 모두 복호화되어 Forward Secrecy를 제공하지 못합니다. DHE/ECDHE는 임시 키 쌍을 매 세션마다 생성해 교환하므로 세션별 독립성을 보장하며 Forward Secrecy를 제공합니다. Node.js에서는 ciphers 옵션으로 'ECDHE-RSA-AES128-GCM-SHA256' 같은 AEAD cipher를 우선 배치하고, honorCipherOrder를 true로 설정해 서버 우선순위를 따르게 합니다. TLS 1.3은 핸드셰이크를 1-RTT로 단축하고, 안전하지 않은 cipher suite를 제거했으며, 0-RTT 재개를 지원해 성능을 크게 개선했습니다.
- • TLS 핸드셰이크는 cipher suite 협상, 인증서 검증, 키 교환, 암호화 시작 순서
- • RSA 키 교환은 Forward Secrecy 미제공, DHE/ECDHE는 임시 키로 제공
- • Node.js에서 AEAD cipher 우선 배치 및 honorCipherOrder 설정
- • TLS 1.3은 1-RTT 핸드셰이크, 안전하지 않은 cipher 제거, 0-RTT 재개 지원
- • 보안과 성능 균형을 위해 ECDHE + AES-GCM 조합 권장
금융 API나 개인정보를 다루는 서비스에서 과거 통신 내역이 유출되지 않도록 Forward Secrecy를 보장하는 cipher suite 설정이 필수적입니다.
TLS 1.3의 0-RTT 재개 기능이 보안상 어떤 위험을 가지고 있으며, 어떤 상황에서 사용을 제한해야 할까요?
Q. 데이터베이스 쿼리 옵티마이저가 실행 계획을 수립할 때 사용하는 Cost-Based Optimization(CBO)의 동작 원리를 설명하고, 통계 정보(Cardinality, Selectivity, Histogram)가 어떻게 활용되는지 설명해주세요. Node.js에서 PostgreSQL이나 MySQL을 사용할 때 EXPLAIN ANALYZE 결과를 해석하는 방법과, 옵티마이저가 잘못된 실행 계획을 선택했을 때 힌트나 쿼리 재작성으로 개선하는 전략을 제시해주세요.
옵티마이저가 다양한 실행 계획의 비용을 추정하는 방법과, 통계 정보의 정확성이 실행 계획에 미치는 영향을 생각해보세요.
Cost-Based Optimizer는 가능한 모든 실행 계획의 예상 비용을 계산해 최소 비용 계획을 선택합니다. Cardinality는 결과 행 수 추정치, Selectivity는 조건절이 필터링하는 비율, Histogram은 데이터 분포 정보로 각각 비용 계산에 사용됩니다. 인덱스 스캔 vs 풀 스캔, 조인 순서, 조인 알고리즘(Nested Loop, Hash, Merge) 선택 시 이 통계들이 핵심 역할을 합니다. EXPLAIN ANALYZE 결과에서 estimated rows vs actual rows 차이가 크면 통계 정보가 오래되었거나 부정확한 것이므로 ANALYZE 명령으로 갱신합니다. 옵티마이저가 잘못된 계획을 선택하면 WHERE 조건 순서 변경, CTE 대신 서브쿼리 사용, 인덱스 힌트 추가, 또는 쿼리 분할로 개선할 수 있습니다. Node.js에서는 slow query log를 모니터링하고 주기적으로 통계를 갱신하는 자동화가 중요합니다.
- • CBO는 통계 기반으로 실행 계획 비용을 추정해 최적 계획 선택
- • Cardinality, Selectivity, Histogram으로 결과 행 수와 데이터 분포 파악
- • EXPLAIN ANALYZE에서 estimated vs actual rows 차이로 통계 정확성 판단
- • 통계 오류 시 ANALYZE 갱신, 쿼리 재작성, 힌트로 실행 계획 개선
- • 주기적 통계 갱신과 slow query 모니터링 자동화 필요
대용량 데이터를 다루는 분석 쿼리나 복잡한 조인이 포함된 API에서 실행 계획 분석과 최적화는 응답 시간을 수 초에서 수 밀리초로 단축시킬 수 있습니다.
다중 컬럼 복합 인덱스에서 첫 번째 컬럼의 Selectivity가 매우 낮을 때 옵티마이저가 인덱스를 사용하지 않는 이유는 무엇이며, 어떻게 개선할 수 있을까요?
Q. 파일 시스템의 inode 구조와 역할을 설명하고, 하드 링크와 심볼릭 링크의 차이를 inode 관점에서 비교해주세요. Node.js에서 fs.stat()으로 파일 정보를 조회할 때 inode 번호가 같은 파일들이 존재하는 이유와, 대용량 파일 시스템에서 inode 고갈 문제가 발생하는 시나리오 및 해결 방법을 설명해주세요.
inode가 파일의 메타데이터를 저장하는 방식과, 파일 이름과 실제 데이터의 연결 구조를 생각해보세요.
inode는 파일의 메타데이터(권한, 소유자, 크기, 타임스탬프, 데이터 블록 포인터)를 저장하는 자료구조이며, 파일 이름은 디렉토리 엔트리에 저장되어 inode 번호와 매핑됩니다. 하드 링크는 동일한 inode를 가리키는 여러 디렉토리 엔트리를 생성하므로 inode의 링크 카운트가 증가하며, 원본과 링크를 구분할 수 없고 모든 링크가 삭제되어야 데이터가 해제됩니다. 심볼릭 링크는 별도의 inode를 가지며 대상 경로를 문자열로 저장하는 특수 파일이므로, 원본 삭제 시 깨진 링크가 됩니다. Node.js의 fs.stat()에서 같은 inode 번호는 하드 링크된 파일을 의미합니다. 소형 파일이 대량 생성되면 데이터 블록은 남아도 inode가 고갈될 수 있으며, 이는 파일 시스템 생성 시 inode 비율 조정이나 대용량 파일 시스템으로 마이그레이션으로 해결합니다.
- • inode는 파일 메타데이터와 데이터 블록 포인터를 저장하는 구조체
- • 하드 링크는 동일 inode 공유, 심볼릭 링크는 별도 inode로 경로 저장
- • 하드 링크는 링크 카운트 증가, 원본 삭제 시에도 데이터 유지
- • 소형 파일 대량 생성 시 inode 고갈 가능, 데이터 블록은 충분해도 발생
- • 파일 시스템 생성 시 inode 비율 조정이나 XFS 같은 동적 inode 할당 FS 사용
로그 파일 로테이션 시스템에서 하드 링크를 활용해 디스크 공간을 절약하거나, 빌드 시스템에서 심볼릭 링크로 버전별 라이브러리를 관리하는 데 사용됩니다.
Docker 컨테이너 환경에서 호스트와 컨테이너 간 파일을 공유할 때 inode 번호가 어떻게 처리되며, 이것이 하드 링크 동작에 어떤 영향을 미칠까요?
Q. 대규모 분산 시스템에서 여러 노드가 생성하는 고유 ID를 충돌 없이 생성하기 위한 Twitter Snowflake 알고리즘의 구조를 설명하고, 타임스탬프, 데이터센터 ID, 워커 ID, 시퀀스 번호가 각각 몇 비트로 구성되는지 설명해주세요. 시계 역행(clock skew) 문제가 발생했을 때 중복 ID 생성을 방지하는 전략과, Node.js 클러스터 환경에서 워커별로 고유 ID를 할당하는 구현 방법을 제시해주세요.
64비트 정수를 시간, 노드 식별, 순서 정보로 분할하는 방식과, 시간 기반 ID의 한계를 생각해보세요.
Snowflake 알고리즘은 64비트를 1비트(부호), 41비트(타임스탬프, 밀리초 단위), 10비트(데이터센터 5비트 + 워커 5비트), 12비트(시퀀스 번호)로 구성합니다. 타임스탬프는 커스텀 epoch 이후 경과 시간이며, 같은 밀리초에 최대 4096개 ID를 생성할 수 있습니다. 시계 역행 시 마지막 생성 타임스탬프를 저장해 현재 시간이 과거로 돌아가면 에러를 발생시키거나 시간이 따라잡을 때까지 대기하는 전략을 사용합니다. Node.js 클러스터에서는 각 워커의 cluster.worker.id를 워커 ID로 사용하고, 프로세스 시작 시 Redis나 설정 파일에서 데이터센터 ID를 할당받습니다. 비트 연산으로 각 필드를 조합하며, BigInt를 사용해 JavaScript의 53비트 정수 한계를 넘어 64비트 전체를 활용합니다. 시퀀스 번호는 메모리 변수로 관리하며 밀리초가 바뀌면 0으로 리셋합니다.
- • 64비트를 타임스탬프(41), 데이터센터/워커(10), 시퀀스(12)로 분할
- • 밀리초당 4096개 ID 생성 가능, 시간 순서 보장으로 정렬 효율적
- • 시계 역행 시 마지막 타임스탬프 저장해 중복 방지
- • Node.js에서 cluster.worker.id 활용, BigInt로 64비트 처리
- • 분산 환경에서 데이터센터/워커 ID 중앙 관리 필요
마이크로서비스 아키텍처에서 각 서비스가 독립적으로 주문 ID, 사용자 ID 등을 생성하면서도 전역적으로 고유성을 보장하고 시간 순서를 유지하는 데 사용됩니다.
Snowflake 알고리즘에서 41비트 타임스탬프가 표현할 수 있는 최대 기간은 얼마이며, 이 기간이 지나면 어떻게 대응해야 할까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!