[클린 아키텍처] 2부. 벽돌부터 시작하기 : 프로그래밍 패러다임

출처 : yes24

 

🎯 프로그래밍 패러다임 : 3가지 패러다임

• 구조적 프로그래밍 
• 객체지향 프로그래밍 
• 함수형 프로그래밍 

 

---

❗ 구조적 프로그래밍

1) 탄생과정

• "데이크스트라"는 모듈을 증명 가능하게 하는 바로 그 제어 구조가 모든 프로그램을 만들 수 있는 제어 구조의 최소 집합과 동일하다는 사실을 발견했다. (최소 집합은 순차, 분기, 반복 3가지로 표현할 수 있다는 것)
• 그렇기에 우리는 모두 구조적 프로그래머이며, 선택의 여지는 없다.

 

2) 기능적 분해

모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고, 결국 모듈을 기능적으로 분해할 수 있음을 뜻한다.

 

3) 엄밀한 증명은 없다.

무언가가 올바른지를 입증할 때 사용하는 전략에 유클리드 방식 같이 수학적인 증명만 있는 것은 아니다.

상당히 성공한 또 다른 전략으로는 과학적 방법이다.

 

과학적 방법이란?

• 사실임을 증명하는 것이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다.

 

4) 테스트

"테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수 없다"

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다. 

 

5ㄱ) 결론

• 현재의 우리 모두는 구조적 프로그래머이며, 여기에 선택의 여지는 없다.
• 구조적 프로그래밍이 오늘날까지 가치있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 이 능력 때문이다.
• 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.

 

---

❗ 객체지향 프로그래밍

좋은 아키텍처를 만드는 일은 OO 설계 원칙을 이해하고 응용하는 데서 출발한다. 

 

OO(Object-Oriented)란?

• 캡슐화, 상속, 다형성 3가지를 적절히 조합한 것.

 

1) 캡슐화?

OO를 정의하는 요소로 캡슐화를 언급하는 이유는 데이터와 함수를 쉽고 효과적으로 캡슐화하는 방법을 제공하기 때문이다.

 

C언어

ex) point.h

struct Point;
struct Point* makePoint(double x, double y);
double distance (struct Point *p1, struct Point *p2);

 

point.c

#include "point.h"
#include <stdlib.h>
#include <math.h>

struct Point {
  double x,y;
};

struct Point* makepoint(double x, double y) {
  struct Point* p = malloc(sizeof(struct Point));
  p->x = x;
  p->y = y;
  return p;
}

double distance(struct Point* p1, struct Point* p2) {}

-> Point의 구조체가 어떻게 구성되어 있는지 확인할 수 없으며, 함수만 사용할 수 있다. 

-> 이것이 바로 완벽한 캡슐화

 

 

하지만, OO 언어는 강력한 캡슐화에 의존한다는 정의는 받아들이기 힘들다.

• 이유 : 자바와 C#에서 헤더와 구분체를 분리하는 방식을 모두 버렸기 때문.
• OO 프로그래밍은 프로그래머가 충분히 올바르게 행동함으로써 캡슐화된 데이터를 우회해서 사용하지 않을 거라는 믿음을 기반으로 한다.

 

2) 상속?

상속이란?

• 단순히 어떤 변수와 함수를 하나의 유효 범위로 묶어서 재정의하는 것이다.

이전에 상속은 어떻게 구현했나? 

OO에서 상속이 처음 나온 것은 아니고, C언어에서 "손수" 만들었다. 

하지만, 직접 만들면서 다중 상속, 업캐스팅을 구현하기 어려웠다.

 

이런 점에서 OO언어는 새로운 개념을 만들지는 않았지만, 상당히 편리한 방식으로 상속을 구현할 수 있도록 제공했다고 볼 수 있다.

 

3) 다형성?

다형성이란?

• 하나의 객체가 여러가지 타입을 가질 수 있는 것.(오버로딩, 오버라이딩, 함수형 인터페이스)

이전에 다형성은 어떻게 사용하고 있었나?

• 위의 캡슐/상속과 마찬가지로 C언어에서 이미 STDOUT, STDIN 등과 같은 타입에 의존하여 사용하고 있었다.

OO에서 다형성

• 다형성은 함수를 가리키는 포인터를 응용했고, OO는 다형성을 좀 더 안전하고 편리하게 사용할 수 있도록 해준다.
• C언어에서 함수의 포인터를 직접 사용하려고 한다면, 포인터를 초기화하고, 포인터를 통해 함수를 호출하는 관례를 지켜야 한다. 만약 프로그래머가 위의 작업을 망각하게 되면 버그를 찾아내기 힘들다.
• OO는 이러한 관례를 없애주며, 실수할 위험이 없도록 만들었다. 
• 제어흐름을 간접적으로 전환하는 규칙을 부과한다고 결론지을 수 있다.

 

4) 다형성이 가진 힘

만약, 새로운 입출력장치가 생긴다고 하면 어떨까?

