당신의 프로그램에 버그를 번식시키는 요인들

당신의 프로그램에 버그를 번식시키는 요인들
────────────────────────────────────

1. 기술적 메커니즘에 대한 이해 부족
일례로, 저는 Thread에서 COM Object를 사용하려면 먼저 CoInitilize()를 호출해야 된다는 사실을 몰라서 하루동안 삽질한 경험이 있습니다(...) 어떤 라이브러리나 API를 이용할 때, 내부적인 동작원리나 설계 사상에 대한 이해없이 단지 사용법만 알고 있을 경우에, 이같은 간단한 문제에도 그 원인을 짚어내지 못하는 경우가 있습니다. 그리고 주의깊지 못한 사용 방법으로 인해 버그가 생겨날 수 있는 거죠.

프로그래밍에 있어서 OS에 대한 이해가 중요한 것도 이같은 맥락에서 입니다. 여튼 프로그래머는 공부해야 될게 많습니다...


2. 완벽하지 못한 추상화
「조엘 온 소프트웨어」를 보면 허술한 추상화에 대한 이야기가 나옵니다. 저는 발전된 기술이라는 것은 그 이전에 존재했던 복잡한 메커니즘을 단순한 개념으로 추상화 시켜놓는 것이라고 생각합니다만, 어쨌거나 문제는 최신의 '기술' 혹은 '라이브러리'라고 해도 그 기반이 되는 메커니즘을 완전히 숨기지는 못합니다.

JAVA나 C#을 쓰면서 포인터에 대해서 전혀 알 필요가 없다면 오죽 좋겠습니까. VC++의 MFC 혹은 Delphi의 VCL만 쓰면서 Win32 API에 대해 전혀 알 필요가 없다면 정말 좋겠지요. 하지만 조금만 더 깊이 들어가려 하면 바로 이것과 관련된 지식을 만나게 될 수 밖에 없는 것이 현실입니다.

이것은 결국 1번과 같은 맥락입니다. 높은 차원의 추상화된 개념만 가지고 사고해서는, 추상화가 깨지는 순간에 부딛히게 될 때 당활할 수 밖에 없겠지요.

이 경우는 추상화를 구현한 것 자체에도 일종의 결함같은 것이 존재한다고 볼 수 있겠습니다.


3. 예측하지 못한 예외상황
프로그래밍을 할 때는 보통 이상적인 상황을 가정합니다. 사용자는 언제나 올바른 입력을 하며 한치의 실수도 없고 이상한(혹은 수상한) 동작을 전혀 하지 않으며 사소한 오류에는 신경쓰지 않는 아주 마음씨 착한 유저라고 말이죠...

물론 현실의 유저들은 99.9% 바보 천치입니다... 아, 이 표현에 너무 분노하지 말아주세요(...) 예초에 프로그래머가 가정하는 유저가 너무 이상적이라서 그런 겁니다.

유저는 당연히 실수할 수 있습니다. 게다가 일부는 악의적인 의도를 가진 유저도 있습니다. 이렇게 험난한 세상에 갖 태어난 프로그램을 던져주면 전쟁터에 홀로 떨어진 것처럼 황폐해져서 돌아오게 될겁니다.

여기서 유저라는 것이 꼭 사람인 것만은 아닙니다. 프로그램을 실행하는 OS도 유저가 될 수 있습니다. 어쨌든, 자신이 만들 것을 사용하는 쪽은 아예 아무것도 모르는 혹은 최소한의 것만 알고있는 바보라고 가정하고 최대한 친절하게 온갖 상황에 다 대처할 수 있도록 만드는 것이 최선일 겁니다.

물론 프로그래머도 사람인지라, 예상하지 못하는 예외상황도 엄청나게 많이 있습니다.


4. 인간과 CPU의 차이
사람은 개떡같이 말해도 찰떡같이 보정해서 알아 듣습니다. 하지만 CPU는 개떡은 개떡이고 찰떡은 찰떡입니다. 즉, 쓰래기를 넣으면 쓰래기가 나오는 구조(Garbage In Garbage Out: GIGO)입니다. 한마디로 시키는 대로만 하는 녀석이죠. 융통성이라곤 전혀 없습니다. 인간관계에서 이런 부류의 사람을 상대하는 것은 정말 피곤하지요. (사실 저도 좀 그런 편입니다만...)

프로그래머는 늘 이런 녀석을 상대로 말싸움하고 있습니다. 인간적인 사고로 보면 이러이러 해서 저러저러하고 요렇게 하면 된다는 논리가 아주 그럴듯해 보여도, CPU군에게는 너무 두리뭉실하다는 것이죠. 우리의 CPU군에게는 유치원생에게 길을 알려줄 때보다도 더욱 자세하게 하나하나 지시해야 합니다.

단, 이것은 고도의 추상화된 프로그래밍 언어를 쓰면 어느정도 해결은 됩니다. 한마디로 융통성있는 통역인을 고용하면 되는 것이죠. 다만 그만큼 통역의 절차가 복잡해지기 때문에 CPU군이 이해하기까지 다소 시간은 걸립니다.


5. 잘못된 설계
잘못된 설계라 함은, 쉽게 기능을 추가하기 어렵고, 하나의 기능을 수정하기 위해 여러곳을 건드려야 하며, 코드를 이해하기가 어려운, 한마디로 이래저래 복잡한 것을 말합니다.

그야말로 버그가 서식하기 아주 좋은 입지조건이죠.


6. 촉박한 일정
소프트웨어 개발에서 생겨나는 문제의 원인에 약방의 감초처럼 거의 빠지지 않고 등장하는 녀석입니다. 여유가 있어야 품질에도 신경쓸 수 있는 것이죠. 일정이 빠듯할 수록 프로그래머는 품질을 희생할 수 밖에 없습니다.

따지고 보면 버그를 키우는 주범은 바로 이 녀석이 아닐까 싶습니다. 시간이 없는데 언제 공부를 하고 있으며(1번), 언제 예외상황에 신경을 쓰고(3번), 언제까지 설계(5번)에 신경을 쓰고 있겠습니까.

사실 버그라는 것은 단지 프도그래머의 '실수'라고만 치부할 수는 없습니다. 정말로 신이 내려와서 코딩을 하지 않는 이상은 버그라는 것은 필연적으로 자생(?!)하기 마련이라는 생각이 듭니다. 그럼에도 버그가 발생하면 일단 프로그래머의 잘못이다!! 라고 몰아세우는 현실이 좀 답답합니다.

출처:버그는 왜 발생하는가?