면접질문: 백엔드 개발자 스레드풀 관련 공식과 API서버 과부하 대응방법

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

백엔드 면접에서 스레드풀 크기는 코어 수와 대기·연산 시간 비율로 초기값을 정한 뒤 부하 테스트로 검증하고, I/O 대기가 없는 API 서버 과부하는 스레드 증설보다 스케일 아웃으로 대응해야 한다.

📌 핵심 요점

1. 스레드풀은 스레드 생성·소멸과 컨텍스트 스위칭에 드는 CPU 비용을 줄이기 위해 실행 단위를 미리 만들어 재사용하는 구조입니다.
2. 스레드풀의 초기 크기는 코어 수 × (1 + 대기시간/연산시간)이라는 관점으로 계산할 수 있습니다. 예컨대 대기 90ms와 연산 10ms라면 코어당 약 10개가 출발점이 된다.
3. I/O 대기가 많은 작업은 더 많은 스레드나 논블로킹 I/O로 개선될 여지가 있지만, 대기가 거의 없는 CPU 바운드 작업은 스레드 수를 늘려도 성능 향상이 제한적입니다.
4. 공식은 초기 설정값일 뿐이며 TPS, P99 지연시간, CPU 사용률, 큐 길이, 스레드 상태를 실제와 유사한 부하로 측정해야 최종 크기를 결정할 수 있다.
5. DB와 외부 I/O가 없는 API 서버의 연산 과부하라면 ALB 뒤에 서버 인스턴스를 수평 확장하는 것이 핵심 대응이며, 동기화된 출력이나 로깅이 병목인지도 함께 확인해야 한다.

🧩 배경과 문제 정의

• 현직 백엔드 개발자가 면접에서 받은 두 가지 질문, 즉 자바 스레드풀 크기를 정하는 공식과 DB 부하가 없는 API 서버의 과부하 대응 방법을 해설한다.
• 설명은 Linux 위에서 실행되는 JVM 프로세스, CPU 코어와 스레드의 관계, I/O 대기 유무를 출발점으로 삼아 공식보다 계측과 부하 검증이 중요하다는 결론으로 이어진다.

🕒 시간순 섹션별 상세정리

1. 면접 질문의 두 축

• 질문은 스레드풀을 어떻게 설정할지와 API·백엔드 서버 과부하를 어떻게 해결할지로 요약됩니다. [00:43]
• Linux 환경의 자바 애플리케이션이라는 조건이 제시되고, 답변에는 신중한 검토가 필요했다고 보여준다. [01:11]

2. Linux와 JVM에서 보는 스레드

• Linux의 경량 프로세스 개념과 자바에서 사용하는 스레드라는 표현을 구분하되, 핵심은 JVM 프로세스가 사용자 모드에서 동작한다는 점입니다. [02:00]
• 스레드는 프로세스 안의 실행·연산 단위이며 CPU 하드웨어와 직접 관련됩니다. [02:43]

3. 스레드풀과 컨텍스트 스위칭

• 코어가 8개인데 실행 가능한 스레드가 100개라면 실제 동시 실행은 제한되고 나머지는 CPU 자원을 기다리게 됩니다. [03:57]
• 실행 상태가 교체될 때 레지스터 문맥을 저장하고 복구하는 컨텍스트 스위칭이 발생하며, 이 과정도 CPU를 소비합니다. [04:59]
• 스레드를 반복 생성·소멸하지 않고 풀에서 대기시켜 재사용하면 생성과 스위칭 관련 오버헤드를 줄일 수 있습니다. [06:00]

4. API 서버 질문의 가정과 실행 단위

• 두 번째 질문은 DB나 외부 시스템 I/O 없이 WAS 서비스 계층에서 출력만 수행하는 상황의 과부하 대응을 묻습니다. [07:08]
• 프로세스에는 가상 메모리와 I/O 권한이 주어지고, 그 안의 스레드들은 프로세스 자원을 공유하는 실행 단위입니다. [08:40]

5. 스레드풀 크기 공식

• 스레드 수는 CPU 코어 수의 영향을 받으며, 코어 수와 같으면 스위칭을 줄일 수 있지만 실제 작업에는 대기시간이 존재할 수 있습니다. [09:43]
• 외부 I/O 동안 CPU를 사용하지 않는 시간이 생기므로 연산시간뿐 아니라 대기시간의 비율을 반영해야 합니다. [10:24]
• 대기 90ms, 연산 10ms인 예에서는 코어당 약 10개의 스레드를 초기값으로 볼 수 있다고 보여준다. [11:05]

6. I/O 바운드와 CPU 바운드

• 작업이 I/O 바운드인지 CPU 바운드인지 구분해야 하며, I/O 대기가 길다면 논블로킹 I/O 구조가 성능을 높일 수 있습니다. [11:37]
• 동시 요청량과 평균 처리시간의 관계를 계산하는 리틀의 법칙도 참고 가능한 방식으로 소개됩니다. [11:51]

7. 공식보다 중요한 계측과 부하 시험

• 실제 CPU 사용시간과 대기시간을 프로파일링하는 능력이 중요하고, 공식은 실전의 불명확한 변수까지 설명하는 절대 규칙이 아닙니다. [12:49]
• 공식으로 초기값을 정한 뒤 운영에 가까운 조건의 부하 테스트를 통해 적절한 스레드 수를 산출해야 합니다. [13:28]
• 부하 생성 자체도 실제 부하를 정확히 정의해야 하는 경험적 작업이며 도구로 nGrinder와 Gatling이 제시됩니다. [14:13]

8. 측정 지표와 포트폴리오

