맨위로가기

소프트웨어 버그

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 버그는 설계, 구현, 또는 운영 과정에서 발생하는 오류로, 컴퓨터 프로그램의 예상치 못한 동작이나 오작동을 유발한다. '버그'라는 용어는 기술적인 문제점을 지칭하는 데 오랫동안 사용되었으며, 에이다 러브레이스가 계산 오류의 위험성을 언급한 1842년 메모나, 그레이스 호퍼가 발견한 나방에서 유래된 일화처럼 소프트웨어 개발 이전부터 존재했다. 버그는 논리적 오류, 오타, 실행 환경 문제 등 다양한 원인으로 발생하며, 무한 루프, 데이터 손실, 시스템 충돌과 같은 심각한 결과를 초래할 수 있다. 소프트웨어 개발 과정에서 버그를 예방하기 위해 테스트, 정적 분석, 코드 검토, 그리고 최신 프로그래밍 언어의 기능과 같은 다양한 기법이 사용되며, 버그 관리 시스템을 통해 버그의 문서화, 분류, 수정 및 관리가 이루어진다. 버그는 심각도와 우선순위에 따라 처리되며, 패치 및 유지보수 릴리스를 통해 수정된다.

더 읽어볼만한 페이지

  • 소프트웨어 버그 - 교착 상태
    교착 상태는 둘 이상의 프로세스가 자원을 점유하고 서로의 자원을 요청하여 더 이상 진행할 수 없는 상태를 의미하며, 상호 배제, 점유 대기, 비선점, 순환 대기 네 가지 조건이 모두 충족되어야 발생하고, 운영 체제는 이를 예방, 회피, 무시, 발견하는 방법으로 관리한다.
  • 소프트웨어 버그 - 글리치
    글리치는 예기치 않은 오작동이나 오류를 뜻하며, 전자 공학, 컴퓨터, 비디오 게임, 텔레비전 방송, 대중문화 등 다양한 분야에서 기능 실패, 오류, 그래픽 및 사운드 문제, 신호 오류 등의 이상 현상을 포괄적으로 지칭하는 용어이다.
소프트웨어 버그
소프트웨어 버그
1869년 잡지
1869년 잡지 "Every Saturday"에 실린 삽화, "장애 - 우리는 우리 기계에 적절한 시기에 나타나지 않는 장애를 그렇게 부른다."
개요
정의컴퓨터 프로그램이나 시스템의 설계 또는 구현상의 결함
영향예상치 못한 동작, 오류, 충돌 등 다양한 문제 발생 가능
비용막대한 경제적 손실 초래 가능 http://www.nist.gov/public_affairs/releases/n02-10.htm
원인
일반적인 원인코딩 오류
설계 결함
요구사항 불충분
테스트 부족
부적절한 유지보수
유형
메모리 누수프로그램이 더 이상 필요하지 않은 메모리를 해제하지 않아 시스템 성능 저하 또는 충돌을 일으키는 현상
버퍼 오버플로프로그램이 버퍼에 할당된 것보다 더 많은 데이터를 쓰려고 할 때 발생
논리 오류코드의 논리적인 결함으로 인해 프로그램이 예상대로 작동하지 않는 현상
구문 오류프로그래밍 언어의 문법 규칙을 위반하는 오류
경쟁 조건여러 스레드가 동시에 동일한 데이터에 접근하려고 할 때 발생하는 문제
산술 오류0으로 나누는 것과 같은 잘못된 산술 연산으로 인해 발생하는 오류
디버깅
디버깅버그를 찾고 수정하는 과정
디버거디버깅을 지원하는 소프트웨어 도구
예방
코딩 표준 준수일관성 있고 오류 없는 코드를 작성하기 위해 미리 정의된 코딩 규칙을 따름
코드 검토다른 개발자가 코드를 검토하여 잠재적인 버그를 식별
단위 테스트개별 코드 모듈을 테스트하여 예상대로 작동하는지 확인
통합 테스트여러 코드 모듈을 함께 테스트하여 상호 작용이 올바르게 작동하는지 확인
정적 분석코드를 실행하지 않고 잠재적인 버그를 식별하는 데 사용되는 기술
동적 분석코드를 실행하는 동안 버그를 식별하는 데 사용되는 기술
관련 용어
결함 (Defect)소프트웨어의 결함 또는 문제점을 포괄적으로 지칭하는 용어
오류 (Error)사람의 실수로 인해 발생하는 문제
실패 (Failure)소프트웨어가 예상대로 작동하지 않는 현상
취약점 (Vulnerability)공격자가 악용할 수 있는 소프트웨어의 약점
참고
같이 보기컴파일러
디버거
프로파일러
GUI 디자이너
통합 개발 환경
기타
관련 링크버그 보고 (위키백과)
Bug reports (Wikipedia)

2. 역사

"버그"라는 용어는 컴퓨터와 소프트웨어가 만들어지기 이전부터 엔지니어들 사이에서 사용되던 용어였다. 토머스 에디슨은 1878년에 자신의 발명 과정에서 발생하는 문제점을 "버그"라고 표현했다[38]。

컴퓨터 소프트웨어 오류의 개념은 찰스 배비지의 해석 기관 프로그래밍을 담당했던 에이다 러브레이스까지 거슬러 올라간다. 에이다 러브레이스는 1842년에 남긴 메모에서, 계산 절차를 나타내는 카드의 잘못된 삽입으로 인해 잘못된 계산 결과가 얻어질 위험성을 시사했다.

그레이스 호퍼가 프로젝트에서 일할 때 릴레이 사이에 끼어있는 나방을 발견하고, 이것을 작업 일지에 테이프로 붙여 "진짜 벌레가 '버그'로 발견된 첫 번째 예"라고 기록했다[39][40][41][42][43]。

3. 원인과 영향

