구조적 방법론으로 복잡한 소프트웨어를 분해하는 법

복잡성을 기능과 흐름으로 나누는 접근

구조적 방법론은 1970년대에 등장한 소프트웨어 개발 방법론이다. 복잡한 시스템을 분석과 설계의 대상으로 다룰 수 있도록 단순화하고, 표준화된 절차로 개발 과정을 관리하는 데 초점을 둔다. 문제를 상위 수준에서 먼저 나눈 뒤 해법을 점차 구체화하는 하향식(Top-down) 접근이 중심이다.

설계의 경계를 만드는 원리

추상화(Abstraction)는 문제에서 본질적인 특성만 남겨 복잡성을 줄인다. 은행 시스템의 계좌 관리를 모델링할 때 계좌번호와 잔액처럼 필요한 정보에 집중하고, 불필요한 세부사항은 제외하는 방식이다.

정보 은닉(Information Hiding)은 모듈의 내부 데이터와 동작 방식을 외부에 드러내지 않는 원칙이다. 모듈은 정해진 인터페이스로만 상호작용하므로, 인증 모듈의 암호화 알고리즘을 바꿔도 다른 모듈에 미치는 영향을 줄일 수 있다.

분할과 정복(Divide and Conquer)은 큰 문제를 관리 가능한 하위 문제로 나누고, 각각을 해결한 뒤 통합한다. 급여 시스템을 직원정보관리, 급여계산, 세금처리 모듈로 구분하는 사례가 이에 해당한다. 복잡성 관리뿐 아니라 팀의 작업 분담에도 적합하다.

단계적 상세화(Stepwise Refinement)는 상위 수준의 설계를 세부 설계로 계속 풀어내는 과정이다. 주문처리라는 기능은 주문입력, 주문검증, 재고확인, 결제처리로 구체화할 수 있다.

모듈화(Modularization)는 시스템을 기능적으로 독립된 단위로 나누는 일이다. 각 모듈이 단일 기능에 집중하면 독립적인 개발과 테스트가 가능하며, 재사용성과 유지보수성도 높아진다. 회원관리, 상품관리, 결제처리, 배송관리를 별도 모듈로 구성하는 방식이 대표적이다.

요구를 모델로 옮기는 과정

요구분석(Requirement Analysis)에서는 사용자 요구사항을 수집·분석·문서화하고, 시스템의 목표와 범위를 정한다. 요구사항 명세서와 타당성 분석 보고서가 주요 산출물이며, 인터뷰·설문조사·관찰·문서 검토 등을 활용한다. 예를 들어 요구사항은 다음처럼 표현될 수 있다. 시스템은 분당 최소 100건의 주문을 처리할 수 있어야 한다.

구조적 분석(Structured Analysis)은 이렇게 정리된 요구사항을 기능 모델로 변환하는 단계다. 시스템의 기능 요소와 데이터 흐름을 식별하는 데 DFD, 데이터 사전, 미니명세서를 사용한다.

데이터의 이동을 보여 주는 DFD

데이터 흐름도(DFD, Data Flow Diagram)는 시스템 안에서 데이터가 이동하고 처리·저장되는 모습을 그래픽으로 표현한다. 프로세스는 원, 데이터 흐름은 화살표, 데이터 저장소는 평행선, 외부 개체는 사각형으로 나타낸다.

⤢✕

데이터 사전과 미니명세서

데이터 사전(DD, Data Dictionary)은 시스템에서 쓰는 모든 데이터 요소의 정의와 특성을 문서화한다. 데이터 항목과 구조, 흐름, 저장소에 관한 상세 정보를 제공한다.

주문정보 = 주문번호 + 고객ID + 주문일자 + {주문상품} + 결제정보
주문상품 = 상품코드 + 수량 + 단가
결제정보 = 결제방법 + 결제금액 + [카드정보]
카드정보 = 카드사 + 카드번호 + 만료일

미니명세서(Mini Specification)는 DFD에 나타난 각 프로세스의 상세 로직을 기술한다. 구조적 영어, 의사코드, 결정 테이블 등을 이용한다.

프로세스: 주문유효성검증
1. 고객ID 존재여부 확인
2. 각 주문상품의 재고 확인
3. IF (모든 재고 충분) THEN
     주문상태 = "승인"
   ELSE
     주문상태 = "재고부족"
     부족상품 목록 생성
   ENDIF
4. 주문결과 반환

아키텍처에서 보는 응집도와 결합도

구조적 설계(Structured Design)는 분석 모델을 소프트웨어 아키텍처로 바꾸는 단계다. 시스템 구성 요소와 상호작용을 정의하고, 모듈과 인터페이스를 설계한다.

