Concurrency and Parallelism

Concurrency and Parallelism

동시성과 병렬성은 현대 시스템 설계에서 성능 최적화의 핵심 개념이다. 동시성은 작업 간 전환을 통해 단일 자원으로 다수 작업을 논리적으로 처리하며, 병렬성은 다중 코어 또는 분산 환경에서 여러 작업을 실제 동시에 실행해 처리량을 극대화한다. 두 개념은 멀티스레딩, 비동기 I/O, GPU 병렬 처리, 분산 시스템 등 다양한 분야에서 상호 보완적으로 사용되며, 시스템의 응답성, 확장성, 자원 효율성을 크게 향상시킨다.

등장 배경 및 발전 과정

• Concurrency 의 필요성은 CPU 의 유휴 자원 방지와 사용자 응답성 확보에서 출발했으며, 멀티태스킹 OS, GUI 환경, 네트워크 서비스로 이어지며 발전했다.
• Parallelism 의 발전은 물리적 제약 (CPU 단일코어) 의 극복을 위한 하드웨어 진보 (멀티코어, GPU) 와 맞물려 성능 향상을 목적으로 발전해왔다.
• 최근에는 클라우드, 분산 시스템, AI/ML, IoT 환경의 확산으로 병렬성과 동시성을 동시에 활용하는 설계가 일반화되었다.
• 특히, 비동기 처리 모델(Promise, async/await, Rx, coroutine 등) 과 Actor Model, Dataflow 등의 설계 패턴은 실시간성과 확장성을 동시에 요구하는 현대 시스템에서 핵심 기술로 자리잡고 있다.

목적 및 필요성

1. 성능 향상 및 처리량 극대화

   • 병렬 실행을 통해 CPU 대기 시간을 줄이고, 단위 시간당 처리 가능한 작업 수 (Throughput) 를 증가시킴.
   • I/O 작업이 지연될 때 다른 작업을 선점하여 전반적인 실행 효율을 높임.\
   • CPU-bound 와 I/O-bound 작업을 분리 처리하여 자원 낭비 없이 동시 운영 가능.

2. 응답성 (Responsiveness) 향상

   • 사용자 인터페이스 (UI) 에서 긴 작업이 전체 시스템을 블로킹하지 않도록 비동기 처리로 응답성 유지.
   • 웹 서버나 모바일 앱에서 수백~수천 개의 요청을 동시에 수용 가능하게 하여 지연 감소.

3. 자원 활용 최적화

   • 멀티코어/멀티스레드 하드웨어를 최대한 활용하여 하드웨어 투자 대비 효율 극대화.
   • 네트워크, 메모리, 디스크 등의 자원에 대한 접근 충돌을 제어하여 낭비 없이 처리.

4. 확장성 (Scalability) 확보

   • 병렬 처리를 통해 하드웨어 스케일 업/스케일 아웃 시 성능 선형 증가 가능.
   • 마이크로서비스, 분산 시스템, 클라우드 환경 등에서 수평 확장을 자연스럽게 지원.

5. 실시간 및 반응형 시스템 구현

   • 실시간 게임, 금융 시스템, IoT 등에서 이벤트를 지연 없이 병렬·동시 처리 가능.
   • 사용자 중심의 빠른 피드백 루프가 필요한 서비스에서 필수적인 요구사항 충족.

6. 코드 구조의 모듈화 및 유지보수성 향상

   • 독립적인 작업 단위를 스레드/프로세스로 분리하면 코드의 관심사 분리 (Separation of Concerns) 효과가 발생.
   • 테스트, 디버깅, 장애 격리, 로깅 등 운영 측면에서도 구조적 장점 제공.

핵심 개념

• 동시성 (Concurrency) 은 논리적 구조 설계 측면에서 시스템의 응답성과 유연성을 확보하며, 주로 I/O 바운드 환경이나 사용자 인터페이스, 서버 애플리케이션에서 많이 사용된다.
• 병렬성 (Parallelism) 은 실제로 작업을 병렬로 처리하여 처리 속도를 높이는 실행 최적화 수단으로, CPU 바운드 작업, 과학적 계산, 대용량 데이터 분석에 적합하다.
• 실무에서는 두 개념이 종종 결합되어 사용되며, 시스템의 목적에 따라 적절한 모델을 선택하고, 스레드 수, 메모리 최적화, 병목 제거 등과 같은 성능 튜닝 기법과 연계되어야 한다.
• 동기화 전략, 예외 처리, 테스트 및 모니터링 체계까지 포함된 전방위적 접근이 필요하며, 병행 처리의 안정성과 성능을 모두 확보하는 것이 핵심이다.

개념 비교 요약

실무 구현 관점 정리

시스템 설계 관점

프로그래밍 구현 관점

성능 최적화 관점

개념 확장: 관련 기술 및 구성 요소

주요 기능 및 역할

• **동시성 (Concurrency)**은 하나의 프로세서에서도 여러 작업을 논리적으로 동시에 처리하기 위한 기술로, 시분할, 비동기 처리, 이벤트 루프, 컨텍스트 스위칭, 동기화 등의 기능을 통해 UI 응답성, 서버 처리율, 자원 활용도를 높이는 데 중점을 둔다.

• **병렬성 (Parallelism)**은 실제로 여러 프로세서나 코어에서 작업을 물리적으로 동시에 실행하는 기술로, 데이터/작업/파이프라인 병렬성, 스케줄링, 멀티코어 활용 등을 통해 연산 속도 및 대규모 데이터 처리 성능을 극대화한다.

• 공통 기능 및 역할로는, 자원 충돌 방지를 위한 동기화 처리, 교착 상태 및 기아 상태 대응, 연산/데이터 분할, 시스템 확장성 확보, 응답성과 처리량 향상 등이 있다. 이러한 기능은 성능 최적화, 안정성 강화, 확장성 확보라는 궁극적 목적과 직결된다.

특징

• 개념적 차이: 동시성은 구조적 설계 기법으로 여러 작업을 병렬처럼 보이게 하는 데 초점을 두며, 병렬성은 하드웨어 기반 처리 모델로 실제 동시에 여러 작업을 수행하는 실행 중심 개념이다.

• 실행 예측성과 안정성: 동시성은 실행 순서의 비결정성으로 인해 디버깅과 테스트가 어렵고 동기화가 중요하다. 병렬성은 계산 단위가 분리되면 예측 가능한 결과를 만들 수 있으나, 자원 동기화와 커뮤니케이션 오버헤드가 존재한다.

• 성능 목표 차이: 동시성은 주로 응답 시간 최소화 및 처리 유연성을, 병렬성은 처리 속도 극대화 및 대규모 작업 효율화를 목표로 한다.

• 구현 시 고려사항:

  • 동시성은 이벤트 기반, 코루틴, 비동기 처리 모델과 밀접하고, 프로그램 흐름 제어와 자원 보호 중심으로 설계됨.
  • 병렬성은 CPU 코어 수, 데이터 분할 전략, 작업 간 종속성 여부에 따른 구조적 분리 및 최적화가 핵심이다.

• 공통의 과제: 두 방식 모두 공유 자원 접근에 대한 동기화, 예외 처리, 병목 분석, 테스트 전략이 중요하며, 운영체제 스케줄러와 메모리 모델의 영향을 받는다.

핵심 원칙

• 정합성 보장 원칙은 시스템 내 상태가 항상 예측 가능하고 유효하게 유지되도록 보장하며, 특히 트랜잭션/데이터 처리 환경에서 중요하다. (ACID 원칙과 일맥상통)

• 자원 경쟁 제어 원칙은 동시 자원 접근 시 충돌을 막기 위한 필수 규칙으로, 스레드 안전성과 데이터 무결성의 핵심 기반이다.

