196. CISC (Complex Instruction Set Computer)

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

본질: CISC(Complex Instruction Set Computer)는 하나의 명령어가 길고 복잡한 작업을 한 번에 처리할 수 있도록, 가변 길이 명령어 포맷과 **다양한 주소 지정 방식(메모리 연산 포함)**을 제공하는 아키텍처다.

가치: 컴파일러 기술이 미숙하고 메모리가 비쌌던 시절, 소프트웨어 개발자(어셈블리 프로그래머)의 부담을 덜어주고 코드의 메모리 차지 용량을 극한으로 압축하는 데 가장 큰 공헌을 했다.

융합: 초고속 병렬 실행(파이프라인)의 한계에 부딪혔으나, 현대 x86(Intel/AMD) 칩은 외부로는 CISC를 유지하고 내부적으로는 RISC 형태의 마이크로-옵(Micro-op)으로 변환하여 실행하는 하이브리드 진화를 통해 데스크탑/서버 시장을 지배하고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: CISC(Complex Instruction Set Computer)는 하나의 명령어가 길고 복잡한 작업을 한 번에 처리할 수 있도록 설계된 컴퓨터 아키텍처다. 가변 길이 명령어 포맷과 다양한 주소 지정 방식을 제공하여 소프트웨어 개발의 편의성을 극대화한 구조다.
필요성: CISC는 메모리 자원이 천문학적으로 비쌌던 컴퓨팅 초기에 '코드 밀도(Code Density)'를 극대화하여 제한된 저장 공간 내에 방대한 소프트웨어를 탑재하기 위해 반드시 필요했다. 복잡한 연산(예: 메모리 간 직접 덧셈)을 단 한 줄의 명령어로 압축함으로써 메모리 참조 횟수를 줄이고 프로그램 크기를 최소화할 수 있었기 때문이다. 또한, 어셈블리어로 직접 코딩하던 시절 프로그래머의 생산성을 높여주는 인간 친화적 명령어 셋을 제공했으며, 현대에는 지난 40년간 축적된 방대한 x86 소프트웨어 생태계와의 **'완벽한 하위 호환성'**을 유지하며 데스크탑과 서버 시장의 패권을 사수하는 실질적인 아키텍처 거버넌스의 수단으로 작동한다.
💡 비유: CISC는 '풀옵션 맞춤형 주문'과 같다. "햄버거에 양파 빼고, 소스 두 번 넣고, 패티는 세 장으로 구워서 세트 메뉴로 포장해 줘." 이 한 문장(명령어 1개)으로 주방장(CPU)에게 엄청나게 복잡한 일을 지시한다. 주문은 아주 짧지만, 요리사가 알아듣고(디코딩) 요리하는 데(실행)는 시간이 꽤 걸린다. 주방장의 머리는 아프지만 주문자(프로그래머)는 아주 편한 방식이다.
등장 배경: 1970년대에는 메모리가 천문학적으로 비쌌고, C언어 같은 고급 언어가 막 걸음마를 떼던 시절이라 프로그래머들이 기계어(어셈블리)를 직접 손으로 짰다. 그래서 하드웨어 설계자들은 "개발자들이 코딩하기 편하게, 그리고 메모리를 덜 먹게 칩 안에 아주 복잡하고 강력한 명령어를 잔뜩 넣어주자!"고 생각했다. 메모리 간 복사, 문자열 비교 등 수십 줄의 코드를 단 한 줄로 줄여주는 CISC의 낭만 시대가 이렇게 열렸다.

