버그는 소프트웨어 안에 존재하는가?

A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. from Software bug - Wikipedia

버그에 대한 위키피디아의 정의이다. 번역하자면 다음과 같다.

컴퓨터 프로그램이나 시스템으로 하여금 맞지 않는 결과 또는 예상치 못한 결과를 만들어 내거나 의도치 않은 방식으로 동작하게 하는 에러, 취약점, 실패 상황을 말한다.

위 정의를 문장 그대로 받아들이면, 버그는 이미 존재하는 프로그램 내부에 있으며 여러가지 오작동을 유발하는 요소이다. 즉 버그는 소프트웨어에 내재하고 있는 한 부분이라고 이해된다. 어떤 버그들에 한하자면, 확실히 그러하다고 있고, 이 버그들은 소프트웨어가 존재하기 때문에 실재한다고 말할 수 있는 것들이다.

한편 버그의 정의를 조금 다른 방향에서 접근해보자. 우선 버그의 요인에 대해 확장을 해보자. 버그의 인자로 손 꼽힌 것들은 에러, 취약점, 실패 상황인데, 이 중에서 실패상황을 조금 더 넓게 생각해보자.

예를 들어 기간내에 다 구현하지 못한 기능들에 대해서 생각해보면, 이는 명백히 소프트웨어의 성공에 반하는 것으로써 하나의 Failure 라고 부를 수 있다. 완료되어 제 기능을 하리라 예상했던 프로그램이 그렇지 않은 동작을 보이도록 함으로, 미구현 사항들은 버그라고 할 수 있다. 의도적인 정의의 확장이긴 하나, 버그의 정의 자체를 다시 내리지 않고 요소들의 의미를 넓힌 것이므로 무리 없다 할 수 있을 것이다.

즉 요약하면 리소스의 부족으로 구현하지 못한 일감들도 어느 순간이 되면, 버그로 인식할 수 있다라는 말이다. 이는 버그란 “어느 순간”에 따라 리소스 부족과 같은 외부적인 요인 때문에 생겨난다는 말이 된다. 이 말은 버그가 명백히 소프트웨어 바깥에 존재한다는 뜻이기도 하다. 앞에서는 버그는 소프트웨어 내부에 존재한다는 이야기를 했었는데, 이 두 의견은 완전히 상반된 것 아닌가. 여기에 대한 성급한 결론은 버그는 소프트웨어 내부에 존재하기도 하고, 외부에 존재하기도 한다일 것이다.

버그는 유한한가?

이번에는 조금 환기를 시켜, 하나의 소프트웨어가 가지는 버그의 수는 유한한가 무한한가에 대해서 생각해보자. 만약 하나의 소프트웨어가 가질 수 있는 버그의 수가 유한하다면, 우리는 유한한 시간 내에 이를 모두 개선하여, 완벽한 소프트웨어를 만들 수 있다는 말이 된다. 반면 버그의 수가 무한하다면, 프로그래머들이 버그 픽스 라는 이름으로 하는 행위에는 단순 버그 픽스 보다 높은 차원의 행위에 대한 인식이 필요하다는 말이다.

여기에 대한 답은 “무한하다” 라고 빠르게 내려 볼 수 있는데, 위에서 확장한 버그의 정의와 관련이 있다. 어떤 사람이 어떤 소프트웨어를 만들겠다고 마음 먹은 그 순간, 할 일 목록에는 해야하는 일감들이 생겨나게 되고, 더불어 프로젝트 기간, 비용 같은 외재적 요인들이 생겨나게 된다. 이는 곧 버그가 될 수 있는 “잠재적 버그” 들이 생겨 난다는 말이기도 하다.

주체가 세상을 바라보는 인식의 과정에서 순식간에 그 존재를 드러내는 외재적 버그들 때문에, 버그는 무한하다라는 결론을 내릴 수 있다. 소프트웨어 내부에 존재하는 내재적 버그의 수는 유한인지 무한인지 함부로 이야기할 수 없으므로, 여기에 대한 문제는 남겨두더라도 같은 결론에 도달하게 된다.

과학과의 유사성

자 이제 재밌는 2개의 결론을 가지게 되었다. 버그는 소프트웨어 내부에 존재하기도 하고, 외부에 존재하기도 하는 것처럼 보이는 데다 그 수는 끝이 없는 무한인 것 같다는 결론이다. 이 골치아픈 결론이 프로그래머들에게 시사하는 바는 무엇인가? 사실 동일한 문제 구조를 과학자들도 가지고 있다.

