◆ TURNING · SPRING

new 의 함정

강한 결합을 직접 느껴보는 차시 — 읽기 자료

📍 지금 어디를 만지고 있나요?
브라우저
Tomcat
코드 안 결합
Controller
DB

이 차시의 핵심 용어

강한 결합 (Tight Coupling)한 클래스가 다른 구체 클래스에 직접 의존하는 상태. 부품 교체 시 클래스 수정 필요.
느슨한 결합 (Loose Coupling)인터페이스를 통해서만 의존하는 상태. 부품 구체 클래스 교체에 클래스 수정 불필요. 다음 차시들의 목표.
OCP (개방-폐쇄 원칙)"확장에는 열려있고 수정에는 닫혀있어야 한다." 새 부품을 추가하더라도 기존 클래스를 수정하지 않는 것.

1. 평범해 보이는 코드

class OrderService {
    private MailSender mail = new GmailSender();

    void order() {
        // ... 주문 처리
        mail.send("주문 완료");
    }
}

아무 문제 없어 보입니다. 이렇게 짜는 게 자연스럽죠. 그런데 — 한 줄짜리 요구사항이 들어옵니다.

요청서

"이메일이 자꾸 스팸으로 빠집니다. 카카오톡 알림으로 바꿔주세요."

2. 변경의 도미노

한 클래스의 한 줄을 바꾸면 끝일 것 같지만, 실제로는:

  1. OrderServicenew GmailSender()new KakaoSender() 로 변경
  2. 그런데 KakaoSender 의 메서드 이름이 send() 가 아니고 notify()?
  3. 그럼 OrderService 안에서 호출 코드도 수정
  4. 같은 패턴이 다른 클래스 (CartService, UserService) 에도 있다면? 모두 수정
  5. 단위 테스트도 다 수정 — 진짜 카카오톡 API 를 호출할 수 없으니 Mock 으로 갈아끼움

한 줄 요청이 코드베이스 여러 군데를 부수는 사건이 됩니다.

3. 강한 결합의 정체

「내가 직접 만든다」의 대가

클래스 안에서 new ConcreteClass() 로 직접 객체를 생성하면, 그 클래스는 해당 구체 클래스에 꽉 묶여 있게 됩니다. 인터페이스가 아니라 실체에 의존하는 상태입니다.

OrderService ────new────→ GmailSender ▲ 꽉 묶임 │ 다른 부품으로 갈아끼우려면 OrderService 자체를 수정해야 함

4. 비유 — 일체형 가전

강한 결합은 부품을 갈아끼울 수 없는 일체형 가전과 같습니다. 메인보드 하나만 고장나도 통째로 버려야 하죠. 반면 모듈식 PC 는 부품 하나만 교체하면 됩니다.

5. 다음 차시의 약속

IoC / DI 가 풀어줄 것

다음 두 차시에서 다룰 IoC (제어 역전)DI (의존성 주입) 는, 클래스 안에서 직접 new 하지 않고 외부에서 객체를 받아쓰는 방식을 도입합니다. 이 방식이 「부품 교체」를 코드 수정 없이 가능하게 만듭니다.

6. Before / After

전 차시 끝

객체가 어떻게 만들어지는지 안다 — new 가 자연스럽다고 느낌.

이번 차시 끝

new 의 함정을 손으로 느꼈다. 부품 교체가 왜 어려운지 안다. 다음 도구의 동기가 분명해진다.