intro
sw개발자라면, software architecture라는 말을 들어본 적이 있을 것이다. 여기서 architecture란 무슨 말일까?
Architecture - Wikipedia 검색해 볼까?
Architecture is the art and technique of designing and building, as distinguished from the skills associated with construction. ~ 블라블라. 무언가를 디자인하는 기술 정도로 해석된다.
디자인으로 가볍게 생각해도 되지 않을까? 또한, 건물 사진이 대문짝만 하다. 물리적인 구조물 설계에 주로 쓰는 용어로 보인다.
software에도 architecture라는 용어를 쓴다. 이는 software도 디자인 기술을 익혀야, 멋진 software를 만들 수 있음을 유추해 볼 수 있다. 멋진 건물을 짓기 위해서 건축 디자인 방법을 알아야 하듯이, software도 마찬가지이다.
이번 포스팅에서는, software architecture의 중요성과 architecture의 재료인 프로그래밍 패러다임을 살펴보려고 한다.
software architecture는 왜 필요할까?
먼저, software가 무엇인지 알아야 한다. software는 말 그대로 soft + ware, 부드러운 제품으로 hardware와 다르게, 기계의 동작을 쉽게 변경할 수 있도록 하기 위해 존재한다.
그러나, sw 복잡도가 증가할수록, 변경사항 적용이 점점 힘들어진다. 이는 sw 비용 증가를 초래한다(유지보수하는데 sw개발 시간이 더 많이 소요되므로).
따라서, sw architect는 변경사항 적용이 쉬운 sw 구조를 만들어야 한다.
여기서 잠깐!?! sw 개발자로서 당신의 선택은?
완벽하게 동작, 수정 불가능한 프로그램 vs 동작은 하지 않지만 변경이 쉬운 프로그램
sw 개발자라면 보통 후자를 고를 것이다. 즉, sw 개발자에게는 기능보다 architecture가 중요하다.
("일정이 급하다고 architecture는 신경 쓰지 않고, 동작만 하면 되는 거지"라고 자기 위로한 나 자신을 반성한다.)
프로그래밍 패러다임
아키텍처를 얘기하다가 갑자기 웬 프로그래밍 패러다임일까? 프로그래밍 패러다임이 아키텍처의 방향을 결정하기 때문이다. 마치, 건물 재료가 무엇이냐에 따라, 건물 구조의 방향이 결정된다는 맥락 정도로 이해된다.
프로그래밍 패러다임을 이해해야, 언제 어떤 패러다임으로, 어떤 디자인 아키텍처로 해야 하는 지를 결정할 수 있지 않을까?
구조적 프로그래밍; 제어 흐름과 소스 코드 흐름이 같다.
goto문을 쓰면, 코드 흐름이 계속 바뀌어서, 기능적으로 모듈화가 어렵다.
그래서 goto문을 쓰지 않고, if/else, do/while과 같은 분기와 반복의 단순 제어 구조로 기능 단위로 프로그램을 모듈화 하는 방식이다. 이는 sw를 기능단위로 테스트할 수 있도록 해 준다.
객체지향 프로그래밍; 소스 코드 의존성을 설정할 수 있다.
객체지향이란, 캡슐화, 상속, 다형성 3가지 개념으로 이해하면 된다. 이 중에서 다형성이 main이다.
다형성의 힘은, 소스코드 의존성 방향을 역전하게 해 준다. 이는 어떤 장점이 있을까?
위의 그림을 보자. 다형성을 이용해서, HL1과 ML1 사이에 Interface를 추가했다.
이는 HL1이 ML1을 그대로 호출할 수 있으나, ML1 코드를 더 이상 의존하지 않게 된다.
즉, HL1과 ML1은 독립적으로 개발 배포가 가능하게 만든다.
함수형 프로그래밍; 가변성을 분리해야 한다.
자료 처리를 수학적 함수의 계산으로 취급하고, 상태와 가변성을 분리하는 프로그래밍 패러다임이다.
불변(Immutable) 컴포넌트에는 함수형 방식으로 작업 처리하고, 어떤 가변 변수도 사용하지 않는다.
가변(Mutable) 컴포넌트는 (가변) 변수 상태를 변경할 수 있는, 하나 이상의 다른 컴포넌트(위에서는 Transactional Memory)와 서로 통신한다.
reference
- Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 로버트 C. 마틴
- 구조적 프로그래밍 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)
- 소년코딩 - C++ 06.03 - goto 문 (goto statement) (tistory.com)
- 함수형 프로그래밍 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)
'컴퓨터 > Software Architecture' 카테고리의 다른 글
| [Clean Architecture] 컴포넌트 응집도: 3가지 원칙 (0) | 2023.02.26 |
|---|---|
| [Clean Architecture] SOLID 원칙, ISP(인터페이스 분리 원칙), DIP(의존성 역전 원칙) (0) | 2023.02.25 |
| [Clean Architecture] SOLID 원칙, LSP(리스코프 치환 원칙) (0) | 2023.02.25 |
| [Clean Architecture] SOLID 원칙, OCP(Open-Closed 원칙) (0) | 2023.02.25 |
| [Clean Architecture] SOLID 원칙, SRP(단일 책임 원칙) (0) | 2023.02.25 |
