소프트웨어 빌드가 깨질 때 정말 짜증나지 않나요? 빌드 문제는 예상치 못한 추가 작업을 발생시킵니다. 항상 다른 문제를 해결하느라 급할 때 생기는 것 같아요. 종종 빌드는 현재 진행 중인 작업과 전혀 무관한 요인으로 인해 깨지곤 합니다. 그러니 하고 있던 일을 중단하고 빌드 중단 원인을 파헤쳐 해결한 뒤 빌드를 다시 시작해야 하는 상황(해결해야 할 문제가 하나뿐이길 바라며)은 상당히 짜증나는 일이죠.
오늘 오픈소스 패키지를 재빌드하던 중 이 문제를 마주쳤습니다. 몇 달 전 OpenSSL을 1.0.0 버전으로 업데이트했지만, 이에 의존하는 모든 패키지를 재빌드하지는 않았습니다. 마침 버그 수정을 위해 서브버전 클라이언트를 재빌드하려 했을 때, OpenSSL 1.0.0이 호환되지 않는 변경 사항을 도입한 탓에 서브버전 빌드가 깨져 있음을 발견했습니다. 해결책 찾는데 오래 걸리진 않았습니다. 이 문제는 몇 달 전에 이미 수정되었고, 간단한 웹 검색으로 버그 리포트와 수정 사항을 모두 찾을 수 있었으니까요. 하지만 단순히 제품을 재빌드하려는 중에 이런 문제를 마주치니 여전히 꽤 짜증나는 일이었습니다.
여기서 빛나는 제안을 할 수는 없습니다. 하지만 한 가지 관찰한 바가 있는데, 바로 기계 시간이 이제 풍부하다는 점입니다. 아마도 우리는 매일 밤 모든 소프트웨어를 재빌드해야 할지도 모릅니다. 그렇게 하면 빌드 문제가 발생했을 때 모두가 그 문제를 생생히 기억하는 상태에서 바로 발견할 수 있을 테니까요.
또한 빌드 프로세스에 수동 단계가 포함되어 있다면, 자주 재빌드하기로 결정하는 것이 이를 제거하는 좋은 동기가 될 것입니다. 수동 단계는 오류의 흔한 원인입니다.
소프트웨어 테스터들은 테스트를 마친 소프트웨어를 다시 빌드하는 것을 꺼리는 경향이 있습니다. 그들은 이를 새로운 결함을 발생시킬 기회로 여깁니다. 저는 컴파일러, 링커, 메이크파일과 같은 빌드 도구에 충분히 신뢰를 가지고 있어 언제든지 재빌드할 수 있기를 바랍니다. 우리가 고수준 언어로 작업하고 있다는 점을 고려할 때, 빌드 도구에 대한 신뢰는 필수적입니다. 그러나 단계별 개발 프로세스에서는 양측의 관점을 모두 수용할 여지가 충분히 있습니다.
빌드 중단 가능성을 최소화하거나 빌드 문제 해결에 필요한 노력을 줄이기 위한 소프트웨어 개발 관리 방법에 대한 제안이 있으시면, 이 게시물에 의견을 남겨 주시기 바랍니다.