아키텍처 기초

[ 아키텍처 기초 ]

오늘의 학습 키포인트

• 소프트웨어 아키텍처란 무엇인가
• 아키텍처는 왜 필요해졌는가
• 아키텍처는 개발 과정에서 어떤 역할을 하는가
• 아키텍처는 어떻게 표현하는가(계층적 분할)
• UML 패키지 다이어그램으로 구조를 어떻게 나타내는가
• 디자인 패턴은 아키텍처와 어떤 관계인가

---

1) 왜 '아키텍처'가 필요해졌나

프로그램이 작을 때는 한 번에

이해하고 설계하는 게 가능했다.

 

하지만 규모가 커지면 전체를 동시에

작업하거나 머릿속에 올려두기가 어렵다.

 

해결책은 '추상화'이고, 그 추상화를

실무적으로 가능하게 만드는 방법이 '그룹화'다.

 

아키텍처는 그 그룹 수준에서

시스템을 설계하는 개념이다.

 

흐름도로 정리

[프로그램 규모 증가]
↓
[전체를 한꺼번에 이해/작업 어려움]
↓
[추상화 필요]
↓
[구성요소를 덩어리로 묶기(그룹화)]
↓
[그룹 수준에서 구조/관계/통신을 설계]
↓
[소프트웨어 아키텍처]

 

핵심 배경(인지 한계) 정리

관찰	의미	결과
단기 기억은 보통5~9개 항목 정도만 다루기 쉽다	복잡한 구조를 그대로 들고 설계하기 어렵다	더 큰 단위로 묶어 생각해야 한다
프로시저가 많아지면 전체를 동시에 파악하기 힘들다	'전체를 한 번에'가 불가능해진다	그룹 단위의 설계가 필요해진다

---

2) 아키텍처의 의미: '서브시스템 수준의 덩어리화(chunking)'

아키텍처는 클래스보다 높은 수준에서

'구성 요소와 그 관계'를 다룬다.

 

특히 다음을 중심으로 잡는다.

• 무엇이 구성 요소(컴포넌트)인가
• 각 구성 요소의 역할은 무엇인가
• 구성 요소 간 통신은 어떻게 하는가
• 연결은 어떤 방식이고, 인터페이스는 무엇인가

아키텍처가 다루는 범위를

표로 정리하면 다음과 같다.

항목	아키텍처에서 다루는 내용	메모
구성 요소	클래스/프로세스/프로그램 등 높은 추상 수준의 단위	'덩어리'로 본다
관계	구성 요소 간 연결 유형, 의존, 상호작용	구조의 뼈대
통신	구성 요소 간 통신 방식/프로토콜	인터페이스로 드러남
역할	각 구성 요소가 맡는 책임	분업의 기준이 됨

여기서 역할과 관계가 잘 알려진

통 유형을 '아키텍처 스타일'이라고 한다.

 

적용 분야에 따라 스타일을 선택하고,

그 스타일을 바탕으로 뼈대를 구성한 뒤

필요한 구성 요소를 추가 배치하는 것이 중요하다.

---

3) '아키텍처'와 '디자인 패턴'의 관계

디자인 패턴은 '아키텍처 구성 요소 내부에서

일어나는 상세 설계'에 필요한 지식이다.

자주 접하는 문제에 대한 설계 솔루션을 제공한다.

 

아키텍처와 디자인 패턴의 관계를

한 번에 구분하면 다음 표로 정리할 수 있다.

구분	아키텍처	디자인 패턴
초점	큰 구조 (구성 요소, 관계, 통신)	내부 설계 (객체/클래스 수준 문제 해결)
적용 범위	서브시스템/컴포넌트 수준	컴포넌트 내부의 상세 설계
목적	전체 시스템 뼈대 확립, 품질 요구 반영	반복되는 설계 문제를 검증된 해법으로 단순화
예시	클라이언트-서버 구조, 컴포넌트 인터페이스	싱글톤, 중재자 등

패턴 지식은 설계 단계에서 마주치는 문제를

'이미 해답이 알려진 문제'로 바꿔주기 때문에,

작업 난이도를 낮추고 설계를 단순화하는 효과가 있다.

---

4) 아키텍처란 무엇인가: 웹 시스템 예시로 이해하기

정의 자체는 다음으로 잡을 수 있다.

소프트웨어 아키텍처는 높은 추상 수준의

구성 요소(예: 클래스, 프로세스, 프로그램)의 구조와

구성 요소 간 관계, 연결 유형 및 상호작용을 의미한다.

 

웹 기반 시스템은 전형적으로

'클라이언트-서버' 아키텍처로 설명된다.

구성 요소	역할	연결
클라이언트(브라우저)	서비스를 요청	HTTP
서버(웹 서버)	서비스를 제공	HTTP

 

 

웹 시스템 특성도 같이 정리할 수 있다.

특성	의미
서버는 클라이언트에 대한 사전 지식이 없다	서버가 특정 클라이언트를 미리 알고 있는 구조가 아니다
클라이언트는 서버 위치를 정확히 모른다	DNS를 통해 서버를 찾는다
HTTP는 상태 없는 통신이다	상태 변화 메커니즘이 없으면 연결은 기본적으로 '무상태'가 된다

---

5) 아키텍처의 역할: 개발 전 과정의 중심축

아키텍처는 요구 분석부터 설계, 구현, 통합, 테스트까지

전체 과정에 영향을 주는 초기 의사 결정의 핵심이다.

 

특히 비기능 요구(유지보수성, 확장성, 성능 등)를

시스템에 녹여 넣는 역할이 크다.

 

개발 흐름에 맞춰 아키텍처가 하는 일을

표로 대체하면 다음처럼 된다.

