설계 원리와 설계 기본 개념

[ 설계 원리 ]

요구 분석이 '무엇을 만들 것인가'를 다룬다면,

설계는 '어떻게 실현할 것인가'를 구체화하는 단계다.

즉 요구를 만족시키는 솔루션(구조/역할/인터페이스)을

결정하는 활동이며, 특히 아키텍처 설계가

품질(성능·보안·가용성 등)을 좌우한다.

 

학습 키포인트

• 설계 기본 개념과 과정은 무엇인가?
• 설계 작업에 고려하여야 할
  품질 목표에는 어떤 것들이 있는가?
• 전통적인 설계 원리는 어떤 것들이 있는가?
• 객체지향 설계 원리(SOLID) 등
  현대 설계 원리는 무엇인가?
• 아키텍처의 컴포넌트를
  효율적으로 구성하는 원리는 무엇인가?

---

1. 분석과 설계의 차이

요구 분석은 시스템이 담아야 할

기능/요구를 찾아 '무엇'을 정리한다.

설계는 그 요구를 만족시키기 위해

시스템의 논리 구성을 정해

'어떻게' 구현할지 결정한다.

 

건축 설계로 비유하면 집주인의 요구가

'침실 3개, 거실, 서재, 주방, 냉난방, 수도/전기, 욕실 2개'라면,
설계는 '거실은 1층 중앙, 침실은 2층, 주방/서재는 북쪽...'처럼

배치/구조/스타일을 선택해 도면을 만드는 일이다.

 

요구를 만족하는 방법은 여러 개가 가능하며,

그중 하나를 선택한 결과가 설계다.

[요구 분석]
- 중심: 고객/사용자 요구
- 산출: 요구 사항, 기능 목록, 유스케이스, 프로토타이핑
        |
        v
[설계]
- 중심: 솔루션
- 산출: 아키텍처 설계(구조/역할/인터페이스) + 상세 설계(알고리즘/데이터)
        |
        v
[구현]
- 산출: 코드, 제어 흐름, 실행 가능한 시스템

---

2. 설계에서 가장 중요한 것: 아키텍처

소프트웨어 설계에서 핵심은

기본 구조를 결정하는 아키텍처 설계다.

시스템 성능, 보안, 가용성 같은 품질은

'아키텍처를 어떻게 구성했는가'에 크게 의존한다.

 

설계는 임의로 고르는 작업이 아니다.

• 요구 변경(예: 확장 필요) 때문에
  구조를 바꾸는 경우가 있고
• 비용이 적거나 확장이 쉬운 구조를 선택하는 등
  원칙/근거 기반으로 최종안을 결정해야 한다

---

3. 설계 작업은 2가지로 나뉜다

설계는 크게 기본 구조 설계(아키텍처)와

상세 설계로 구분된다.

 

1) 기본 구조 설계(아키텍처 설계)

• 모듈(또는 서브시스템)의 역할을 정하고
• 모듈 간 인터페이스(통신 규약)를 정의한다.

2) 상세 설계

• 각 모듈 내부의 알고리즘, 데이터 구조를 구체화한다.

---

4. 설계는 창의적인 과정이지만, 커뮤니케이션이 핵심

설계는 개발자의 창의성이 발휘되는 과정이다.

동시에 분석 모델링과 완전히 분리되지 않고

함께 진행되기도 한다.

특히 커뮤니케이션이 중요한 이유는

아래 항목 때문이다.

• 구조 설계
  고객 요구(특히 비기능 요구) 충족 여부를 확인하며
  아키텍처/인터페이스를 확정해야 한다.
• 상세 설계
  고객과 직접 관련은 적더라도,
  개발자 간 협업을 위한 명확한 공유가 필요하다.

대규모 시스템은 복잡해서

원리 없이 접근하면 구조가 쉽게 무너진다.

그래서 설계에는 검증된 원리들이 반복적으로 사용된다.

---

5. 전통적인 설계 원리 vs 현대 설계 원리

