소프트웨어 아키텍처에 대해 공부한 내용을 정리해보려고 합니다.
실무에서 흔히 사용하던 아키텍처뿐만 아니라 다양한 패턴을 대략적으로 설명하도록 하겠습니다.
아키텍처란?
소프트웨어 개발에서 아키텍처는 시스템을 설계하고 구축하는 방식입니다.
특히 백엔드 개발에서 아키텍처는 서버, 데이터베이스, 서비스 간의 통신 방식 등 다양한 요소를 어떻게 설계하고 상호작용하게 할지를 결정하는 중요한 요소입니다.
대표적인 백엔드 아키텍처 패턴
백엔드 개발에서 자주 언급되는 아키텍처 패턴들을 소개해보겠습니다.
각 패턴은 특정 상황에서 그 장점이 두드러지며, 그에 따른 트레이드오프가 존재합니다.
1. 레이어드 아키텍처 (Layered Architecture)
레이어드 아키텍처는 가장 널리 사용되는 아키텍처 패턴입니다. 시스템을 여러 계층으로 나누어 각 계층이 명확한 역할을 담당하도록 설계하는 방식이죠. 일반적으로 프레젠테이션 레이어, 비즈니스 로직 레이어, 데이터 액세스 레이어로 구성됩니다.
장점
- 구조적으로 코드가 나뉘어 있어 이해하기 쉽습니다.
- 유지보수와 기능 추가가 용이합니다.
- 각 계층이 독립적으로 관리되기 때문에, 코드의 재사용성이 높습니다.
단점
- 계층 간 의존성이 커지면 성능이 저하될 수 있습니다.
- 대규모 시스템에서는 복잡도가 증가할 수 있습니다.
실무 적용
저는 현재 실무에서 주로 레이어드 아키텍처를 사용하고 있습니다.
새로 기능을 추가할 때 특정 레이어만 수정하면 되는 유연함이 있어, 빠르게 변동이 잦은 프로젝트에서 매우 유용합니다.
하지만 대규모 프로젝트에선 성능에 영향을 줄 수도 있어, MSA와 같은 아키텍처를 고려하는 것도 중요합니다.
2. 클린 아키텍처 (Clean Architecture)
클린 아키텍처는 애플리케이션의 핵심 비즈니스 로직과 외부 시스템을 분리하는 데 중점을 둡니다.
이 방식은 시스템이 변화하더라도 내부 로직이 변경되지 않고, 외부의 변화에 유연하게 대처할 수 있도록 설계합니다.
장점
- 비즈니스 로직이 외부 시스템에 의존하지 않아서 유연성이 높습니다.
- 의존성이 적기 때문에 테스트가 용이합니다.
단점
- 설계가 복잡하고, 초기 비용이 크기 때문에 작은 프로젝트에서는 과도할 수 있습니다.
실무 적용
대규모 프로젝트에 활용할 수 있을 것 같습니다 특히 장기적인 유지보수를 고려한다면, 클린 아키텍처의 장점이 돋보일 것 같습니다.
3. 마이크로서비스 아키텍처 (Microservices Architecture)
마이크로서비스 아키텍처는 애플리케이션을 여러 독립적인 서비스로 나누어, 각 서비스가 독립적으로 개발, 배포, 확장될 수 있도록 하는 방식입니다.
서비스 간의 결합도를 낮추고, 각 서비스는 별도의 데이터베이스와 비즈니스 로직을 가집니다.
장점
- 각 서비스가 독립적으로 운영되기 때문에 확장성이 뛰어납니다.
- 장애가 발생해도 전체 시스템에 영향을 미치지 않는 장애 격리성이 우수합니다.
단점
- 서비스 간 통신이 복잡해지고, 운영 비용이 증가할 수 있습니다.
- 데이터 일관성 유지와 배포 복잡성이 문제될 수 있습니다.
실무 적용
개인적으로 마이크로서비스 아키텍처는 대규모 프로젝트에 매우 적합하다고 생각하지만, 동시에 운영과 관리에 대한 부담이 크다고 느껴집니다. 서비스가 분리되면서 각각의 팀이 독립적으로 작업할 수 있다는 점은 확실히 장점이지만, 아직 도입 전이라 배포 복잡성을 해결하는 부분이 걱정됩니다.
4. 이벤트 드리븐 아키텍처 (Event-Driven Architecture)
이벤트 드리븐 아키텍처는 시스템에서 발생하는 이벤트를 기반으로 동작합니다. 각 컴포넌트가 이벤트를 감지하고, 그에 반응하여 작업을 수행하는 방식이죠. 비동기 작업이 중요한 시스템에서 주로 사용됩니다.
장점
- 비동기 처리가 용이하고, 시스템이 확장성이 뛰어납니다.
- 여러 이벤트를 독립적으로 처리할 수 있습니다.
단점
- 이벤트 흐름을 추적하기 어려워서 디버깅이 복잡할 수 있습니다.
- 이벤트 중복이나 순서 처리에서 문제가 발생할 수 있습니다.
실무 적용
이벤트 드리븐 아키텍처는 실시간 데이터 처리가 필요한 시스템에 적합하다고 생각합니다.
아직 제가 직접적으로 사용해보진 않았지만, 나중에 비동기 처리 시스템에서 활용하면 좋을 것 같습니다.
5. 서버리스 아키텍처 (Serverless Architecture)
서버리스 아키텍처는 개발자가 서버를 관리할 필요 없이 클라우드 서비스 제공자가 서버 운영을 대신하는 방식입니다. FaaS(Function as a Service)를 통해 필요할 때만 함수가 실행되며, 리소스가 사용될 때만 비용이 발생합니다.
장점
- 서버 관리 부담이 적고, 비용 효율적입니다.
- 자동 확장이 가능하여 동적인 트래픽을 처리하기 좋습니다.
단점
- 클라우드 제공자에 의존하게 되고, 복잡한 커스터마이징이 어렵습니다.
실무 적용
작은 프로젝트에서 서버리스 아키텍처를 활용한다면 효율적일 것으로 보입니다.
특히 초기 개발과 배포가 간편해, 스타트업이나 신속한 배포가 필요한 프로젝트에서 유용할 것 같습니다.
아키텍처 선택 시 고려 사항
백엔드 아키텍처를 설계할 때, 다음과 같은 요소들을 고려해야 합니다.
확장성 (Scalability)
서비스가 커짐에 따라 얼마나 쉽게 확장할 수 있는지유지보수성 (Maintainability)
새로운 기능 추가 및 버그 수정을 얼마나 효율적으로 할 수 있는지성능 (Performance)
요청에 대한 응답 시간과 처리 속도가 얼마나 빠른지비용 (Cost)
인프라 비용 및 개발 비용이 얼마나 드는지
이 요소들은 프로젝트의 요구사항에 따라 각기 다른 아키텍처 스타일을 선택할 때 중요한 지표가 됩니다.
마무리
이렇게 다양한 소프트웨어 아키텍처 패턴을 간단히 정리해봤습니다.
프로젝트의 성격에 따라 각 아키텍처를 적절하게 선택하는 것이 중요합니다. 이 글을 시작으로 다양한 아키텍처를 공부하고 실무에 적용해보려고 합니다.
다음 포스팅에서는 레이어드 아키텍처에 대해 더 깊이 다뤄볼 예정입니다.
감사합니다.
관련글 > 레이어드 아키텍처 (Layered Architecture)
관련글 > MSA (Microservices Architecture)
참고 자료
모놀리식 아키텍처
https://yozm.wishket.com/magazine/detail/1813/
마이크로서비스 아키텍처
https://www.samsungsds.com/kr/insights/msa_architecture_edm.html
레이어드 아키텍처
https://blog.doctornow.co.kr/tech/layered-architecture
이벤트 드리븐 아키텍처
https://cloud.google.com/eventarc/docs/event-driven-architectures?hl=ko
서버리스 아키텍처
https://aws.amazon.com/ko/serverless/
