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

Service

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

My

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

Policy

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

© 2026 그알것 · What Still Matters

질문 목록OperatingSystem
OperatingSystem

멀티태스킹 시스템의 한계와 스레드 도입 이유는 무엇인가요?

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

면접관의 질문 의도

스레드가 좋다는 결론이 아니라, 프로세스 대비 비용 구조와 그 대가로 떠안는 동기화 부담을 같이 보는지 가르려는 질문이다.

큐레이션 답변

학습 자료

멀티태스킹은 프로세스 단위로 시간을 나눠 동시 실행감을 만들지만, 프로세스 전환은 메모리 매핑·캐시·페이지 테이블까지 갈아끼우는 무거운 작업이라 자주 일어날수록 비용이 커진다. 또 프로세스 사이는 주소공간이 격리돼 있어 데이터를 주고받으려면 IPC라는 별도 채널을 거쳐야 한다. 스레드는 같은 프로세스의 메모리(특히 힙)를 공유하면서 실행 단위만 가볍게 늘리는 방식이라, 전환 비용이 낮고 협업이 쉬워진다. 대신 공유 메모리에서 가시성·원자성 문제가 새로 생겨 락·CAS·메모리 모델 같은 동기화 비용을 떠안고 가야 하고, 진짜 코어 병렬이 필요하면 멀티프로세싱이라는 또 다른 축을 같이 본다.

좋은 답변 구조

  1. 01멀티태스킹이 가진 프로세스 전환 비용과 데이터 공유 한계를 짚는다
  2. 02스레드가 같은 주소공간을 공유해 무엇을 가볍게 만들었는지 설명한다
  3. 03공유 메모리에서 생기는 가시성·원자성 비용을 동기화 부담으로 정리한다
  4. 04스레드와 멀티프로세싱·메시지 패싱을 작업 성격에 따라 골라 쓰는 기준으로 마무리한다

자주 실수하는 포인트

스레드가 언제나 프로세스보다 우월하다고 단정한다
공유 메모리 동기화 문제를 가볍게 보고 락 없이 끼워 쓴다
프로세스·스레드 전환 비용 차이를 설명하지 못하고 한 덩어리로 묶는다

실무 맥락

  • I/O 바운드 핸들러가 많아 스레드 풀 크기와 큐 길이가 응답 시간에 직접 묻어나는 서버
  • CPU 바운드 작업과 I/O 작업이 한 노드에서 섞여 모델 선택이 처리량을 가르는 환경
  • 공유 상태가 많은 도메인에서 락 경합 때문에 스레드를 늘려도 처리량이 오르지 않는 자리

본인 경험에 녹이는 힌트

스레드 수를 늘렸는데 처리량이 오히려 떨어진 지점을 측정해 본 경험이 있다면 동기화·전환 비용 사례로 연결할 수 있다

공유 상태를 메시지 패싱·불변 객체로 바꿔 락을 줄인 경험이 있다면 동시성 모델 선택 관점에서 말할 수 있다

CPU 바운드 작업을 별도 프로세스로 빼본 적이 있다면 스레드 한계와 멀티프로세싱 자리를 엮을 수 있다

커뮤니티 인기 답변

전체 0개

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

관련 꼬리 질문

Q1스레드 수를 늘릴 때 성능이 역전되는 지점은 왜 생기나요
Q2멀티프로세싱이 더 적합한 작업은 어떤 경우인가요
Q3공유 메모리 대신 메시지 패싱을 선택할 기준은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문