핵심 인사이트 (3줄 요약)
- 본질: 인터럽트 사이클 (Interrupt Cycle)은 현재 명령어의 결과를 아키텍처 상태에 안전하게 반영한 뒤, 외부 사건이나 내부 예외를 처리하기 위해 정상 흐름에서 서비스 루틴으로 제어권을 넘기는 복귀 가능한 우회 절차다.
- 가치: 이 절차 덕분에 CPU (Central Processing Unit)는 느린 입출력 장치의 완료를 계속 감시하지 않아도 되고, 운영체제는 타이머 인터럽트를 기반으로 선점형 스케줄링과 빠른 이벤트 응답을 구현할 수 있다.
- 판단 포인트: 좋은 인터럽트 설계는 "빨리 반응하는 것"만이 아니라, 문맥 저장 비용·우선순위 충돌·파이프라인 플러시·정밀한 예외 (Precise Exception) 보장을 함께 관리하는 데서 결정된다.
Ⅰ. 개요 및 필요성
인터럽트 사이클 (Interrupt Cycle)은 CPU가 현재 명령어를 마친 뒤, 다음 명령어를 이어서 가져오기 전에 인터럽트 요청을 확인하고 필요하면 인터럽트 서비스 루틴 (Interrupt Service Routine, ISR)으로 분기하는 제어 단계다. 핵심은 "지금 하던 일을 완전히 버리는 것"이 아니라, 나중에 정확히 돌아올 수 있도록 멈추는 것이다.
이 개념이 필요해진 이유는 CPU와 외부 장치의 속도가 극단적으로 다르기 때문이다. 키보드 입력, 디스크 완료, 네트워크 수신, 타이머 만료 같은 사건은 CPU 클럭과 무관하게 비동기적으로 발생한다. 이런 사건을 매번 CPU가 직접 확인하는 폴링 (Polling) 방식만 쓰면, CPU는 실제 계산보다 "아직 안 끝났니?"를 묻는 데 더 많은 시간을 낭비하게 된다.
인터럽트 사이클은 이 비효율을 구조적으로 해결한다. 장치가 준비되었을 때만 CPU를 호출하게 만들고, CPU는 호출 시점에 현재 문맥(Context)을 저장한 뒤 필요한 처리만 하고 원래 흐름으로 복귀한다. 그래서 인터럽트는 단순한 편의 기능이 아니라, 현대 시스템의 반응성·자원 효율·멀티태스킹을 떠받치는 하드웨어 계약이다.
┌────────────────────────────────────────────────────────────────────────────┐
│ 왜 인터럽트 사이클이 필요한가: 감시보다 호출 │
├────────────────────────────────────────────────────────────────────────────┤
│ Polling 방식 │
│ CPU ──▶ 장치 확인 ──▶ 아직 아님 ──▶ 장치 확인 ──▶ 아직 아님 ──▶ 반복 │
│ │
│ Interrupt 방식 │
│ CPU ──▶ 본업 수행 ───────────────────────────────▶ 인터럽트 수신 후 대응 │
│ 장치가 준비되면 스스로 신호 전송 │
└────────────────────────────────────────────────────────────────────────────┘
이 그림이 보여 주는 차이는 단순한 편의성보다 더 크다. 폴링은 CPU 시간을 사건 탐지에 쓰고, 인터럽트는 CPU 시간을 본업에 쓰다가 필요할 때만 제어 흐름을 굽힌다. 즉 인터럽트 사이클의 존재 이유는 응답성 확보와 유휴 낭비 제거를 동시에 달성하는 데 있다.
- 📢 섹션 요약 비유: 인터럽트 사이클은 식당 사장이 주방을 비우고 매초 문밖을 확인하는 대신, 벨이 울릴 때만 나가 손님을 맞는 방식과 같다. 벨이 없으면 반응은 느리고 일이 낭비되며, 벨이 있으면 본업과 응답을 둘 다 챙길 수 있다.
Ⅱ. 아키텍처 및 핵심 원리
인터럽트 사이클을 구성하는 핵심 요소는 프로그램 카운터 (Program Counter, PC), 프로그램 상태 워드 (Program Status Word, PSW) 또는 상태 레지스터, 스택 포인터 (Stack Pointer, SP), 인터럽트 벡터 테이블 (Interrupt Vector Table, IVT), 그리고 인터럽트 허용 비트다. 제어 유닛 (Control Unit)은 명령어 경계에서 인터럽트 요청이 펜딩(Pending) 상태인지 확인하고, 허용 조건이 맞으면 복귀 주소와 상태를 저장한 뒤 ISR 주소를 PC에 적재한다.
| 구성 요소 | 역할 | 인터럽트 사이클에서 중요한 이유 |
|---|---|---|
| PC | 다음 실행 주소 유지 | 복귀 지점을 정확히 남겨야 원래 흐름을 재개 가능 |
| PSW/상태 레지스터 | 인터럽트 허용, 조건 코드 보관 | 단순 주소뿐 아니라 실행 상태까지 복구해야 함 |
| SP | 스택 최상단 관리 | 문맥 저장 위치를 정해 nested interrupt를 감당 |
| IVT | 인터럽트 번호와 ISR 주소 연결 | 어떤 사건인지에 따라 즉시 적절한 핸들러 진입 |
| 인터럽트 마스크 | 허용/차단 제어 | 긴급도와 임계구역 보호를 하드웨어 수준에서 보장 |
아래 흐름은 고전적 단일 코어 관점에서 인터럽트 사이클이 어떻게 진행되는지 보여 준다.
┌────────────────────────────────────────────────────────────────────────────┐
│ 인터럽트 사이클의 전형적 상태 전이 │
├────────────────────────────────────────────────────────────────────────────┤
│ 정상 명령 실행 완료 │
│ │ │
│ ▼ │
│ 인터럽트 요청 검사 ── No ───────────────────────────────▶ 다음 Fetch │
│ │ │
│ Yes │
│ ▼ │
│ 인터럽트 허용 비트 확인 및 우선순위 판정 │
│ │ │
│ ▼ │
│ SP 갱신 → PC/PSW 저장 → 인터럽트 벡터 조회 → PC ← ISR 시작 주소 │
│ │ │
│ ▼ │
│ ISR 실행 │
│ │ │
│ ▼ │
│ 인터럽트 복귀 명령 수행 → PSW/PC 복구 → 원래 프로그램 복귀 │
└────────────────────────────────────────────────────────────────────────────┘
이 그림의 핵심은 인터럽트가 단순 점프가 아니라 저장 → 분기 → 처리 → 복구의 완전한 왕복 구조라는 점이다. 그래서 인터럽트 사이클의 비용은 ISR 본문만이 아니라, 문맥 저장과 복구에 필요한 클럭 수까지 함께 봐야 한다. 짧은 ISR이라도 인터럽트 빈도가 지나치게 높으면 전체 시스템은 "일보다 갈아타기"에 더 많은 시간을 쓸 수 있다.
현대 파이프라인에서는 여기에 한 가지 조건이 더 붙는다. 인터럽트는 보통 명령어 경계 또는 retire/commit 지점에서 수용되어야 정밀한 예외 (Precise Exception)를 보장할 수 있다. 즉 앞선 명령은 완전히 끝났고, 뒤 명령은 아직 반영되지 않은 상태를 만들어야 운영체제가 복구 가능한 일관된 상태를 받는다.
- 📢 섹션 요약 비유: 인터럽트 사이클은 책을 읽다가 급한 전화를 받는 상황과 같다. 페이지 번호를 접어 두고, 중요한 메모를 남기고, 전화를 받고 돌아와야 같은 문장부터 다시 읽을 수 있다. 접어 두는 과정이 없으면 복귀는 빨라 보여도 정확하지 않다.
Ⅲ. 비교 및 연결
인터럽트 사이클의 경계는 폴링과 비교할 때 가장 또렷하고, 예외(Exception)와 비교할 때 가장 자주 헷갈린다. 폴링은 CPU가 사건을 찾으러 가는 방식이고, 인터럽트는 사건이 CPU를 부르는 방식이다. 또한 외부 장치가 건 요청은 하드웨어 인터럽트, 명령어 실행 중 내부에서 검출된 오류는 예외로 분류되지만, 둘 다 결국 제어 흐름을 바꾸고 상태를 저장한다는 점에서 공통 메커니즘을 공유한다.
| 비교 항목 | 폴링 (Polling) | 인터럽트 (Interrupt) | 예외 (Exception) |
|---|---|---|---|
| 발생 주체 | CPU의 능동 확인 | 외부 장치/타이머의 비동기 요청 | CPU 내부 실행 결과 |
| 발생 시점 | 소프트웨어가 검사할 때만 | 사건 발생 시 즉시 펜딩 | 명령어 수행 중 동기적으로 검출 |
| 장점 | 단순하고 예측 쉬움 | CPU 낭비 감소, 응답성 우수 | 오류 복구와 보호 가능 |
| 주의점 | 불필요한 바쁜 대기 | 문맥 저장·우선순위 관리 필요 | 정밀한 예외 순서 보장 필요 |
운영체제와 연결하면 인터럽트 사이클은 곧 스케줄링의 시작점이 된다. 타이머 인터럽트가 주기적으로 들어오면 커널은 현재 프로세스의 문맥을 저장하고 다른 프로세스로 전환할 수 있다. 컴퓨터구조 관점의 인터럽트 사이클이 운영체제 관점의 문맥 교환 (Context Switch)과 직접 이어지는 이유가 여기에 있다.
파이프라인과 연결하면 인터럽트는 제어 해저드 (Control Hazard) 성격도 가진다. 이미 인출·해독된 뒤 명령어들은 인터럽트 수용 시점에 따라 무효화(flush)될 수 있고, 특히 깊은 파이프라인일수록 잘못 가져온 명령어를 버리는 비용이 커진다. 그래서 현대 CPU는 "가능한 빨리 응답"보다 "정확한 지점에서 응답"을 더 우선시한다.
┌────────────────────────────────────────────────────────────────────────────┐
│ 인터럽트 사이클이 다른 계층과 연결되는 방식 │
├────────────────────────────────────────────────────────────────────────────┤
│ 장치 완료/타이머 │
│ │ │
│ ▼ │
│ 인터럽트 요청 ──▶ CPU 인터럽트 사이클 ──▶ ISR │
│ │ │
│ ├──▶ 커널 스케줄러 호출 │
│ │ └──▶ Context Switch │
│ │ │
│ └──▶ 파이프라인 flush / precise state 보장 │
└────────────────────────────────────────────────────────────────────────────┘
이 연결 구조가 중요한 이유는 인터럽트 사이클이 "장치 처리만의 문제"가 아니라는 점을 보여 주기 때문이다. 하드웨어에서는 제어권 전환, 운영체제에서는 스케줄링, 마이크로아키텍처에서는 정밀 상태 보장이 한 번에 맞물린다.
- 📢 섹션 요약 비유: 폴링은 택배가 왔는지 창문을 계속 내다보는 것이고, 인터럽트는 초인종이 울리면 나가는 것이다. 예외는 집 안에서 갑자기 가스 경보가 울리는 경우인데, 밖에서 온 신호든 안에서 난 문제든 결국 하던 일을 멈추고 먼저 처리해야 한다는 점은 같다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 인터럽트 사이클은 "응답을 빠르게 만들자"보다 "어디까지를 즉시 처리하고 어디부터를 뒤로 미룰까"의 문제로 나타난다. 인터럽트 직후의 상반부(Top Half)는 장치 상태 확인, 인터럽트 원인 제거, 최소한의 데이터 확보까지만 수행하고, 긴 계산이나 블로킹 작업은 하반부(Bottom Half), 소프트인터럽트 (Software Interrupt, SoftIRQ), 워크큐 같은 지연 처리 메커니즘으로 넘기는 것이 일반적이다. 인터럽트 컨텍스트에서 오래 머물수록 다른 인터럽트와 스케줄링이 막히기 때문이다.
대표 사례는 네트워크 패킷 폭주다. 초당 수십만 번 인터럽트가 들어오면 CPU는 패킷 처리보다 인터럽트 진입/복귀 오버헤드에 더 많은 시간을 쓰게 된다. 이때는 NAPI (New API)처럼 일정 부하 이상에서는 인터럽트에서 폴링 모드로 전환하는 하이브리드 전략이 더 유리하다. 즉 인터럽트는 항상 정답이 아니라, 빈도와 비용이 맞을 때 가장 강력한 방식이다.
설계·운영 판단 체크리스트
- 인터럽트 수용 지점이 명령어 경계 또는 정밀 상태 보장 지점으로 제한되어 있는가?
- ISR에서 잠금 경쟁, 메모리 할당, 블로킹 호출 같은 장기 지연 요소를 피하고 있는가?
- 우선순위가 높은 장치가 낮은 장치의 ISR 때문에 지연되지 않도록 중첩 인터럽트 또는 마스킹 정책이 설계되어 있는가?
- 인터럽트 폭주 시 폴링 전환, 코얼레싱(coalescing), MSI-X 분산 같은 완화 전략이 준비되어 있는가?
피해야 할 안티패턴
- ISR 안에서 파일 I/O, sleep, 긴 반복문을 수행하는 설계
- 모든 사건을 최고 우선순위 인터럽트로 처리해 우선순위 체계를 붕괴시키는 설계
- 멀티코어 환경에서 인터럽트를 한 코어에 몰아넣어 캐시 편향과 지연을 키우는 운영
결국 기술사 답안에서는 "인터럽트가 왜 좋은가"만 쓰면 부족하다. 언제 폴링보다 유리한지, 언제 오히려 인터럽트 오버헤드가 병목이 되는지, 그리고 정밀한 예외와 문맥 보존을 어떻게 보장하는지가 함께 나와야 좋은 판단이 된다.
- 📢 섹션 요약 비유: 인터럽트 처리는 응급실 접수와 같다. 환자를 빨리 받는 것도 중요하지만, 접수창구에서 오래 붙잡아 두면 뒤 환자들이 모두 밀린다. 응급 처치만 하고 검사·입원은 뒤 절차로 넘겨야 병원이 전체적으로 잘 돈다.
Ⅴ. 기대효과 및 결론
인터럽트 사이클의 가장 큰 효과는 CPU 시간을 사건 감시에서 실제 계산으로 돌려놓는 데 있다. 그 결과 시스템은 더 높은 처리 효율, 더 나은 반응성, 더 현실적인 멀티태스킹을 얻는다. 특히 타이머 인터럽트 기반 선점, 디바이스 완료 통지, 오류 처리 루틴은 현대 범용 컴퓨터가 "동시에 많은 일을 하는 것처럼 보이게" 만드는 토대다.
다만 이 장점은 공짜가 아니다. 인터럽트마다 문맥 저장/복구 비용이 들고, 파이프라인 플러시와 캐시 교란이 생기며, 우선순위 역전이나 인터럽트 스톰(Interrupt Storm) 같은 운영 문제가 뒤따를 수 있다. 그래서 인터럽트 사이클은 무조건 많이 쓰는 기술이 아니라, 사건의 긴급성·빈도·처리 길이를 고려해 설계해야 하는 제어 전략이다.
미래 방향도 분명하다. 메시지 기반 인터럽트 (Message Signaled Interrupts, MSI)와 확장형 메시지 기반 인터럽트 (Message Signaled Interrupts eXtended, MSI-X), 인터럽트 코얼레싱, 멀티큐 네트워크 장치, 가상화 보조 인터럽트 전달처럼 더 세밀하게 "누가 어느 코어를 언제 깨울 것인가"를 조정하는 방향으로 발전한다. 따라서 인터럽트 사이클은 단순한 교과서 단계가 아니라, 현대 시스템에서 정확한 상태 보존 위에 반응성을 얹는 핵심 제어 메커니즘으로 기억해야 한다.
- 📢 섹션 요약 비유: 인터럽트 사이클은 회사 대표 번호로 걸려 온 긴급 전화를 적절한 담당자에게 연결하는 교환 시스템과 같다. 전화를 잘 받는 것만큼, 메모를 남기고 정확한 사람에게 넘기고 다시 본업으로 돌아오게 하는 체계가 중요하다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 명령어 사이클 (Instruction Cycle) | 인터럽트 사이클은 정상 명령 실행 루프 사이에 끼어드는 예외적 제어 단계다. |
| 인터럽트 벡터 (Interrupt Vector) | 어떤 ISR로 점프할지 결정하는 인덱스이자 주소 매핑 수단이다. |
| 문맥 교환 (Context Switch) | 인터럽트가 커널 스케줄러를 깨우면 프로세스 전환으로 확장된다. |
| 정밀한 예외 (Precise Exception) | 인터럽트/예외 수용 시점에 앞선 명령 완료와 뒤 명령 미반영 상태를 보장한다. |
| 파이프라인 플러시 (Pipeline Flush) | 인터럽트 수용 후 잘못 진행 중인 뒤 단계 명령어를 제거하는 비용과 연결된다. |
| 폴링 (Polling) | 인터럽트 사이클의 필요성과 장점을 가장 잘 드러내는 대비 개념이다. |
📈 관련 키워드 및 발전 흐름도
단순 폴링 기반 장치 감시
│
▼
인터럽트 요청선 + 인터럽트 사이클
│
▼
인터럽트 벡터 (Interrupt Vector) · ISR
│
▼
타이머 인터럽트 기반 선점형 스케줄링
│
▼
정밀한 예외 (Precise Exception) · 파이프라인 플러시 제어
│
▼
MSI/MSI-X · 인터럽트 코얼레싱 · 가상화 보조 전달
이 흐름은 "장치를 계속 감시하던 구조"에서 출발해, "벡터 기반 자동 분기"를 거쳐, "멀티코어·가상화 환경에서 인터럽트를 정교하게 배분하는 구조"로 발전해 온 과정을 보여 준다.
👶 어린이를 위한 3줄 비유 설명
- 컴퓨터가 숙제를 하고 있을 때 초인종이 울리면, 어디까지 했는지 책갈피를 꽂고 문을 열러 가는 과정이 인터럽트 사이클이에요.
- 문 앞 일을 끝내면 책갈피를 보고 다시 원래 숙제로 정확히 돌아와요.
- 그래서 컴퓨터는 매번 문밖을 확인하지 않아도 되고, 중요한 일이 생겼을 때만 빠르게 반응할 수 있어요.