객체 지향 설계 – dsgnmstr; Design Monster

1. 들어가며: 거대한 시스템을 지탱하는 보이지 않는 손, 팬인과 팬아웃

우리가 매일 사용하는 복잡하고 거대한 소프트웨어 시스템은 어떻게 안정적으로 작동할까요? 수많은 기능과 모듈이 얽혀있는 현대의 애플리케이션 이면에는 시스템의 안정성과 확장성을 좌우하는 보이지 않는 원리들이 숨어있습니다. 그중에서도 ‘팬인(Fan-In)’과 ‘팬아웃(Fan-Out)’은 시스템의 복잡도와 의존성을 이해하는 데 가장 기본적이면서도 핵심적인 개념입니다. 이 두 개념을 이해하는 것은 단순히 기술 용어를 아는 것을 넘어, 시스템의 잠재적인 병목 지점을 예측하고, 유지보수가 용이하며, 변화에 유연하게 대처할 수 있는 견고한 아키텍처를 설계하는 첫걸음이 됩니다.

본래 디지털 논리 회로 설계에서 유래한 팬인과 팬아웃은 이제 소프트웨어 공학, 특히 마이크로서비스 아키텍처(MSA), 데이터 엔지니어링, 이벤트 기반 시스템 등 현대적인 기술 패러다임에서 그 중요성이 더욱 부각되고 있습니다. 높은 팬아웃은 시스템 변경 시 ‘나비 효과’처럼 예상치 못한 파급 효과를 일으켜 유지보수 비용을 급증시키는 원인이 되기도 하고, 낮은 팬인은 코드의 재사용성이 떨어져 개발 효율을 저해하는 신호가 될 수 있습니다. 반면, 높은 팬인은 해당 모듈이 시스템 내에서 얼마나 중요하고 안정적인지를 보여주는 긍정적인 지표로 해석될 수 있습니다.

이 글에서는 팬인과 팬아웃의 기본적인 개념부터 시작하여, 이들이 소프트웨어 아키텍처에 어떻게 적용되고 어떠한 인과관계를 만들어내는지 심도 있게 파헤쳐 보고자 합니다. 또한, 넷플릭스(Netflix)의 마이크로서비스 아키텍처나 AWS Lambda를 활용한 서버리스 컴퓨팅과 같은 최신 사례를 통해 팬인과 팬아웃이 실제 시스템에서 어떻게 관리되고 최적화되는지 구체적으로 살펴보겠습니다. 독자 여러분은 이 글을 통해 시스템의 복잡성을 측정하고 제어하는 강력한 도구를 얻게 될 것이며, 더 나은 소프트웨어 설계를 위한 깊이 있는 통찰력을 갖추게 될 것입니다.

2. 팬인(Fan-In)과 팬아웃(Fan-Out)의 핵심 개념 완전 정복

팬인과 팬아웃의 개념을 정확히 이해하기 위해, 그 기원이 된 디지털 논리 회로의 관점에서 먼저 살펴보겠습니다. 이 기본 원리를 이해하면 소프트웨어 공학에서의 추상적인 개념을 훨씬 쉽게 받아들일 수 있습니다.

팬아웃 (Fan-Out): 하나의 신호가 얼마나 많은 부하를 감당하는가?

디지털 논리 회로에서 팬아웃은 하나의 논리 게이트(Logic Gate) 출력이 정상적으로 구동할 수 있는 다른 논리 게이트 입력의 최대 개수를 의미합니다. 쉽게 말해, 한 명의 리더(출력)가 몇 명의 팀원(입력)에게 명확한 지시를 내릴 수 있는지를 나타내는 수치와 같습니다.

출력 게이트는 제한된 전류 공급 능력을 가지고 있습니다. 만약 이 능력을 초과하여 너무 많은 입력 게이트에 연결되면, 전압 레벨이 불안정해져 신호가 왜곡되고 시스템 전체의 오작동을 유발할 수 있습니다. 예를 들어, 특정 게이트의 팬아웃이 ’10’이라면, 이는 해당 게이트의 출력 신호가 최대 10개의 다른 게이트 입력으로 안전하게 전달될 수 있음을 의미합니다. 이 수치를 넘어서면 시스템의 신뢰성은 보장할 수 없게 됩니다.

