Engineering

디자인 패턴, 파사드(Facade pattern)

소프트웨어가 점점 커지고 기능이 많아질수록 하나의 기능을 처리하기 위해 여러 객체와 서비스가 함께 동작하게 됩니다. 처음에는 간단했던 코드도 시간이 지나면서 복잡한 의존성을 가지게 되고, 결국 특정 기능 하나를 호출하기 위해 여러 클래스의 메서드를…

M
Mason
Software Engineer · · 4분

소프트웨어가 점점 커지고 기능이 많아질수록 하나의 기능을 처리하기 위해 여러 객체와 서비스가 함께 동작하게 됩니다. 처음에는 간단했던 코드도 시간이 지나면서 복잡한 의존성을 가지게 되고, 결국 특정 기능 하나를 호출하기 위해 여러 클래스의 메서드를 순서대로 실행해야 하는 상황이 발생합니다.

이러한 복잡성을 줄이기 위해 사용하는 디자인 패턴이 바로 파사드(Facade) 패턴입니다.

파사드 패턴은 구조(Structural) 패턴 중 하나로, 복잡한 서브 시스템을 하나의 단순한 인터페이스로 감싸 사용자에게 제공하는 패턴입니다. 사용자는 내부 구조를 알 필요 없이 파사드 객체만 호출하면 원하는 기능을 사용할 수 있습니다.

파사드(Facade)는 건축 용어로 건물의 정면을 의미합니다. 건물 내부에는 다양한 구조와 설비가 존재하지만 외부에서는 하나의 깔끔한 외관만 보이는 것처럼, 소프트웨어에서도 복잡한 내부 로직을 숨기고 단순한 진입점을 제공하는 역할을 수행합니다.

예를 들어 회원가입 기능을 생각해보겠습니다. 회원가입이 완료되기 위해서는 사용자 정보 저장, 비밀번호 암호화, 이메일 발송, 포인트 지급, 로그 기록 등 여러 작업이 동시에 수행될 수 있습니다.

파사드 패턴을 사용하지 않는 경우 다음과 같은 코드가 작성될 수 있습니다.

UserService userService = new UserService();
EmailService emailService = new EmailService();
PointService pointService = new PointService();
LogService logService = new LogService();
 
userService.createUser(user);
emailService.sendWelcomeMail(user);
pointService.giveWelcomePoint(user);
logService.writeLog(user);

위 코드는 서비스가 추가될수록 호출하는 코드도 함께 수정되어야 합니다. 또한 서비스 호출 순서를 잘못 작성하면 예상하지 못한 문제가 발생할 수 있습니다.

이러한 문제를 해결하기 위해 파사드 클래스를 생성할 수 있습니다.

public class UserFacade {
 
    private UserService userService;
    private EmailService emailService;
    private PointService pointService;
    private LogService logService;
 
    public void signup(User user) {
        userService.createUser(user);
        emailService.sendWelcomeMail(user);
        pointService.giveWelcomePoint(user);
        logService.writeLog(user);
    }
}

이제 클라이언트는 복잡한 내부 로직을 알 필요 없이 하나의 메서드만 호출하면 됩니다.

UserFacade userFacade = new UserFacade();
 
userFacade.signup(user);

코드의 가독성이 향상되고 클라이언트와 서브 시스템 간의 결합도도 크게 감소하게 됩니다.

파사드 패턴의 가장 큰 장점은 복잡한 시스템을 단순하게 사용할 수 있다는 점입니다. 내부 구현이 변경되더라도 클라이언트 코드는 영향을 적게 받으며, 기능 사용 방법이 명확해집니다. 또한 여러 객체를 조합하여 하나의 비즈니스 기능으로 제공할 수 있기 때문에 유지보수성과 확장성이 향상됩니다.

반면 모든 기능을 하나의 파사드에 집중시키면 객체가 지나치게 비대해질 수 있습니다. 또한 지나친 추상화는 내부 기능을 세밀하게 제어해야 하는 상황에서 오히려 불편함을 초래할 수 있으므로 적절한 수준에서 사용하는 것이 중요합니다.

파사드 패턴은 실무에서도 매우 자주 사용됩니다. Spring의 Service 계층이 여러 Repository를 묶어 하나의 비즈니스 로직을 제공하는 경우, 결제 시스템에서 PG사 연동과 주문 처리 로직을 하나로 제공하는 경우, 또는 복잡한 외부 API 호출을 하나의 서비스로 감싸는 경우 등이 대표적인 예시입니다.

결국 파사드 패턴은 복잡한 시스템을 단순하게 만들기 위한 패턴입니다. 사용자는 내부 구조를 알지 못해도 원하는 기능을 쉽게 사용할 수 있으며, 개발자는 복잡한 의존성을 효과적으로 관리할 수 있습니다. 규모가 커질수록 코드의 진입점을 단순하게 유지하는 것이 중요한데, 이러한 상황에서 파사드 패턴은 매우 유용한 해결책이 될 수 있습니다.

이 글이 어떠셨나요? 이모지로 반응을 남겨주세요
M
Mason
Software Engineer · masonlab

코드와 비즈니스, 그 사이에서 배운 것들을 기록하고 공유합니다.

댓글 0

아직 댓글이 없어요. 첫 댓글을 남겨보세요.

이런 글은 어때요?