• 공정성과 안정성 원칙은 시스템이 특정 프로세스에 편향되지 않고, 모든 요청이 일정 시간 안에 처리되도록 보장한다. 이는 고가용성과 실시간성 보장에 직접적 영향을 준다.

• 효율성 원칙은 자원의 낭비를 줄이고 시스템 확장을 용이하게 하며, 특히 대규모 시스템 또는 클라우드 네이티브 환경에서 중요한 고려 사항이다.

Concurrency vs. Parallelism 비교

• Concurrency는 여러 작업을 구조적으로 겹쳐 실행하는 설계 중심의 개념이며, 응답성과 자원 활용 최적화에 초점을 둔다.
• Parallelism은 여러 작업을 물리적으로 동시에 처리하는 실행 중심의 개념이며, 처리 성능과 대규모 연산 처리에 초점을 둔다.
• 두 개념은 서로 배타적이지 않으며, 하나의 시스템에서 동시에 사용되는 경우도 많다. 예: Node.js 서버에서 async 로 요청을 처리하면서, 백엔드에서는 멀티프로세싱으로 데이터 처리.
• 적용 시에는 작업 특성 (I/O vs CPU), 하드웨어 환경, 설계 복잡도, **성능 목표 (지연 vs 처리량)**를 고려하여 선택 또는 조합해야 한다.

개념 및 실행 모델

구현 기술 및 언어 기능

성능 및 리소스 특성

문제점 및 제약

적용 영역 비교

아키텍처

동시성 아키텍처

graph TB
    A[메인 스레드] --> B[작업 큐]
    B --> C[스케줄러]
    C --> D[컨텍스트 스위칭]
    D --> E[작업 1]
    D --> F[작업 2]
    D --> G[작업 3]
    
    E --> H[I/O 대기]
    F --> I[CPU 처리]
    G --> J[네트워크 대기]
    
    H --> D
    I --> D
    J --> D
    
    style A fill:#e1f5fe
    style C fill:#f3e5f5
    style D fill:#fff3e0

병렬성 아키텍처

graph TB
    A[작업 분배기] --> B[작업 분할]
    B --> C[서브태스크 1]
    B --> D[서브태스크 2]
    B --> E[서브태스크 3]
    B --> F[서브태스크 4]
    
    C --> G[코어 1]
    D --> H[코어 2]
    E --> I[코어 3]
    F --> J[코어 4]
    
    G --> K[결과 1]
    H --> L[결과 2]
    I --> M[결과 3]
    J --> N[결과 4]
    
    K --> O[결과 통합]
    L --> O
    M --> O
    N --> O
    
    O --> P[최종 결과]
    
    style A fill:#e8f5e8
    style B fill:#fff3e0
    style O fill:#f3e5f5

작동 원리

동시성의 작동 원리

sequenceDiagram
    participant S as 스케줄러
    participant T1 as 작업1
    participant T2 as 작업2
    participant T3 as 작업3
    participant CPU as CPU
    
    S->>CPU: 작업1 시작
    CPU->>T1: 실행 (시간 슬라이스)
    T1-->>CPU: I/O 대기 발생
    CPU->>S: 컨텍스트 저장
    
    S->>CPU: 작업2 시작  
    CPU->>T2: 실행 (시간 슬라이스)
    T2-->>CPU: 시간 만료
    CPU->>S: 컨텍스트 저장
    
    S->>CPU: 작업3 시작
    CPU->>T3: 실행 (시간 슬라이스)
    T3-->>CPU: 완료
    
    S->>CPU: 작업1 재개
    CPU->>T1: 실행 (I/O 완료)
    T1-->>CPU: 완료

병렬성의 작동 원리

sequenceDiagram
    participant M as 마스터
    participant D as 분배기
    participant C1 as 코어1
    participant C2 as 코어2
    participant C3 as 코어3
    participant C4 as 코어4
    participant A as 통합기
    
    M->>D: 전체 작업 전달
    D->>D: 작업 분할
    
    par 병렬 실행
        D->>C1: 서브태스크1
        and
        D->>C2: 서브태스크2
        and
        D->>C3: 서브태스크3
        and
        D->>C4: 서브태스크4
    end
    
    par 동시 처리
        C1->>A: 결과1
        and
        C2->>A: 결과2
        and
        C3->>A: 결과3
        and
        C4->>A: 결과4
    end
    
    A->>A: 결과 통합
    A->>M: 최종 결과

공통점과 차이점

공통점

두 방식 모두 시스템의 효율적 자원 활용과 성능 향상을 목적으로 하며, 스케줄링, 동기화, 복잡한 제어 흐름을 포함하고 있어 실무 시스템에서 핵심적인 역할을 한다는 점이다.

차이점

동시성이 **논리적 겹침 (설계 구조)**에 기반한 반면, 병렬성은 물리적 동시 실행 (실제 처리) 에 기반한다. 하드웨어 의존성, 구현 난이도, 적용 영역도 명확히 다르며, 각각의 문제 해결 전략도 다르다.
실무에서는 종종 두 개념이 조합되어 사용되며, 예를 들어 웹 서버는 비동기적으로 동시성을 유지하면서, 백엔드 연산은 병렬 처리로 처리량을 높이는 구조가 일반적이다.

구현 기법 및 방법

• Concurrency는 " 많은 작업을 동시에 관리한다 " 는 개념이며, 주로 비동기 처리, UI 응답성, I/O 작업 최적화에 사용된다.
• Parallelism은 " 많은 작업을 동시에 실행한다 " 는 개념이며, 주로 대량 데이터 처리, 과학 연산, 머신러닝 학습 등 CPU 중심 병렬 처리를 목표로 한다.
• 동시성은 논리적 동시 실행, 병렬성은 물리적 동시 실행을 의미한다.

동시성 (Concurrency)

• 동시성 구현 기법은 단일 스레드 혹은 단일 자원 (CPU 등) 내에서 작업 간 전환을 효율적으로 관리하는 데 중점을 둔다.
  예: 비동기 I/O, 이벤트 기반 처리, 코루틴, 액터 모델 등은 실제로 동시에 실행되지 않지만 " 동시처럼 " 보이도록 스케줄링하거나 전환한다.
  대표적인 목적은 응답성 향상, 자원 블로킹 최소화, 낮은 메모리 비용이다.

Thread-Based Concurrency

graph TD
    A[Main Process] -->|Creates| T1[Thread 1]
    A -->|Creates| T2[Thread 2]
    T1 -->|Access| R[Shared Resource]
    T2 -->|Access| R
    R -->|Protected by| L[Lock / Semaphore]

구현 예시:

• Thread + Lock

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import threading

counter = 0
lock = threading.Lock()

def increase():
    global counter
    for _ in range(100000):
        with lock:  # 임계 영역 보호
            counter += 1

t1 = threading.Thread(target=increase)
t2 = threading.Thread(target=increase)

t1.start()
t2.start()
t1.join()
t2.join()

print("최종 카운터:", counter)

Async IO (Event Loop-Based Concurrency)

graph TD
    A[Main Thread] --> EL[Event Loop]
    EL --> T1[Task 1: Network I/O]
    EL --> T2[Task 2: File I/O]
    T1 -->|await| EL
    T2 -->|await| EL

구현 예시:

• asyncio + await

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

import asyncio

async def do_work(name, sec):
    print(f"{name} 시작")
    await asyncio.sleep(sec)
    print(f"{name} 완료")

async def main():
    await asyncio.gather(
        do_work("작업1", 2),
        do_work("작업2", 1)
    )

asyncio.run(main())

Coroutine (Generator-Based Concurrency)

graph LR
    Main[Main Function] --> G1[Coroutine A]
    Main --> G2[Coroutine B]
    G1 -->|yield| Main
    Main -->|resume| G2

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

