162. 갓 클래스/블랍 (God Class / Blob)

핵심 인사이트 (3줄 요약)

본질: 갓 클래스/블랍 (God Class / Blob)은 하나의 클래스가 너무 많은 데이터와 책임을 끌어안아, 응집도는 낮고 결합도는 높아진 대표적 객체지향 안티 패턴 (Anti-Pattern)이다.

가치: 이 안티 패턴을 조기에 식별하면 변경 영향 범위를 줄이고, 테스트 가능성과 병렬 개발성을 높이며, 도메인 경계를 더 명확히 재구성할 수 있다.

판단 포인트: 클래스가 크다는 사실만으로 갓 클래스는 아니다. 다수의 변경 이유, 높은 외부 의존, 약한 책임 경계가 함께 나타날 때 분해 대상이라고 판단해야 한다.

Ⅰ. 개요 및 필요성

갓 클래스/블랍 (God Class / Blob)은 단일 클래스가 시스템의 핵심 로직, 데이터 접근, 화면 처리, 외부 연동까지 과도하게 담당하는 구조를 말한다. 객체지향 설계에서는 단일 책임 원칙 (SRP, Single Responsibility Principle)이 "클래스는 하나의 변경 이유만 가져야 한다"고 보지만, 갓 클래스는 여러 변경 이유를 한 곳에 모아 구조적 병목이 된다. 초기에는 개발 속도를 높이는 것처럼 보이지만, 기능이 늘수록 수정 비용과 장애 전파 범위가 더 빠르게 커진다.

이 문제가 자주 생기는 이유는 단순하다. 일정 압박이 있으면 가장 손쉬운 선택은 "기존 큰 클래스에 메서드 하나 더 추가하는 것"이기 때문이다. 그러나 이런 누적은 도메인 지식을 한 파일에 몰아넣고, 다른 개발자가 시스템을 이해하려면 그 거대한 클래스부터 해독해야 하는 상황을 만든다. 결국 유지보수성과 확장성, 팀 생산성이 동시에 떨어진다.

설계·감리 관점에서 갓 클래스는 코드 스타일 문제가 아니라 구조 위험 신호다. 결함 밀도, 회귀 테스트 비용, 배포 리스크가 특정 클래스에 집중되기 때문에, 시스템 품질을 해치는 중심축이 되기 쉽다.

📢 섹션 요약 비유: 갓 클래스는 한 사람이 접수, 진료, 수납, 약 조제까지 모두 맡는 병원 창구와 같다. 처음엔 편해 보여도 한 군데가 막히면 전체 서비스가 멈춘다.

Ⅱ. 아키텍처 및 핵심 원리

갓 클래스는 보통 책임 축이 섞이면서 만들어진다. 사용자 인증, 주문 처리, 통계 집계, 외부 API 호출처럼 서로 다른 변화 주기를 가진 기능이 한 클래스에 쌓이면, 메서드 간 공통 데이터도 줄고 외부 의존은 늘어난다. 그 결과 클래스 내부는 느슨해지고 외부와는 강하게 묶이는 구조가 된다.

아래 그림은 갓 클래스가 어떻게 시스템의 모든 방향으로 손을 뻗으며 구조 병목이 되는지 보여 준다.

┌──────────────────────────────────────────────────────────────┐
│                God Class / Blob의 구조적 병목                │
├──────────────────────────────────────────────────────────────┤
│                       OrderManager                           │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ 인증 │ 주문 │ 결제 │ 메일 │ 통계 │ 캐시 │ 예외처리     │  │
│  └────────────────────────────────────────────────────────┘  │
│      │       │      │      │      │      │                 │
│      ├───────┼──────┼──────┼──────┼──────┤                 │
│      ▼       ▼      ▼      ▼      ▼      ▼                 │
│   UserDB   PG사   Mail   Report Cache  Audit                │
│                 Gateway Server Store  Log                   │
└──────────────────────────────────────────────────────────────┘

이런 구조는 정량 지표로도 드러난다. 가중 메서드 수 (WMC, Weighted Methods per Class)가 높고, 객체 간 결합도 (CBO, Coupling Between Objects)가 크며, 메서드 응집도 결여 (LCOM, Lack of Cohesion in Methods)가 커질수록 갓 클래스 가능성이 높다. 특히 외부 데이터 과다 접근 (ATFD, Access to Foreign Data)이 높으면 "자기 일보다 남의 데이터를 끌어와 처리하는 클래스"일 가능성이 크다.

