소프트웨어 버그
 | 이 문서의 내용은 출처가 분명하지 않습니다. (2010년 9월) |
| 소프트웨어 개발 프로세스 | |
|---|---|
| 활동과 단계 | |
| 요구사항 분석 · 기능 명세 구조 · 설계 구현 · 테스팅 배치 · 유지보수 | |
| 개발 모형 | |
| 애자일 소프트웨어 개발 · 클린룸 DSDM · 순차점증적 개발 · 반복형 개발 RAD · RUP · 나선 모형 폭포수 모델 · 익스트림 프로그래밍 스크럼 · V 모델 · TDD | |
| 지원 활동 | |
| 구성 관리 · 문서화 품질보증 · 프로젝트 관리 사용자 경험 설계 | |
| 도구 | |
| 컴파일러 · 디버거 · 프로파일러 GUI 디자이너 · 통합 개발 환경 | |
위키백과의 버그에 대해서는 위키백과:버그 보고 문서를 참고하십시오.
소프트웨어 버그(영어: software bug) 또는 줄여서 버그(bug)는 소프트웨어가 예상하지 못한 잘못된 결과를 내거나, 오류가 발생하거나, 착오나 오작동이 발생하는 등의 문제를 뜻한다. 버그는 프로그램의 소스 코드나 설계 과정에서의 결점, 결함 및 오류 때문에 발생한다.
버그의 결과로 다양한 문제가 발생할 수 있다. 몇몇 버그는 프로그램의 동작에 조그마한 영향을 줄 뿐이며, 오랜 시간 동안 발견되지 않고 남아 있을 수 있다. 이보다 더 심각한 버그는 프로그램의 실행이 중단되거나 강제 종료되는 문제를 일으킬 수 있고, 어떠한 버그는 보안 문제를 발생시킬 수도 있다. 예를 들어, 악의적인 사용자는 자주 발생하는 버그인 버퍼 오버플로를 사용해서 원래는 허락되지 않은 일을 할 수 있다.
버그는 다양한 형태로, 또 다양한 정도로 프로그램의 사용자들에게 불편함 등의 영향을 미칠 수 있다. 몇몇 버그들은 프로그램의 기능에 미미한 영향만 미치는데, 이 때문에 오랫동안 사용자들이 이들을 발견하지 못하는 경우도 있다. 하지만 심각한 버그들은 프로그램이 전혀 작동하지 못하는 상태가 되게 하여 사용자들에게 큰 불편을 주기도 한다. 한편, 보안 버그들은 나쁜 의도를 가진 사용자들에 의하여 악용되어 시스템의 불법적인 권한을 획득할 수 있는 수단이 되기도 한다.
역사와 사례
[편집]| “ | 나의 모든 발명의 과정이 그러했다. 첫 번째 단계는 직관이고 곧 많은 진전이 이루어진다. 그 다음에는 어려움이 나타나고, 이들이 해결될 때 즈음에서 "버그"가 나타난다. 이를 해결하기 위해서는 몇 달간의 관찰과 학습, 노동이 필요하다. 이 "버그"가 잡힌 후에야 상업적인 성공과 실패가 확실히 판가름난다. | ” |
— 토머스 에디슨, 1878년
| ||
설명할 수 없는 문제점들을 가리키기 위해 사용되는 "버그"라는 단어는 이미 오랫동안 엔지니어들의 전문 용어였으며, 컴퓨터와 컴퓨터 소프트웨어가 만들어지기 이전부터 사용되었다. 최초에는 버그가 하드웨어의 기계적인 오동작을 설명하기 위해 사용된 것으로 보인다.
버그의 폐해는 매우 심각하다. 1980년대 Therac-25 방사선 치료 기계의 제어 코드에 있었던 버그 때문에 몇몇 환자들이 목숨을 잃었다. 1996년, 유럽 스페이스 에이전시의 미화 10억 불짜리 프로토타입 아리안 5호 로켓이 발사 후 1분도 채 못 되어 폭발하고 말았는데, 이 역시 컴퓨터 프로그램의 버그 때문이었다. 1994년 6월, 로얄 에어 포스 치누크가 스코틀랜드에서 추락하여 29명의 탑승자가 사망하였다. 처음에는 파일럿의 실수로 사고원인이 결론지어졌으나, 컴퓨터 위클리지의 조사에 의하여 항공기의 엔진 제어 컴퓨터에 들어 있는 소프트웨어의 버그 때문에 발생했었을 수도 있다는 주장이 제기되었다.
일반적인 컴퓨터 버그
[편집]디버깅
[편집]
이 부분의 본문은 디버그입니다.버그를 찾아서 고치는 과정은 디버깅(영어: debugging)은 컴퓨터 프로그래밍의 주된 부분이다. 초기 컴퓨팅 선구자 모리스 윌크스는 1940년대 말에 자신의 프로그램에 남겨놓은 실수를 찾는데 자신의 남은 인생을 보내겠다는 의미로 그가 깨달은 바를 기술하였다.[1]
