마이크로서비스 아키텍처 (Microservice Architecture)
쉽게 풀면
큰 백화점을 하나의 거대한 매장으로 통째로 운영하는 대신, 옷 가게·식당·서점을 각각 독립된 점포로 나누어 운영하는 것과 비슷합니다. 옷 가게에 문제가 생겨도 서점은 정상적으로 영업할 수 있고, 식당만 리모델링하거나 확장할 수도 있습니다. 마이크로서비스 아키텍처도 마찬가지로, 회원 관리·결제·상품 검색 같은 기능을 각각 독립된 작은 서비스로 쪼개어 개발합니다. 한 서비스에 장애가 나도 전체 시스템이 멈추지 않고, 특정 서비스만 따로 수정하거나 서버를 늘려 확장할 수 있다는 장점이 있습니다. 이는 하나의 거대한 코드 덩어리로 모든 기능을 처리하는 "모놀리식(monolithic)" 구조와 대비되는 개념입니다.
왜 중요한가
마이크로서비스 아키텍처는 클라우드 네이티브 컴퓨팅, 컨테이너 오케스트레이션, 데브옵스(DevOps) 문화 확산과 맞물려 대규모 웹 서비스와 분산 시스템 연구에서 핵심적인 설계 패러다임으로 다뤄집니다. 서비스를 독립적으로 확장·배포할 수 있다는 특성 덕분에 트래픽 급증에 유연하게 대응하는 시스템 설계 연구나, 장애를 다른 서비스로 전파시키지 않는 회복탄력성(resilience) 연구의 기반이 됩니다. 또한 서비스 간 통신, 데이터 일관성, 관측가능성(observability) 확보처럼 마이크로서비스 특유의 새로운 문제를 해결하려는 연구도 소프트웨어공학 분야에서 활발히 이뤄지고 있습니다.
논문에서는 이렇게 쓰입니다
이 문장은 "하나로 뭉쳐 있던 시스템을 여러 개의 독립된 서비스로 나누었더니, 각 서비스를 더 빨리 업데이트할 수 있게 되었고 한 부분에 문제가 생겨도 다른 부분까지 영향을 덜 받게 되었다"는 뜻입니다. 소프트웨어공학, 클라우드 컴퓨팅 분야 논문에서 시스템 구조를 설명할 때 자주 쓰입니다.
여러 개의 작은 서비스들이 서로 통신할 때 생기는 지연을 줄이고, 하나가 고장 났을 때 자동으로 다른 경로로 요청을 돌리는 기술을 제안했다는 뜻입니다.
온라인 쇼핑몰의 여러 기능을 독립된 서비스로 나눈 뒤, 이 서비스들에 걸쳐 있는 작업이 중간에 실패해도 데이터가 어긋나지 않도록 관리하는 특정 설계 방식을 적용했다는 뜻입니다.
조금 더 깊게 보면
마이크로서비스는 대개 도커(Docker) 같은 컨테이너 기술로 패키징되고, 쿠버네티스(Kubernetes) 같은 오케스트레이션 도구로 배포·확장·복구가 자동화되는 경우가 많습니다. 서비스가 많아지면 서비스 간 호출 경로가 복잡해지므로, 이를 통합 관리하는 "서비스 메시(service mesh)"나 API 게이트웨이 같은 구성 요소가 함께 언급됩니다. 여러 서비스에 걸친 작업의 데이터 일관성 문제는 전통적인 ACID 트랜잭션 대신, 각 단계의 실패를 보상 작업으로 되돌리는 "사가(saga) 패턴" 같은 대안적 설계로 다뤄지는 경우가 많으며, 시스템 전체의 상태를 파악하기 위한 분산 추적(distributed tracing)과 로그 통합도 중요한 연구 주제로 다뤄집니다.
주의할 점
마이크로서비스가 항상 정답인 것은 아닙니다. 서비스 수가 늘어날수록 서비스 간 통신을 관리하는 API (응용 프로그래밍 인터페이스) 호출이 많아지고, 여러 서비스에 걸친 작업의 데이터 일관성(ACID 트랜잭션처럼 하나의 단위로 묶기 어려움)을 보장하기가 더 어려워집니다. 규모가 작은 프로젝트에서는 오히려 관리 부담만 늘어날 수 있어, 서비스 규모와 팀 구조를 고려해 선택해야 합니다.