기능을 구현하는 일과 그 기능을 안정적으로 운영하는 일은 서로 다른 질문을 던집니다. 서비스가 커질수록 어디까지 하나로 묶을지, 장애가 생겼을 때 영향을 어떻게 제한할지, 새 버전을 어떤 방식으로 배포할지를 함께 고민해야 합니다.
2025년 12월 20일 열린 12차 그로스톡에서 임한구 님은 시스템 아키텍처를 주제로 발표했습니다. 방송대 학우들이 전공 학습과 프로젝트 경험을 나누는 그로스로그에서, 백엔드 시스템을 설계하고 운영할 때 만나는 구조와 배포 방식의 핵심 키워드를 한자리에서 살펴본 시간이었습니다.
4년차 백엔드 개발자가 정리한 세 가지 흐름 🧭
그로스로그 1기로 활동한 임한구 님은 자신을 4년차 백엔드 개발자로 소개했습니다. 발표는 발표자 소개를 시작으로 시스템 아키텍처와 배포 전략을 차례로 살펴보는 구성으로 진행됐습니다.
임한구 님이 화이트보드에 서비스 흐름을 그리며 시스템 아키텍처를 설명하고 있다.
서비스 구조를 설명할 때는 하나의 정답을 제시하기보다 여러 패턴을 폭넓게 펼쳐 보였습니다. 시스템의 경계를 나누는 방식부터 서비스 간 통신, 장애 대응, 데이터 일관성, 관측 가능성까지 백엔드 개발자가 운영 환경에서 마주치는 주제를 연결해 볼 수 있었습니다.
하나의 애플리케이션에서 분산된 서비스까지
모놀리식 구조는 애플리케이션의 여러 기능을 하나의 배포 단위로 관리합니다. 구조가 단순한 단계에서는 개발과 배포 흐름을 이해하기 쉽지만, 서비스가 커지면 기능 간 결합도와 변경 영향 범위를 함께 살펴야 합니다.
분산된 서비스 구조에서는 역할에 따라 경계를 나누는 일만큼 서비스 사이의 연결을 다루는 일이 중요해집니다. 발표에서는 Monolithic을 출발점으로 Database per Service, Service Discovery, API Gateway, BFF, Sidecar, Service Mesh와 같은 패턴을 함께 제시했습니다.
데이터와 이벤트를 다루는 키워드로는 CQRS와 Event Sourcing, Materialized View, Pub/Sub, Outbox, SAGA가 등장했습니다. 서비스가 나뉜 뒤에도 데이터의 흐름과 처리 결과를 어떻게 맞출지 고민하게 만드는 패턴들입니다.
장애를 견디고 흐름을 관찰하는 장치 🔍
분산 구조에서는 한 서비스의 지연이나 실패가 다른 서비스로 번지지 않도록 경계를 세워야 합니다. Circuit Breaker와 Bulkhead는 실패의 전파를 제한하는 관점에서, Distributed Tracing과 Log Aggregation은 여러 서비스를 거친 요청의 흐름을 추적하는 관점에서 살펴볼 수 있습니다.
Centralized Configuration은 여러 실행 환경의 설정을 일관되게 관리하는 문제와 이어집니다. 패턴의 이름을 외우는 것보다 현재 시스템에서 장애를 어디까지 격리해야 하는지, 문제가 생겼을 때 원인을 찾을 정보가 충분한지 질문해 보는 편이 실제 설계에 더 가깝습니다.
배포 전략도 아키텍처의 일부입니다 🛠️
발표에서는 In-place, Recreate, Rolling Update, Blue/Green, Canary 배포를 주요 전략으로 정리했습니다. In-place는 기존 환경에서 애플리케이션을 교체하고, Recreate는 기존 버전을 종료한 뒤 새 버전을 올리는 방식입니다.
Rolling Update는 인스턴스를 순차적으로 교체해 한 번에 바뀌는 범위를 줄입니다. Blue/Green은 기존 환경과 새 환경을 따로 준비한 뒤 트래픽을 전환하며, Canary는 새 버전을 일부 사용자나 트래픽에 먼저 노출하고 범위를 점차 넓혀 갑니다.
각 방식은 중단 시간, 추가 인프라 비용, 버전 호환성, 문제 발생 시 되돌리는 방법에서 서로 다른 조건을 가집니다. 배포 전략을 정할 때는 “어떤 방식이 가장 최신인가”보다 “우리 서비스가 감당할 수 있는 변경 범위와 복구 시간은 얼마인가”를 먼저 확인해야 합니다.
구조를 고르는 기준은 운영에서 드러납니다
이번 발표에 등장한 패턴을 실제 프로젝트의 질문으로 바꾸면 선택 기준이 선명해집니다. 서비스의 경계가 필요한 이유, 장애가 번지는 경로, 요청을 추적하는 방법, 새 버전을 검증하고 되돌리는 절차를 차례로 적어 보면 지금 필요한 구조가 무엇인지 판단하는 데 도움이 됩니다.
시스템 아키텍처는 많은 패턴을 사용하는 일이 아니라 문제에 맞는 책임과 경계를 선택하는 일입니다. 다음 프로젝트를 설계할 때는 기능 목록 옆에 장애와 배포 시나리오도 함께 적어 보세요.
'그로스톡' 카테고리의 다른 글
| [GL 5기] 개발자처럼 사고하기: 시작하기 전에 ‘이것’만 알아두세요 🧠 (0) | 2026.07.31 |
|---|---|
| [GL 4기] 커뮤니티로 성장하기: 그로스로그 1년 활동 회고 🌱 (0) | 2026.07.31 |
| [GL 3기] 그로스로그 앱 백엔드, 정책과 구조를 함께 설계한 이유 🧱 (0) | 2026.07.31 |
| [GL 3기] 콘텐츠 관리와 가격 자동화, 복잡한 상품 정책을 코드로 옮기다 ⚙️ (0) | 2026.07.31 |
| [GL 5기] 3월 AI가 코드를 짜도 문제 정의는 사람이 한다, 개발자 사고법과 현실 Q&A🌱 (0) | 2026.05.23 |