글로벌 칼럼 | 버그투성이 소프트웨어가 만들어지는 이유

물리적 물체의 제조는 대부분 같은 것을 반복해서 생산하기 때문에 이해하기 쉽다. 제품을 기계적으로 생산한다면, 프로세스는 질서정연하고 반복 가능하며 심지어 완벽할 수도 있다. 전체 프로세스의 효율성이 높아질 때까지 최악의 병목 현상을 찾아서 반복해서 개선할 수 있다. 

다리나 집을 짓는 것은 덜 반복적이지만, 두 경우 모두 수십 년, 심지어 수세기에 걸쳐 프로세스가 발전해 왔다. 놀라운 일은 거의 없다.
 

ⓒ Getty Images Bank

하지만 소프트웨어를 구축하는 것은? 완전히 다른 차원의 이야기이다. 크고 작은 모든 프로젝트는 독특하고 이전에 한 번도 해본 적이 없다. 주어진 문제를 해결하는 방법에는 여러 가지가 있으며, 똑똑한 사람들 간에 무엇이 가장 좋은 방법인지에 대해 의견이 분분하다. 어쩌면 가장 좋은 방법이란 없을지도 모른다. 그나마 더 나은 방법은 프로젝트를 처음 수행한 후에야 드러나는 경우가 많다. 어떤 경로를 선택하든 항상 알려지지 않은 미지의 영역이 존재한다. 

물론 수년에 걸쳐 몇 가지 베스트 프랙티스가 개발되고 몇 가지 패턴이 등장했지만, 이런 패턴을 구현하는 방법에 대해서는 개발자마다 의견이 다를 수 있다. 즉, 일반적으로 제품을 만드는 가장 좋은 방법은 꽤 명확하지만, 소프트웨어 프로젝트를 구축하는 방법은 무한대로 많기 때문에 “가장 좋은 방법”이라는 개념이 문제가 된다.
 

블랙홀 속의 수정구

물론 이 때문에 소프트웨어 프로젝트의 소요 시간을 파악하는 것은 매우 어렵다. 수년간의 노력에도 불구하고 누구나 신뢰할 수 있는 방법을 찾지 못한 것 같다. 필자를 포함한 많은 사람이 거의 불가능하다고 생각한다.

하지만 “거의 불가능하다”는 말은 비즈니스 책임자가 듣고 싶은 말이 아니다. 소프트웨어를 제작하고 판매하는 기업이라면, 고객에게 “만들어 달라고 했던 그 소프트웨어 말인데, 언제 완성될지 전혀 모르겠어요. 지금은 좋은 구축 방법을 찾고 있어요. 한 가지 방법을 시도했는데, 잘되지는 않았지만 결과적으로 더 나은 방법을 찾았을 수도 있어요. 하지만 어떻게 할 것인지 완전히 확신할 수 없기 때문에 언제 준비되어 작동할 수 있을지는 말씀드릴 수 없네요”라고 할 수는 없을 것이다.

이 가상의 고백은 사실에 가까운 것이지만, 고객에게 이를 인정하는 소프트웨어 개발 업체는 거의 없을 것이다. 심지어는 그것이 사실이라는 사실조차 깨닫지 못할 수도 있다. 

소프트웨어 업계는 이 문제를 해결하기 위해 많은 노력을 기울여 왔고, 지금도 계속하고 있으며, 많은 소프트웨어 프로세스 도구의 제품 마케팅 책임자는 이 문제를 해결했다고 말한다. 하지만 사실은 그렇지 않다. 많은 마케팅 문구가 작성되고 많은 약속이 이루어졌지만, “소프트웨어 프로젝트가 언제 완료될지는 아무도 모른다”는 것은 여전히 사실로 남아있다.

그 결과 새로운 소프트웨어와 기능을 생산하려는 그룹과 이런 새로운 제품과 기능으로 수익을 창출하려는 그룹 사이에는 불가피한 긴장감이 존재한다. 

