Node.js 미드레벨 CS 기초 기술면접

대용량 로그 데이터의 경우 중간 삽입/삭제가 빈번하다면 Linked List가 O(1) 시간복잡도로 유리하지만, JavaScript는 네이티브 Linked List를 제공하지 않아 직접 구현해야 합니다. Array는 연속된 메모리 할당으로 캐시 지역성이 좋고 인덱스 접근이 O(1)이지만, 중간 삽입/삭제 시 O(n)의 비용이 발생합니다. Linked List는 노드마다 포인터를 저장해야 하므로 메모리 오버헤드가 크고, V8의 최적화를 받기 어려워 실제로는 Array가 더 빠른 경우가 많습니다. 따라서 실무에서는 순차 처리가 주된 경우 Array를, 빈번한 중간 조작이 필요하면 적절한 자료구조 라이브러리 사용을 고려해야 합니다.

HTTP/1.1은 하나의 TCP 연결에서 요청-응답이 순차적으로 처리되어 Head-of-Line Blocking이 발생하지만, HTTP/2는 바이너리 프레이밍 계층을 통해 하나의 연결에서 여러 스트림을 동시에 처리하는 멀티플렉싱을 지원합니다. 각 요청은 고유한 스트림 ID를 가진 프레임으로 분할되어 인터리빙 방식으로 전송되므로 연결 수를 줄이고 레이턴시를 개선할 수 있습니다. Node.js에서는 http2 모듈을 사용하며, 서버 푸시와 헤더 압축(HPACK)으로 추가 성능 향상이 가능합니다. 다만 HTTPS가 필수이고, 레거시 클라이언트 호환성 문제와 단일 TCP 연결의 패킷 손실 시 전체 스트림이 영향받는 점을 고려해야 합니다.

Node.js는 libuv 라이브러리를 통해 파일 I/O 같은 블로킹 작업을 별도의 Thread Pool(기본 4개)에서 처리하여 메인 Event Loop가 블로킹되지 않도록 합니다. fs.readFile()은 작업을 Thread Pool에 위임하고 콜백을 등록한 뒤 즉시 반환하여 Event Loop가 계속 실행되지만, fs.readFileSync()는 메인 스레드에서 직접 시스템 콜을 실행하여 완료될 때까지 블로킹됩니다. 대량의 파일 I/O, 암호화 작업, DNS 조회가 동시에 발생하면 Thread Pool이 고갈되어 다른 비동기 작업까지 지연될 수 있으므로, UV_THREADPOOL_SIZE 환경변수로 크기를 조정해야 합니다. 다만 너무 크게 설정하면 컨텍스트 스위칭 오버헤드가 증가하므로 CPU 코어 수와 작업 특성을 고려해야 합니다.

데이터베이스 인덱스는 대부분 B-Tree 구조로 구현되어 O(log n) 시간에 검색이 가능하며, 리프 노드에 실제 데이터의 포인터를 저장합니다. 인덱스를 과도하게 생성하면 INSERT/UPDATE/DELETE 시 모든 인덱스를 갱신해야 하므로 쓰기 성능이 저하되고, 추가 저장공간이 필요하며, 옵티마이저가 잘못된 인덱스를 선택할 수 있습니다. Covering Index는 쿼리에 필요한 모든 컬럼을 인덱스가 포함하고 있어 테이블 접근 없이 인덱스만으로 결과를 반환할 수 있는 경우입니다. MySQL에서는 EXPLAIN 명령어로 실행 계획을 확인하여 type이 index나 range인지, key 컬럼에 사용된 인덱스가 표시되는지 확인할 수 있습니다.

LRU 캐시는 용량이 가득 찼을 때 가장 오래 사용되지 않은 항목을 제거하는 캐시 정책입니다. O(1) 시간복잡도를 달성하려면 Hash Map과 Doubly Linked List를 함께 사용해야 하며, Hash Map은 키로 빠른 접근을 제공하고 Doubly Linked List는 사용 순서를 유지합니다. get 연산 시 Hash Map으로 노드를 찾아 리스트의 맨 앞으로 이동시키고, put 연산 시 새 노드를 맨 앞에 추가하며 용량 초과 시 리스트 맨 뒤 노드를 제거합니다. JavaScript에서는 Map 객체와 직접 구현한 Doubly Linked List를 사용하거나, ES2015의 Map이 삽입 순서를 보장하는 특성을 활용할 수 있지만 중간 이동이 필요하므로 완전한 LRU 구현을 위해서는 커스텀 구조가 필요합니다.