그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Performance
Performance

스레드, 프로세스, 코어 수는 무조건 많을수록 좋은가요?

실무4/5
설계4/5
인간4/5
기초3/5

면접관의 질문 의도

리소스 수치 증가의 부작용을 알고 있는지, 그리고 "무엇을 측정해 어디서 멈출지" 기준을 말할 수 있는지를 가른다.

큐레이션 답변

학습 자료

스레드·프로세스·코어 수는 워크로드에 맞는 적정값이 있을 뿐, 많다고 좋지 않다. 스레드를 과도하게 늘리면 컨텍스트 스위칭과 락 경합·캐시 미스가 쌓이고, 프로세스는 메모리와 IPC 비용이 따라 붙는다. 코어를 늘려도 작업이 병렬화되지 않으면 처리량은 그대로다. "수를 올린다" 전에 병목이 CPU인지 I/O인지 락인지부터 측정한다.

좋은 답변 구조

  1. 01스레드·프로세스·코어 각각의 특성과 늘렸을 때 따라오는 비용을 구분해 설명한다
  2. 02왜 임계점이 생기는지 — 컨텍스트 스위칭, 락 경합, 메모리 압박, 암달의 법칙으로 풀어낸다
  3. 03CPU 바운드·I/O 바운드 워크로드에 따라 적정값 기준이 어떻게 갈리는지 말한다
  4. 04측정 지표(CPU 사용률, 대기 큐 길이, 락 경합, p99 응답)를 보고 결정한다는 기준으로 마무리한다

자주 실수하는 포인트

스레드·프로세스·코어를 같은 비용 구조로 취급해 세 가지를 묶어 "많을수록 좋다"고 단정한다
병목을 측정하지 않고 풀 사이즈부터 두 배로 키우는 것이 튜닝이라고 설명한다
CPU 바운드 작업에 스레드를 계속 늘려 컨텍스트 스위칭으로 처리량이 떨어지는 역효과를 빠뜨린다
코어를 늘리면 순차 실행 비율과 무관하게 처리량이 선형으로 오른다고 가정한다

실무 맥락

  • JVM 스레드 풀이나 Node.js 워커 수를 운영 트래픽 기준으로 조정해야 하는 백엔드 환경
  • 트래픽이 늘어 응답이 느려지는데 CPU·메모리 지표는 여전히 평탄한 상황
  • 컨테이너 한 대당 CPU·메모리 한도를 정해 비용 효율을 맞춰야 하는 인프라 설계

본인 경험에 녹이는 힌트

스레드 풀이나 워커 수를 올렸는데 응답 시간이 오히려 나빠진 경험이 있다면 "측정 → 임계점 인식 → 되돌리기" 흐름으로 풀어낼 수 있다

CPU 바운드·I/O 바운드 작업에서 풀 사이즈를 다르게 잡아본 경험이 있다면 워크로드 특성과 연결해 기준을 보여 줄 수 있다

장애 회고에서 "수를 먼저 늘리자"는 의견을 잠깐 보류하고 지표 확인부터 한 사례가 있다면 의사결정 기준으로 풀어낼 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1스레드 풀 사이즈는 어떤 지표를 보고 조정하나요
Q2CPU 바운드와 I/O 바운드 작업의 동시성 전략은 어떻게 다른가요
Q3컨텍스트 스위칭 비용은 어떻게 관찰할 수 있나요
Q4암달의 법칙이 병렬화 한계에 어떻게 작용하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문