단계	아키텍처 관점에서 하는 일	결과물/효과
요구사항 분석	비기능 요구를 제약사항으로 끌어올림	후속 개발의 기준이 생김
아키텍처 설계	제약사항 반영, 컴포넌트 구조 확립	시스템 뼈대
상세 설계	컴포넌트 내부 설계 (패턴 활용 영역)	구체 설계안
구현	컴포넌트 구현	동작 가능한 구성 요소
통합 및 시험	인터페이스 중심으로 통합/시험	시스템 완성도 검증

Unified Process 같은 프로세스 모델에서도

아키텍처는 초기에 확립하고,

설계에서 시각화/문서화하며,

구현까지 계속 참조하는 핵심 축으로 다뤄진다.

 

즉,

실행 가능한 아키텍처를
지속적으로 발전시키는 관점이다.

---

6) 아키텍처 표현: 계층적 분할(hierarchical decompositions)

좋은 아키텍처는 복잡한 시스템을 간단히 요약한다.

표현의 핵심은 '추상화'다.

• 불필요한 상세를 생략한다
• 중요한 문제에 관심을 집중한다
• 컴포넌트는 블랙박스로 두고,
  외부에 드러나야 할 구조적 속성만 나타낸다

계층적 분할은 '수준을 나눠서' 보여주는 방식이다.

한 장면을 텍스트 다이어그램으로 바꾸면 다음과 같다.

최상층(큰 구조)
[클라이언트] → [브로커] → [서버]

분할(브로커/서버를 더 자세히)
[클라이언트] → [브로커]
├─ [메시지 처리기]
└─ [디렉토리 서비스]
↓
[서버]
├─ [보안 서버]
├─ [요구 처리기]
└─ [데이터 저장소]

여기서 포인트는 '어디까지 분할하느냐'다.

• 어떤 컴포넌트는 더 이상 분할하지 않을 수 있다
• 그 의미는 해당 내부 구조가 전체 시스템의
  비기능적 품질 목표에 상대적으로 덜 중요하다는 뜻이다.
• 내부 상세는 컴포넌트 개발자에게 위임되고
  아키텍처 수준에서는 축약한다

---

7) UML 패키지 다이어그램: 서브시스템 구조를 표현하는 도구

패키지는 클래스를 의미 있는

관련 그룹으로 묶는 메커니즘이다.

Java의 package 선언과 자연스럽게 매핑된다.

 

패키지로 얻는 효과를 정리한 표

포인트	내용
복잡도 제어	시스템을 서브시스템으로 나눠 관리한다
재사용/사용성	내부 상세를 몰라도 import로 사용 가능하다
높은 수준 표현	클래스 묶음이므로 추상화된 컴포넌트를 표현하기 좋다
중첩 가능	패키지 안에 패키지를 넣어 구조를 표현할 수 있다

 

의존 관계(패키지 다이어그램에서 자주 쓰는 장면)는

이렇게 표현된다.

[myGUI] ─────▶ [java.awt]
의미: myGUI가 java.awt의 내용을 사용한다(의존한다)

 

중첩 패키지(패키지 안에 패키지) 예시는

이런 구조로 이해하면 된다.

[Clerk User Interface]
├─ [Customer 클래스]
├─ [RentalUI 클래스]
└─ [Business System Client 패키지]

---

8) Note: 패키지로 분할하는 방법(가이드 체크리스트)

패키지 분할의 기준은

기능적으로 관련 있는 클래스를

같은 서브시스템에 모으는 것이다.

 

유스케이스 하나를 기준으로 연관 클래스를

같은 서브시스템으로 그루핑하는 접근도 가능하다.

 

가이드는 체크리스트로 바꾸면

다음 표처럼 보기 좋아진다.

가이드	핵심	피해야 할 것
일관된 패키지 만들기	기능/관련성으로 그룹화	관련 없는 클래스가 섞인 큰 모놀리식 패키지
목적을 반영하는 이름	클래스 목적/기능이 드러나는 이름	의미 없는 이름
하위 패키지 사용	규모가 크면 하위로 더 나눔	한 패키지에 과밀 수용
패키지 없는 클래스 피하기	패키지 선언 없이 두지 않기	루트에 떠도는 클래스
패키지-디렉토리 구조 일치	탐색을 쉽게 하는 일관성	구조가 뒤섞인 경로
순환 종속성 피하기	패키지 간 순환 의존 최소화	A↔B 같은 고리 의존

패키지로 분할하면 클래스 사이 의존을 최소화할 수 있어

솔루션 도메인의 복잡성을 줄이는 데 도움이 된다.

---

9) 예시 패키지 구조 만들어보기

사원 관리 애플리케이션 예시 구조는

다음처럼 제시할 수 있다.

com.example.myapp
├─ model : Employee 및 관련 도메인 클래스
├─ dao : 데이터베이스 접근 객체
├─ service : 데이터 처리 기능이 들어 있는 서비스 클래스
└─ util : 공통 유틸리티 클래스

---

[ 마무리 ]

• 아키텍처는 큰 시스템을 '그룹 수준에서'
  설계하기 위한 추상화 방식이다.
• 아키텍처는 구성 요소, 관계, 통신, 인터페이스를
  정의해 개발 전 과정의 뼈대가 된다.
• 표현은 불필요한 상세를 생략하고
  계층적 분할로 수준별 구조를 보여주는 것이 핵심이다.
• 패키지 다이어그램은 서브시스템 구조를 표현하기에 적합하고,
  패키지 분할 가이드를 따르면 복잡도와 의존을 줄일 수 있다.
• 디자인 패턴은 아키텍처 내부의 상세 설계에서 반복 문제를
  검증된 해법으로 단순화하는 역할을 한다.