런타임 오류(Runtime Error)란?

출처 : http://kin.naver.com/open100/db_detail.php?d1id=1&dir_id=101&eid=i8+loEhMNOV18h7VRGMaK40mMnPlx8D8

* 이 글은 런타임 오류의 해결책에 대한 글이 아니라, 런타임 오류가 무엇인가에 대한 글입니다.
프로그램과 상황에 따라 런타임 오류는 다양하게 발생하므로 일반적인 해결 방법이 없습니다.

런타임 오류를 해결하고자 한다면 기본적으로
1. 해당 프로그램 제작사나 유통사의 사이트에 방문하여 FAQ, Q&A를 검색
2. 네이버, 구글 등의 사이트에서 검색
3. 해결하지 못했으면 관련 사이트 곳곳에 문의
이 과정을 따르시면 됩니다.

 

 

- 런타임 오류(Runtime Error)란?

  어떤 프로그램을 만들 때 그 프로그램의 소스 코드를 모두 다 짠 후에는 일반적으로 다음과 같은 과정을 거친다.    (소스 코드를 원하는 동작에 맞게 사고하여 만들어가는 과정을 '짜다' 혹은 '코딩하다'라고 한다)

     소스 코드를 컴파일한다

-> 리소스(resource) 및 오브젝트(object) 파일 링크(link) 및 연계 편집

-> 실행 파일 생성

-> 프로그램 실행