전통적인 설계 원리

• 분할 정복: 복잡한 대상을 나눠서 하나씩 해결
• 계층화: 레벨(층)을 나눠 책임을 정리
• 모듈화: 변경 단위를 모듈로 분리
• 추상화: 핵심만 남기고 세부는 감춤

현대 설계 원리(객체지향/아키텍처 확장)

• 정보 은닉(information hiding)
  : 내부 구현/데이터를 외부에 노출하지 않기
• 인터페이스와 구현 분리
  : 약속(규격)과 실제 구현을 분리해 교체 가능하게
• 의존 관계 역전(Dependency Inversion)
  : 추상에 의존하도록 구조를 뒤집어 변경 영향 최소화

전통 원리(복잡도 관리)            현대 원리(변경 영향 최소화)
- 분할 정복                      - 정보 은닉
- 계층화                         - 인터페이스/구현 분리
- 모듈화                         - 의존 관계 역전
- 추상화                         -> 확장성, 유지보수성 강화

---

6. 설계 기본 개념: 서브시스템과 모듈

아키텍처는

'시스템을 구성하는 컴포넌트'와

'컴포넌트 간 상호작용'의 집합이다.

 

여기서 컴포넌트는 독립적으로 취급 가능한 단위이며,

보통 서브시스템 또는 모듈이라고 부른다.

 

서브시스템
클래스의 모임(패키지)로 볼 수 있고,

다른 서브시스템과 상호작용하기 위한 인터페이스를 가진다.

 

즉 복잡도를 줄이기 위해

시스템을 분할한 단위가 서브시스템이다.

 

복잡한 시스템은 서브시스템을

반복적으로 분할해 계층화할 수도 있다.

 

예시: Accounting 서브시스템이 제공하는 서비스(인터페이스)

• Enrolled(Student, Semester)
• PayTuition(Student, Amount)
• Leave(Student, Semester)
• Graduate(Student)

애플리케이션 아키텍처를 설계할 때는

구성요소(컴포넌트)를 정의하고,

컴포넌트 간 관계와 통신 인터페이스를

정하는 일이 대규모 시스템 개발에서 중요하다.

[UI] ---> [Register] ---> [Course]
            |
            v
       [StudentDB]

[Accounting] <----> [Register]
[Profile]    <----> [Register]

 

• 화살표는 의존/호출 관계를 의미한다.
• 핵심은 '서브시스템은 인터페이스로 상호작용한다'는 점이다.

---

7. 용어 정리: 컴포넌트 / 모듈 / 서브시스템

 

컴포넌트

• 명확한 역할을 가지며
  독립적으로 존재 가능한 시스템의 부분
• 대체 가능(동일 기능의 다른 컴포넌트로 교체 가능)
• 재사용 가능하도록 설계되는 경우가 많다
  (프레임워크도 일종의 컴포넌트)

모듈

• 프로그래밍 언어 문법 구조로 정의되는 구현 단위
• 예: Java의 메서드/클래스/패키지, C의 파일/함수

서브시스템

• 여러 방식으로 구현될 수 있는 더 추상적인 개체
• 시스템의 일부로서 유한한 인터페이스를 가지며
• 내부 구현이 바뀌거나 구성 요소가
  교체되어도 지속적으로 존재한다

---

8. 설계 관점(아키텍처 관점) 3가지

최근 아키텍처 기반 설계는

기능 구현 중심(Top-down/Bottom-up)에서 벗어나

품질 중심 설계로 이동했다.

이때 아키텍처는 일관된 관점(aspect)을 가진다.

 

1) 모듈 관점

책임을 구현한 코드 단위(모듈)와

관계로 구조를 설명

 

2) 컴포넌트 관점

실행 시 동작하는 요소와

상호작용으로 구조를 설명

 

3) 할당 관점

하드웨어 배치, 설치, 작업 할당,

구현, 데이터 저장을 포함한 관점

