SW Architecture

1. SW Architecture란?

소프트웨어 시스템의 구조와 설계를 결정하는 것을 의미한다.

• 시스템의 기능, 성능, 안정성, 보안성 등의 비기능적인 요구사항을 충족시키기 위한 구조와 설계를 수립한다.
• 소프트웨어 시스템의 구성 요소, 구성 요소 간의 관계, 인터페이스, 데이터 흐름 등을 포함하는 시스템의 전반적인 구조를 설계하는데 이를 위해 다양한 모델링 기법과 설계 원칙을 사용한다.
• 소프트웨어 시스템의 복잡도를 줄이고, 시스템의 확장성, 유지 보수성, 재사용성, 이식성 등을 높이기 위한 목적으로 수행한다.
• 소프트웨어 개발 전 단계에서 수립되며, 이를 통해 소프트웨어 개발자들은 전체 시스템의 구조를 파악하고, 개별적인 모듈을 개발할 수 있다. 또한, SW Architecture는 소프트웨어 개발자들 간의 협업과 의사 소통을 원활하게 할 수 있도록 도와준다.
• 소프트웨어 시스템의 성능, 안정성, 보안성 등의 비기능적인 요구사항을 충족시키기 위해 중요한 역할을 수행하며, 이를 통해 소프트웨어 시스템의 품질을 향상시킬 수 있다.

2. SW Architecture의 필요성

2-1. 구조가 잡히지 않은 Application의 특징

• 하나의 요구 사항이라도 적용하는데 시간이 오래 걸린다.
• 변경이 느리거나 못할 수도 있다.
• 버그에 대한 대응이 느리다.
• 확장성이 좋지 않다.
• 개발자가 시간이 지남에 따라 시스템을 이해하고 수정하기가 어려워 유지 관리 비용이 증가하고 변화하는 요구 사항에 적응하는 능력이 저하될 수 있다.

2-2. 구조가 잘 잡힌 Application의 특징

• 요구사항에 빠르게 적용한다.
• 오류에 대한 대응이 빠르다.
• 변경에 빠르다.
• 확장성이 좋다.
• 좋은 아키텍처 구조를 가지고 있다.
• 더 쉽게 테스트, 배포 및 유지 관리할 수 있는 애플리케이션을 구축할 수 있다.

3. SW Architecture의 종류

SW Architecture는 소프트웨어 시스템의 상위 수준 구조를 설계하고 해당 구성 요소, 상호 작용 및 관계를 정의하는 프로세스이며 여러 유형의 SW Architecture가 있으며 각각 고유한 특성, 장점 및 단점이 있다.

3-1. Monolithic architecture

• 모놀리틱 아키텍처는 응용 프로그램의 모든 구성 요소가 서로 강하게 통합되고 종속되어있는 소프트웨어 아키텍처 패턴이다. 이 아키텍처에서는 전체 응용 프로그램이 단일, 자체 포함 단위로 구축되며 단일 아티팩트로 배포된다.
• 이 접근 방식은 응용 프로그램을 개발하고 배포하기가 더 쉬울 수 있으며 모든 것이 단일 코드베이스 내에 포함되지만 응용 프로그램을 유지 관리하고 확장하는 것이 더 어려울 수 있으며 응용 프로그램의 일부를 변경하면 다른 부분에 예기치 않은 결과가 발생할 수 있다.
• 최근에는 마이크로서비스 아키텍처를 사용하여 모놀리틱 응용 프로그램을 더 작고 관리하기 쉬운 구성 요소로 분해하는 경향이 있다. 이 접근 방식은 더 큰 유연성과 확장성을 제공할 수 있지만 추가적인 복잡성과 오버헤드가 발생될 수 있다.
• Layered Architecture, Clean Architecture, Hexagonal Architectured등이 해당된다.

3-2.Decentralized architecture

