위키원
버그
버그(bug)는 프로그램 상의 결함에 의해 소프트웨어가 오작동하는 현상이다.[1]
목차
개요
컴퓨터 기술 분야에서 버그란 컴퓨터 프로그램의 코딩 오류를 의미하는 용어이다. 프로그램 사용자가 이러한 버그를 발견하기 전에 찾아 수정하는 것을 디버깅(debugging)이라 하며, 디버깅은 프로그램의 개발 시작 단계부터 완료될 때까지 계속해서 이루어진다. 하지만 제품이 출시된 후나 베타 테스트 기간 중에도 버그는 여전히 남아있을 수 있으나 일반적으로 프로그램 개발 절차가 잘 확립되어 있고 프로그램의 설계를 잘하면 그것이 비록 수천, 수만 개의 명령문이 조합된 대형 프로그램이라 해도 버그를 최소한으로 줄일 수 있다. 버그의 어원은 1944년 하버드에서 MarkⅠ 컴퓨터로 프로그램을 개발했던 최초의 프로그래머인 그레이스 호퍼에 의해 비롯되었고, 젊은 해군장교였던 호퍼는 기술자들이 MarkⅡ 컴퓨터에서 오동작을 일으킨 벌레(모기)를 꺼낸 사건을 서술했다. 에릭 레이몬드는 그의 저서인 The New Hacker's Dictionary 에서 '그 벌레(모기)가 해군에 여러 해동안 전시되었고, 지금은 스미스소니언 박물관에 소장되어 있다'고 하였다. 이와 같이 버그라는 용어는 현대의 컴퓨터 이전의 진공관 컴퓨터 시대부터 산업적 또는 전기적 오동작을 의미하는데 사용되었고, 때로는 컴퓨터 하드웨어 문제를 지칭하는 것으로 사용되기도 한다.[2] 버그의 결과로 다양한 문제가 발생할 수 있다. 몇몇 버그는 프로그램의 동작에 조그마한 영향을 줄 뿐이며, 오랜 시간 동안 발견되지 않고 남아 있을 수 있다. 이보다 더 심각한 버그는 프로그램의 실행이 중단되거나 강제 종료되는 문제를 일으킬 수 있고, 어떠한 버그는 보안 문제를 발생시킬 수도 있다. 예를 들어, 악의적인 사용자는 자주 발생하는 버그인 버퍼 오버플로를 사용해서 원래는 허락되지 않은 일을 할 수 있다. 버그는 다양한 형태로, 또 다양한 정도로 프로그램의 사용자들에게 불편함 등의 영향을 미칠 수 있다. 몇몇 버그들은 프로그램의 기능에 미미한 영향만 미치는데, 이 때문에 오랫동안 사용자들이 이들을 발견하지 못하는 경우도 있다. 하지만 심각한 버그들은 프로그램이 전혀 작동하지 못하는 상태가 되게 하여 사용자들에게 큰 불편을 주기도 한다. 한편, 보안 버그들은 나쁜 의도를 가진 사용자들에 의하여 악용되어 시스템의 불법적인 권한을 획득할 수 있는 수단이 되기도 한다.[3]
소프트웨어 버그
- 소프트웨어 버그(software bug) : 소프트웨어가 예상하지 못한 잘못된 결과를 내거나, 오류가 발생하거나, 착오나 오작동이 발생하는 등의 문제를 뜻한다. 프로그램의 소스 코드나 설계 과정에서의 오류 때문에 발생한다.
종류
- 보어버그(Bohrbug) - 보어의 원자모형처럼 명확한 버그라고 해서 붙은 버그들로, 매우 명확한 이유로 생기는 버그지만 정작 도저히 찾아낼 수 없는 버그들을 보어버그라고 부른다. 이런 버그들은 대부분 매우매우 특수한 경우에만 등장하는 버그이기 때문에 반영구적으로 발견되지 않는 경우가 상당히 많다.
- 하이젠버그(Heisenbug) - 불확정성원리에서 이름을 따온 버그로, 특정 수단으로만 발견이 가능한, 즉 디버거의 종류나 수단에 따라서 발견되기도, 되지 않기도 하는, 심지어 모습을 바꾸는 버그들을 말한다. 대부분의 경우 메모리 부분의 코딩이 뭔가 잘못된 경우이다. 이런 버그들은 디버거가 알아서 고쳐놓고 출력해버려서 발견되지 않는 경우가 있기 때문이다.
- 만델버그(Mandelbug) - 프렉탈이란 명칭을 제시한 만델브로트의 이름을 딴 버그로, 버그를 일으키는 원인이 괴악하게 꼬여있는 것들을 말한다. 만델버그는 보어버그에 속하며 그중에서도 실용적으로 해결할 방법이 없는 경우에 해당된다.
- 슈뢰딩버그(Schrödinbug) - 누군가 소스코드를 열어보기 전까지(상자를 열어보기 전까지), 기능이 정상과 오작동을 오가며 파동하는 것을 말한다. (슈뢰딩거의 고양이가 삶과 죽음 사이에서 요동하는 것 처럼). 소스코드를 열어보면, 영구적인 버그로 상태가 고정된다. aaronaught이 만든 단어이다.
- 달 주기 버그 - 달의 주기에 따라 버그 발생율이 달라진다는 미신이 실제로 일어난 경우. Y2K 버그처럼 특정 숫자에 약한 경우가 해당된다.
- 통계학적 버그 - 한두번 실행해보는 것으로는 발견할 수 없고, 여러 번 실행해서 통계를 낼 수 있을 정도가 되면 그제서야 튀어나오는 버그를 말한다. 유사-랜덤 코드들에서 자주 발생한다.
- 카운터 버그 - 버그를 재현하려는 사람이 만든 재현 코드에서 당신이 찾은 버그이다.
- 힉스-보손 버그 - 사용자 보고서나 이벤트 로그등을 분석 해 볼 때, 낮은 확률로 존재할 것으로 추측되는 가상의 버그이다. 실존하는지 여부를 알 수 없고, 원인을 알 수 없기 때문에 이를 개발환경에서 재현하는 것은 매우 어렵거나 불가능하다.
- 성난 여자친구 버그(Mad girlfriend bug) - 뚜렷한 오동작이 있는데도 불구하고, 애플리케이션은 모든 것이 정상이라는 메시지만 보여주는 경우를 말한다.
- UFO 버그 - 고객에 의해 보고되는 버그로, 버그가 존재하지 않음을 증명하고 보여 주어도 계속해서 보고되며, 고객들은 반드시 그 버그가 존재한다고 믿는다.
- 엑스칼리버 버그 - 회사의 모든 개발자가 수정하려고 시도했었으나 아무도 성공하지 못한 버그를 말한다.
역사적 사례
인류 역사상 최초의 버그
[4]
1945년 9월 9일 Mark.II 컴퓨터의 회로에 나방이 들어가 합선을 일으킨 것을 코볼의 발명자인 그레이스 호퍼가 발견한 인류 역사상 최초의 버그이다. 이 나방은 나중에 미국 해군에서 여러 해 동안 전시했다고 한다. 현재는 스미스소니언 박물관이 소장 중이다.[4]
The Therac 25
Therac 25는 전자빔으로 피부 근처의 종양을 제거하는 Electron 모드와 X-ray로 피부 깊숙한 곳의 종양을 제거하는 X-ray 모드의 두가지 동작 모드를 지원했다. 그 전에는 각각 별도의 장비로 되어 있던 것을 하나로 합쳐 공간과 비용을 혁신적으로 개선한 제품이었다고 한다. 그런데 X-ray 모드는 강한 방사선을 사용하기 때문에 이를 균일하고 안전하게 환자에게 쪼일 수 있게 하는 턴 테이블이라고 하는 장치를 환자와 방사선 발사기 사이 위치하도록 제어해주는 것이 필요했다. 하지만 이 장치는 Electron 모드로 동작할 때는 필요하지 않았다. 때문에 모드에 따라 턴테이블을 움직여 주어야 하는데 이러한 제어를 컴퓨터 소프트웨어가 담당하고 있었다. 불행히도 이 소프트웨어에는 버그가 있어 '간혹' X-ray 모드인 상태에서 턴테이블이 제위치에 있지 않은 경우가 발생했다. 정상적인 경우라면 왼쪽의 두 그림중 하나의 상태여야 하는데 소프트웨어의 오류로 인해 오른쪽과 같은 상황에서 방사능을 발사했고, 이로 인해 문제가 완전히 밝혀져서 고쳐지기까지 무려 6건의 사고가 발생하여 3명이 사망하고 다른 3명은 심각한 방사능 후유장애에 시달려야 했다.[5]
패트리엇 미사일 방어 시스템 (1991)
이라크 스커드 미사일을 방어하기 위해 걸프전에서 처음으로 사용되었다. 많은 뉴스 기사들이 이 시스템의 성공을 알렸지만, 사우디아라비아의 테헤란에서 28명의 미국 병사를 죽인 미사일을 포함해서 몇 발의 미사일에 대한 방어는 실패하였다. 분석가들은 소프트웨어 버그가 문제라는 것을 알아냈다. 14시간이 지나면 수치를 누적하는 시스템 시계에서 작은 시간 오류가 발생하여 추적 시스템이 더는 수치를 누적하지 못하였다. 테헤란 공격에서 이 시스템은 100시간 이상 운용되고 있었다.[6]
인텔 펜티엄 부동 소수점 나눗셈 버그 (1994)
인텔의 소프트웨어 테스트 엔지니어들은 칩을 출시하기 전에 발견하였으나 인텔 측에선 중요한 버그가 아니라고 판단하고 제품을 출시하였다. 린치버그 대학교의 토마스 R. 나이슬리는 이 버그를 발견하여 인터넷에 올렸고 다른 사람들에 의해 오답을 출력하는 추가적인 경우들이 발견되었다. 이 때문에 해당 제품을 리콜하여 금전적인 손해(4억 달러 이상)도 입었으며, 인텔이라는 회사에 대한 신뢰도가 떨어졌다.[6]
아리안 5 로켓 폭발 (1996)
1996년 아리안 5 로켓이 발사된지 40초 만에 폭발하였다. 이유는 64비트로 표현된 실수 값을 16비트 정수로 변환하는 과정에서 16비트보다 큰 수가 입력되어 오버플로우가 발생하여 폭발하였다. 윗부분을 계산하는 코드를 아리안 4 로켓의 코드를 그대로 사용하여 나타난 일이다.[6]
NASA 화성 극지 착륙선 (1999)
1999년 나사(NASA)의 화성 극지 착륙선이 화성 표면에 착륙을 시도하는 도중 사라졌다. 원인을 조사하였고, 가장 근접한 이유는 단 하나의 데이터 비트를 잘못 설정하였기 때문으로 결론을 내렸으며 사람들은 이 문제가 왜 내부 테스트에서 잡히지 않았는지 놀라워 했다. 실제 NASA에서는 이 부분에 대해서 두 팀으로 나누어서 테스트하였다. 한 팀은 착륙선의 다리를 접어 내리는 절차를 테스트하였고, 또 다른 팀은 그 시점부터 착륙 절차를 테스트하였다. 첫 번째 팀은 접촉 스위치 비트가 설정되었는지 확인하지 않았다. 이 비트는 첫 번째 팀의 영역이 아니었으며, 두 번째 팀은 테스트를 시작하기 전에 항상 컴퓨터를 리셋해서 접촉 스위치 비트를 초기화했다. 각자 두 부분은 완벽하게 작동되었지만, 함께 동작했을 때는 완벽하게 작동되지 않아 결국에는 착륙선이 추락하는 결과가 나왔다.[6]
Y2K 버그 (2000)
2000년 이전에 메모리 저장 공간을 줄이기 위해 연도 YYYY 4자리 형식을 2자리 형식으로 줄이는 방식을 사용하여 1999년을 99로 표현하였으며 2000은 00으로 표현하여 1900년인지 2000년인지 알 수 없게 되었다. 2000년이 되기 전에 시스템이 갱신될 것으로 생각했으나 계속 사용했다. 잠재적인 Y2K(와이투케이) 오류를 고치기 위해서 위 방식처럼 된 프로그램을 교체하거나 갱신하는 목적으로 수 천억 달러가 소모되었을 것으로 추정된다.[6]
위험한 미리보기 (2004)
1994년 JPEG 형식의 그림에 바이러스가 포함된 채로 전자메일을 통해 신속하게 전달된다는 일이 있었으나 이는 만우절에 보내져서 단순한 장난으로 치부되었다. 이 당시 전문가들은 JPEG 이미지를 보는 것만으로 PC에 바이러스를 감염시키는 방법은 없다고 언급 하였다. 2004년 JPEG 이미지를 보는 것만으로 바이러스를 감염시킬 수 있다는 것이 증명되며 이는 시간의 흐름과 함께 기술적인 문제는 극복될 수 있다는 것을 보여준 사례이다.[6]
각주
참고자료
- hokey, 〈버그란 무엇인가 - 버그에 대한 고찰〉, 2019-03-01
- terms, 〈버그〉, 1999-06-21
- 위키백과, 〈소프트웨어 버그
- 나무위키, 〈버그〉
- 덤덤2, 〈역사상 최악의 버그 The Therac 25〉
- binple, 〈역사상 최악의 버그 소프트웨어 오류 사례〉, 2010-05-01
같이 보기