-> 종료

  1) 컴파일타임 오류(Compile-time Error)

  이 과정 중에서, 제일 처음 과정(소스 코드 컴파일)에서 발생하는 오류는 컴파일타임 오류 라고 한다. 컴파일 도중에 발생한 오류를 지칭하는 말이다. 이 오류는 대개 소스 코드 자체의 문법적 오류(syntax error)로 인하여 발생한다. 또한 이 오류는 핸들링(handling)이 불가능한 것이다. 프로그램으로서 실행조차 되기 전에 오류가 발생했는데 당연히 핸들링이고 나발이고 일단 코드를 수정해야할 것이다. 그래서 이 오류는 개발 과정에서 사전에 수정되므로 일반 사용자들이 이 오류를 볼 일은 없다.

  2) 링크타임 오류(Link-time Error)

  두 번째 과정(연계 편집)에서 발생하는 오류는 링크타임 오류라고 한다. 컴파일타임 오류와 마찬가지로 프로그램 실행 전에 발생한 오류의 하나이다. 사실 이 오류는 그리 중요하게 여기지도 않고, 이런 용어는 잘 쓰지도 않는다.  이 오류는 주로 필요한 리소스(Resource; 그림, 문자열과 같이 프로그램에 들어가는 부가적인 데이터들을 일컫는다)나 라이브러리의 부재로 인해 발생하지만, 그렇지 않은 경우에는 해결하기가 까다롭다. 컴파일 오류와 마찬가지의 이유로 일반 사용자들이 맞닥뜨릴 일이 없는 형태의 오류이다.

 3) 런타임 오류(Run-time Error)

  그리고 네번째 과정에서 발생하는 오류를 런타임 오류라고 한다. 런타임 오류의 정의는 말 그대로, "프로그램 실행 중 발생한 오류"이다. 다른 뜻은 없다. 인터넷 검색을 하다보면 런타임 오류를 설명하는 말이 다음과 같은 것들이 있다.

  "프로그램이 조정할 수 있는 환경을 넘어선 환경에 의해서 발생되는 오류",
  "어떤 객체(object)를 실행하려고 찾다가 없거나, 혹은 적당하지 않은 값을 리턴 받으면서 생기는 오류"
 

  이 설명들은 완전히 틀린 건 아니지만 엄밀히 말하면 모두 틀렸다. 왜 그런지 알아보자.

  4) 런타임 오류의 발생 원인

  런타임 오류의 발생 원인은 매우 다양하지만 피상적인 이유는 단 하나이다.

  프로그램이 동작 중에 어떤 이유로 잘못된 데이터를 가지게 되어 잘못된 처리를 진행하려 할 때 런타임 오류가 발생하는 것이다. 이 때 프로그램 자체적으로 조정하거나, 혹은 OS가 끼어들어 프로그램을 중단시킨다. 프로그램이 런타임 오류를 자체적으로 조정했다면 사용자는 여전히 프로그램을  계속 이용 할 수 있을 것이다. 하지만 OS가 프로그램을 중지시켰다면 더 이상 이용하지 못하고 사용중이던 데이터도 증발하게 된다.

  프로그래머들은 분명히 개발 과정에서 런타임 오류가 발생할 가능성을 통찰하여 오류가 발생해도 잘못된 처리를 하지 않도록하는 코드를 미리 넣어서 사용자에게 알록달록하고 화려하고 자세한 알림창을 띄워 친절하게 알려주지만, 프로그래머들도 신은 아닌 관계로 어쩌다보면 예기치 못한 런타임 오류(unexpected run-time error)가 발생한다.

  그러면 그렇게 프로그램이 핸들링하지 못한 예기치 못한 런타임 오류는 어떻게 될까?   그것은 '하수 종말 처리장'을 떠올리면 어떻게 될지 알기 쉽다. 핸들링되지 못한 런타임 오류는 OS(혹은 VM)가 최종적으로 처리한다. OS는 런타임 오류를 최종적으로 핸들링하여 사용자에게 예기치 못한 런타임 오류가 발생하였음을 알린 후 프로그램을 종료시키고 다시 정상적으로 컴퓨터를 운영한다. 이것이 윈도우에서 종종 보게되는 다음과 같은 장면의 발생 과정이다.

 

  앞서 설명한대로, 런타임 오류의 피상적인 이유는 단 한 가지라고 했다. 그렇다면 근본적인 원인은 뭘까? 답은, "너무 다양하다"이다. 그 중 몇 개를 뽑아 나열하자면 다음과 같다.

  1. 논리적으로 잘못된 동작의 조합

  2. OS가 판단하기에 어떤 프로그램이 내린 명령이 컴퓨터의 운영에 좋지 않은 영향을 미친다고 생각될 때

  3. 플랫폼(platform) 차이의 문제
 

  '논리적으로 잘못된 동작의 조합'이라는 것은 쉽게 말해 버그(bug)이다. 프로그래머들은 프로그램을 항상 프로그램이 정상적이고 상식적인 방향으로 동작하도록 설계하지만 이미 말한대로 프로그래머는 신이 아니므로 프로그램은 분명 이상한 동작을 할 수가 있다. 기대하고 예측하고 설계한 방향으로 프로그램이 동작하지 않는 것이다. 그럴 때 우리는 이를 버그라고 부른다. 이런 측면에서 모든 프로그램은 버그가 발생할 가능성이 있다고 할 수도 있다. 그래서, 어느 것이나 마찬가지지만, 프로그램도 피드백(feedback)이 중요하다.

  물론 버그가 발생했다고 다 런타임 오류로 직행하는 것은 아니다. 버그에도 멀쩡하게 동작하는(그러나 원하는 방향은 아닌) 버그와, 런타임 오류를 발생시키는 버그가 있다. 그래서 버그는 처리가 골치 아프다.

  플랫폼 차이의 문제로 인한 런타임 오류는 프로그램 설계에 대한 문제이기도 하다. 단적인 예를들자면, 윈도우 XP에서 개발된 프로그램이 DOS에서 잘 돌아 가겠느냐하는 것이다. 물론 그럴 수도, 아닐 수도 있다.

  요즘 개발되는 대개의 프로그램은 선배 프로그래머들에 의해 이미 개발된 편리한 라이브러리와 툴을 이용함으로써 개발 생산성을 높이고 시간을 단축시키곤 하지만, 오히려 그 때문에 플랫폼에 제약을 받게 된다. 그 라이브러리가 특정 플랫폼에서 최적화 되어있는 경우가 많기 때문이다. 그래서 앞서 든 예와 같이, 플랫폼이 바뀌면 프로그램이 동작하는 상황도 바뀐다. 프로그램 설계시에 그것을 예측하지 못하면 결국 프로그램은 오동작하여 런타임 오류가 발생하는 것이다. 그런데 사실 이것은 예측하여 설계한다 해도 이러한 오동작을 완전히 박멸할 수는 없다. 모든 사용자의 컴퓨터가 같은 OS라고 해서 장착한 하드웨어나 깔린 프로그램이 한결 같이 같은 것이 아니므로 얼마든지 발생할 수가 있다. 프로그래머들은 이러한 문제를 해결하기 위해 플랫폼과 프로그램 사이의 격차를 줄일 수 있는 방법을 고안하게 되는데, 그것이 바로 VM이다. 이 VM을 통해 실행되는 프로그램은 어떤 플랫폼에서든지 동일하게 동작한다고 보장받는다. 덕분에 이렇게 플랫폼 차이에 의한 런타임 오류는 점점 해소되고 있다.

  아, 잠시 이야기가 샜는데....;;

  그 다음, 마지막으로 2번의 경우는 사실 위의 화면과 같은 모든 오류 메시지의 원인이기도 하다. 버그로 인해서, 혹은 플랫폼 차이로 인한 오동작으로 인해 프로그램이 '분수에 넘치는 짓'(권한을 넘는 동작)을 하면 OS는 프로그램을 중지 시키고 강제 종료 시킨다.

  그런 '분수에 넘치는 짓'으로 말할 것 같으면, 대표적으로 '메모리 침범'을 들 수 있다. '메모리 침범'은, 어떤 프로그램이 OS가 허락한 메모리의 영역 이외의 영역에 접근하려고 하는 것이다. 이것은 빈틈없이 꽉 짜인 운영체제에서 대단히 위험한 행동으로서, OS는 즉시 프로그램을 멈춘 뒤 사용자에게 알리고 강제 종료시킨다. OS라는 '독재자'가 구축해 놓은 세상이 보기에는 법률 위반과 같다. 위법을 저지르면 어찌 될까? 당연히 성문법에 명시된 그대로의 처벌을 받을 것이다.

  5) 런타임 오류의 해결책

  발생 원인을 알았으니, 이제 해결 방법을 알아야 할 것이다. 런타임 오류는 어떻게 해결할 수 있을까? 결론부터 말하자면 일반 사용자들은 런타임 오류를 거의 해결할 수 없다. 어떤 프로그램에서 발생하는 런타임 오류에 대한 '해결책'이라고 알려지는 것은 전적으로 그 프로그램을 만든 사람, 혹은 그 프로그램과 매커니즘을 잘 아는 일부 전문가들이 제시한 것이다. 일반 사용자들은(물론 여기에도 전문가는 있겠지만...) 그저 전문가들이 알려주는 대로 따를 수 밖에 없다. 그래서 런타임 오류를 해결하는 패치나 해결된 새로운 버전이 나오기를 기다려야 한다. 하지만 그 해결책이나 패치가 모든 컴퓨터, 모든 상황에서 유효할 수는 없으며, 결국 런타임 오류는 모든 사람, 모든 컴퓨터에서 완전히 박멸되기 힘들다. 그 이유는 간단하다. 일반 사용자는 프로그램 내부에서, 특정한 동작이나 작업이 어떻게 돌아가는지 모르기 때문이다. 만약 그걸 안다면 왜 오류가 발생했는지도 금방 추적해내어 오류를 해결할 수 있을 것이다. 런타임 오류를 해결하는 방법의 핵심은 프로그램이 어떻게 잘못 돌아가는지 알아내는 것이다.

  그렇다고 그 매커니즘을 모르는 일반 사용자들이 런타임 오류를 아주 해결할 수 없다는 말은 아니다. 프로그래머들(시스템 프로그래머나 OS 프로그래머등)은 오류가 발생했을 때 다른 프로그래머를 위해 반드시 오류의 원인과 발생 위치등에 대한 자세한 정보를 알려주도록 설계한다. 그런 때에 발생하는 오류 메시지의 일부는 일반 사용자들도 쉽게 알아들을 수 있다. 예를 들어, "파일을 찾을 수 없습니다", "파일이 이미 사용 중이므로 접근할 수 없습니다", "접근 권한이 없습니다" 등과 같이 딱 보면 알 수 있는 오류 메시지도 있다. 이런 경우에 눈치가 좀 있거나 컴퓨터를 좀 만질 줄 아는 사용자라면 금방 해결할 수 있다. 물론 이것저것 건드리다가 망가뜨리는 수도 있을 것이다.