"메모리에서 메모리로 바로 더해라"라는 CISC 특유의 무지막지한 융합 명령어를 시각화하면 다음과 같다.

  ┌─────────────────────────────────────────────────────────────────────────────┐
  │         CISC의 궁극기: 메모리-투-메모리(Memory-to-Memory) 연산              │
  ├─────────────────────────────────────────────────────────────────────────────┤
  │                                                                             │
  │   [ 명령어 1줄 ] : ADD [2000번지], [1000번지]                               │
  │                                                                             │
  │   [ CPU 내부의 눈물겨운 마이크로코드(Microcode) 실행 ]                      │
  │    (틱!) 1. 메모리 1000번지로 가서 값을 읽어온다. (버스를 탐)               │
  │    (틱!) 2. 메모리 2000번지로 가서 값을 읽어온다. (버스를 또 탐)            │
  │    (틱!) 3. ALU를 깨워서 두 값을 더한다.                                    │
  │    (틱!) 4. 더한 결과를 들고 다시 2000번지로 가서 저장한다.                 │
  │                                                                             │
  │ * 원리: 프로그래머는 1줄만 썼지만, CPU는 안에서 땀을 뻘뻘 흘리며 4번 일한다.│
  │   ──▶ "하드웨어가 소프트웨어의 고통을 짊어진 설계 철학"                     │
  └─────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] RISC라면 LOAD 두 번, ADD 한 번, STORE 한 번으로 나누어 써야 할 코드를 CISC는 단 하나의 명령어로 압축한다. 이를 위해 CISC 칩 내부에는 이 복잡한 동작을 여러 단계로 쪼개서 지휘하는 마이크로프로그램(Microprogram) ROM이 숨어 있다. 코드는 극단적으로 짧아졌지만, 이 명령어 하나가 끝날 때까지 파이프라인의 다른 명령어들은 모두 숨죽이고 기다려야 하는 막대한 지연(Latency)이 발생한다.

📢 섹션 요약 비유: CISC 명령어는 '이삿짐센터 포장 이사'와 같습니다. 나는 "이 집 물건 저 집으로 옮겨줘(명령어 1줄)"라고 말만 하면 끝납니다. 내가 직접 박스를 사고(Load), 포장하고(Add), 푸는(Store) 수고를 덜지만, 이삿짐 아저씨(CPU 내부)는 그 한마디를 듣고 며칠 동안 엄청난 육체노동을 해야 합니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

CISC의 3대 설계 원칙 (The Golden Rules of CISC)

CISC는 하드웨어 엔지니어가 소프트웨어 엔지니어에게 바친 가장 복잡한 러브레터다.

핵심 원칙	아키텍처적 구현	달성 목적 (Why)	비유
Variable Instruction Length	명령어의 길이가 1바이트부터 15바이트까지 고무줄처럼 변함	공간 낭비 없는 극한의 메모리 압축률(Code Density) 달성	몸집에 딱 맞는 맞춤옷
Complex Addressing Modes	메모리 주소를 가리키는 방식이 수십 가지에 달함 (`[Base+Index*Scale]`)	고수준 언어의 배열과 포인터를 하드웨어가 직접 지원	자체 내장 내비게이션
Micro-programmed Control	CPU 안에 작은 프로그램(ROM)을 두어 명령어를 해석함	칩 설계를 바꾸지 않고도 새로운 복합 명령어 추가가 쉬움	통역사 고용

심층 동작 원리: "마이크로-옵(Micro-op) 변환의 마술"

초창기 CISC는 정말로 내부에서 복잡하게 돌았다. 하지만 클럭 스피드 경쟁이 불붙은 1990년대, 파이프라인의 병목을 견디지 못한 인텔은 **"외유내강(겉은 CISC, 속은 RISC)"**이라는 천재적인 변종 아키텍처를 융합해 낸다.

  ┌───────────────────────────────────────────────────────────────────────────┐
  │         현대 x86 (CISC) 프로세서의 이중생활: Micro-op 변환                │
  ├───────────────────────────────────────────────────────────────────────────┤
  │                                                                           │
  │   [ 외부 (소프트웨어가 보는 CISC 명령어) ]                                │
  │      `ADD [EAX], EBX`  (가변 길이 2-주소 복합 명령어)                     │
  │              │                                                            │
  │   [ 경계 (Hardware Decoder) ] ◀── 여기서 명령어를 잘게 찢는다!            │
  │              │                                                            │
  │   [ 내부 (파이프라인이 실행하는 RISC 형태의 Micro-ops) ]                  │
  │      1. μ-Load  t1, [EAX]    (레지스터 t1으로 메모리 읽어오기)            │
  │      2. μ-Add   t2, t1, EBX  (순수한 3-주소 레지스터 덧셈)                │
  │      3. μ-Store [EAX], t2    (결과를 다시 메모리에 쓰기)                  │
  │                                                                           │
  │ * 혁명: 호환성(CISC)을 유지하면서 성능(RISC 파이프라인)까지 잡아버렸다!   │
  └───────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이것이 인텔과 AMD가 50년 넘게 살아남은 비결이다. 외부에서 들어오는 x86 명령어는 아주 더럽고 복잡한 가변 길이의 CISC다. 하지만 CPU 가장 앞단의 '디코더(Decoder)'가 이 끔찍한 덩어리를 집어삼킨 뒤, 파이프라인이 씹어 삼키기 좋은 아주 작고 균일한 RISC 형태의 조각들, 즉 **마이크로-옵(Micro-ops)**으로 썰어버린다. 이렇게 썰린 조각들은 내부의 슈퍼스칼라(Superscalar) 엔진을 타고 빛의 속도로 병렬 처리된다. 오늘날의 CISC는 사실상 'RISC 에뮬레이터를 품은 괴물'이다.

