라이브러리 지향 아키텍처 (Library Oriented Architecture): 여러분이 아마 들어본 적 없을 가장 흥미로운 아키텍처 패턴

안녕하세요!

여러분이 가장 좋아하는 Dev.to 작가, 혹은 그와 비슷한 무언가인 Jairo Jr입니다 😄.

지난 몇 년 동안 저는 소프트웨어 아키텍처 (Software Architecture)를 공부하는 데 많은 시간을 보냈습니다. 대부분의 백엔드 엔지니어들과 마찬가지로, 저 또한 계층형 아키텍처 (Layered Architecture), 클린 아키텍처 (Clean Architecture), 헥사고날 아키텍처 (Hexagonal Architecture), 이벤트 기반 아키텍처 (Event-Driven Architecture), 그리고 마이크로서비스 (Microservices)라는 일반적인 여정을 거쳐왔습니다.

다양한 개념들을 탐구하던 중, 제 시선을 즉시 사로잡은 아키텍처 스타일을 발견했습니다: 바로 **라이브러리 지향 아키텍처 (Library Oriented Architecture, LOA)**입니다.

저는 Krystian Kościelniak의 글을 읽다가 이 용어를 처음 발견했는데, 이는 도메인 (Domain)과 코드 조직화 (Code Organization)에 대한 제 생각을 완전히 바꾸어 놓았습니다.

재미있는 점은 이 아이디어가 거의 너무 단순하게 들린다는 것입니다.

그리고 여러분이 소프트웨어 엔지니어라면, 보통 그때부터 상황이 위험해진다는 것을 이미 알고 계실 겁니다 😄.

🤔 성장하는 모든 애플리케이션이 직면하는 문제

코드베이스를 열어보고 스스로에게 이렇게 질문해 본 적이 있나요:

하나의 도메인이 어디서 끝나고 다른 도메인이 어디서 시작되는가?

처음에는 모든 것이 정리되어 있는 것처럼 보입니다. 그러다 프로젝트가 성장하고, 새로운 기능이 추가되고, 더 많은 비즈니스 규칙 (Business Rules)이 나타나면, 갑자기 결제 (Billing) 시스템이 사용자 (Users)를 알고, 사용자가 알림 (Notifications)을 알고, 알림이 결제를 알게 되며, 결국 아무도 무엇이 무엇의 소유인지 알 수 없게 됩니다.

코드는 여전히 작동하지만, 경계 (Boundaries)가 모호해집니다. 그리고 모호한 경계는 대개 비용이 많이 드는 문제를 야기합니다.

문제는 대략 다음과 같습니다:

애플리케이션이 성장함에 따라 소유권 (Ownership)을 이해하기가 점점 더 어려워집니다. 원래 하나의 도메인에 속했던 기능이 서서히 다른 도메인으로 유출되기 시작하며, 아무도 계획하지 않았지만 결국 모두가 유지보수해야 하는 의존성 (Dependencies)을 만들어냅니다.

🧠 LOA를 논하기 전에, 온톨로지 (Ontologies)에 대해 이야기해야 합니다

라이브러리 지향 아키텍처 (Library Oriented Architecture)를 이해하기 위해서는, 먼저 **온톨로지 (Ontology)**라고 불리는 개념을 이해해야 합니다.

온톨로지 (Ontology)라는 단어는 실제보다 훨씬 더 복잡하게 들립니다.

솔직히 말해서, 제가 이 단어를 처음 읽었을 때 소프트웨어 아키텍처(Software Architecture) 기사가 아니라 실수로 철학 책을 읽고 있는 게 아닌가 생각했습니다 📖.

소프트웨어 용어로 말하자면, 온톨로지 (Ontology)란 단순히 특정 도메인 (Domain) 내부의 개념 (Concepts), 관계 (Relationships), 그리고 비즈니스 규칙 (Business Rules)을 기술하는 방법입니다.

이커머스 (E-commerce) 플랫폼을 생각해 보세요. 고객 (Customers), 주문 (Orders), 상품 (Products), 결제 (Payments)가 있습니다. 더 중요한 것은, 이러한 개념들을 서로 연결하는 규칙들이 있다는 점입니다.

예를 들어:

• 고객 (Customers)은 주문 (Orders)을 생성합니다.
• 주문 (Orders)은 상품 (Products)을 포함합니다.
• 결제 (Payments)는 주문 (Orders)을 정산합니다.

