소프트웨어공학 레포트 - 현대 소프트웨어 개발 환경에서 시스템의 규모와 복잡성 증가에 따른 문제점과 이에 대응하는

I. 서론

팀 프로젝트에서 로그인 기능을 맡았을 때 코드는 200줄 남짓이었는데도 다른 팀원의 수정 때문에 계속 예상 밖의 오류가 생겼다. 회원 정보 구조가 바뀌자 로그인 화면만 고치면 될 줄 알았지만 세션 처리, 권한 확인, 테스트 데이터까지 함께 손봐야 했다. 규모가 더 큰 서비스라면 한 기능의 수정이 몇 군데에 닿는지 파악하는 일부터 어려워질 것이다. 현대 소프트웨어의 문제는 코드 줄 수가 많다는 사실만으로 설명되지 않는다. 서로 연결된 모듈, 데이터, 외부 서비스, 배포 환경, 개발팀이 늘면서 관계의 수가 커지고, 그 관계가 변경의 위험을 만든다. 소프트웨어공학은 복잡성을 없애는 기술보다 복잡성이 통제 가능한 범위에 머물도록 만드는 방법들의 집합에 가깝다.

II. 본론

1) 기능 수보다 관계 수가 더 빠르게 늘어나는 시스템

시스템 규모가 커질 때 가장 먼저 나타나는 문제는 변경 영향 범위를 예측하기 어렵다는 점이다. 작은 프로그램에서는 한 사람이 전체 구조를 머릿속에 담을 수 있지만, 수십 개 서비스와 데이터 저장소가 연결된 환경에서는 어떤 코드가 어떤 기능을 호출하는지 전부 기억하기 힘들다. 결제 방식 하나를 추가했는데 주문 상태 처리나 환불 로직이 깨질 수 있고, 데이터베이스 컬럼 하나를 바꾸면서 통계 배치가 실패할 수도 있다. 각 부분이 맞게 동작해도 연결 지점에서 오류가 생긴다. 소프트웨어의 규모는 기능 목록의 길이만으로 재기 어렵고, 구성요소 사이의 의존 관계가 얼마나 복잡한지 함께 봐야 한다.

요구사항도 복잡성을 키운다. 서비스가 성장하면 사용자는 더 많은 기능을 원하고 법규, 보안, 접근성, 장애 대응 같은 비기능 요구도 늘어난다. 기능 요구는 화면이나 메뉴처럼 눈에 잘 띄지만 성능과 신뢰성은 문제가 생기기 전까지 잘 드러나지 않는다. 사용자가 갑자기 몰리는 날에 응답 속도가 느려지거나 한 지역의 서버 장애가 전체 서비스 중단으로 이어지면 설계 단계에서 놓친 품질 속성이 뒤늦게 비용으로 돌아온다. 개발 막바지에 성능과 보안을 덧붙이는 방식은 구조를 크게 뜯어고치게 만들 수 있다. 따라서 초기 요구 분석에서 기능뿐 아니라 성능 목표, 장애 허용 범위, 보안 수준, 변경 가능성을 함께 다뤄야 한다.

사람과 조직의 규모도 코드 복잡성과 연결된다. 개발자가 많아지면 병렬 작업이 가능하지만 의사소통 비용도 늘어난다. 같은 개념을 팀마다 다른 이름으로 부르거나 API의 의미를 다르게 이해하면 오류가 코드 작성 전에 생긴다. 문서가 낡으면 새로 합류한 개발자는 실제 코드를 뒤져 구조를 추측하게 되고, 특정 사람만 아는 지식이 쌓이면 그 사람이 빠졌을 때 유지보수가 막힌다. 버전 관리에서 충돌이 자주 나거나 비슷한 기능이 여러 곳에 중복 구현되는 일도 흔하다. 그래서 대규모 개발에서는 프로그래밍 실력뿐 아니라 공통 용어, 인터페이스 계약, 리뷰 절차, 기록 방식까지 설계 대상이 된다.