소프트웨어 버그는 프로그래밍, 설계, 구현 등 다양한 단계에서 발생할 수 있다. 논리적인 버그는 프로그램 설계 과정에서 발생하며, 무한 루프나 계산 오류 등을 일으킨다. 오기(誤記)에 의한 버그는 프로그램 구현 과정에서 발생하며, 존재하지 않는 프로그램 참조, 의도한 범위를 초과한 계산 결과, 수치 계산 오류 등을 일으킨다.

운영 체제(OS), 장치 드라이버, 가상 머신 등의 실행 환경이나, 컴파일러, 라이브러리, 애플리케이션 프레임워크 등의 개발 환경에 버그가 포함되어 애플리케이션 소프트웨어에 버그가 발생하는 경우도 있다. 2000년 문제처럼, 소프트웨어가 원래 예측된 수명을 넘어 운영되어 사양이 버그가 되는 환경 의존적인 버그도 있다.

버그는 심각한 피해를 야기할 수 있다. 일례로 1980년대 Therac-25 방사선 치료 기계의 제어 코드에 있던 버그 때문에 몇몇 환자들이 목숨을 잃었다.[1]

3. 1. 일반적인 컴퓨터 버그

3. 2. 버그의 폐해

1980년대 Therac-25 방사선 치료 기계의 제어 코드에 있던 버그 때문에 몇몇 환자들이 목숨을 잃었다.[1] 1996년, 유럽 스페이스 에이전시의 10억달러짜리 프로토타입 아리안 5호 로켓이 발사 후 1분도 채 못 되어 폭발했는데, 이 역시 컴퓨터 프로그램의 버그 때문이었다.[1] 1994년 6월, 로얄 에어 포스 치누크가 스코틀랜드에서 추락하여 29명의 탑승자가 사망하였다.[1] 처음에는 파일럿의 실수로 사고 원인이 결론지어졌으나, 컴퓨터 위클리지의 조사에 의하여 항공기의 엔진 제어 컴퓨터에 들어 있는 소프트웨어의 버그 때문에 발생했을 수도 있다는 주장이 제기되었다.[1]

4. 용어

"버그"라는 단어는 컴퓨터와 컴퓨터 소프트웨어가 만들어지기 이전부터 엔지니어들이 설명할 수 없는 문제점들을 가리키는 전문 용어로 오랫동안 사용되었다. 최초에는 하드웨어의 기계적인 오동작을 설명하기 위해 사용된 것으로 보인다. 1878년 토머스 에디슨은 동료에게 보낸 편지에서 기계의 고장을 "버그"라고 불렀으며[38], 제2차 세계 대전 중에는 레이더의 고장을 버그라고 불렀다는 기록이 남아 있다.

''오류 변형''(그리스어 ''meta'' = "변화", ''morph'' = "형태")은 소프트웨어 배포 최종 단계에서 결함의 진화를 의미한다. 소프트웨어 개발 수명 주기 초기에 분석가가 저지른 ''실수''가 수명 주기 최종 단계에서 ''결함''으로 이어지는 변환을 ''오류 변형''이라고 한다.[2]

개발 주기에서 오류의 다양한 단계는 실수,[3] 이상,[3] 결함,[3] 고장,[3] 오류,[3] 예외,[3] 충돌,[3] 글리치, 버그,[3] 결함, 사고,[3] 또는 부작용으로 설명될 수 있다.

컴퓨터 소프트웨어에 오류가 들어가는 개념은 찰스 배비지의 해석 기관까지 거슬러 올라갈 정도로 오래되었다. 1842년 해석 기관의 프로그래밍을 담당한 에이다 러브레이스는 계산 절차를 나타내는 카드의 잘못된 삽입으로 인해 잘못된 계산 결과가 얻어질 위험성을 메모에서 시사했다.

그레이스 호퍼가 프로젝트에서 일할 때, 고장난 Mark II를 조사하던 중 릴레이 사이에 나방이 끼어 있는 것을 발견했다는 이야기가 있다.[39] 그녀는 이것을 작업 일지에 테이프로 붙여 "진짜 벌레가 '버그'로 발견된 첫 번째 예"라고 적어 남겼다.[40][41][42][43] 이 일지는 미국 해군 역사 박물관에 보관되어 있다. 호퍼는 1984년 『타임』지와의 인터뷰에서 "그때 이후로, 컴퓨터에 뭔가 문제가 있으면 거기에 버그가 있다고 말하게 되었다"라고 말했다.

윌리엄 셰익스피어의 『헨리 4세』에서 혐오스러운 것이라는 의미로 사용된 "버그"라는 단어에서 유래했다는 설도 있다. 프로그램상의 결함을 벌레에 비유하여 부르게 되었다는 설도 있지만, 이것은 오류로 여겨진다. 현재 미국의 구어에서 버그는 컴퓨터 버그나 벌레의 의미 외에도 동사로 "사람을 괴롭히다, 짜증나게 하다"라는 의미로 자주 사용된다.

5. 논란

소프트웨어의 동작을 설명하기 위해 ''버그''라는 용어를 사용하는 것은 인식 때문에 논쟁의 여지가 있다. 일부에서는 해당 용어를 폐기하고 ''결함'' 또는 ''오류''로 대체해야 한다고 주장한다.

일부에서는 ''버그''가 결함이 저절로 발생했다는 의미를 내포하며, 인간에 의해 발생했다는 점을 더 명확하게 시사하는 ''결함''을 대신 사용할 것을 주장한다.[4]

일부에서는 ''버그''가 의도적인 설계 결정을 은폐하는 데 사용될 수 있다고 주장한다. 2011년, 알 프랭컨 미국 상원 의원으로부터 암호화되지 않은 파일에 사용자의 위치를 기록하고 저장하는 문제로 비판을 받은 후,[5] 애플은 해당 동작을 버그라고 칭했다. 그러나 민주주의 기술 센터의 저스틴 브룩만은 "그들이 버그라고 부르는 문제를 수정하게 되어 기쁘지만, 그들이 사용자를 추적한다는 것을 강력하게 부인하는 것은 받아들일 수 없습니다."라고 말하며 이와 같은 묘사에 직접적으로 반박했다.[6]

6. 예방

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

