1. 개요
Bug프로그램을 실행하는 과정에서 발생하는 오류.
2. 상세
메모리 할당과 반환 또는 오버플로 등으로 인한 크래시, 구현상의 실수나 착각, 헛손질에 따른 오작동도 포함한다. 한마디로 원하던 결과가 나오지 않으면 버그. 글리치라고도 불린다. 프로그램의 실행 자체에 실패하는 오류와는 다른 개념이다.버그라는 용어는 컴퓨터가 만들어지기 이전부터 엔지니어들 사이에서 사용되어 왔던 전문 용어다. 1878년 토머스 에디슨이 언급하기도 했다. #
실제 버그가 발견된 최초의 사례이다(First actual case of bug being found.).[1]
위 사진은 1947년 9월 9일 Mark.II 컴퓨터의 회로에 나방이 들어가 합선을 일으킨 것을 코볼의 발명자인 그레이스 호퍼가 발견한 인류 역사상 최초의 버그. 이 나방은 나중에 미합중국 해군에서 여러 해 동안 전시했다고 한다. 현재는 스미스소니언 재단 소속 박물관에 소장되어 있다.
웬만한 크기 이상의 프로그램 개발 중 50%의 시간과 70%의 골치(?)는 최종 디버깅(버그를 찾아내고 없애는 작업) 작업에 따른다. 프로그램이라는 게 뚝딱뚝딱 만든다고 되는 게 절대로 아니다. 거기에다 디버깅이 새로운 버그를 만들어낼 때도 많다. 심지어 디버깅했더니 더 많은 버그가 불쑥 튀어나오는 경우도 있고[2] 디버깅하려고 손만 대면 또 멀쩡해지는 버그도 있다.[3][4] 또한, 버그를 발견해 수정한 뒤 실행해보면 다른 부분에서 버그가 걸리는 경우도 많다. 이 경우는 대규모 프로그램에서 자주 발생된다. 워낙 많은 코드들이 관여돼서 코드를 조금만 손봐도 시스템 전체에 영향을 미치는데, 이 경우에는 실사용에 무리를 주는 치명적인 버그가 아니라면 그냥 두는 경우도 많다.[5]
| 프로그래머들의 딜레마 |
프로그래머들도 버그가 없는 프로그램이 작성되면 굉장히 두려워한다. 이러한 프로그램들은 꼭 중요한 순간에 뒤통수를 때린다는 징크스가 있기 때문이다. 예를 들면 슈뢰딩버그. 그리고 이에 대한 공포를 드러내 주는 예. 버그가 분명히 있었는데 수정하려고 보니 버그가 안 보이는 상황이다. 쉽게 예를 들자면 집안에 말벌(버그)이 들어와서 벌레를 잡기 위해 창문과 문을 닫고 전기 파리채를 챙겨 왔다. 그런데 방금 전까지 책상 위에 있던 말벌(버그)이 보이지 않는다! 분명 창문을 닫고 문을 닫았기 때문에 말벌(버그)은 반드시 방 안에 있을 수밖에 없다. 이런 상황이 되면 당신은 말벌이 저절로 사라졌다고 안심하는 것이 아니라, 오히려 언제 어디서 다시 튀어나와 문제를 일으킬지 전혀 예측할 수 없기 때문에 그 말벌을 직접 죽이기 전까지는 다른 어떤 일도 마음 놓고 할 수 없게 된다. 프로그램에 버그가 없다는 것은 바로 그런 상황이라고 설명할 수 있다. 속칭 컴덕 쪽의 비유로는 컴퓨터 자가 수리 다 끝내고 심지어 컴퓨터도 아무런 문제 없이 잘 돌아가는데 분해할 때 나온 나사 한두 개가 남아있는 상황과 같은 것이다. 다른 분야도 마찬가지로 부품들을 전부 확인하고 조립했는데 남는 부품이 있는 느낌이다.
당신이 아무 불편 없이 쓴다고 생각하고 있는 프로그램들은 100% 버그를 가지고 있다. 심지어 매우 단순해 보이는 메모장조차 버그가 존재한다. bush hid the facts 참조.[6]
오죽하면 "버그가 없는 프로그램은 없다. 만약 버그가 없는 프로그램이 있다면 그것은 버그가 존재할 수 없을 정도로 단순하거나 버그가 있어도 모를 정도로 복잡한 프로그램일 것이다"라는 말도 있을 정도. 사실 버그가 존재할 수 없을 정도로 단순한 프로그램은 없다. 단순히 콘솔에 Hello, world! 한 문장만을 띄우는 프로그램을 짠다고 가정하면 5줄 안쪽으로 코딩할 수 있지만 그 5줄을 돌리기 위해 밑에 깔리는 숨겨진 코드들은 생각보다 매우 거대하다. 좀 생각을 크게 하자면, 그러니까 컴퓨터 하드웨어 단위까지 실제 프로그램 5줄 + 컴파일러, 헤더 파일 몇천 줄, 통합 개발 환경 최소 몇천 줄, 인스톨러 몇천 줄, 익스플로러 몇만 줄, OS 몇천만 줄.[7]
사실 상용 프로그램의 경우에는 주어진 기한이 있기 때문에 그 날짜 안에 프로그램이 동작하도록 만드는 것이 제1의 목적이다. 프로그램에 버그가 있고 없고는 중요하지 않다. 일단 날짜 맞추는 게 중요하다. 안 그러면 위약금이나 각종 페널티가 터진다. 그러다 보니 선개통 후완공식으로 버그가 있다는 것을 알면서도 일단 동작만 하도록 프로그램을 만든다. 보통 프로그램이 한 번에 납품되는 것은 아니므로 문제를 인식한 고객 측은 버그에 대한 피드백을 해 올 것이고, 그 시점부터 디버깅을 해서 완벽하게 해결하는 형태이다. 예를 들자면 게임에서 베타 테스트 같은 걸 운영하는 것이 있다.
그 외에 프로그램을 개발하는 단계에서는 "사용자가 A와 B란 동작을 하면 C란 결과가 나온다"와 같은 시나리오가 존재한다. 여기에는 FM동작 이외에도 각종 변칙적이거나 돌발적인 행동요소도 포함되지만 사실 모든 상황을 감안하지는 못한다. 프로그래머들이 기억해야 하는 중요한 명언 중에 하나가, '사용자들은 절대 네가 상상한 대로 프로그램을 사용하지 않는다'일 정도. 그러다 보니 상정 외의 상황에서는 미처 파악하지 못한 버그가 나오는 경우가 있다. 이런 걸 노리고 일부러 이스터 에그를 숨기기도 하지만, 프로그래머 입장에서 정말 상상도 못 한 일을 벌이는 경우에만 튀어나오는 버그도 종종 있다.
또한 프로그램 동작 메커니즘에서 발생하는 나비효과가 있다. 이건 정말 답 안 나온다. 앞에서 영향을 받은 것들이 쌓이고 쌓였다가 터지는 것이라서 A를 해결하니 B가 터져 나오고 B를 해결하니 C가 터져 나오는 형상. 더 꼬일 수도 있고 하나씩하나씩 해결했더니 원점으로 회귀하는 경우도 간혹 발생한다.
반대로 희귀하지만 버그를 그대로 놔두는 게 프로그램에 더 도움이 되어 그냥 적용시킨 사례도 있는데, 대표적인 것이 워게임: 레드 드래곤의 진형 관련 버그와 티모의 버섯이 회전하는 버그.
이것을 제거하는 작업을 디버깅이라고 한다.
현대에도 PC에 벌레가 서식해 고장의 원인이 되기도 한다. 발열로 따뜻한 본체 속으로 추위를 피해서 터를 잡기도 하고, 심지어는 알을 까기도 한다. 데스크톱은 2~3년간은 들춰볼 일이 없어서 벌레들에게 완벽한 도피처. 이런 사례는 심심찮게 발생한다. SSD를 점령한 불개미. 어느 날 갑자기 SSD 인식 오류가 생겨 열어봤더니 불개미 떼가 SSD에 들어가 알을 까고 있는 모습이 당사자로 하여금 개미를 죽입시다 개미는 나의 원수를 외치게 할 정도로 처참하다. 심한 경우 Xbox One처럼 바퀴벌레가 해처리를 틀거나, 심지어는 쥐가 기어 들어가기도 한다. 집에서 고양이를 키우는 경우 고양이가 따뜻한 PC에 자주 올라가서 고양이 털 범벅이 될 수 있다.
집 안이 깨끗하다면 큰 걱정 하지 않아도 된다.
3. 게임에서의 버그
4. 치트를 적용한 해킹 버전 게임들의 속어
정식 명칭은 아니나 꽤 많은 초등학생들에 의해 사용되는 단어. 아무래도 해킹과 버그의 개념 차이를 잘 모르기 때문에 사용되는 단어로 추정된다. 혹은 '우린 모르고 그랬어요 징징'하는 식의 면책을 위해 의도적으로 사용하는 은어일 가능성도 있다. 네이버 지식iN 등지에서 심심치 않게 게임 버그를 찾는 초딩들을 발견할 수 있다.특히 모바일 게임에서 이러한 종류의 게임이 많으며, 버그판이라고 주로 불린다. 이러한 버그판 게임 파일은 드롭박스에 많이 올라와있다. 그러나 올라온지 시간이 좀 지난 파일은 대부분 404에러가 뜬다.
그리고 버그라는 단어 하나로 기묘한 단어들을 만들어낸다. '돈버그' 등의 단어는 그나마 양호한 축에 속한다. 심하면 '크랙버그', 돈버그크랙 등 정체불명의 단어가 탄생한다.
특히 일반적인 치트 방식[8]을 사용할 수 없는 온라인 게임이나 인앱 결제가 포함된 모바일 게임들을 찾는 경우가 많다. 당연히 불법이고 발각되면 계정 정지를 먹을 가능성이 높기도 하지만 정작 제대로 동작하지 않는 경우가 많으며 와레즈 불법 공유와 마찬가지로 각종 악성코드로 뒤덮혀있을 가능성이 높다.
명절 등지에 사촌동생들이 이것을 찾느라 컴퓨터를 악성코드 투성이로 만들어 컴퓨터들을 박살내고 다닌다는 피해사례 등이 보고되고 있다.
간혹 버그쓰다 발각되면 경찰서나 벌금 낸다는 사람이 있는데 당연히 말도 안 되는 소리이고 계정 영구정지만 걸린다. 그리고 버그를 쓰는 행위는 법적 처벌이 되지 않는다. 버그 등으로 처벌받는 사례는 사용이 아닌 버그를 악용 게임사의 운영을 방해해서 영업방해 등으로 처벌받는 사례가 대부분이다. 이런 사람들은 주로 유튜브에 많은 편이다. 그러니 버그러를 까는 사람들은 이런 말을 자제하는게 좋다. 괜히 나만 개논리 펼치는 사람이라고 보기 일쑤이다. 물론 처벌을 받지 않는다고 해서 버그판을 플레이하는 것이 바람직하다는 뜻은 절대 아니다. 또한, 게임 내의 버그 등을 부당하게 이용하여 부당 수익을 내거나, 혹은 게임 내의 구조를 회복 불능 수준으로 망가뜨리는 경우에는 실제로 고발당할 수 있으니 유의할 것.
[1] 왜 "최초의 규명된 사례(First actual case)"라는 수식어구까지 붙였는가 하면, 이전까지만 해도 컴퓨터 내지는 기계가 내뱉는 오류들을 알음알음 "버그"라고는 칭해져 왔었는데 이처럼 아예 벌레 그 자체가 원인이었던 경우는 그레이스 호퍼가 최초였다.[2] 가끔은 차라리 이게 나을 때도 있다. 매우 운이 없을 경우 구글링해도 버그의 존재만 확인되고 명확한 해결책이 존재하지 않는 버그가 있는데, 기적적으로 발생 조건을 알아낸 뒤 그걸 해결하고 다수의 버그가 튀어나온다고 해도 그 대부분이 해결책이 존재하는 것들이라 맨 땅에 헤딩하는 것보다는 훨씬 편해진다.[3] 하이젠베르크의 불확정성 원리에서 따온 말. 하이젠버그의 원인은 주로 그냥 실행할 때 메모리 초기화같이 예기치 못한 동작을 막아주는 기작이 빠졌는데 디버깅을 할 때는 디버거가 알아서 그런 기작을 다 해주는 것이다. 또는 멀티코어 시스템에서 둘 이상의 코어가 같은 메모리 영역을 사용하는데 메모리에 대한 연산이 보호되어있지 않을 때 발생한다. 나는 분명 1을 썼는데 다시 값을 참조해 보니 10이 되거나 하는 경우. 디버거를 걸면 연산을 추적하는 과정에서 이러한 경우가 걸러질 때가 많다.[4] 또한, 최근의 언어들은 성능향상 및 최적화를 위해 컴파일이나 런타임 단계에서 일반적인 상식과는 다르게 작동하는 경우가 있는데, 그런 것 때문에 발생한다고도 한다.[5] 대용량, 고사양 게임의 경우 제작사 측에서 버그의 존재를 알고도 플레이에 지장이 없으면 그대로 출시하는 경우가 많다.[6] 해당 버그는 현재 수정된 상태이지만 다른 버그가 존재할 수는 있다.[7] Windows XP의 공식 소개가 "4,500만 줄의 코드로 컴파일되었다"이다.[8] 세이브 파일 조작 등