def coroutine():
    print("시작")
    yield "중단1"
    print("다시 실행")
    yield "중단2"
    print("종료")

co = coroutine()
print(next(co))   # 시작 → 중단1
print(next(co))   # 다시 실행 → 중단2

Actor Model (Message Passing)

graph TD
    A1[Actor 1] -->|send msg| A2[Actor 2]
    A2 -->|process msg| A3[Actor 3]
    A3 -->|send response| A1

구현 예시:

• Actor-like with Queue

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import threading
import queue

def actor(mailbox):
    while True:
        msg = mailbox.get()
        if msg == "STOP":
            break
        print(f"수신 메시지: {msg}")

mailbox = queue.Queue()
actor_thread = threading.Thread(target=actor, args=(mailbox,))
actor_thread.start()

mailbox.put("헬로")
mailbox.put("월드")
mailbox.put("STOP")
actor_thread.join()

Software Transactional Memory (유사 구현)

graph TD
    A[Transaction Start] --> R1[Read Var A]
    R1 --> W1[Write Var A]
    W1 --> CM[Commit Manager]
    CM -->|Check Conflicts| RS[Rollback/Commit]

구현 예시:

• Atomic + Lock 사용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import threading

balance = 1000
lock = threading.Lock()

def transfer(amount):
    global balance
    with lock:
        if balance >= amount:
            balance -= amount
            print(f"이체 성공: {amount}, 잔액: {balance}")
        else:
            print("잔액 부족")

threads = [threading.Thread(target=transfer, args=(300,)) for _ in range(5)]

for t in threads:
    t.start()
for t in threads:
    t.join()

병렬성 (Parallelism)

• 병렬성 구현 기법은 여러 스레드/프로세서/노드에서 여러 작업을 실제로 동시에 실행하는 데 중점을 둔다.
  예: 멀티프로세싱, GPGPU, 분산 시스템 등은 연산을 분할하여 동시에 수행함으로써 처리 속도 향상, 확장성 확보, 대규모 연산 최적화에 효과적이다.

Process-Based Parallelism (멀티프로세스 기반)

graph TD
    A[Main Process] --> P1[Process 1]
    A --> P2[Process 2]
    P1 --> T1[Task A]
    P2 --> T2[Task B]

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

from multiprocessing import Process

def task(name):
    print(f"{name} 작업 시작")

if __name__ == '__main__':
    p1 = Process(target=task, args=("A",))
    p2 = Process(target=task, args=("B",))
    p1.start()
    p2.start()
    p1.join()
    p2.join()

Data Parallelism (데이터 병렬 처리)

graph TD
    A[Main Program] --> D1[Data Chunk 1] --> P1[Worker 1]
    A --> D2[Data Chunk 2] --> P2[Worker 2]
    A --> D3[Data Chunk 3] --> P3[Worker 3]
    P1 --> R1[Result 1]
    P2 --> R2[Result 2]
    P3 --> R3[Result 3]
    R1 --> R[Result Merge]
    R2 --> R
    R3 --> R

구현 예시:

• with multiprocessing.Pool

1
2
3
4
5
6
7
8
9

from multiprocessing import Pool

def square(n):
    return n * n

if __name__ == '__main__':
    with Pool(4) as pool:
        results = pool.map(square, range(10))
    print("병렬 결과:", results)

Task Parallelism (태스크 병렬 처리)

graph TD
    A[Main Program] --> T1[Task: Encode Video]
    A --> T2[Task: Upload File]
    A --> T3[Task: Notify User]
    T1 --> Done1
    T2 --> Done2
    T3 --> Done3

구현 예시:

• with concurrent.futures

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

from concurrent.futures import ProcessPoolExecutor

def encode():
    return "영상 인코딩 완료"

def upload():
    return "파일 업로드 완료"

def notify():
    return "유저 알림 완료"

with ProcessPoolExecutor() as executor:
    futures = [
        executor.submit(encode),
        executor.submit(upload),
        executor.submit(notify)
    ]
    for future in futures:
        print(future.result())

Pipeline Parallelism (파이프라인 병렬 처리)

graph TD
    A[Data Input] --> S1[Stage 1: Parse]
    S1 --> S2[Stage 2: Transform]
    S2 --> S3[Stage 3: Save]

구현 예시:

• Queue + Process 기반 파이프라인

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

from multiprocessing import Process, Queue

def stage1(q_out):
    for i in range(5):
        q_out.put(f"raw_{i}")

def stage2(q_in, q_out):
    while not q_in.empty():
        item = q_in.get()
        q_out.put(item.upper())

def stage3(q_in):
    while not q_in.empty():
        print(f"저장: {q_in.get()}")

if __name__ == '__main__':
    q1 = Queue()
    q2 = Queue()

    p1 = Process(target=stage1, args=(q1,))
    p2 = Process(target=stage2, args=(q1, q2))
    p3 = Process(target=stage3, args=(q2,))

    p1.start(); p1.join()
    p2.start(); p2.join()
    p3.start(); p3.join()

GPU-Based Parallelism (병렬 연산을 위한 GPU 사용)

graph TD
    A[Main Program] --> G[GPU Kernel]
    G -->|Parallel Cores| C1[Core 1]
    G --> C2[Core 2]
    G --> C3[Core 3]
    G --> Cn[Core N]

구현 예시:

• NumPy 로 병렬 연산 시뮬레이션

1
2
3
4
5
6
7

import numpy as np

a = np.random.rand(1000000)
b = np.random.rand(1000000)

c = a * b  # 벡터화된 병렬 연산 (NumPy 내부적으로 SIMD나 OpenMP 사용 가능)
print("연산 완료:", c[:5])

※ 실제 GPU 병렬 연산은 Numba, CuPy, PyCUDA 등에서 지원하며 위 예시는 CPU 벡터화 시뮬레이션.

Fork-Join (작업 분할)

graph TD
    Main[Main Task] --> F1[Subtask A]
    Main --> F2[Subtask B]
    F1 --> J[Join Point]
    F2 --> J
    J --> R[Result Aggregation]

구현 예시:

• concurrent.futures

1
2
3
4
5
6
7
8

from concurrent.futures import ThreadPoolExecutor

def square(n):
    return n * n

with ThreadPoolExecutor(max_workers=4) as executor:
    results = list(executor.map(square, range(10)))
    print("결과:", results)****

도전 과제

• 공통 과제는 대부분의 시스템이 겪는 동시 접근 문제 (Race, Deadlock, Resource Contention 등) 이며, 구조적 설계와 테스트 도구로 제어 가능하다.

• 동시성 특화 과제는 비결정성과 스레드 간 통신 구조가 핵심이며, 비동기 프로그래밍 패턴과 스케줄링 전략이 중요하다.

• 병렬성 특화 과제는 작업 분할 전략과 메모리 일관성 보장이 성능 병목의 원인이며, 병렬 프로그래밍 모델 선택과 최적화 알고리즘이 필수다.

• 확장성 및 미래 기술 과제는 AI, 양자, 이기종 처리 환경 등 복잡한 연산 패러다임이 혼합된 구조로 진입하고 있으며, 자동화와 인터페이스 표준화가 관건이다.

공통 도전 과제

데드락 (Deadlock)

여러 스레드나 프로세스가 서로 자원을 점유한 채 상대 자원을 기다리며 무한 대기 상태가 되는 현상

1. 상호 배제 (Mutual Exclusion)
2. 점유와 대기 (Hold and Wait)
3. 비선점 (No Preemption)
4. 순환 대기 (Circular Wait)
   등으로 인하여 발생한다.

실제 시스템 사례

PostgreSQL 트랜잭션 충돌

• 두 개의 트랜잭션이 동시에 서로의 Row-Level Lock 을 요청하면서 교착 상태 발생.
• 트랜잭션 A: UPDATE users SET email=… WHERE id=1
• 트랜잭션 B: UPDATE orders SET status=… WHERE user_id=1