징후	의미	실무 해석
클래스 크기 급증	메서드·필드가 비정상적으로 많음	새 기능 추가 시 이 클래스가 기본 진입점이 됨
높은 CBO	외부 객체 의존이 많음	변경 영향 범위가 넓고 테스트 격리가 어려움
높은 LCOM	메서드들이 공통 상태를 거의 공유하지 않음	책임이 여러 덩어리로 섞여 있음
높은 ATFD	타 객체 내부 데이터를 직접 자주 사용	캡슐화가 무너지고 도메인 경계가 흐려짐

따라서 갓 클래스 해소의 핵심은 단순 분할이 아니라 책임 축을 다시 세우는 것이다. 도메인 책임별로 클래스를 나누고, 조정 역할이 필요하면 얇은 오케스트레이터(Orchestrator)만 남겨야 한다. 큰 클래스가 아니라 "많은 이유로 동시에 바뀌는 클래스"가 문제라는 점이 본질이다.

📢 섹션 요약 비유: 갓 클래스는 여러 칸막이가 무너진 창고와 같다. 물건은 많지만 분류가 안 돼 있어 찾기 어렵고, 하나를 옮기다 다른 물건까지 다 무너진다.

Ⅲ. 비교 및 연결

갓 클래스는 종종 퍼사드 (Facade)나 애플리케이션 서비스와 혼동된다. 그러나 퍼사드는 복잡한 서브시스템을 단순 인터페이스로 감싸되, 실제 책임은 하위 객체에 위임한다. 반면 갓 클래스는 인터페이스만 큰 것이 아니라 실제 상태와 규칙까지 직접 소유해 변경이 집중된다.

비교 항목	갓 클래스/블랍	퍼사드 (Facade)	책임 분리된 서비스
주목적	기능을 한곳에 몰아 처리	복잡한 사용법을 단순화	책임별 업무 수행
비즈니스 로직 위치	클래스 내부에 과다 집중	하위 객체에 대부분 위임	각 서비스에 분산
상태 보유	많음	보통 적음	책임 범위 내 최소화
변경 이유	여러 개	인터페이스 변화 중심	도메인별로 제한
테스트 난이도	높음	중간	낮음

이 안티 패턴은 단일 책임 원칙 (SRP), 인터페이스 분리 원칙 (ISP, Interface Segregation Principle), 의존 역전 원칙 (DIP, Dependency Inversion Principle)과 직접 연결된다. SRP를 어기면 책임이 커지고, ISP를 어기면 거대한 인터페이스가 생기며, DIP가 약하면 상위 로직이 세부 구현과 강하게 묶인다. 즉 갓 클래스는 하나의 실수보다 여러 설계 원칙 붕괴가 겹쳐 나타나는 결과다.

또 싱글톤 (Singleton)과 결합하면 위험이 커진다. 전역 접근 가능한 거대 클래스는 편의성 때문에 더 많은 책임을 끌어당기고, 결국 테스트와 병렬 개발의 적이 된다. 감리 답안에서는 "중앙 집중" 자체가 아니라 "위임 없는 중앙 집중"이 문제라고 구분해서 쓰는 것이 중요하다.

📢 섹션 요약 비유: 퍼사드는 안내 데스크이고, 갓 클래스는 안내 데스크 직원이 직접 창고 관리·정산·배송까지 다 하는 상황이다. 겉모습은 비슷해도 부담의 무게가 완전히 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 갓 클래스를 한 번에 쪼개기보다, 변경 빈도와 책임 경계를 기준으로 단계적으로 분해해야 한다. 먼저 메서드와 필드를 기능별로 군집화하고, 외부 의존이 많은 영역부터 별도 서비스나 도메인 객체로 분리한다. 그 뒤 남은 클래스는 조정 역할만 수행하게 줄이는 방식이 안전하다. 이 과정에서 단위 테스트와 승인 테스트가 없다면 분해 자체가 새로운 장애를 만들 수 있다.

리팩토링 체크리스트

최근 변경 이력이 특정 대형 클래스에 반복적으로 몰렸는가?
메서드들이 사용하는 필드 집합이 여러 덩어리로 분리되는가?
외부 시스템 호출, 데이터 접근, 화면 로직이 한 클래스에 함께 있는가?
해당 클래스를 단독 테스트하기 위해 목 객체(Mock Object)가 과도하게 필요한가?
도메인 경계나 바운디드 컨텍스트 (Bounded Context) 기준으로 분리 가능한가?

