본문으로 이동

소프트웨어 버그

위키백과, 우리 모두의 백과사전.
최초의 버그: 하버드 대학교가 만든 마크 II 컴퓨터의 계전기에서 발견된 나방

소프트웨어 버그(영어: software bug) 또는 줄여서 버그(bug)는 컴퓨터 소프트웨어의 결함(버그)이다. 결함이 많거나 그 정도가 심각한 컴퓨터 프로그램은 버그가 많다고 표현된다.

소프트웨어 버그의 영향은 사용자 인터페이스의 단어 철자 오류와 같은 사소한 것부터 빈번한 충돌과 같은 심각한 것까지 다양하다.

2002년 미국 상무부 국립표준기술연구소의 의뢰로 진행된 연구에 따르면, "소프트웨어 버그 또는 오류는 매우 만연하고 해로워서 미국 경제에 연간 약 590억 달러, 즉 국내총생산의 약 0.6%에 달하는 손실을 입히는 것으로 추정된다"고 결론지었다.[1]

1950년대 이후 일부 컴퓨터 시스템은 작동 중에 다양한 소프트웨어 오류를 감지하거나 자동 수정하도록 설계되어 왔다.

역사

[편집]

용어

[편집]

실수 변형(mistake metamorphism, 그리스어 meta = "변화", morph = "형태"에서 유래)이라는 용어는 소프트웨어 배포의 최종 단계에서 결함이 진화하는 것을 의미한다. 소프트웨어 개발 생명주기의 초기 단계에서 분석가가 저지른 실수가 주기의 최종 단계에서 결함으로 이어지는 과정을 실수 변형이라고 불렀다.[2]

개발 주기에서 실수가 나타나는 서로 다른 단계는 실수(mistake),[3]: 31  이상(anomaly),[3]: 10  결점(fault),[3]: 31  실패(failure),[3]: 31  오류(error),[3]: 31  예외(exception),[3]: 31  충돌(crash),[3]: 22  글리치(glitch), 버그(bug),[3]: 14  결함(defect), 사건(incident),[3]: 39  또는 부작용(side effect)으로 설명될 수 있다.

예시

[편집]

소프트웨어 버그는 재난과 연관되기도 했다.

  • Therac-25 방사선 치료 장치의 소프트웨어 버그는 1980년대 환자 사망의 직접적인 원인이 되었다.[4]
  • 1996년, 유럽 우주국의 10억 달러 규모 시제품인 아리안 5호 로켓이 발사된 지 1분도 채 되지 않아 온보드 유도 컴퓨터 프로그램의 버그로 인해 파괴되었다.[5]
  • 1994년, RAF 치누크 헬리콥터가 추락하여 29명이 사망했다. 초기에는 조종사 과실로 치부되었으나, 나중에 엔진 제어 컴퓨터(FADEC)의 소프트웨어 버그로 인해 발생한 것으로 생각되었다.[6]
  • 버그가 있는 소프트웨어는 21세기 초 영국의 우체국 스캔들을 일으켰다.[7]

논란

[편집]

소프트웨어의 동작을 설명하기 위해 버그라는 용어를 사용하는 것은 인식의 차이로 인해 때때로 논란이 된다. 일부는 버그라는 용어가 결함이 스스로 발생했다는 암시를 준다고 주장하며 이 용어를 버려야 한다고 제안한다. 대신 그것이 인간에 의해 발생했음을 더 명확하게 나타내는 결함(defect)이라는 용어를 사용할 것을 권장한다.[8]

어떤 이들은 의도적인 설계 결정을 은폐하기 위해 버그라는 용어를 사용할 수 있다고 주장한다. 2011년, 사용자의 위치를 암호화되지 않은 파일에 기록하고 저장한 일로 앨 프랭큰 미국 상원의원의 조사를 받은 후,[9] 애플은 해당 동작을 버그라고 불렀다. 그러나 민주주의와 기술 센터(CDT)의 저스틴 브룩맨은 "그들이 버그라고 부르는 것을 고치고 있어서 다행이지만, 사용자를 추적했다는 사실을 강력히 부인하는 것에는 동의할 수 없다"고 말하며 그러한 묘사에 직접적으로 이의를 제기했다.[10]

예방

[편집]
프랑스 라크루아드베르니역의 두 화면에 표시된 소프트웨어 버그로 인한 오류

소프트웨어 개발 프로세스에서 가능한 한 일찍 버그를 예방하는 것은 투자와 혁신의 목표이다.[11][12]

언어 지원

[편집]

새로운 프로그램 언어들은 기존 언어의 취약점을 바탕으로 일반적인 버그를 예방하도록 설계되는 경향이 있다. BASIC이나 C와 같은 오래된 언어에서 얻은 교훈은 C#이나 러스트와 같은 후기 언어의 설계에 반영된다.