장애 발생 플로우

sequenceDiagram
    participant TxA as 트랜잭션 A
    participant TxB as 트랜잭션 B
    participant DB as DB 락 매니저

    TxA->>DB: Row-Lock(users.id=1) 요청
    DB-->>TxA: 락 획득 성공
    TxB->>DB: Row-Lock(orders.user_id=1) 요청
    DB-->>TxB: 락 획득 성공
    TxA->>DB: Row-Lock(orders.user_id=1) 요청 (TxB가 점유 중)
    TxB->>DB: Row-Lock(users.id=1) 요청 (TxA가 점유 중)
    DB-->>All: 교착 상태 감지
    DB-->>TxB: TxB 롤백

탐지/진단

• PostgreSQL pg_stat_activity, pg_locks 뷰 조회
• 로그 분석 (log_lock_waits = on)
• DEADLOCK DETECTED 메시지 탐지

예방 및 해결 전략

• 자원 요청 순서 통일
• 타임아웃 설정 (lock_timeout)
• 락 범위 최소화 (작은 트랜잭션으로 쪼개기)

Python 구현 예시 (락 순서 통일)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import threading
import time

lock_a = threading.Lock()
lock_b = threading.Lock()

def task(lock1, lock2):
    with lock1:
        time.sleep(0.1)
        with lock2:
            print("작업 완료")

# 두 스레드가 동일한 순서로 락 요청 (Deadlock 예방)
t1 = threading.Thread(target=task, args=(lock_a, lock_b))
t2 = threading.Thread(target=task, args=(lock_a, lock_b))

t1.start()
t2.start()

레이스 컨디션 (Race Condition)

둘 이상의 스레드가 공유 자원에 동시에 접근하고, 그 결과가 실행 순서에 따라 달라지는 문제

• 동기화되지 않은 공유 상태 접근 및 비원자적 연산 수행
  로 인해 발생한다.

실제 시스템 사례

Node.js 기반 채팅 서버에서 메시지 순서 꼬임

• 동일한 사용자에게 동시에 두 메시지가 전송되었지만, 네트워크 지연과 콜백 충돌로 순서가 뒤바뀜.
• socket.emit() 이 논리적 순서를 보장하지 않음.

장애 발생 플로우

sequenceDiagram
    participant Client as 클라이언트
    participant Server as Node.js 서버
    participant Network as 네트워크

    Client->>Server: 메시지1 전송 요청
    Client->>Server: 메시지2 전송 요청
    Server->>Network: 메시지2 먼저 송신
    Server->>Network: 메시지1 송신 (지연 발생)
    Network-->>Client: 메시지2 도착
    Network-->>Client: 메시지1 도착
    Note right of Client: 메시지 순서 역전 → 논리 오류 발생

탐지/진단

• Node.js 에서는 --trace-sync-io, async_hooks 모듈 사용
• Jest, Mocha + race detection 도구 적용
• 테스트 중 비결정적 결과 확인

예방 및 해결 전략

• Queue 처리 로직 추가
• 비동기 순서 보장 (Promise chaining)
• 불변 데이터 구조 도입

JavaScript 구현 예시 (순서 보장 큐)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

const messageQueue = [];
let processing = false;

function enqueueMessage(message) {
  messageQueue.push(message);
  processQueue();
}

async function processQueue() {
  if (processing) return;
  processing = true;

  while (messageQueue.length > 0) {
    const msg = messageQueue.shift();
    await sendMessage(msg);  // 순차 처리
  }

  processing = false;
}

async function sendMessage(msg) {
  return new Promise((resolve) => {
    setTimeout(() => {
      console.log("보낸 메시지:", msg);
      resolve();
    }, 100);
  });
}

// 순서 보장됨
enqueueMessage("Hello");
enqueueMessage("World");

동시성 특화 도전 과제

기아 상태 (Starvation)

특정 스레드나 프로세스가 자원을 계속 배정받지 못해 실행되지 못하는 현상

• 자원 우선순위 정책이 낮은 스레드를 무한정 대기시키는 경우
  등으로 인해 발생한다.

실제 시스템 사례

Linux 우선순위 기반 스케줄러 (CFS):

• Linux 의 Completely Fair Scheduler(CFS) 에서는 nice 값이 낮은 (high priority) 프로세스가 CPU 를 점유하면서 nice 값이 높은 (low priority) 프로세스가 CPU 를 획득하지 못해 기아 상태에 빠질 수 있음
• 특히 실시간 프로세스와 사용자 프로세스 간 자원 경합이 존재할 때 자주 발생

장애 발생 플로우

sequenceDiagram
    participant CPU
    participant TaskA as 실시간 작업 A (High Priority)
    participant TaskB as 사용자 작업 B (Low Priority)

    Note over CPU: 우선순위 기반 스케줄링 시작

    loop 무한 반복
        TaskA->>CPU: 실행 요청 (높은 우선순위)
        CPU-->>TaskA: 실행 권한 부여
        Note over TaskB: 실행 요청했지만 대기 상태
    end

    Note over TaskB: 계속된 대기 → 기아 상태 진입

탐지/진단

• top 명령어에서 PR, NI 값 확인
• CPU Time 이 오랫동안 0 인 상태 확인
• 스레드 대기 시간 로그 분석

예방 및 해결 전략

• Aging (대기 시간에 따라 우선순위 증가)
• Fair Scheduler 사용
• 우선순위 역전 방지 (Priority Inheritance)

Python 구현 예시 (Aging 기반 공정 스케줄러 시뮬레이션)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import heapq
import time

# (우선순위, 대기 시간, 작업 이름)
waiting_tasks = [
    [5, 0, 'Task-A'],
    [10, 0, 'Task-B'],  # 낮은 우선순위 → Aging 적용
]

def scheduler():
    for _ in range(5):
        # Aging: 대기 시간 반영 → 우선순위 조정
        for task in waiting_tasks:
            task[0] -= 1  # 우선순위 숫자가 낮을수록 우선됨
            task[1] += 1
        # 정렬 후 실행
        heapq.heapify(waiting_tasks)
        task = heapq.heappop(waiting_tasks)
        print(f"[실행] {task[2]} (우선순위={task[0]}, 대기={task[1]})")
        time.sleep(0.1)
        heapq.heappush(waiting_tasks, task)

scheduler()

병렬성 특화 도전 과제

부하 불균형 (Load Imbalance)

병렬 처리 시 작업이 균등하게 분배되지 않아 일부 스레드 또는 코어가 과부하되는 현상

• 작업 단위의 불균형
• 정적 스케줄링
• 동적 분배 실패
  등으로 인해 발생한다.

실제 시스템 사례

Apache Spark 클러스터 작업 불균형

• 특정 Task 는 매우 작은 파일을 처리하고, 다른 Task 는 수백 MB 의 Parquet 파일을 처리하면서 일부 Executor 가 오랫동안 idle 상태 유지.

장애 발생 플로우

flowchart TD
    A[Job Submit: 100개 작업] --> B1[Executor-1: 90% 완료]
    A --> B2["Executor-2: 5% 완료 (대형 파일)"]
    A --> B3[Executor-3: Idle]
    B1 --> C[전체 Job 지연 발생]
    B2 --> C
    B3 --> C
    C --> D{Spark DAG Scheduler}
    D -->|탐지 불가| E[수동 튜닝 필요]

탐지/진단

• Spark UI 의 Task/Stage 별 Executor 별 작업 수 시각화
• 실행 시간 편차, idle core 탐지
• 실시간 Metrics (Ganglia, Prometheus)

예방 및 해결 전략

• 동적 워크로드 분배 (Work Stealing)
• Task granularity 조정
• Data locality 고려

Python 구현 예시 (Work Stealing 구조)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