• 분산 아키텍처는 데이터 및 자원의 제어 및 처리를 단일 위치에서 중앙 집중화하는 대신 노드 또는 피어 네트워크에 분산하는 소프트웨어 아키텍처 패턴이다.
• 분산 아키텍처에서 각 노드는 데이터 또는 자원의 자체 복사본을 가지고 있으며, 자체 트랜잭션을 처리하고 검증한다. 이렇게 함으로써 중앙 권위자나 중개인이 필요 없어지며, 시스템이 실패나 공격에 강해진다.
• 분산 아키텍처는 피어 투 피어(P2P) 네트워크, 블록체인 시스템 및 기타 분산 시스템에서 일반적으로 사용된다. 이들은 중앙 집중화된 아키텍처보다 더 투명하고 안전하며 강력하며 더 효율적이고 확장 가능한 시스템 가능성을 제공한다.
• 이들은 모든 노드가 시스템의 상태에 대해 동의하는 것을 보장하기 위한 합의 매커니즘과 데이터가 여러 노드를 통해 분배되고 검증되어야 하기 때문에 느린 성능 가능성과 같은 일부 도전 과제가 발생 할 수 있다.
• Service Oriented Architecture, Event-based Architecture, MicroService Architecture등이 해당된다.

3-3. Client-Server Architecture

• 클라이언트-서버 아키텍처에서 시스템은 서비스를 요청하는 클라이언트와 서비스를 제공하는 서버의 두 부분으로 나뉜다.
• 클라이언트와 서버는 HTTP, TCP/IP 또는 SOAP와 같은 프로토콜을 사용하여 네트워크를 통해 통신한다.
• 서버가 클라이언트 브라우저에 데이터와 서비스를 제공하는 웹 애플리케이션에서 널리 사용된다.

3-4. Microservice Architecture

• 마이크로서비스 아키텍처는 애플리케이션을 작고 독립적이며 느슨하게 결합된 서비스 모음으로 구성하는 최신 아키텍처 스타일이다.
• 각 마이크로서비스는 단일 비즈니스 기능을 수행하고 API를 사용하여 다른 마이크로서비스와 통신한다.
• 확장성, 탄력성, 유연성이 뛰어나지만 관리가 복잡하고 높은 수준의 자동화가 필요하다.
  
  

3-5. Event-driven architecture

• 이벤트 기반 아키텍처에서 시스템 구성 요소는 이벤트를 송수신하여 서로 통신한다.
• 이벤트는 버튼 클릭 또는 센서 판독과 같은 어떤 일이 발생했다는 신호다.
• 이 아키텍처는 IoT 장치 및 금융 시스템과 같이 실시간 처리가 필요한 애플리케이션에 유용하게 쓰인다.
  
  

3-6. Service Oriented Architecture (SOA)

• 서비스 지향 아키텍처(SOA)는 응용 프로그램 간에 공유할 수 있는 느슨하게 결합되고 재사용 가능한 서비스의 개발에 중점을 둔 아키텍처 유형이다.
• 이 아키텍처에서 각 서비스는 잘 정의된 비즈니스 기능을 제공하고 SOAP 또는 REST와 같은 표준 프로토콜을 사용하여 다른 서비스와 통신한다.
• 개발 및 관리가 복잡할 수 있지만 유연성, 확장성 및 재사용성을 제공한다.
  
  

3-7. Layered architecture

• 계층화된 아키텍처는 시스템을 각각 특정 기능 세트를 담당하는 논리적 계층으로 나누는 고전적인 아키텍처 스타일이다.
• 각 계층은 상위 계층에 서비스를 제공하고 하위 계층에서 제공하는 서비스를 사용한다.
• 이해하고 유지 관리하기 쉽지만 성능 문제와 레이어 간의 긴밀한 결합으로 이어질 수 있다.

4. SW Architecture 선택시 고려 사항

