197. 팬인 (Fan-in) / 팬아웃 (Fan-out) - 모듈 복잡도 지표

핵심 인사이트: 회사 조직도에서 '내 밑에 부하 직원이 몇 명인가'가 팬아웃(Fan-out)이고, '나를 부르는 상사가 몇 명인가'가 팬인(Fan-in)이다. 부하 직원이 너무 많으면 관리하기 힘들고(통제 불가), 상사가 많으면 공용으로 잘 쓰이는 핵심 인재(재사용성 높음)라는 뜻이다.

Ⅰ. 팬인(Fan-in)과 팬아웃(Fan-out)의 개념

소프트웨어 설계에서 모듈의 구조적 복잡도(Complexity)와 재사용성을 측정하는 아주 직관적이고 중요한 지표입니다. 시스템의 구조도(Structure Chart) 상에서 모듈 간의 호출 관계(선)를 세어서 계산합니다.

        [ 모듈 A ]         [ 모듈 B ]         [ 모듈 C ]
             │                 │                  │
             └────────┬────────┘                  │
                      ▼                           ▼
                 [ 모듈 D ] ◀─────────────────────┘
                 (Fan-in: 3)
                (Fan-out: 2)
                 ┌────┴────┐
                 ▼         ▼
             [모듈 E]   [모듈 F]

Ⅱ. 팬인 (Fan-in) : 나를 호출하는 모듈의 수

• 의미: "얼마나 많은 모듈들이 나를 필요로 하는가?"
• 특징: 팬인이 높다는 것은 그 모듈이 여러 곳에서 공통으로 많이 재사용(Reuse) 되고 있다는 뜻입니다. (예: '로그인 체크 모듈'은 장바구니, 마이페이지 등 모든 곳에서 호출하므로 팬인이 매우 높습니다.)
• 설계 지침: 훌륭한 설계는 Fan-in을 높게 유지하여 중복 코드를 줄이는 것입니다. 단, 너무 높으면 단일 장애점(SPOF)이 될 수 있으므로 테스트를 가장 빡세게 해야 합니다.

Ⅲ. 팬아웃 (Fan-out) : 내가 호출하는 모듈의 수

• 의미: "내가 일을 시키는(부려 먹는) 모듈이 몇 개인가?"
• 특징: 팬아웃이 높다는 것은 그 모듈이 자신이 해야 할 일을 수많은 하위 모듈에게 뿌려주는 '제어(Control)' 역할이 강하다는 뜻입니다. 반면, 내부 로직이 너무 복잡해 통제력이 떨어진다는 신호이기도 합니다.
• 설계 지침: 훌륭한 설계는 Fan-out을 낮게(보통 3~4 이내) 유지하는 것입니다. 만약 Fan-out이 너무 크면, 중간 관리자 모듈을 하나 더 만들어서 지시 체계를 단순화(계층화)해야 합니다.

Ⅳ. 요약된 최적의 설계 원칙

• Fan-in은 높게 (High) ➔ 재사용 극대화
• Fan-out은 낮게 (Low) ➔ 제어의 복잡도 최소화

📢 섹션 요약 비유: '프린트 출력'이라는 비서(모듈)는 영업부, 인사부, 개발부 등 수많은 상사들이 부르므로 팬인(Fan-in)이 높습니다(아주 유능한 공유 자원). 반면 '프로젝트 매니저(모듈)'가 혼자서 디자인, 개발, 기획, 테스트 등 10개의 하청업체(팬아웃 10)를 직접 관리하려 들면 과로사하므로, 중간 관리자(팬아웃 줄이기)를 둬서 체계를 잡아야 합니다.