소프트웨어공학 레포트 - 소프트웨어의 개발과정과 건축 공학 단계의 유사성을 고려할 때, 요구사항 변경에 따른 추가

I. 서론

팀 과제로 작은 웹 서비스를 만들 때 로그인 화면의 버튼 색을 바꾸자는 의견에는 아무도 긴장하지 않았다. 그런데 발표를 2주 앞두고 "회원마다 권한을 나누고 관리자 기능도 넣자"는 말이 나오자 분위기가 달라졌다. 화면 하나를 더 만드는 일처럼 들렸지만 데이터베이스 구조, 로그인 처리, 메뉴 노출, 테스트 항목까지 함께 바뀌었다. 이미 만든 부분을 뜯어고치는 시간이 새 기능을 만드는 시간보다 길었다. 건물을 올리는 중간에 방의 용도와 출입 동선을 바꾸는 일과 꽤 닮아 있었다. 요구사항 변경의 비용이 왜 심각한지는 변경량 자체보다 이미 연결된 작업이 얼마나 많은지에서 드러난다.

II. 본론

1) 설계 변경이 뒤 공정을 흔드는 공통 구조

건축과 소프트웨어 개발은 결과물의 재료가 전혀 다르지만 작업이 이어지는 방식에는 닮은 점이 있다. 건축에서는 발주 목적과 요구를 확인하고, 설계를 만들고, 구조와 설비를 구체화한 뒤 시공하고 검사한다. 소프트웨어도 사용자 요구를 분석하고 시스템 구조와 세부 기능을 설계한 다음 구현과 테스트를 거쳐 배포한다. 앞 단계에서 정한 내용이 뒤 단계의 작업 기준이 된다는 점이 핵심이다. 초기에 요구가 달라지면 문서와 모형을 고치면 되지만 뒤로 갈수록 수정 대상이 실제 산출물과 여러 연결 관계로 늘어난다.

건축 현장을 떠올리면 비용 증가가 직관적으로 이해된다. 기초 공사 전에 벽 위치를 옮기면 도면을 수정하는 것으로 끝날 수 있다. 골조가 올라간 뒤 같은 변경을 요구하면 이미 설치한 자재를 철거하고 배관과 전기선을 다시 배치해야 할 수 있다. 준공 직전이라면 안전 검토와 인허가 문서까지 건드릴 가능성이 생긴다. 변경 내용은 "벽 하나 이동"으로 같아도 결정 시점에 따라 영향 범위가 달라진다. 이미 투입한 비용을 회수하기 어렵다는 점도 부담을 키운다.

소프트웨어에서도 요구사항은 설계와 구현의 출발점이 된다. 김유경의 2023년 연구는 소프트웨어 요구사항이 작업, 비용, 기간을 정량화하고 분석부터 유지보수까지 의사결정의 기준이 된다고 설명한다. 요구사항이 명확해야 개발자와 사용자가 같은 결과물을 상상할 수 있다. "검색이 빨라야 한다"는 표현만으로는 부족하고 어느 데이터에서 어느 정도 응답시간을 기대하는지 구체화해야 설계와 시험 기준을 만들 수 있다. 모호한 요구는 뒤 단계에서 해석 차이로 돌아온다.

그렇다고 건축 비유를 그대로 가져오면 소프트웨어의 특성을 놓칠 수 있다. 코드는 벽돌처럼 눈앞에 쌓이지 않고 복제와 수정도 상대적으로 쉽다. 화면 문구 하나는 몇 분 만에 바꿀 수 있고 새 파일을 배포하는 데 물리적 철거가 필요하지 않다. 그래서 소프트웨어 변경은 언제든 싸게 할 수 있다는 오해가 생긴다. 문제는 수정이 쉬운 대상과 어려운 대상이 같은 코드 안에 섞여 있다는 데 있다. 글자 하나를 고치는 일과 데이터 구조를 바꾸는 일은 모두 "변경"이지만 비용의 크기가 완전히 다르다.