일반적으로 소프트웨어 테스트를 실시하여 소프트웨어가 사양대로 정상적으로 동작하는지 확인한다. 그 과정에서 버그가 발견되면 소프트웨어를 수정하고 다시 테스트를 실시하여 사양대로 정상적으로 동작하도록 완성한다.

그러나 소프트웨어에 '버그가 존재한다'는 것은 특정 절차에 의해 재현하기만 하면 되지만, "소프트웨어에 '버그가 절대로 존재하지 않는다'는 것을 입증하는 방법"은 수학적으로 존재할 수 없다. 어느 정도 복잡성을 가진 프로그램에서 버그의 수를 0에 가깝게 하는 것 이상은 불가능하다. 소프트웨어 테스트에서 알려진 버그를 모두 제거하더라도, 다른 버그가 전혀 존재하지 않는다는 것을 의미하지는 않는다.

에츠허르 데이크스트라는 "프로그램 테스트는 버그가 존재한다는 것을 나타내는 데는 매우 효과적이지만, 버그가 존재하지 않는다는 것을 나타낼 수는 없다"라는 격언을 남겼다.

최근의 OS 등 방대한 프로그래밍을 필요로 하는 소프트웨어에는 "버그가 없는 소프트웨어는 없다"고 한다. 모든 버그를 제거한 소프트웨어를 만들려면 개발, 디버깅, 테스트, 릴리스까지 막대한 시간과 비용이 소요되어 개발 비용을 회수할 수 없게 된다. 따라서 대부분의 소프트웨어 제조업체는 어느 정도의 버그가 남아 있더라도, 치명적인 문제나 주요 기능에 영향을 주지 않고 다른 회피책이 있다면, 알려진 문제점으로 사용자에게 고지한 후 릴리스하기도 한다.

예를 들어, 은행의 온라인 시스템(계정계 시스템)은 사회 기반을 지탱하는 중요한 시스템이지만, 1년에 몇 차례 다운되는 정도가 기준이 된다. 그 이상의 품질을 확보하는 것보다 문제가 발생하는 시점에서 대처하는 것이 비용 효과 측면에서 더 유리하다고 판단되기 때문이다.

출하 후에는 개발사가 예상하지 못한 조작을 했을 때 버그가 발견되는 경우가 많다. 제작사의 프로그래머나 테스터는 전문가로서의 지식과 경험이 있어, 무의식 중에 위험하거나 부하가 걸리는 조작을 피하는 경향이 있다. 반대로 예상 밖의 조작으로 발생하는 버그는 발견하기 어렵다. 이러한 버그는 전문 지식이 없는 일반 사용자가 사용함으로써 발견되는 경우도 많다.

최근에는 버그가 남아 있다는 전제하에, 최신 기능이나 수정된 기능을 탑재한 소프트웨어를 알파 버전이나 베타 버전으로 일반 사용자에게 사용하게 하고, 보고된 버그를 정식 버전까지 수정하는 방법도 자주 사용된다. 특히 보안 취약점이나 치명적인 버그 발견자에게 포상금을 지급하는 벤더도 있다.[45] 게임 제품 등에서는 아마추어 일반인에게 시험 삼아 사용하게 하여 버그를 발견하는 전문적인 직업도 있다.

또한, 최근에는 원래 예상하지 않은 동작이지만, 기본 동작에 영향이 없는 경우 "사양"으로 간주하는 경우도 있다.

버그 수정이나 기능 추가로 인해 새로운 버그가 생기는 것을 방지하려면, 기존 기능이 사양대로 정상적으로 동작하는지 확인하기 위한 단위 테스트를 자동화하고 회귀 테스트를 자주 하는 것이 중요하다. 이 개발 기법은 테스트 주도 개발이라고 불리며, 리팩토링 및 애자일 소프트웨어 개발의 핵심이다.

AI의 발달에 따라, 프로그래머가 작성하는 코드를 AI가 감시하여 버그로 이어질 가능성이 있는 코드를 작성하면 경고를 주어 버그 발생을 미연에 방지하는 방법도 있다. 다만, 대량의 학습 데이터와 머신 파워가 필요하다는 단점이 있다.[46]

소프트웨어 버그를 발생시키지 않는 가장 좋은 방법은 처음부터 버그가 발생하기 어려운 개발을 염두에 두는 것이다. 버그가 발생하기 어려운 환경에서는 공수에 여유가 생길 뿐만 아니라, 소프트웨어 자체의 성능도 좋아지기 쉽다. 올바른 환경을 추구하는 것은 매우 중요한 문제이다.

어떤 방법론을 따르면 개발 과정에 문제가 생기지 않는지, 안전한 프로그램을 작성하려면 어떤 언어를 사용해야 하는지, 적절한 인원 배치와 소통은 어떻게 이루어져야 하는지 등, 이러한 지견을 다루는 분야를 소프트웨어 공학이라고 한다.

6. 1. 언어 지원

최신 프로그래밍 언어는 BASIC, C와 같은 이전 언어의 취약점을 기반으로 일반적인 버그를 예방하도록 설계되었다. C#, Rust와 같은 언어는 이러한 교훈을 바탕으로 설계되었다.

이러한 언어들은 정적 타입 시스템, 제한된 네임스페이스, 모듈 프로그래밍과 같은 기능을 포함한다. 예를 들어, 타입이 지정된 컴파일된 언어(예: C)에서 다음과 같은 코드는 타입 검사에 실패한다.

```text

float num = "3";

```

이는 문자열을 float 변수에 할당할 수 없기 때문이다. 컴파일에 실패하므로 개발 진행을 재개하기 전에 이 결함을 수정해야 한다. 인터프리터 언어의 경우 런타임 시점에 오류가 발생한다.

일부 언어는 더 느린 성능을 희생하여 버그를 쉽게 유발하는 기능을 제외한다. 예를 들어, Java는 포인터 산술 연산을 지원하지 않는데, 이는 일반적으로 빠르지만 위험하다고 간주되며 주요 버그를 일으키기 쉽다.

