222. 구조적 해저드 (Structural Hazard)

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

1. 본질: 구조적 해저드 (Structural Hazard)는 파이프라인의 여러 명령어가 같은 시점에 같은 하드웨어 자원을 요구할 때, 자원 수가 부족해 명령어 흐름이 멈추는 물리적 충돌이다.
2. 가치: 이 문제를 이해하면 파이프라인 성능이 단순 클럭 속도보다 자원 배치와 포트 수에 더 크게 좌우된다는 사실을 잡을 수 있다.
3. 판단 포인트: 해결책은 자원 복제, 포트 확장, 파이프라이닝, 스톨 허용으로 나뉘며, 성능 목표와 면적·전력 비용 사이의 균형이 설계의 핵심이다.

Ⅰ. 개요 및 필요성

구조적 해저드 (Structural Hazard)는 파이프라인 내부의 명령어들이 서로 논리적으로는 독립적이어도, 동시에 사용할 수 있는 하드웨어가 부족해서 발생하는 자원 충돌이다. 즉 문제의 본질은 "계산 순서가 틀렸다"가 아니라 "동시에 쓸 도구가 하나뿐이다"에 가깝다. 데이터 해저드나 제어 해저드가 명령어 관계에서 비롯된다면, 구조적 해저드는 아키텍처의 물리적 구성에서 직접 발생한다.

이 개념이 중요한 이유는 파이프라인이 본래 노리는 처리량 향상을 가장 정직하게 깎아먹기 때문이다. 이상적으로는 매 클럭마다 새 명령어가 하나씩 진입해야 하지만, 명령어 인출과 데이터 접근이 같은 메모리 포트를 공유하거나, 긴 곱셈기가 하나뿐이면 특정 클럭에서 누군가는 반드시 기다려야 한다. 결국 구조적 해저드는 **CPI (Cycles Per Instruction)**를 증가시키며, 하드웨어를 충분히 빠르게 설계했더라도 자원 배치가 좁으면 전체 성능은 기대치에 못 미친다.

특히 단일 메모리 구조, 단일 포트 레지스터 파일, 다중 사이클 연산기, 좁은 버스 구조에서는 이런 충돌이 자주 나타난다. 그래서 파이프라인을 설계할 때는 단계 수를 늘리는 것만큼이나, 각 단계가 동시에 요구하는 자원의 개수와 충돌 빈도를 함께 계산해야 한다.

• 📢 섹션 요약 비유: 구조적 해저드는 조리사는 여러 명인데 프라이팬이 하나뿐인 주방과 같다. 레시피는 서로 달라도 같은 팬을 동시에 쓸 수 없어서 결국 누군가는 줄을 서야 한다.

Ⅱ. 아키텍처 및 핵심 원리

구조적 해저드는 보통 파이프라인 단계가 특정 자원을 같은 클럭에 동시에 요구할 때 드러난다. 고전적인 5단계 파이프라인에서는 IF (Instruction Fetch), ID (Instruction Decode/Register Read), EX (Execute), MEM (Memory Access), WB (Write Back)가 겹쳐 실행되므로, 각 단계가 필요로 하는 메모리·레지스터 포트·연산기 수가 맞지 않으면 충돌이 생긴다.

아래 그림은 단일 메모리를 쓸 때 가장 자주 소개되는 구조적 해저드를 보여준다. 한 명령어는 MEM 단계에서 데이터를 읽고, 뒤의 다른 명령어는 같은 클럭에 IF 단계에서 다음 명령어를 가져오려 한다. 메모리 포트가 하나라면 둘 중 하나는 대기해야 한다.

┌────────────────────────────────────────────────────────────────────────────┐
│        단일 메모리에서 발생하는 구조적 해저드의 시간 충돌                 │
├────────────────────────────────────────────────────────────────────────────┤
│ Cycle    1        2        3        4        5        6                   │
│ I1     [ IF ] → [ ID ] → [ EX ] → [ MEM] → [ WB ]                         │
│ I2              [ IF ] → [ ID ] → [ EX ] → [ MEM] → [ WB ]                │
│ I3                       [ IF ] → [ ID ] → [ EX ] → [ MEM]                 │
│ I4                                [ IF ? ]                                 │
│                                    │                                       │
│                                    ├─ I1은 데이터 접근 필요 (MEM)          │
│                                    └─ I4는 명령어 인출 필요 (IF)           │
│                                                                            │
│ 결과: 메모리 포트가 1개이면 I4는 Stall, 메모리 포트가 2개면 동시 진행      │
└────────────────────────────────────────────────────────────────────────────┘