• 요구 사항 이해 : 기능적 요구 사항, 비기능적 요구 사항 및 제약 사항을 포함하는 프로젝트 요구 사항을 기반으로해야한다.
  
  
• 트레이드오프 평가 : 프로젝트에 가장 적합한 아키텍처를 결정하기 위해 SW Architecture 마다 가진 장단점을 고려하여 다른 아키텍처 간의 트레이드오프를 평가해야한다.
  
  
• 확장성과 성능 고려 : 예상 작업 부하를 처리하고 필요에 따라 확장할 수 있도록 설계되어야 하기 때문에 소프트웨어 아키텍처 선택 시 성능 요구 사항를 고려해야 한다.
  
  
• 유지 보수 및 유연성 고려 : 프로젝트가 진행됨에 따라 유지 관리 및 수정이 쉬워야 한다. 또한 요구 사항의 변화를 수용할 수 있을 만큼 유연해야 한다.
  
  
• 개발팀 전문성 고려 : 개발팀의 전문성과 경험을 바탕으로 팀이 편안하고 효과적으로 구현할 수 있는 아키텍처를 선택하는 것이 중요하다.
  
  
• 프로젝트 일정 및 예산에 대한 영향 평가 : 각 아키텍처 옵션을 구현하는 데 필요한 비용과 시간을 고려해야한다.

5. 좋은 Architecture를 설계하기 위해서.

좋은 SW Architecture를 설계하기 위해서는 시스템의 요구 사항, 제약 조건 및 목표를 고려하는 구조화되고 조직화된 접근 방식이 필요하다.

• 시스템의 요구 사항과 제약 사항 이해 : 시스템의 기능적 및 비기능적 요구 사항과 설계 및 구현에 영향을 줄 수 있는 제약 사항을 이해해야한다.
  
  
• 이해 관계자 식별 : 사용자, 고객, 개발자 및 프로젝트 관리자와 같이 시스템의 영향을 받을 모든 이해 관계자를 식별해야한다.
  
  
• 시스템 구성 요소 정의 : 사용 사례, 순서도 및 UML 다이어그램과 같은 다양한 도구와 기술을 사용하여 시스템 구성 요소와 상호 작용을 정의해야한다.
  
  
• 아키텍처 스타일 정의 : 아키텍처 스타일은 클라이언트-서버, 이벤트 기반 또는 계층화와 같은 시스템 설계에 대한 전반적인 접근 방식을 정의해야 한다. 스타일은 시스템의 요구 사항과 제약 조건에 따라 선택해야 한다.
  
  
• 적절한 패턴 및 사례 선택 : SOLID 원칙, 디자인 패턴, 테스트 및 배포를 위한 모범 사례와 같은 시스템 설계에 적합한 패턴 및 사례를 선택한다.
  
  
• 성능 및 확장성 보장 : 시스템은 허용 가능한 수준의 성능을 유지하면서 시간이 지남에 따라 증가하는 데이터 및 트래픽 양을 처리할 수 있도록 설계되어야 한다.
• 보안 및 개인 정보 보호 : 시스템은 무단 액세스 또는 침해로부터 민감한 데이터를 안전하게 보호하도록 설계되어야 한다.
  
  
• 아키텍처 문서화 : 시스템을 잘 이해하고 시간이 지남에 따라 유지 및 관리를 하기 위해 아키텍처는 개발자가 따라야 할 명확한 다이어그램, 설명 및 지침과 함께 잘 문서화되어야 한다.

6. 좋은 SW Architecture란?