- 결론

  자, 그러면 이제 인터넷에 떠도는 런타임 오류에 대한 두 개의 설명이 뭐가 틀렸는지 알겠는가?

  "프로그램이 조정할 수 있는 환경을 넘어선 환경에 의해서 발생되는 오류"

  ==> 런타임 오류라는 것은 프로그램의 조정 가능 여부와는 무관하다.

  "어떤 객체(object)를 실행하려고 찾다가 없거나, 혹은 적당하지 않은 값을 리턴 받으면서 생기는 오류"

  ==> 이 설명도 참 애매하다. 적당하지 않은 값을 리턴 받았다고 죄다 런타임 오류가 발생하는 것은 아니다.(물론 OOP에서는 그럴 수 있다).

  결론 : 런타임 오류는 "프로그램 실행 도중에 발생한 오류의 총칭"일 뿐, 그 이상 그 이하도 아니다.

* 오류 핸들링(error handling) : 프로그램 실행 도중 발생한 오류를 처리하는 것을 일컫는다.

* 플랫폼(platform) : OS나 프로그램이 동작하고 있는 컴퓨터 환경을 통칭한다.
* VM(Virtual Machine) : 가상 머신. 프로그래밍에서 말하는 VM은 컴파일된 프로그램의 코드를 번역하여 실행하는 컴파일러를 지칭하는 말이다. 하드웨어와 프로그램 사이를 중계하며 양자간 차이를 줄이는 역할을 한다.
* OS(Operating System) : 운영 체제

