인터럽트 벡터 및 벡터 테이블 (Interrupt Vector & Vector Table)

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

본질: 인터럽트 벡터 (Interrupt Vector)는 특정 인터럽트 신호가 발생했을 때 처리해야 할 ISR (Interrupt Service Routine)의 시작 메모리 주소를 가리키는 고유 식별자이자 포인터이며, 이들을 모아놓은 배열 구조를 인터럽트 벡터 테이블 (IVT, Interrupt Vector Table)이라 한다.

가치: 수많은 하드웨어 및 소프트웨어 인터럽트 요인을 개별적인 분기문(If-Else) 없이 하드웨어가 직접 메모리 주소로 변환하게 함으로써, 사건 발생부터 처리 시작까지의 지연 시간 (Latency)을 최소화하는 고속 인덱싱 기능을 제공한다.

융합: 현대 x86 아키텍처의 IDT (Interrupt Descriptor Table)나 ARM의 Vector Table은 단순 주소를 넘어 권한 체크 (DPL), 게이트 유형 (Interrupt/Trap Gate) 정보를 포함하는 서술자 (Descriptor) 구조로 진화하여 시스템 보안의 핵심 관문 역할을 수행한다.

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

개념: 인터럽트 벡터 (Interrupt Vector)는 인터럽트의 종류를 구분하는 정수값(번호)이자, 해당 인터럽트를 처리할 함수의 메모리 시작 주소를 의미한다. 운영체제는 부팅 과정에서 메모리의 특정 영역에 각 번호별 ISR 주소를 미리 기록해두는데, 이 공간을 인터럽트 벡터 테이블 (IVT, Interrupt Vector Table) 또는 인터럽트 서술자 테이블 (IDT, Interrupt Descriptor Table)이라고 부른다.
필요성: CPU가 인터럽트 신호를 받았을 때, "무엇이 발생했는가"를 아는 것만으로는 부족하다. "어떻게 처리할 것인가(어떤 코드를 실행할 것인가)"로 즉각 연결되어야 한다. 만약 벡터 테이블이 없다면 CPU는 발생할 때마다 운영체제에게 일일이 물어보거나 모든 장치를 전수 조사해야 하므로 응답 속도가 치명적으로 느려진다. 벡터 테이블은 하드웨어가 신호를 받자마자 정해진 주소로 즉시 점프할 수 있게 하는 '고속 자동 응답기'와 같다.
💡 비유: 인터럽트 벡터 테이블은 아파트 입구의 "우편함"과 같다. 각 호수(인터럽트 번호)마다 정해진 우편함(테이블 엔트리)이 있고, 그 안에는 해당 가구로 가는 지도(ISR 주소)가 들어 있어, 배달원(CPU)이 고민 없이 바로 목적지로 찾아갈 수 있게 돕는다.
등장 배경 및 구조적 발전: 초기 시스템에서는 인터럽트 신호가 오면 무조건 고정된 하나의 주소로만 점프했다 (단일 벡터). 거기서 소프트웨어가 다시 장치 상태를 읽어 어떤 장치인지 판별해야 했다. 장치가 늘어나면서 이 판별 시간이 길어지자, 하드웨어가 직접 인터럽트 번호를 송출하고 CPU가 이를 인덱스로 사용하여 테이블에서 주소를 바로 찾아가는 '벡터형 인터럽트' 방식이 표준이 되었다.