📢 섹션 요약 비유: 마이크로-옵 변환은 '통돼지 바비큐 썰기'와 같습니다. 손님(소프트웨어)이 통돼지 한 마리(CISC 명령어)를 통째로 주문하면, 식당 안에서는 주방장(디코더)이 그걸 한입 크기의 큐브 스테이크(Micro-op)로 잘게 썰어서 요리사들(파이프라인)에게 나눠줍니다. 덕분에 요리사들은 통돼지를 들고 쩔쩔맬 필요 없이 아주 빠르고 편하게 고기를 구울 수 있습니다.

Ⅲ. 융합 비교 및 다각도 분석

심층 기술 비교: CISC의 디코더 vs RISC의 디코더

명령어 길이가 고무줄(가변)이냐 나무젓가락(고정)이냐가 낳은 실리콘 면적의 차이다.

비교 항목	CISC (가변 길이 명령어)	RISC (고정 길이 명령어)	아키텍처 판단 포인트
명령어 분리 작업	어디서 끝나는지 바이트마다 검사해야 함	4바이트 단위로 기계적으로 썰면 끝	디코더(Decoder)의 로직 복잡도
디코더가 차지하는 면적	칩 면적의 약 20~30%를 차지함	칩 면적의 5% 미만	남는 트랜지스터를 캐시에 투자할 여력
병렬 디코딩 난이도	최상 (앞 명령어 길이를 모르면 뒤를 못 봄)	최하 (그냥 4바이트씩 4개 가져오면 됨)	Fetch 병목 (Instruction Byte Queue)
코드 밀도 (용량)	가장 작다 (메모리와 디스크 아낌)	뚱뚱하다 (캐시 메모리 낭비 발생)	L1 I-Cache(명령어 캐시) 효율성

과목 융합 관점

컴파일러 (Legacy Optimization): 현대의 영리한 컴파일러 제작자(GCC, LLVM)들은 사실 CISC 칩을 향해 코드를 짤 때 CISC의 복잡한 명령어를 잘 안 쓴다. 문자열 복사 전용 명령어인 REP MOVSB 같은 것을 쓰는 것보다, 그냥 단순한 RISC 스타일의 기본 명령어(LOAD, ADD)를 루프로 돌리는 것이 칩 내부의 마이크로-옵 스케줄러를 타면서 훨씬 더 빨리 실행된다는 사실을 깨달았기 때문이다. CISC의 복잡한 명령어들은 점차 '하위 호환성을 위해 남겨진 박물관의 화석'이 되어가고 있다.
운영체제 (Backward Compatibility): CISC의 생명줄은 **'호환성'**이다. 1980년대 짜여진 16비트 MS-DOS 시절의 프로그램(어셈블리)이 2026년의 최신 64비트 인텔 코어 i9에서도 완벽하게 돌아간다. OS는 이 미친 짓을 지원하기 위해 칩 내부에 리얼 모드, 보호 모드, 롱 모드 등 수많은 상태 레지스터의 벽을 쳐가며 CISC의 유산을 떠안고 있다.

  ┌───────────────────────────────────────────────────────────────────────────┐
  │         아키텍처의 역설: "강력한 명령어가 파이프라인을 부순다"            │
  ├───────────────────────────────────────────────────────────────────────────┤
  │                                                                           │
  │   [ CISC의 비극 ] : CALL_AND_SAVE_ALL_REGS (가상의 명령어)                │
  │     - 이 명령어 하나가 실행되는 데 무려 '50 Cycle'이 걸린다!              │
  │     - 이 녀석이 파이프라인을 꽉 막고 있는 50 Cycle 동안, 뒤에 따라오던    │
  │       수많은 명령어들은 꼼짝도 못 하고 컨베이어 벨트 위에 서 있어야 한다. │
  │                                                                           │
  │ * 결론: 파이프라인 시대에는 뚱뚱하고 복잡한 명령어가 칩 전체의 독이 된다. │
  └───────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "하나의 명령어로 많은 일을 하자"는 CISC의 철학은, 역설적이게도 명령어 파이프라이닝(Pipelining) 기술이 발전하면서 가장 큰 장애물이 되었다. 파이프라인의 핵심은 '모든 공정이 일정한 시간(1 Cycle) 안에 끝나야 한다'는 것이다. 그런데 CISC 명령어는 어떤 놈은 1 Cycle, 어떤 놈은 100 Cycle이 걸린다. 100 Cycle짜리 돌연변이가 들어오는 순간 전체 공장이 멈춰 선다(Stall). 결국 CISC는 내부 디코더를 갈아엎어 이 돌연변이들을 1 Cycle짜리 RISC 조각(Micro-op)으로 쪼개는 성형수술을 거쳐야만 했다.