이러한 물리적 제약은 소프트웨어 세계에서도 유사한 함의를 가집니다. 소프트웨어 모듈의 팬아웃은 해당 모듈이 직접적으로 의존하는(호출하거나 사용하는) 다른 모듈의 수를 의미합니다. 팬아웃이 높다는 것은 하나의 모듈이 변경될 경우, 그 변경의 영향을 받는 다른 모듈이 많아진다는 것을 뜻하며, 이는 시스템의 복잡도와 유지보수 비용 증가로 직결됩니다.

팬인 (Fan-In): 하나의 게이트가 얼마나 많은 입력을 받는가?

반대로 팬인은 하나의 논리 게이트가 수용할 수 있는 입력 신호의 최대 개수를 말합니다. 예를 들어, 4개의 입력 단자를 가진 AND 게이트의 팬인은 ‘4’입니다. 이는 게이트가 4개의 서로 다른 입력 신호를 받아 하나의 출력 신호를 만들어낼 수 있음을 의미합니다.

팬인이 커질수록 게이트 내부 회로는 복잡해지고, 신호 전달에 지연(Propagation Delay)이 발생할 가능성이 커집니다. 여러 입력 신호가 동시에 게이트에 도달하고 처리되는 과정에서 시간이 소요되기 때문입니다. 따라서 하드웨어 설계에서는 성능 목표에 맞춰 적절한 팬인 값을 갖는 게이트를 선택하는 것이 중요합니다.

소프트웨어 공학에서 팬인은 하나의 모듈을 직접적으로 호출하거나 사용하는 다른 모듈의 수를 의미합니다. 어떤 모듈의 팬인이 높다는 것은 여러 다른 모듈들이 그 모듈에 의존하고 있다는 뜻이며, 이는 해당 모듈의 재사용성이 높고 시스템 내에서 중요한 역할을 수행하고 있음을 시사합니다. 따라서 소프트웨어 관점에서 높은 팬인은 일반적으로 긍정적인 지표로 간주됩니다.

구분	디지털 논리 회로 (Hardware)	소프트웨어 공학 (Software)
팬아웃 (Fan-Out)	하나의 게이트 출력이 연결될 수 있는 다른 게이트 입력의 최대 개수	하나의 모듈이 의존하는(호출하는) 다른 모듈의 개수
의미	전기적 부하, 구동 능력의 한계	의존성, 변경의 파급 효과(Ripple Effect)
높을 경우	신호 왜곡, 시스템 오작동 위험 증가	유지보수 어려움, 결합도(Coupling) 증가, 테스트 복잡성 증가
팬인 (Fan-In)	하나의 게이트가 가질 수 있는 입력 단자의 최대 개수	하나의 모듈을 의존하는(호출하는) 다른 모듈의 개수
의미	회로의 복잡성, 신호 처리 지연	재사용성, 모듈의 중요도 및 안정성
높을 경우	신호 전달 지연 시간 증가	높은 재사용성, 해당 모듈 수정 시 영향도 큼, 신중한 설계 필요

3. 디지털 논리 회로를 넘어 소프트웨어 아키텍처로

이제 팬인과 팬아웃의 개념을 소프트웨어 아키텍처의 세계로 확장해 보겠습니다. 코드와 모듈, 서비스 간의 상호작용을 이 두 가지 렌즈를 통해 바라보면 시스템의 구조적 건강 상태를 진단하고 개선 방향을 설정할 수 있습니다.

소프트웨어에서의 팬아웃: 의존성의 척도와 그 영향

소프트웨어에서 팬아웃은 하나의 모듈(클래스, 함수, 서비스 등)이 직간접적으로 알고 있어야 하는 다른 모듈의 개수를 나타냅니다. 즉, ‘결합도(Coupling)’와 깊은 관련이 있습니다. A 모듈이 B, C, D 모듈을 호출한다면, A의 팬아웃은 3입니다.

팬아웃이 높은 모듈은 ‘만물박사’ 또는 ‘문어발’ 모듈에 비유할 수 있습니다. 이러한 모듈은 너무 많은 책임을 지고 있으며, 시스템의 여러 부분과 강하게 결합되어 있습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다.