컴파일 언어는 런타임 전, 즉 소프트웨어 개발 프로세스에서 인터프리터 언어보다 더 이른 시점에 일부 오타(철자가 틀린 식별자 등)를 감지할 수 있게 해준다.

언어에는 정적 자료형 체계, 제한된 이름공간 및 모듈식 프로그래밍과 같은 기능이 포함될 수 있다. 예를 들어, 컴파일되는 자료형 언어(C와 같은 언어)의 경우:

float num = "3";

위 코드는 구문상으로는 정확하지만, 오른쪽의 문자열을 float 변수에 할당할 수 없으므로 자료형 검사에 실패한다. 컴파일이 실패하면 개발을 재개하기 전에 이 결함을 강제로 수정해야 한다. 인터프리터 언어의 경우, 이러한 실패는 나중에 런타임이 되어서야 발생한다.

일부 언어는 성능 저하를 감수하고서라도 버그를 유발하기 쉬운 기능을 배제한다. 복잡하고 버그가 많은 코드보다 단순하고 느리지만 정확한 코드를 작성하는 것이 보통 더 낫다는 원칙 때문이다. 예를 들어, 자바는 매우 빠를 수 있지만 주의 깊게 사용하지 않으면 메모리 오염이나 세그멘테이션 오류를 일으킬 수 있는 포인터 산술을 지원하지 않는다.

일부 언어는 일반적인 버그를 예방하기 위해 런타임 오버헤드를 추가하는 기능을 포함한다. 예를 들어, 많은 언어에는 런타임 경계 검사가 포함되어 있으며 충돌 대신 경계를 벗어난 오류로부터 복구할 수 있는 방법이 있다.

기법

[편집]

스타일 가이드라인과 방어적 프로그래밍은 놓치기 쉬운 오타를 예방할 수 있다.

예를 들어, 대부분의 C 계열 언어는 명령어가 하나만 있는 경우 명령 블록 주위의 중괄호 생략을 허용한다. 다음 코드는 condition이 참인 경우에만 함수 foo를 실행한다.

if (condition)
    foo();

그러나 이 코드는 항상 foo를 실행한다.

if (condition);
   foo();

중괄호를 사용하면—비록 엄격하게 요구되지 않더라도—이러한 오류를 안정적으로 예방할 수 있다.

if (condition) {
    foo();
}

컨벤션 준수는 수동으로(코드 검토를 통해) 이루어지거나 린터와 같은 자동화된 도구를 통해 강제될 수 있다.

명세

[편집]

일부는 프로그램의 의도된 동작을 명시하는 프로그램 명세서를 작성하는 것이 버그를 예방할 수 있다고 주장한다. 그러나 다른 이들은 조합 폭발과 부정확성 문제 때문에 아주 짧은 프로그램을 제외하고는 공식적인 명세가 비현실적이라고 주장한다.

소프트웨어 테스트

[편집]

소프트웨어 테스트의 한 가지 목표는 버그를 찾는 것이다. 테스트 중의 측정은 남아 있을 가능성이 있는 버그의 수에 대한 추정치를 제공할 수 있다. 이는 제품이 더 오래 테스트되고 개발될수록 더 신뢰할 수 있게 된다.

애자일 관행

[편집]

애자일 소프트웨어 개발은 비교적 작은 변경 사항이 포함된 빈번한 소프트웨어 릴리스를 수반할 수 있다. 결함은 사용자 피드백을 통해 드러난다.

테스트 주도 개발(TDD)을 사용하면 제품 코드를 작성하는 동안 단위 테스트를 함께 작성하며, 모든 테스트가 작성되고 성공적으로 완료될 때까지 제품 코드가 완성된 것으로 간주하지 않는다.

정적 분석

[편집]

정적 코드 분석 도구는 컴파일러의 기능을 넘어 프로그램 텍스트를 검사하여 잠재적인 문제를 찾아냄으로써 개발자를 돕는다. 일반적으로 명세가 주어졌을 때 모든 프로그래밍 오류를 찾는 문제는 해결 불가능하지만(정지 문제 참조), 이러한 도구들은 인간 프로그래머가 소프트웨어를 작성할 때 특정 종류의 단순한 실수를 저지르는 경향이 있다는 사실을 이용한다.

계측

[편집]

소프트웨어가 실행되는 동안의 성능을 모니터링하는 도구들은 병목 현상과 같은 문제를 찾거나 올바른 작동을 보장하기 위해 코드에 명시적으로 내장되거나(PRINT "I AM HERE"와 같은 단순한 문장 등) 도구로 제공될 수 있다. 대부분의 시간이 특정 코드 조각에서 소요된다는 사실을 발견하는 것은 종종 놀라운 일이며, 이러한 가정의 제거는 코드를 다시 작성하게 만들 수 있다.

오픈 소스

[편집]

