구조적·정보공학·객체지향·CBD·제품계열 방법론

핵심 요약

소프트웨어 개발 방법론은 소프트웨어를 개발할 때 수행할 절차, 사용할 기법·도구, 역할, 산출물 등을 체계화한 것이다. 방법론을 구분할 때는 무엇을 중심으로 시스템을 나누는지와 무엇을 재사용하는지를 먼저 확인한다.

구조적 방법론은 기능과 처리 흐름, 정보공학은 전사 데이터와 업무, 객체지향은 객체의 책임과 협력, CBD는 컴포넌트 조립, 제품계열은 관련 제품의 공통성과 차이를 중심으로 한다.

1. 다섯 방법론 비교

방법론, 생명주기 모델, 모델링 언어는 서로 다르다. 폭포수·나선형은 활동의 배치 방식, 객체지향 방법론은 분석·설계·개발 접근, UML은 모델을 표현하는 언어다.

2. 구조적 방법론

복잡한 시스템을 큰 기능에서 작은 기능으로 분해하는 하향식 접근을 사용한다. 기능 분해를 통해 각 부분의 역할을 명확하게 하고, 모듈 간 결합을 낮추며 모듈 내부의 응집을 높이는 설계를 지향한다.

구조적 분석과 구조적 설계의 산출물을 구분한다.

DFD는 처리·자료흐름·자료저장소·외부 개체로 시스템을 나타낸다. 프로그램 명령의 실행 순서를 그리는 순서도와는 다르다. 상위 DFD를 하위로 상세화할 때 외부와 주고받는 데이터 관계를 일관되게 유지하는 것이 중요하다.

“DFD가 모듈 호출 계층을 직접 표현한다”는 설명은 구조도와 혼동한 것이다. 구조적 분석은 구현 전에 무엇을 처리해야 하는지를 명확히 하는 데 초점을 둔다.

3. 정보공학 방법론

정보공학(Information Engineering)은 기업 전체의 정보 요구를 업무와 데이터 중심으로 분석하고 통합 시스템을 구축하는 접근이다. 특정 DB 제품의 사용법이나 정규화 기법 하나를 뜻하지 않는다.

전형적인 진행 흐름은 다음과 같다.

정보전략계획 → 업무영역 분석 → 업무시스템 설계 → 시스템 구축

정보전략계획에서는 조직의 목표와 정보화 방향을 연결한다. 업무영역 분석에서는 업무와 데이터의 관계를 파악한다. 이후 이를 지원하는 시스템을 설계하고 구현한다. 전사 데이터 모델은 부서마다 다르게 쓰이는 고객·제품·계약 등의 의미를 통일하는 데 도움을 준다.

CRUD 매트릭스는 업무와 데이터 사이의 생성(Create)·조회(Read)·수정(Update)·삭제(Delete) 관계를 표로 나타낸다. 단순한 프로그램 실행 일정표와 구분한다.

예를 들어 영업부와 회계부의 고객 코드가 달라 연결이 어렵다면, 부서별 프로그램의 기능 분해보다 전사 데이터 정의와 통합 관계를 먼저 정리하는 정보공학 관점이 중요하다.

4. 객체지향 방법론

객체지향은 데이터와 그 데이터를 다루는 행위를 객체로 묶고 객체 간 메시지와 협력으로 시스템을 구성한다.

클래스는 공통 속성과 행위를 정의한 틀이며, 객체·인스턴스는 그 틀에 따라 만들어진 구체적인 실체로 이해할 수 있다. 분석에서는 필요한 객체와 책임을 찾고, 설계에서는 관계·인터페이스·협력을 구체화한다.

예매 시스템에서 공연·좌석·예매를 객체로 표현하고 각 객체가 자신의 상태와 행위를 책임지도록 구성한다면 객체지향 관점이다. 단순히 Java나 C++을 사용했다는 사실만으로 분석·설계가 적절한 객체지향 방식이라는 보장은 없다.

5. CBD: 컴포넌트 기반 개발

CBD(Component Based Development)는 재사용 가능한 컴포넌트를 탐색·평가하고, 필요한 부분을 개발·조정한 뒤 조립·통합하는 방법이다.

컴포넌트는 명확한 인터페이스로 기능을 제공하는 소프트웨어 단위다. 내부 구현을 모두 알지 않아도 명세에 따라 사용하도록 하는 것이 중요하다. 컴포넌트는 클래스나 객체 한 개와 반드시 일치하지 않는다. 여러 클래스·모듈을 포함할 수 있다.