일부 언어는 런타임 오버헤드를 추가하여 일부 버그를 방지하는 기능을 포함한다. 예를 들어, 많은 언어는 런타임 범위 검사를 포함하고 충돌하는 대신 범위 밖의 조건을 처리하는 방법을 포함한다.

컴파일된 언어는 인터프리터 언어보다 소프트웨어 개발 프로세스에서 더 이른 런타임 전에 오타(예: 오타가 있는 식별자)를 감지할 수 있다.[44]

6. 2. 기법

프로그래밍 스타일과 방어적 프로그래밍 같은 기법은 오타를 방지하는 데 도움이 된다.[44] 예를 들어, 코드에서 비교적 사소한 오타로 인해 버그가 발생할 수 있다.

```

if (condition) foo();

```

위 코드는 `condition`이 참일 경우에만 함수 `foo`를 실행해야 하지만, 아래 코드는 항상 `foo`를 실행한다.

```

if (condition); foo();

```

이러한 문제를 방지하기 위해 한 줄만 있는 경우에도 블록에 중괄호를 사용하는 규칙을 적용할 수 있다.

```

if (condition) {

foo();

}

```

이러한 규칙은 코드 검토와 같이 수동으로 적용하거나 자동화된 도구를 통해 적용할 수 있다.[44]

6. 3. 명세

프로그램의 동작을 명시하는 프로그램 명세를 작성하면 버그를 예방할 수 있다는 주장이 있다.

조합 폭발과 불확정성 문제 때문에 형식적 명세는 아주 짧은 프로그램을 제외하고는 실용적이지 않다는 반론도 있다.[44]

6. 4. 소프트웨어 테스팅

소프트웨어 테스팅의 한 가지 목표는 버그를 찾는 것이다. 테스팅 중의 측정은 남아 있을 가능성이 있는 버그의 수에 대한 추정치를 제공할 수 있다. 제품이 더 오래 테스트되고 개발될수록 더 신뢰할 수 있게 된다. 일반적으로 소프트웨어가 사양대로 정상적으로 동작하는지 확인하는 소프트웨어 테스트를 실시하고, 그 과정에서 버그가 발견되면 소프트웨어를 수정하고 다시 테스트를 실시하여 사양대로 정상적으로 동작하도록 완성한다.

에츠허르 데이크스트라는 "프로그램 테스트는 버그가 존재한다는 것을 나타내는 데는 매우 효과적이지만, 버그가 존재하지 않는다는 것을 나타낼 수는 없다"라는 격언을 남겼다.[44]

모든 버그를 완전히 제거한 소프트웨어를 만들려면 제품의 개발, 디버깅, 테스트부터 릴리스까지 방대한 시간과 비용이 들게 되어 개발 비용을 회수할 수 없게 된다. 이 때문에 소프트웨어 제조업체의 대부분은 어느 정도의 버그가 남아 있더라도, 치명적인 문제나 주요 기능에 대한 영향이 없고, 다른 회피책이 있는 등 예상 범위 내의 버그라면, 알려진 문제점으로 사용자에게 고지한 후 릴리스하기도 한다.

출하 후에는 개발사가 예상하거나 고려하지 않은 조작을 했을 때 버그가 발견되는 경우가 많다. 이러한 버그는 전문 지식이 없는 일반 사용자가 사용함으로써 발견되는 경우도 적지 않다.

최근에는 버그가 남아 있다는 것을 전제로 한 다음, 최신 기능이나 수정한 기능을 탑재한 소프트웨어를 알파 버전이나 베타 버전으로 일반 사용자에게 사용해보고, 보고된 버그를 정식 버전까지 수정하는 수법도 자주 사용된다. 특히 보안상의 취약점이나 치명적인 버그의 발견자에게 포상금을 지급하는 벤더도 있다.[45]

버그 수정이나 기능 추가로 인해 소프트웨어에 새로운 버그가 혼입되는 것을 방지하기 위해서는, 기존 기능이 사양대로 정상적으로 동작하는 것을 보증하기 위한 단위 테스트를 자동화하여 회귀 테스트의 기회를 늘리는 것이 중요하다. 이 개발 기법은 테스트 주도 개발이라고 불리며, 리팩토링 및 애자일 소프트웨어 개발의 핵심이 되고 있다.

AI의 발달에 따라, 프로그래머가 작성하는 코드를 AI가 감시하여 버그로 이어질 것 같은 코드를 작성하면 경고를 주고 버그의 발생을 미연에 방지하는 수법도 있다.[46]

6. 5. 애자일 개발 방식

애자일 소프트웨어 개발은 비교적 작은 변경 사항으로 소프트웨어를 자주 릴리스하는 것을 포함하며, 사용자 피드백을 통해 결함을 발견한다. 테스트 주도 개발(TDD)에서는 단위 테스트를 프로덕션 코드를 작성하는 동안 함께 작성하며, 모든 테스트가 성공적으로 완료될 때까지 프로덕션 코드는 완료된 것으로 간주되지 않는다. 이러한 개발 기법은 리팩토링 및 애자일 소프트웨어 개발의 핵심이다.[46]

6. 6. 정적 분석

정적 코드 분석 도구는 컴파일러의 범위를 넘어 프로그램 텍스트를 검사하여 잠재적인 문제를 발견함으로써 개발자를 돕는다. 일반적으로 사양에 따라 모든 프로그래밍 오류를 찾는 문제는 해결할 수 없지만(정지 문제 참조), 이러한 도구는 인간 프로그래머가 소프트웨어를 작성할 때 특정 종류의 단순한 실수를 자주 범한다는 사실을 이용한다.[44]

6. 7. 계측

소프트웨어의 실행 성능을 모니터링하는 도구는 병목 현상과 같은 문제를 찾아내거나 올바른 작동을 보장하기 위해 코드에 명시적으로 내장될 수 있다. 코드의 어느 부분이 가장 많은 시간을 소모하는지 발견하는 것은 종종 놀라운 일이며, 이러한 가정이 제거되면 코드를 다시 작성하게 될 수도 있다.[44]

