본 내용은 박지현 교수님의 Software Engineering 강의를 기반으로 개인적인 공부를 더한 글입니다.

---

우리는 소프트웨어를 개발하기 전, 전체적인 시스템의 구조를 결정해야합니다. 큰 시스템을 여러 sub-system으로 자르고 각각의 관계를 identify하게 되는데요. 이러한 과정이 Architectural Design입니다.

이미 다양한 design 패턴들이 나와있기 때문에 우리는 적절한 패턴을 찾아서 적용하면 됩니다. 오늘은 5가지의 Architectural pattern을 살펴보고 각각의 장단점을 알아보도록 합시다.

1. Layered architecture
2. Repository architecture
3. Client-Server architecture
4. Pipe and filter architecture
5. Model-View-Controller(MVC) architecture

1. Layered architecture

Layered architecture는 위와 같은 구성으로 이루어져 있는데요. 각각의 layer는 서비스가 모여서 형성됩니다. 각 층이 interface로 연결되어있기 때문에 한 층이 변경되더라도, 모든 층에 영향을 끼치는 것이 아니라 인접한 층만 변경해주면 됩니다.

• 장점으로는 유지보수가 편리합니다. 위에서 말씀드렸다시피 인터페이스가 변경되었을 때, 영향을 주는 범위가 한정되므로 대처가 쉽습니다.
• 단점은 실무에서 layer 간에 분리가 명료하게 일어나지 않는다는 것입니다. 따라서 위의 장점을 온전히 누리기 어렵습니다.
  그리고 계층화가 되어있다보니 성능에 문제가 있을 수 있습니다.

2. Repository architecture

sub-system들은 데이터를 주고받게되는데요. 많은 양의 데이터가 오랫동안 공유되어야할 때에는 이 패턴을 사용합니다. 데이터를 한 곳에 저장한 뒤, 공유하는 방식으로 이루어져있습니다.

위는 이클립스와 같은 IDE의 구조를 예시로 든 것입니다. 처음 project를 만들 때 저장소를 지정하면 그 곳에 모든 정보를 저장하고 다른 모듈들이 그곳에 접근하여 데이터를 주고받는 형식입니다.

• 장점은 요소 간 independent하다는 것입니다. 요소는 저장소와 통신할 뿐 다른 요소와의 직접적인 커뮤니케이션이 없기 때문에 한 요소가 바뀌더라도 다른 요소에 미치는 영향이 적습니다.
  게다가 한 곳에 데이터를 저장하기 때문에 consistency나 가장 최신의 값을 항상 유지할 수 있습니다.

• 단점은 single point of failure입니다. 따라서 저장소에 문제가 생기면 전체 시스템에 영향을 줄 수 있습니다. 이를 해결하기 위해 저장소를 분산하거나 백업하는 방법이 있을 수 있는데요. 이러한 방법을 사용한다면 장점인 consistency나 최신값 update를 누리기 어려울 것입니다.
  또한 모든 커뮤니케이션을 저장소를 통해 하다보니 몇몇 경우에 있어서 비효율적일 수 있습니다.

3. Client-Server architecture

이 방식은 저장소와 처리하는 곳이 같은 pc에서 일어나는 Repository architecture와 달리, 저장소와 처리하는 곳이 다릅니다. 따라서 데이터를 공유하지만 물리적으로 떨어진 곳에서 저장소에 접근해야할 경우, distributed system이 많이 사용하는 패턴입니다.

위의 예제처럼 네트워크를 통하여 client는 data를 요청하고 server는 요청 서비스를 제공해줍니다.

• 장점은 서버가 분산되어있기 때문에 네트워크를 통하여 어디서든 접근할 수 있다는 것입니다.

• 단점으로는 Repository architecture와 비슷하게 single point of failure가 발생할 수 있다는 것입니다.
  또 네트워크의 상황에 따라서 성능이 변하기 때문에 일관적인 성능을 기대하기 어렵습니다.

4. Pipe and filter architecture

다음은 Pipe and filter architecture입니다. 이 패턴은 이름처럼 filter가 중간중간 있어서 data를 처리하는 과정이 여러번 일어나게 됩니다. 순차적이고 transaction이 있는 data processing 앱에서 많이 사용합니다. 예를 들면, 항공기 예약이나 은행 계좌관리 시스템이 있을 수 있겠네요.

위는 payment에 관련된 예제입니다. 이처럼 input에 대하여 관련 output을 produce하고, 이것은 또 다른 stage의 input으로 들어가는 sequential 구조를 지닙니다. 하지만 중간에 보이는 것처럼 병렬적으로 처리할 수도 있습니다.

• 장점은 다양한 비즈니스 처리에 사용될 수 있다는 것입니다.
  또 순차적이거나 concurrent한 시스템을 모두 구현할 수 있습니다.

• 단점으로는 stage 간 output - input이 연결되어있기 때문에, 미리 data format이 정해져있어야합니다.
  그리고 이러한 format을 맞추는 과정에서 시스템 overhead가 증가할 수 있습니다.

5. Model-View-Controller(MVC) architecture

마지막으로 MVC 패턴입니다. 이것은 시스템 데이터로부터 보이는 부분과 인터렉션 부분을 분리시킨 것인데요. 이름에서 보이는 것처럼 3가지의 logical component로 구성되어있습니다.

• Model : System data과 이와 관련된 operation을 관리합니다.
• View : 데이터가 user에게 presentation되는 방식을 정의하고 관리합니다.
• Controller : 마우스 클릭이나, 키보드 입력과 같은 interation을 관리하고, 이를 뷰나 모델에 전달합니다.

이 패턴은 다양한 방법으로 view를 처리할 수 있을 때 많이 사용합니다. 위는 web application에 관한 예제입니다. 이처럼 3요소가 서로 분리되어 처리됨을 볼 수 있습니다.

• 장점은 같은 data를 다양한 방식으로 보여줄 수 있다는 것입니다. 만약 view를 web browser가 아닌 mobile browser로 변경하고 싶다면, view를 mobile에 맞게 변경하면 그만이기 때문에 손쉬운 변경이 가능합니다.

• 단점으로는 각각의 부분을 분리시키기 위해서 추가적인 코드가 들어갈 수 있고, 코드가 복잡해지는 경우가 있을 수 있습니다.

---

이렇게 5가지의 Architectural pattern을 알아보았습니다.
오늘 알아본 5가지의 패턴 외에도 많은 Architectural pattern이 존재합니다.
이렇게 많은 패턴 중에서 각 패턴이 어떠한 장단점이 있는지 파악하고, 내가 만들 시스템에는 어떤 패턴이 적합할지 고민하는 과정이 중요할 것 같습니다.