• 시스템의 요구사항 및 제약사항 이해 : 시스템의 기능적 및 비기능적 요구 사항은 물론 설계 및 구현에 영향을 미칠 수 있는 제약 조건을 명확하게 이해하여 설계해야 한다.
  
  
• 시스템 모듈화 : 느슨하게 결합되고 쉽게 교체할 수 있는 잘 정의된 구성 요소와 인터페이스가 있는 모듈식이어야 한다. 이를 통해 시스템은 시간이 지남에 따라 변화하는 요구 사항에 맞게 진화하고 적응할 수 있기 때문이다.
  
  
• 디자인 패턴 및 모범 사례 사용 : 시스템을 유지 관리, 테스트 및 확장을 위해 SOLID 원칙, 종속성 주입 및 관심사 분리와 같은 잘 정립된 디자인 패턴 및 모범 사례를 사용하여 설계해야 한다.
  
  
• 성능 및 확장성 고려 : 시간이 지남에 따라 증가하는 데이터 및 트래픽 양을 처리할 수 있는 기능과 함께 성능 및 확장성을 염두에 두고 설계되어야 한다.
  
  
• 보안 및 개인정보 보호 : 민감한 데이터를 보호하고 무단 액세스를 방지하기 위한 적절한 조치와 함께 보안 및 개인정보 보호를 염두에 두고 설계되어야 한다.
  
  
• 효과적인 문서화 및 커뮤니케이션 : 모든 사람이 시스템의 디자인을 이해하고 시간이 지남에 따라 시스템을 개발하고 유지 관리하기 위해 문서화가 잘 되어야 하며 개발자, 프로젝트 관리자 및 사용자를 포함한 모든 이해 관계자에게 효과적으로 전달되어야 한다.

7. 프로젝트 진행 중 Architecture 변경.

프로젝트 진행 중 아키텍처가 변경되는 경우, 변경에 대한 합당한 이유나 근거가 필요하다.
아키텍처 변경에 대한 합당한 근거가 있는 경우에도 프로젝트 일정, 예산 및 기타 요인에 미치는 영향을 신중하게 고려해야한다.

7-1. 변경 요인.

• 프로젝트 요구 사항 변경 : 프로젝트 요구 사항이 크게 변경되면 새로운 요구 사항을 수용하기 위해 아키텍처를 조정해야 할 수 있다.
  
  
• 성능 문제 : 아키텍처가 예상대로 수행되지 않으면 성능을 개선하기 위해 변경이 필요할 수 있다.
  
  
• 기술 변경 : 새로운 기술이 나오거나 기존 기술이 사용하지 않을 만큼 구식이 된 경우, 아키텍처를 업데이트하여 새로운 기술을 활용하거나 구식 기술을 대체해야 할 수 있다.
  
  
• 보안 문제 : 현재 아키텍처에 보안 문제가 있는 경우, 보안을 개선하기 위해 변경이 필요할 수 있다.
  
  
• 비용 고려 사항 : 현재 아키텍처를 유지 보수하거나 운영하는 데 너무 많은 비용이 드는 경우, 비용을 줄이기 위해 변경이 필요할 수 있다.

7-2. 변경 절차.

개발자는 논리적인 절차를 통해 소프트웨어 아키텍처에 대한 모든 변경 사항이 합리적이고 신중하게 계획되어 전체 시스템이 개선되도록 할 수 있도록 진행 해야한다. 또한 변경 사항을 문서화하여 시간이 지나도 시스템을 유지 관리 및 확장할 수 있도록 보장 해야한다.

• 변경 이유 확인 : 요구 사항의 변경, 시스템 성능 개선 또는 보안 문제 해결에 대한 욕구 때문인지 변경 이유를 잘 이해하고 명확하게 문서화해야 한다.
  
  
• 변경의 영향 평가 : 변경이 시스템에 미치는 기능, 성능, 보안 및 유지 관리 가능성에 대한 영향 평가를 신중하게 고려하고 문서화해야 한다.
  
  
• 변경 계획 수립 : 변경에 대한 명확한 타임라인과 변경을 구현하고 시스템 성능이나 기능에 부정적인 영향을 미치지 않는지 테스트하는 단계가 포함되어야 한다.
  
  
• 변경 사항 문서화 : 개발자가 따라야 할 업데이트된 다이어그램, 설명 및 지침이 포함된 변경 사항을 문서화 한다. 이 문서는 명확하고 간결해야 하며 모든 이해 관계자가 사용할 수 있어야 한다.