6. 8. 오픈 소스

오픈 소스 개발은 누구나 소스 코드를 검토할 수 있게 해준다. 에릭 S. 레이먼드가 리누스의 법칙으로 널리 알린 한 학설에 따르면, 대중적인 오픈 소스 소프트웨어는 다른 소프트웨어보다 버그가 적거나 없을 가능성이 더 높은데, "충분한 수의 눈이 주어진다면 모든 버그는 얕다"는 것이다.[9] 하지만 이 주장은 논쟁의 대상이 되어 왔다. 컴퓨터 보안 전문가인 일라이어스 레비는 "복잡하고, 잘 이해되지 않으며, 문서화되지 않은 소스 코드에서는 취약점을 숨기기 쉽다"며, "사람들이 코드를 검토하더라도, 그들이 그렇게 할 자격이 있다는 것을 의미하지는 않는다"고 썼다.[10] 오픈 소스 소프트웨어 버그의 한 예로는 데비안의 2008 OpenSSL 취약점이 있었다.

7. 디버깅

컴퓨터 프로그래밍에서 버그를 찾아서 고치는 과정인 디버깅(debugging영어)은 매우 중요한 부분이다. 초기 컴퓨팅 선구자 모리스 윌크스는 1940년대 말에 자신의 프로그램에 있는 오류를 찾는 데 남은 인생을 보내겠다는 의미로 자신의 깨달음을 기술했다.[49]

디버거는 프로그래머가 코드 한 줄씩 실행하고 변수 값을 확인하는 등 프로그램의 내부 작동을 검사하여 결함 있는 코드를 찾는 데 도움을 주는 프로그램이다. 디버거를 사용하는 대신, 프로그램 실행을 추적하고 값을 보기 위해 디버그 정보를 출력하는 로직으로 코드를 계측할 수도 있다.

일부 버그는 디버거로 프로그램을 실행하는 것과 같이 버그를 찾는 데 도움이 되도록 설정을 보강할 때마다 발생을 멈추는 경우가 있는데, 이를 ''하이젠버그 버그''라고 한다.

8. 관리

버그는 문서화, 분류, 할당, 재현, 수정 및 수정된 코드 릴리스와 같은 활동을 통해 관리된다. 프로그래밍 도구는 소프트웨어의 버그 및 기타 문제를 추적하는 데 사용된다. 일반적으로 소프트웨어 개발팀은 버그 추적 시스템을 사용하며, 이는 고객 서비스가 이슈 추적 시스템을 통해 사용자 피드백을 추적하는 것과는 다른 도구이다.[13]

추적되는 항목은 '버그', '결함', '티켓', '이슈', '기능' 또는 애자일 소프트웨어 개발의 경우 '스토리'나 '에픽'이라고 불린다. 이러한 항목은 심각도, 우선순위 및 버전 번호와 같은 측면별로 분류된다.

트리아지는 버그의 심각도와 우선순위, 개발 일정과 같은 외부 요인을 고려하여 버그를 수정할지 여부와 시기를 결정하는 프로세스이다. 트리아지는 정기적으로 발생하며, 이전 트리아지 이후의 새로운 버그와 모든 열린 버그를 검토한다. 참석자는 프로젝트 관리자, 개발 관리자, 테스트 관리자, 빌드 관리자 및 기술 전문가가 될 수 있다.[14][15]

최근 소프트웨어 개발에서 버그 수정은 중요한 작업으로 여겨진다. 버그를 빠짐없이 수정하고 재발을 방지하기 위해서는 발견 일시, 발견자, 재현 방법, 수정 담당자, 수정 이력, 수정 방법, 중요도, 테스트 상황 등 많은 정보를 기록하고 관리해야 한다. 개발 과정에서 수천 개의 버그가 발생하고 다수의 테스트 담당자와 수정 담당자가 관여한다는 점을 고려하면, 기존의 파일 수준 관리로는 한계가 있다. 이러한 배경에서 버그 관리 시스템(버그 추적 시스템, '''BTS'''[47])이 등장했다.

버그 관리 시스템은 웹 서버에서 작동하며, 웹 브라우저를 통해 접속할 수 있다. 전자 메일과 연동하여 수정 시 테스트 담당자나 버그 보고자에게 메일을 전송하는 경우도 있다.