이의제기 내용추가 (2006-08-13 10:30 추가) 이의제기 내용보기

Q) 허용되지 않은 메모리 접근은 runtime error가 아니라 memory access violation이 뜨지 않나요..;;
근본적인 문제 자체가 다른 걸로 알고있는데요;;
---------------------------------------------------------
R) 메모리 침범이 곧 런타임 오류죠. 이유야 어쨌든 프로그램 실행 시간에 발생한 오동작이니까요.

이의제기 내용추가 (2007-01-04 16:39 추가) 이의제기 내용보기

leeyb 님의 의견 제시 :

꼭 틀렸다고 볼 수 없기 때문에 이의제기를 하지 않으려 했습니다만, 내용상의 근거가 부족하여 신빙성이 떨어지고 오해의 소지가 있기 때문에 굳이 이의 제기를 합니다.

우선 링크타임 오류라는 용어는 님께서 하신 말대로 잘 쓰여지지도 않는 용어입니다. 소스 코드를 실행 프로그램으로 만드는 과정에서 일어날수 있는 3대 오류로서는 보통 문법 오류, 논리 오류, 실행시간 오류로 구분할 수 있을 겁니다. (출처: 매혹적인 C++ p.74)
누군가는 3대 오류를 컴파일,논리,실행 으로 구분하거나 컴파일,링크,실행 으로 구분할 수도 있을겁니다. 물런 이런식의 구분이 틀렸다는 얘기가 아닙니다. 하지만 님의 말대로 잘 쓰여지지 않는 용어이기 때문에 사용하는데 좀더 신중했어야 했다고 생각됩니다. 개인적인 용도의 블로그에 올릴 내용도 아니거니와, 수많은 사람들이 볼수 있는 오픈된 지식으로서는 적절치 못하다고 생각되어집니다.

"프로그램이 조정할 수 있는 환경을 넘어선 환경에 의해서 발생되는 오류"
"어떤 객체(object)를 실행하려고 찾다가 없거나, 혹은 적당하지 않은 값을 리턴 받으면서 생기는 오류"

이 두말의 내용은 아주 지극히 평범한.. 실행시간 오류에 대한 설명문들입니다. 이 역시 정답이라고 하기 뭐하지만, 틀렸다고 할수는 없을 겁니다. 결론에서 두 문장이 틀렸다고 못을 박으셨지만, 첫번째 문장이 틀린 이유로서 '런타임 오류라는 것은 프로그램의 조정 가능 여부와는 무관하다' 라는 주장의 근거는 무엇인지요?
여기서 '프로그램의 조정가능 여부' 라고 하신것은 첫번째 문장을 잘못 이해 하셨기 때문인 것 같습니다. 프로그램을 조정하는 것이 아니라 '프로그램이 조정하는 환경'이라는 점을 염두해 두셨다면 결코 틀렸다고 할 수 없다는것을 금방 아실 수 있을 겁니다.
두번째 문장은 님께서 지적하신대로 애매한 문장이고 항상 오류가 발생한다고 할수 없지만 그렇다고 아예 발생하지 않는다고 할 수도 없지 않습니까? 오히려 대부분의 저러한 상황에서는 런타임 오류가 발생하는 것이 당연한 거라고 할수도 있습니다. 어찌하여 두 문장이 완전히 틀렸다고 못을 박으시는지요?
누구나 실수를 할 수 있는 것이지만, 제가 보기에는 두 문장을 부정함으로서 자신의 주장을 좀더 돋이이게 하려는 효과를 위해 일부러 이렇게 적으셨다는 생각이 드는군요. 하지만, 이경우 근거가 명확하지 않으면 주장과 함께 글 전체가 신빙성을 잃어버리게 됩니다.

