Note ≣

퍼사드를 싱글톤 추상 팩토리(singleton abstract factory)라고도 합니다.

Note ≣ 체험담

어두웠던 J2EE 초창기, 저는 어느 대형 뱅킹 애플리케이션을 만드는 대리급 개발자로 일했는데 우리 팀 사람들은 거의 모든 J2EE 디자인 패턴을 구현했습니다. EJB는 모조리 퍼사드로 감쌌고 퍼사드를 불러 쓰는 서비스 EJB는 다른 퍼사드로 다시 감싸는 식이었습니다. API가 뭉개지지 않도록 퍼사드 앞에 인터페이스를 두었습니다. J2EE 시절엔 로컬(local) 인터페이스, 원격(remote) 인터페이스를 각각 한 세트씩 작성해야 해서 EJB 하나를 만들려면 결과적으로 인터페이스 4개와 클래스 2개가 필요했습니다. 스파게티 코드는 아니었지만 레이어가 소고기 라자냐보다 더 뚱뚱해지기 시작했습니다. 우리 팀원들끼리 작업할 때엔 별 탈 없었습니다. 하지만 다른 팀 사람들이 우리 핵심 서비스를 갖다 쓰면서 시스템 성능은 물론이고 변경 요청을 감당할 능력이 바닥나기 시작했습니다.

결국, 큰 비용을 감수하고 한 서버 업체에 연락해서 유명한 컨설턴트를 모셔와 시스템 분석을 의뢰했습니다. 몇 차례 회의를 거쳐 우리 코드베이스를 가만히 들여다보던 컨설턴트는 리팩터링이 필요하다고 결론 내립니다. 그의 말에 따라 우리는 퍼사드와 여기에 물려있던 인터페이스를 삭제했습니다. 그렇게 하니 관리할 코드가 줄고 성능이 좋아져서 다들 만족했습니다. 이 사건을 계기로 큰 교훈을 얻었습니다. ‘제아무리 간단한 패턴이라도 꼭 필요할 때에 조금만 사용하고 자신의 패턴 지식을 과시하지 말지어다!’