정량 설계와 분석

심화 컴퓨터구조의 첫 문장은 꽤 냉정합니다. 어떤 설계가 좋다고 말하려면 숫자를 가져와야 합니다. “캐시를 키웠다”, “파이프라인을 깊게 했다”, “예측기가 똑똑하다”는 출발점일 뿐입니다. 진짜 질문은 얼마나 빨라졌는가, 어떤 프로그램에서 그런가, 전력과 비용은 얼마를 냈는가입니다. 이 장은 그 질문을 던지는 법을 배웁니다. 감상문에서 실험 보고서로 넘어가는 문턱이라고 보면 됩니다.

1.1 정량 설계의 태도

컴퓨터 아키텍트는 멋진 회로를 그리는 사람인 동시에 숫자 사이에서 타협을 중재하는 사람입니다. 성능을 올리면 전력이 튀고, 전력을 낮추면 지연 시간이 늘고, 면적을 줄이면 병렬성이 줄어듭니다. 하나를 당기면 다른 쪽이 따라 움직입니다. 그래서 심화 설계의 기본 자세는 “좋다/나쁘다”가 아니라 무엇을 얼마만큼 얻고 무엇을 내주었는가입니다.

1.2 성능 공식과 세 가지 손잡이

CPU 성능을 볼 때 가장 기본이 되는 식은 실행 시간을 세 덩어리로 나눕니다. 복잡한 설계도 결국 이 셋 중 하나를 건드립니다.

CPU 실행 시간 = 명령어 수 × CPI × 클럭 주기
             = 명령어 수 × CPI / 클럭 속도

성능 = 1 / 실행 시간

명령어 수는 프로그램, 컴파일러, ISA가 함께 결정합니다. CPI는 명령어 하나가 평균 몇 사이클을 먹는지이며, 파이프라인, 캐시, 분기 예측, 병렬 실행의 영향을 받습니다. 클럭 주기는 한 사이클의 길이로, 회로 경로와 공정, 전압, 발열과 얽혀 있습니다. 하나만 잡고 흔들면 나머지가 조용히 복수할 수 있습니다.

상대 성능을 말하는 법

“A가 B보다 빠르다”는 말은 실행 시간의 역수로 비교해야 깔끔합니다. B가 10초, A가 6초에 끝난다면 A는 B보다 10 / 6 = 1.67배 빠릅니다. 반대로 “40% 빠르다” 같은 표현은 기준을 헷갈리게 만들기 쉬우니, 보고서에서는 배율과 실행 시간을 함께 적는 편이 좋습니다.

1.3 벤치마크를 믿되, 너무 사랑하지 않기

벤치마크는 설계의 체중계입니다. 체중계가 없으면 다이어트가 감정이 되고, 벤치마크가 없으면 성능 논쟁이 목소리 크기 싸움이 됩니다. 하지만 체중계 숫자 하나로 건강을 다 설명할 수 없듯, 벤치마크 점수 하나로 컴퓨터를 다 설명할 수도 없습니다.

좋은 벤치마크는 실제 사용을 어느 정도 대표해야 하고, 반복 가능해야 하며, 측정 환경이 투명해야 합니다. 입력 데이터가 너무 작으면 캐시에 전부 들어가서 현실보다 예쁘게 보이고, 컴파일러 옵션이 과하게 맞춤화되면 제품의 평균 사용 경험과 멀어집니다. 심지어 벤치마크가 유명해질수록 설계가 그 벤치마크에 맞춰 자라나는 일도 생깁니다. 시험 범위가 공개되면 모두가 그 단원만 열심히 보는 법입니다.

1.4 암달의 법칙과 개선의 천장

어떤 부분을 대단히 빠르게 만들었다고 해서 전체 프로그램이 같은 비율로 빨라지는 것은 아닙니다. 전체 시간 중 개선되는 부분의 비율이 성능 향상의 천장을 정합니다. 이 불편한 진실을 공식으로 적으면 다음과 같습니다.

