[Level 2] Layered Architecture에 대한 개인적인 고찰

자바 콘솔 기반 프로그램을 구현하던 레벨1에서 웹 기반 프로그램을 구현하는 레벨2로 넘어오면서 Layered Architecture를 계속 접하게 되었다. 인터넷을 조금만 찾아봐도 Layered Architecture의 각 계층들이 어떤 책임을 지는지에 대해 설명하는 글들을 쉽게 접할 수 있다. 그러나 미션을 진행하면서 궁금했던 것은 Layered Architecture로 설계된 프로그램에서 각 계층들이 어떻게 정보를 주고 받게 할 것인가였다. 

 

레벨1에서 MVC 구조를 사용하며 VIew와 Model이 상호 독립적으로 최대한 의존하지 않도록 해야했고 그 완충 작용을 해주는 역할이 Controller였다. 그런데 Layered Architecture로 설계된 웹 프로젝트에서 각 계층들은 왜 분리해야 하는지, 어떻게 분리해야 하는지에 대해서 같은 이유로 답하기엔 뭔가 걸리는 부분들이 있었다. 이번 포스팅을 통해 해당 부분들에 대한 스스로의 생각을 정리해보고자 한다.

 

 

[Layered Architecture를 사용하는 이유]

 

쉽게 알 수 있는 첫번째 이유는 관심사의 분리를 통한 유지보수성과 확장성의 확보이다.

• 여기서 관심사의 분리라는 말이 조금 추상적으로 다가왔다. 그래서 관심사의 분리라는 용어를 계층 간 역할과 책임 분리라는 용어로 치환해서 생각하기로 결정했다.
• 그러면 Layered Architecture에서 각 계층에게 기대하는 책임과 역할은 무엇일까? 여러 레퍼런스를 찾아보며 간단하게 정리해본 내용은 아래와 같다.

• Layered Architecture에서 각 계층의 책임 (4-tier)
  • Presentation
    • client 요청에 따라 어떤 서비스 로직이 수행되어야 하는지 Mapping 한다. 다만 자세한 서비스 로직 구현 방식에 대해서는 알지 못한다.
    • 단지 요청에 따른 서비스 로직을 mapping 해 실행되도록 하고 그 결과를 다시 반환한다.
    • View와 Controller가 대표적인 구성 요소이다.
  • Business
    • 어플리케이션의 비즈니스 로직을 수행한다.
    • Presentation Layer 로부터 요청을 받아서 Persistence Layer에게서 데이터를 가져와 비즈니스 로직을 수행한다.
    • 비즈니스 로직 수행 결과를 다시 Presentation Layer에 반환하거나 Persistence Layer에게 넘겨서 객체 영속성을 유지한다.
      • 객체의 영속성이란?
        • 객체의 상태를 영구적으로 저장하고 유지하기 위한 개념이다.
  • Persistence
    • 어플리케이션 정보의 영속성을 보장하기 위한 출처에 데이터를 저장하거나 가져올 수 있다.
    • 데이터를 저장하거나 조회하는 출처는 관계형 DB가 될 수도 있고 파일 시스템, NoSQL 등이 될 수도 있다.
  • Database
    • 말 그대로 데이터베이스가 존재하는 계층이다. (일반적으로 데이터베이스 그 자체를 말한다.) 

 

이처럼 각 계층별로 수행하는 책임과 역할이 다르다. 즉 관심사를 분리했다고 얘기할 수 있다. 이에 대한 예시로 콘솔로 진행하던 자동차 경주 게임 프로그램을 웹으로도 확장해야 하는 경우를 생각해보자.

• 이 경우 기존 콘솔로만 데이터를 제공하던 Presentation 계층의 기능에 웹으로도 데이터를 제공하는 기능을 추가해야 한다. 이 때 Business 계층의 책임과 역할은 동일하기에 별다른 수정사항이 발생하지 않는다. 결과적으로 서로 다른 Presentation Layer의 요청들이라도 동일한 Business Layer가 이를 수행할 수 있다.
• 즉 관심사를 분리했기 때문에 다른 계층에 대한 변경의 파급효과가 최소화된 것이다. 이를 통해 우리는 쉽게 유지보수를 진행할 수 있게되어 유지보수성이 향상된다고 얘기할 수 있다.
• 또한 각 계층의 구성요소들이 수행해야 하는 책임과 역할이 명확하기 때문에 이를 수행할 수 있다면 다른 구성요소로 쉽게 변경할 수 있어 확장성이 확보된다고 얘기할 수 있다.

 

 

두번째는 변경에 대한 취약성을 보호하기 위함이다.

• 사실 이 부분이 첫번째 이유에서 확장성을 확보하는 것과 어떤 차이가 있는지 명확하게 구분하기 힘들었다.
• 시간을 들여서 고민해본 후 내린 결론은 이 장점이 위에서 언급한 확장성과 굉장히 밀접하게 연관되어 있는 개념이라는 것이다. 즉 Layered Architecture를 통해 확장성을 확보하면 자연스럽게 같이 변경에 대한 취약성이 내려간다고 얘기할 수 있다.

 

 

 

[마치며]

 

웹 자동차 경주 미션을 진행하는 도중 리뷰어 범블비가 달아주신 리뷰를 얘기하며 마무리해볼까 한다.

 

"요구사항을 가장 잘 충족시키는 가장 심플한 것을 찾으라. ... 복잡한 것이 나쁘고 잘못된 것이기 때문이다."

토비님이 예전에 남겼던 글의 일부입니다. 복잡한 아키텍처를 도입하는 건 그 아키텍처가 아니면 복잡성을 풀어낼 수 없을 때입니다. 먼저 가장 심플하게 풀어낼 방법을 찾고 해결이 안 되면 복잡한 방법을 찾는 습관이 좋은 개발자를 향한 한 걸음이 아닐까 싶네요 😄

 

동의되지 않는 기술과 원칙에 쉽게 굴복하지 말아야 하는데 학습하는 사람의 입장에서 정말 쉽지 않다는 것을 느끼고 있는 요즘이다. 조금 더 주관을 가지고 최대한 간단한 방법으로 문제를 해결하는 습관을 남은 기간동안 연습해봐야겠다.