5-7. 소리치는 아키텍처

건물의 청사진을 살펴보고 있다고 상상해 보자.

이 문서는 아키텍트가 작성했고 건물에 대한 일련의 계획을 보여주고 있다.이 계획서는 무슨 이야기를 해 주는가?

그 계획서가 한 가족이 거주할 주택을 그리고 있다면, 정문, 거실로 연결되는 현관, 그리고 식당 역시 볼 수 있을 것이다.

식당 가까이에 주방이 있을 것이고, 아마 주방 근처에는 간이 식탁이 있고, 바로 붙어서 가족 방이 있을 가능성이 높다.

이러한 계획서를 본다면 한 가족이 사는 주택을 보고 있다는 사실에 의심의 여지가 없을 것이다. 다시 말해, 이 아키텍처는 “집이야”라고 소리칠 것이다.

 

이제 도서관의 아키텍처를 보고 있다고 가정해 보자.

커다란 정문, 체크인과 체크아웃을 담당할 사서를 위한 공간, 독서 공간, 작은 회의실, 도서관의 장서를 모두 보관할 정도의 책장을 배치한 진열실이 차례로 나타날 것이다.

이 아키텍처는 “도서관이야”라고 소리칠 것이다.

 

자, 여러분의 애플리케이션 아키텍처는 뭐라고 소리치는가?

상위 수준의 디렉터리 구조, 최상위 패키지에 담긴 소스 파일을 볼 때, 이 아키텍처는 “헬스 케어 시스템이야”또는 “재고 관리 시스템이야” 라고 소리치는가? 아니면 “레일스야”, “스프링”/”하이버네이트야”, 아니면 “ASP야”라고 소리치는가?

 

아키텍처의 테마

이바 야콥슨이 쓴 책<Object Oriented Software Engineering>

주택이나 도서관의 계획서가 해당 건축물의 유스케이스에 대해 소리치는 것처럼, 소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 한다.

 

아키텍처는 프레임워크에 대한 것이 아니다.

아키텍처는 프레임워크로 제공받아서는 절대 안된다. 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야 할 대상이 아니다. 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없다.

 

아키텍처의 목적

좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다.

주택에 대한 계획서를 다시 한번 생각해 보자. 아키텍트가 주목하는 첫 번째 관심사는 주택이 거주하기에 적합한 공간임을 확실히 하는 것이지, 벽돌로 지어지는지를 확인하는 것이 아니다. 실제로 아키텍트는 외장재를 소유주가 결정할 수 있도록 애쓰지만, 이 역시도 계획서가 유스케이스를 확실히 충족시킨 이후다.

 

좋은 소프트웨어 아키텍처는 프레임워크, 데이터베이스, 웹 서버, 그리고 여타 개발 환경 문제나 도구에 대해서는 결정을 미룰 수 있도록 만든다. 프레임워크는 열어 둬야 할 선택사항이다.

좋은 아키텍처는 프로젝트의 훨씬 후반까지 레일스, 스프링, 하이버네이트, 톰캣, MYSQL에 대한 결정을 하지 않아도 되게 해준다. 뿐만 아니라 이러한 결정을 쉽게 번복할 수 있도록 한다.

좋은 아키텍처는 유스케이스에 중점을 두며, 지엽적인 관심사에 대한 결합은 분리시킨다.

 

하지만 웹은?

웹은 아키텍처일까? 시스템이 웹을 통해 전달된다는 사실이 시스템의 아키텍처에 영향을 주는가?

당연히 아니다! 웹은 전달 메커니즘(입출력 장치)이며, 애플리케이션 아키텍처에서도 그와 같이 다뤄야 한다.

애플리케이션이 웹을 통해 전달된다는 사실은 세부사항이며, 시스템 구조를 지배해서는 안 된다.

 

실제 애플리케이션을 웹으로 전달할지 여부는 미루어야 할 결정사항 중 하나다. 시스템 아키텍처는 시스템이 어떻게 전달될지에 대해 가능하다면 아무것도 몰라야 한다. 과도한 문제를 일으키거나 근본적인 아키텍처를 뜯어고치지 않더라도 시스템을 콘솔 앱, 웹 앱, 리치 클라이언트 앱, 심지어 웹서비스 앱으로도 전달할 수 있어야 한다.

 

프레임워크는 도구일 뿐, 삶의 방식은 아니다

프레임워크는 매우 강력하고 상당히 유용할 수 있다.

프레임워크 제작자는 자신이 만든 프레임워크를 매우 깊이 신뢰하곤 한다.

이들이 작성하는 예제들은 그 프레임워크를 사용하는 방식에 대해 진실된 신자의 관점에서 이야기하곤 한다.

프레임워크 사용예제를 작성하는 다른 제작자들 역시 진실된 믿음을 가진 신봉자인 경향이 있다.

이들은 “프레임워크가 모든 것을 하게 하자”라는 태도를 취한다.

 

이는 우리가 취하고 싶은 태도가 아니다.

 

눈이 아플정도로 면밀하게 프레임워크를 살펴보자. 그리고 비판적으로 보자. 그래, 프레임워크는 도움이 되겠지만, 비용은 얼마나 드는가? 프레임워크를 어떻게 사용할지, 그리고 프레임워크를 사용하지 않으려면 어떻게 해야할지를 스스로에게 물어보라. 어떻게 하면 아키텍처를 유스케이스에 중점을 준 채 그대로 보존할 수 있을지를 생각하라. 프레임워크가 아키텍처의 중심을 차지하는 일을 막을 수 있는 전략을 개발하라.

 

테스트하기 쉬운 아키텍처

아키텍처가 유스케이스를 최우선으로 한다면, 그리고 프레임워크와는 적당한 거리를 둔다면, 프레임워크를 전혀 준비하지 않더라도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.

테스트를 돌리는 데 웹 서버가 반드시 필요한 상황이 되어서는 안 된다. 데이터베이스가 반드시 연결되어 있어야만 테스트를 돌릴 수 있어서도 안 된다. 엔티티 객체는 반드시 오래된 방식의 간단한 객체여야 하며, 프레임워크나 데이터베이스, 또는 여타 복잡한 것들에 의존해서는 안 된다.

 

유스케이스 객체가 엔티티 객체를 조작해야 한다.

최종적으로, 프레임워크로 인한 어려움을 겪지 않고도 반드시 이 모두를 있는 그대로 테스트할 수 있어야 한다.

 

결론

아키텍처는 시스템을 이야기해야 하며, 시스템에 적용한 프레임워크에 대해 이야기해서는 안 된다. 당신이 헬스 케어 시스템을 구축하고 있다면, 새로 들어온 프로그래머가 처음 소스 저장소를 보고, “오, 헬스 케어 시스템이군” 이어야만 한다.

새로 합류한 프로그래머는 시스템이 어떻게 전달될지 알지 못한 상태에서도 시스템의 모든 유스케이스를 이해할 수 있어야 한다.

 

언젠가 이들은 당신을 찾아와서 이렇게 말할 것이다.

“모델처럼 보이는 것들을 확인했습니다. 그런데 뷰와 컨트롤러는 어디에 있죠?”

그러면 당신은 응당 다음과 같이 답해야 한다.

“아, 그것은 세부사항이므로 당장은 고려할 필요가 없습니다. 나중에 결정할 겁니다.”