이 문제를 수식으로 보면, 실제 성능은 실효 CPI = 이상적 CPI + 구조적 스톨 빈도로 표현할 수 있다. 즉 구조적 해저드가 잦을수록 클럭 주파수가 높아도 체감 처리량은 줄어든다. 그래서 현대 프로세서는 명령어 캐시와 데이터 캐시를 분리하고, 레지스터 파일에 여러 읽기 포트를 두며, 자주 쓰는 실행 유닛을 병렬로 배치해 충돌을 줄인다.

• 📢 섹션 요약 비유: 구조적 해저드는 톨게이트 차로가 하나뿐인 고속도로와 같다. 차가 빠르더라도 차로가 좁으면 결국 병목은 요금소에서 생긴다.

Ⅲ. 비교 및 연결

구조적 해저드는 다른 해저드와 비교해야 경계가 선명해진다. 구조적 해저드는 자원 부족, 데이터 해저드는 값의 선후 관계, 제어 해저드는 다음에 갈 경로의 불확실성이 원인이다. 따라서 구조적 해저드는 주로 하드웨어 자원 배치로 해결되고, 데이터 해저드는 포워딩과 스케줄링, 제어 해저드는 분기 예측과 플러시 제어가 중심이 된다.

메모리 구조 관점에서는 폰 노이만 구조 (Von Neumann Architecture)와 하버드 구조 (Harvard Architecture)의 차이가 대표적이다. 명령어와 데이터를 같은 메모리 경로로 다루는 폰 노이만 구조는 단순하지만 IF와 MEM 충돌이 일어나기 쉽다. 반면 하버드 구조나 현대의 분리된 L1 캐시 (Level 1 Cache)는 명령어 경로와 데이터 경로를 나눠 구조적 해저드를 원천적으로 줄인다.

또한 구조적 해저드는 슈퍼스칼라 (Superscalar)와 비순차 실행 (Out-of-Order Execution)으로 갈수록 더 중요해진다. 한 클럭에 여러 명령어를 동시에 발행하면, 같은 ALU나 로드/스토어 유닛을 두고 경쟁이 커지기 때문이다. 즉 고성능화는 해저드를 없애는 마법이 아니라, 더 많은 자원을 투입하고 더 정교한 중재 정책을 요구하는 방향으로 이어진다.

• 📢 섹션 요약 비유: 구조적 해저드는 운동장에 공이 모자란 문제이고, 데이터 해저드는 패스를 아직 못 받은 문제이며, 제어 해저드는 어느 골대로 뛸지 아직 모르는 문제와 같다. 겉보기엔 모두 멈춤이지만, 막히는 이유는 서로 다르다.

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

실무에서 구조적 해저드 대응은 "자원을 더 넣을 것인가, 기다림을 감수할 것인가"의 판단이다. 서버용 CPU나 고성능 애플리케이션 프로세서는 IPC (Instructions Per Cycle)를 높이기 위해 명령어 캐시·데이터 캐시 분리, 다중 실행 유닛, 다중 포트 레지스터 파일을 적극 채택한다. 반대로 저가형 MCU (Microcontroller Unit)나 초저전력 칩은 면적과 전력을 아끼기 위해 일부 충돌을 허용하고, 필요한 순간에만 스톨하도록 설계한다.

설계 판단 체크리스트

1. 충돌이 빈번한 자원이 성능 상의 진짜 병목인가?
2. 자원 복제로 얻는 성능 이득이 면적·전력 증가보다 큰가?
3. 포트 수를 늘릴 때 임계 경로 (Critical Path)와 클럭 속도 저하가 생기지 않는가?
4. 스톨을 허용해도 목표 응답시간과 실시간성이 유지되는가?

