Hacker News 2026.06.18 26

칩을 만들기 전에 '통째로 시뮬레이션'하는 기술이 다시 뜨는 이유

칩은 만들어보기 전에 어떻게 성능을 알까?

CPU나 새로운 반도체 칩을 설계하는 회사들은 큰 고민이 하나 있어요. 실제로 칩을 찍어내는 데는 수백억 원과 몇 달이 들거든요. 그런데 다 만들고 나서 '어? 생각보다 느리네' 하면 끝장이에요. 그래서 칩을 물리적으로 만들기 전에, 컴퓨터 안에서 그 칩이 어떻게 동작할지를 흉내 내보는 게 필수예요. 이걸 '아키텍처 시뮬레이션'이라고 해요.

쉽게 말하면, 설계도만 있는 가상의 CPU를 소프트웨어로 만들어두고 '이 CPU에서 이 프로그램을 돌리면 몇 사이클이 걸릴까?'를 미리 계산해보는 거예요. 건물을 짓기 전에 3D 모델로 바람과 하중을 시뮬레이션하는 것과 비슷해요. SIGARCH(컴퓨터 아키텍처 학회의 블로그)에서 최근 다룬 이야기는, 이 '엄밀한 풀 시스템 타이밍 시뮬레이션'이 다시 중요해지고 있다는 거예요.

'풀 시스템'과 '타이밍'이라는 두 단어

여기서 두 단어를 풀어볼게요. 먼저 '타이밍 시뮬레이션'이에요. 시뮬레이션에는 크게 두 종류가 있어요. 하나는 '기능만 흉내 내기'예요. 계산 결과가 맞는지만 보는 거죠. 1+1=2가 잘 나오는지만 확인하고, 그게 몇 나노초 걸리는지는 신경 안 써요. 빠르지만 성능은 알 수 없어요. 다른 하나가 '타이밍 시뮬레이션'인데, 이건 매 클럭 사이클마다 파이프라인, 캐시, 메모리 지연까지 다 따져요. 정확하지만 엄청나게 느려요. 실제 1초짜리 작업을 시뮬레이션하는 데 몇 시간씩 걸리기도 해요.

'풀 시스템(full-system)'은 또 다른 차원이에요. 보통은 내가 짠 프로그램(유저 코드)만 시뮬레이션하면 된다고 생각하기 쉬운데, 현실의 성능은 그렇게 단순하지 않아요. 운영체제(OS)가 스케줄링하고, 인터럽트가 끼어들고, 네트워크 카드와 디스크가 끼어들고, 여러 코어가 서로 신호를 주고받죠. 풀 시스템 시뮬레이션은 이 운영체제와 주변 장치까지 통째로, 심지어 부팅부터 시뮬레이션 안에 넣는 거예요. 진짜 컴퓨터 한 대를 통째로 가상으로 돌리는 셈이죠.

왜 지금 '다시' 뜨는가

한동안 이 분야는 시들했어요. 너무 느리니까요. 대신 사람들은 빠른 근사 모델이나 일부 구간만 뽑아 측정하는 샘플링 기법(예: SimPoint)으로 때웠어요. 무어의 법칙 덕에 그냥 가만히 있어도 칩이 빨라지던 시절엔 그렇게 대충 해도 됐고요.

그런데 상황이 바뀌었어요. 무어의 법칙이 둔해지면서, 이제 성능은 'CPU 코어 하나를 더 빠르게'가 아니라 'GPU, AI 가속기, 특수 칩들을 어떻게 잘 엮느냐'에서 나와요. 그리고 요즘 워크로드, 그러니까 데이터센터의 마이크로서비스나 AI 추론 작업은 OS와 하드웨어 경계를 마구 넘나들어요. 이런 복잡한 동작은 유저 코드만 떼어내서는 절대 정확히 못 잡아요. 운영체제, 메모리, 가속기가 뒤엉킨 전체 그림을 봐야만 진짜 성능이 보이거든요. 그래서 느려도 정확한 '풀 시스템 타이밍 시뮬레이션'으로 다시 눈을 돌리는 거예요.

도구들과 업계 지형

이 바닥의 대표 도구는 gem5예요. 학계와 업계가 함께 쓰는 오픈소스 시뮬레이터인데, CPU·캐시·메모리·OS까지 통째로 모델링할 수 있어요. 상용으로는 Wind River의 Simics 같은 것도 있고요. 너무 느린 문제를 풀려고 FPGA(프로그래밍 가능한 하드웨어 칩)에 시뮬레이터를 얹어 가속하는 FireSim 같은 프로젝트도 활발해요.

특히 RISC-V(누구나 무료로 쓸 수 있는 개방형 CPU 설계 표준)가 뜨면서, 스타트업이나 연구실도 자기만의 칩을 설계하는 시대가 됐어요. 직접 칩을 만든다는 건 곧 '만들기 전에 정확히 시뮬레이션할 도구'가 필요하다는 뜻이고요. 그래서 이 정확한 시뮬레이션 기술이 다시 주목받는 거예요.

한국 개발자에게는?

솔직히 웹·앱 개발자가 내일 당장 gem5를 켤 일은 없어요. 하지만 두 부류에겐 진짜 중요해요. 첫째, 삼성·SK하이닉스나 반도체 스타트업, 시스템 반도체 쪽으로 가려는 분들. 이건 그 세계의 핵심 도구이자 공용어예요. 둘째, 성능 엔지니어링을 깊게 파는 분들. '왜 내 서비스가 이 하드웨어에서 이만큼만 나오지?'를 끝까지 파고들면 결국 캐시, 메모리 대역폭, OS 스케줄링 같은 이 시뮬레이션이 다루는 영역에 닿거든요.

당장 안 쓰더라도, '소프트웨어 성능은 결국 하드웨어 전체의 합주'라는 감각을 갖는 것만으로도 시야가 넓어져요. 클라우드 인스턴스를 고를 때나 병목을 찾을 때 막연한 추측 대신 구조적으로 생각하게 되거든요.