226. WAR (Write After Read)

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

본질: WAR (Write After Read)는 앞선 명령어가 데이터를 아직 읽기도(Read) 전에 뒤따르는 명령어가 해당 위치에 새로운 값을 먼저 써버려(Write) 앞 명령어가 오염된 값을 읽게 되는 반의존성 (Anti-dependency) 상황이다.

가치: 순서대로 실행되는 파이프라인에서는 발생하지 않으나, 명령어 실행 순서를 뒤섞는 비순차 실행 (Out-of-Order Execution) 환경에서 데이터 무결성을 파괴하는 치명적인 위협이 된다.

판단 포인트: 데이터의 인과관계가 아닌 '이름(레지스터 번호)'이 겹쳐서 발생하는 가짜 의존성이므로, 하드웨어가 레지스터 이름을 몰래 바꿔치기하는 레지스터 리네이밍 (Register Renaming) 기술을 통해 100% 무효화 가능하다.

Ⅰ. 개요 및 필요성

WAR 해저드는 "성격 급한 뒷사람이 앞사람의 책을 뺏어 덮어쓰는" 상황이다. 고전적인 5단 파이프라인은 무조건 순서대로 실행되므로 뒷사람이 앞사람을 추월해 데이터를 덮어쓸 일이 없다. 하지만 현대 CPU는 노는 꼴을 못 봐서 준비된 명령어부터 먼저 실행하는 비순차 실행(OoO)을 수행하는데, 이때 WAR라는 유령이 나타나 수치를 오염시킨다.

이 해저드를 관리해야 하는 이유는 명령어 수준 병렬성 (ILP)의 확보 때문이다. WAR를 해결하지 못하면 레지스터 이름이 겹치는 모든 명령어는 앞의 읽기가 끝날 때까지 멍하니 서 있어야 한다. 이는 CPU의 강력한 병렬 엔진을 공회전시키는 원인이 된다. 따라서 레지스터라는 유한한 이름을 가상의 무한한 물리적 공간으로 확장하여, 이름 충돌 없이 병렬 실행을 가능케 하는 것이 고성능 아키텍처의 핵심 설계 전략이다.

📢 섹션 요약 비유: 1번 손님이 테이블 위 신문(읽기)을 아직 다 보지도 않았는데, 2번 손님이 갑자기 들어와서 자기 맘대로 그 신문 위에 매직으로 낙서를 해버리는(쓰기) 뻔뻔한 새치기 상황과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리

WAR 해저드는 프로그램의 원래 순서와 하드웨어의 실제 실행 순서가 뒤집힐 때 발생한다.

명령어 순서	어셈블리 예시	동작 성격	설명
명령어 1 (선행)	`ADD $t0, $t1, $t2`	`$t1` 소비 (Read)	`$t1`의 옛날 값을 읽어야 함
명령어 2 (후행)	`SUB $t1, $t3, $t4`	`$t1` 생성 (Write)	`$t1`에 새로운 값을 덮어씀

┌─────────────────────────────────────────────────────────────────────────────┐
│          비순차 실행(OoO) 환경에서의 WAR 발생 메커니즘 시각화               │
├─────────────────────────────────────────────────────────────────────────────┤
│  [ 프로그램 원래 순서 ]        [ 하드웨어 실제 실행 (OoO) ]                 │
│  1. ADD t0, t1, t2  ─────▶   2. SUB t1, t3, t4 (먼저 완료! t1=새 값)        │
│  2. SUB t1, t3, t4           1. ADD t0, t1, t2 (뒤늦게 완료! t1=새 값?)     │
│                                                                             │
│ * 문제 상황: Inst 1이 메모리 지연 등으로 늦어지는 사이, Inst 2가 먼저 t1을  │
│   갱신해버림. 뒤늦게 실행된 Inst 1은 원치 않는 새 값을 읽어 연산 오류 발생! │
└─────────────────────────────────────────────────────────────────────────────┘

여기서 핵심은 Inst 1과 Inst 2 사이에는 데이터가 건너가는 인과관계가 전혀 없다는 것이다. 단순히 $t1이라는 이름표(간판)가 우연히 겹쳤을 뿐이다. 그래서 이를 '진짜' 의존성이 아닌 가짜 의존성 (False Dependency) 또는 **이름 의존성 (Name Dependency)**이라고 부른다.

📢 섹션 요약 비유: 도서관에서 앞사람이 다 읽지도 않은 책에 뒷사람이 낙서를 해서 내용을 바꿔버려, 앞사람이 원래 내용을 영원히 읽을 수 없게 만드는 파괴적인 새치기 행위입니다.

Ⅲ. 비교 및 연결

WAR는 리네이밍이라는 '속임수'로 풀 수 있다는 점에서 RAW와 명확히 구분된다.