from queue import Queue
import threading
import time

task_queues = [Queue() for _ in range(4)]

# 작업 스레드
def worker(index):
    while True:
        try:
            task = task_queues[index].get_nowait()
        except:
            # 다른 큐에서 steal
            for i, q in enumerate(task_queues):
                if i != index and not q.empty():
                    task = q.get()
                    break
            else:
                break  # 종료
        print(f"Worker {index} 처리: {task}")
        time.sleep(0.1)

# 작업 분배
for i in range(10):
    task_queues[i % 2].put(f"Task-{i}")  # 일부 큐에만 몰림

# 워커 실행
threads = [threading.Thread(target=worker, args=(i,)) for i in range(4)]
[t.start() for t in threads]
[t.join() for t in threads]

미래 기술 및 확장성 도전 과제

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

• 설계 전략에서는 작업 특성 (I/O vs CPU 바운드) 을 정확히 분석하고, 그에 따라 적절한 동시성 모델과 리소스 분리를 설계하는 것이 핵심이다. 공유 상태는 가능한 줄이고, 메시지 기반 통신 구조를 활용하여 독립성과 확장성을 확보해야 한다.

• 동기화 및 락 관리는 데드락 및 레이스 컨디션을 방지하고, 임계 구역을 최소화하는 방식으로 병목을 줄이는 것이 중요하다. 필요 시 lock-free 또는 CAS 기반 구조로 전환하며, 락 획득 순서를 일관되게 유지하는 설계가 요구된다.

• 스레드 및 리소스 관리에서는 스레드 수를 하드웨어에 맞게 조정하고, 컨텍스트 스위칭 비용을 줄이기 위한 전략 (예: batching, affinity 설정 등) 을 도입해야 한다. Python 의 경우 GIL 우회 전략도 함께 필요하다.

• 안정성과 오류 대응에서는 비결정적 에러의 디버깅 난이도를 고려해 예외 처리를 격리하고, 자원 회수 루틴을 명확히 설계해야 한다. race condition, deadlock 발생 가능성을 항상 염두에 두고 체계적인 오류 대응 방식을 포함해야 한다.

• 모니터링 및 테스트는 병렬/동시성 시스템의 품질 확보에서 핵심이다. 정적 분석과 실시간 성능 측정 도구를 통해 병목과 경합을 식별하고, 병렬 시나리오 기반의 테스트 전략을 마련해야 실무 적용 시 안정성을 확보할 수 있다.

실무에서 자주 발생하는 Concurrency 관련 이슈 디버깅 가이드

Concurrency 환경에서는 비결정적 동작 (non-deterministic behavior) 이 디버깅을 매우 어렵게 만든다.
아래는 자주 발생하는 이슈, 증상, 진단 방법 및 해결 전략을 실제 환경 기반으로 정리한 가이드이다.

주요 이슈 유형 및 증상

디버깅 및 진단 전략

해결 및 예방 전략

시스템 설계에 Concurrency / Parallelism 통합 전략

Concurrency 와 Parallelism 을 효과적으로 시스템 아키텍처에 통합하는 전략은, 목표에 따른 아키텍처 분리와 역할 분담 방식을 명확히 설정하는 데서 시작된다.

Concurrency 와 Parallelism 은 단순한 프로그래밍 기술을 넘어서, 시스템 전체의 구조, 성능, 안정성에 직결되는 핵심 전략이다.
실무에서는 다음을 항상 고려해야 한다:

• 정확히 문제를 분석하고 (I/O bound 인가, CPU bound 인가?)
• 적절한 설계 전략을 혼합하며 (비동기 + 병렬 처리 모델)
• 디버깅 가능하고 확장 가능한 구조로 설계할 것

통합 설계 전략 개요

설계 패턴

Reactive + Parallel Processing

graph TD
A[Client] --> B[Async Gateway]
B --> C[Reactive Service]
C --> D1[ThreadPool Worker 1]
C --> D2[ThreadPool Worker 2]
D1 --> E[Storage]
D2 --> E

• Reactive Gateway는 요청을 비동기 처리
• 내부에서는 CPU-intensive 병렬 처리 실행 (ex: ThreadPool)

메시지 기반 분산 병렬 처리

graph TD
A[Producer Service] -->|event| B[Kafka Queue]
B --> C1[Consumer Worker 1]
B --> C2[Consumer Worker 2]
C1 --> D[Batch ETL or Inference]
C2 --> D

• 이벤트 기반 병렬 워커 처리
• 병렬성이 높고, Concurrency 와 decoupling 구조 유지

적용시 고려사항

예시 전략

성능을 최적화하기 위한 고려사항 및 주의할 점

• 메모리 관리는 병렬 작업에서 가장 빈번한 병목 원인 중 하나이다. NUMA 환경에서는 접근 위치에 따라 속도 차이가 크기 때문에 지역성을 고려한 메모리 배치가 중요하며, false sharing 을 피하기 위해 데이터 패딩이나 구조체 정렬이 필요하다.

• 스레드 및 스케줄링에서는 스레드 수 조절, 컨텍스트 스위칭 최소화, CPU 캐시 활용이 중요하다. 스레드 어피니티와 워크 스틸링 전략을 결합하면 병렬 작업의 효율을 높일 수 있다.

• 동기화 전략은 락 경합을 줄이고 데드락을 방지하기 위한 구조 설계가 핵심이다. 세분화된 락과 락 프리 자료구조는 필수이며, 조건 변수와 동기화 계층 설계를 명확히 해야 한다.

• 작업 분할 및 부하 분산에서는 작업 단위 크기 설정과 워크로드 균형이 중요하다.너무 작은 단위는 오버헤드, 너무 큰 단위는 병렬성 저하로 이어질 수 있다.

• 비동기 I/O는 특히 고성능 서버나 GUI 시스템에서 중요하며, 폴링 기반 구조는 이벤트 기반 방식으로 전환하는 것이 자원 효율에 유리하다.

• 성능 분석 및 프로파일링은 모든 최적화 전략의 출발점이다. 병목은 일반적으로 예측하기 어려우므로, 정기적인 프로파일링과 시각화 도구를 활용해 확인해야 한다.

• 오류 대응 및 안정성 측면에서는 충돌 상황에 대한 backoff 전략, 재시도 제한, 오류 감지 로직이 중요하며, 병렬 환경에서는 이러한 전략 없이는 병목과 장애 전파가 빠르게 일어난다.

분류에 따른 종류 및 유형

• 실행 모델
  Concurrency 는 논리적 동시성 (예: 비동기 I/O, 이벤트 루프), Parallelism 은 실제 물리적 병렬 처리 (예: GPU 연산, 멀티코어 실행) 에 기반한다. 대부분의 고성능 시스템은 두 가지 모델을 혼합하여 활용한다.

• 구현 방식
  멀티스레딩과 멀티프로세싱은 전통적인 접근 방식이며, 최근에는 액터 모델, CSP, STM 등 더 안전하고 예측 가능한 동시성 모델이 다양하게 활용된다. 특히 Go, Erlang, Kotlin 등 언어는 모델에 최적화된 구조를 내장하고 있다.

• 병렬성 유형
  데이터 병렬성은 머신러닝이나 GPU 연산에 적합하고, 작업 병렬성은 웹 요청이나 백엔드 처리 등에서 자주 사용된다. 파이프라인 병렬성은 ETL, 영상 처리 등 흐름 기반 작업에 효과적이다.

• 동기화 방식
  전통적 락 기반 방식은 데드락 위험이 존재하며, 현대적 동기화 전략은 락 프리, 대기 프리 방식으로 진화하고 있다. 실시간/고성능 시스템에서는 락 사용을 피하고 원자 연산 기반 동기화를 선호한다.