오픈 소스 개발은 누구든 소스 코드를 검사할 수 있게 해준다. 에릭 레이먼드가 리누스의 법칙으로 대중화한 사고 방식에 따르면, 인기 있는 오픈 소스 소프트웨어는 "보는 눈이 충분하면 모든 버그는 쉽게 드러난다"기 때문에 다른 소프트웨어보다 버그가 적거나 없을 가능성이 더 높다.[13] 그러나 이 주장은 논란이 되어 왔다. 컴퓨터 보안 전문가 엘리아스 레비(Elias Levy)는 "복잡하고 이해하기 어렵고 문서화되지 않은 소스 코드에는 취약점을 숨기기 쉽다"며, "사람들이 코드를 검토한다고 해서 그들이 그럴 자격이 있다는 뜻은 아니다"라고 썼다.[14] 오픈 소스 소프트웨어 버그의 예로는 데비안의 2008년 OpenSSL 취약점이 있다.

디버그

[편집]

디버깅은 소프트웨어 개발 생명주기의 중요한 부분이 될 수 있다. 초기 컴퓨터 선구자인 모리스 윌크스는 1940년대 후반에 "내 인생의 남은 시간 중 상당 부분을 내 프로그램의 오류를 찾는 데 보내게 될 것"임을 깨달았다고 묘사했다.[15]

일반적으로 버그를 찾는 첫 번째 단계는 버그를 안정적으로 재현하는 것이다. 문제를 재현할 수 없다면 프로그래머는 버그의 원인을 찾을 수 없으며 따라서 수정할 수도 없다.

일부 버그는 재현하기 어려운 입력에 의해 드러난다. Therac-25 방사선 장치 사망 사고의 한 원인은 기기 조작자가 치료 계획을 매우 빠르게 입력할 때만 발생하는 버그(구체적으로는 경쟁 상태)였다. 이를 할 수 있게 되기까지 며칠간의 연습이 필요했기 때문에 테스트 중이나 제조사가 재현을 시도할 때는 버그가 나타나지 않았다. 다른 버그들은 버그를 찾기 위해 디버거로 프로그램을 실행하는 등 설정이 보강될 때마다 발생을 멈추기도 하는데, 이를 하이젠버그(하이젠베르크의 불확정성 원리의 이름을 따서 익살스럽게 명명됨)라고 한다.

때때로 버그는 고립된 결함이 아니라 프로그래머 측의 사고나 계획의 오류를 나타낸다. 종종 이러한 논리 오류는 프로그램의 한 섹션을 전면적으로 점검하거나 다시 작성해야 하며, 이 과정을 리팩터링이라고 한다.

코드를 단계별로 살펴보며 실행 과정을 상상하거나 기록하는 코드 검토를 통해 버그를 재현하지 않고도 오류를 찾는 경우가 많다.

디버거라고 알려진 프로그램은 코드를 한 줄씩 실행하고 변수 값을 확인하는 등 프로그램의 내부 작동을 검사하여 프로그래머가 잘못된 코드를 찾도록 도와줄 수 있다.

디버거를 사용하는 대신, 프로그램 실행을 추적하고 값을 보기 위해 디버그 정보를 출력하는 로직을 코드에 삽입할 수 있다. 출력은 일반적으로 시스템 콘솔, 창, 로그 파일 또는 지시용 LED를 구동할 수 있는 컴퓨터 하드웨어 출력으로 전달된다.

1990년대 이후, 특히 아리안 5호 501편 참사 이후 추상 해석에 의한 정적 코드 분석과 같은 자동화된 디버깅 보조 도구에 대한 관심이 높아졌다.[16]

임베디드 시스템에서는 하드웨어를 수정하는 것보다 소프트웨어를 수정하는 것이 비용이 적게 들고 지장을 덜 주기 때문에 하드웨어 버그를 해결하기 위해 소프트웨어를 수정하는 경우가 많다.

관리

[편집]
버그 이력 예시(GNU 클래스패스 프로젝트 데이터). 새로운 버그는 처음에 미확인(unconfirmed) 상태다. 재현되면 확인됨(confirmed)으로 변경된다. 문제가 해결되면 수정됨(fixed)으로 변경된다.

버그는 문서화, 분류, 할당, 재현, 수정 및 수정된 코드의 배포와 같은 활동을 통해 관리된다.

도구는 버그 및 소프트웨어의 다른 문제들을 추적하는 데 자주 사용된다. 일반적으로 소프트웨어 개발 팀이 자신의 작업량을 추적하기 위해 사용하는 도구와 고객 서비스에서 사용자 피드백을 추적하기 위해 사용하는 도구는 서로 다르다.[17]

추적되는 항목은 종종 버그, 결함, 티켓, 이슈, 기능으로 불리거나 애자일 소프트웨어 개발의 경우 스토리 또는 에픽으로 불린다. 항목은 심각도, 우선순위 및 영향을 받는 버전 번호 등의 측면에 따라 분류된다.