주요 버그 관리 시스템으로는 Bugzilla와 影舞 등이 있으며, 웹 서버를 필요로 하지 않는 P2P 아키텍처 기반의 버그 관리 시스템인 [http://www.valtech.jp/papilio.htm Papilio]와 같은 것도 등장했다.

버그 관리 시스템은 버전 관리 시스템과 마찬가지로 소프트웨어를 개발하는 데 필수적인 도구가 되어가고 있다.

8. 1. 심각도

심각도는 버그가 미치는 영향의 정도를 나타낸다.[16] 이러한 영향에는 데이터 손실, 금전적 손실, 신뢰도 하락, 노력 낭비 등이 있을 수 있다. 심각도 수준은 표준화되어 있지 않으며, 산업 및 추적 도구와 같은 맥락에 따라 다르다. 예를 들어, 비디오 게임의 충돌은 은행 서버의 충돌과 다른 영향을 미친다. 심각도 수준의 예로는 '충돌 또는 멈춤', '해결 방법 없음'(사용자가 작업을 완료할 수 없음), '해결 방법 있음'(사용자가 여전히 작업을 완료할 수 있음), '시각적 결함'(예: 오타), '문서 오류' 등이 있다. 또 다른 심각도 예시로는 '치명적', '높음', '낮음', '블로커', '사소함'이 있다.[17] 버그의 심각도는 수정 우선순위와 별개의 범주일 수 있으며, 두 가지 모두 정량화되고 별도로 관리될 수 있다.

8. 2. 우선순위

우선순위는 다른 버그와 비교하여 해당 버그를 해결하는 것이 얼마나 중요한지를 나타낸다. 우선순위는 1부터 5까지의 숫자나 '치명적', '높음', '낮음', '보류'와 같은 이름으로 지정할 수 있다. 우선순위는 심각도와 비슷하거나 같을 수 있지만, 다른 측면을 가진다.

우선순위는 버그의 심각도와 수정하는 데 드는 노력의 정도를 함께 고려하여 결정될 수 있다. 심각도가 낮더라도 수정하기 쉬운 버그는, 수정하는 데 훨씬 더 많은 노력이 필요한 중간 정도의 심각도를 가진 버그보다 우선순위가 더 높을 수 있다.

8. 3. 패치

충분히 우선순위가 높은 버그는 특별 릴리스를 통해 수정될 수 있는데, 이를 패치라고 부른다.[44] 소비자용 애플리케이션 소프트웨어는 버전 관리 시스템을 통해 버그 수정이나 기능 추가가 이루어졌음을 나타낸다. 제조사는 이러한 수정 사항을 정기적으로 수정 프로그램 형태로 제공한다.

마이크로소프트(Microsoft)는 매달 두 번째 화요일(일본은 그 다음 날)에 자사 제품의 버그 수정 프로그램을 발표한다. 이전에는 수정 프로그램이 완성될 때마다 발표했지만, 사용자가 빈번하게 확인해야 했고 수정이 이루어지지 않고 방치되는 경우가 많아져 이러한 방식을 채택했다. 다만, 이미 실질적인 피해가 발생한 경우에는 즉시 발표가 이루어진다. 다른 회사들도 마이크로소프트를 따라 비슷한 시기에 발표하는 경우가 많아졌다.

8. 4. 유지보수 릴리스

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

8. 5. 알려진 문제

소프트웨어를 출시할 때 알려진, 우선순위가 낮은 버그나 기타 문제가 있는 경우가 흔하다. 가능한 이유는 다음과 같다.

  • 마감일을 준수해야 하지만, 마감일까지 모든 버그를 수정할 자원이 부족한 경우[20]
  • 해당 버그가 향후 릴리스에서 이미 수정되었고, 우선순위가 높지 않은 경우
  • 버그를 수정하는 데 필요한 변경 사항이 너무 많은 비용이 들거나, 다른 많은 구성 요소에 영향을 미쳐 대규모 테스트 활동이 필요한 경우
  • 일부 사용자가 기존의 버그가 있는 동작에 의존하고 있다고 의심되거나 알려진 경우, 제안된 수정 사항이 파괴적인 변경을 가져올 수 있음.
  • 문제는 향후 릴리스에서 더 이상 사용되지 않을 영역에 있으며, 수정할 필요가 없는 경우
  • "버그가 아니라 기능입니다"[21] 예상되는 동작과 실제 동작 간의 오해가 있거나, 미비문 기능이 있는 경우

9. 영향

소프트웨어 버그로 인해 발생하는 피해 규모와 유형은 소프트웨어 품질 관련 의사 결정, 프로세스 및 정책에 영향을 미친다. 유인 우주 비행, 항공, 원자력 발전, 의료, 대중교통, 자동차 안전과 같이 소프트웨어 결함이 인명 피해나 사망을 초래할 수 있는 분야의 경우, 온라인 쇼핑 웹사이트보다 훨씬 더 많은 조사와 품질 관리를 받게 된다. 은행과 같이 소프트웨어 결함으로 인해 심각한 재정적 피해가 발생할 수 있는 분야에서도 사진 편집 응용 프로그램보다 품질 관리가 더 중요하다.

버그 수정에는 상당한 노력과 비용이 소요된다. 1978년, Lientz 등은 프로젝트 중간값이 개발 노력의 17%를 버그 수정에 투자한다는 것을 보여주었다.[22] 2020년에는 깃허브 저장소에 대한 연구에서 중간값이 20%로 나타났다.[23]

10. 비용

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

1990년의 다른 연구에서는 매우 우수한 소프트웨어 개발 프로세스가 배포 실패율을 SLOC 1,000줄당 0.1개까지 낮출 수 있다고 보고했다.[25] 이 수치는 스티브 매코넬의 ''코드 컴플리트''[26] 및 ''NASA의 비행 소프트웨어 복잡성에 대한 연구''와 같은 문헌에서 반복적으로 언급된다.[27] 일부 프로젝트는 결함 제로를 달성하기도 했는데, 63,000 SLOC로 구성된 IBM Wheelwriter 타자기 펌웨어와 500,000 SLOC의 우주 왕복선 소프트웨어가 그 예이다.[25]

11. 벤치마크

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


  • 지멘스 벤치마크
  • ManyBugs[28]는 9개의 오픈 소스 프로그램에서 185개의 C 버그를 벤치마크한 것이다.
  • Defects4J[29]는 5개의 오픈 소스 프로젝트에서 341개의 Java 버그를 벤치마크한 것이다. 다양한 패치 유형을 포함하는 해당 패치가 포함되어 있다.

12. 유형

소프트웨어 버그는 다양한 유형으로 나타나며, 설계, 산술 연산, 제어 흐름, 인터페이스, 동시성, 자원 관리 등 여러 측면에서 발생할 수 있다.


  • 설계 오류: 불충분하거나 잘못된 설계로 인해 발생하는 버그이다. 예를 들어, 기호를 고려하지 않은 정렬 알고리즘은 기호가 포함된 단어를 올바르게 정렬하지 못한다.[1]
  • 산술 연산 오류: 산술 오버플로 및 언더플로, 0으로 나누기 등 수치 연산 과정에서 발생하는 오류이다.[30]
  • 제어 흐름 오류 (논리 오류): 무한 루프, 무한 재귀, 잘못된 비교 연산자 사용 등 논리적인 오류로 인해 발생하는 버그이다.[1]
  • 인터페이스 오류: 잘못된 API 사용, 잘못된 프로토콜 구현, 호환되지 않는 시스템 등 인터페이스와 관련된 오류이다.
  • 동시성 오류: 교착 상태, 경쟁 상태 등 동시성 프로그래밍에서 발생하는 오류이다.
  • 자원 관리 오류: NULL 포인터 참조 제거, 무한 루프, 버퍼 오버플로, 메모리 누수 등이 자원 관리 오류에 해당한다.

12. 1. 설계 오류

버그는 사양에 기반한 불충분하거나 잘못된 설계로 인해 발생할 수 있다. 예를 들어, 사양이 단어 목록을 알파벳순으로 정렬하는 것이라고 가정할 때, 설계 버그는 기호를 고려하지 않은 설계로 인해 발생할 수 있다. 그 결과 기호가 포함된 단어의 알파벳순 정렬이 잘못될 수 있다.[1]

12. 2. 산술 연산 오류

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

12. 3. 제어 흐름 오류 (논리 오류)

제어 흐름 버그는 논리 오류라고도 하며, 오류로 실패하지는 않지만, 무한 루프, 무한 재귀, 잘못된 비교 연산자 사용과 같은 조건문의 잘못된 비교, 오프 바이 원 오류와 같이 예상과 다른 동작을 보이는 코드로 특징지어진다.[1]

프로그래밍상의 주요한 버그에는 논리적인 버그와 오기(誤記)에 의한 버그가 있다.[1] 논리적인 버그는 프로그램의 설계 과정에서 발생한다. 무한 루프나 계산 오류 등을 일으키며, 때로는 컴퓨터를 폭주시키거나 반대로 정지시키기도 한다.[1]

12. 4. 인터페이스 오류


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

12. 5. 동시성 오류

12. 6. 자원 관리 오류

NULL 포인터 참조 제거, 무한 루프, 버퍼 오버플로, 메모리 누수 등이 자원 관리 오류에 해당한다.

13. 정치에서의 버그

뉴 아메리카의 오픈 테크놀로지 연구소는 2016년 8월 "Bugs in the System" 보고서를 발표했다. 이 보고서는 미국의 정책 입안자들이 연구자들이 소프트웨어 버그를 식별하고 해결하는 데 도움을 주기 위한 개혁을 해야 한다고 주장했다.[36] 보고서는 "소프트웨어 취약성 발견 및 공개 분야의 개혁 필요성을 강조"하고 있다.[36] 보고서의 저자 중 한 명은 미국 의회가 사이버 보안이라는 더 큰 문제와 싸우기 위해 여러 법안을 통과시켰음에도 불구하고 사이버 소프트웨어 취약성을 해결하기 위해 충분한 노력을 기울이지 않았다고 말했다.[36]

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

보고서에 따르면 컴퓨터 사기 및 남용 방지법, 디지털 밀레니엄 저작권법 및 전자 통신 프라이버시 법은 보안 연구자들이 합법적인 보안 연구를 수행하는 동안 일반적으로 수행하는 행위에 대해 형사 처벌과 민사 처벌을 가한다.[36]

14. 대중문화에서의 버그


  • 비디오 게임에서 "글리치"라는 용어는 소프트웨어 버그를 지칭하는 데 사용되기도 한다.[48] 그 예로 MissingNo.가 있다.
  • 1968년 소설 ''2001: 스페이스 오디세이''와 동명의 영화에서 우주선의 온보드 컴퓨터인 HAL 9000이 모든 승무원을 죽이려 한다. 1982년 소설 ''2010: 오디세이 투''와 1984년 영화 ''2010: 우리가 접촉하는 해''에서는 이 행동이 컴퓨터가 두 개의 상충하는 목표, 즉 모든 정보를 완전히 공개하고, 비행의 진정한 목적을 승무원에게 숨기도록 프로그래밍되었기 때문에 발생했다는 것이 밝혀진다. 이 갈등으로 인해 HAL은 편집증에 시달리고 결국 살인적인 경향을 보이게 된다.
  • Nena의 1983년 노래 ''99 Luftballons''(99 Red Balloons)의 영어 버전에서 "소프트웨어 버그"의 결과로 99개의 빨간 풍선이 발사된 것이 적의 핵 미사일 발사로 오인되어 이에 상응하는 발사 대응이 필요하게 되고, 결국 재앙을 초래한다.
  • 1999년 미국 코미디 영화 ''오피스 스페이스''에서 세 명의 직원이 회사가 Y2K 컴퓨터 버그에 집착하는 점을 이용하여, 잘린 푼돈을 자신들의 은행 계좌로 보내는 컴퓨터 바이러스를 사용하려 한다. 이는 살라미 절단으로 묘사되는 오랫동안 알려진 기술이다.
  • 2004년 엘렌 울먼의 소설 ''The Bug''는 데이터베이스 애플리케이션에서 찾기 어려운 버그를 찾으려는 프로그래머에 관한 이야기이다.[37]
  • 2008년 캐나다 영화 ''컨트롤 알트 딜리트''는 1999년 말에 2000년 문제와 관련된 회사의 버그를 수정하기 위해 고군분투하는 컴퓨터 프로그래머에 관한 이야기이다.

15. 컴퓨터 게임에서의 버그

컴퓨터 게임은 일반적인 소프트웨어와 마찬가지로 버그가 존재한다. 게임 진행이나 세이브 데이터 보존에 영향을 주는 버그는 게임 잡지 등에서 공지되거나, 인기 게임의 경우 신문에서도 다뤄진다. 심각한 버그라고 판단되면 제작사가 대책을 마련한다.[48] PC 게임은 공식 웹사이트에서 수정 패치를 배포하여 대응할 수 있다. 가정용 게임 소프트웨어는 이전에는 업데이트가 어렵거나 불가능하여 무상으로 수정판과 교환하기도 했다. 그러나 최근에는 대부분의 가정용 게임기가 네트워크 기능을 지원하고 대용량 저장 장치를 탑재하여 패치 데이터를 설치할 수 있게 됨에 따라, 네트워크를 통해 수정 패치를 배포하여 대응한다.

사용자가 버그를 비기나 잔기술로 이용하기도 한다. 『스페이스 인베이더』의 「나고야 격추」처럼, 개발자가 의도하지 않은 현상이 나중에 정식 사양으로 인정되는 경우도 있다.

2D 게임은 물체 간 충돌 판정이나 화면 표시 위치 등 좌표 계산 처리가 비교적 간단하지만, 3D 게임은 공간 복잡도가 높아 버그가 발생하기 쉽다. 이로 인해 캐릭터가 벽 사이에 끼이거나, 표시되어야 할 오브젝트가 표시되지 않는 등의 문제가 발생할 수 있다.

온라인 게임에서는 랭킹 조작이나 과금 시스템 관련 버그가 발생하면 게임에 치명적인 문제가 될 수 있으므로, 게임 서버를 일시 중지해서라도 버그를 수정해야 한다. 일부 온라인 게임은 이용 약관을 통해 사용자가 버그를 의도적으로 발생시키는 행위를 금지하기도 한다.

참조

[1] 웹사이트 Software bugs cost US economy dear http://www.nist.gov/[...] 2009-06-10
[2] 간행물 Testing experience : te : the magazine for professional testers testingexperience 2012-03
[3] 서적 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology IEEE 1990-12-31
[4] 간행물 News at SEI September 1999 https://insights.sei[...] Software Engineering Institute 1999-09-01
[5] 간행물 Apple faces questions from Congress about iPhone tracking https://www.computer[...] 2011-04-21
[6] 간행물 Apple denies tracking iPhone users, but promises changes https://www.computer[...] 2011-04-27
[7] 서적 Automated Defect Prevention: Best Practices in Software Management https://ieeexplore.i[...] Wiley-IEEE Computer Society Press 2007-09
[8] 서적 The Practical Guide to Defect Prevention https://archive.org/[...] Microsoft Press
[9] 웹사이트 Release Early, Release Often https://web.archive.[...] 2011-05-14
[10] 뉴스 Wide Open Source https://web.archive.[...] SecurityFocus 2000-04-17
[11] 웹사이트 Maurice Wilkes Quotes https://quotepark.co[...] QuoteFancy 2024-04-28
[12] 웹사이트 PolySpace Technologies history http://christele.fau[...] 2019-08-01
[13] 간행물 Bug Tracking Basics: A beginner's guide to reporting and tracking defects https://www.stickymi[...] 2017-12-19
[14] 서적 Managing The Testing Process https://books.google[...] Wiley India Pvt. Limited 2021-06-19
[15] 서적 Shipping Greatness - Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon https://books.google[...] O'Reilly Media
[16] 간행물 Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems https://linkinghub.e[...] 2020-10-01
[17] 웹사이트 5.3. Anatomy of a Bug http://www.bugzilla.[...]
[18] 백과사전 Show stopper https://hdl.handle.n[...] Department of Defense, Defense Systems Management College
[19] 서적 Show-stopper!: the breakneck race to create Windows NT and the next generation at Microsoft https://archive.org/[...] The Free Press
[20] 잡지 The Next Generation 1996 Lexicon A to Z: Slipstream Release 1996-03
[21] 웹사이트 'It''s Not a Bug, It''s a Feature.' Trite – or Just Right? https://www.wired.co[...]
[22] 간행물 Characteristics of Application Software Maintenance 1978
[23] 논문 The Corrective Commit Probability Code Quality Metric 2020
[24] 간행물 An Overview of the Software Engineering Laboratory https://ntrs.nasa.go[...] 1994-12
[25] 간행물 Engineering software under statistical quality control https://trace.tennes[...]
[26] 서적 Code Complete https://archive.org/[...] Microsoft Press
[27] 간행물 Appendix D – Software Complexity https://www.nasa.gov[...] 2009-03-05
[28] 간행물 The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs
[29] 서적 'Proceedings of the 2014 International Symposium on Software Testing and Analysis – ISSTA 2014'
[30] 컨퍼런스 A comprehensive study of real-world numerical bug characteristics IEEE 2017-11-23
[31] 서적 Feature Interactions in Telecommunications and Software Systems V https://books.google[...] IOS Press
[32] 서적 Multimedia Networking: Technology, Management and Applications: Technology, Management and Applications https://books.google[...] Idea Group Inc (IGI) 2001
[33] 서적 Introduction to Computer Networks and Cybersecurity https://books.google[...] CRC Press 2016
[34] 문서 RFC 1263
[35] 웹사이트 Bugs in the System https://na-productio[...] 2016-08-22
[36] 웹사이트 Cyber reforms needed to strengthen software bug discovery and disclosure: New America report – Homeland Preparedness News https://homelandprep[...] 2016-08-12
[37] 서적 The Bug Picador 2004
[38] 문서 Edison to Puskas, 13 November 1878, Edison papers, Edison National Laboratory, U.S. National Park Service, West Orange, N.J., cited in Thomas P. Hughes, ''American Genesis: A History of the American Genius for Invention,'' Penguin Books, 1989, ISBN 0-14-009741-4, on page 75.
[39] 웹사이트 Danis, Sharron Ann: "Rear Admiral Grace Murray Hopper" http://ei.cs.vt.edu/[...]
[40] 문서 First actual case of bug being found.
[41] 간행물 IEEE Annals of the History of Computing, Vol 22 Issue 1, 2000
[42] 문서 これ以前から故障の原因のことを「バグ」と呼んでいたことが推測される。
[43] 문서 日誌の記述全体は 1545（時刻）Relay #70 Panel F（moth）in relay. First actual case of bug being found.
[44] 웹사이트 E.W. Dijkstra Archive: On the reliability of programs. (EWD303) https://www.cs.utexa[...]
[45] 웹사이트 世界で重要度を増す「バグ報奨金」制度 | Forbes JAPAN（フォーブス ジャパン） https://forbesjapan.[...]
[46] 웹사이트 人工知能が「バグの発生」を未然に防ぐ──ゲーム開発に導入したユービーアイソフトの狙い https://wired.jp/201[...] WIRED.jp 2018-03-19
[47] 문서 bug tracking system
[48] 웹사이트 バグるとは - デジタル大辞泉 コトバンク https://kotobank.jp/[...]
[49] 문서 Maurice Wilkes Quotes


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com