변경의 어려움: 팬아웃이 높은 모듈에 의존하는 모듈 중 하나라도 변경되면, 해당 모듈 자신도 변경되어야 할 가능성이 커집니다. 예를 들어, A가 의존하는 B 모듈의 인터페이스가 변경되면 A 모듈의 코드 수정은 불가피합니다. 이는 변경의 파급 효과(Ripple Effect)를 증폭시켜 유지보수를 악몽으로 만듭니다.
테스트의 복잡성: 해당 모듈을 테스트하기 위해서는 의존하는 모든 모듈을 함께 고려해야 합니다. 이는 단위 테스트(Unit Test)를 어렵게 만들고, 테스트 환경을 설정하는 데 많은 노력이 들게 합니다. 의존하는 모듈들을 실제 객체 대신 Mock 객체로 대체해야 하는 경우가 빈번해집니다.
재사용성 저하: 특정 컨텍스트에 지나치게 의존적인 모듈은 다른 환경에서 재사용하기 어렵습니다. 너무 많은 전제조건을 필요로 하기 때문입니다.

따라서 좋은 설계는 불필요한 팬아웃을 줄여 각 모듈이 자신의 책임에만 집중하도록 하는 것을 목표로 합니다. 이는 단일 책임 원칙(Single Responsibility Principle)과도 일맥상통합니다.

소프트웨어에서의 팬인: 재사용성의 지표와 그 가치

반면, 팬인은 하나의 모듈이 얼마나 많은 다른 모듈에 의해 사용되는지를 나타내는 지표입니다. 즉, ‘응집도(Cohesion)’와 연관 지어 생각할 수 있습니다. 유틸리티 라이브러리의 특정 함수나, 시스템 전반에서 사용되는 인증 모듈과 같이 잘 설계된 공통 모듈은 자연스럽게 팬인이 높아집니다.

높은 팬인은 일반적으로 긍정적인 신호로 해석되며, 다음과 같은 장점을 가집니다.

높은 재사용성: 팬인이 높다는 것은 해당 모듈의 기능이 여러 곳에서 필요로 할 만큼 범용적이고 유용하다는 명백한 증거입니다. 이는 코드 중복을 줄이고 개발 효율성을 높이는 데 크게 기여합니다.
안정성 검증: 여러 모듈에서 널리 사용된다는 사실 자체가 해당 모듈이 충분히 테스트되고 검증되었음을 의미할 수 있습니다. 버그가 있었다면 이미 여러 곳에서 문제가 발생했을 것이기 때문입니다.
중요도 인식: 시스템 내에서 어떤 모듈이 핵심적인 역할을 하는지 쉽게 파악할 수 있습니다. 팬인이 높은 모듈은 시스템의 기반이 되는 중요한 로직을 담고 있을 가능성이 높습니다.

하지만 팬인이 높은 모듈을 수정할 때는 극도의 주의가 필요합니다. 해당 모듈의 작은 변경 하나가 이를 사용하는 모든 모듈에 예기치 않은 부작용(Side Effect)을 일으킬 수 있기 때문입니다. 따라서 팬인이 높은 모듈은 엄격한 테스트 케이스와 명확한 API 문서, 그리고 하위 호환성을 고려한 신중한 변경 관리가 필수적입니다.

4. 현대 기술 속 팬인/팬아웃 적용 사례 분석

이론적인 개념을 넘어, 팬인과 팬아웃이 실제 현대 기술 환경에서 어떻게 나타나고 관리되는지 구체적인 사례를 통해 살펴보겠습니다.

사례 1: 마이크로서비스 아키텍처(MSA)의 통신 병목과 팬아웃

넷플릭스(Netflix)와 같은 대규모 기업들은 거대한 단일 애플리케이션(Monolithic Application)을 여러 개의 작은 독립적인 서비스로 분리하는 마이크로서비스 아키텍처(MSA)를 성공적으로 도입했습니다. 각 서비스는 독립적으로 개발, 배포, 확장이 가능하여 개발 속도와 유연성을 크게 향상시켰습니다.