플랫폼 얘기가 나왔기에 그에 대해서도 잠깐 말하겠습니다. 대부분의 프로그래머들이 실행시간 오류를 체크할때 플랫폼 차이의 문제를 어느정도로 중요하게 생각할까요? 실질적으로 거의 고려하지 않습니다. 물런 어떤 프로그램을 개발하느냐에 따라서 다를 수 있겠지만, 거의 개발 당시에 당연히 이프로그램은 원하는 플랫폼에서만 동작하도록 설계하게 되며, 해당 플랫폼의 조건에 맞지 않으면 동작하지 않게 하는것이 얼마든지 가능하기 때문입니다. 또한 의도된 종료나, 아예 동작조차 하지 않는 것이라면 실행시간오류라고 말하기 어려울 것입니다. (예. Java VM, DirectX, ...)

'윈도우 XP에서 개발된 프로그램이 DOS에서 잘 돌아 가겠느냐'라고 하셨는데 사실 이 경우에 설마 XP에서 콘솔 형태로 개발된 프로그램이라고 해도 이전버전의 DOS에서 실행하려고 하면 실행조차 되지 않는 경우가 대부분입니다. 또한 마이크로소프트에서 차기 버전의 운영에체에서는 이전버전의 운영체제들에 대한 호환성을 거의 완벽하게 제공하기 때문에 DOS버전의 프로그램도 XP에서 거의 정상적으로 실행되는 것을 확인할수 있습니다. 이처럼 운영체제의 차이는 실행되거나 아예 실행되지 않으므로 실행도중에 발생되는 런타임오류의 예로서는 부적절하다고 생각되는군요..

어떠한 사실을 전파하기 위해 글을 적을때는 최대한 객관성을 유지하면서 주장에 대한 명확한 근거와 출처를 제시해야 합니다. 물런 프로그래밍을 하면서 쌓은 수많은 지식들에 대한 출처를 일일이 기입한다는 것은 사실상 불가능에 가까울런지도 모르죠.. 예를 들때 애초에 지명도 있는 사이트의 문건이나 책의 내용을 예로 들었다면 더 좋았을것이라고 생각을 합니다.

처음 이 글을 보게 되었을때 네이버 메인페이지의 정보 Today란에 있길래 런타임오류라는 생소한 말을 일반사용자들을 위해 어떤식으로 재미있게 설명했을까? 하면서 기대하고 왔기 때문에 실망이 더 컸던것 같습니다. 차라리 군더더기 예제들을 좀 버리고서라도 내용을 좀더 줄이고 일반인들을 더욱 배려했더라면 하는 아쉬움이 남습니다.

추가적인 수정의 의지가 있으시다니 다른 말은 안하겠습니다. 사실 제말도 다 맞다고 저 자신도 확신할 수 없군요. 원래 한마디만 하고 지나가려다 반박 댓글이 나오길래 조금 흥분해서 말을 좀 심하게 한것같습니다.. 확인하시는 대로 댓글에 있는 제 글들은 자삭조치 하겠습니다.


--------------

저는 그런 의도로 쓴 것이 아닌데, 쓰다보니 그렇게 해석이 되는 문장이 나왔네요. 사실 이 글을 쓴 목적과 의도가 지식인에 이미 있었던 어떤 런타임 오류에 대한 질답글 때문이었습니다. 검색해보시면 아마 금방 아실듯 하군요. 분명 두번째 답변이 옳은 말이었는데, 첫번째 답변이 채택되었던 글이었습니다. 그 글을 보면서 제 나름대로 반론을 만들어낸다고 한 것이 이 글입니다. 즉, 이 글의 예상독자는 바로 그 답변자였던 겁니다. 어쩌다가 네이버 메인에 뜨게되었으나--사실 네이버가 한 눈에 봐도 완벽하지 않은 이 글을 메인에 띄운 것은, 사람들의 이의 제기로 완벽을 기하라는 의미였겠죠-- 이미 leeyb님이 지적하신대로 원래는 초보자를 위한 글이 아니었습니다. 다행히 이전에 여러 분들의 지적이 있어서, 이왕이면 네이버 메인에 뜬만큼 좀더 초보자를 위한 실용적 내용으로 바꾸자는 생각으로 수정글을 쓰고 있습니다. 수정글에는 leeyb님의 의견이 충분히 반영될 것입니다. 물론 그전에 쪽지로 여러가지 대담을 나눠볼까 합니다. 제가 알고있는 것이 얼마든지 틀릴 수도 있으니, 조언을 구한 뒤에 수정글을 완성할까 합니다. 좋은 의견 감사합니다.