전체 속도 향상 = 1 / ((1 - F) + F / S)

F = 개선되는 부분이 전체 실행 시간에서 차지하는 비율
S = 그 부분의 속도 향상 배율

예를 들어 전체 실행 시간의 40%를 차지하는 부분을 10배 빠르게 해도 전체 속도 향상은 1 / (0.6 + 0.4 / 10) = 1.56배입니다. 그 부분을 무한히 빠르게 해도 최대는 1 / 0.6 = 1.67배입니다. 무한대라는 단어를 꺼냈는데 결과가 1.67배라니 조금 억울합니다. 하지만 이 억울함을 설계 전에 알려주는 게 암달의 법칙의 쓸모입니다.

Common case를 빠르게

암달의 법칙이 주는 실무적 조언은 단순합니다. 자주 일어나는 일을 빠르게 하세요. 드문 일을 100배 빠르게 만드는 것보다 흔한 일을 20% 줄이는 편이 전체에 더 클 수 있습니다. 그래서 프로파일링이 중요합니다. 병목은 상상 속에서 자주 변장합니다.

1.5 전력과 에너지

과거에는 클럭을 올리면 성능이 제법 순하게 따라왔습니다. 지금은 전력과 발열이 먼저 문 앞을 막습니다. 노트북은 팬 소리가 사용 경험이고, 휴대폰은 배터리가 제품성이고, 데이터센터는 전기 요금이 곧 운영비입니다.

동적 전력 ∝ 부하 정전용량 × 전압² × 스위칭 빈도
에너지 = 전력 × 시간

전력은 순간 소비량이고, 에너지는 일을 끝낼 때까지 쓴 총량입니다. 어떤 설계는 순간 전력은 높아도 빨리 끝나서 에너지가 낮을 수 있습니다. 반대로 얌전하게 오래 돌면 총 에너지가 커질 수 있습니다. 그래서 모바일과 서버에서는 “성능만”이 아니라 성능/와트, 작업당 에너지 같은 지표가 중요합니다.

1.6 신뢰성과 가용성

컴퓨터가 한 대일 때 고장은 이벤트입니다. 컴퓨터가 수만 대일 때 고장은 날씨에 가깝습니다. 언젠가가 아니라 계속 일어납니다. 그래서 대규모 시스템은 “고장이 안 나게”만 설계하지 않고, 고장이 나도 서비스가 계속되게 설계합니다.

가용성 = MTTF / (MTTF + MTTR)

MTTF = 평균 고장 간격
MTTR = 평균 수리 시간

MTTF가 길수록 좋고, MTTR이 짧을수록 좋습니다. 하지만 어느 쪽이 더 효과적인지는 상황에 따라 다릅니다. 아주 비싼 부품으로 고장을 줄이는 방법도 있고, 고장난 부품을 빠르게 우회하고 복구하는 방법도 있습니다. 클라우드와 데이터센터에서는 후자가 특히 중요합니다. 부품은 실패할 수 있지만, 서비스는 실패하지 않은 척해야 하니까요.

1.7 설계 판단의 체크리스트

이 장의 핵심은 공식을 외우는 데 있지 않습니다. 설계 제안을 만났을 때 어떤 질문을 던질지 몸에 익히는 데 있습니다. “더 빠릅니다”라는 말 뒤에 측정 조건과 대가를 붙이면, 설계 논의가 갑자기 어른스러워집니다.

성능

실행 시간, 처리량, 지연 시간 중 무엇을 말하는지 먼저 고릅니다.

비용

면적, 검증 시간, 제조 비용, 운영 비용까지 포함해서 봅니다.

전력

전력 제한에 걸리는지, 작업당 에너지는 줄었는지 따로 봅니다.

신뢰성

고장 확률만 보지 말고, 고장 후 복구 시간과 사용자 영향까지 봅니다.