아키텍처 - 아키텍처의 오해

- 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.)

- 개요

만약 어떤 건물에 대한 설계도를 본다고 해보자. 해당 설계도에 독서 공간, 회의실, 책장을 배치한 많은 진열장이 있다면 정확히는 몰라도 도서관이라고 추측할것이다.

 

어플리케이션을 만들기 위해 패키지 구조를 잡았다고 하자. 좋은 아키텍처라면 어떤 사람이 해당 패키지 구조를 보았을 때 "이 어플리케이션은 헬스 케어 시스템이다" 라고 생각하게 만들어야 한다.

 

만약 패키지구조를 보고나서 드는 생각이 스프링으로 구현했나? ASP인가? 하이버네이트를 사용했나? MySQL인가? 라는 생각이 들도록 만들었다면 제대로된 아키텍처인지 다시 한번 생각해볼 필요가 있다.

---

- 목적

나를 포함한 많은 사람들은 아키텍처에 대해 환상을 갖는다. 아키텍처라는 말을 들으면 프레임워크를 자유자재로 다루고 기술적인 측면에서 트러블슈팅을 막힘없이 하는 신과 같은 존재처럼 보인다.

 

하지만 좋은 아키텍처라면 이런 세부적인 기술보다 유스케이스에 중점을 두어야 한다. 따라서 프레임워크나 도구가 아닌 유스케이스를 만족하는 구조를 설계해야 한다. 유스케이스를 모두 지원하면서 이에 부수적인 스프링, 하이버네이트, 톰캣과 같은 결정을 후반에 할 수 있도록 미루어야 한다.

 

위와 같은 목적을 생각한다면 웹 또한 아키텍처는 아니다. 웹은 오히려 입출력의 하나에 지나지 않으며(그렇다고해서 웹 기술이 하찮거나 쉽다는 얘기가 아니다.), 필요하다면 콘솔이나 웹 앱 으로도 변경할 수 있어야 한다.

---

- 프레임워크

프레임워크는 개발에 많은 영향을 미친다. 하지만 프레임워크가 아키텍처의 중심을 차지해서는 안된다. 언제나 중심은 유스케이스를 지원하는 설계이다.

 

요즘 많이 사용하는 스프링 부트는 업무규칙이 핵심적인 가치임을 강조한다. 스프링 MVC에 비해 상당히 설정이 간편하여 비즈니스 로직에 더 집중할 수 있도록 발전하였다.

---

- 테스트

아키텍처가 유스케이스를 최우선으로 두는데 성공했다면 톰캣을 띄우지 않고도 테스트가 가능해야 한다. 엔티티는 POJO 이면서 데이터베이스에 의존하지 않는다. 또한 프레임워크가 없어도 테스트를 할 수 있어야 한다.

---

- 결론

아키텍처는 프레임워크가 아닌 시스템을 말해야 한다. 어떤 개발자가 어플리케이션 소스를 보았을 때, 해당 시스템의 프레임워크나 뷰, 컨트롤러가 아닌 도메인을 언급하도록 아키넥처를 설계해야 한다.