인터럽트 신호가 벡터 번호를 통해 실제 메모리 주소로 변환되는 매핑 과정을 시각화하면 다음과 같다.

  ┌─────────────────────────────────────────────────────────────────┐
  │            인터럽트 벡터 매핑 메커니즘 (Mapping)                │
  ├─────────────────────────────────────────────────────────────────┤
  │                                                                 │
  │ [외부 장치] ──▶ [인터럽트 신호 + 벡터 번호(N)] ──▶ [CPU]        │
  │                                                    │            │
  │   CPU 내부 동작:                                    │           │
  │    1. 현재 PC 저장                                  │           │
  │    2. 점프 주소 계산 = [IVT 시작 주소] + (N * 엔트리 크기)      │
  │    3. 해당 주소에서 실제 ISR 주소 읽기                ▼         │
  │                                                                 │
  │ [메모리 상의 인터럽트 벡터 테이블 (IVT)]                        │
  │ ┌───────┬───────────────────────────┐      ┌──────────────┐     │
  │ │ Index │      ISR 주소 (Pointer)   │      │ 실제 ISR 코드  │   │
  │ ├───────┼───────────────────────────┤      ├──────────────┤     │
  │ │   0   │ 0x1000 (Divide by Zero) ──┼─────▶│ [ISR 0]      │     │
  │ ├───────┼───────────────────────────┤      ├──────────────┤     │
  │ │  ...  │           ...             │      │ ...          │     │
  │ ├───────┼───────────────────────────┤      ├──────────────┤     │
  │ │   N   │ 0x5000 (Keyboard IRQ)   ──┼─────▶│ [ISR N]      │     │
  │ └───────┴───────────────────────────┘      └──────────────┘     │
  └─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 도식은 인터럽트 벡터가 어떻게 '간접 참조'를 통해 유연성을 확보하는지 보여준다. 하드웨어 장치(또는 트랩 명령)가 'N'이라는 번호를 던지면, CPU는 메모리에 위치한 테이블의 N번째 칸을 들여다본다. 그 칸에 적힌 '0x5000'이라는 값이 바로 우리가 실행해야 할 함수의 실제 위치다. 만약 운영체제가 ISR의 위치를 바꾸고 싶다면, 테이블의 값만 갱신하면 된다. 하드웨어 설계를 바꿀 필요 없이 소프트웨어적으로 처리 로직을 완전히 교체할 수 있다는 것이 벡터 테이블의 가장 큰 아키텍처적 이점이다.

📢 섹션 요약 비유: 인터럽트 벡터는 복잡한 질문에 대해 미리 답안지 번호를 매겨놓은 "색인표"와 같아서, 질문이 들어오는 순간 고민 없이 정답이 적힌 페이지로 바로 넘길 수 있게 해줍니다.

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

인터럽트 벡터 테이블 구성 요소 및 예약 영역:

| 벡터 범위 | 용도 | 주요 예시 | 비유 | |:---|:---|:---|:---|:---| | 0 ~ 19 | CPU 예약 예외 | 0: Div by Zero, 14: Page Fault | 긴급 제동 장치 | | 20 ~ 31 | 미래 예약 영역 | Intel/ARM 사의 향후 확장용 | 여분 차선 | | 32 ~ 255 | 사용자 정의 인터럽트 | 32~47: 하드웨어 IRQ, 128(0x80): 시스템 콜 | 개별 매장 입구 |

IDT (Interrupt Descriptor Table) 엔트리 구조 (x86 기준): 현대적인 시스템의 벡터 테이블은 단순한 '주소' 이상의 정보를 담고 있다. 보안을 위해 호출자의 권한을 체크하고, 어떤 스택을 사용할지 결정하는 복합적인 '서술자 (Descriptor)' 구조를 갖는다.

  ┌─────────────────────────────────────────────────────────────────┐
  │           인터럽트 게이트 서술자 (Gate Descriptor)              │
  ├─────────────────────────────────────────────────────────────────┤
  │                                                                 │
  │ 63            48 47 46 45 44    40 39         32                │
  │ ┌──────────────┬─┬───┬─┬───────┬──────────────┐                 │
  │ │ Offset 31:16 │P│DPL│0│ Type  │ Reserved     │ (상위 32비트)   │
  │ └──────────────┴─┴───┴─┴───────┴──────────────┘                 │
  │ 31            16 15           0                                 │
  │ ┌──────────────┬──────────────┐                                 │
  │ │ Segment Sel  │ Offset 15:0  │               (하위 32비트)     │
  │ └──────────────┴──────────────┘                                 │
  │                                                                 │
  │ * P (Present): 유효한 엔트리인가?                               │
  │ * DPL (Descriptor Privilege Level): 접근 가능한 최소 권한       │
  │ * Offset: 실제 ISR 함수 주소 (분할 저장됨)                      │
  └─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 단순히 32비트나 64비트 주소 하나만 적어놓지 않는 이유는 '보안' 때문이다. 만약 사용자 프로세스가 트랩을 통해 커널로 들어오려 할 때, DPL 필드를 검사하여 호출자의 권한이 적절한지 하드웨어가 먼저 판단한다. 권한이 낮은 프로세스가 치명적인 예외 핸들러를 강제로 호출하는 것을 막는 방어선이다. 또한 Type 필드를 통해 이것이 '인터럽트 게이트'인지 '트랩 게이트'인지 구분한다. 인터럽트 게이트를 통과하면 CPU는 자동으로 다른 인터럽트가 들어오지 못하게 플래그를 끄지만, 트랩 게이트는 이를 유지한다. 벡터 테이블의 엔트리 하나가 단순한 포인터를 넘어 '보안 검문소' 역할을 수행하는 셈이다.