실무 판단 포인트

즉시 분해 대상: 변경 충돌이 잦고 장애 원인이 반복적으로 한 클래스에 모이는 경우
주의 관찰 대상: 클래스가 크더라도 단순 오케스트레이션만 하고 실제 규칙은 위임하는 경우
안티패턴: 클래스만 여러 개로 쪼개고 정적 유틸리티나 전역 상태로 다시 묶어 버리는 경우

기술사 관점에서는 "갓 클래스의 문제점"만 쓰면 부족하다. 어떤 지표로 냄새를 포착하고, 어떤 기준으로 책임을 분리하며, 리팩토링 후 어떤 품질 속성(변경 용이성, 시험 용이성, 재사용성)이 개선되는지까지 연결해야 답안의 설득력이 생긴다.

📢 섹션 요약 비유: 갓 클래스 리팩토링은 무거운 이삿짐을 한 상자에 다 담아두지 않고 방별로 다시 나누는 작업과 같다. 정리 기준이 있어야 옮길 때도 덜 깨지고, 나중에 찾기도 쉽다.

Ⅴ. 기대효과 및 결론

갓 클래스를 제거하면 변경 영향 범위가 줄고, 테스트 단위가 작아지며, 팀원이 각자 독립적으로 기능을 수정할 여지가 커진다. 이는 단순 코드 미관이 아니라 배포 안정성, 회귀 결함 감소, 개발 속도 향상으로 이어진다. 특히 도메인 경계가 선명해지면 이후 마이크로서비스 분리나 모듈화 설계로 확장할 때도 유리하다.

다만 무조건 작은 클래스를 많이 만드는 것이 정답은 아니다. 책임 경계 없이 기계적으로 분할하면 오히려 호출 관계만 복잡해질 수 있다. 따라서 핵심은 "작게 쪼개기"가 아니라 "같이 변하는 것끼리 묶고, 다르게 변하는 것은 분리하기"다.

결론적으로 갓 클래스/블랍은 객체지향 설계의 실패 신호이자 리팩토링 우선순위 결정 지표로 기억할 필요가 있다. 큰 클래스 자체보다, 시스템의 여러 축이 한곳에 엉겨 붙어 있다는 사실이 본질적 위험이다.

📢 섹션 요약 비유: 좋은 조직은 모든 일을 한 명의 영웅에게 맡기지 않는다. 각자 맡은 부서가 분명해야 회사도 오래 건강하게 돌아간다.

📌 관련 개념 맵

개념	연결 포인트
안티 패턴 (Anti-Pattern)	갓 클래스는 반복적으로 품질 저하를 일으키는 대표적 구조 실패 사례다.
단일 책임 원칙 (SRP, Single Responsibility Principle)	갓 클래스는 하나의 클래스가 여러 변경 이유를 가지며 SRP를 위반한다.
퍼사드 (Facade)	중앙 진입점처럼 보이지만 실제 책임 위임 여부에서 갓 클래스와 갈린다.
클래스 추출 (Extract Class)	갓 클래스 분해에 가장 직접적으로 쓰이는 리팩토링 기법이다.
바운디드 컨텍스트 (Bounded Context)	도메인 경계를 기준으로 책임을 나눌 때 유용한 설계 기준이다.

📈 관련 키워드 및 발전 흐름도

객체지향 설계 원칙
    │
    ▼
SRP (Single Responsibility Principle)
    │
    ▼
안티 패턴 (Anti-Pattern)
    │
    ▼
갓 클래스 / 블랍 (God Class / Blob)
    │
    ├─▶ 품질 지표: CBO · LCOM · WMC · ATFD
    │
    └─▶ 리팩토링: Extract Class · Interface Segregation
                 │
                 ▼
         도메인 경계 재정립

이 흐름은 설계 원칙 위반이 안티 패턴으로 드러나고, 이를 정량 지표와 리팩토링으로 되돌리는 과정을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

갓 클래스는 한 친구가 반장, 청소, 발표, 숙제 검사까지 전부 다 맡는 것과 같아요.
처음엔 빨라 보여도 그 친구가 아프면 반 전체가 바로 엉망이 돼요.
그래서 일은 잘게 나눠 각자 맡게 해야 모두가 편하고 실수도 줄어요.