시스템 아키텍처 설계

시스템 아키텍처란

시스템 아키텍처란 시스템을 구성하는 요소(소프트웨어, 하드웨어, 데이터 등)와 이들 간의 상호작용을 정의하는 고수준의 설계이다.

요소

• 구성 요소 (components)
• 구성 요소 간의 관계
• 인터페이스: 상호작용을 정의하는 규약
• 데이터 흐름

중요성

• 성능 최적화: 자원 사용 효율적으로 관리
• 확장 용이성 (ex. 트위터의 확장성 미고려 이슈로 인한 점검)
• 유지 보수 및 관리 용이성 (모듈화된 구조는 독립적 업데이트 가능)
• 시스템 안정성 및 신뢰성
• 비용 절감

 

꼼꼼한 아키텍처 설계는 매우 매우 매우 중요하다!

여담이지만 이전에 진행했던 프로젝트에서 백엔드 팀원들이 각각 다른 기술을 사용했고(Spring, Nest.js) 독립적으로 배포 되었다. 그러나 이는 적절하지 않은 선택이었다.. 학기 중에 빠르게 완성되어야 하는 작은 프로젝트였기 때문에 굳이 그렇게 나눌 필요가 없었다. 이후 고려 해야 할 것들이 더 많이 생겼고, 소통이 어려워 생각보다 많이 꼬이기 시작했다.

프로젝트 성격과 환경에 따른 충분한 고민이 필요한 것 같다.

아키텍처 패턴

모놀리식 아키텍처

• 하나의 코드베이스에서 관리
• 모듈 간 의존성이 매우 높음
• 변경 사항 하나로 인해 전체를 봐야 할 가능성이 있음

장점	단점
기술 스택 일관성	유지 보수 어려움
단순한 개발, 배포	확장성 제한 (시스템 전체 확장 필요)
통합 테스트 용이	전체 배포 리스크

 

클라이언트-서버 아키텍처

• 요청하는 클라이언트와 응답하는 서버의 통신
• 3-tier (presentation, application, data)
• monolithic의 하위에 있다고 볼 수 있음

장점	단점
중앙 집중화	서버 부하
유지보수 용이성: 클라이언트 변경 없이 서버에서만 업데이트	네트워크 의존성: 통신이 가능해야 함
확장성: 서버의 성능 향상, 서버의 수 증가 등	비용: 서버 유지보수 비용 등
안정성 및 신뢰성	복잡성

 

마이크로서비스 아키텍처

• 여러 개의 작은 독립적인 서비스들로 쪼개어 개발
• 독립적 배포, 운영 가능
• RESTful API, 메시지 브로커, gRPC 등으로 서로 통신

💡서비스는 어떻게 나뉘어지는가?  회사마다 다르다. db, 비즈니스 로직 등등도 다 다르게 가져갈 수 있다.

 

장점	단점
확장성	복잡한 관리
유지보수 용이성	분산된 데이터 관리
개발 속도 향상: 팀 별 관리, 맡은 서비스에 집중	배포 복잡성: 독립적으로 배포하므로 복잡해진다

 

서버리스 아키텍처

 

• 개발자가 서버 관리할 필요가 없는 클라우드 컴퓨팅 모델
• 트리거되는 비즈니스 로직만 작성하면 됨
• AWS Lambda, Google Cloud Functions 등
• 이벤트 기반 어플리케이션(챗봇 등), 마이크로서비스 아키텍처의 일부, 스케일 아웃이 중요한 작업

💡FaaS : Function as a Service

- 개발자는 함수만 작성하면 됨

- 클라우드 환경에서 함수가 실행되며 작동함

 

장점	단점
자원을 효율적으로 사용 (함수 실행 시에만 자원 사용)	실행 시간 제한: 주기가 있음. 머신러닝 학습 등에는 적절하지 않음
자동 확장	상태 관리 어려움: 함수 실행이 끝나면 사라짐
쉬운 관리	디버깅 및 모니터링 어려움
빠른 배포

 

결합도와 응집도

=> 결합도는 낮게, 응집도는 높게 설계하자

 

결합도

• 모듈 간 의존성의 정도
• 낮을 수록 모듈 간 독립성이 좋음 → 유지보수, 확장성 +

응집도

 

• 모듈 내 구성요소들이 밀접하게 관련되어 있는 정도
• 높을수록 모듈은 하나의 기능만 수행함 → 유지보수, 재사용성 +

확장성과 유연성

=> 확장성과 유연성을 고려해 설계하자

 

확장성

 

• 시스템이 트래픽에 대응할 수 있는 능력
• 방법: 모듈화, 분산 처리 등으로 해결

유연성

• 시스템이 변화화는 요구 사항에 적응할 수 있는 능력
• 기능과 구현의 분리
• 방법: 플러그인 사용해서 모듈 쉽게 추가, 교체하기