📢 섹션 요약 비유: 파이프라인에서 CISC의 지연은 '고속도로 톨게이트의 진상 손님'과 같습니다. 다들 하이패스(1 Cycle)로 쌩쌩 지나가는데, 어떤 차가 갑자기 멈춰 서서 수표를 내고 동전으로 거슬러 달라고 5분 동안 실랑이(복잡한 명령어)를 벌이면, 그 뒤에 있는 수백 대의 차들(명령어들)이 전부 멈춰 서서 도로가 마비되는 끔찍한 상황입니다.

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

실무 시나리오

시나리오 — 레거시 은행 시스템의 하드웨어 마이그레이션: 상황: 30년 전 IBM 메인프레임(CISC)용 어셈블리로 짜여진 뱅킹 코어가 있는데, 소스코드가 유실되어 바이너리만 남음. 판단: "CISC 아키텍처의 에뮬레이션(Emulation) 한계"다. 이 바이너리를 최신 ARM(RISC) 클라우드 서버에서 돌리려 에뮬레이터를 썼지만, CISC 특유의 기괴한 메모리 직접 연산과 플래그 갱신 부작용을 소프트웨어로 완벽히 흉내 내느라 성능이 1/100로 토막 남. 결국 비싸더라도 철저한 하위 호환성을 보장하는 최신 x86(CISC) 서버를 사서 네이티브로 돌려버리는 것이 가장 싸고 안전한 기술적 결단이 된다.
시나리오 — 고성능 게임 엔진의 캐시 적중률(Cache Hit) 최적화: 상황: 수백만 개의 몬스터 객체를 처리하는 로직에서 메모리 대역폭 한계로 프레임이 떨어짐. 판단: "CISC 가변 길이 명령어의 장점 극대화"다. CISC(x86)는 RISC에 비해 코드가 압축되어 있다. 특히 자주 쓰이는 명령어는 1~2바이트로 매우 짧다. 개발자는 컴파일러의 -Os (크기 최적화) 플래그를 미세 조정하여, 아주 좁은 L1 명령어 캐시 안에 루프 로직이 100% 들어맞게 욱여넣는다. 코드가 작기 때문에 램(RAM)에서 가져올 일 자체가 사라져 지연 시간(Latency)을 이겨내는 CISC만의 최적화다.

  ┌──────────────────────────────────────────────────────────────────────────────┐
  │         마이크로아키텍처 합성: CISC 디코더(Decoder) 설계 딜레마              │
  ├──────────────────────────────────────────────────────────────────────────────┤
  │                                                                              │
  │   [ 매 클럭마다 여러 개의 CISC 명령어를 동시에 파싱해야 한다면? ]            │
  │                │                                                             │
  │                ▼                                                             │
  │    명령어 1이 3바이트인지 5바이트인지 어떻게 알지?                           │
  │          ├─ [치명타] 첫 번째 명령어를 다 해석해야만 두 번째 시작점을 앎!     │
  │          └─ 직렬화된 해독 과정 때문에 디코더 병목이 터진다!                  │
  │                │                                                             │
  │                ▼                                                             │
  │    인텔/AMD의 무식한 해결책 (Brute-force)                                    │
  │          ├─ [융합 기술] "그냥 바이트마다 모두 명령어의 시작점이라고 가정해!" │
  │          └─ 병렬로 무식하게 다 해독해 본 뒤, 진짜 길이를 찾으면 나머진 버림. │
  │                                                                              │
  │  최종 조치: 칩 면적과 전력을 갈아 넣어 RISC의 속도를 돈으로 사버렸다!        │
  └──────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] x86 아키텍처가 전력을 무지막지하게 퍼먹는 가장 큰 이유다. ARM(RISC)은 모든 명령어가 4바이트이므로, 4, 8, 12 위치에서 잘라서 3개의 디코더에 동시에 던져주면 끝난다. 하지만 x86은 길이가 제멋대로다. 앞놈을 뜯어보기 전엔 뒷놈이 어디서 시작하는지 알 수가 없다. 이 직렬적 한계를 깨기 위해, x86 칩은 엄청난 수의 잉여 디코더 회로를 때려 박아 모든 경우의 수를 동시에 스캔하는 무식하고도 위대한 물리적 투자를 단행했다. 이로 인해 PC 시장에서는 승리했지만, 배터리가 생명인 모바일 시장에서는 철저히 버림받게 된다.