심층 동작 메커니즘 (IDTR 레지스터): 메모리 어딘가에 흩어져 있는 벡터 테이블을 CPU가 찾기 위해서는 그 기준 주소를 알고 있어야 한다. 이를 위해 IDTR (Interrupt Descriptor Table Register)이라는 특수 레지스터가 존재하며, 운영체제는 부팅 시 LIDT (Load IDT) 명령을 통해 테이블의 위치와 크기를 CPU에 각인시킨다.

  ┌──────────────────────────────────────────────────────────────────┐
  │              IDTR 레지스터와 메모리 참조 관계                    │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  [CPU 내부 IDTR]                                                 │
  │  ┌──────────────────────┬────────────────────┐                   │
  │  │ Base Address (64bit) │ Limit (16bit)      │                   │
  │  └──────────┬───────────┴────────────────────┘                   │
  │             │                                                    │
  │             ▼ [메모리 시작점]                                    │
  │             ┌──────────────────────┐                             │
  │             │ Vector 0 Descriptor  │                             │
  │             ├──────────────────────┤                             │
  │             │ Vector 1 Descriptor  │                             │
  │             ├──────────────────────┤  ◀── CPU는 하드웨어적으로   │
  │             │        ...           │      이 위치를 계속 주시    │
  │             └──────────────────────┘                             │
  │                                                                  │
  │ * 보안: IDTR 값은 커널 모드에서만 수정 가능 (Privileged Inst)    │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] CPU는 인터럽트 번호 'N'이 들어오면, 내부 IDTR 레지스터의 Base Address에 N * 엔트리 크기를 더해 메모리 위치를 즉시 계산해낸다. 이 과정은 하드웨어 유닛이 직접 수행하므로 소프트웨어의 개입이 전혀 없으며, 매우 빠른 속도로 처리된다. Limit 필드는 테이블의 경계를 정의하여, 잘못된 번호가 들어왔을 때 메모리 밖을 참조하지 않도록 보호한다. 실무적으로 커널 패닉 (Kernel Panic) 상황 중 'IDT 리밋 위반'은 운영체제가 이 하이브리드 포인터 구조를 제대로 설정하지 못했을 때 발생하는 아주 기초적이면서도 치명적인 오류다.

📢 섹션 요약 비유: IDTR 레지스터는 "전국 도서관 목록"을 들고 있는 관리자와 같고, 벡터 테이블은 그 도서관 안의 "도서 분류 번호"와 같아서 어떤 책(ISR)이든 번호만 알면 1초 만에 찾아낼 수 있게 합니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

IVT (Real Mode) vs IDT (Protected Mode) 비교:

비교 항목	IVT (Interrupt Vector Table)	IDT (Interrupt Descriptor Table)
CPU 모드	리얼 모드 (초기 16비트 환경)	보호 모드 / 롱 모드 (현대 32/64비트)
위치	메모리 0번지 (고정)	메모리 어디나 가능 (IDTR로 지정)
엔트리 크기	4바이트 (단순 CS:IP 주소)	8바이트 (32비트) / 16바이트 (64비트)
보안 기능	없음 (누구나 수정 가능)	강력 (DPL, Gate Type 등 포함)
오버헤드	극히 낮음	권한 체크 등으로 인한 약간의 발생

