소프트웨어 공학의 위험한 교리

소프트웨어 공학의 위험한 교리
안내: 본 포스트의 한글 요약 및 분석 리포트는 AI 기술을 통해 자동 생성되었습니다. 정보의 정확성을 위해 하단의 [원본 논문 뷰어] 또는 ArXiv 원문을 반드시 참조하시기 바랍니다.

초록

본 논문은 소프트웨어 공학이 과학적 정당성을 얻기 위해서는 증거에 기반하지 않은 네 가지 교리를 버려야 한다고 주장한다. 요구사항 존재론, 전통적 단계 모델, 소프트웨어‑중심 설계, 방법론 효능에 대한 믿음이 실제 실천을 왜곡하고 연구·실무를 오도한다는 점을 분석하고, 증거 기반 실천을 통해 이를 극복할 방안을 제시한다.

상세 분석

논문은 먼저 “교리”를 ‘증거와 무관하게 받아들여지는 신념’으로 정의하고, 소프트웨어 공학에서 널리 퍼진 네 가지 교리를 차례로 해부한다. 첫 번째 교리인 “소프트웨어는 명확한 요구사항을 가진다”는 가정은 실제 현장에서 요구사항이 흐릿하고 진화한다는 경험적 연구와 충돌한다. 요구사항을 고정된 산출물로 취급하면 변화 관리 비용이 급증하고, 이해관계자와 개발자 사이의 협업을 저해한다. 두 번째 교리인 분석‑설계‑코딩‑테스트의 단계 구분은 전통적인 워터폴 모델에 뿌리를 두지만, 현대 애자일·DevOps 환경에서는 작업이 순환적이고 병렬적으로 진행된다는 실증적 증거가 다수 존재한다. 단계 구분을 고수하면 팀의 자율성과 피드백 루프가 약화된다. 세 번째 교리인 “소프트웨어 공학은 소프트웨어 자체 설계에 초점한다”는 관점은 시스템 전체, 특히 하드웨어·인간·조직적 요소와의 상호작용을 무시한다. 시스템 사고와 복합성 이론에 따르면, 소프트웨어는 전체 시스템의 한 부분에 불과하며, 이를 독립적으로 설계하면 통합 위험이 커진다. 네 번째 교리인 “방법론은 효과적으로 적용된다”는 믿음은 실제 프로젝트에서 방법론 채택률이 낮고, 적용 시에도 조직 문화·인력 역량·프로젝트 특성에 따라 성공이 크게 달라진다는 데이터를 간과한다. 저자는 이러한 교리들이 과학적 엄밀성을 가장한다 채택 과정에서 경험적 검증을 배제하고, 결과적으로 연구 주제 선정과 실무 지침을 왜곡한다는 점을 강조한다. 마지막으로 증거 기반 실천(Evidence‑Based Practice, EBP)을 도입하면 교리의 실효성을 체계적으로 검증하고, 실무자와 학계가 공통된 데이터 기반 위에서 논의를 전개할 수 있음을 제시한다.


댓글 및 학술 토론

Loading comments...

의견 남기기