- 모듈 관점: 모듈과 관계로 구조를 설명(책임 중심)
- 컴포넌트 관점: 실행 요소와 상호작용으로 구조를 설명(동작 중심)
- 할당 관점: 배치/설치/데이터 저장 관점으로 구조를 설명(환경 중심)

 

---

9. 설계 작업 과정(아키텍처 설계 과정)

설계는 의사결정 과정이면서,

동시에 시스템을 알아가는 과정이다.

특히 시스템 유형이 중요하다.

시스템 유형에 따라 적합한

아키텍처 스타일이 달라지기 때문이다.

• 대화형 시스템
  : 계층 구조 스타일을 사용하는 경우가 많다
• 임베디드 시스템
  : 이벤트 스타일을 사용하는 경우가 많다

일반적인 설계 과정은 다음 흐름을 따른다.

 

1) 설계 목표 설정

전체 시스템 설계 목표 결정

예시)

전화 교환 시스템이라면 고장 내성(fault tolerance),

안전/보안, 최대 성능 등이 목표가 될 수 있다

 

2) 스타일 결정

목표와 시스템 유형에 맞는 아키텍처 스타일 선택

적용 가능한 표준 스타일이 있으면 적용, 없으면 맞춤형 아키텍처 설계

 

3) 서브시스템 기능/인터페이스 명세

서브시스템 간 인터페이스 정의

상호작용을 위한 동작(규약)을 작성

 

4) 아키텍처 설계 검토

요구/설계 목표/설계 원리를 만족하는지 검토

필요하면 피드백을 반영해 수정

[1 설계 목표 설정]
        |
        v
[2 스타일 결정]
        |
        v
[3 서브시스템 기능/인터페이스 명세]
        |
        v
[4 설계 검토]
        ^
        |
     (피드백)

---

10. 설계가 중요한 이유: 변경이 올 때 시스템이 버티는가

아키텍처 설계는 소프트웨어의 기본 프레임을 결정한다.
구조를 잘못 잡으면 '작동'은 되는데

유지보수/확장에 '취약한 시스템'이 된다.

 

강결합의 위험

애플리케이션 코드가

써드파티 데이터베이스 컴포넌트에 직접 의존하면,

 

데이터베이스가 바뀌는 순간

애플리케이션 코드 대부분을 수정해야 한다.

 

해결: 래퍼(wrapper)로 데이터베이스 숨기기

애플리케이션 객체에서

DB를 직접 보지 않도록 래퍼(추상화 계층)를 둔다.

그러면 DB가 바뀌어도

비즈니스 객체는 그대로 두고

래퍼만 수정하면 된다.

비즈니스 객체보다 래퍼가 변경하기 쉬우므로

전체 변경 비용이 크게 줄어든다.

 

이때 적용되는 설계 원리가

종속성 규칙(dependency rule)이다.

서로의 의존도를 낮춰 변경의 영향을 최소화하면

유지보수가 쉬워지고 확장성이 높아진다.

1) 직접 의존(변경에 취약)
[Business 객체들] ---> [Third-party DB 컴포넌트]

2) 래퍼로 캡슐화(변경 영향 최소화)
[Business 객체들] ---> [DB Wrapper] ---> [DB]
- DB가 바뀌면 Wrapper만 수정
- Business는 보호됨

---

마무리 정리 

1. 설계는 요구를 만족시키는
   '구조적 솔루션'을 결정하는 단계다.
2. 아키텍처 설계가 품질(성능/보안/가용성)을 크게 좌우한다.
3. 전통 원리(분할정복·계층화·모듈화·추상화)와
   현대 원리(정보은닉·인터페이스/구현 분리·의존 역전)는
   변경에 강한 구조를 만든다.
4. 설계 관점(모듈/컴포넌트/할당)으로 구조를 바라보면
   의도가 명확해지고 협업이 쉬워진다.
5. 래퍼 같은 구조는 종속성 규칙을 통해 변경의 파급을 통제한다.