때때로 트리아지라고 불리는 프로세스에서, 버그의 심각도와 우선순위 및 개발 일정과 같은 외부 요인에 근거하여 각 버그를 수정할지 여부와 시기를 결정한다. 트리아지에는 일반적으로 원인 조사가 포함되지 않는다. 트리아지는 정기적으로 발생할 수 있으며 최소한 이전 트리아지 이후의 새 버그를 검토하는 것으로 구성되며, 모든 열린 버그로 확장될 수도 있다. 참석자에는 프로젝트 관리자, 개발 관리자, 테스트 관리자, 빌드 관리자 및 기술 전문가가 포함될 수 있다.[18][19]

심각도

[편집]

심각도는 버그가 미치는 영향의 척도이다.[20] 이 영향은 데이터 손실, 재정적 손실, 영업권 하락 및 노력 낭비가 될 수 있다. 심각도 수준은 표준화되어 있지 않으며 산업 및 추적 도구와 같은 상황에 따라 다르다. 예를 들어, 비디오 게임의 충돌은 은행 서버의 충돌과는 다른 영향을 미친다. 심각도 수준의 예로는 충돌 또는 멈춤, 해결 방법 없음(사용자가 작업을 수행할 수 없음), 해결 방법 있음(사용자가 여전히 작업을 수행할 수 있음), 시각적 결함(예: 오타), 또는 문서 오류 등이 있다. 또 다른 심각도 세트의 예로는 치명적(critical), 높음(high), 낮음(low), 차단(blocker), 사소함(trivial) 등이 있다.[21] 버그의 심각도는 수정을 위한 우선순위와 동일한 범주가 될 수도 있고, 두 가지가 별도로 정량화되어 관리될 수도 있다.

제품 출시를 지연시킬 만큼 심각한 버그를 쇼스토퍼(show stopper)라고 한다.[22][23]

우선순위

[편집]

우선순위는 다른 버그와 비교하여 해당 버그를 해결하는 것의 중요성을 나타낸다. 우선순위는 1에서 5까지의 숫자이거나 치명적, 높음, 낮음, 보류(deferred)와 같은 이름일 수 있다. 우선순위는 심각도와는 다른 측면임에도 불구하고 그 수치는 심각도 등급과 유사하거나 동일할 수 있다.

우선순위는 버그의 심각도와 수정에 필요한 노력 수준의 결합일 수 있다. 심각도는 낮지만 수정하기 쉬운 버그는 수정에 훨씬 더 많은 노력이 필요한 중간 심각도의 버그보다 높은 우선순위를 가질 수 있다.

패치

[편집]

충분히 높은 우선순위의 버그는 흔히 패치라고 불리는 특별 릴리스를 정당화할 수 있다.

유지보수 릴리스

[편집]

버그 수정을 강조하는 소프트웨어 릴리스는 새로운 기능이나 다른 변경 사항을 강조하는 릴리스와 차별화하기 위해 유지보수 릴리스라고 부를 수 있다.

알려진 문제

[편집]

알려진 낮은 우선순위의 버그나 다른 문제를 포함한 채로 소프트웨어를 출시하는 것은 일반적인 관행이다. 가능한 이유로는 다음을 포함하나 이에 국한되지 않는다.

  • 마감 기한을 지켜야 하며 마감일까지 모든 버그를 수정하기에는 리소스가 부족한 경우[24]
  • 버그가 이미 차기 릴리스에서 수정되었으며 우선순위가 높지 않은 경우
  • 버그를 수정하기 위해 필요한 변경 비용이 너무 크거나 너무 많은 다른 구성 요소에 영향을 미쳐 대규모 테스트 활동이 필요한 경우
  • 일부 사용자가 기존의 버그가 있는 동작에 의존하고 있다고 의심되거나 알려진 경우. 제안된 수정 사항이 호환성을 깨뜨리는 변경을 유발할 수 있다.
  • 문제가 차기 릴리스에서 폐기될 영역에 있는 경우. 수정을 할 필요가 없다.

영향

[편집]

소프트웨어 버그가 일으킬 수 있는 손상의 양과 유형은 소프트웨어 품질에 관한 의사 결정, 프로세스 및 정책에 영향을 미친다. 유인 우주 비행, 항공, 원자력, 의료, 대중교통 또는 자동차 안전과 같은 응용 분야에서는 소프트웨어 결함이 인명 피해나 심지어 사망에 이를 잠재력이 있기 때문에, 예를 들어 온라인 쇼핑 웹사이트보다 훨씬 더 많은 조사와 품질 관리를 거치게 된다. 소프트웨어 결함이 은행이나 고객에게 심각한 재정적 손실을 입힐 잠재력이 있는 뱅킹과 같은 응용 분야에서도 품질 관리는 사진 편집 애플리케이션보다 더 중요하다.

버그로 인해 발생하는 피해 외에도, 버그를 수정하는 데 투자되는 노력으로 인해 발생하는 비용도 있다. 1978년 린츠(Lientz) 등은 프로젝트의 중간값이 개발 노력의 17%를 버그 수정에 투자한다는 것을 보여주었다.[26] 2020년 깃허브 저장소에 대한 연구에서는 중간값이 20%인 것으로 나타났다.[27]