도입 체크리스트

Micro-op Cache (L0 Cache): 그토록 힘들게 번역해 낸 마이크로-옵 조각들이 루프(Loop)를 돌 때 또 디코더를 거치는 것은 낭비다. 디코더 바로 뒤에 마이크로-옵 전용 캐시(Trace Cache)를 융합하여, 디코더의 전원 자체를 꺼버리고 전력을 아끼는 구조가 탑재되었는가?
Macro-op Fusion: 오히려 너무 잘게 쪼개진 명령어들(예: 비교 CMP와 분기 JE)을 파이프라인에 넣기 전에 하나로 합쳐버려(Fusion) 전체 실행 효율을 높이는 양방향 최적화 회로가 있는가?

안티패턴

복잡한 융합 명령어(예: x86의 ENTER, LEAVE)의 맹신: 함수 프레임을 만들고 지우는 고수준의 행위를 단 1바이트 명령어로 만들어둔 과거의 유산. 하지만 칩 내부적으로는 엄청나게 긴 마이크로코드로 풀리며 속도가 바닥을 긴다. 컴파일러가 이런 구형 복합 명령어를 무시하고, PUSH, SUB ESP 같은 단순한 명령어 조합으로 코드를 생성하도록 강제하지 않는 것은 치명적인 벤치마크 점수 하락(안티패턴)이다.
📢 섹션 요약 비유: 복합 명령어의 맹신은 '전자레인지 자동 버튼의 배신'과 같습니다. "피자 데우기"라는 자동 버튼(복합 명령어)을 누르면 편할 줄 알았는데, 안에서 윙윙대며 5분 동안 쓸데없는 해동 모드까지 돌아가서 피자가 질겨집니다. 차라리 수동으로 "30초만 데워(단순 명령어)"라고 명확히 지시하는 게 가장 빠르고 맛있습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	초창기 컴퓨터 환경	CISC 아키텍처 융합 효과	개선 효과
정량	프로그램 코드가 길어 메모리 초과	다양한 주소 모드로 코드 극한 압축	프로그램 용량 최소화 (Code Density 극대화)
정량	컴파일러가 모든 주소 계산 로직 생성	하드웨어 디코더가 복잡도 대신 처리	컴파일러 설계 비용 대폭 감소 (과거 기준)
정성	프로그래머의 저수준 코딩 고통	고수준 언어(C/Pascal)에 맞춘 명령어 제공	소프트웨어 개발 생산성의 초기 폭발적 증대

미래 전망

CISC와 RISC의 경계 소멸 (x86의 하이브리드화): 밖에서는 호환성을 위해 CISC의 옷(가변 길이 명령어)을 입고, 안에서는 속도를 위해 RISC의 근육(Micro-ops, Superscalar, Out-of-Order)으로 달리는 이 현대적 융합(Post-RISC) 현상은 앞으로도 영원히 계속될 것이다.
레거시 디코더의 하드웨어 분리: 무거운 x86 디코더를 메인 코어에서 덜어내고, 별도의 특수 칩렛(Chiplet)이나 가상화 계층(Binary Translation)으로 넘겨, 실리콘의 핵심은 순수 RISC로만 돌리는 혁신적인 다이(Die) 분리 아키텍처가 제안되고 있다.

참고 표준

x86 (IA-32) 및 AMD64 (x86-64): 지구상에 살아남은 유일하고도 가장 압도적인 CISC의 결정체. 수천 개의 명령어가 얽혀 있는 거대한 제국.
VAX-11: 1970년대를 지배한 진정한 CISC의 끝판왕. "하드웨어로 C언어 컴파일러를 만들겠다"는 광기의 산물이었으나 결국 성능의 한계로 멸망했다.

