타르구덩이에서 빠져나오기 위한 여정 - 1

1. 필수 복잡성(essential complexity): 필수 복잡성은 문제 자체에서 비롯되는 복잡성. 이 복잡성은 제거할 수 없으며, 소프트웨어가 해결하려는 문제의 본질에 내재해 있습니다. 예를 들어, 은행 시스템에서 거래를 처리하는 논리적인 복잡성은 필수 복잡성에 해당합니다.
2. 우발적 복잡성(accidental complexity): 우발적 복잡성은 문제의 본질과는 무관하게 개발 과정에서 도입된 불필요한 복잡성을 말합니다. 이는 주로 소프트웨어 설계나 구현 방식에서 발생합니다. 예를 들어, 언어의 제한이나 시스템의 아키텍처적인 결정 때문에 발생하는 복잡성이 우발적 복잡성에 해당.

• 복잡성의 주요 원인은 상태(state) 관리에서 발생하며, 이는 소프트웨어 개발에서 가장 큰 문제 중 하나이다.
• 상태 관리 문제를 해결하기 위해서는 상태를 최소화하고, 불변성(immutability)을 적극 활용해야 한다.
• 논문은 함수형 프로그래밍이 이러한 복잡성을 줄이는 데 유용하다고 주장. 함수형 프로그래밍 언어는 상태를 변경하지 않으며, 순수 함수(pure functions)를 사용하여 부작용(side effects)을 제거하므로 우발적 복잡성을 줄이는 데 도움을 준다고 봄.
• 또한, 도메인 모델링의 중요성을 강조하며, 잘 정의된 도메인 모델이 필수 복잡성을 효과적으로 다룰 수 있다고 말함.

해결 방안

1. 함수형 프로그래밍: 함수형 프로그래밍 언어의 사용을 통해 상태를 줄이고, 불변성을 유지하며, 순수 함수를 사용함으로써 복잡성을 낮출 수 있습니다.
2. 도메인 모델링: 문제의 본질을 잘 표현하는 도메인 모델을 설계함으로써 필수 복잡성을 명확히 하고, 우발적 복잡성을 최소화할 수 있습니다.
3. 복잡성의 분리: 시스템의 각 부분이 복잡성을 독립적으로 다루도록 설계하여 전체 시스템의 복잡성을 관리할 수 있습니다. 예를 들어, 비즈니스 로직, 데이터 관리, 사용자 인터페이스를 분리하는 것이 한 예입니다.

가상의 이상적인 세상을 상상하자.

성능도 언어도 인프라까지 우리가 원하는 자원을 제공받는다. 우리는 이러한 배경에서 상태와 제어에 바라보는 것이다.

이상적인 세계는 상태의 주된 목표는 상태를 최대한 줄이는 것이다. 이상세계에서 생략할 수 있는 녀석이라면, 이 상태를 우발적인 상태로 식별할 것이다.

이런식별은 우리가 상태를 만들 때, 이것이 우발적인 상태인지 본질적으로 필수적인 상태인지 인지하는 것으로 우리가 어떤 복잡성을 허용했는지 인지하는데 도움이 될 것이라고 개인적으로 생각한다.

1. 입력데이터 직접 제공(입력)된 데이터를 필수적이다. 이 데이터는 두가지 유형이 있다.
   1. (요구사항에 따라) 향후 시스템이 참조할 가능성이 있는 경우 : 이상세계에서도 필수상태에 해당한다.
   2. 가능성이 없는 경우 : 유지할필요가 없다.

2. 필수 파생 데이터 - 변경 불가(Immutable)

   우발적인 상태이다. 입력데이터를 통해 언제든지 필요할 때마다 파생시킬 수 있다. 따라서 이상적인 세계에서는 저장할 필요가 없다.

3. 필수 파생 데이터 - 변경 가능(Mutable)

   역시 우발적 상태.

   파생 데이터의 변경 가능성은 데이터를 파생하는 데 사용된 함수(로직)에 역함수가 있는 경우에만 의미가 있다. 파생된 데이터가 입력 데이터를 단순화하기 위한 재구조화를 나타내는 경우 역함수가 존재하는 경우가 많다.

   그렇지 않다면 이 데이터는 파생되 것으로 간주할 수 없으며 사실상 입력데이터로 간주한다.

4. 우발적 파생 데이터

   시스템의 본질적 기능에 필수적이지 않지만, 구현 과정에서 도입된 불필요한 상태를 의미.

   예를들어 아래처럼 반복계산을 피하기 위한 캐싱처리 같은 것들이다.

   procedure int doCalculation(int y)
     // ’subsidaryCalcCache’ is declared and initialized
     // elsewhere in the code
     if (subsidaryCalcCache.contains(y) == false) {
       subsidaryCalcCache.y := slowSubsidaryCalculation(y)
     }
   return 3 * (4 + subsidaryCalcCache.y)
   

우리는 무한정의 리소스를 합리적인 가격으로 사용할 수 있다.

물론 클라우드 서비스가 신은 아니지가 무한정 제공해줄 수는 없다. 하지만 우리가 N개의 리소스가 필요하고 클라우드 업체가 N+1 개의 리소스를 제공한다면 우리는 무한으로 체감할 수 있습니다.