• 메모리 모델
  공유 메모리는 성능이 뛰어나지만 race condition 문제가 빈번하므로, 메시지 패싱 구조는 안전성과 확장성 면에서 점점 선호되고 있다. Erlang/Go/Rust 등이 메시지 기반 설계에 특화된 언어다.

• 비동기 패턴
  콜백 → Promise/Future → Coroutine → Reactive 로 진화하며, 현대 프레임워크들은 구조화된 비동기 패턴을 통해 개발자 경험과 유지보수를 동시에 개선하고 있다.

• 하드웨어 및 언어 기반
  병렬/동시 처리는 하드웨어와 언어의 특성에 따라 성능과 코드 구조가 달라진다. 고성능을 요구하는 분야에서는 GPU, 클러스터 기반 처리를 사용하며, 언어는 Go, Rust, Kotlin 이 주요 선택지로 떠오르고 있다.

실무 사용 예시

• 웹 서버 & 실시간 통신
  비동기 I/O 와 이벤트 루프 기반 구조로 수많은 연결을 처리하며, 플랫폼에 따라 병렬 요청 처리를 병행한다. Kafka 와 같은 시스템은 동시성 메시징 구조 위에 병렬 소비 모델을 결합해 고성능을 실현한다.

• 데이터 파이프라인 & 빅데이터 분석
  비동기 API 요청이나 외부 연산을 Concurrency 로 처리하고, Spark/Hadoop 등에서의 대용량 연산은 Parallelism 으로 병렬 수행된다. 이 둘의 조합이 데이터 처리 성능을 극대화한다.

• 머신러닝/AI & 미디어 처리
  비동기 데이터 로딩과 병렬 연산을 동시에 사용하여 학습 속도 및 인코딩 처리량을 최적화한다. 특히 GPU 병렬화와 lock-free 구조는 병목 해소에 효과적이다.

• 금융/게임 분야
  마이크로초 단위 응답성과 실시간 렌더링, 동시 액션 처리 등 초저지연 환경에서 Concurrency 와 Parallelism 을 동시에 활용하는 대표적 사례다.

• 분산 시스템 & 데이터베이스
  동시 요청 처리 (커넥션 풀, Actor 모델) 와 분산 쿼리/계산의 병렬화를 통해 확장성과 성능을 동시에 확보하며, 장애 대응력도 향상된다.

• 모바일/클라이언트 애플리케이션
  UI 스레드 분리와 백그라운드 동시 처리 (AsyncTask, GCD 등) 구조를 통해 앱 반응성과 사용자 경험 (UX) 을 크게 향상시킨다.

활용 사례

사례 1: 대용량 이미지 처리 웹 서비스

시나리오: 대용량 이미지 처리 웹 서비스에서 동시성과 병렬성을 활용한 성능 최적화

시스템 구성:

• 프론트엔드: React 기반 웹 애플리케이션
• API 서버: Node.js Express 서버 (동시성)
• 이미지 처리 서버: Python 멀티프로세싱 (병렬성)
• 메시지 큐: Redis
• 데이터베이스: PostgreSQL

graph TB
    subgraph "클라이언트"
        A[웹 브라우저]
    end
    
    subgraph "API 서버 (동시성)"
        B[Node.js Express]
        C[이벤트 루프]
    end
    
    subgraph "메시지 큐"
        D[Redis Queue]
    end
    
    subgraph "이미지 처리 서버 (병렬성)"
        E[Python Master Process]
        F[Worker Process 1]
        G[Worker Process 2]
        H[Worker Process 3]
        I[Worker Process 4]
    end
    
    subgraph "저장소"
        J[PostgreSQL]
        K[File Storage]
    end
    
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    E --> G
    E --> H
    E --> I
    B --> J
    E --> J
    F --> K
    G --> K
    H --> K
    I --> K

Workflow:

• 사용자가 이미지 업로드 요청 전송
• API 서버가 비동기적으로 요청 접수하고 즉시 응답
• 이미지 처리 작업을 Redis 큐에 추가
• Python 서버가 작업을 멀티프로세싱으로 병렬 처리
• 처리 완료 후 결과를 데이터베이스에 저장
• 웹소켓을 통해 클라이언트에 완료 알림 전송

역할:

• 동시성 (API 서버): 다수 클라이언트 요청을 동시에 처리하여 응답성 보장
• 병렬성 (이미지 처리): CPU 집약적 작업을 다중 프로세스로 분산하여 처리 속도 향상

유무에 따른 차이점:

• 동시성 없는 경우: 클라이언트 요청이 순차 처리되어 대기 시간 급증
• 병렬성 없는 경우: 이미지 처리가 단일 프로세스에서 실행되어 처리 시간 4 배 증가

구현 예시:

• Python 멀티프로세싱 이미지 처리 예시

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76

  # Python 멀티프로세싱 이미지 처리 예시 from multiprocessing import Pool, Queue import cv2 import numpy as np def process_image(image_data): """ 개별 이미지 처리 함수 Args: image_data: 이미지 데이터와 처리 옵션을 포함한 딕셔너리 Returns: 처리된 이미지 경로 """ try: # 이미지 로드 image = cv2.imread(image_data['input_path']) # 이미지 처리 작업 (예: 리사이징, 필터 적용) if image_data.get('resize'): width, height = image_data['resize'] image = cv2.resize(image, (width, height)) if image_data.get('blur'): image = cv2.GaussianBlur(image, (15, 15), 0) # 처리된 이미지 저장 cv2.imwrite(image_data['output_path'], image) return { 'status': 'success', 'output_path': image_data['output_path'], 'image_id': image_data['image_id'] } except Exception as e: return { 'status': 'error', 'error': str(e), 'image_id': image_data['image_id'] } def main(): """ 메인 프로세스 - 이미지 처리 작업을 병렬로 실행 """ # 처리할 이미지 목록 image_tasks = [ { 'image_id': 1, 'input_path': 'input/image1.jpg', 'output_path': 'output/processed_image1.jpg', 'resize': (800, 600), 'blur': True }, { 'image_id': 2, 'input_path': 'input/image2.jpg', 'output_path': 'output/processed_image2.jpg', 'resize': (1024, 768) } # … 더 많은 이미지 작업 ] # CPU 코어 수만큼 프로세스 풀 생성 with Pool(processes=4) as pool: # 병렬로 이미지 처리 실행 results = pool.map(process_image, image_tasks) # 결과 처리 for result in results: if result['status'] == 'success': print(f"이미지 {result['image_id']} 처리 완료: {result['output_path']}") else: print(f"이미지 {result['image_id']} 처리 실패: {result['error']}") if __name__ == '__main__': main()

