2025년 9월 15일·7분
데이비드 패터슨: RISC 사고와 공동설계의 지속적 영향
데이비드 패터슨의 RISC 사고와 하드웨어·소프트웨어 공동설계가 성능 대비 전력 효율을 어떻게 향상시키고 CPU 설계를 형성했으며 오늘날 RISC-V에 어떤 영향을 미쳤는지 알아봅니다.
데이비드 패터슨의 RISC 사고와 하드웨어·소프트웨어 공동설계가 성능 대비 전력 효율을 어떻게 향상시키고 CPU 설계를 형성했으며 오늘날 RISC-V에 어떤 영향을 미쳤는지 알아봅니다.
데이비드 패터슨은 종종 “RISC 개척자”로 소개되지만, 그의 지속적인 영향력은 특정 CPU 설계 하나를 넘어섭니다. 그는 컴퓨터에 대해 실용적인 사고방식을 대중화하는 데 기여했습니다. 즉 성능을 측정하고 단순화하며 전체 시스템 관점에서 개선하라는 접근입니다 — 칩이 이해하는 명령에서부터 그 명령을 생성하는 소프트웨어 도구까지 말입니다.
RISC(축소 명령어 집합 컴퓨팅)는 프로세서가 더 작은 집합의 단순한 명령에 집중할 때 더 빠르고 예측 가능하게 동작할 수 있다는 아이디어입니다. 하드웨어에 복잡한 연산 메뉴를 가득 채우는 대신, 흔히 쓰이는 연산을 빠르고 규칙적으로 파이프라인화하기 쉽게 만듭니다. 대가는 “능력 부족”이 아니라, 단순한 빌딩 블록을 효율적으로 실행할 때 실제 워크로드에서 더 좋은 성능을 내는 경우가 많다는 점입니다.
패터슨은 또한 하드웨어–소프트웨어 공동설계를 옹호했습니다. 이는 칩 설계자, 컴파일러 작성자, 시스템 디자이너가 반복적으로 피드백하며 함께 작업하는 루프입니다.
프로세서가 단순한 패턴을 잘 실행하도록 설계되면, 컴파일러는 그 패턴을 신뢰성 있게 만들어낼 수 있습니다. 반대로 컴파일러가 실제 프로그램이 특정 연산(예: 메모리 접근)에 많은 시간을 소비한다는 걸 보여주면, 하드웨어는 그 케이스를 더 잘 처리하도록 조정될 수 있습니다. 그래서 명령어 집합 구조(ISA)에 대한 논의가 자연스럽게 컴파일러 최적화, 캐시, 파이프라이닝과 연결됩니다.
이 글을 읽으면 RISC 아이디어가 단순한 속도뿐 아니라 성능 대비 전력과 어떻게 연결되는지, “예측 가능성”이 현대 CPU와 모바일 칩을 어떻게 더 효율적으로 만드는지, 그리고 이러한 원칙이 노트북에서 클라우드 서버에 이르기까지 오늘날의 기기에서 어떻게 나타나는지를 알게 될 것입니다.
더 깊이 들어가기 전에 핵심 개념 지도를 보고 싶다면 /blog/key-takeaways-and-next-steps로 건너뛰세요.
초기 마이크로프로세서는 회로를 넣을 공간이 제한되고, 메모리는 비쌌으며, 저장장치는 느린 환경에서 설계되었습니다. 디자이너들은 저렴하고 “충분히 빠른” 컴퓨터를 내놓으려 했고, 종종 작은 캐시(또는 없음), 낮은 클럭 속도, 소프트웨어가 원하는 것에 비해 매우 제한된 주기억장치를 가진 시스템이 나왔습니다.
당시 널리 퍼진 생각은 CPU가 더 강력한 고수준 명령어를 제공하면 — 여러 단계의 작업을 한 번에 처리할 수 있는 명령어 — 프로그램이 더 빠르게 실행되고 작성도 쉬워질 것이라는 것이었습니다. 하나의 명령어가 “여러 개의 작업을 대신” 한다면 전체 명령어 수가 줄어 시간과 메모리를 절약할 것이라는 직관이 있었죠.
이것이 많은 CISC(복잡 명령어 집합 컴퓨팅) 설계의 직관입니다: 프로그래머와 컴파일러에 화려한 도구 상자를 제공하는 겁니다.
문제는 실제 프로그램(및 이를 번역하는 컴파일러)이 그 복잡성을 일관되게 활용하지 않았다는 점입니다. 가장 정교한 명령어들 중 많은 것이 드물게 사용된 반면, 작은 집합의 단순한 연산 — 데이터 로드, 저장, 더하기, 비교, 분기 — 가 반복적으로 등장했습니다.
동시에 방대한 복잡한 명령어 메뉴를 지원하는 일은 CPU를 설계하기 어렵게 만들고 최적화 시간을 늘렸습니다. 복잡성은 칩 면적과 설계 노력을 소모해, 오히려 일상적인 동작을 예측 가능하고 빠르게 만드는 데 쓰일 수 있는 자원을 잠식했습니다.
RISC는 그 격차에 대한 응답이었습니다: CPU를 소프트웨어가 실제로 자주 하는 일에 집중시키고, 그 경로들을 빠르게 만든 다음, 컴파일러가 더 많은 ‘오케스트레이션’을 체계적으로 하게 하자는 것입니다.
CISC(복잡 명령어 집합)는 여러 단계의 작업을 한 번에 수행할 수 있는 많은 전문화된 도구를 갖춘 작업장을 닮았습니다. 하나의 명령어가 메모리에서 데이터를 불러오고 계산을 수행한 뒤 결과를 저장할 수 있습니다.
RISC(축소 명령어 집합)는 자주 사용하는 신뢰할 수 있는 소수의 도구(망치, 드라이버, 줄자)를 들고 다니며 반복 가능한 단계로 모든 것을 만드는 것과 같습니다. 각 명령어는 하나의 작은, 명확한 일을 수행하는 경향이 있습니다.
명령어가 더 단순하고 균일하면 CPU는 더 깔끔한 조립 라인(파이프라인)을 만들 수 있습니다. 그 조립 라인은 설계하기 쉽고 더 높은 클럭으로 동작시키기 쉬우며 바쁘게 유지하기 쉬워집니다.
CISC 스타일의 ‘한 번에 많은 일을 하는’ 명령어에서는 CPU가 복잡한 명령어를 디코드하고 내부적으로 더 작은 단계로 분해해야 하는 경우가 많습니다. 이는 복잡성을 더하고 파이프라인을 원활하게 유지하기 어렵게 만들 수 있습니다.
RISC는 명령어 실행 시간의 예측 가능성을 목표로 합니다 — 많은 명령어가 대략 비슷한 시간에 실행됩니다. 예측 가능성은 CPU가 작업을 효율적으로 스케줄링하게 하고 컴파일러가 파이프라인을 멈추게 하지 않는 코드를 생성하게 돕습니다.
RISC는 같은 작업을 수행하는 데 더 많은 명령어가 필요할 수 있습니다. 이는 다음을 의미할 수 있습니다:
그러나 각 명령어가 빠르고 파이프라인이 매끄럽게 유지된다면 이는 여전히 좋은 거래일 수 있습니다.
실무에서는 잘 최적화된 컴파일러와 좋은 캐시가 ‘명령어 수 증가’의 단점을 상쇄하고, CPU가 복잡한 명령어를 풀어내느라 낭비하는 시간보다 실제 연산에 더 많은 시간을 쓰게 합니다.
버클리 RISC는 단순히 새로운 ISA가 아니었습니다. 그것은 연구 태도였습니다: 종이 위에서 우아해 보이는 것부터 시작하지 말고 — 프로그램이 실제로 무엇을 하는지부터 시작해 CPU를 그 현실에 맞춰 설계하라.
개념적으로 버클리 팀은 매우 빠르고 예측 가능하게 동작할 수 있는 단순한 CPU 코어를 목표로 했습니다. 하드웨어에 많은 복잡한 명령어 ‘트릭’을 채우는 대신, 컴파일러가 더 많은 작업을 하도록 의존했습니다: 간단한 명령어를 선택하고, 이를 잘 스케줄링하며, 가능한 한 데이터를 레지스터에 유지하도록 하는 식입니다.
이런 역할 분담은 중요했습니다. 더 작고 깔끔한 코어는 파이프라인화가 쉽고, 설계와 이해가 쉬우며, 트랜지스터당 성능이 더 좋을 때가 많습니다. 컴파일러는 프로그램 전체를 보기 때문에 하드웨어가 런타임에 즉시 하기 어려운 방식으로 미리 계획할 수 있습니다.
데이비드 패터슨은 측정을 강조했습니다. 컴퓨터 설계에는 유혹적인 신화가 많아, 유용해 보이지만 실제 코드에서는 거의 사용되지 않는 기능들이 생기기 쉽습니다. 버클리 RISC는 벤치마크와 워크로드 트레이스를 사용해 핫패스(루프, 함수 호출, 메모리 접근 등)를 찾아내도록 밀어붙였습니다.
이는 ‘일반적인 경우를 빠르게 만드는’ 원칙과 직접 연결됩니다. 대부분의 명령어가 단순 연산과 로드/스토어라면, 그 빈번한 경우를 최적화하는 것이 희귀한 복잡한 명령어를 가속화하는 것보다 더 큰 이득을 줍니다.
지속되는 교훈은 RISC가 아키텍처이자 사고방식이라는 점입니다: 자주 일어나는 것을 단순화하고, 데이터로 검증하며, 하드웨어와 소프트웨어를 하나의 시스템으로 보고 함께 조정하라는 것입니다.
하드웨어–소프트웨어 공동설계는 CPU를 고립된 상태로 설계하지 않는다는 생각입니다. 칩과 컴파일러(그리고 때로는 운영체제)를 서로 염두에 두고 함께 설계하면, 합성적 ‘베스트 케이스’ 명령어 시퀀스가 아니라 실제 프로그램이 빠르고 효율적으로 실행되게 됩니다.
공동설계는 다음 같은 엔지니어링 루프로 작동합니다:
ISA 선택: 어떤 동작을 CPU가 쉽게 표현할지 결정합니다(예: 로드/스토어 모델, 충분한 레지스터, 단순한 주소 지정모드).
컴파일러 전략: 컴파일러는 핫 변수는 레지스터에 유지하고, 스톨을 피하도록 명령어를 재배열하며, 호출 규약을 선택하는 등 적응합니다.
워크로드 결과: 실제 프로그램을 측정해 시간과 에너지가 어디에 쓰이는지 확인합니다.
다음 설계: 측정에 따라 ISA와 마이크로아키텍처(파이프라인 깊이, 레지스터 수, 캐시 크기 등)를 조정합니다.
작은 루프(C 예제)는 관계를 잘 보여줍니다:
for (int i = 0; i < n; i++)
sum += a[i];
RISC 스타일 ISA에서는 컴파일러가 일반적으로 sum과 i를 레지스터에 유지하고, a[i]에 대해 간단한 load 명령을 사용하며, 로드가 진행되는 동안 CPU가 바쁘게 일하도록 명령어 스케줄링을 수행합니다.
칩이 컴파일러가 거의 사용하지 않는 복잡한 명령어나 특수 하드웨어를 추가하면, 그 영역은 여전히 전력과 설계 노력을 소비합니다. 반면 컴파일러가 실제로 의존하는 ‘단조로운’ 것들 — 충분한 레지스터, 예측 가능한 파이프라인, 효율적인 호출 규약 — 이 과소투자될 수 있습니다.
패터슨의 RISC 사고는 실제 소프트웨어가 혜택을 받을 수 있는 곳에 실리콘을 투자하라고 강조했습니다.
핵심 RISC 아이디어는 CPU의 ‘조립 라인’을 더 바쁘게 유지하는 것이었습니다. 이 조립 라인이 바로 파이프라인입니다: 프로세서는 한 명령어를 완전히 끝내기 전에 작업을 단계(페치, 디코드, 실행, 라이트백)로 나누고 겹쳐서 수행합니다. 모든 것이 원활하면 주기당 거의 한 명령어를 완료할 수 있습니다 — 마치 여러 공정 스테이션을 가진 공장에서 차들이 이동하는 것과 같습니다.
파이프라인은 각 항목이 비슷할 때 가장 잘 작동합니다. RISC 명령어는 상대적으로 균일하고 예측 가능하게(종종 고정 길이, 단순한 주소 지정) 설계되어 특수 사례가 줄어듭니다. 이는 한 명령어가 추가 시간을 필요로 하거나 특이한 자원을 요구하는 경우를 줄입니다.
실제 프로그램은 완벽히 부드럽지 않습니다. 때로는 어떤 명령어가 이전 명령어의 결과에 의존해(결과가 준비되기 전엔 사용할 수 없음) 대기해야 합니다. 때로는 메모리에서 데이터를 기다리거나 분기가 어느 경로로 갈지 모를 때도 있습니다.
이런 상황들이 스톨을 유발합니다 — 파이프라인의 일부가 유휴 상태가 되는 짧은 정지. 기본 직관은 간단합니다: 다음 단계가 필요한 것을 아직 받지 못하면 유용한 작업을 할 수 없어 멈춘다는 것입니다.
여기서 하드웨어–소프트웨어 공동설계가 분명히 나타납니다. 하드웨어가 예측 가능하면 컴파일러가 도울 수 있습니다. 컴파일러는 프로그램 의미를 바꾸지 않으면서 명령어 순서를 재배치해 ‘틈’을 메꿀 수 있습니다. 예를 들어 값이 준비되기를 기다리는 동안, 그 값에 의존하지 않는 독립된 명령어를 앞에 놓을 수 있습니다.
그 결과는 역할 분담의 이득입니다: 일반적인 경우에 CPU는 더 단순하고 빠르게 유지되고, 컴파일러는 더 많은 계획을 수행해 스톨을 줄이며 처리량을 높입니다 — 종종 더 복잡한 명령어 세트를 추가하지 않고도 실제 성능을 개선합니다.
CPU는 몇 사이클 만에 단순한 연산을 수행할 수 있지만, 메인 메모리(DRAM)에서 데이터를 가져오는 데는 수백 사이클이 걸릴 수 있습니다. 이 차이는 DRAM이 물리적으로 더 멀고 용량·비용에 최적화되어 있으며 지연(latency)과 대역폭(bandwidth) 제약을 받기 때문입니다.
CPU가 빨라질수록 메모리는 같은 속도로 따라오지 못했고 — 이 커지는 불일치는 흔히 ‘메모리 월’이라고 불립니다.
캐시는 CPU 가까이에 배치된 작고 빠른 메모리로, 모든 접근에 DRAM의 패널티를 지불하지 않도록 합니다. 캐시는 실제 프로그램이 지역성을 가진다는 점에 의존합니다:
현대 칩은 캐시를 계층적으로 쌓아(L1, L2, L3) 코어의 ‘워킹 셋’을 가깝게 유지하려 합니다.
여기서 하드웨어–소프트웨어 공동설계의 가치가 드러납니다. ISA와 컴파일러는 프로그램이 생성하는 캐시 압력에 큰 영향을 줍니다.
일상적으로 말하면, 메모리 월 때문에 높은 클럭 속도를 가진 CPU도 느리게 느껴질 수 있습니다: 큰 앱을 열거나 데이터베이스 쿼리를 실행하거나 피드를 스크롤하거나 큰 데이터셋을 처리할 때는 캐시 미스와 메모리 대역폭이 병목이 되는 경우가 많습니다 — 원시 산술 속도가 병목이 되는 경우는 드뭅니다.
오랫동안 CPU 논의는 누가 작업을 더 빨리 끝내느냐의 경쟁처럼 들렸습니다. 그러나 실제 컴퓨터는 물리적 한계 — 배터리 용량, 열, 팬 소음, 전기요금 — 안에서 동작합니다.
그래서 성능 대비 전력이 핵심 지표가 되었습니다: 소비하는 에너지 대비 얼마나 많은 유용한 작업을 얻는가입니다.
이는 최고 성능이 아니라 효율을 뜻합니다. 두 프로세서가 일상에서 비슷하게 빠르게 느껴질 수 있지만, 하나는 더 적은 전력을 소모하며 더 시원하게 유지되고 같은 배터리로 더 오래 동작할 수 있습니다.
노트북과 폰에서는 배터리 수명과 사용 쾌적성에 직접 영향을 미치고, 데이터센터에서는 수천 대의 기계를 전력과 냉각 비용 측면에서 운영하는 비용에 영향을 미칩니다.
RISC 사고는 하드웨어에서 더 적은 일을 하되 예측 가능성을 높이는 방향으로 CPU 설계를 이끌었습니다. 단순한 코어는 전력면에서 다음과 같은 이점을 줄 수 있습니다:
중요한 점은 ‘단순함이 항상 최고’가 아니라는 것입니다. 복잡성에는 에너지 비용이 있고, 잘 선택된 ISA와 마이크로아키텍처는 작은 기법적 절충으로 큰 효율을 얻을 수 있습니다.
폰은 배터리와 발열을, 서버는 전력 공급과 냉각을 신경 씁니다. 환경은 다르지만 교훈은 같습니다: 가장 빠른 칩이 항상 가장 좋은 컴퓨터는 아닙니다. 안정적 처리량을 전력 내에서 제공하는 설계가 종종 승자입니다.
RISC는 흔히 ‘더 단순한 명령어가 승리했다’로 요약되지만, 더 오래가는 교훈은 미묘합니다: 명령어 집합은 중요하지만, 많은 실제 이득은 ISA 자체보다 칩을 어떻게 구현했는지에서 나왔습니다.
초기 RISC 주장은 더 깔끔하고 작은 ISA가 자동으로 컴퓨터를 빠르게 만든다고 암시했습니다. 실제로는 RISC가 가능하게 한 구현 선택들 — 단순한 디코딩, 더 깊은 파이프라인, 높은 클럭, 컴파일러가 예측 가능하게 스케줄할 수 있는 구조 — 이 더 큰 속도 향상을 가져온 경우가 많습니다.
이 때문에 서로 다른 ISA를 가진 두 CPU가 마이크로아키텍처, 캐시 크기, 분기 예측, 공정 차이에 따라 놀랄 만큼 비슷한 성능을 보일 수 있습니다. ISA는 규칙을 정하고, 마이크로아키텍처가 게임을 하는 셈입니다.
패터슨 시대의 핵심 변화는 가정이 아니라 데이터로 설계하는 것이었습니다. 사용될 것처럼 보인다고 해서 명령어를 추가하기보다는, 팀들이 실제 프로그램이 무엇을 하는지를 측정하고 흔한 경우를 최적화했습니다.
이런 사고방식은 기능 중심 설계보다 자주 더 좋은 결과를 냈습니다. 또한 트레이드오프를 명확히 합니다: 몇 줄의 코드를 절약해주는 명령어는 사이클, 전력, 칩 면적을 더 소비할 수 있고, 그 비용은 모든 곳에서 드러납니다.
RISC 사고는 ‘RISC 칩’에만 영향을 준 것이 아닙니다. 시간이 흐르면서 많은 CISC CPU들은 내부적으로 RISC 같은 기법(복잡한 명령어를 더 단순한 내부 연산으로 분해 등)을 도입하면서 호환성 있는 ISA를 유지했습니다.
결과는 ‘RISC가 CISC를 이겼다’가 아니라, 측정, 예측 가능성, 하드웨어–소프트웨어 조정에 가치를 두는 설계로의 진화였습니다 — ISA 로고와 상관없이요.
RISC는 연구실에만 머물지 않았습니다. 초기 연구에서 현대 관행으로 이어지는 명확한 맥락 중 하나는 MIPS에서 RISC-V로 이어지는 흐름입니다 — 단순성과 명료성을 특징으로 삼은 두 ISA입니다.
MIPS는 교육용 ISA로 기억되는 경우가 많지만, 그럴 만한 이유가 있습니다: 규칙을 설명하기 쉽고 명령어 형식이 일관되며 로드/스토어 모델이 컴파일러 작업을 방해하지 않습니다.
그러한 깔끔함은 학문적 측면뿐 아니라 실제 제품에도 기여했습니다. MIPS 프로세서는 워크스테이션에서 임베디드 시스템까지 오랫동안 실제품에 탑재되었는데, 규칙적이고 직관적인 ISA는 빠른 파이프라인, 예측 가능한 컴파일러, 효율적인 툴체인을 만들기 쉽기 때문입니다.
RISC-V는 MIPS가 하지 못한 한 걸음을 내디뎠습니다: 오픈 ISA라는 점입니다. 이 점은 인센티브를 바꿉니다. 대학, 스타트업, 대기업이 ISA 접근 문제 없이 실험하고 실리콘을 출시하며 툴링을 공유할 수 있습니다.
공동설계 관점에서는 이 개방성이 중요합니다. 소프트웨어 측(컴파일러, OS, 런타임)이 하드웨어 측과 공개적으로 함께 발전할 수 있기 때문입니다.
RISC-V가 공동설계와 잘 맞는 또 다른 이유는 모듈식 접근입니다. 작은 베이스 ISA에서 시작해 벡터 연산, 임베디드 제약, 보안 기능 같은 확장을 필요에 따라 추가할 수 있습니다.
이 방식은 모든 기능을 하나의 모놀리식 설계에 쑤셔 넣는 대신, 하드웨어 기능을 실제로 실행될 소프트웨어에 맞추는 건강한 절충을 장려합니다.
더 깊은 입문을 원하면 /blog/what-is-risc-v를 참고하세요.
공동설계는 RISC 시대의 역사적 주석이 아니라 현대 컴퓨팅이 더 빨라지고 효율적으로 진화하는 방식입니다. 핵심 아이디어는 패터슨식입니다: 하드웨어만으로 또는 소프트웨어만으로 ‘이기는’ 것이 아니라 둘이 서로의 강점과 제약을 맞출 때 이긴다는 것.
스마트폰과 많은 임베디드 장치는 RISC 원칙(대개 ARM 기반)을 많이 따릅니다: 단순한 명령어, 예측 가능한 실행, 에너지 사용에 대한 강한 강조.
이 예측 가능성은 컴파일러가 효율적인 코드를 생성하도록 돕고, 디자이너가 스크롤링 중에는 전력을 적게 쓰고 카메라 파이프라인이나 게임에선 순간적으로 성능을 끌어올릴 수 있는 코어를 설계하는 데 유리합니다.
노트북과 서버도 점점 같은 목표 — 특히 성능 대비 전력 — 를 추구합니다. 전통적 RISC ISA가 아니더라도 많은 내부 설계 선택은 RISC와 유사한 효율성을 목표로 합니다: 깊은 파이프라인, 넓은 실행 유닛, 공격적인 전력 관리와 실제 소프트웨어 동작에 맞춘 튜닝 등입니다.
GPU, AI 가속기(TPU/ NPU), 미디어 엔진은 공동설계의 실용적 형태입니다: 모든 작업을 범용 CPU에 억지로 통과시키는 대신 플랫폼이 공통 연산 패턴에 맞춘 하드웨어를 제공합니다.
이것이 단순한 추가 하드웨어가 아니라 공동설계인 이유는 주변 소프트웨어 스택에 있습니다:
소프트웨어가 가속기를 대상화하지 않으면 이론적 속도는 현실화되지 않습니다.
유사한 사양을 가진 두 플랫폼이 서로 다르게 느껴지는 이유는 ‘실제 제품’에 컴파일러, 라이브러리, 프레임워크가 포함되기 때문입니다. 잘 최적화된 수학 라이브러리(BLAS), 좋은 JIT, 똑똑한 컴파일러는 칩을 바꾸지 않고도 큰 성능 향상을 만들 수 있습니다.
이 때문에 현대 CPU 설계는 벤치마크 중심인 경우가 많습니다: 하드웨어 팀은 컴파일러와 워크로드가 실제로 무엇을 하는지 보고 캐시, 분기 예측, 벡터 명령, 프리페치 같은 기능을 조정합니다.
플랫폼(폰, 노트북, 서버, 임베디드 보드)을 평가할 때 공동설계 신호를 찾으려면:
현대 컴퓨팅의 진보는 단일 ‘더 빠른 CPU’가 아니라 실제 워크로드에 맞춰 측정하고 설계된 전체 하드웨어+소프트웨어 시스템에서 옵니다.
RISC 사고와 패터슨의 넓은 메시지는 몇 가지 오래가는 교훈으로 요약할 수 있습니다: 빠르게 해야 할 것을 단순화하라, 실제로 일어나는 일을 측정하라, 그리고 하드웨어와 소프트웨어를 하나의 시스템으로 보라 — 사용자는 구성 요소가 아니라 전체를 경험하기 때문입니다.
첫째, 단순함은 전략이지 미학이 아닙니다. 깔끔한 ISA와 예측 가능한 실행은 컴파일러가 좋은 코드를 생성하고 CPU가 그 코드를 효율적으로 실행하기 쉽게 만듭니다.
둘째, 측정이 직관보다 낫습니다. 대표 워크로드로 벤치마크를 수행하고 프로파일 데이터를 수집해 실제 병목을 설계 결정의 지표로 삼으세요 — 컴파일러 최적화, CPU SKU 선택, 중요한 핫패스 재설계 등 어느 경우든 마찬가지입니다.
셋째, 공동설계에서 이득이 누적됩니다. 파이프라인에 친화적인 코드, 캐시를 고려한 데이터 구조, 현실적인 성능 대비 전력 목표는 이론적 최대치보다 실제 작업에서 더 큰 속도를 제공합니다.
플랫폼(x86, ARM, 또는 RISC-V 기반 시스템)을 선택할 때는 사용자가 실제로 사용하는 방식으로 평가하세요:
이 측정들을 실제 소프트웨어로 옮겨 출시하는 일이 일부라면, 빌드–측정 루프를 단축하는 것이 도움이 됩니다. 예를 들어 팀들은 Koder.ai 같은 도구를 사용해 채팅 기반 워크플로(웹, 백엔드, 모바일)로 실제 애플리케이션을 프로토타입하고 반복하며 각 변경 후 동일한 엔드투엔드 벤치마크를 다시 실행합니다. 플래닝 모드, 스냅샷, 롤백 같은 기능은 패터슨이 강조한 ‘측정하고 설계하라’는 규율을 현대 제품 개발에 적용하는 사례입니다.
효율성에 대한 더 깊은 입문은 /blog/performance-per-watt-basics를 참고하세요. 환경을 비교하고 간단히 비용/성능 절충을 추정하려면 /pricing이 도움이 될 수 있습니다.
지속되는 교훈은 이렇습니다: 단순성, 측정, 공동설계라는 아이디어는 MIPS 시대의 파이프라인에서 현대의 이종 코어와 RISC-V 같은 새로운 ISA로 구현이 진화하더라도 계속해서 가치를 창출합니다.
RISC(축소 명령어 집합 컴퓨팅)는 파이프라인화와 최적화가 쉬운, 작고 단순하며 규칙적인 명령어를 강조합니다. 목표는 ‘기능이 적다’가 아니라 실제 프로그램에서 자주 쓰이는 연산(로드/스토어, 산술, 분기)에 대해 더 예측 가능하고 효율적인 실행을 달성하는 것입니다.
CISC는 메모리에서 불러오기, 계산, 결과 저장처럼 여러 단계를 한 번에 수행하는 복잡한 명령어를 많이 제공하는 반면, RISC는 작은 빌딩 블록(대개는 로드/스토어와 ALU 연산)을 사용합니다. RISC는 컴파일러가 이 작은 블록을 효율적으로 조합하도록 기대합니다. 다만 현대 CPU에서는 많은 CISC 설계가 내부적으로 복잡한 명령어를 더 단순한 내부 마이크로작업으로 변환하기 때문에 둘의 경계는 흐려졌습니다.
명령어가 더 단순하고 균일하면 CPU는 더 매끄러운 ‘조립 라인’(파이프라인)을 설계할 수 있습니다. 그러면 대부분의 주기가 유용한 작업으로 채워져 처리량이 증가하고, 특수 처리나 예외를 다루느라 낭비되는 시간이 줄어듭니다. 결과적으로 단순한 명령어들이 실제 워크로드에서 더 빠르게 동작할 수 있습니다.
예측 가능한 ISA와 실행 모델은 컴파일러가 다음을 안정적으로 하게 합니다:
이로써 파이프라인의 버블(빈 공간)을 줄이고, 복잡한 하드웨어 기능 없이도 실제 성능을 끌어올릴 수 있습니다.
하드웨어–소프트웨어 공동설계는 CPU를 고립된 제품으로 설계하지 않는다는 뜻입니다. ISA 선택, 컴파일러 전략, 실제 워크로드 측정이 서로 피드백을 주고받으면서 반복적으로 조정됩니다. 이 과정에서 하드웨어와 툴체인, 때로는 OS/런타임까지 함께 튜닝되어 실제 프로그램이 빠르고 효율적으로 동작하도록 만듭니다.
파이프라인이 멈추는(스톨나는) 이유는 주로 다음과 같습니다:
이런 스톨은 파이프라인의 일부가 유휴 상태가 되게 하므로 성능 손실로 이어집니다. RISC 스타일의 예측 가능성은 하드웨어와 컴파일러가 이런 경우를 줄이는 데 도움을 줍니다.
‘메모리 월’은 빠른 CPU 실행 속도와 느린 메인 메모리(DRAM) 접근 간의 벌어짐을 의미합니다. 캐시는 CPU에 가까운 작은 고속 메모리로, 시간적·공간적 지역성을 이용해 DRAM 접근을 줄입니다. 하지만 캐시 미스가 발생하면 수백 사이클을 기다려야 할 수 있어 실제 성능에 큰 영향을 미칩니다.
‘성능 대비 전력(Performance per watt)’은 단위 에너지로 얼마나 많은 유용한 작업을 수행하는지를 나타내는 효율성 지표입니다. 배터리 수명, 발열, 데이터센터의 전력·냉각 비용에 직접적인 영향을 미치죠. RISC 사고는 예측 가능한 실행과 불필요한 스위칭 감소를 통해 이 효율을 개선하는 방향으로 하드웨어를 유도합니다.
단순히 ‘RISC가 CISC를 완전히 이겼다’는 프레임은 잘못된 해석입니다. 많은 CISC 설계는 내부적으로 RISC와 유사한 기법(명령어를 더 단순한 내부 마이크로옵으로 분해 등)을 도입했습니다. 진정한 승리는 사고방식의 변화에 있습니다: 실제 워크로드를 측정하고, 흔한 경우를 최적화하며, 하드웨어와 소프트웨어를 긴밀히 맞춰나가는 접근입니다.
RISC-V는 작은 베이스 ISA와 모듈형 확장을 갖춘 오픈 ISA로, 공동설계에 특히 적합합니다. 대학, 스타트업, 대기업이 ISA 접근성 문제 없이 실험하고 툴체인을 함께 발전시킬 수 있기 때문입니다. ‘단순한 코어 + 강한 툴링 + 측정’이라는 전통적 RISC 정신을 현대적으로 이어가는 예라고 볼 수 있습니다. 자세한 내용은 /blog/what-is-risc-v을 참고하세요.