570. 단일 스레드 성능 (STP) vs 다중 스레드 성능 (MTP)

핵심 인사이트 (3줄 요약)

1. 본질: 단일 스레드 성능 (Single-Thread Performance, STP)은 한 개의 중요한 실행 흐름을 얼마나 빨리 끝내는가를, 다중 스레드 성능 (Multi-Thread Performance, MTP)은 여러 실행 흐름을 합쳐 단위 시간에 얼마나 많이 처리하는가를 본다.
2. 가치: 사용자 체감 응답성은 대개 STP에, 서버·배치·렌더링의 총 처리량은 MTP에 더 민감하므로 같은 칩이라도 무엇을 최적화했는지에 따라 가치가 달라진다.
3. 판단 포인트: 좋은 아키텍처 선택은 "코어 수가 많은가"가 아니라 직렬 구간의 비중, 메모리 대역폭, tail latency, 전력 예산을 보고 STP와 MTP의 목표 함수를 먼저 정하는 데서 시작한다.

Ⅰ. 개요 및 필요성

STP와 MTP는 같은 "성능"이라는 단어 안에 들어 있지만, 실제로는 서로 다른 목표를 본다. STP는 브라우저의 메인 스레드, 게임의 렌더 스레드, 실시간 제어 루프처럼 하나의 임계 경로를 얼마나 빨리 끝낼 수 있는가를 묻는다. 반면 MTP는 웹 서버, 가상화 호스트, 대규모 빌드, 렌더링처럼 여러 일을 동시에 얼마나 많이 밀어낼 수 있는가를 묻는다.

과거에는 주파수를 올리면서 둘을 어느 정도 함께 개선할 수 있었지만, 전력 밀도와 발열 한계가 커지면서 이제는 고정된 전력·면적 예산 안에서 선택해야 한다. 큰 코어 몇 개에 자원을 몰아주면 STP는 좋아지지만 코어 수가 줄고, 작은 코어를 많이 넣으면 MTP는 늘지만 단일 작업의 체감 속도는 둔해질 수 있다. 그래서 현대 프로세서 설계는 "더 빠른 중앙처리장치 (Central Processing Unit, CPU)"보다 어떤 성능을 더 비싸게 사는가의 문제에 가깝다.

이 그림은 같은 예산에서도 목표가 달라지면 칩 구성이 달라짐을 보여 준다.

┌────────────────────────────────────────────────────────────────────────────┐
│      같은 Area / Power 예산이라도 목표 함수가 다르면 구조가 달라진다        │
├────────────────────────────────────────────────────────────────────────────┤
│ STP Focus -> Big Core Few -> Fast Response / Low Thread Count             │
│ MTP Focus -> Small Core Many -> High Throughput / Lower Per-Thread Speed  │
│ Serial Section Exists -> 결국 일부 구간은 STP가 전체 체감을 결정           │
└────────────────────────────────────────────────────────────────────────────┘

• 📢 섹션 요약 비유: STP는 서류 한 장을 가장 빨리 배달하는 오토바이 한 대이고, MTP는 상자를 한꺼번에 실어 나르는 트럭 여러 대다. 무엇을 옮기느냐에 따라 더 좋은 탈것이 달라진다.

Ⅱ. 아키텍처 및 핵심 원리

STP를 끌어올리려면 보통 더 넓은 superscalar front-end, 큰 분기 예측기, 비순차 실행 (Out-of-Order, OoO), 큰 private cache가 필요하다. 이들은 명령어 수준 병렬성 (Instruction-Level Parallelism, ILP)을 끌어내어 한 스레드의 명령어를 더 빨리 처리한다. 반대로 MTP는 스레드 수준 병렬성 (Thread-Level Parallelism, TLP)을 활용하므로, 같은 예산이라면 더 많은 코어 수, 더 많은 hardware thread, 더 높은 메모리 병렬성이 중요해진다.

