문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 버그 (문단 편집) == 상세 == 메모리 할당과 반환 또는 [[오버플로]] 등으로 인한 크래시, 구현상의 실수나 착각, 헛손질에 따른 오작동도 포함한다. 한마디로 원하던 결과가 나오지 않으면 버그. [[글리치]]라고도 불린다. 프로그램의 실행 자체에 실패하는 [[오류]]와는 다른 개념이다. 버그라는 용어는 컴퓨터가 만들어지기 이전부터 엔지니어들 사이에서 사용되어 왔던 전문 용어다. 1878년 [[토머스 에디슨]]이 언급하기도 했다. [[http://en.wikipedia.org/wiki/Software_bug#Etymology|#]] [[파일:attachment/computer_bug.jpg]] > '''실제 버그가 발견된 최초의 사례이다(First actual case of bug being found.).'''[* 왜 "최초의 규명된 사례(First actual case)"라는 수식어구까지 붙였는가 하면, 이전까지만 해도 컴퓨터 내지는 기계가 내뱉는 오류들을 알음알음 "버그"라고는 칭해져 왔었는데 이처럼 '''아예 벌레 그 자체'''가 원인이었던 경우는 그레이스 호퍼가 최초였기 때문. [[그레이스 호퍼]] 문서 참고.] 위 사진은 1945년 9월 9일 Mark.II [[컴퓨터]]의 회로에 [[나방]]이 들어가 합선을 일으킨 것을 [[코볼]]의 발명자인 [[그레이스 호퍼]]가 발견한 인류 역사상 최초의 버그. 이 나방은 나중에 [[미국 해군]]에서 여러 해 동안 전시했다고 한다. 현재는 [[스미스소니언 박물관]]이 소장 중. 웬만한 크기 이상의 프로그램 개발 중 50%의 시간과 70%의 골치(?)는 최종 디버깅(버그를 찾아내고 없애는 작업) 작업에 따른다. 프로그램이라는 게 뚝딱뚝딱 만든다고 되는 게 절대로 아니다. 거기에다 디버깅이 새로운 버그를 만들어낼 때도 많다. 심지어 디버깅했더니 더 많은 버그가 불쑥 튀어나오는 경우도 있고[* 가끔은 차라리 이게 나을 때도 있다. 매우 운이 없을 경우 구글링해도 버그의 존재만 확인되고 명확한 해결책이 존재하지 않는 버그가 있는데, 기적적으로 발생 조건을 알아낸 뒤 그걸 해결하고 다수의 버그가 튀어나온다고 해도 그 대부분이 해결책이 존재하는 것들이라 맨 땅에 헤딩하는 것보다는 훨씬 편해진다.] [[하이젠버그#s-3|디버깅하려고 손만 대면 또 멀쩡해지는 버그]]도 있다.[* 하이젠베르크의 [[불확정성 원리]]에서 따온 말. 하이젠버그의 원인은 주로 그냥 실행할 때 메모리 초기화같이 예기치 못한 동작을 막아주는 기작이 빠졌는데 디버깅을 할 때는 디버거가 알아서 그런 기작을 다 해주는 것이다. 또는 멀티코어 시스템에서 둘 이상의 코어가 같은 메모리 영역을 사용하는데 메모리에 대한 연산이 보호되어있지 않을 때 발생한다. 나는 분명 1을 썼는데 다시 값을 참조해 보니 10이 되거나 하는 경우. 디버거를 걸면 연산을 추적하는 과정에서 이러한 경우가 걸러질 때가 많다.][* 또한, 최근의 언어들은 성능향상 및 최적화를 위해 컴파일이나 런타임단계에서 일반적인 상식과는 다르게 작동하는 경우가 있는데, 그런 것 때문에 발생한다고도 한다.] 또한, 버그를 발견해 수정한 뒤 실행해보면 다른 부분에서 버그가 걸리는 경우도 많다. 이 경우는 대규모 프로그램에서 자주 발생된다. 워낙 많은 코드들이 관여돼서 코드를 조금만 손봐도 시스템 전체에 영향을 미치는데, 이 경우에는 실사용에 무리를 주는 치명적인 버그가 아니라면 그냥 두는 경우도 많다.[* 대용량, 고사양 게임의 경우 제작사 측에서 버그의 존재를 알고도 플레이에 지장이 없으면 그냥 출시하는 경우가 대표적.] ||{{{#!wiki style="margin:-5px -10px" [[파일:external/thimg.todayhumor.co.kr/102849a9864bd466b0dd1b642516278e.jpg|width=100%]]}}}|| || 프로그래머들의 고뇌 || 프로그래머들도 버그가 없는 프로그램이 작성되면 굉장히 두려워한다. 이러한 프로그램들은 꼭 중요한 순간에 뒤통수를 때린다는 징크스가 있기 때문이다. 예를 들면 '''[[슈뢰딩거의 고양이|슈뢰딩버그]]'''. [[http://comic.naver.com/webtoon/detail.nhn?titleId=403631&no=36&weekday=sun#content_image_3|그리고 이에 대한 공포를 드러내 주는 예]]. 버그가 분명히 있었는데 수정하려고 보니 버그가 안 보이는 상황이다. 쉽게 예를 들자면 집안에 말벌(버그)이 들어와서 벌레를 잡기 위해 창문과 문을 닫고 전기 파리채를 챙겨 왔다. 그런데 방금 전까지 책상 위에 있던 말벌(버그)이 보이지 않는다! 분명 창문을 닫고 문을 닫았기 때문에 말벌(버그)은 반드시 방 안에 있을 수밖에 없다. 이런 상황이 되면 당신은 말벌이 저절로 사라졌다고 안심하는 것이 아니라, 오히려 언제 어디서 다시 튀어나와 문제를 일으킬지 전혀 예측할 수 없기 때문에 그 말벌을 직접 죽이기 전까지는 다른 어떤 일도 마음 놓고 할 수 없게 된다. 프로그램에 버그가 없다는 것은 바로 그런 상황이라고 설명할 수 있다. 속칭 [[컴덕]] 쪽의 비유로는 컴퓨터 자가 수리 다 끝내고 심지어 컴퓨터도 아무런 문제 없이 잘 돌아가는데 분해할 때 나온 나사 한두 개가 남아있는 상황과 같은 것이다. 다른 분야도 마찬가지로 부품들을 전부 확인하고 조립했는데 남는 부품이 있는 느낌이다. 당신이 아무 불편 없이 쓴다고 생각하고 있는 프로그램들은 100% 버그를 가지고 있다. 심지어 매우 단순해 보이는 [[메모장]]조차 버그가 존재한다. [[bush hid the facts]] 참조.[* 해당 버그는 현재 수정된 상태이지만 다른 버그가 존재할 수는 있다.] 오죽하면 "버그가 없는 프로그램은 없다. 만약 버그가 없는 프로그램이 있다면 그것은 버그가 존재할 수 없을 정도로 단순하거나 버그가 있어도 모를 정도로 복잡한 프로그램일 것이다"라는 말도 있을 정도. 사실 버그가 존재할 수 없을 정도로 단순한 프로그램은 없다. 단순히 콘솔에 [[Hello, world!]] 한 문장만을 띄우는 프로그램을 짠다고 가정하면 5줄 안쪽으로 코딩할 수 있지만 그 5줄을 돌리기 위해 밑에 깔리는 숨겨진 코드들은 생각보다 매우 거대하다. 좀 생각을 크게 하자면, 그러니까 컴퓨터 하드웨어 단위까지 실제 프로그램 5줄 + 컴파일러, 헤더 파일 몇천 줄, [[통합 개발 환경]] 최소 몇천 줄, 인스톨러 몇천 줄, 익스플로러 몇만 줄, OS 몇천만 줄.[* [[Windows XP]]의 공식 소개가 '''"4,500만 줄의 코드로 컴파일되었다"'''이다.] 사실 상용 프로그램의 경우에는 주어진 기한이 있기 때문에 그 날짜 안에 프로그램이 동작하도록 만드는 것이 제1의 목적이다. 프로그램에 버그가 있고 없고는 중요하지 않다. 일단 날짜 맞추는 게 중요하다. 안 그러면 위약금이나 각종 페널티가 터진다. 그러다 보니 [[선개통 후완공]]식으로 버그가 있다는 것을 알면서도 일단 동작만 하도록 프로그램을 만든다. 보통 프로그램이 한 번에 납품되는 것은 아니므로 문제를 인식한 고객 측은 버그에 대한 피드백을 해 올 것이고, 그 시점부터 디버깅을 해서 완벽하게 해결하는 형태이다. 예를 들자면 게임에서 [[베타 테스트]] 같은 걸 운영하는 것이 있다. 그 외에 프로그램을 개발하는 단계에서는 "사용자가 A와 B란 동작을 하면 C란 결과가 나온다"와 같은 시나리오가 존재한다. 여기에는 FM동작 이외에도 각종 변칙적이거나 돌발적인 행동요소도 포함되지만 사실 모든 상황을 감안하지는 못한다. 프로그래머들이 기억해야 하는 중요한 명언 중에 하나가, '사용자들은 절대 네가 상상한 대로 프로그램을 사용하지 않는다'일 정도. 그러다 보니 상정 외의 상황에서는 미처 파악하지 못한 버그가 나오는 경우가 있다. 이런 걸 노리고 일부러 [[이스터 에그]]를 숨기기도 하지만, 프로그래머 입장에서 정말 상상도 못 한 일을 벌이는 경우에만 튀어나오는 버그도 종종 있다. 또한 프로그램 동작 메커니즘에서 발생하는 [[나비효과]]가 있다. 이건 정말 답 안 나온다. 앞에서 영향을 받은 것들이 쌓이고 쌓였다가 터지는 것이라서 A를 해결하니 B가 터져 나오고 B를 해결하니 C가 터져 나오는 형상. 더 꼬일 수도 있고 하나씩하나씩 해결했더니 원점으로 회귀하는 경우도 간혹 발생한다. 반대로 희귀하지만 버그를 그대로 놔두는 게 프로그램에 더 도움이 되어 그냥 적용시킨 사례도 있는데, 대표적인 것이 [[워게임: 레드 드래곤]]의 진형 관련 버그와 [[티모]]의 버섯이 회전하는 버그. 이것을 제거하는 작업을 [[디버깅]]이라고 한다. 현대에도 PC에 벌레가 서식해 고장의 원인이 되기도 한다. 발열로 따뜻한 본체 속으로 추위를 피해서 터를 잡기도 하고, 심지어는 알을 까기도 한다. 데스크톱은 2~3년간은 들춰볼 일이 없어서 벌레들에게 완벽한 도피처. 이런 사례는 심심찮게 발생한다. [[http://gall.dcinside.com/board/view/?id=pridepc_new3&no=4571563|SSD를 점령한 불개미]]. 어느 날 갑자기 SSD 인식 오류가 생겨 열어봤더니 불개미 떼가 SSD에 들어가 알을 까고 있는 모습이 당사자로 하여금 [[개미를 죽입시다 개미는 나의 원수]]를 외치게 할 정도로 처참하다. 심한 경우 [[엑원]]처럼 [[바퀴벌레]]가 [[해처리]]를 틀거나, 심지어는 [[deadmau5|쥐가 기어 들어가기도 한다.]] 집에서 고양이를 키우는 경우 고양이가 따뜻한 PC에 자주 올라가서 고양이 털 범벅이 될 수 있다. 집 안이 깨끗하다면 큰 걱정 하지 않아도 된다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기