"소프트웨어의 무능함"을 감싸 안기 위해 "하드웨어의 복잡함"을 짊어진, 가장 인간적이고 끈질긴 아키텍처 'CISC'의 진화 로드맵은 다음과 같다.

  ┌──────────────────────────────────────────────────────────────────────────────────────────────┐
  │         타협과 생존: CISC 아키텍처 진화 로드맵                                               │
  ├──────────────────────────────────────────────────────────────────────────────────────────────┤
  │                                                                                              │
  │   [1단계: 친절한 하드웨어]    [2단계: 파이프라인의 저주]   [3단계: 외유내강의 마이크로 융합] │
  │                                                                                              │
  │   메모리 좁은데 압축 좀 하자 ──▶ 클럭이 안 올라가네? 멸망 위기 ──▶ 겉은 CISC, 속은 RISC 변신 │
  │  (가변 길이와 복잡한 명령어)  (명령어 길이가 달라서 막혔다)  (Micro-ops 변환으로 부활)       │
  │ "내가 다 해줄게 짧게 말해"   "네가 너무 뚱뚱해서 줄이 막혀"  "쪼개서 넣으니까 엄청 빠르지!"  │
  └──────────────────────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] CISC는 죽다 살아난 이단아다. 1단계: 초창기엔 컴파일러가 멍청하고 메모리가 귀해서, 똑똑한 하드웨어가 복잡한 명령어를 처리해 주는 CISC가 정답이었다. 2단계: 하지만 90년대 들어 RISC 진영이 파이프라인과 고정 길이 명령어를 무기로 "클럭 스피드"를 미친 듯이 올리자, CISC는 뚱뚱한 명령어 때문에 멸망의 위기에 처했다. 3단계: 여기서 인텔은 천재적인 꼼수를 냈다. 수십 년 치의 '소프트웨어 호환성(Windows)'을 무기로 겉모습(ISA)은 CISC를 유지하되, 칩 내부에 RISC 통역기(디코더)를 융합하여 속을 완전히 뜯어고친 것이다. 이로써 CISC는 가장 비효율적인 명령어 구조를 가지고도 지구상에서 가장 빠른 CPU로 군림하는 기적을 이어가고 있다.

📢 섹션 요약 비유: 현대 CISC의 생존 방식은 '오래된 외관의 최첨단 개조 차량(리스토어)'과 같습니다. 겉모습(ISA 명령어)은 40년 전 낡고 뚱뚱한 각그랜저 그대로라서 옛날 부품(소프트웨어)이 다 맞지만, 뚜껑을 열어보면 엔진(마이크로아키텍처)은 페라리의 최첨단 V8 엔진(RISC의 Micro-ops)으로 개조되어 있어 고속도로에서 스포츠카(ARM)를 가볍게 추월하는 괴물 같은 차량입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Variable Instruction Length	CISC의 핵심 특징. 명령어가 1~15바이트로 제멋대로라 코드는 짧아지지만 파이프라인 디코더는 피눈물을 흘린다.
Micro-operation (μ-op)	CISC가 파이프라인의 저주를 풀기 위해 찾아낸 해독제. 뚱뚱한 명령어를 잘게 쪼갠 RISC 형태의 내부 부품.
Backward Compatibility	CISC(x86)가 무겁고 복잡함에도 불구하고 세상의 패권을 쥐고 있는 유일한 이유. "옛날 게임이 돌아가야 하니까."
Code Density (코드 밀도)	RISC를 압도하는 CISC의 유일한 무기. 명령어 크기가 작아 메모리를 덜 먹고 L1 캐시 적중률이 극도로 높다.
Complex Addressing Mode	`[EAX + EBX*4 + 100]` 처럼 배열의 인덱스를 하드웨어 가산기가 한 방에 계산해 내는 CISC만의 폭력적인 주소 편의성.

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

CISC는 맥가이버칼처럼 **'아주 복잡하고 다양한 도구가 하나로 뭉쳐있는 만능 장비'**예요!
"나무를 잘라서 다듬고 못을 박아라!"라는 복잡한 주문을 한 번에 알아듣고 처리할 수 있지만, 도구가 무거워서 움직임이 조금 둔해요.
하지만 지금의 똑똑한 CISC(인텔 컴퓨터)는 겉으로는 무거운 척하면서 속으로는 날쌘 닌자(RISC)로 변신해서 아주 빨리 계산하는 꼼수를 부린답니다!