이를 간단히 표현하면 STP는 대략 한 스레드의 IPC (Instructions Per Cycle) × 주파수, MTP는 활성 스레드 수 × 각 스레드의 진행률 - 공유 자원 충돌 비용으로 볼 수 있다. 여기서 공유 자원 충돌 비용이 핵심이다. 코어 수만 늘려도 마지막 단계에서는 마지막 수준 캐시 (Last-Level Cache, LLC), 메모리 대역폭, coherence traffic 때문에 MTP가 선형으로 늘지 않는다. 폴락의 법칙 (Pollack's Rule)도 큰 코어의 복잡도를 늘릴수록 STP 향상이 면적 대비 둔화된다고 경고한다.

이 그림은 STP와 MTP가 서로 다른 곳에 실리콘 예산을 쓰는 방식을 요약한다.

┌────────────────────────────────────────────────────────────────────────────┐
│     Fixed Budget Split: STP는 코어 내부를, MTP는 코어 개수를 키운다         │
├────────────────────────────────────────────────────────────────────────────┤
│ [Big Core]   -> Wide Decode -> Large OoO -> Large Cache -> High STP       │
│ [Many Cores] -> Core x N   -> Shared LLC -> High Thread Count -> High MTP │
│                         but Memory / Coherence limits stop linear scaling  │
└────────────────────────────────────────────────────────────────────────────┘

• 📢 섹션 요약 비유: STP 중심 코어는 한 명의 숙련 장인에게 최고 장비를 몰아주는 방식이고, MTP 중심 코어는 적당한 장비를 여러 사람에게 나눠주는 방식이다. 같은 예산이라도 "깊이"와 "수"의 배분이 다르다.

Ⅲ. 비교 및 연결

STP와 MTP의 차이는 결국 latency와 throughput의 차이다. 화면을 한 번 클릭했을 때 바로 반응해야 하는 작업은 STP가 낮으면 체감이 나빠지고, 수천 개 요청을 동시에 처리하는 서비스는 MTP가 낮으면 총 처리량이 급격히 떨어진다. 그래서 두 지표는 서로 경쟁하기도 하지만, 실제 시스템에서는 함께 관리해야 하는 경우가 많다.

암달의 법칙 (Amdahl's Law)은 직렬 구간이 남아 있는 한 STP가 전체 성능 상한을 결정한다고 말한다. 반면 구스타프슨의 법칙 (Gustafson's Law)은 문제 크기가 커질수록 병렬 부분이 커져 MTP의 가치가 커진다고 본다. 동시에 다중 스레드 동시 실행 (Simultaneous Multithreading, SMT)은 큰 코어 안의 놀고 있는 실행 자원을 활용해 MTP를 보강하지만, 근본적으로 낮은 STP 코어를 높은 STP 코어로 바꿔 주지는 못한다.

결국 STP와 MTP를 단순 대립항으로만 보면 설계를 그르치기 쉽다. 예를 들어 현대 하이브리드 CPU는 고성능 코어와 고효율 코어를 함께 두어 전경 작업은 STP, 배경 작업은 MTP 쪽으로 보내는 식으로 둘을 절충한다.

• 📢 섹션 요약 비유: STP는 한 명의 독주자가 얼마나 잘 치는가이고, MTP는 오케스트라 전체가 얼마나 많은 소리를 풍성하게 내는가다. 멋진 공연은 둘 중 하나만으로 완성되지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 중요한 것은 벤치마크 숫자를 많이 외우는 일이 아니라, 내 워크로드의 병목이 한 스레드인지 여러 스레드인지 먼저 가르는 것이다. 사용자 입력이 끊기면 안 되는 클라이언트, 짧은 거래를 빠르게 끝내야 하는 데이터베이스, 실시간 제어는 STP를 우선해야 한다. 반대로 독립 작업이 많은 서버, 렌더링 팜, 빌드 팜, 대규모 추론은 일정 수준의 STP만 확보되면 그다음부터는 MTP가 더 큰 가치를 낸다.

현대 플랫폼에서는 운영체제 스케줄러도 이 구분을 적극적으로 활용한다. 전력 여유가 있을 때는 터보 부스트로 STP를 순간 강화하고, 백그라운드 작업은 고효율 코어나 낮은 우선순위 큐로 보내 총 처리량과 전성비를 맞춘다. 이 과정에서 비균일 메모리 접근 (Non-Uniform Memory Access, NUMA) 배치까지 어긋나면 MTP 이점이 쉽게 줄어든다. 따라서 기술사 답안에서는 코어 구조만이 아니라 스케줄러, 메모리 계층, 전력 정책까지 함께 언급해야 완성도가 높다.

적용 판단 체크리스트

1. 성능 목표가 평균 처리량인가, 아니면 최악 응답 시간인가?
2. 전체 코드에서 직렬 구간과 동기화 비용은 얼마나 큰가?
3. 코어 수를 늘렸을 때 메모리 대역폭과 LLC가 이를 감당하는가?
4. tail latency가 중요한 서비스인가, 아니면 총 작업 수가 중요한 배치 작업인가?
5. 하이브리드 코어 또는 가속기에 일을 나눌 수 있는 소프트웨어 스택이 준비되어 있는가?

피해야 할 안티패턴

• 코어 수만 보고 MTP가 무조건 높다고 판단하는 것

• 단일 스레드 벤치마크만 보고 서버 처리량을 예측하는 것

• 메모리 병목과 lock contention을 무시한 채 병렬화만 늘리는 것

• 응답성이 중요한 작업을 느린 효율 코어에 장시간 묶어 두는 운영

• 📢 섹션 요약 비유: 식당 운영에서 손님 한 명의 주문을 빨리 내는 능력과, 점심시간에 수백 명을 동시에 받는 능력은 다르다. 주방 구조를 정할 때는 어떤 장면이 더 중요한지 먼저 정해야 한다.

Ⅴ. 기대효과 및 결론

STP와 MTP를 올바르게 구분하면 시스템은 더 높은 점수보다 더 맞는 성능을 낼 수 있다. 사용자는 앱이 즉시 반응한다고 느끼고, 운영자는 같은 전력과 장비 수로 더 많은 요청을 처리할 수 있다. 또한 코어 배치, 캐시 크기, 스케줄링 정책, 전력 제어를 목적에 맞게 조정할 수 있어 성능 튜닝의 방향이 선명해진다.

한계도 있다. STP를 끝없이 올리려 하면 코어 복잡도와 전력이 급증하고, MTP를 무작정 키우면 메모리·동기화·운영 복잡도가 발목을 잡는다. 앞으로는 하이브리드 코어, domain-specific accelerator, 품질 보장 (Quality of Service, QoS)을 고려한 scheduler처럼 STP와 MTP를 하나의 칩 안에서 계층적으로 분담하는 구조가 더 중요해질 가능성이 크다.

결론적으로 STP와 MTP는 우열 경쟁이 아니라 고정된 자원 아래에서 latency와 throughput 중 무엇을 우선 최적화할 것인가를 가르는 판단 축으로 기억해야 한다.

• 📢 섹션 요약 비유: 좋은 감독은 단거리 선수와 릴레이 팀을 같은 기준으로 평가하지 않는다. 한 사람의 기록과 팀 전체 기록은 다른 훈련법이 필요하다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

주파수 상승 중심 성능 향상
        │
        ▼
큰 OoO 코어로 STP 확대
        │
        ▼
멀티코어 확산으로 MTP 본격화
        │
        ▼
SMT · Shared LLC · NUMA 최적화
        │
        ▼
Hybrid Core · QoS-Aware Scheduling
        │
        ▼
Domain-Specific Accelerator와 역할 분담

이 흐름은 성능 최적화의 기준이 "한 코어를 더 빠르게"에서 "여러 성능 목표를 한 칩 안에서 분담"하는 방향으로 이동했음을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

1. STP는 힘센 친구 한 명이 어려운 문제를 아주 빨리 푸는 능력이에요.
2. MTP는 여러 친구가 나눠서 숙제를 많이 끝내는 능력이에요.
3. 어려운 문제 한 개는 힘센 친구가, 쉬운 문제 백 장은 여러 친구가 더 잘 해낸답니다.