잘 경계 지어진 시스템의 가치
시스템을 구성하는 컴포넌트의 크기가 클수록 새로운 정보가 기존 정보와 충돌할 가능성이 높아집니다. 상충되는 정보가 시스템 내에서 경쟁하는 것은 비효율적이므로, 기존 정보의 영향을 제한하고 새로운 정보를 신속히 활용하여 가치를 창출해야 합니다. 컴포넌트의 가치는 두 가지 측면에서 발생합니다. 첫째, 내부와 외부를 분리하는 경계를 제공하며, 둘째, 다른 요소들과 상호작용하는 ‘접촉면’ 또는 ‘인터페이스’를 제공합니다.
과거 마이크로서비스 논의는 주로 컴포넌트의 추가 및 변경 속도, 통합 오버헤드 감소, 시스템 안정성 향상에 초점을 맞췄습니다. 이러한 장점들은 경제적인 관점에서 중요하지만, 컴포넌트가 세분화될수록 이를 지원하는 운영 비용이 전체 비용에서 차지하는 비중이 커집니다. Kubernetes, Istio와 같은 시스템들이 오버헤드 감소를 위해 등장했지만, 현재 인프라 접근 방식으로는 여전히 ‘최소’ 컴포넌트 크기가 크다는 한계가 있습니다.
컴포넌트 인터페이스 정의
저자는 Ruby 코드를 통해 컴포넌트 인터페이스의 문제를 설명합니다. 첫 번째 예시는 같은 머신 내에서 greet와 say_hello 함수가 서로 의존하는 간단한 경우입니다. 두 번째 예시는 greet가 다른 서비스에 있다고 가정하고, 파일 I/O와 JSON을 사용하여 데이터를 주고받는 일반적인 분산 시스템의 상호작용 방식을 보여줍니다. 이는 오늘날 대부분의 분산 애플리케이션이 사용하는 방식입니다.
그러나 저자는 다른 접근 방식을 제시합니다. eval을 활용하여 실행 가능한 코드(언어) 자체를 인터페이스로 사용하는 예시를 보여줍니다. 이는 다음과 같은 특징을 가집니다.
-
언어 인터페이스: 단순한 데이터 교환을 넘어, 언어의 풍부한 표현력과 실행 능력을 인터페이스로 활용합니다. 이는 정적으로 정의된 API보다 강력하고 유연합니다.
-
동적 인터페이스: 인터페이스가 정적으로 정의되지 않고, 계산의 결과로 생성되거나 심지어 기계 지능에 의해 생성될 수 있는 가능성을 열어줍니다.
-
피어-투-피어 아키텍처: 이러한 언어 인터페이스는 컴포넌트들이 반드시 동일한 머신이나 프로세스에 있을 필요도, 반드시 분리된 물리/가상 머신에 있을 필요도 없게 만듭니다. 이는 인터넷이 본질적으로 피어-투-피어 시스템임에도 불구하고 클라이언트-서버 아키텍처가 지배적인 현상을 극복하고, Meta나 Google과 같은 기업의 불필요한 권력 집중을 해소할 수 있는 기회를 제공합니다.
저자는 Ruby의 eval을 직접 사용하라는 것이 아니라, ‘언어’가 가진 풍부한 가능성을 인터페이스로 활용하자는 근본적인 아이디어를 강조합니다. 이러한 접근 방식은 Actors 모델(Erlang, Unison 등)과 같은 기존의 분산 컴퓨팅 연구에서도 찾아볼 수 있습니다. 현재 이러한 시나리오를 투명하고 효율적으로 만들 인프라가 부족하지만, 필요한 기술적 이해는 충분히 확보되어 있다고 주장합니다.
기존 패러다임의 전환 필요성
새로운 정보를 효율적으로 배포하여 더 나은 의사결정을 내리는 것이 우리의 목표라면, 컴포넌트 언어 인터페이스(Component Language Interfaces) 구축이 필요할 수 있습니다. 이는 정의 가능하고 측정 가능한 가치이므로, 저자의 의견에 동의하지 않더라도 그 필요성을 평가할 수 있습니다.