온톨로지 (Ontology)는 그러한 언어와 관계들을 정의합니다. 즉:

온톨로지 (Ontology)는 도메인 (Domain)의 언어를 기술합니다.

시각적으로는 다음과 같은 모습입니다:

시스템을 개념과 관계의 집합체로 생각하기 시작하면, LOA (Library Oriented Architecture)가 훨씬 더 말이 되기 시작합니다.

📚 LOA의 핵심 아이디어

라이브러리 지향 아키텍처 (Library Oriented Architecture)의 중심 아이디어는 놀라울 정도로 단순합니다:

각 도메인 (Domain)이 하나의 라이브러리 (Library)가 됩니다.

그게 전부입니다.

비밀스러운 프레임워크 (Framework)도 없습니다.

새로운 런타임 (Runtime)도 없습니다.

AI 기반의 블록체인 구동 마이크로서비스 메시 (AI-powered blockchain-driven microservice mesh) 🚀✨😅 같은 것도 아닙니다.

패키지 (Package)도 아닙니다.

폴더 (Folder)도 아닙니다.

모놀리스 (Monolith) 안에 숨겨진 모듈 (Module)도 아닙니다.

진정한 라이브러리 (Library)입니다.

각 라이브러리 (Library)는 해당 특정 비즈니스 역량 (Business Capability)과 관련된 모든 것을 포함합니다:

• 도메인 개념 (Domain concepts)
• 도메인 규칙 (Domain rules)
• 도메인 동작 (Domain behavior)
• 도메인 유스케이스 (Domain use cases)

예를 들어:

customer-library
payment-library
inventory-library
...

각 라이브러리는 자신의 지식을 소유합니다.

각 라이브러리는 자신의 규칙을 소유합니다.

각 라이브러리는 자신의 진화 (Evolution)를 소유합니다.

도메인들이 뒤섞여 있는 거대한 애플리케이션 (Application)을 갖는 대신, 명시적인 소유권을 가진 독립적인 단위들을 갖게 됩니다.

도메인 (Domain)은 더 이상 애플리케이션 (Application)의 한 섹션이 아니라, 일급 시민 (First-class citizen)이 됩니다.

🏗️ 구조 (The Structure)

단순화된 LOA 애플리케이션은 보통 다음과 같은 모습을 띱니다:

아키텍처는 크게 세 가지 주요 부분으로 나눌 수 있습니다: 애플리케이션 (Application), 미들웨어 (Middleware), 그리고 도메인 라이브러리 (Domain Libraries)입니다.

애플리케이션 (Application)

애플리케이션은 시스템의 진입점 (Entry point)입니다.

애플리케이션은 프레임워크 통합 (Framework integrations), 의존성 주입 (Dependency injection), 컨트롤러 (Controllers), API 엔드포인트 (API endpoints), 그리고 인프라 설정 (Infrastructure configuration)을 포함합니다.

애플리케이션의 책임은 오케스트레이션 (Orchestration)입니다.

애플리케이션은 요소들을 어떻게 서로 연결할지는 알지만, 도메인 지식 (Domain knowledge)을 소유하지는 않습니다.

미들웨어 (Middleware)

미들웨어는 애플리케이션과 라이브러리 사이의 가교 역할을 합니다.

미들웨어의 책임은 다음과 같은 공통 서비스 (Common services)를 제공하는 것입니다:

• HTTP 통신 (HTTP communication)
• 캐싱 (Caching)
• 영속성 추상화 (Persistence abstractions)
• 메시징 (Messaging)
• 공유 유틸리티 (Shared utilities)

목표는 도메인 라이브러리 내부에서 인프라에 직접적으로 결합 (Infrastructure coupling)되는 것을 방지하는 것입니다.

라이브러리 (Libraries)

이곳이 실제로 비즈니스 (Business)가 살아 숨 쉬는 곳입니다.

각 라이브러리는 다음을 포함합니다:

• 비즈니스 엔티티 (Business entities)
• 비즈니스 규칙 (Business rules)
• 유스케이스 (Use cases)
• 도메인 로직 (Domain logic)

이상적으로, 라이브러리는 프레임워크 의존성 (Framework dependencies)이 없고, 인프라 관련 사항 (Infrastructure concerns)이 없으며, 애플리케이션 자체에 대한 지식도 없습니다.