• 부하 테스트 경험은 백엔드 취업 포트폴리오에 활용할 수 있으며 TPS와 P99 지연시간을 확인해야 합니다. [14:38]
• CPU 사용률, 큐 적체량, 처리 지연, 스레드풀 내부 상태 변화를 함께 관찰한 뒤 최적값을 결정해야 합니다. [15:20]
• 부하 생성 도구도 실제 운영 환경에 가깝게 사용하는 것이 쉽지 않다고 강조한다. [15:30]

9. 동기화 출력과 CPU 바운드 조건

• 표준 출력의 print 계열 메서드는 동기화로 인해 스레드 상태 변화와 성능 저하를 일으킬 수 있습니다. [16:35]
• 외부 I/O 대기가 없는 조건에서는 WebFlux 같은 논블로킹 I/O 구조로 바꿔도 성능 향상을 기대하기 어렵습니다. [17:00]
• CPU 바운드 작업에서는 스레드 수를 늘리는 효과가 작고 최적 스레드 수는 코어 수에 가까워집니다. [17:40]

10. ALB와 서버 스케일 아웃

• AWS 구조에서는 ALB를 리버스 프록시로 두고 뒤의 EC2 인스턴스에서 여러 API 서버를 운영할 수 있습니다. [18:47]
• 스케일 업은 단일 장비의 사양을 높이고, 스케일 아웃은 비슷한 서버 여러 대로 요청을 분산하는 방식입니다. [19:17]
• I/O 개선과 스레드 증설의 이점이 없는 조건에서는 ALB 뒤의 WAS를 수평 확장하는 것이 사실상의 답이라고 정리한다. [20:27]

11. 오케스트레이션과 로깅 병목

• 클라우드에서 서버가 늘어나면 Docker와 Kubernetes를 포함한 운영 및 오케스트레이션 문제가 뒤따릅니다. [20:49]
• 동기화된 출력 구간은 스레드가 많아도 한 번에 하나만 실행될 수 있으므로 비동기 로깅으로 병목을 줄이는 방안을 검토할 수 있습니다. [21:40]

12. 원인 진단과 마무리

• CPU 사용률이 낮은데 지연이 크다면 락 획득 경쟁이나 동기화 병목이 크게 작용했을 가능성을 확인해야 합니다. [22:10]
• GC, 요청 큐 적체, 예상하지 못한 동시성 문제도 모니터링해 가시성을 확보하고 정확한 원인을 진단해야 합니다. [22:44]
• 네트워크 유입에는 문제가 없다는 가정 아래 스레드풀 계산, 부하 검증, 스케일 아웃을 면접 답변의 흐름으로 제시하며 영상을 마칩니다. [23:12]

🧾 결론

• 스레드풀 공식은 정답이 아니라 실험을 시작하기 위한 초기값입니다.
• CPU 바운드 API에서는 스레드 수 증설이나 WebFlux 전환보다 코어 수에 가까운 실행 구조와 서버 스케일 아웃이 더 직접적인 대응입니다.
• CPU 사용률이 낮은데 지연시간이 크다면 락 경합, 동기화 출력, GC, 요청 큐 적체처럼 다른 병목을 진단해야 한다.
• 최적화의 핵심 역량은 공식을 암기하는 것이 아니라 실제 부하를 정의하고 프로파일링과 모니터링으로 원인을 확인하는 것입니다.

📈 투자·시사 포인트

• 클라우드 기반 API 서비스에서는 단일 서버의 미세 조정보다 로드 밸런서, 수평 확장, 컨테이너 오케스트레이션을 포함한 운영 구조가 확장성을 좌우한다.
• 성능 도구를 도입할 때는 제품 자체보다 실제 트래픽을 재현할 시나리오 설계와 TPS·P99·큐 지표의 해석 역량이 중요한다.
• 논블로킹 프레임워크는 모든 과부하를 해결하는 범용 해법이 아니므로, I/O 대기 비중을 확인하지 않은 기술 전환은 비용만 늘릴 수 있다.
• 백엔드 개발자의 면접과 포트폴리오에서는 nGrinder나 Gatling을 사용한 부하 시험, 측정 결과, 설정 변경 전후 비교를 제시하는 것이 실무 역량을 보여주는 근거가 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 코어 수와 대기·연산 시간 비율로 계산한 스레드 수는 평균값에 기반한 초기 추정치이므로 실제 트래픽 분포와 런타임 환경에서도 적합한지 검증해야 한다.
• 질문의 프린트가 실제로 동기화된 표준 출력인지, 비동기 로깅 프레임워크인지에 따라 락 병목의 크기가 달라질 수 있다.
• 과부하 원인이 CPU인지 네트워크인지, GC인지, 락 경합인지, 큐 적체인지가 측정되지 않았으므로 스케일 아웃만으로 문제가 완전히 해결된다고 단정할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 프로파일링으로 요청별 CPU 연산시간과 I/O 대기시간을 분리해 측정한다.
• 코어 수와 대기시간/연산시간 비율로 스레드풀 초기값을 계산하고 주변 값을 함께 시험한다.
• nGrinder나 Gatling으로 실제 트래픽에 가까운 부하 시나리오를 구성한다.
• TPS, P99 지연시간, CPU 사용률, 큐 길이, 스레드 상태와 GC 지표를 동시에 수집한다.

❓ 열린 질문

• 실제 병목은 높은 CPU 사용률에서 발생합니까, 아니면 CPU 사용률이 낮은 상태에서 락과 큐 대기로 발생합니까?
• 운영 트래픽의 평균값뿐 아니라 피크 구간과 P99에서 대기시간/연산시간 비율은 어떻게 달라집니까?
• 서버를 스케일 아웃했을 때 네트워크, 로드 밸런서, 공유 상태, 로그 처리 계층에 새로운 병목이 생기지 않습니까?