대규모 C++ 시스템의 모듈 간 결합도 분리 전략과 실전 사례

대규모 C++ 시스템에서의 결합 문제와 해법

기능이 확장됨에 따라 대규모 C++ 시스템은 복잡성이 기하급수적으로 증가한다. 모듈 간 강한 결합은 코드 유지보수를 어렵게 만들고, 단위 테스트를 방해하며, 빌드 시간을 비효율적으로 늘린다. 특히 "스파게티 의존성" 구조가 형성되면 작은 변경조차 예측 불가능한 부작용을 유발할 수 있다.

주요 해결 목표:

  • 모듈 독립성 확보 및 기능 격리
  • 병렬 개발 및 자동화된 테스트 지원
  • 헤더 파일 의존성 감소로 빌드 속도 개선
  • 기술 스택 점진적 업그레이드 가능하게 설계

결합 문제 예시:

// 나쁜 예: 구현체에 직접 의존
class AuditLogger {
public:
    void record(const std::string& event) {
        storage.open(); // 구체적인 클래스에 의존
        storage.store(event);
    }
private:
    PostgreSQLStorage storage; // 하드코딩된 의존성
};
// 이 설계는 의존 역전 원칙(DIP)을 위반하며, 다른 저장소로 교체하기 어렵다.

주요 해법 비교:

전략장점적용 사례
인터페이스 추상화 + 팩토리런타임 구현 교체 가능다중 로깅/저장소 백엔드
의존성 주입(DI)테스트 용이성 및 유연성 향상서비스 간 협업
이벤트 버스비동기 통신으로 결합도 완화모듈 간 상태 알림
인터페이스를 통한 모듈 결합도 분리 다이어그램
인터페이스를 중간 계층으로 두어 여러 모듈이 동일한 추상화에 의존하도록 설계

C++에서 인터페이스 격리 원칙의 실전 적용

상속 대신 조합을 통한 유연한 설계

깊은 상속 계층은 하위 클래스가 상위 클래스의 구현 세부사항에 의존하게 만들어 확장성을 저해한다. 반면, 인터페이스 기반 조합은 동작을 외부에서 주입받아 유연성을 극대화한다.

// C++에서의 조합 기반 설계 예시
class Drivable {
public:
    virtual ~Drivable() = default;
    virtual void drive() = 0;
};

class ElectricMotor : public Drivable {
public:
    void drive() override { /* 전기 모터 구동 */ }
};

class Vehicle {
    std::unique_ptr<Drivable> engine_;
public:
    explicit Vehicle(std::unique_ptr<Drivable> engine)
        : engine_(std::move(engine)) {}
    
    void operate() { engine_->drive(); }
};

Pimpl 관용구를 통한 컴파일 타임 결합도 제거

Pimpl(Pointer to Implementation)은 구현 세부사항을 헤더에서 숨겨 재컴파일 범위를 줄인다.

// widget.h
class Widget {
    class Impl;
    std::unique_ptr<Impl> pImpl_;
public:
    Widget();
    ~Widget();
    void process();
};

// widget.cpp
class Widget::Impl {
    int internalState_;
public:
    void execute() { /* 실제 로직 */ }
};

Widget::Widget() : pImpl_(std::make_unique<Impl>()) {}
Widget::~Widget() = default;
void Widget::process() { pImpl_->execute(); }

인터페이스 버전 관리와 바이너리 호환성

Protocol Buffers는 필드 삭제 후 재사용을 방지하기 위해 reserved 키워드를 제공한다.

message UserProfile {
  int32 user_id = 1;
  string display_name = 2;
  reserved 3, 5 to 7; // 기존 필드 번호 보호
  string contact_email = 8;
}

컴파일 타임 인터페이스 검증

C++에서는 명시적 캐스팅을 통해 인터페이스 구현 여부를 컴파일 시점에 확인할 수 있다.

class ICache {
public:
    virtual ~ICache() = default;
    virtual std::optional<Data> get(const Key&) = 0;
    virtual void put(const Key&, const Data&) = 0;
};

class RedisCache : public ICache { /* 구현 */ };

