최근 많은 서비스가 ‘마이크로서비스(MSA)’ 구조를 이야기합니다.
하지만 여전히 수많은 성공적인 서비스들은, 하나의 거대한 덩어리로 이루어진 ‘모놀리식 아키텍처’로 만들어져 훌륭하게 운영되고 있습니다.
이 전통적인 구조는 무조건 나쁜 것일까요?
그리고 QA는 이 거대한 단일 시스템을 어떻게 효과적으로 테스트해야 할까요?
이번 글에서는 ‘모놀리식 아키텍처’의 특징과 그에 맞는 QA의 ‘테스트 전략’에 대해 알아보겠습니다.
Q. ‘모놀리식 아키텍처’, 정확히 무엇인가요?
‘모놀리식 아키텍처’는 소프트웨어의 모든 구성 요소가 하나의 프로젝트, 하나의 코드베이스에 통합되어 있는 구조를 말합니다.
사용자 인터페이스(UI), 비즈니스 로직, 데이터베이스 접근 코드 등이 모두 한 덩어리로 묶여서 함께 개발되고, 테스트되고, 배포되는 것이 특징입니다.
- 비유:
- 모든 부서가 한 건물 안에 빽빽하게 모여있는 ‘거대한 백화점’과 같습니다.
- 모든 것이 한곳에 있어 내부 부서 간의 소통은 매우 편리합니다.
- 하지만 한 부서에서 리모델링 공사를 시작하면, 백화점 전체 영업에 영향을 줄 수 있습니다.
Q. QA 관점에서 ‘모놀리식 아키텍처’의 장점은 무엇인가요?
테스트의 ‘단순성’과 ‘예측 가능성’이 가장 큰 장점입니다.
- 1. 단순한 테스트 환경:
- 테스트를 위해 여러 개의 서비스를 따로따로 실행하고 연동할 필요가 없습니다.
- 하나의 애플리케이션만 실행하면 되므로, 테스트 환경을 구축하고 관리하기가 마이크로서비스에 비해 훨씬 쉽습니다.
- 2. 용이한 E2E 테스트:
- 모든 코드가 한곳에 연결되어 있기 때문에, 사용자의 전체 시나리오를 처음부터 끝까지 테스트하는 ‘E2E 테스트’가 비교적 간단하고 안정적입니다.
- 서비스 간의 네트워크 통신 실패와 같은 외부 변수가 거의 없어, 테스트 결과가 일관되게 나오는 경향이 있습니다.
Q. QA 관점에서 ‘모놀리식 아키텍처’의 단점은 무엇인가요?
‘속도’와 ‘영향 범위’의 문제가 가장 큰 단점입니다.
- 1. 느린 빌드 및 배포 시간:
- 아주 작은 코드 하나를 수정해도, 거대한 시스템 전체를 처음부터 다시 빌드하고 배포해야 합니다.
- 이 과정이 수십 분 이상 걸리게 되면, QA는 버그 수정에 대한 피드백을 빠르게 받기 어렵고 전체 개발 속도가 느려집니다.
- 2. 광범위한 회귀 테스트 필요:
- 모든 코드가 서로 강하게 연결되어 있어, 한 부분의 수정이 전혀 예상치 못한 다른 부분에 영향을 미칠(부작용) 확률이 높습니다.
- 따라서 코드 변경 시마다 매우 넓은 범위의 회귀 테스트가 필요하며, 이는 많은 시간과 노력을 요구합니다.
- 3. 장애의 거대한 영향 범위:
- 특정 기능 하나에 심각한 버그가 발생하여 서버가 다운되면, 그 기능과 전혀 상관없는 다른 모든 기능까지 함께 멈춰버리는 ‘전체 장애’로 이어지기 쉽습니다.
Q. ‘모놀리식’ 환경에서 효과적인 테스트 전략은 무엇인가요?
‘모놀리식 아키텍처’의 단점을 보완하는 방향으로 ‘테스트 전략’을 수립해야 합니다.
- 1. 강력한 자동화 회귀 테스트 구축:
- 코드 변경 시마다 넓은 범위의 회귀 테스트가 필요하므로, 이를 매번 수동으로 감당하는 것은 불가능에 가깝습니다.
- 핵심 기능에 대한 견고한 ‘자동화 회귀 테스트 스위트’를 구축하여, CI/CD 파이프라인에서 자동으로 실행되도록 하는 것이 필수입니다.
- 2. 통합 테스트에 집중:
- ‘모놀리식’ 내부의 각 모듈(컴포넌트)들이 서로 데이터를 잘 주고받는지 확인하는 ‘통합 테스트’의 중요성이 매우 큽니다.
- 모듈과 모듈이 만나는 경계, 즉 인터페이스를 중점적으로 테스트하여, 기능 통합 시 발생할 수 있는 문제들을 조기에 발견해야 합니다.
- 3. 릴리즈 전 철저한 E2E 테스트:
- 한번 배포되면 수정이 어렵고 장애의 영향 범위가 크므로, 릴리즈 전 최종 단계에서 주요 사용자 시나리오에 대한 ‘E2E 테스트’를 철저하게 수행하여 안정성을 최대한 확보해야 합니다.
결론: 구조에 맞는 테스트 전략의 중요성
‘모놀리식 아키텍처’는 결코 ‘나쁜’ 구조가 아닙니다.
오히려 많은 서비스, 특히 프로젝트 초기에 더 빠르고 단순하게 개발할 수 있는 강력한 장점을 가집니다.
중요한 것은 QA가 ‘모놀리식’ 구조의 특징을 명확히 이해하는 것입니다.
그리고 ‘광범위한 회귀 테스트’라는 단점을 ‘테스트 자동화’로 보완하며, ‘철저한 통합 및 E2E 테스트’를 통해 안정성을 확보하는 맞춤형 ‘테스트 전략’을 구사해야 합니다.
참고 자료 (References)
- Martin Fowler – MonolithFirst:
https://martinfowler.com/bliki/MonolithFirst.html - AWS – What is a Monolithic Architecture?:
https://aws.amazon.com/what-is/monolithic-architecture/