소프트웨어 엔지니어링은 정말 특별할까?

글에서는 소프트웨어 엔지니어링이 전통 공학(Traditional Engineering)과 본질적으로 다르다는 주장이 종종 자기 방어 기제(Defense Mechanism)로 작용한다고 지적합니다. '우리는 다르기 때문에 예측 불가능하고, 라이선스가 없으며, 엄격한 엔지니어링을 적용하지 않아도 된다'는 논리가 이에 해당합니다. 하지만 이러한 차이점들은 대부분 과장되거나 오해에서 비롯되며, 다른 공학 분야에서도 유사한 문제에 직면한다는 점을 강조합니다.

소프트웨어 개발이 본질적으로 애자일(Agile)이고 전통 공학은 워터폴(Waterfall)이라는 이분법적 구분은 단순화된 시각입니다. 실제로는 전통 공학에서도 반복 개발 및 즉흥적인 수정이 필요한 경우가 많으며, 소프트웨어 역시 초기 설계 단계의 중요성을 간과할 수 없습니다. 경제적 모델(Economic Model)에 따라 반복 주기의 길이와 비용이 달라질 뿐, 두 방식 모두 적응성과 피드백을 중요시한다는 점에서 유사합니다.

소프트웨어가 유독 예측 불가능하다는 인식은 결과만 보고 과정의 어려움을 간과하기 때문입니다. 전통 공학에서도 설계 변경, 공급망 문제, 예상치 못한 물리적 제약 등 예측하기 어려운 변수가 많습니다. 또한, 기술 스택의 빠른 변화(Rapid Tooling Churn)는 소프트웨어만의 문제가 아니며, 하드웨어 분야에서도 파운드리 기술 변화 등 예측 불가능성이 존재함을 지적합니다.

소프트웨어에서 '코드가 곧 설계'라는 주장은 UML 모델링 후 코드 생성을 기대하는 시각에 대한 반발입니다. 하지만 다른 공학 분야에서도 설계와 구현(Design and Implementation)은 분리되지 않으며, 실제 제작 과정에서 발생하는 문제점을 해결하기 위해 설계가 지속적으로 수정됩니다. 기계 공학의 '페틀링(Fettling)'처럼, 소프트웨어의 '클린 코드' 작성 역시 설계의 일부로 볼 수 있습니다.

전통 공학이 소프트웨어보다 더 엄격하다는 주장은 사실과 다릅니다. 소프트웨어는 자동화된 테스트(Automated Testing)와 버전 관리(Version Control) 등 오히려 더 체계적인 검증 프로세스를 갖추고 있습니다. 커뮤니티에서는 코드 리뷰(Code Review)가 단일 검증 지점이 아닌, 전체 품질 프로세스의 일부로 통합되어야 한다는 의견이 제시되었습니다. 또한, 단기 기억 상실증(Short-term Memory Loss)처럼 과거의 교훈을 잊고 바퀴를 재발명하는 경향을 비판합니다.

소프트웨어는 물리적 재료와 달리 논리적으로만 제약되며 마모되지 않는다는 점에서 높은 일관성(Consistency)을 가집니다. 반면, 물리적 재료는 공차(Tolerance)와 환경 변화에 따라 성능이 달라집니다. 이러한 재료의 특성 때문에 소프트웨어는 변경 비용이 저렴하여 빠른 개발 속도(Velocity)를 가지며, 이는 다른 공학 분야에서 시뮬레이션 도구로 소프트웨어를 활용하는 이유가 됩니다.