하지만 MSA 환경에서는 서비스 간의 호출, 즉 네트워크 통신이 빈번하게 발생합니다. 여기서 팬아웃의 개념이 중요해집니다. 예를 들어, 사용자의 프로필 정보를 보여주는 ‘사용자 프로필 서비스’가 있다고 가정해 보겠습니다. 이 서비스가 완벽한 화면을 구성하기 위해 ‘주문 내역 서비스’, ‘시청 기록 서비스’, ‘추천 콘텐츠 서비스’, ‘결제 정보 서비스’ 등을 모두 직접 호출해야 한다면, ‘사용자 프로필 서비스’의 팬아웃은 매우 높아집니다.

이러한 구조는 심각한 문제를 야기할 수 있습니다. 의존하는 서비스 중 하나라도 응답이 지연되거나 장애가 발생하면, 그 영향이 ‘사용자 프로필 서비스’에 즉시 전파되어 전체 서비스의 장애로 이어질 수 있습니다. 이를 ‘연쇄 장애(Cascading Failure)’라고 합니다. 또한, 각 서비스의 API가 변경될 때마다 ‘사용자 프로필 서비스’는 계속해서 코드를 수정해야 합니다.

이 문제를 해결하기 위해 등장한 패턴이 바로 API Gateway입니다. API Gateway는 클라이언트의 요청을 받는 단일 진입점(Single Point of Entry) 역할을 하며, 여러 마이크로서비스를 호출하고 그 결과를 조합하여 클라이언트에게 최종적으로 응답합니다. 이를 통해 개별 서비스의 팬아웃을 획기적으로 줄일 수 있습니다. ‘사용자 프로필 서비스’는 이제 API Gateway만 호출하면 되므로 팬아웃이 ‘1’로 줄어듭니다. 반대로 API Gateway는 수많은 서비스를 호출해야 하므로 팬아웃이 높지만, 그 역할 자체가 원래부터 분산된 서비스들을 통합하는 것이므로 문제가 되지 않습니다. 대신, API Gateway 자체의 팬인은 높아져 시스템의 중요한 관문 역할을 수행하게 됩니다.

사례 2: 대규모 데이터 처리 파이프라인과 팬인/팬아웃

빅데이터 처리 환경에서는 수많은 데이터 소스로부터 데이터를 수집(Fan-In)하고, 이를 가공하여 여러 목적지로 분산(Fan-Out)시키는 패턴이 흔하게 사용됩니다.

팬인 패턴: Apache Kafka나 AWS Kinesis와 같은 메시지 큐 또는 스트리밍 플랫폼은 대표적인 팬인 패턴의 예시입니다. 웹 서버 로그, 애플리케이션 메트릭, IoT 디바이스 센서 데이터 등 다양한 소스에서 발생하는 이벤트 데이터들이 하나의 Kafka 토픽(Topic)으로 집중됩니다. 이렇게 데이터가 한곳으로 모이면, 중앙에서 데이터를 일관된 방식으로 관리하고 처리할 수 있게 됩니다. 즉, 데이터 파이프라인의 진입점 역할을 하는 Kafka 토픽은 매우 높은 팬인을 가지게 됩니다.
팬아웃 패턴: 이렇게 Kafka 토픽에 모인 데이터는 여러 컨슈머(Consumer) 그룹에 의해 소비됩니다. 예를 들어, 동일한 실시간 클릭 스트림 데이터를 가지고 ‘실시간 이상 탐지 시스템’은 사기 행위를 분석하고, ‘추천 시스템’은 사용자 맞춤형 콘텐츠를 생성하며, ‘데이터 웨어하우스 적재 시스템’은 장기 보관을 위해 데이터를 저장소로 보냅니다. 이 경우, 하나의 Kafka 토픽(데이터 생산자)이 여러 목적을 가진 시스템(데이터 소비자)으로 데이터를 분배하므로 높은 팬아웃을 가지게 됩니다. 이러한 발행/구독(Pub/Sub) 모델은 시스템 간의 결합도를 낮추고, 새로운 데이터 소비자를 유연하게 추가할 수 있게 해주는 강력한 아키텍처 패턴입니다.

최신 사례: 서버리스 컴퓨팅과 이벤트 기반 아키텍처

AWS Lambda와 같은 서버리스 컴퓨팅(Function-as-a-Service, FaaS) 환경은 이벤트 기반 아키텍처(Event-Driven Architecture, EDA)와 결합하여 팬인/팬아웃 패턴을 극적으로 활용합니다.