벡터 테이블은 시스템의 가상화 (Virtualization) 단계에서 더욱 복잡해진다. 하이퍼바이저 (Hypervisor)는 게스트 OS가 하드웨어 벡터 테이블을 직접 건드리지 못하게 하고, 중간에서 가상 벡터 테이블을 통해 신호를 중계한다.

  ┌──────────────────────────────────────────────────────────────────┐
  │            가상화 환경에서의 인터럽트 벡터 중계                  │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │ [하드웨어] ──▶ [Host IDT] ──▶ [Hypervisor]                       │
  │                                     │                            │
  │                                     ▼ [Injection]                │
  │                          ┌─────────────────────────┐             │
  │                          │    Guest OS (VM)        │             │
  │                          │  [Guest IDT] ──▶ [ISR]  │             │
  │                          └─────────────────────────┘             │
  │                                                                  │
  │ * 이슈: 가상화 오버헤드의 주범은 '인터럽트 엑싯(Exit)'           │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 가상 머신 안에서 돌아가는 윈도우나 리눅스는 자신들이 진짜 하드웨어의 벡터 테이블을 관리한다고 착각한다. 하지만 실제로는 하이퍼바이저가 관리하는 '그림자 테이블 (Shadow Table)'을 보고 있는 것이다. 인터럽트가 발생하면 하드웨어는 일단 하이퍼바이저의 벡터 테이블로 제어권을 넘기고, 하이퍼바이저는 어느 VM(Virtual Machine)으로 보낼지 결정한 뒤 해당 VM의 가상 인터럽트 컨트롤러에 신호를 주입(Injection)한다. 이 이중 매핑 구조 때문에 가상화 환경에서의 인터럽트 레이턴시는 네이티브 대비 클 수밖에 없으며, 이를 줄이기 위해 Intel VT-x 같은 하드웨어 가속 기술이 벡터 테이블 처리를 직접 돕기도 한다.

📢 섹션 요약 비유: 가상화 환경의 벡터 테이블은 "중간 대행사"를 거치는 서류 전달과 같아서, 보안과 격리는 확실하지만 직접 전달하는 것보다 단계가 더 많은 것과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오 및 운영 전략:
1. 인터럽트 벡터 가로채기 (Hooking): 보안 솔루션이나 루트킷 (Rootkit)은 특정 벡터 번호의 주소를 자신의 함수 주소로 몰래 바꿔치기한다. 시스템 콜 번호 (0x80)를 후킹하면 모든 파일 열기나 네트워크 전송을 감시할 수 있다. 이를 방지하기 위해 현대 OS는 IDT 영역을 '읽기 전용'으로 보호한다.
2. 벡터 부족 문제 (Vector Exhaustion): MSI-X 방식을 사용하는 고성능 서버 장치가 수천 개 늘어나면 256개뿐인 벡터 번호가 부족해진다. 실무적으로는 여러 장치가 하나의 벡터를 공유하게 하거나, 멀티 CPU 시스템에서 코어별로 벡터 공간을 분리하여 할당하는 고도의 자원 관리가 필요하다.
3. IDT 손상과 트리플 폴트 (Triple Fault): 예외 처리 중 또 예외가 발생하고(Double Fault), 이를 처리할 핸들러 주소가 IDT 오염으로 잘못되어 있으면 CPU는 포기하고 시스템을 리셋시킨다. 이를 '트리플 폴트'라 하며 부팅 중 무한 재부팅의 주원인이다.
리눅스 커널에서 하드웨어 인터럽트와 벡터 번호를 연결하고 디버깅하는 실무 과정은 다음과 같다.

  ┌────────────────────────────────────────────────────────────────────┐
  │            인터럽트 벡터 디버깅 및 분석 플로우                     │
  ├────────────────────────────────────────────────────────────────────┤
  │                                                                    │
  │ 1. [번호 확인] ──▶ cat /proc/interrupts 로 벡터/IRQ 매핑 확인      │
  │ 2. [핸들러 추적] ──▶ 커널 소스에서 request_irq() 호출 지점 검색    │
  │ 3. [IDT 상태 조회] ──▶ 디버거(kgdb)로 IDTR 주소의 메모리 덤프      │
  │ 4. [충돌 감지] ──▶ 특정 벡터에 여러 장치가 등록(Sharing)되었나?    │
  │ 5. [성능 튜닝] ──▶ 빈번한 벡터의 ISR 실행 시간 측정 및 최적화      │
  │                                                                    │
  │ * 실무 팁: 벡터 공유는 성능 저하의 주범이므로 가급적 피할 것       │
  └────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 엔지니어는 시스템 부하가 높을 때 단순히 "CPU 점유율이 높다"고 말해서는 안 된다. 구체적으로 "네트워크 카드가 사용하는 벡터 45번의 ISR이 코어 0번에서 너무 오래 머물고 있다"는 식으로 벡터 중심의 분석이 가능해야 한다. 리눅스의 /proc/interrupts는 하드웨어 벡터와 소프트웨어 핸들러의 매핑 관계를 보여주는 거울과 같다. 기술사적 판단으로 볼 때, 벡터 테이블은 시스템의 '신경절'이며, 이 신경망이 엉키거나(공유) 오염(후킹)되는 것을 막는 것이 안정적인 서버 운영의 기초 체력이다.