대표 흐름은 요구 분석 → 컴포넌트 탐색·선정 → 부족한 기능 개발·적응 → 조립·통합 → 시험이다. 기존 컴포넌트와 요구사항의 차이, 인터페이스 호환성, 성능과 품질을 확인해야 한다.

검증된 인증·결제·알림 컴포넌트를 조립하면 개발 기간을 줄일 수 있다. 그러나 “재사용했으므로 통합 시험이 필요 없다”는 결론은 틀리다. 개별 컴포넌트가 정상이어도 결합한 시스템에서 오류가 발생할 수 있다.

COTS는 상용 기성 소프트웨어를 뜻한다. CBD가 기성품을 활용할 수는 있지만, 모든 컴포넌트가 상용 제품이어야 하는 것은 아니다.

6. 소프트웨어 제품계열

소프트웨어 제품계열(Software Product Line)은 관련 제품들이 공통 핵심 자산을 공유하면서 제품별 차이를 계획적으로 반영하도록 개발하는 접근이다.

공통성은 제품군이 함께 갖는 특성이고, 가변성은 제품에 따라 선택·변경되는 특성이다. 공통 구조, 컴포넌트, 요구 모델, 시험 자산 등을 재사용할 수 있다.

예를 들어 기본 결제 기능은 같지만 고객별로 정산·회원·할인 기능이 다른 여러 판매 시스템을 만든다고 하자. 공통 기반을 먼저 정리하고 제품별 선택을 구성하면 제품계열 관점이다. 공통 자산을 구축하는 도메인 공학과 이를 사용해 개별 제품을 만드는 애플리케이션 공학을 구분한다.

CBD는 주로 한 시스템에서 컴포넌트를 재사용하는 방법에, 제품계열은 관련 제품군 전체의 공통성과 차이를 관리하는 방식에 초점이 있다. 단순히 소스를 복사하여 제품마다 따로 고치는 방식과는 다르다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

방법론별 산출물과 판단 차이

구조적 방법론

자료 흐름도(DFD)는 자료의 이동과 처리를 표현한다. 자료 사전은 흐름·저장소 등에서 사용하는 자료 항목의 이름, 의미, 구성과 형식을 정의한다. 최소 명세(Mini-spec)는 더 분해하지 않는 기본 처리의 내부 논리를 기술하며 구조적 언어, 결정표, 결정 트리 등을 사용할 수 있다. 자료 사전이 처리 알고리즘 전체를 대신하지는 않는다.

상위 처리를 하위 DFD로 분해할 때 상위 경계를 드나드는 입출력과 하위 도식 경계의 입출력이 대응해야 한다. 이를 균형성으로 이해한다. 세부 내부 흐름이 늘어나는 것은 가능하지만 상위 경계에 없는 외부 입출력을 설명 없이 추가하면 일관성이 깨진다.

정보공학 방법론

데이터 중심의 장기적인 정보 구조와 업무 프로세스의 관계를 함께 설계한다. CRUD 행렬은 프로세스와 데이터의 생성(Create)·조회(Read)·변경(Update)·삭제(Delete) 관계를 표시한다. 조회·변경은 있는데 생성 주체가 없다면 외부 유입, 초기 적재 또는 생성 업무의 누락 여부를 확인한다. 행렬의 빈칸 하나가 언제나 오류라는 뜻은 아니다.

객체지향·CBD·제품계열

추상화는 목적에 중요한 속성과 동작을 남기고 불필요한 세부 사항을 감추는 모델링이다. 다형성은 공통 인터페이스의 같은 호출이 실제 객체의 구현에 따라 다르게 동작하는 성질이다. 캡슐화는 상태와 동작을 묶고 외부 접근을 통제하는 것이며 단순히 이름을 감추는 것만으로 완성되지 않는다.

컴포넌트 교체는 함수 이름과 매개변수 형식만 같다고 충분하지 않다. 금액 단위, 오류 의미, 선행·후행 조건, 트랜잭션 보장과 같은 계약도 맞아야 한다. 외부 상용 컴포넌트(COTS)는 소스 코드가 제공된다고 가정할 수 없으므로 공개 인터페이스·라이선스·교체 가능성을 확인한다.

제품계열은 공통 자산을 바탕으로 변이 지점을 선택하여 관련 제품들을 만든다. 기능 모델에서는 필수·선택·대안 관계뿐 아니라 requires, excludes 같은 기능 간 제약을 함께 확인한다. 예를 들어 '실시간 알림은 메시지 모듈 필요'와 '오프라인 전용 제품은 네트워크 기능 제외' 조건이 있다면 기능을 독립적인 체크박스처럼 선택할 수 없다.