대표 전략

• 자원 복제: ALU, 로드/스토어 유닛, 캐시 경로를 늘려 충돌 자체를 줄인다.
• 자원 분할: 메모리 뱅킹이나 명령어/데이터 분리처럼 경로를 나누어 경쟁을 완화한다.
• 파이프라인화: 긴 연산기를 여러 단계로 쪼개 동시 처리 수용량을 높인다.
• 중재 허용: 하드웨어 중재기(arbiter)로 순서를 정하고, 드문 충돌은 스톨로 흡수한다.

안티패턴

파이프라인 단계 수만 늘리고 실제 자원 수를 그대로 두는 설계는 대표적인 악수다. 겉으로는 깊은 파이프라인이라 고성능처럼 보이지만, 실전에서는 같은 메모리와 같은 실행 유닛을 두고 더 자주 부딪혀 스톨만 늘어난다. 즉 파이프라인 심화와 자원 확충은 함께 설계되어야 한다.

• 📢 섹션 요약 비유: 카운터 직원만 10명으로 늘리고 계산대는 2대만 두면 손님은 빨라지지 않는다. 진짜 병목은 사람 수가 아니라 계산대 수에 있기 때문이다.

Ⅴ. 기대효과 및 결론

구조적 해저드를 잘 다루면 파이프라인은 이상적인 처리량에 더 가까워진다. 스톨이 줄어들면서 CPI가 개선되고, 고성능 코어에서는 여러 명령어를 안정적으로 병렬 처리할 수 있다. 또한 자원 충돌이 줄면 성능 예측 가능성이 높아져 시스템 튜닝과 병목 분석도 쉬워진다.

다만 해결책은 공짜가 아니다. 자원 복제와 포트 확장은 칩 면적, 소비전력, 배선 복잡도, 검증 난이도를 모두 증가시킨다. 특히 다중 포트 메모리나 실행 유닛 증설은 단순히 "부품 하나 더 넣기"가 아니라 배선 지연과 발열, 스케줄링 정책까지 다시 설계해야 하는 문제다.

앞으로의 방향은 무조건적인 복제보다, 자주 충돌하는 자원만 선택적으로 확장하고 나머지는 뱅킹, 동적 스케줄링, 계층형 캐시 구조로 완화하는 쪽에 가깝다. 따라서 구조적 해저드는 "하드웨어가 부족해서 생기는 단순 충돌"로 외우기보다, 성능 목표를 위해 어디까지 자원을 투자할지 묻는 아키텍처적 의사결정 문제로 기억하는 것이 정확하다.

• 📢 섹션 요약 비유: 좋은 경기장은 관중석만 크게 짓지 않는다. 사람들이 몰리는 출입문, 매점, 화장실까지 함께 설계해야 진짜로 붐벼도 잘 돌아간다.

📌 관련 개념 맵

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

단일 실행 경로
    │
    ▼
파이프라인 도입
    │
    ├─ 자원 동시 요구 증가
    ▼
구조적 해저드 (Structural Hazard)
    │
    ├─ 자원 복제: ALU · 캐시 · 포트 확장
    ├─ 자원 분리: Harvard Architecture · 메모리 뱅킹
    └─ 자원 중재: Stall · Arbiter
    ▼
슈퍼스칼라 · 비순차 실행에서의 정교한 자원 스케줄링

이 흐름은 파이프라인이 성능을 높이는 동시에 자원 경쟁을 드러내고, 이후 아키텍처가 복제·분리·중재 전략으로 진화해 왔음을 보여준다.

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

1. 친구 넷이 같이 그림을 그리고 싶은데 색연필 통이 하나뿐이면, 한 번에 한 명만 쓸 수 있어요.
2. 그래서 다른 친구들은 자기 차례가 올 때까지 잠깐 멈춰 서야 하는데, 그게 구조적 해저드예요.
3. 색연필을 더 준비하거나, 연필 통을 나눠 놓으면 친구들이 덜 기다리고 더 빨리 그림을 끝낼 수 있어요.