📢 섹션 요약 비유: 벡터 테이블 관리는 거대한 전화 교환국에서 수천 개의 회선이 꼬이지 않게 정리하는 것과 같아서, 선 하나만 잘못 연결해도 엉뚱한 사람(ISR)에게 전화가 가거나 불통(패닉)이 될 수 있습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과: 인터럽트 벡터 테이블은 '하드웨어의 고정성'과 '소프트웨어의 유연성'을 완벽하게 결합한 아키텍처적 걸작이다. 이 메커니즘 덕분에 새로운 장치가 나와도 운영체제는 벡터 번호와 ISR 주소만 새로 등록하면 즉시 호환성을 확보할 수 있다. 또한 모든 사건 처리가 '색인(Index)' 기반으로 수행되므로, 복잡한 시스템에서도 일정한 수준의 응답 지연 (Deterministic Latency)을 보장하는 효과를 거둔다.
미래 전망: 장치 수가 기하급수적으로 늘어나는 클라우드/IoT 환경에서는 고정된 256개 벡터의 한계를 넘기 위해 '메시지 기반 가상 인터럽트 벡터' 기술이 일반화될 것이다. 또한 보안 위협에 대응하여 하드웨어가 직접 벡터 테이블의 위변조를 실시간으로 감시하는 Intel CET 같은 기술이 표준으로 자리 잡아, 인터럽트 벡터는 더욱 견고한 시스템의 심장부로 진화할 것이다.
📢 섹션 요약 비유: 인터럽트 벡터 테이블은 디지털 세계의 "내비게이션 지도"와 같아서, 세상의 모든 길(인터럽트 요인)이 바뀌어도 지도 데이터(테이블)만 업데이트하면 길을 잃지 않고 목적지(ISR)에 도착하게 해줍니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
ISR (Service Routine)	벡터 테이블의 엔트리가 실제로 가리키고 있는 실행 코드 블록.
IDTR (IDT Register)	메모리 상의 벡터 테이블 위치를 CPU에 알려주는 핵심 레지스터.
인터럽트 게이트 (Gate)	권한 체크와 모드 전환 기능을 포함한 현대적 벡터 엔트리의 확장 개념.
MSI-X	물리적 핀 대신 메시지로 벡터 번호를 전달하여 확정성을 높인 최신 기술.
트리플 폴트 (Triple Fault)	벡터 테이블 참조 실패나 오류 처리가 연쇄적으로 실패할 때 발생하는 시스템 리셋 현상.

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

인터럽트 벡터는 집집마다 붙어 있는 "호수" 번호표 같은 거예요.
벡터 테이블은 아파트 입구에 있는 "우편함 목록"인데, 101호는 김 씨네, 102호는 이 씨네 집이라고 적혀 있어서 배달원이 바로 찾아갈 수 있게 도와줘요.
이 목록표가 없으면 배달원이 집을 찾느라 한참 헤매야 하지만, 목록표 덕분에 눈을 감고도 척척 편지를 배달할 수 있답니다!