라이브러리는 오직 자신의 도메인만을 알고 있습니다.

그리고 그것은 매우 강력합니다.

이를 시각화하는 또 다른 방법은 다음과 같습니다:

💡 내가 이 아이디어를 좋아하는 이유

LOA (Library Oriented Architecture)에 제가 매료된 가장 큰 이유는 명확성 (Clarity)입니다.

도메인 (Domain)이 라이브러리 (Library)가 되면, 소유권 (Ownership)이 명시적으로 변합니다. 비즈니스 규칙 (Business rules)이 어디에 속해야 하는지, 변경 사항이 어디에서 발생해야 하는지, 그리고 특정 기능의 소유자가 누구인지를 즉각적으로 알 수 있습니다.

수년간 대규모 코드베이스 (Codebases)를 다루면서, 저는 많은 아키텍처 문제들이 기술적인 문제가 전혀 아니라는 사실을 깨달았습니다.

그것들은 바로 소유권의 문제입니다.

LOA는 도메인 경계 (Domain boundaries)를 가시화하고 강제함으로써 그 과제를 직접적으로 해결합니다.

이 아키텍처는 엔지니어들이 기술적 계층 (Technical layers) 대신 비즈니스 역량 (Business capabilities)의 관점에서 생각하도록 장려하며, 이는 시간이 지남에 따라 더 깨끗하고 유지보수가 용이한 시스템을 만드는 경향이 있습니다.

🔍 이것은 그저 모듈러 모놀리스 (Modular Monolith) 아닌가요?

언뜻 보기에는 매우 유사해 보입니다.

그리고 솔직히 말해서, 어느 정도 겹치는 부분도 있습니다.

만약 여러분이 다음과 같이 생각하고 있다면:

이건 수상할 정도로 모듈러 모놀리스 (Modular monolith) 같은데.

여러분만 그렇게 생각하는 것이 아닙니다.

저도 정확히 똑같은 반응을 보였습니다 😅.

두 접근 방식 모두 강력한 경계를 만들고 결합도 (Coupling)를 줄이는 것을 목표로 합니다.

차이점은 LOA가 모듈성 (Modularity)을 한 단계 더 밀어붙인다는 점입니다.

다음과 같이 생각하는 대신:

이 폴더는 결제 모듈 (Payment module)에 속한다.

여러분은 다음과 같이 생각하기 시작합니다:

이 라이브러리가 바로 결제 도메인 (Payment domain)이다.

이 미묘한 차이가 팀이 소프트웨어를 설계하는 방식을 바꿉니다.

도메인은 애플리케이션 (Application) 내부의 하나의 폴더로 머무는 것이 아니라, 자체적인 생명주기 (Lifecycle)와 소유권을 가진 독립적인 단위가 됩니다.

🤖 AI 시대에 LOA가 주는 예상치 못한 이점

LOA를 공부하면서 깨달은 한 가지는, 이것이 AI 에이전트 (AI agents)의 세계에 얼마나 자연스럽게 부합하는가 하는 점입니다.

이는 예상치 못한 결과였습니다. 아키텍처에 대해 읽기 시작했는데, 어쩌다 보니 컨텍스트 윈도우 (Context windows)와 토큰 소비 (Token consumption)에 대해 생각하게 되더군요 🤖.

AI 기반 시스템을 구축할 때 가장 큰 도전 과제 중 하나는 컨텍스트 관리 (Context management)입니다. 에이전트 (Agent)에게 더 많은 정보를 제공할수록, 응답은 더 비싸지고, 느려지며, 때로는 정확도가 떨어지게 됩니다.

LOA를 사용하면 도메인 경계 (Domain boundaries)가 자연스럽게 컨텍스트 경계 (Context boundaries)가 됩니다.

에이전트에게 애플리케이션 전체에 대한 접근 권한을 주는 대신, 해결하려는 문제와 관련된 라이브러리 (Library)만 제공할 수 있습니다.

결제 에이전트 (Payment Agent)는 결제 개념만 필요합니다. 재고 에이전트 (Inventory Agent)는 재고 개념만 필요합니다.