비용

[편집]

1994년, NASA의 고더드 우주 비행 센터는 코드 1,000라인당(SLOC) 평균 오류 수를 4.5개에서 1개로 줄이는 데 성공했다.[28]

1990년의 또 다른 연구는 매우 우수한 소프트웨어 개발 프로세스가 1000 SLOC당 0.1개라는 낮은 배포 실패율을 달성할 수 있다고 보고했다.[29] 이 수치는 스티브 맥코넬의 코드 컴플릿(Code Complete)과 같은 문헌과 비행 소프트웨어 복잡성에 관한 NASA 연구에서 반복적으로 언급된다.[30][31] 일부 프로젝트는 심지어 결함 제로를 달성하기도 했는데, 63,000 SLOC로 구성된 IBM 휠라이터 타자기의 펌웨어와 500,000 SLOC의 우주왕복선 소프트웨어가 그 예이다.[29]

벤치마크

[편집]

테스트 및 디버깅에 대한 재현 가능한 연구를 돕기 위해 연구자들은 선별된 버그 벤치마크를 사용한다.

  • Siemens 벤치마크
  • ManyBugs[32]: 9개의 오픈 소스 프로그램에 있는 185개의 C 버그 벤치마크이다.
  • Defects4J[33]: 5개의 오픈 소스 프로젝트에서 추출한 341개의 자바 버그 벤치마크이다. 다양한 패치 유형을 다루는 해당 패치들이 포함되어 있다.

유형

[편집]

몇 가지 주목할 만한 버그 유형은 다음과 같다.

설계 오류

[편집]

버그는 명세에 기반한 불충분하거나 잘못된 설계로 인해 발생할 수 있다. 예를 들어, 단어 목록을 알파벳순으로 정렬하는 것이 명세인데, 기호를 고려하지 않은 설계로 인해 기호가 포함된 단어의 정렬이 잘못되는 경우 설계 버그가 발생할 수 있다.

산술

[편집]

수치 연산은 예상치 못한 출력, 느린 처리 또는 충돌을 일으킬 수 있다.[34] 이러한 버그는 반올림으로 인한 정밀도 손실, 수치적으로 불안정한 알고리즘, 산술 오버플로 및 언더플로와 같은 데이터 저장 품질에 대한 인식 부족이나, 일부 언어에서는 예외를 던지고 다른 언어에서는 NaN 또는 무한대와 같은 특별한 값을 반환하는 0으로 나누기와 같이 소프트웨어 코딩 언어별 계산 처리 방식에 대한 인식 부족으로 인해 발생할 수 있다.

제어 흐름

[편집]

제어 흐름 버그 또는 논리 오류는 오류와 함께 실패하지는 않지만, 무한 루프, 무한 재귀, 잘못된 비교 연산자 사용과 같은 조건문에서의 잘못된 비교, 그리고 오프 바이 원 오류와 같이 예상된 동작을 하지 않는 코드가 특징이다.

인터페이싱

[편집]
  • 잘못된 API 사용.
  • 잘못된 프로토콜 구현.
  • 잘못된 하드웨어 처리.
  • 특정 플랫폼에 대한 잘못된 가정.
  • 호환되지 않는 시스템. 새로운 API나 통신 프로토콜은 두 시스템이 서로 다른 버전을 사용할 때 작동하는 것처럼 보일 수 있지만, 한 버전에서 구현된 기능이 다른 버전에서 변경되거나 누락된 경우 오류가 발생할 수 있다. 지속적으로 실행되어야 하는 운영 시스템에서, 통신 산업[35]이나 인터넷[36][37][38]과 같이 대규모 업데이트를 위해 전체 시스템을 종료하는 것은 불가능할 수 있다. 이 경우 대규모 네트워크의 중단을 최소화하기 위해 대규모 시스템의 작은 세그먼트들이 개별적으로 업그레이드된다. 그러나 일부 섹션이 간과되어 업그레이드되지 않아 찾기 및 수리가 어려운 호환성 오류가 발생할 수 있다.
  • 잘못된 코드 주석(annotation).

병행성

[편집]
  • 교착 상태 – 첫 번째 작업이 끝날 때까지 두 번째 작업이 계속될 수 없지만, 동시에 두 번째 작업이 끝날 때까지 첫 번째 작업이 계속될 수 없는 상태.
  • 경쟁 상태 – 여러 개의 동시 작업이 리소스를 차지하기 위해 경쟁하는 상태.
  • 임계 구역, 상호 배제 및 기타 동시 처리 기능에서의 오류. TOCTOU(Time-of-check to time-of-use)는 보호되지 않은 임계 구역의 한 형태이다.

리소스 관리