1. 리소스를 유동적으로 변화시킬 수 있다는 점과 마이크로서비스의 번영
   • 리소스의 유동적 변화: 클라우드 컴퓨팅의 가장 큰 장점 중 하나는 필요에 따라 컴퓨팅 자원(메모리, CPU, 스토리지 등)을 유동적으로 할당하고 조정할 수 있다는 점이다.
   • 마이크로서비스의 번영: 마이크로서비스 아키텍처는 큰 애플리케이션을 여러 작은 독립적인 서비스로 나누어 관리하는 접근 방식이다. 각 서비스는 독립적으로 배포, 확장, 유지보수할 수 있어야 한다. 클라우드의 유동적인 리소스 관리 기능은 이러한 마이크로서비스의 요구사항을 충족시켜 주며, 필요한 경우 각 서비스를 개별적으로 확장하거나 축소할 수 있게 해줍니다. 이로 인해 마이크로서비스 아키텍처가 더욱 번영할 수 있는 환경이 조성된 것이다.
2. 도메인 단위로 서비스 만들기와 클라우드의 역할
   • 도메인 단위 서비스: 도메인 주도 설계(DDD)에서는 시스템을 비즈니스 도메인 단위로 나누어 각 도메인에 맞는 서비스를 설계하고 구현. 이러한 서비스는 독립적이며, 각각의 도메인이 다른 도메인과 적절히 격리되어 운영될 수 있도록 설계됩니다.
   • 클라우드의 기여: 클라우드 환경은 이러한 독립적인 도메인 단위 서비스를 손쉽게 배포하고 관리할 수 있게 해줍니다. 각 도메인 서비스는 클라우드 인프라에서 독립적으로 운영될 수 있으며, 필요에 따라 별도의 리소스를 할당받아 운영될 수 있습니다. 클라우드는 이러한 서비스의 유연한 확장성, 높은 가용성, 손쉬운 배포를 가능하게 하여 도메인 단위로 서비스를 만들고 분리하는 작업을 더 효율적으로 할 수 있게 해준다.

1. 함수형은 리소스가 많이 필요하다.
   • 불변성(immutability): 함수형 프로그래밍에서는 데이터가 불변으로 다뤄지기 때문에, 상태 변경을 할 때마다 새로운 데이터 구조가 생성된다. 이는 추가적인 메모리 사용을 요구한다. (또한 이것은 Persistant Data Structure 라는 자료구조가 제시되면서 함수형 시대의 태동이 되었다고 볼 수 있다. 이 자료구조는 나중에 시간이 되면 소개하도록 함)
   • 재귀와 고차 함수: 함수형 프로그래밍에서는 반복 대신 재귀를 많이 사용하며, 고차 함수는 더 복잡한 계산을 수행할 수 있도록 합니다. 이러한 접근은 코드의 가독성과 재사용성을 높여주지만, 복잡한 계산이 반복되면서 더 많은 메모리와 CPU 자원을 필요로 한다.
   • 게으른 평가(lazy evaluation): 게으른 평가 전략은 필요할 때까지 계산을 지연시키는 방식으로 자원을 최적화하지만, 특정 시점에 갑작스런 리소스 소비를 유발할 수 있다.
2. 초기 컴퓨팅 환경의 한계
   • 초기 컴퓨터의 제한적인 리소스로는 비효율적인 자원 사용을 초래한다.

처음 out of tar pit 에 설명한. essential data 즉, input data 만 저장해야하며 파생데이터는 계산만해서 사용하는 세상에 우리는 살고 있는가? 우리의 데이터베이스는 불변한가?

하지만 우리는 변화를 원한다. 구글에서 동일한 값을 검색하면, 1년 전 데이터와 동일한 결과를 원하지 않는다. 시간이 지남에 따라 리턴값은 변화해야 한다.

데이터베이스에서도 불변성을 유지하는 것이 가능하지만, 현실적으로는 데이터를 수정하고 업데이트하는 경우가 더 많다. C나 Java 같은 언어에서도 불변하게 코드를 작성할 수 있지만, 우리는 이 언어들의 자료구조를 불변이라고 말하지 않는다. 쉽게 변할 수 있는 구조이기 때문이다. 그렇기에 우리는 c,java의 자료구조를 불변하다고 말하지 않는다. 변하게 하는 방식이 너무 쉽기 때문이다.

database 도 마찬가지다. 우리는 불변하게 사용할 수도 있다. 하지만 그렇다고 우리가 사용하는 데이터베이스를 불변하다고 생각하지 않는다. 우리는 어떤 테이블의 구조를 보고 이것이 불변하다. 현재까지 한번도 수정이 일어난 적이 없다고 단정할 수 없다.

• 구조적 프로그래밍은 제어흐름의 직접적인 전환에 부과되는 규율이다.
• 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 부과되는 규율이다.
• 함수형 프로그래밍은 변수 할당에 부과되는 규율이다.

이들 세 패러다임 모두 우리에게서 무언가를 앗아갔다. 각 패러다임은 우리가 코드를 작성하는 방식의 형태를 한정시킨다. 어떤 패러다임도 우리의 권한이나 능력에 무언가를 보태지는 않는다.

지난 반세기 동안 우리가 배운 것은 해서는 안되는 것에 대해서다.

– 클린 아키텍처 –

위처럼 제약을 가함으로서 우리는 다음과 같은 이점을 기대할 것이다.

• 구조적 프로그래밍:
  • 코드의 가독성 향상
  • 로직의 명확한 구조화
  • 디버깅의 용이성

• 객체 지향 프로그래밍:
  • 코드의 재사용성 증가
  • 복잡한 시스템의 모듈화
  • 유지보수의 용이성
• 함수형 프로그래밍:
  • 부작용 최소화
  • 병렬 처리의 용이성
  • 테스트와 디버깅의 단순화

분명 C로도 함수형 프로그래밍이 가능하고, 객체지향 프로그래밍이 가능하다.

하지만 우리가 스스로를 제약하기 도와주는 언어를 사용할 때, 더욱더 쉽게 원하는 이상에 도달할 수 있다.