그 결과 토큰 소비 (Token consumption)가 줄어들고, 추론 (Reasoning)이 더 집중되며, 에이전트가 일반론자 (Generalists)보다는 전문가 (Specialists)에 훨씬 가깝게 동작하게 됩니다.

AI가 소프트웨어 아키텍처 (Software architecture)의 일부가 됨에 따라, 이는 LOA의 가장 흥미로운 이점 중 하나가 될 수 있습니다.

✅ 장점 (Advantages)

이 개념을 연구한 결과, 제가 보는 가장 큰 이점들은 다음과 같습니다.

명확한 도메인 경계 (Clear Domain Boundaries)

모든 도메인은 명시적인 집을 가집니다. 이는 소유권 (Ownership)을 이해하기 쉽게 만들고, 비즈니스 규칙 (Business rules)이 시스템의 관련 없는 부분으로 유출될 가능성을 줄여줍니다.

높은 재사용성 (High Reusability)

도메인이 라이브러리로 패키징되기 때문에, 전체 코드베이스 (Codebase)를 가져오지 않고도 여러 애플리케이션에서 재사용할 수 있습니다.

더 쉬운 테스트 (Easier Testing)

도메인 로직 (Domain logic)을 격리하기가 더 쉬워져, 단위 테스트 (Unit tests) 및 통합 테스트 (Integration tests)를 작성하고 유지 관리하기가 더 간단해집니다.

프레임워크 독립성 (Framework Independence)

비즈니스 규칙은 Spring, Express, ASP.NET 또는 기타 프레임워크 (Framework)로부터 독립적으로 유지되어, 장기적인 결합도 (Coupling)를 줄여줍니다.

더 나은 장기적 유지보수성 (Better Long-Term Maintainability)

명확한 경계와 감소된 결합도는 비즈니스 요구사항이 성장함에 따라 시스템을 더 쉽게 진화시킬 수 있게 합니다.

⚠️ 잠재적 단점 (Potential Drawbacks)

물론, 완벽한 아키텍처는 없습니다.

LOA 또한 과제를 안겨줍니다.

더 많은 초기 설계 노력 (More Initial Design Effort)

LOA는 도메인 경계에 대한 신중한 고민을 요구합니다. 잘못된 경계는 경계가 아예 없는 것만큼이나 많은 문제를 일으킬 수 있습니다.

패키지 관리 복잡성 (Package Management Complexity)

도메인의 수가 증가함에 따라, 라이브러리 간의 버전 및 의존성 (dependencies) 관리는 더욱 어려워집니다.

모든 프로젝트에 이상적인 것은 아님 (Not Ideal for Every Project)

규모가 작은 애플리케이션은 추가된 복잡성을 정당화할 만큼 추가적인 구조로부터 충분한 이득을 얻지 못할 수도 있습니다.

대부분의 아키텍처 결정과 마찬가지로, LOA는 트레이드오프 (trade-off) 관계에 있는 것이지 만능 해결책 (silver bullet)은 아닙니다.

🚀 마치며 (Final Thoughts)

제가 라이브러리 지향 아키텍처 (Library Oriented Architecture)에서 가장 좋아하는 점은 라이브러리 그 자체가 아닙니다.

바로 사고방식 (mindset)입니다.

LOA는 우리가 도메인 (domains)을 폴더나 모듈, 혹은 기술적 계층 (technical layers)이 아닌, 일급 시민 (first-class citizens)으로 생각하도록 강제합니다.

도메인 말입니다.

LOA가 육각형 아키텍처 (Hexagonal Architecture), 클린 아키텍처 (Clean Architecture), 또는 모듈형 모놀리스 (Modular Monoliths)를 대체하게 될까요?

아마 그렇지 않을 것입니다.

하지만 LOA는 흥미로운 관점을 제공합니다:

만약 도메인이 애플리케이션의 일부가 아니라면 어떨까요?

만약 애플리케이션이 단순히 도메인들의 집합을 오케스트레이션 (orchestrating)하는 것이라면 어떨까요?

그리고 이것은 제가 이 아키텍처 스타일을 발견한 이후로 계속 고민해 온 질문입니다.

어쩌면 LOA가 차세대 거대한 아키텍처 트렌드가 되지는 못할지도 모릅니다.

하지만 LOA는 분명히 제가 도메인을 다르게 바라보게 만들었습니다. 그리고 저에게 그것은 이미 승리입니다 🎯.