출세한 익룡님의 면접 결과

스레드 풀 크기가 너무 작으면 요청 대기 및 누락이 발생하고, 너무 크면 불필요한 자원 소모가 생긴다는 핵심 트레이드오프를 정확히 짚으셨습니다. 다만 "자원 소모"의 구체적인 내용을 보완하면 더욱 설득력 있는 답변이 될 수 있는데, 스레드가 많아질수록 컨텍스트 스위칭(Context Switching) 비용이 증가하고 각 스레드가 점유하는 스택 메모리(기본 512KB~1MB)가 누적되어 오히려 전체 처리량(Throughput)이 저하될 수 있다는 점을 언급하면 좋습니다. 또한 최적 크기 산정 기준으로 "요청 양"뿐 아니라 CPU 바운드 작업인지 I/O 바운드 작업인지에 따라 공식이 달라진다는 점(예: I/O 바운드의 경우 CPU 코어 수 × (1 + 대기시간/처리시간))도 함께 제시하면 실무 경험이 녹아든 답변으로 한 단계 더 깊어질 수 있습니다.

메모리 점유를 언급하신 것은 맞는 방향이지만, 스레드 과다로 인한 성능 저하의 가장 핵심적인 원인인 **컨텍스트 스위칭(Context Switching) 오버헤드**가 빠져 있습니다. 스레드 수가 CPU 코어 수를 크게 초과하면 OS 스케줄러가 스레드 간 전환을 빈번하게 수행하게 되고, 이 과정에서 레지스터 저장·복원, 캐시 미스 등의 비용이 누적되어 실제 처리량이 오히려 감소합니다. 메모리 측면에서도 단순히 "상시 메모리에 놓는다"는 표현보다는 "각 스레드가 스택 메모리(기본 수백 KB~1MB)를 독립적으로 점유하므로, 수백 개의 유휴 스레드가 수백 MB의 메모리를 낭비한다"고 구체적으로 설명하면 더욱 설득력 있는 답변이 됩니다. 다음에는 "스레드 수 > CPU 코어 수일 때 컨텍스트 스위칭 비용이 증가한다"는 포인트를 꼭 포함해 보세요.

컨텍스트 스위칭이 실행 시간을 늘린다는 방향은 맞게 짚으셨습니다. 다만 질문의 핵심은 "왜 성능이 저하되는가"의 메커니즘이었는데, 결과만 언급하고 원인이 빠진 점이 아쉽습니다. 컨텍스트 스위칭 비용의 핵심은 CPU가 현재 스레드의 레지스터·스택 포인터 등 실행 상태를 TCB(Thread Control Block)에 저장하고 다음 스레드의 상태를 복원하는 데 드는 CPU 사이클, 그리고 스레드 전환 시 CPU 캐시가 무효화되어 발생하는 캐시 미스(cache miss)입니다. 예를 들어 "스레드가 100개로 늘어나면 OS 스케줄러가 빈번하게 TCB를 저장·복원하고 캐시 미스가 누적되어 실제 연산보다 스위칭 오버헤드가 더 커질 수 있다"는 식으로 원인과 결과를 연결해 설명하면 훨씬 완성도 있는 답변이 됩니다.