소프트웨어는 매우 유연하고 새로운 기능을 제공할 수 있기 때문에 고객은 부분적으로는 현재의 기능에 따라 구매 결정을 내리지만, 종종 “다음 큰 것”에 따라 구매를 결정한다. 그 결과, 영업부서는 아직 존재하지 않는 기능을 홍보하고 심지어 판매하기도 한다. 당연히 고객은 이런 기능이 언제 출시될지 알고 싶어 한다. 그리고 당연히 소프트웨어 기업은 특정 기간 내에 기능을 제공하겠다고 약속한다. 

하지만 이런 약속은 지키기 어려운 경우가 많다. 소프트웨어 개발팀은 영업 담당자에게 언제 출시될지 정확하게 알려줄 수 있으면 좋겠지만, 앞서 설명한 것처럼 불가능한 일이다. 아는 것처럼 말하고 행동하는 개발자도 있겠지만, 실제로는 모른다. 종종 날짜를 알아야 한다는 압박도 받는다. 그 날짜를 예측하기 위해 많은 노력을 기울이지만, 그 예측은 거의 항상 틀린다. 때로는 엄청나게 틀릴 때도 있다.
 

다리가 세 개 달린 의자

그렇다면 개발팀은 무엇을 해야 할까? 돌릴 수 있는 다이얼이 있다. 모두가 가장 먼저 돌리는 다이얼은 더 많은 시간을 일하는 것이다. 그럴 수도 있다. 그러나 개발팀을 압박하면 일반적으로 더 많은 지름길과 더 많은 오류가 발생해 기술 부채만 증가하고 정시 납품이 반드시 이루어지는 것은 아니다. 관리자는 근무 시간을 늘리기 위해 더 많은 인력을 충원하고 싶은 유혹을 받지만 브룩스의 법칙이 작동해 상황만 악화된다. 지체되는 소프트웨어 개발 프로젝트에 인력을 추가하는 것은 개발을 더 늦출 뿐이다.

제공해야 할 기능들을 변경하는 것도 일반적인 해결책 중 하나다. 또 다른 방법은 버그 수정을 줄이거나 사용자 인터페이스의 효율성을 낮추는 등 품질을 희생하는 것이다. 마지막으로 일정을 변경할 수 있지만, 이는 고객을 짜증 나게 한다.

따라서 “품질, 일정 또는 기능, 둘 중 하나를 선택하라!”는 유명한 세 발 달린 의자가 있다. 기업은 일정을 희생하는 것을 싫어하며, 때로는 아예 일정을 거부하기도 한다. 감정이 매우 중요한 고객들은 일정이 바뀌는 것을 싫어하고 일반적으로 기능이 축소되는 것을 싫어한다. 

그렇게 되면 품질이 도마 위에 오르게 되고, 솔직히 말해서 보통 이런 길을 택하게 된다. 결함이 있는 애플리케이션을 좋아하는 사람은 아무도 없지만, 겉보기에 잘 작동하는 기능 뒤에 품질 저하를 숨기는 것은 쉽고 유혹적인 일이다. 고객이 '작동하는 소프트웨어'를 제공받고 사후에야 품질이 부족하다는 사실을 발견하는 것은 너무나 일상적인 일이다. 그런 다음 개발팀은 버그를 수정하고 품질을 개선하는 '포인트 릴리즈'를 제공한다. 이는 사실상 일정을 변경하는 매우 교묘한 방법으로, 버그 수정 시간을 납품 시간 이후로 미루는 것이다. 

이 “영리한” 문제 해결 방식이 일반적으로 선택된다. 개발팀은 아마도 약속한 날짜에 맞춰 고객에게 약속한 기능이 제공되고 모두가 만족한다. 고객이 소프트웨어를 실행하기 전까지는. 

소프트웨어 개발팀이 만드는 것은 기계 장치 같은 것이 아니다. 결국 누군가는 뒤처리를 해야 하는데, 보통 소프트웨어 개발자와 QA팀이 그 역할을 하게 된다. 이렇게 버그투성이 소프트웨어가 나오는 것이다. 
editor@itworld.co.kr