모듈 응집도(Cohesion)는 모듈 내부 요소들이 얼마나 밀접하게 관련되는지를 뜻한다. 높은 응집도가 바람직하며 기능적 응집도가 가장 높은 형태다. 낮은 수준부터 높은 수준까지 우연적 응집도, 논리적 응집도, 시간적 응집도, 절차적 응집도, 통신적 응집도, 순차적 응집도, 기능적 응집도로 구분한다.

우연적 응집도: 서로 관련 없는 기능들이 한 모듈에 존재
논리적 응집도: 논리적으로 유사한 기능들을 그룹화
시간적 응집도: 동시에 실행되는 기능들의 그룹화
절차적 응집도: 순차적으로 실행되는 기능들의 그룹화
통신적 응집도: 동일한 데이터를 사용하는 기능들의 그룹화
순차적 응집도: 한 기능의 출력이 다른 기능의 입력이 되는 경우
기능적 응집도: 단일 목적을 위한 모든 요소가 결합된 경우

모듈 결합도(Coupling)는 모듈 사이의 상호의존성 정도다. 낮은 결합도가 바람직하고, 데이터 결합도가 가장 낮은 형태다. 높은 수준에서 낮은 수준으로 내용 결합도, 공통 결합도, 제어 결합도, 스탬프 결합도, 데이터 결합도로 나뉜다.

내용 결합도: 한 모듈이 다른 모듈의 내부 동작에 직접 의존
공통 결합도: 전역 데이터를 공유하는 모듈 간 결합
제어 결합도: 한 모듈이 다른 모듈의 내부 논리를 제어
스탬프 결합도: 모듈 간에 데이터 구조를 전달
데이터 결합도: 모듈 간에 필요한 데이터만 매개변수로 전달

⤢✕

제어 흐름을 제한하는 구조적 프로그래밍

구조적 프로그래밍(Structured Programming)은 구조화된 코드 작성을 위한 프로그래밍 패러다임이다. 순차, 선택, 반복 구조를 사용하고 goto 문장은 지양한다.

함수와 루틴에는 하나의 진입점과 하나의 종료점만 두는 단일 입출구 원칙을 적용한다. 가독성과 디버깅이 쉬워진다. 제어 구조는 다음 범위 안에서 구성한다.

순차(Sequence): 명령어를 순차적으로 실행
선택(Selection): if-then-else, switch-case 구문
반복(Iteration): for, while, do-while 루프

모듈 크기는 한 화면(약 50줄)에 표시할 수 있는 범위로 제한한다. 코드의 가독성과 이해도를 높이기 위한 기준이다.

⤢✕

은행 업무 시스템에 적용하는 모습

은행 업무 시스템에서는 계좌관리, 입출금 처리, 대출관리 등의 기능을 요구분석 단계에서 정의한다. 구조적 분석에서는 DFD로 고객·창구직원·시스템 사이의 데이터 흐름을 모델링하고, 데이터 사전으로 계좌정보와 거래내역의 구조를 정의한다.

구조적 설계 단계에서는 계좌관리, 거래처리, 보고서생성 모듈을 구성한다. 각 모듈이 단일 기능에 집중하도록 높은 응집도를 확보하고, 표준화된 인터페이스로 통신해 낮은 결합도를 지향한다. 구현에서는 거래 유효성 검증, 잔액 확인, 트랜잭션 처리, 결과 반환의 순차적 흐름을 적용할 수 있다.

선택할 때 고려할 점

구조적 방법론은 복잡한 문제를 체계적으로 분해해 관리할 수 있게 하며, 표준화된 문서와 도구로 의사소통을 돕는다. 유지보수성과 재사용성을 높이고, 하향식 접근을 통해 초기 시스템 구조를 명확히 하며, 팀 작업 분담과 협업을 지원한다.

반면 변화에 유연하게 대응하기 어렵고 사용자 참여가 초기에 집중되는 경향이 있다. 객체지향 개념을 반영하지 못하며, 대규모 시스템에서는 문서 작업이 과도해질 수 있다. 반복적 개발과 프로토타이핑 지원도 미흡하다.

이후 방법론으로 이어진 흐름

구조적 방법론은 객체지향 방법론과 애자일 방법론 등 현대적 방법론의 기초가 됐다.

⤢✕

추상화, 정보 은닉, 분할과 정복 같은 원칙은 이후 방법론에서도 계속 활용된다. 객체지향과 애자일이 등장한 뒤에도, 요구사항이 명확하고 체계적인 접근이 필요한 영역에서는 구조적 방법론의 관점이 유효하다.