[편집]
  • 널 포인터 역참조.
  • 초기화되지 않은 변수 사용.
  • 잘못된 자료형에 유효한 명령어 사용(이진화 십진법 등 참조).
  • 접근 위반(access violation).
  • 리소스 누수. 해제 없이 반복적인 할당으로 인해 메모리 누수나 핸들 누수와 같은 유한한 시스템 리소스가 고갈되는 현상.
  • 버퍼 오버플로. 프로그램이 할당된 저장 공간의 끝을 넘어 데이터를 저장하려고 시도하는 것. 이는 접근 위반이나 저장소 위반으로 이어질 수도 있고 그렇지 않을 수도 있다. 이들은 빈번하게 보안 버그가 된다.
  • 논리적으로는 유효하지만 스택 오버플로를 일으키는 과도한 재귀.
  • Use-after-free 오류. 시스템이 메모리를 해제한 후 해당 메모리를 참조하는 포인터를 사용하는 것.
  • 이중 해제(double free) 오류.

구문

[편집]
  • 같음 테스트 대신 할당을 수행하는 등 잘못된 토큰 사용. 예를 들어, 일부 언어에서 x=5는 x의 값을 5로 설정하는 반면, x==5는 x가 현재 5인지 아니면 다른 숫자인지 확인한다. 인터프리터 언어는 이러한 코드가 실행될 때 실패하게 한다. 컴파일 언어는 테스트가 시작되기 전에 이러한 오류를 잡아낼 수 있다.

팀워크

[편집]
  • 전파되지 않은 업데이트: 예를 들어, 프로그래머가 "myAdd"는 변경했지만 동일한 알고리즘을 사용하는 "mySubtract"를 변경하는 것을 잊은 경우. 이러한 오류는 DRY 철학을 통해 완화된다.
  • 오래되었거나 잘못된 주석: 많은 프로그래머는 주석이 코드를 정확하게 설명한다고 가정한다.
  • 문서와 제품 간의 차이.

정치에서

[편집]

"시스템의 버그" 보고서

[편집]

뉴아메리카(New America) 그룹이 운영하는 오픈 테크놀로지 인스티튜트(Open Technology Institute)[39]는 2016년 8월 "시스템의 버그(Bugs in the System)"라는 보고서를 발표하여 미국 정책 입안자들이 연구자들이 소프트웨어 버그를 식별하고 해결하는 데 도움이 되도록 개혁을 단행해야 한다고 밝혔다. 이 보고서는 "소프트웨어 취약점 발견 및 공개 분야에서의 개혁 필요성을 강조한다."[40] 보고서의 저자 중 한 명은 의회가 사이버 보안이라는 더 큰 문제를 해결하기 위해 여러 법안을 통과시켰음에도 불구하고, 사이버 소프트웨어 취약점을 해결하기에는 충분한 조치를 취하지 않았다고 말했다.[40]

정부 연구원, 기업 및 사이버 보안 전문가는 일반적으로 소프트웨어 결함을 발견하는 사람들이다. 이 보고서는 컴퓨터 범죄 및 저작권법의 개혁을 촉구한다.[40]

컴퓨터 사기 및 남용 방지법(Computer Fraud and Abuse Act), 디지털 밀레니엄 저작권법(Digital Millennium Copyright Act) 및 전자 통신 프라이버시법(Electronic Communications Privacy Act)은 보안 연구원들이 합법적인 보안 연구를 수행하는 동안 일상적으로 수행하는 행위에 대해 형사 처벌 및 민사 벌금을 부과한다고 보고서는 밝혔다.[40]

대중문화에서

[편집]
  • 비디오 게임에서 "글치"라는 용어는 때때로 소프트웨어 버그를 가리키는 데 사용된다. 그 예로 글리치이자 비공식 포켓몬 종인 미싱노가 있다.
  • 1968년 소설 2001: 스페이스 오디세이와 동명의 영화에서 우주선의 온보드 컴퓨터인 HAL 9000은 승무원 모두를 죽이려 시도한다. 후속작인 1982년 소설 2010 우주 여행과 1984년 영화 2010에서, 이 행동은 컴퓨터가 모든 정보를 완전히 공개하는 것과 비행의 진짜 목적을 승무원들에게 비밀로 유지하는 것이라는 상충하는 두 가지 목표로 프로그래밍되었기 때문에 발생한 것으로 밝혀졌다. 이 갈등은 HAL을 피해망상적으로 만들었고 결국 살인으로 이어졌다.
  • 네나(Nena)의 1983년 노래 99 Luftballons의 영어 버전에서는 "소프트웨어의 버그"로 인해 99개의 빨간 풍선 무리가 적의 핵미사일 발사로 오인되어 이에 상응하는 발사 대응을 유발하고 대참사를 초래한다.
  • 1999년 미국 코미디 영화 오피스 스페이스에서 세 명의 직원은 1센트 미만의 소수점 금액을 자신의 은행 계좌로 보내는 컴퓨터 바이러스를 사용하여 회사의 Y2K 컴퓨터 버그에 대한 우려를 (성공적이지는 못했지만) 이용하려 시도한다. 이는 살라미 기법으로 알려진 오래된 수법이다.
  • 엘렌 울먼의 2004년 소설 'The Bug'는 데이터베이스 애플리케이션에서 찾기 힘든 버그를 찾으려는 프로그래머의 시도를 다루고 있다.[41]
  • 2008년 캐나다 영화 컨트롤 알트 딜리트는 1999년 말 자신의 회사의 2000년 문제 관련 버그를 고치기 위해 고군분투하는 컴퓨터 프로그래머에 관한 영화이다.