• Node.js 동시성 API 서버 예시

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110

  // Node.js 동시성 API 서버 예시 const express = require('express'); const redis = require('redis'); const multer = require('multer'); const { v4: uuidv4 } = require('uuid'); const app = express(); const client = redis.createClient(); // 파일 업로드 설정 const upload = multer({ dest: 'uploads/' }); /** * 이미지 업로드 및 처리 요청 엔드포인트 * 비동기 처리로 즉시 응답 후 백그라운드에서 처리 */ app.post('/upload', upload.single('image'), async (req, res) => { try { const jobId = uuidv4(); const imageData = { jobId: jobId, filename: req.file.filename, originalName: req.file.originalname, mimetype: req.file.mimetype, size: req.file.size, uploadedAt: new Date().toISOString(), // 처리 옵션들 options: { resize: req.body.resize ? JSON.parse(req.body.resize) : null, blur: req.body.blur === 'true', format: req.body.format || 'jpg' } }; // Redis 큐에 작업 추가 (비동기) await client.lpush('image_processing_queue', JSON.stringify(imageData)); // 즉시 응답 - 클라이언트는 대기하지 않음 res.json({ success: true, jobId: jobId, message: '이미지 업로드 완료. 처리 중입니다.', estimatedTime: '30초' }); console.log(`작업 ${jobId} 큐에 추가됨`); } catch (error) { console.error('업로드 처리 중 오류:', error); res.status(500).json({ success: false, error: '서버 내부 오류' }); } }); /** * 작업 상태 확인 엔드포인트 * 클라이언트가 폴링하여 처리 상태 확인 */ app.get('/status/:jobId', async (req, res) => { try { const jobId = req.params.jobId; // 데이터베이스에서 작업 상태 조회 (비동기) const status = await getJobStatus(jobId); res.json({ success: true, jobId: jobId, status: status.status, // 'pending', 'processing', 'completed', 'failed' progress: status.progress, result: status.result }); } catch (error) { console.error('상태 조회 중 오류:', error); res.status(500).json({ success: false, error: '상태 조회 실패' }); } }); /** * 데이터베이스에서 작업 상태 조회 (비동기 함수) */ async function getJobStatus(jobId) { // 실제로는 데이터베이스 쿼리 return new Promise((resolve) => { setTimeout(() => { resolve({ status: 'completed', progress: 100, result: { outputPath: `/processed/${jobId}.jpg`, fileSize: 245760, processedAt: new Date().toISOString() } }); }, 100); }); } // 서버 시작 const PORT = process.env.PORT || 3000; app.listen(PORT, () => { console.log(`서버가 포트 ${PORT}에서 실행 중입니다.`); console.log('동시성을 활용하여 다중 클라이언트 요청을 처리합니다.'); });

사례 2: 대규모 데이터 처리 파이프라인

시나리오: 대규모 데이터 처리 파이프라인에서 외부 API 호출로 데이터를 수집하고, 수집된 데이터를 분석/가공하여 리포트를 생성하는 과정을 수행.

시스템 구성:

• API Fetcher: 비동기 HTTP 호출을 통해 수집 (Concurrency)
• Processing Cluster: 수집된 데이터를 분할 (Map), 병렬분석 (Reduce) 수행 (Parallelism)
• Queue / 메시지 브로커: 작업 분할 및 단계 간 decoupling

graph TD
  A[API 요청 목록] -->|async fetch| B(API Fetcher)
  B --> C[메시지 큐]
  C --> D[Worker 노드 1]
  C --> E[Worker 노드 2]
  D --> F[Map 작업]
  E --> F
  F --> G[Reduce / 집계 및 리포트 작성]
  G --> H[최종 보고서 저장]

Workflow:

1. API 요청 목록 생성
2. Fetcher 가 동시에 여러 API 호출 (concurrency)
3. 원시 데이터 큐로 전달
4. Worker 노드들 각자 병렬로 Map/Reduce 분석 (parallelism)
5. 집계된 결과 리포트 저장

역할:

• Concurrency: API 호출 병렬화, 외부 통신 대기 동안 시스템 효율 극대화
• Parallelism: CPU-intensive 분석 및 집계 작업을 분산하여 처리속도 향상

유무에 따른 차이점:

• Concurrency 없이: 단일 API 호출 → 순차 처리 → 대기 시간 증가
• Parallelism 없이: 순차 데이터 분석 및 리포트 → 전체 처리 지연
• 둘 없으면 처리량 및 응답성 모두 매우 낮음

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# API Fetch (Concurrency)
import asyncio
import aiohttp

async def fetch(session, url):
    async with session.get(url) as resp:
        return await resp.json()

async def bulk_fetch(urls):
    async with aiohttp.ClientSession() as s:
        return await asyncio.gather(*(fetch(s, u) for u in urls))

# 병렬 분석 (Parallelism)
from multiprocessing import Pool

def process_item(item):
    # CPU-intensive 분석 로직
    return compute_statistics(item)

def parallel_process(data):
    with Pool() as p:
        return p.map(process_item, data)

# 전체 워크플로우 예시
def pipeline(urls):
    data = asyncio.run(bulk_fetch(urls))
    analysis = parallel_process(data)
    # 집계 및 저장
    return analysis

사례 3: 대규모 REST API 서버

시나리오: 대규모 REST API 서버 (파이썬 FastAPI 또는 Node.js) 에서 수천 건의 동시 요청을 처리하고, CPU 집약적인 데이터 분석 (NumPy, 멀티프로세싱) 을 백엔드에서 병렬 수행

시스템 구성:

• 사용자 → API 서버 (동시성) → 병렬 데이터 분석 엔진 → 결과 DB

시스템 구성 다이어그램:

flowchart TD
    A[User] --> B["API Server (FastAPI, Node.js) - 동시성"]
    B --> C["병렬 데이터 분석(파이썬 멀티프로세싱, NumPy)"]
    C --> D[Result DB]

Workflow:

• 사용자가 API 로 동시 요청
• 서버는 비동기 IO 로 동시성 처리
• 데이터 분석/AI 작업은 멀티프로세싱 병렬 분산
• 결과를 DB 에 저장/응답으로 반환

역할:

• 동시성: 서버가 여러 요청의 입출력을 논리적으로 동시에 체계적으로 관리/처리
• 병렬성: 데이터 분석 작업이 각 CPU 코어에서 동시 실행되어 전체 처리 시간 단축

유무에 따른 차이점:

• 둘 다 미적용: 동시 접속시 서버 지연·병목, 연산 지연.
• 동시성만: 많은 요청만 받으나, 뒤의 연산이 느림.
• 병렬성만: 단일 요청만 빠름, 전체 서버 처리량 낮음.
• 둘 다 적용: 대용량 요청과 대량연산 모두 신속·효율적 평행처리.

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Python FastAPI + 동시성 + 병렬성 (멀티프로세싱) 예시
from fastapi import FastAPI
from concurrent.futures import ProcessPoolExecutor
import numpy as np

app = FastAPI()
executor = ProcessPoolExecutor(max_workers=4)  # 병렬성: CPU 코어 사용

def heavy_compute(data):
    # 실제 병렬 연산 (예: 대규모 행렬 계산)
    return np.linalg.inv(data)

@app.post("/analyze")
async def analyze(payload: dict):
    data = np.array(payload["data"])
    # 동시성: 비동기 요청, 병렬성: 대규모 연산은 프로세스 풀에서 처리
    loop = asyncio.get_running_loop()
    result = await loop.run_in_executor(executor, heavy_compute, data)
    return {"result": result.tolist()}

사례 4: 고성능 웹 서버 구현

시나리오: 대규모 트래픽을 처리해야 하는 전자상거래 웹사이트에서 동시성과 병렬성을 활용하여 성능과 확장성을 개선하는 사례.

시스템 구성:

• 프론트엔드: React.js 기반 SPA(Single Page Application)
• 백엔드: Node.js + Express (비동기 이벤트 루프)
• 데이터베이스: 읽기용 복제본을 가진 MongoDB 클러스터
• 캐시 레이어: Redis 클러스터
• 메시지 큐: RabbitMQ
• 배포: Kubernetes 기반 컨테이너 오케스트레이션

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[사용자] → [CDN] → [로드 밸런서]
                    ↓
[웹 서버 클러스터] ↔ [캐시 클러스터(Redis)]
        ↓               ↑
[API 서버 클러스터(Node.js)]
        ↓               ↑
[메시지 큐(RabbitMQ)] → [워커 프로세스]
        ↓               ↑
[데이터베이스 클러스터(MongoDB)]
  [Primary] → [Replica 1, Replica 2, …]

Workflow

