동기와 비동기, blocking과 non-blocking을 공부하다 보면 거의 반드시 concurrency와 parallelism도 만나게 됩니다. 문제는 이 둘도 말이 비슷해서 같은 뜻처럼 느껴지기 쉽다는 점입니다.
하지만 실제로는 분명히 다른 개념입니다. 둘 다 “여러 작업을 다룬다”는 공통점은 있지만, concurrency는 작업을 겹쳐 다루는 능력에 가깝고, parallelism은 여러 작업이 실제로 동시에 실행되는 상태에 더 가깝습니다.
이 글에서는 아래 내용을 정리합니다.
- concurrency와 parallelism이 각각 무엇인지
- 비동기와는 어떤 관계가 있는지
- 왜 둘을 같은 말로 쓰면 이해가 꼬이는지
핵심은 concurrency는 작업을 번갈아 다루는 구조이고, parallelism은 여러 작업이 같은 시간에 실제로 실행되는 상태라는 점입니다.
Concurrency 란 무엇인가
concurrency는 여러 작업이 한 시스템 안에서 겹쳐 진행될 수 있도록 다루는 능력입니다. 꼭 같은 순간에 물리적으로 실행되지 않아도 됩니다.
예를 들어 하나의 런타임이:
- 작업 A를 조금 진행하고
- 작업 B로 넘어갔다가
- 다시 작업 A를 이어서 처리
하는 식으로 여러 작업을 교차 처리할 수 있다면, 이것은 concurrency 관점에서 여러 작업을 함께 다루고 있는 것입니다.
즉, concurrency의 핵심은 “여러 일을 관리하고 진행시키는 구조”에 있습니다.
Parallelism 이란 무엇인가
parallelism은 여러 작업이 같은 시점에 실제로 동시에 실행되는 상태입니다. 보통은 여러 CPU 코어나 여러 실행 유닛이 필요합니다.
예를 들어:
- 코어 1에서 작업 A 실행
- 코어 2에서 작업 B 실행
처럼 같은 순간에 진짜로 함께 돌아가고 있다면 parallelism입니다.
즉, parallelism의 핵심은 “실행이 물리적으로 겹친다”는 점입니다.
가장 쉬운 비유
요리로 비유하면 감이 빨리 옵니다.
Concurrency
한 명의 요리사가:
- 냄비를 올려 두고
- 그 사이에 재료를 썰고
- 다시 냄비를 확인하는 식으로
여러 작업을 번갈아 다룹니다.
Parallelism
두 명의 요리사가:
- 한 명은 면을 삶고
- 다른 한 명은 소스를 동시에 만들면
같은 시간에 실제로 두 작업이 진행됩니다.
즉, concurrency는 한 사람이 여러 일을 잘 굴리는 느낌이고, parallelism은 여러 사람이 동시에 일하는 느낌에 더 가깝습니다.
왜 둘을 헷갈릴까
겉으로 보면 둘 다 “동시에 여러 일을 처리하는 것처럼” 보이기 때문입니다. 하지만 보는 관점이 다릅니다.
- concurrency: 여러 작업의 진행을 겹쳐서 다룸
- parallelism: 여러 작업이 실제로 동시에 실행됨
그래서 concurrency가 있다고 해서 항상 parallelism이 있는 것은 아니고, parallelism이 있으려면 concurrency 구조가 함께 보이는 경우가 많습니다.
비동기와는 어떤 관계가 있을까
비동기도 여기서 자주 같이 등장합니다. 하지만 비동기 역시 같은 말은 아닙니다.
- 비동기: 기다리는 동안 다른 일을 진행할 수 있는 구조
- concurrency: 여러 작업을 겹쳐 다루는 구조
- parallelism: 여러 작업이 실제로 동시에 실행되는 상태
즉, 비동기 코드는 concurrency를 잘 만들 수 있지만, 그것이 자동으로 parallelism을 의미하지는 않습니다.
예를 들어 JavaScript의 event loop 기반 비동기 코드는 concurrency는 잘 보여주지만, 작업이 항상 여러 CPU에서 병렬 실행되는 것은 아닙니다.
왜 이 차이가 중요할까
이 차이를 이해하면 “비동기인데 왜 CPU가 하나만 바쁘지?” 같은 질문도 풀기 쉬워집니다.
예를 들어:
- 네트워크 요청을 많이 겹쳐 처리한다 -> concurrency
- CPU 연산 여러 개를 여러 코어에서 동시에 돌린다 -> parallelism
즉, 문제의 성격에 따라 필요한 것이 달라집니다.
실무에서 어떻게 보이면 좋을까
I/O 중심 작업
웹 서버, API 호출, 파일 읽기처럼 기다리는 시간이 많은 작업은 concurrency 구조가 특히 중요합니다.
CPU 중심 작업
이미지 처리, 대량 계산처럼 연산량이 많은 작업은 parallelism이 더 중요할 수 있습니다.
즉:
- 기다림이 많은 문제 -> concurrency가 큰 도움
- 계산이 많은 문제 -> parallelism이 더 중요
라고 보면 실무 감각이 잡히기 쉽습니다.
자주 하는 오해
1. 비동기면 자동으로 병렬 처리다
아닙니다. 비동기는 concurrency 구조를 만드는 데 도움을 줄 수 있지만, 병렬 실행과는 다른 이야기입니다.
2. concurrency 와 parallelism 은 같은 말이다
아닙니다. 하나는 구조와 관리 방식, 다른 하나는 실제 실행 상태에 더 가깝습니다.
3. parallelism 이 항상 더 좋다
문제에 따라 다릅니다. I/O 중심 문제에서는 concurrency 설계가 더 직접적인 효과를 줄 수 있습니다.
처음 공부할 때 추천하는 연결
이 개념은 아래 흐름으로 보면 특히 잘 이어집니다.
- 동기 vs 비동기 가이드
- Blocking vs Non-Blocking 가이드
Concurrency vs Parallelism- Event Loop 가이드
즉, “기다리는 방식”을 먼저 이해한 뒤, “여러 작업을 어떻게 굴리는가”로 넘어오는 흐름이 자연스럽습니다.
FAQ
Q. concurrency 가 있으면 parallelism 도 있는 건가요?
항상 그렇지는 않습니다. 하나의 실행 흐름만으로도 concurrency 구조는 만들 수 있습니다.
Q. parallelism 이 있으면 concurrency 도 있는 건가요?
대개 여러 작업을 다룬다는 점에서는 관련이 있지만, 개념적으로는 여전히 구분해서 보는 편이 좋습니다.
Q. JavaScript 는 concurrency 만 있고 parallelism 은 없나요?
기본 실행 모델에서는 concurrency 쪽 설명이 더 자주 맞지만, 환경에 따라 worker 같은 다른 병렬성 도구도 존재할 수 있습니다.
Read Next
- 이런 흐름이 실제 런타임에서 어떻게 돌아가는지 궁금하다면 Event Loop 가이드를 이어서 읽어보세요.
- 더 앞 개념부터 다시 정리하고 싶다면 동기 vs 비동기 가이드와 Blocking vs Non-Blocking 가이드를 같이 보면 좋습니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.