소프트웨어의 모든 것은 피라미드다 (마음에 들든 안 들든)

Source: Dev.to

Introduction

잠시 지나면, 소프트웨어는 도구처럼 보이지 않게 된다.
중력처럼 보이기 시작한다.
무엇을 만들든, 복잡성은 언제나 아래로 가라앉는다.
나는 이 모델을 계획한 것이 아니라, 어디서든 같은 형태를 계속 눈치채다 보니, 패턴에 이름을 붙이는 대신 피라미드를 그리기 시작했다.

Frameworks

프레임워크는 그들이 존재하는 위치를 보면 강력해 보인다:

• Framework
• Runtime Environment
• Programming Language
• Compiler or Interpreter
• Machine Code

프레임워크는 컴퓨터에 새로운 능력을 부여하지 않는다. UI가 사용자 경험을 위해 존재하듯, 프레임워크는 개발자 경험을 위해 존재한다. 모든 것이 잘 돌아가면, 당신은 정상에 있다. 또 다른 추상화를 추가해서 디버깅하지 않는다.

Architecture

사람들은 아키텍처가 팀이 커질 때 시작된다고 생각한다. 그렇지 않다.
단일 MVC 앱도 이미 피라미드를 형성한다:

• 변동성은 최상위에 있다.
• 컨트롤러는 의도를 변환한다.

비즈니스 로직이 위쪽으로 새어나오면, 상황이 빠르게 부패한다. 이것은 과잉 설계가 아니다.

Horizontal Scaling

시스템이 성장함에 따라 흔히 저지르는 실수는 수평적인 것이다. 사람들은 복잡성을 너무 일찍 옆으로 퍼뜨린다.

각 모듈은:

• 자신의 규칙을 소유한다
• 인터페이스를 노출한다
• 내부를 숨긴다

배포는 여전히 지루하다. 규모가 커지면 추출은 기계적으로 이루어진다. 추출이 고통스럽다면, 경계가 허구였던 것이다.

Microservices

마이크로서비스는 복잡성을 없애는 것이 아니라 네트워크를 가로질러 이동시킨다. 모든 네트워크 홉은 실패 모드이다.

• 마이크로서비스는 조직 규모를 해결할 뿐, 초기 불확실성을 해결하지 않는다.
• 마이크로서비스는 야망이 아니라 압력에 의해 얻어진다.
• 너무 일찍 사용하면, 문제를 해결하기보다 더 빠르게 증폭시킨다.

The Pyramid Rule

네 개의 피라미드 모두에서 규칙은 변하지 않는다:

자주 변하는 것들을 최상위에 두라.

프레임워크는 빠르게 변한다. 이 순서를 어긴다고 해서 현대적이 되는 것은 아니다. 이것은 철학이 아니라 가역성이다.

• 레이어가 높을수록: 실수 비용이 저렴하고, 재작성도 쉽다.
• 레이어가 낮을수록: 비용이 높고, 복구에 오래 걸린다.

강한 시스템은 중력을 존중한다. 약한 시스템은 추상화로 그것에 맞서려 한다.

Conclusion

피라미드를 한 번 보면, 질문이 바뀐다:

• 내가 건드리는 레이어는 무엇인가?
• 이 결정은 얼마나 가역적인가?
• 나는 무게를 제자리에 있지 않은 곳에 더하고 있는가?