// 컴파일 타임 검증 (헤더 또는 소스 파일 내부에 배치)
static_assert(std::is_base_of_v<ICache, RedisCache>, "RedisCache must implement ICache");

실전 사례: 고성능 거래 시스템 리팩토링

초당 수천 건의 요청을 처리하던 시스템에서 REST over JSON 대신 gRPC + Protobuf를 도입하여 직렬화 오버헤드를 60% 감소시켰다. 동시에 핵심 경로에서 비동기 이벤트 처리를 도입해 P99 지연 시간을 850ms에서 120ms로 단축했다.

의존성 관리 체계와 도구 체인

의존 역전 원칙과 서비스 레지스트리

서비스 인터페이스를 정의하고, 런타임에 구현체를 등록/조회하는 방식으로 모듈 간 직접 의존을 제거한다.

// C++ 템플릿 기반 서비스 레지스트리 예시
template<typename Interface>
class ServiceRegistry {
    std::unordered_map<std::string, std::unique_ptr<Interface>> services_;
public:
    void registerService(std::string name, std::unique_ptr<Interface> svc) {
        services_[std::move(name)] = std::move(svc);
    }
    
    Interface* getService(const std::string& name) {
        auto it = services_.find(name);
        return it != services_.end() ? it->second.get() : nullptr;
    }
};

의존성 그래프 자동 분석

빌드 시스템(예: Bazel, CMake) 또는 정적 분석 도구를 활용해 헤더 포함 관계를 파싱하여 의존성 그래프를 생성할 수 있다. 이를 통해 순환 의존성이나 금지된 크로스-레이어 호출을 자동으로 탐지한다.

의존성 방화벽 설정

계층 간 통신 규칙을 강제 적용하기 위해 다음 원칙을 준수한다:

  • 인터페이스만 헤더에 노출
  • 구현체는 소스 파일 내부에 캡슐화
  • 의존성 방향을 한 방향으로 고정 (예: UI → Business → Data)

모듈 간 생명주기 및 통신 관리

스마트 포인터를 통한 자원 관리

모듈 간 객체 공유 시 다음과 같은 규칙을 권장한다:

  • 팩토리 함수는 std::shared_ptr 반환
  • 수신자는 std::weak_ptr로 참조하여 순환 참조 방지
  • 사용 전 반드시 lock()으로 유효성 검사

이벤트 기반 비동기 통신

Kafka나 RabbitMQ 같은 메시지 브로커를 사용해 모듈 간 이벤트를 전달함으로써 시간적·공간적 결합도를 낮춘다.

// 이벤트 발행 예시
struct OrderCreatedEvent {
    std::string order_id;
    std::string customer_id;
    std::chrono::system_clock::time_point timestamp;
};

eventBus.publish("orders.created", serialize(event));

동기/비동기 호출 경계 설정

핵심 비즈니스 로직은 동기 호출로 강한 일관성 보장, 보조 작업(알림, 로깅 등)은 비동기 처리로 자원 효율성 향상.

모듈 동적 로딩

C++에서는 dlopen/LoadLibrary 등을 활용해 런타임에 공유 라이브러리를 로드할 수 있다. 이 경우 모든 플러그인이 동일한 ABI(Application Binary Interface)를 준수해야 안정적인 교체가 가능하다.

미래 방향: 마이크로 커널과 플러그인 아키텍처

핵심 기능만을 포함하는 마이크로 커널 위에 플러그인을 동적으로 적재하는 구조는 확장성과 유지보수성을 극대화한다. 클라우드 네이티브 게이트웨이 등에서 이미 검증된 접근법이다.

플러그인 인터페이스 예시:

class Plugin {
public:
    virtual ~Plugin() = default;
    [[nodiscard]] virtual std::string name() const = 0;
    virtual bool initialize() = 0;
    virtual void handleRequest(Request&) = 0;
};

이러한 설계는 기능 추가/수정 시 전체 시스템 재배포 없이 특정 플러그인만 교체 가능하게 하며, 실패 시 영향 범위를 최소화한다.

태그: C++ Dependency Injection Interface Segregation Pimpl Event Bus

9월 26일 15:49에 게시됨

인기 태그

©2026 괴물 클럽