문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 디버그 (문단 편집) === 과정 === 디버그를 하는 것 자체는 말로 설명하면 굉장히 쉽다. 오류 혹은 비정상적인 작동을 하는 부분을 찾아 수정하면 된다. 문제는 디버깅은 프로그래머가 만드는 과정에서 미처 고려하지 못한 부분이나 실수를 찾는 것이기 때문에 이 오류가 난 부분을 찾기란 굉장히 어렵다. 프로그램 코드의 길이가 수십줄~수천줄 정도라면 [[근성]]으로 코드를 샅샅히 뒤져 찾을 수도 있겠지만 수만줄 이상이 넘어가면 [[답이 없다]]. 프로그래머가 예측하는 부분 안에서 나오길 바라는 수 밖에. 그렇다고 디버그를 안하면 앞서 언급한 악영향 중에 어떤 악영향이 나올지를 장담할 수 없다. 이런 악명과 사례는 이미 오래전부터 알려져 있어서 지금에 이르러서는 이 디버깅을 도와주는 프로그램 적인 도구들이 많이 등장한 상태이다. 프로그램 내에 존재하는 모든 변수 값을 표시하거나, 프로그램 코드를 한줄 한줄 멈춰가며 구동시키는 것 등이 대표적으로 디버깅에 도움을 주는 것들이다. 하지만 이것들은 말 그대로 도움을 주는 것이지 직접 버그를 찾아주는 것은 절대 아니다. 가령 1+2를 해야 할 프로그램에서 프로그래머의 실수로 1-2를 적는다면 의도하지 않은 결과가 나오기 때문에 버그이지만 컴퓨터 입장에선 어쨌든 실행은 멀쩡히 되기 때문에 오류로 인식하지 않는다. 디버깅의 핵심은 바로 이런 부분을 찾아야 하는 것이다. 또한 이 디버깅이 얼마만큼의 시간이 걸리는 지는 아무도 모른다. 일단 버그가 정확히 몇 개다. 라고 단정지을 수 있는 것도 아니고 버그가 발생되는 코드가 프로그래머가 생각하는 부분에 있다는 보장이 전혀 없기 때문이다. 프로그래머가 생각한 부분에서 버그가 발생되는 코드가 발견 되었다면 디버깅 시간은 짧아질 것이고 전혀 엉뚱한 곳에서 나온다면 디버깅에 걸리는 시간은 한없이 길어진다. 그리고 대부분의 버그는 전혀 예상치 못한 곳에서 뜬금없이 튀어나온다. 그래서 이런 부분은 개발 기간과 QA에 쏟아붇는 자원을 늘리는 것이 정답이고, 그렇지 못하면 [[빌 게이츠의 굴욕]]처럼 제품 출시 후 어마어마한 버그를 내뱉으며 망신을 당한다는 것을 임원들이 깨달아 [[크런치]]처럼 개발자를 혹사시키는 경영학적인 [[리스크]]로 돌아온다는 것을 인지해야 한다. 하지만 [[사이버펑크 2077]]같은 예시를 볼때 실제로 기간을 늘리거나 투자금을 어마어마하게 받아도 소프트웨어 품질 향상에 기여를 못하는 것을 보면 사람들이 [[부정부패]]를 의심하기도 한다. 이런 과정들을 줄여주는것이 단위 테스트인데, xUnit 등을 이용해서 자동화를 시켜놓으면 디버깅 시간이 확 줄어든다. 물론 단위 테스트가 끝났다고 다 끝난 것은 아니고, 상위 테스트를 통해 단위 간의 상호작용 과정에서 발생할 수 있는 버그도 줄여야 한다. 게다가 코드 상으로는 버그가 아니더라도 윤리적으로는 치명적인 결함, 그리고 앞서 언급했듯 발생 자체가 불법인 결함이 얼마든지 발생할 수 있으므로, 이러한 결함 역시 줄여야 하는 게 디버그의 몫이다. 실제로 패션쥬디의 경우 [[http://blog.alyac.co.kr/1125|가져왔던 광고 라이브러리가 멀웨어임이 드러나면서]] 모든 앱이 구글 직권으로 내려갔고, 이에 따라 개발사였던 ENI 스튜디오는 더 이상 구글 플레이에 앱을 등록할 수 없게 되면서 사업 영역 역시 대폭 축소해야만 했다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기