• 우리가 진짜로 하고 싶었던 일은 "장치 독립성"으로 어떤 장치에서나 쉽게 사용할 수 있는 형태이다.
• OO의 등장으로 "플러그인 아키텍처"를 적용할 수 있게 되었다.

 

5) 의존성 역전

다형성 매커니즘이 등장하기 전, 소프트웨어의 모습은?

 출처 : https://peter-cho.gitbook.io/book/11/clean-architecture/2

• 호출트리 : main함수 -> 고수준 함수 -> 중간 수준 함수 -> 저수준 함수
• 소스코드의 의존성의 방향은 제어흐름을 따르게 된다.

 

 

다형성이 나타난 후에는?

 출처 : https://peter-cho.gitbook.io/book/11/clean-architecture/2 

• 인터페이스를 통해 함수 호출이 되는데, 의존성의 방향은 제어흐름과 반대된다. 이를 의존성 역전이라고 한다.
• OO언어가 다형성을 안전하고 편리하게 제공한다는 사실은 소스코드 의존성을 어디에서든 역전시킬 수 있다는 뜻이기도 하다.
• 또한, 의존성의 방향을 역전하고 싶다면, 인터페이스를 추가하면 된다.
• 즉, 소스코드 의존성이 제어흐름의 방향과 일치하도록 제한되지 않는다.
• 호출하는 모듈이든 아니면 호출 받는 모듈이든 관계없이 소프트웨어 아키텍트는 소스코드 의존성을 원하는 방향으로 설정할 수 있다.

 

그렇다면, 어떻게 활용할 수 있는가?

• 배포 독립성, 개발 독립성

 

6) 결론

OO란?

• 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력이다.
• OO를 사용하면 플러그인 아키텍처를 구성할 수 있고, 모듈에 대해 독립성을 보장할 수 있다.

 

 

---

❗ 함수형 프로그래밍

함수형 프로그래밍이라는 개념은 프로그래밍 그 자체보다 앞서 등장했다.

이 패러다임에서 핵심이 되는 기반은 "람다"계산법으로 알론조 처치가 1930년대에 발명했다.

 

1) 정수를 제곱하기

ex) 자바 예시

public static void main(String args[]) {
	for (int i=0; i<25; i++) {
    	System.out.println(i*i);
    }
}

 

- 자바는 가변변수 사용

 

ex) 클로저 사용 예시

(println (take 25 (map (fn [x] (* x x)) (range))))

- 함수형 언어에서는 변수가 변하지 않는다.

 

 

2) 불변성과 아키텍처

Q. 왜 아키텍처에서 변수의 가변성이 중요한가?
A. 경합조건, 교착상태조건, 동시 업데이트 문제가 모두 가변변수로 인해 발생하기 때문이다.

 

아키텍트라면 무조건 "동시성"문제에 관심을 기울이고, 스레드와 프로세스가 여러 개인 상황에서도 설계한 시스템이 강경하길 바란다. 

그렇다면, 불변성이 정말로 실현 가능할까?

저장공간이 무한하고 프로세서의 속도가 무한히 빠르다고 가정하면 긍정적이다.

 

cf) 경합조건

- 두 개의 쓰레드가 같은 자원으로 접근하기 위해 경쟁하고, 이 자원으로 인해 접근 순서가 중요한 의미를 지니는 상황.

 

 

3) 가변성의 분리

현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼야한다.

 

출처 : https://uchanlee.dev/clean-architecture/book/ch6/

• 불변 컴포넌트는 순수 함수형 컴포넌트가 아닌 하나 이상의 다른 컴포넌트와 서로 통신한다.
• 트랜잭션 메모리는 데이터베이스가 디스크의 레코드를 다루는 방식과 동일한 방식으로 메모리의 변수를 처리한다.

* 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리하자.

    -> 분리하려면 가변 변수들을 보호하는 적절한 수단을 동워내 뒷받침해야 한다.

* 현명한 아키텍트라면, 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다. 

 

 

 

4) 이벤트 소싱

기본 발상 : 애플리케이션의 수명주기 동안 문제 없이 동작할 정도의 저장공간, 처리능력을 가지고 트랜잭션의 모든 값을 저장한다.

 

이벤트 소싱이란?

• 상태가 아닌 트랜잭션을 저장하는 전략
• 상태가 필요해지면 단순히 상태의 시작점부터 모든 트랜잭션을 처리한다.
• 단, 저장공간이 많이 필요하다.
• 결과적으로는 CRUD가 아닌 그저 CR만 수행하고, 그렇기에 동시 처리 문제 등도 발생하지 않는다. (결국 완전한 함수형으로 만들 수 있다는 뜻. )

 

---

🪄 결론

- 구조적 프로그래밍 : 제어흐름의 직접적인 전환에 부과되는 규율

- 객체 지향형 프로그래밍 : 제어흐름의 간접적인 전환에 부과되는 규율

- 함수형 프로그래밍 : 변수 할당에 부과되는 규율

 

 

 

📗 참고자료

- 클린 아키텍처 책 : http://www.yes24.com/Product/Goods/77283734