비교 항목	RAW (진성 의존성)	WAR (가짜 의존성)	아키텍처적 통찰
본질적 원인	데이터 흐름의 인과관계	하드웨어 자원(이름) 부족	데이터 vs 이름
시간 여행 비유	과거가 없으면 미래가 없음	동명이인 때문에 생긴 오해	불가피함 vs 해결가능
비순차 실행 시	무조건 대기 (Stall)	이름만 바꾸면 대기 불필요	병목 vs 기회
해결 기법	포워딩, 스케줄링	레지스터 리네이밍	배선 vs 맵핑

현대 CPU는 수백 개의 비밀 물리 레지스터(PRF)를 숨겨두고, $t1이라는 논리 레지스터를 실시간으로 P1, P10 등으로 바꿔치기한다. 이렇게 하면 SUB가 P10에 아무리 빨리 써도, ADD는 안전한 P1에서 옛날 값을 여유 있게 읽어갈 수 있다.

📢 섹션 요약 비유: RAW는 "엄마가 밥을 다 해줘야(Write) 먹을 수 있는(Read)" 자연의 섭리지만, WAR는 단순히 "형이 쓰고 있는 파란 그릇(Read)에 동생이 반찬을 담겠다(Write)고 싸우는 것"입니다. 그릇만 다른 색깔로 바꿔주면(리네이밍) 해결됩니다.

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

실무 아키텍트에게 WAR 처리는 칩의 물리 레지스터(PRF) 용량 설계와 직결된다.

설계 및 실무 판단 포인트

리네이밍 윈도우 크기: 칩 내부에 숨겨둔 물리 레지스터가 160개라면, 비순차적으로 처리할 수 있는 명령어의 한계도 그 근처다. 만약 리네이밍할 빈 상자가 다 떨어지면(Starvation), WAR를 피하지 못해 전 파이프라인이 멈추는 재앙이 발생한다.
x86의 레지스터 부족 극복: x86은 쓸 수 있는 레지스터가 16개뿐이라 WAR 지뢰밭이다. 이를 해결하기 위해 하드웨어 리네이밍 유닛은 1초에 수십억 번씩 이름표를 갈아 끼우며, 컴파일러의 '레지스터 돌려막기' 부작용을 온몸으로 받아낸다.
PPA 관점의 비용: 리네이밍을 위한 매핑 테이블과 수백 개의 물리 레지스터는 막대한 다이 면적과 전력을 소모한다. 따라서 모바일 효율 코어에서는 이를 생략하고 순차 실행을 택해 전성비를 챙기는 전략적 선택을 하기도 한다.

안티패턴

과도한 레지스터 재사용 코딩: 변수가 100개인데 억지로 레지스터 2개만 돌려쓰는 코드를 짜면, 하드웨어 리네이밍 유닛에 과부하를 주어 관리 오버헤드 때문에 성능이 오히려 저하될 수 있다.
📢 섹션 요약 비유: 식당 테이블 간판이 하나뿐이라 손님들이 싸울 때마다, 사장님(리네임 유닛)이 창고에서 임시 테이블과 번호판을 무한히 꺼내오는 극강의 서비스 요령입니다. 창고가 꽉 차면 가게 문을 닫아야 합니다.

Ⅴ. 기대효과 및 결론

WAR 해저드는 '가상화' 기술을 통해 극복된 하드웨어 설계의 위대한 승리다.

결론적으로 현대 아키텍처는 WAR라는 가짜 장벽을 레지스터 리네이밍으로 완벽히 허물어버림으로써, 명령어들 간의 불필요한 대기 시간을 제거하고 연산 유닛의 가동률을 90% 이상으로 끌어올렸다. 미래에는 물리 레지스터라는 고정된 틀을 넘어, 명령어 간의 데이터플로우를 런타임에 그래프로 그려서 동적으로 자원을 할당하는 데이터 중심 스케줄링으로 진화하며 WAR의 유산마저 지워버릴 것이다.

📢 섹션 요약 비유: WAR는 이름이 모자랐던 좁은 아키텍처가 낳은 비극적 유령이었지만, 지하 창고(물리 레지스터)를 파놓는 눈속임 마술 덕분에 영원히 퇴마되었습니다.

📌 관련 개념 맵

개념	연결 포인트
레지스터 리네이밍	WAR를 해결하는 하드웨어의 '이름 바꿔치기' 기술
비순차 실행 (OoO)	WAR 해저드를 탄생시킨 근본적인 병렬화 기법
반의존성 (Anti-dependency)	데이터 값은 상관없고 이름만 겹치는 WAR의 또 다른 이름
물리 레지스터 파일 (PRF)	리네이밍된 가짜 이름들이 실제로 거주하는 대규모 저장소

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

1번 친구가 공책을 읽고(Read) 있는데, 2번 친구가 갑자기 나타나 그 공책 위에 자기 글씨를 덧씌워 써버렸어요(Write).
그러면 1번 친구는 원래 내용을 못 읽게 되겠죠? 순서가 꼬여서 생긴 이 사고를 'WAR 해저드'라고 해요.
똑똑한 선생님(CPU)은 이 싸움을 막으려고, 2번 친구에게 이름표만 똑같은 '새 공책'을 몰래 쥐여줘서 각자 자기 공책을 보게 해준답니다!