1. 사용자가 웹사이트 방문 및 상품 검색 요청
2. 로드 밸런서가 요청을 가용한 웹 서버로 분배
3. 웹 서버는 API 서버에 검색 요청 전달
4. API 서버는 먼저 Redis 캐시 확인
5. 캐시 미스 시 비동기적으로 MongoDB 에 쿼리 실행
6. 검색 결과를 캐시에 저장하고 사용자에게 반환
7. 사용자가 상품을 장바구니에 추가하거나 주문 시 메시지 큐에 작업 추가
8. 백그라운드 워커 프로세스가 큐에서 메시지를 소비하여 재고 확인, 결제 처리 등 수행

역할 및 성과:

• 동시성과 병렬성 기법을 통해 다음과 같은 역할과 성과를 달성했다:
  1. 응답성 향상: 사용자 요청에 대한 응답 시간이 평균 300ms 에서 80ms 로 단축
  2. 처리량 증가: 시간당 처리 가능한 주문 수가 5 배 증가
  3. 자원 효율성: 서버 자원 활용률 70% 이상으로 유지
  4. 확장성 개선: 트래픽 급증 시 자동 확장

구현 예시:

1. 이벤트 루프 기반 동시성 (Node.js)
   Node.js 의 이벤트 루프는 비차단 I/O 연산을 통해 한 스레드로 수천 개의 동시 연결을 처리한다. 데이터베이스 쿼리, 파일 시스템 작업, HTTP 요청 등을 비동기적으로 처리하여 서버의 응답성을 유지한다.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

   // Node.js에서의 비동기 라우트 핸들러 예시 app.get('/products/search', async (req, res) => { try { const query = req.query.q; const cacheKey = `search:${query}`; // 캐시 확인 (비동기) const cachedResults = await redisClient.get(cacheKey); if (cachedResults) { return res.json(JSON.parse(cachedResults)); } // 데이터베이스 쿼리 (비동기) const results = await Product.find({ $text: { $search: query } }).limit(20); // 캐시에 결과 저장 (백그라운드에서 실행) redisClient.set(cacheKey, JSON.stringify(results), 'EX', 3600) .catch(err => console.error('캐시 저장 실패:', err)); // 즉시 결과 반환 res.json(results); } catch (error) { console.error('검색 오류:', error); res.status(500).json({ error: '서버 오류' }); } });

2. 작업 큐를 통한 비동기 처리 (RabbitMQ)
   주문 처리, 재고 확인, 이메일 발송 등 시간이 오래 걸리는 작업은 메시지 큐에 위임하여 백그라운드에서 처리한다. 이를 통해 사용자 요청에 대한 응답 시간을 최소화하고, 작업량에 따라 워커 프로세스를 확장할 수 있다.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124

   // 주문 생성 및 작업 큐 활용 예시 app.post('/orders', async (req, res) => { try { // 주문 데이터 유효성 검증 const orderData = validateOrderData(req.body); // 주문 기본 정보 즉시 저장 const order = new Order({ userId: req.user.id, items: orderData.items, status: 'pending', createdAt: new Date() }); await order.save(); // 주문 처리 작업을 메시지 큐에 전송 (비동기) await orderQueue.sendToQueue('order-processing', { orderId: order._id, userId: req.user.id, items: orderData.items }); // 사용자에게 즉시 응답 res.status(201).json({ orderId: order._id, status: 'pending', message: '주문이 접수되었습니다.' }); } catch (error) { console.error('주문 생성 오류:', error); res.status(400).json({ error: error.message }); } }); // 워커 프로세스에서 주문 처리 orderQueue.consume('order-processing', async (msg) => { try { const orderData = JSON.parse(msg.content.toString()); // 재고 확인 (병렬 처리) const stockCheckResults = await Promise.all( orderData.items.map(item => checkStock(item.productId, item.quantity)) ); // 재고 부족 항목 확인 const outOfStockItems = stockCheckResults .filter(result => !result.available) .map(result => result.productId); if (outOfStockItems.length > 0) { // 주문 상태 업데이트 await Order.findByIdAndUpdate(orderData.orderId, { status: 'failed', statusReason: '재고 부족', outOfStockItems }); // 사용자에게 알림 await notificationQueue.sendToQueue('email-notifications', { type: 'order-failed', userId: orderData.userId, orderId: orderData.orderId, reason: '재고 부족' }); } else { // 결제 처리 const paymentResult = await processPayment(orderData); if (paymentResult.success) { // 재고 감소 (병렬 처리) await Promise.all( orderData.items.map(item => updateStock(item.productId, -item.quantity) ) ); // 주문 완료 처리 await Order.findByIdAndUpdate(orderData.orderId, { status: 'completed', paymentId: paymentResult.paymentId }); // 주문 확인 이메일 발송 큐에 추가 await notificationQueue.sendToQueue('email-notifications', { type: 'order-confirmation', userId: orderData.userId, orderId: orderData.orderId }); } else { // 결제 실패 처리 await Order.findByIdAndUpdate(orderData.orderId, { status: 'failed', statusReason: '결제 실패', paymentError: paymentResult.error }); // 결제 실패 알림 await notificationQueue.sendToQueue('email-notifications', { type: 'payment-failed', userId: orderData.userId, orderId: orderData.orderId }); } } // 메시지 처리 완료 확인 orderQueue.ack(msg); } catch (error) { console.error('주문 처리 오류:', error); // 오류 발생 시 주문 상태 업데이트 try { await Order.findByIdAndUpdate( JSON.parse(msg.content.toString()).orderId, { status: 'error', statusReason: error.message } ); } catch (dbError) { console.error('주문 상태 업데이트 실패:', dbError); } // 재시도를 위해 메시지 다시 큐에 넣기 또는 오류 큐로 전송 orderQueue.nack(msg, false, false); } });

3. 데이터베이스 읽기 복제본 활용
   읽기 작업의 부하를 분산하기 위해 MongoDB 복제 세트를 구성하여 읽기 쿼리는 복제본으로, 쓰기 쿼리는 기본 노드로 라우팅한다. 이를 통해 읽기/쓰기 작업을 병렬화하여 전체 시스템 처리량을 향상시킨다.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

   // 데이터베이스 연결 설정 const primaryConnection = mongoose.createConnection(PRIMARY_DB_URI, { useNewUrlParser: true, useUnifiedTopology: true }); const replicaConnection = mongoose.createConnection(REPLICA_DB_URI, { useNewUrlParser: true, useUnifiedTopology: true, readPreference: 'secondaryPreferred' }); // 읽기 전용 모델 (복제본 사용) const ProductRead = replicaConnection.model('Product', productSchema); // 쓰기 가능 모델 (기본 노드 사용) const ProductWrite = primaryConnection.model('Product', productSchema); // 제품 목록 조회 API (읽기 연산 → 복제본 사용) app.get('/products', async (req, res) => { try { const products = await ProductRead.find() .limit(20) .sort({ createdAt: -1 }); res.json(products); } catch (error) { res.status(500).json({ error: error.message }); } }); // 제품 생성 API (쓰기 연산 → 기본 노드 사용) app.post('/products', async (req, res) => { try { const newProduct = new ProductWrite(req.body); await newProduct.save(); res.status(201).json(newProduct); } catch (error) { res.status(400).json({ error: error.message }); } });

4. 수평적 확장을 통한 병렬 처리
   Kubernetes 를 사용하여 API 서버와 워커 프로세스를 수평적으로 확장한다. 트래픽이 증가하면 자동으로 더 많은 포드 (Pod) 를 생성하여 요청을 병렬로 처리하고, 트래픽이 감소하면 자원을 회수한다.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

   # Kubernetes Deployment 설정 예시 apiVersion: apps/v1 kind: Deployment metadata: name: api-server spec: replicas: 3 # 기본 3개의 복제본 selector: matchLabels: app: api-server template: metadata: labels: app: api-server spec: containers: - name: api-server image: ecommerce/api-server:latest resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "500m" memory: "512Mi" ports: - containerPort: 3000 --- # 수평적 오토스케일링 설정 apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: api-server-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-server minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80