과학자들은 세상의 진리에 대해 알기 위해 가설을 세우고 이를 검증함으로써 새로운 지식을 만들어낸다. 그들은 과학적 방법론이라는 절차를 수행함으로써, 절차의 타당성을 확립하고 반증에 대한 가능성을 열어둠으로써 자신이 발견한 지식에 대한 확장 가능성을 준비한다.

바로 이 가설에 무한성이 숨어있다. 어떤 사안에 대해 만들어 낼 수 있는 가설의 수는 무한하다고 볼 수 있기 때문이다. 하나의 가설에 대한 실험이 성공하든 실패하든 이는 새로운 가설 수립에 대한 필요성을 만들어내고, 설사 실험이 검증에 실패한다해도 이는 또 다른 차원의 가설을 만들어내기 때문이다. 이 무한한 가설들 중에서 과학자들은 적절한 가설을 선택하여 검증함으로써 지식 체계를 한 발자국씩 앞으로 전진시켜 가는 것이다.

무한한 가설들과 지식체계, 무한한 버그들과 소프트웨어, 이 정도면 유사해 보이지 않는가?

선별 능력

선과 모터사이클 관리술에서 파이드로스가 지적했듯이, 문제는 바로 이 가설 선택에 있다. 무한한 가설(버그) 들 위에서 한 방향으로의 진보를 만들어 내는 행위는 무엇인가? 무엇이 그 진보를 통해 보다 나은 지식체계(소프트웨어) 구축을 할 수 있도록 하는가? 예를 들어 무작위로 고른 버그들을 기계적으로 고치기만 하면, 보다 나은 소프트웨어를 만들 수 있는 것인가?

무작위적으로 버그를 골라 고치기만 하면 좋은 소프트웨어가 될 것이다 라는 말은 원숭이가 타자기를 두드려 프랑스 국립 박물관의 모든 책을 써내는 것과 같은 이야기이고(출처), 이는 발생할 가능성이 없다. 이야기했듯이 무작위성을 제거해 가는 부분에 그 비밀이 숨어 있는 것이다. 과학에 비춰 말하자면, 무한한 가설들 중에서 진리에 한발짝 더 다가갈 수 있는 가설을 선별해 내는 능력, 그것이 과학의 진보를 이뤄내는 비밀이다.

결론

무한한 버그들 중에서 소프트웨어 품질 개선에 도움이 되는 것들을 선별해 내는 작업이야 말로, 소프트웨어 품질과 가장 직접적으로 관련이 있는 작업이라는 것이다.

품질과 관련된 버그들을 선별해 내는 능력이 보다 높은 질을 고취하는 데 있어서 가장 중요한 것이다. 우리가 어떤 소프트웨어의 품질을 높이기 위해 하는 행위 중 가장 본질적인 것은, 어떤 버그를 고칠지 결정하는 바로 그 순간에 이뤄진다는 것이다. 물론 버그를 선택한다고 해서 모두 훌륭히 픽스해내지는 못하지만, 이는 시간의 문제일 따름이다. 좋은 프로그래머는 10이라는 크기의 버그를 고쳐 1이라는 버그 2개를 만들어낼 뿐이지만, 그렇지 않은 프로그래머는 10 크기의 버그를 고쳐, 3 크기의 버그 3개를 만들어낸다. 하지만 전체 총량을 줄여나간다는 점에서는 동일하다. 다만 후자는 더 많은 시간을 필요로 할 뿐이다. 그러니 이는 시간의 문제가 맞다.

어쨋든 소프트웨어 품질과 버그 선별 능력 사이의 관계를 이해하고 나면, 자연스럽게 다음 질문은 그럼 어떻게 해야 품질을 높일 수 있는 버그를 선택할 수 있는가로 넘어가게 된다. 여기에 대해서는 조금 더 형이상학적인 답변이 나올 수 밖에 없다. 그리고 깊게 들어간 형이상학과 철학은 나도 잘 모르는 분야라 여기에 대해서는 선과 모터사이클 관리술에서 언급된 부분을 발췌하여 또 하나의 글을 작성해 보기로 하는 것이 나을 것이다.