프리징 (컴퓨팅)
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
프리징은 컴퓨터 시스템이나 프로그램이 응답하지 않고 멈춘 것처럼 보이는 현상을 의미한다. 하드웨어 문제, 소프트웨어 버그, 프로세스 간의 통신 문제, 리소스 부족 등이 프리징의 원인이 될 수 있다. 다중 작업 환경에서 운영 체제는 개별 프로세스나 스레드가 멈출 경우 시스템 전체의 영향을 다르게 처리하며, 협력적 다중 작업 시스템에서는 멈춘 스레드가 시스템을 멈추게 할 수 있지만, 선점형 다중 작업 시스템에서는 그렇지 않다. 프리징은 프로그램 강제 종료, 시스템 재시작, 또는 워치독 타이머와 같은 해결 방법을 통해 해결할 수 있으며, 애플리케이션 개발 시에는 비동기 처리와 사용자 인터페이스 개선을 통해 예방할 수 있다.
더 읽어볼만한 페이지
- 소프트웨어 이상 - 예외 처리
예외 처리는 프로그램 실행 중 예외 발생 시 정상적인 실행 흐름을 유지하거나 안전하게 종료하기 위한 메커니즘으로, 많은 프로그래밍 언어에서 제공하며 예외 안전성을 목표로 한다. - 소프트웨어 이상 - NaN
NaN(Not a Number)은 IEEE 754 표준에서 숫자가 아님을 나타내는 특수한 값으로, 지수부가 모두 1이고 가수부가 0이 아닌 비트 패턴으로 표현되며, 연산 시 예외를 발생시키지 않고 전파되는 quiet NaN과 예외를 발생시키는 signaling NaN이 있다. - 컴퓨터 오류 - 블루스크린
블루스크린은 윈도우 운영체제에서 발생하는 치명적인 오류로, 컴퓨터 작동을 멈추고 파란색 화면에 오류 메시지를 표시하며, 하드웨어 또는 소프트웨어 문제로 인해 발생하고, 시스템 복원, 안전 모드 부팅 등의 방법으로 대처한다. - 컴퓨터 오류 - 글리치
글리치는 예기치 않은 오작동이나 오류를 뜻하며, 전자 공학, 컴퓨터, 비디오 게임, 텔레비전 방송, 대중문화 등 다양한 분야에서 기능 실패, 오류, 그래픽 및 사운드 문제, 신호 오류 등의 이상 현상을 포괄적으로 지칭하는 용어이다. - 컴퓨터 용어 - 중앙 처리 장치
중앙 처리 장치(CPU)는 컴퓨터 시스템의 핵심 부품으로, 프로그램 명령어를 해석하고 실행하여 데이터를 처리하는 장치이다. - 컴퓨터 용어 - 운영체제 서비스 관리
프리징 (컴퓨팅) | |
---|---|
현상 개요 | |
정의 | 프로세스가 응답하지 않는 상태 |
다른 용어 | 멈춤, 정지, 먹통 |
영어 | freeze (프리즈) |
원인 | |
일반적인 원인 | 소프트웨어 버그 하드웨어 문제 과도한 시스템 부하 드라이버 충돌 운영 체제 오류 |
증상 | |
사용자 인터페이스 | 응답 없음 창 제목 표시줄에 "(응답 없음)" 표시 [^] 마우스 커서가 "대기" 모양으로 변경 창 내용이 흐릿하게 표시 (Windows Vista 이후) [^] |
시스템 | CPU 사용률 급증 디스크 I/O 급증 메모리 부족 |
해결 방법 | |
임시 해결책 | 프로그램 강제 종료 (작업 관리자 사용) 시스템 재부팅 |
근본적인 해결책 | 소프트웨어 업데이트 또는 재설치 하드웨어 점검 및 교체 드라이버 업데이트 운영 체제 업데이트 또는 재설치 |
관련 용어 | |
시스템 멈춤 | 시스템 전체가 응답하지 않는 상태 |
데드락 (교착 상태) | 여러 프로세스가 서로의 자원 해제를 기다리며 무한정 멈춰있는 상태 |
2. 원인
프리징은 다양한 원인으로 발생할 수 있으며, 크게 하드웨어 문제, 소프트웨어 문제, 리소스 부족 문제로 나눌 수 있다.
하드웨어나 소프트웨어 문제는 프리징을 일으키는 일반적인 원인이다. 예를 들어, CPU 과열이나 버그가 있는 장치 드라이버는 시스템을 멈추게 할 수 있다. 프로그래밍 오류로 인한 무한 루프나 교착 상태 역시 프리징의 주요 원인이다.[4]
리소스 부족 또한 프리징을 유발할 수 있다. 컴퓨터가 처리할 수 있는 용량을 초과하는 작업이 주어지거나, 메모리가 부족한 경우 시스템이 느려지거나 멈출 수 있다. 스파이웨어와 같이 몰래 설치된 프로그램도 시스템 자원을 소모하여 프리징을 유발할 수 있다.
OS, 장치 드라이버, 하드웨어 등 시스템의 중요한 부분에서 문제가 발생하면 시스템 전체가 프리징될 수 있다. 시스템 전체 프리징으로부터 복구하려면 컴퓨터 재시작이 필요하다. 프리엠티브 멀티태스킹 OS에서는 응용 프로그램이 프리징되어도 시스템 전체나 다른 응용 프로그램에 영향을 주지 않지만, MS-DOS나 Windows 3.x, Classic Mac OS 등 프리엠티브 멀티태스킹이 아닌 OS에서는 응용 프로그램 프리징만으로도 컴퓨터를 재시작해야 하는 경우가 있다.
2. 1. 하드웨어 문제
하드웨어는 간헐적인 문제나 다른 하드웨어와의 호환성 문제로 인해 컴퓨터를 멈추게 할 수 있다[3](이는 업그레이드를 할 때 발생할 수 있다). 하드웨어는 시간이 지남에 따라 먼지나 열 손상으로 인해 결함이 발생할 수도 있다.CPU의 과열과 같은 물리적인 문제도 프리징을 유발할 수 있다.[4] 패밀리 컴퓨터와 같이 충격에 약한 게임기에서는 접촉 불량으로 인해 게임이 프리징되는 경우가 있다. 이 경우, 일반적으로 게임기를 리셋하는 수밖에 없으며, 배터리 백업 등으로 진행 상황의 데이터를 저장하는 기능을 갖추지 않은 게임에서는 처음부터 다시 시작해야 한다. CD 등 광학 매체를 채용한 게임기는 픽업 렌즈의 열화로 인해 읽기 불량이 다발적으로 발생하여 게임이 프리징되는 경우도 있다.
2. 2. 소프트웨어 문제
소프트웨어나 장치 드라이버의 버그, 무한 루프, 교착 상태 등이 프리징을 유발할 수 있다.[4] 프로그래머가 루프에 대한 종료 조건을 잘못 설정하거나, 협력적 멀티태스킹 운영 체제에서 다른 작업에 제어를 넘겨주지 않아 프리징이 발생할 수 있다.프로세스 간 통신에서 발생하는 경합 조건도 프리징의 원인 중 하나이다. 예를 들어, 한 프로세스가 다른 프로세스에 신호를 보내고 응답을 기다리는 동안, 다른 프로세스도 신호를 보내느라 바빠 서로의 신호를 받지 못하는 교착 상태가 발생할 수 있다.[4]
Microsoft Windows에서는 응용 프로그램이 프리징되면, 일반적으로 응용 프로그램 이름 등이 표시되는 윈도우의 제목 표시줄 부분 문자열 끝에 '''(응답 없음)'''이 표시된다.
2. 3. 리소스 부족
컴퓨터가 실제로 매우 느리게 처리하고 있을 때 멈춘 것처럼 보일 수 있다. 이는 다음과 같은 원인으로 발생할 수 있다:- 너무 많은 프로그램이 동시에 실행되는 경우
- 메모리(RAM) 부족
- 메모리 단편화
- 느린 하드웨어 접근(특히 원격 장치로의 접근)
- 느린 시스템 API
스파이웨어와 같이 몰래 설치된 숨겨진 프로그램도 시스템 자원을 소모하여 프리징을 유발할 수 있다.[3]
3. 다중 작업 (Multitasking)
운영 체제의 다중 작업 방식은 프리징에 영향을 미칠 수 있다. 다중 작업 운영 체제에서 개별 프로세스 또는 스레드가 멈출 수 있지만, 전체 시스템에 미치는 영향은 다양하다. 협력적 다중 작업 시스템에서는 실행 중인 스레드가 다른 스레드의 실행을 막아 시스템을 멈추게 할 수 있다. 반면 선점형 다중 작업 시스템에서는 운영 체제가 각 스레드에 시간 조각을 할당하여 실행하므로, 하나의 스레드가 멈춰도 다른 스레드는 계속 실행될 수 있다.
Microsoft Windows에서는 응용 프로그램이 프리징되면, 일반적으로 응용 프로그램 이름 등이 표시되는 윈도우의 제목 표시줄 부분 문자열 끝에 '''(응답 없음)'''이 표시된다.
3. 1. 협력적 다중 작업 (Cooperative Multitasking)
협력적 다중 작업 시스템에서는 멈춘 스레드가 시스템을 멈추게 할 수 있는데, 이는 실행 중인 스레드가 다른 스레드의 실행을 막기 때문이다.[1] MS-DOS, Windows 3.x, Classic Mac OS와 같이 선점형 멀티태스킹을 지원하지 않는 운영 체제에서는 응용 프로그램이 프리징되면 컴퓨터를 재시작해야 하는 경우가 있었다.3. 2. 선점형 다중 작업 (Preemptive Multitasking)
현대의 운영 체제는 주로 선점형 다중 작업을 사용하며, 여기에는 윈도우 2000 및 후속 버전, 리눅스, 애플의 macOS가 있다. 선점형 다중 작업 시스템에서는 운영 체제가 각 스레드에 시간 조각을 할당하여 실행하므로, 하나의 스레드가 멈춰도 다른 스레드는 계속 실행될 수 있다.[1] 스레드가 멈추면 스케줄러가 다른 상호 의존적인 작업 그룹으로 전환하여 모든 프로세스가 멈추지 않도록 할 수 있다.그러나 멈춘 스레드는 여전히 리소스를 소비한다. 최소한 스케줄링 항목을 소비하며, (예를 들어 무한 루프에 갇힌 경우) 예약될 때 프로세서 사이클과 전력을 소비하여 시스템 속도를 늦추지만 멈추게 하지는 않는다.
선점형 다중 작업을 사용하더라도 잘못된 동작을 하거나 악의적인 작업이 프로세서 시간을 독점할 수는 없지만, IO나 메모리와 같은 다른 리소스를 독점함으로써 시스템을 멈추게 할 수 있다. 예를 들어, 파일 시스템을 차단하는 프로세스는 종종 시스템을 멈추게 한다.
4. 해결 방법
프로그램이 멈춘 것처럼 보여도 실제로는 느리게 진행 중일 수 있으며, 몇 분 정도 기다리면 작업이 완료될 수 있다.
현대 운영 체제에서는 프리징된 프로세스를 종료하거나, 시스템을 재시작하는 방법으로 문제를 해결할 수 있다. 임베디드 시스템에서는 Watchdog 타이머를 사용하여 멈춤 현상이 발생하면 자동으로 시스템을 리부팅할 수 있다.
4. 1. 프로그램 강제 종료
현대 운영 체제는 멈춘 프로세스를 종료하는 기능을 제공한다. 예를 들어 유닉스의 kill 명령어, 윈도우의 작업 관리자에서 "작업 끝내기" 버튼(목록에서 특정 프로세스를 선택하고 "작업 끝내기"를 누름)과 같은 그래픽 인터페이스를 사용할 수 있다.[7]4. 2. 시스템 재시작
프로그램 강제 종료로 해결되지 않는 프리징의 경우, 시스템을 재시작해야 할 수 있다. MS-DOS, 초기 버전의 Windows 또는 Classic Mac OS와 같은 구형 시스템에서는 멈춤 현상이 발생할 경우 종종 완전히 재시작해야 했다.[7]4. 3. 워치독 타이머 (Watchdog Timer)
임베디드 시스템에서는 Watchdog 타이머를 사용하여 멈춤 현상이 발생할 경우 자동으로 시스템을 리부팅할 수 있다.[1]5. 예방 대책 (애플리케이션)
애플리케이션에서 프리징을 예방하려면, 시간이 오래 걸리는 처리는 사용자 인터페이스를 담당하는 메인 스레드가 아닌 별도의 스레드에서 비동기적으로 처리해야 한다. 처리 결과는 콜백을 통해 받거나, Future 패턴 또는 async/await 구문을 사용하여 간결하게 작성할 수 있다. 또한, 프로그레스 바를 표시하여 처리 진행 상황을 시각적으로 보여주고, 필요한 경우 사용자가 작업을 취소할 수 있도록 취소 버튼을 제공하는 것이 좋다.[9][10][11]
5. 1. 비동기 처리 (Asynchronous Processing)
애플리케이션에서 사용자 응답을 담당하는 메인 스레드는 시간이 오래 걸리는 처리를 직접 실행해서는 안 된다. 특히 저장 장치 입출력(I/O)이나 네트워크 연결 및 통신과 같은 처리는 완료 시간을 예측하기 어렵고, 다른 프로세스에 의해 하드웨어 리소스가 먼저 점유되면 예상보다 오래 걸릴 수 있다.[9]어떤 서브루틴을 호출하고 처리 결과를 반환값으로 직접 받는 블로킹(동기) 처리는 프로그래밍이 간단하지만, 프리징을 유발하기 쉽다. 타임아웃 시간을 지정하는 블로킹 처리를 사용할 수도 있지만, 근본적인 해결책은 아니다.
프리징을 피하려면 처리 시간이 오래 걸리는 경우 부정 응답을 즉시 반환하는 논블로킹 처리나, 요청을 발행 후 콜백을 통해 결과를 받는 비동기 처리를 사용해야 한다. 예를 들어 I/O나 네트워크 처리는 서브 스레드(워커 스레드)나 다른 서비스 프로세스에 위임하고, 메인 스레드는 결과 알림을 받아 후속 처리를 진행해야 한다. 시간이 오래 걸리는 처리는 백그라운드에서 실행하여 애플리케이션의 메인 스레드가 응답성을 유지하도록 할 수 있다.[9]
과거에는 비동기 처리가 프로그래밍을 어렵게 했지만, 현대적인 프로그래밍 언어 및 환경에서는 Future 패턴이나 async/await 구문을 사용하여 간결하게 작성할 수 있다.
서브 스레드에서 비동기 처리 결과가 반환될 때까지 메인 스레드는 자유롭게 사용할 수 있지만, 프로그레스 바를 표시하는 등 애플리케이션 동작 상황을 사용자에게 알려야 한다.[10][11] 여러 데이터를 처리하거나 파일을 읽고 쓸 때, 처리 진척률과 예상 완료 시간을 화면에 표시하여 애플리케이션이 프리징되지 않았음을 명확히 하고, 사용자의 스트레스를 줄여 체감 대기 시간을 줄일 수 있다. 취소 가능한 처리라면 취소 버튼을 준비하여 사용자 취소 지시가 있을 때 빠르게 처리를 중단하고 응답을 반환해야 한다.
5. 2. 사용자 인터페이스 (UI) 개선
애플리케이션은 사용자의 입력을 처리하는 메인 스레드에서 시간이 오래 걸리는 작업을 직접 처리하지 않아야 한다. 대신, 별도의 스레드(서브 스레드)에서 비동기적으로 처리하고, 그 결과가 나오면 메인 스레드에 알려주는 방식을 사용해야 한다. 메인 스레드는 사용자 인터페이스를 담당하므로, 비동기 처리 결과를 기다리는 동안에도 사용자의 다른 입력을 받을 수 있다.처리 진행 상황은 프로그레스 바 등을 통해 사용자에게 시각적으로 보여주는 것이 좋다.[10][11] 예를 들어, 여러 파일을 처리하거나 데이터를 읽고 쓸 때, 전체 작업 중 얼마나 완료되었는지, 완료까지 얼마나 걸릴지 예상 시간을 표시하면 사용자가 답답함을 덜 느끼고, 애플리케이션이 정상적으로 작동하고 있다는 것을 알 수 있다. 만약 사용자가 작업을 취소할 수 있도록 하려면, 대화 상자 등에 취소 버튼을 만들어 사용자가 취소 요청을 했을 때 최대한 빨리 작업을 중단하고 응답해야 한다.
참조
[1]
특허
Preemptive multi-tasking with cooperative groups of tasks
[2]
웹사이트
Nostalgia: Dragging the Windows XP error dialog
http://old.marcofoli[...]
2022-01-19
[3]
웹사이트
How to Troubleshoot Computer Hangs During Hardware Detection
http://support.micro[...]
Microsoft Support
2007-01-27
[4]
웹사이트
Here's an infinite loop that will hang your machine
https://blogs.msdn.m[...]
2006-11-15
[5]
Microsoft Learn
Preventing Hangs in Windows Applications - Win32 apps
https://learn.micros[...]
[6]
Android Developers
ANR | App quality
https://developer.an[...]
[7]
IT用語辞典 e-Words
Windows 95とは - 意味をわかりやすく
https://e-words.jp/w[...]
[8]
ASCII.jp
マルチコアCPUを賢く使いこなす スケジューリングの秘密 (1/3)
https://ascii.jp/ele[...]
[9]
Microsoft Learn
비동기 프로그래밍 - UWP applications
https://learn.micros[...]
[10]
Microsoft Learn
Progress Bars - Win32 apps
https://learn.micros[...]
[11]
Android Developers
アプリの応答性を維持する | App quality
https://developer.an[...]
[12]
특허
Preemptive multi-tasking with cooperative groups of tasks
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com