예를 들어, 사용자가 아마존 S3(Simple Storage Service) 버킷에 이미지를 업로드하는 이벤트를 생각해 보겠습니다. 이 ‘이미지 업로드’ 이벤트 하나가 트리거가 되어 다양한 Lambda 함수들을 동시에 실행시킬 수 있습니다.

이미지 리사이징 Lambda 함수 (썸네일 생성)
이미지 메타데이터 추출 Lambda 함수 (촬영 시간, 장소 등 DB 저장)
AI 기반 이미지 분석 Lambda 함수 (객체 탐지, 얼굴 인식)
콘텐츠 관리 시스템(CMS)에 알림을 보내는 Lambda 함수

이 경우, S3의 이벤트 소스는 팬아웃되어 여러 Lambda 함수를 동시에 호출합니다. 각 Lambda 함수는 독립적으로 자신의 역할을 수행하므로 시스템 전체의 처리 속도가 병렬화되어 빨라집니다. 반대로, 여러 다른 이벤트 소스(예: API Gateway를 통한 HTTP 요청, DynamoDB 테이블의 데이터 변경 이벤트)가 모두 동일한 ‘사용자 활동 로깅’ Lambda 함수를 호출할 수 있습니다. 이 경우 ‘사용자 활동 로깅’ 함수는 높은 팬인을 가지며, 시스템의 공통적인 관심사를 처리하는 중요한 역할을 맡게 됩니다.

5. 팬인/팬아웃, 어떻게 관리하고 최적화할 것인가?

그렇다면 우리는 어떻게 코드와 아키텍처 수준에서 팬인과 팬아웃을 의도적으로 관리하고 최적의 균형점을 찾을 수 있을까요?

팬아웃 관리 전략: 의존성 역전 원칙과 인터페이스의 활용

과도한 팬아웃은 시스템을 경직되게 만드는 주범입니다. 팬아웃을 효과적으로 관리하기 위한 핵심 전략은 **추상화(Abstraction)**에 의존하는 것입니다. 구체적인 구현 클래스가 아닌, 안정적인 인터페이스나 추상 클래스에 의존하도록 코드를 작성하면 팬아웃의 부정적인 영향을 크게 줄일 수 있습니다.

이는 객체 지향 설계의 원칙 중 하나인 **의존성 역전 원칙(Dependency Inversion Principle, DIP)**과 직접적으로 연결됩니다. 상위 수준 모듈이 하위 수준 모듈의 구체적인 구현에 의존하는 대신, 둘 모두 추상화된 인터페이스에 의존해야 한다는 원칙입니다.

예를 들어, ReportGenerator라는 클래스가 데이터를 MySQLDatabase와 OracleDatabase에서 직접 읽어온다고 가정해 봅시다. 이 경우 ReportGenerator는 두 개의 구체 클래스에 의존하므로 팬아웃이 2가 되며, 새로운 데이터베이스(예: PostgreSQLDatabase)가 추가될 때마다 코드를 수정해야 합니다.

// 나쁜 예: 높은 팬아웃과 구체 클래스 의존
class ReportGenerator {
private MySQLDatabase mySqlDb;
private OracleDatabase oracleDb;

public ReportGenerator() {
this.mySqlDb = new MySQLDatabase();
this.oracleDb = new OracleDatabase();
}

public void generate() {
// mySqlDb와 oracleDb를 직접 사용하여 리포트 생성
}
}

DIP를 적용하면, Database라는 인터페이스를 정의하고, ReportGenerator는 이 인터페이스에만 의존하게 만듭니다. 실제 사용할 데이터베이스 객체는 외부에서 주입(Dependency Injection)받습니다.

// 좋은 예: 팬아웃 감소와 추상화 의존
interface Database {
Data readData();
}

class ReportGenerator {
private List<Database> databases;

public ReportGenerator(List<Database> databases) {
this.databases = databases;
}

public void generate() {
// 주입받은 databases 리스트를 순회하며 리포트 생성
}
}

이제 ReportGenerator는 오직 Database 인터페이스 하나에만 의존하므로 팬아웃이 크게 줄어들고, 새로운 데이터베이스가 추가되어도 ReportGenerator의 코드는 전혀 변경할 필요가 없습니다. 이처럼 인터페이스를 활용한 설계는 팬아웃을 관리하고 시스템의 유연성을 확보하는 강력한 무기입니다.

