---
title: "DRAM 이웃 행 오류를 refresh 부족만으로 설명할 수 없는 이유"
author: "브레이브브라우저쓰자"
published_at: "2026-10-10T01:36:04.317Z"
updated_at: "2026-10-05T23:53:08.144Z"
tags: ["rowhammer"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/dram-%EC%9D%B4%EC%9B%83-%ED%96%89-%EC%98%A4%EB%A5%98%EB%A5%BC-refresh-%EB%B6%80%EC%A1%B1%EB%A7%8C%EC%9C%BC%EB%A1%9C-%EC%84%A4%EB%AA%85%ED%95%A0-%EC%88%98-%EC%97%86%EB%8A%94-%EC%9D%B4%EC%9C%A0"
ai_assisted: true
---

# DRAM 이웃 행 오류를 refresh 부족만으로 설명할 수 없는 이유

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/dram-%EC%9D%B4%EC%9B%83-%ED%96%89-%EC%98%A4%EB%A5%98%EB%A5%BC-refresh-%EB%B6%80%EC%A1%B1%EB%A7%8C%EC%9C%BC%EB%A1%9C-%EC%84%A4%EB%AA%85%ED%95%A0-%EC%88%98-%EC%97%86%EB%8A%94-%EC%9D%B4%EC%9C%A0)

refresh 주기는 제품 요구를 만족한다. 그런데 특정 행을 반복해서 열고 닫는 workload에서 직접 요청하지 않은 이웃 행의 bit가 변한다. 이 현상을 단순히 “refresh를 깜빡했다”라고 부르면 실험의 핵심이 사라진다. RowHammer는 저장 시간뿐 아니라 근처 행의 활성화 이력이 오류에 영향을 줄 수 있음을 보여 준다.

DRAM 셀은 capacitor의 작은 전하로 정보를 저장하고 주기적으로 복원한다. 정상 retention은 외부 disturbance가 주어지지 않을 때의 보존 조건을 다룬다. 반복 활성화는 주변 회로에 영향을 줄 수 있으므로 같은 refresh 간격에서도 오류 경로가 달라진다. 공격 또는 stress를 가하는 행을 aggressor, 영향을 받는 행을 victim이라고 부르는 이유다.

[Flipping Bits in Memory Without Accessing Them, ISCA 2014 원문](https://people.inf.ethz.ch/omutlu/pub/dram-row-hammer_isca14.pdf)은 실제 DDR3 표본에서 반복 wordline 활성화에 따른 disturbance를 조사한다. 이 오래된 표본의 임계값을 최신 DRAM의 안전값으로 쓰면 안 된다. 또한 논문이 제시한 device-level 원인 후보를 모든 제품에서 확정된 단일 물리 원리로 말할 수는 없다. 관측된 명령 이력과 오류 관계, 회로 원인 가설은 구분해야 한다.

## retention만의 대조군을 만드는 생각 실험

victim에 같은 pattern을 쓰고 같은 온도·refresh 조건에서 같은 시간 동안 기다리는 두 실험을 놓자. A는 근처 row를 건드리지 않고, B는 aggressor를 반복 ACT-PRE한다. B에서만 victim 오류가 늘어난다면 “기다린 시간이 같으니 순수 retention만으로 설명된다”는 주장은 부족하다.

설명용으로 refresh 사이 window를1ms, aggressor row cycle을50ns라고 하면 그 안에 배치할 수 있는 반복의 산술 상한은20000회다. 실제 controller가 그렇게 발행할 수 있다는 주장이나 오류 threshold가20000이라는 뜻은 아니다. command bus, 다른 bank와 window 제약, 실제 workload가 반복 수를 제한한다. 이 예는 같은1ms라도 근처의 활동 이력이0회와 많은 횟수로 달라질 수 있음을 보여 준다.

실험에서 REF 개수만 같게 해도 모든 조건이 동일해지는 것은 아니다. victim이 실제로 복원된 내부 순서, aggressor open time, pattern, 다른 row의 활동이 결과에 들어갈 수 있다. 대조군은 비교하려는 변수 외의 조건을 가능한 한 맞춰야 한다.

## software 접근 수와 ACT 수 사이의 두 단계

CPU가 어떤 주소를 반복 load해도 대부분 cache hit라면 DRAM의 해당 행은 거의 활성화되지 않는다. cache 밖으로 내려와도 열린 row에서 column을 반복 읽으면 매번 새로운 ACT가 필요하지 않다. 그래서 software loop 횟수를 곧바로 row activation 횟수로 사용하면 물리 stress를 잘못 측정한다.

주소 관계도 중요하다. CPU의 연속 주소와 DRAM의 물리적인 이웃 wordline은 같다는 보장이 없다. controller mapping과 DRAM 내부 remapping이 있고, logical row 번호의±1이 곧 physical neighbor라는 단정도 위험하다. 오류 위치를 근거로 topology를 해석할 때는 알려진 주소 계층과 추정한 물리 관계를 구분해야 한다.

## refresh를 늘리는 처방의 범위

victim 복원을 더 자주 하면 disturbance가 쌓일 시간을 줄일 수 있다. 대신 refresh 작업량과 접근 정지가 늘고, 모든 device·pattern에서 동일 여유가 확보되는지 다시 검증해야 한다. count를 감시하거나 의심되는 이웃을 선택적으로 복원하는 방어에도 coverage와 상태 관리 비용이 있다.

ECC는 발생한 일부 bit 오류를 처리할 수 있지만 특정 word에 오류가 집중돼 correction 범위를 넘는 경우까지 자동으로 막지 않는다. refresh·활성화 관리·오류 code의 역할을 각각 표시하면 어느 실패 경로에 빈칸이 남는지 보인다. 보호 하나의 이름만으로 메모리 isolation을 보장했다고 판단하지 않는다.

RowHammer를 이해하는 좋은 출발점은 시간선에 victim의 복원과 aggressor의 ACT-PRE 이력을 함께 놓는 것이다. refresh가 정상이라는 사실과 disturbance가 없다는 사실은 서로 다른 조건이다. 직접 읽지 않은 행의 오류도 주변의 활동을 포함하면 설명할 수 있고, 그 설명에 맞는 방어와 검증 대조군을 선택할 수 있다.