같이 보기

[편집]

각주

[편집]
  1. ↑ “Software bugs cost US economy dear”. 2009년 6월 10일. 2009년 6월 10일에 원본 문서에서 보존된 문서. 2012년 9월 24일에 확인함.
  2. ↑ 《Testing experience : te : the magazine for professional testers》. 《Testing Experience》 (Germany: testingexperience). March 2012. 42쪽. ISSN 1866-5705. (구독 필요)
  3. 1 2 3 4 5 6 7 8 9 《610.12-1990: IEEE Standard Glossary of Software Engineering Terminology》. IEEE. 1990년 12월 31일. doi:10.1109/IEEESTD.1990.101064. ISBN 978-0-7381-0391-4.
  4. ↑ Leveson, Nancy G.; Turner, Clark S. ( 1 July 1993). 《An Investigation of the Therac-25 Accidents》. 《Computer》 26 (IEEE Computer Society). 18-41쪽. Bibcode:1993Compr..26g..18L. doi:10.1109/MC.1993.274940. eISSN 1558-0814. ISSN 0018-9162. LCCN 74648480. OCLC 2240099. S2CID 9691171.
  5. ↑ 《ARIANE 5 Flight 501 Failure Report by the Inquiry Board》. 《The European Space Agency》. Ariane 501 Inquiry Board report. 1996년 7월 23일.
  6. ↑ 사이먼 로저슨 (April 2002). 《The Chinook Helicopter Disaster》. 《IMIS Journal》 12. 1993년 9월 15일에 원본 문서에서 보존된 문서. 2024년 5월 27일에 확인함. Alt URL
  7. ↑ “Post Office scandal ruined lives, inquiry hears”. 《BBC News》. 2022년 2월 14일.
  8. ↑ Humphrey, Watts S. (1999년 4월 1일). “News at SEI – Bugs or Defects?” (PDF). 《News at SEI》. Software Engineering Institute. page 73 of 154 in PDF file. 2023년 10월 15일에 원본 문서 (PDF)에서 보존된 문서. 2025년 2월 2일에 확인함. (linked from News at SEI 1999 Archive)
  9. ↑ 그레그 카이저 (2011년 4월 21일). 《Apple faces questions from Congress about iPhone tracking》. 《컴퓨터월드》.
  10. ↑ 그레그 카이저 (2011년 4월 27일). 《Apple denies tracking iPhone users, but promises changes》. 《컴퓨터월드》.
  11. ↑ Dorota Huizinga; Adam Kolawa (September 2007). 《Automated Defect Prevention: Best Practices in Software Management》. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
  12. ↑ McDonald, Marc; Musson, Robert; Smith, Ross (2007). 《The Practical Guide to Defect Prevention》. Microsoft Press. 480쪽. ISBN 978-0-7356-2253-1.
  13. ↑ "Release Early, Release Often" 보관됨 5월 14, 2011 - 웨이백 머신, 에릭 레이먼드, 성당과 시장
  14. ↑ "Wide Open Source" 보관됨 9월 29, 2007 - 웨이백 머신, Elias Levy, SecurityFocus, April 17, 2000
  15. ↑ “Maurice Wilkes Quotes”. QuoteFancy. 2024년 4월 28일에 확인함.
  16. ↑ “PolySpace Technologies history”. 《christele.faure.pagesperso-orange.fr》. 2019년 8월 1일에 확인함.
  17. ↑ Allen, Mitch (May–June 2002). “Bug Tracking Basics: A beginner's guide to reporting and tracking defects”. 《Software Testing & Quality Engineering Magazine》. 4권 3호. 20–24쪽. 2017년 12월 19일에 확인함.
  18. ↑ Rex Black (2002). 《Managing The Testing Process》 2판. Wiley India Pvt. Limited. 139쪽. ISBN 978-8126503131. 2021년 6월 19일에 확인함.
  19. ↑ Chris Vander Mey (2012). 《Shipping Greatness - Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon》. 오라일리 미디어. 79–81쪽. ISBN 978-1449336608.
  20. ↑ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (2020년 10월 1일). 《Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems》 (영어). 《Information and Software Technology》 126. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  21. ↑ “5.3. Anatomy of a Bug”. 《bugzilla.org》. 2013년 5월 23일에 원본 문서에서 보존된 문서.
  22. ↑ Jones, Wilbur D. Jr. 편집 (1989). 〈Show stopper〉 4판 (영어). 《Glossary: defense acquisition acronyms and terms》. Fort Belvoir, Virginia: Department of Defense, Defense Systems Management College. 123쪽. hdl:2027/mdp.39015061290758?urlappend=%3Bseq=163 – Hathitrust 경유.
  23. ↑ Zachary, G. Pascal (1994). 《Show-stopper!: the breakneck race to create Windows NT and the next generation at Microsoft》 (영어). New York: The Free Press. 158쪽. ISBN 0029356717 – archive.org 경유.
  24. ↑ “The Next Generation 1996 Lexicon A to Z: Slipstream Release”. 《Next Generation》. 15호. March 1996. 41쪽.
  25. ↑ Carr, Nicholas (2018). “'It's Not a Bug, It's a Feature.' Trite – or Just Right?”. 《wired.com》.
  26. ↑ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (1978). 《Characteristics of Application Software Maintenance》. 《Communications of the ACM》 21. 466–471쪽. doi:10.1145/359511.359522. S2CID 14950091.
  27. ↑ Amit, Idan; Feitelson, Dror G. (2020). “The Corrective Commit Probability Code Quality Metric”. arXiv:2007.10912 [cs.SE].
  28. ↑ 《An Overview of the Software Engineering Laboratory》 (PDF). 《Software Engineering Laboratory Series》. December 1994. 22293쪽. Bibcode:1994ntrs.rept22293.
  29. 1 2 Cobb, Richard H.; Mills, Harlan D. (1990). 《Engineering software under statistical quality control》 (영어). 《IEEE Software》 7. 46쪽. doi:10.1109/52.60601. ISSN 1937-4194. S2CID 538311 – University of Tennessee – Harlan D. Mills Collection 경유.
  30. ↑ McConnell, Steven C. (1993). 《Code Complete》 (영어). Redmond, Washington: Microsoft Press. 611쪽. ISBN 978-1556154843 – archive.org 경유. (Cobb and Mills 1990)
  31. ↑ Gerard Holzmann (2009년 3월 5일). 《Appendix D – Software Complexity》 (PDF). 《Final Report: NASA Study on Flight Software Complexity (Daniel L. Dvorak (Ed.))》. NASA Office of Chief Engineer Technical Excellence Program.
  32. ↑ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). 《The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs》. 《IEEE Transactions on Software Engineering》 41. 1236–1256쪽. Bibcode:2015ITSEn..41.1236L. doi:10.1109/TSE.2015.2454513. ISSN 0098-5589.
  33. ↑ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). 〈Defects4J: a database of existing faults to enable controlled testing studies for Java programs〉. 《Proceedings of the 2014 International Symposium on Software Testing and Analysis – ISSTA 2014》. 437–440쪽. CiteSeerX 10.1.1.646.3086. doi:10.1145/2610384.2628055. ISBN 9781450326452. S2CID 12796895.
  34. ↑ Anthony Di Franco; Hui Guo; Cindy Rubio-González (2017년 11월 23일). 《A comprehensive study of real-world numerical bug characteristics》. 2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE. doi:10.1109/ASE.2017.8115662.
  35. ↑ Kimbler, K. (1998). 《Feature Interactions in Telecommunications and Software Systems V》. IOS Press. 8쪽. ISBN 978-90-5199-431-5.
  36. ↑ Syed, Mahbubur Rahman (2001). 《Multimedia Networking: Technology, Management and Applications: Technology, Management and Applications》. Idea Group Inc (IGI). 398쪽. ISBN 978-1-59140-005-9.
  37. ↑ Wu, Chwan-Hwa (John); Irwin, J. David (2016). 《Introduction to Computer Networks and Cybersecurity》. CRC Press. 500쪽. ISBN 978-1-4665-7214-0.
  38. ↑ RFC 1263: "TCP Extensions Considered Harmful" 인용: "새 버전의 프로토콜을 모든 호스트에 배포하는 시간은 상당히 길어질 수 있습니다(사실상 영원히). ... 이전 버전과 새 버전 사이에 미세한 불호환성이라도 있다면 혼란이 발생할 수 있습니다."
  39. ↑ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. “Bugs in the System” (PDF). 《Open Policy Institute》. 2016년 9월 21일에 원본 문서 (PDF)에서 보존된 문서. 2016년 8월 22일에 확인함.
  40. 1 2 3 4 Rozens, Tracy (2016년 8월 12일). “Cyber reforms needed to strengthen software bug discovery and disclosure: New America report – Homeland Preparedness News” (미국 영어). 2016년 8월 23일에 확인함.
  41. ↑ Ullman, Ellen (2004). 《The Bug》. Picador. ISBN 978-1-250-00249-5.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=소프트웨어_버그&oldid=41217854"