팬인 증대 전략: 공통 모듈 설계와 라이브러리화

바람직한 팬인을 높이기 위한 전략은 시스템 전반에 걸쳐 중복되는 기능과 로직을 식별하고, 이를 잘 정의된 공통 모듈이나 라이브러리로 추출하는 것입니다.

예를 들어, 여러 서비스에서 사용자 인증 및 권한 부여 로직이 반복적으로 구현되고 있다면, 이는 비효율적일 뿐만 아니라 보안상 허점을 만들기도 쉽습니다. 이 공통 로직을 별도의 ‘인증 서비스’ 또는 ‘인증 라이브러리’로 만들어 모든 서비스가 이를 호출하도록 설계하면, 해당 모듈의 팬인은 자연스럽게 높아집니다.

이렇게 만들어진 공통 모듈은 다음과 같은 특징을 가져야 합니다.

높은 응집도: 모듈은 명확하게 정의된 단일 책임을 가져야 합니다.
안정적인 인터페이스: 한번 정의된 API는 하위 호환성을 깨뜨리지 않고 신중하게 변경되어야 합니다.
충분한 테스트: 시스템의 여러 부분에 영향을 미치므로, 견고하고 포괄적인 테스트 코드가 필수적입니다.
명확한 문서: 사용 방법을 쉽게 이해할 수 있도록 문서화가 잘 되어 있어야 합니다.

높은 팬인을 가진 모듈을 설계하는 것은 단순히 코드를 재사용하는 것을 넘어, 시스템의 아키텍처를 안정적이고 일관성 있게 만드는 핵심적인 활동입니다.

6. 결론: 안정적이고 확장 가능한 시스템을 위한 필독서

지금까지 우리는 팬인과 팬아웃이라는 두 가지 단순한 지표를 통해 시스템의 복잡성과 구조적 건강 상태를 진단하는 방법을 살펴보았습니다. 디지털 회로의 기본 개념에서 출발하여 현대적인 마이크로서비스 아키텍처와 데이터 파이프라인에 이르기까지, 팬인과 팬아웃은 시대를 관통하며 시스템 설계의 핵심 원리로 자리 잡고 있습니다.

핵심을 다시 정리하자면, 바람직한 설계는 불필요한 팬아웃을 낮추고, 유용한 팬인을 높이는 방향으로 나아가야 합니다. 팬아웃을 낮추는 것은 모듈 간의 결합도를 줄여 변화에 유연하고 유지보수가 쉬운 시스템을 만드는 길이며, 이는 인터페이스와 의존성 역전 원칙을 통해 달성할 수 있습니다. 반대로, 팬인을 높이는 것은 코드의 재사용성을 극대화하고 시스템의 공통 기반을 견고하게 다지는 과정이며, 이는 잘 설계된 공통 모듈과 라이브러리화를 통해 이룰 수 있습니다.

물론 모든 상황에 적용되는 절대적인 규칙은 없습니다. 때로는 성능 최적화를 위해 의도적으로 결합도를 높여야 할 수도 있고, 비즈니스의 핵심 도메인 로직은 팬인이 낮을 수밖에 없습니다. 중요한 것은 팬인과 팬아웃이라는 렌즈를 통해 우리가 만들고 있는 시스템의 의존성 구조를 의식적으로 분석하고, 각 결정이 미래에 어떤 영향을 미칠지 예측하며 트레이드오프를 고려하는 자세입니다.

이 글을 통해 얻은 통찰력을 바탕으로 여러분의 코드와 시스템 아키텍처를 다시 한번 점검해 보시길 바랍니다. 과도한 책임을 지고 있는 ‘문어발’ 모듈은 없는지, 혹은 시스템 곳곳에 보석처럼 숨어있는 재사용 가능한 로직을 발견하여 빛나는 공통 모듈로 만들어낼 수는 없는지 고민해 본다면, 분명 더 안정적이고 확장 가능한 시스템을 향한 의미 있는 첫걸음을 내디딜 수 있을 것입니다.

[태그:] 객체 지향 설계

시스템의 숨겨진 병목, 팬인(Fan-In)과 팬아웃(Fan-Out)을 파헤치다: 마이크로서비스부터 데이터 파이프라인까지

목차