아키텍처 스타일
아키텍처 공부
오늘은 ms learn에서 기본적인 아키텍처 스타일에 대해서 알아보았습니다.
- n계층
- 웹 Queue-Worker
- 마이크로 서비스
- 이벤트 기반 아키텍처
- 빅데이터, 빅 컴퓨팅
5가지 아키텍처 스타일에 대해서 공부하였는데요.
왜 서비스 기획자를 꿈꾸는 사람이 아키텍처를 공부하냐하신다면,
우선 서비스 기획을 하다보면 필연적으로 ui 설계를 하게 되는데
저는 배워도 이해가 잘 안되었던게
데이터와 서비스의 구조 설계가 머릿속에 잡혀있지 않아서
ui설계를 배워도 그림만 예쁘게 그리고 있다는 생각이 들더라구요. (예쁘지도 않긴 하지만)
그래서 아키텍처를 공부를 해봐야겠다는 생각이 들었습니다.
또 요즘에 바이브 코딩, cursor,,,copilot,, 등 되게 잘 나와서
아키텍처를 잘 공부하면 와벽한 코딩실력을 가지지 않더라도
내가 만들고 싶은 서비스를 내가 만들어서 비즈니스를 해볼 수 있겠다는 생각 (근거없는 자신감)
이 들더라구요.
이키텍처를 이해하면, 서비스를 기획할 때 조금 더 현실적인 서비스를 구상해볼 수 있을 것 같기도 하구요
지금은 사실 아이디어를 내더라도 이게 가능한 건지, 비용이 얼마나 들지, 어떤 사람이 필요한지
감이 잘 안와서
막나가는 것도 있어요. 그게 싫더라구요
실무는 아니더라도 내 사이드 프로젝트에서 더 실무에 가깝게 해봤으면 좋겠다는 생각이 들었습니다.
n계층
애플리케이션을 기능별로 층(계층)으로 나눠서 구성한 구조예요.
이름에서 'N'은 몇 개의 층이든 될 수 있다는 뜻이에요. 보통 3~5계층이 많아요.
각각의 층은 자기 아래 층만 접근 가능합니다. 위에서 아래로만 흐름이 내려가요.
� 쉬운 비유: 레스토랑 주방 시스템
� 예시 시나리오: 로그인 기능
사용자가 웹 화면(Web Tier)에서 이메일/비밀번호 입력
이 정보가 비즈니스 계층(Middle Tier)로 전달됨 → 로그인 유효성 검사
검증 시, 데이터 계층(Data Tier)에서 사용자 정보 검색
결과를 비즈니스 계층이 판단하고 → 웹 계층에 “로그인 성공/실패” 전달
실제 웹 서비스 예시
web tier -> 사용자에게 보여주는 화면 + 요청 받기 = React, HTML/CSS
Middle Tier -> 요청 처리 로직 = Node.js, Java, Python
Data Tier -> 데이터 저장 및 관리 = SQL Server, MySQL
장점
- 역할이 명확해서 관리하기 쉽고, 개발자마다 담당 계층이 나뉠 수 있음
- 보안 분리 가능(db는 외부에서 접근 불가)
- 전통적인 기업 시스템이나 관공서, 은행 시스템에서 많이 사용됨
단점
- 모든 계층이 하나로 묶여있어서 -> 기능하나 바꾸면 전체에 영향
- 새로운 기능 추가/변경이 느림
- 각 계층 간 의존도가 높아 유지보수가 어려움 (무겁고 느린 시스템)
"n계층 아키텍처는 '입력 -> 처리 -> 저장'의 구조를 계층으로 구분해서 운영하는 전통적이고 안정적인 방식
기업 내부 시스템이나 공공기관 시스템이 주로 이 구조"
웹 Queue-Worker
✅ 핵심 개념부터: Web-Queue-Worker란?
웹 프론트엔드(Web Front End): 사용자의 요청을 받고 바로 처리 가능한 건 처리함
큐(Queue): 오래 걸리는 작업은 일단 ‘큐’에 담아둠
워커(Worker): 큐에 담긴 요청을 꺼내서 천천히 처리함 (백그라운드에서)
� 즉, 빠른 일은 바로, 무거운 일은 나중에 비동기로 처리하는 구조
�️ 쉬운 예시: 쇼핑몰 사이트
사용자가 쇼핑몰에서 "주문하기" 버튼을 누르면…
1. Web Front End
주문 확인 페이지를 보여줌 (빠르게 응답)
동시에 "주문 생성 요청"을 Queue에 넣음
2. Queue
주문 요청을 담고 대기 중
(빠른 사용자 응답과 느린 처리 분리)
3. Worker
줄 서 있는 주문 요청을 하나씩 꺼내서 처리
예: 결제 승인, 재고 차감, 알림 문자 보내기 등
4. Database / Cache
필요한 정보는 DB에서 읽고, 일부는 캐시에서 빠르게 가져옴
* azure로 매칭해보기
web Front End - Azure App service - 사용자 요청 처리(웹서버)
Queue - Azure Queue Storage or Service Bus - 비동기 작업 대기열
Worker - Azure Function or Azure WebJob - 백그라운드 작업 수행
Database - Azure SQL, Cosmos DB 등 - 데이터 저장소
Cache - Azure Cache for Redis - 자주 사용하는 데이터 캐싱
CDN - Azure CDN - 정적 콘텐츠(이미지 등) 빠르게 제공
Identity Provider - Azure Active Directory B2C - 사용자 인증 처리
Remote Service - 외부 API / Azure Logic App - 외부 시스템과 연동 (예: 결제)
장점
- 빠른 사용자 응담 : 오래 걸리는 작업 미루고, 즉시 응답
- 작업 분리 : 무거운 작업은 워커에서 따로 처리 -> 서버 부하 분산
- PaaS친화적 : App Service, Functions 등 관리형 서비스만으로도 구현가능
- 확장 용이 : 웹서버나 워커를 별도로 스케일링 할 수 있음.
단점
- 구조가 단순해서 복잡한 비즈니스 로직엔 한계
- 비동기 작업은 실패처리, 재시도, 순서 보장 등 고려사항이 많음
- 구조가 잘못되면 "작업이 빠지거나 누락되는 문제" 발생 가능
"Web-Queue-Worker는 간단하지만 효율적인 구조로 빠른 응답 + 백그라운드 작업 분리가 핵심
특히 Azure App Service + Function + Queue Storage를 쓰면 이 구조를 PaaS만으로도 쉽게 구성"
마이크로 서비스
하나의 앱(예: 쇼핑몰)을 기능별로 쪼개서 각각 독립된 작은 서비스로 만드는 방식이에요.
예를 들어, "주문", "결제", "배송", "회원관리" 같은 기능들을 따로따로 서비스로 나눠서 운영하는 거예요.
client - 사용자 - 웹사이트 방문자
api gateway - 사용자의 요청을 각 서비스로 보내주는 정문 - 고객 요청을 알맞은 서비스로 분배
service - 각각의 독립 기능 - "상품 검색", "결제", "장바구니" 등
Management/Orchestration - 전체 서비스들의 상태를 모니터링, 조정 - Kubernetes, Azure Container Apps
DevOps - 개발자+운영자=빠른배포위해 협업하는 사람들 - 각 서비스 담당자가 소규모 관리
�️ 쇼핑몰 예시로 이해해볼게요
기능 - 마이크로서비스
로그인 - 회원서비스
상품검색 - 상품 서비스
장바구니 담기 - 장바구니 서비스
결제하기 - 결제 서비스
후기 작성 - 리뷰 서비스
장점
- 빠른 업데이터 : 로그인 기능만 바꾸고 싶을 때, 거기만 수정해서 바로 배포
- 문제 격리 : 결제 오류 나도, 상품 검색은 사용 가능
- 작은 팀이 각자 담당 -> 책임 명확, 업무 분리
- 자동화 배포 (DevOps)와 궁합 좋음
단점
- 처음부터 구조설계 잘해야 됨
- 서비스끼리 통신 많음. 네트워크 오류/지연 고려
- 빌드/모니터링/배포 시스템이 복잡 -> orchestration 필요
""기능이 많고, 팀원 많고, 자주 배포해야 한다면 ? => 마이크로 서비스""
단순 mvp나 개인 플젝으로는 적합하지 않다.
"마이크로 서비스는 앱을 여러개의 작은 부품으로 나눠서
유지보수, 배포, 문제해결을 훨씬 유연하게 하는 구조"
이벤트 기반 아키텍처
이벤트 기반 아키텍처는 "어떤 일이 발생했을 때 (= 이벤트),
그것을 자동으로 감지해서 처리하는 구조"야.
=> 업무 자동화에 적합
event producers - 이벤트를 만드는 주체 (생산자) - 센서, 사용자 행동, 주문 생성
event ingestion - 이벤트를 받아들이고 분배하는 중간 허브 - Azure event HUB, Azure IoT HUB
event consumers - 이벤트를 받아서 실제로 처리하는 서비스 - 알림 발송, DB 저장, 분석 시스템
� 아주 쉬운 예시: "택배 도착 알림 시스템"
상황 - 역할 - 설명
택배가 도착했다. - event producer - 택배 시스템이 "택배도착"이벤트 발생시킴
이벤트 허브가 이를 수신 - event ingestion - Azure event grid가 이벤트를 모아둠
여러 소비자가 반응 - event consumers - 사용자에게 문자발송, db이력 저장, ai가 배송 패턴 분석 등
"이벤트는 한 번 발생하지만, 여러 소비자가 동시에 다른 방식으로 처리 가능"
IoT, 금융, 온라인 쇼핑몰, 데이터 파이프라인 유용함.
"이벤트 기반 아키텍처는 일이 생기면 알아서 반응하는 시스템
주문이 들어오면->문자보내고->포장시작하고->매출집계까지 자동"
빅데이터, 빅 컴퓨팅
"엄청나게 많은 데이터나 복잡한 계산을 빠르게 병렬처리하는 구조"
데이터를 수집해서 분석 - "고객이 언제 많이 들어오는지 파악"
실시간으로 반응 - "사용자가 클릭하면 바로 추천상품 노출"
수천개 작업 병렬 처리 - "날씨 예보 시뮬레이션, 영상 렌더링, DNA 분석"
구성 요소
요소 - 역할 - 예시 서비스
Data Sources - 데이터가 처음 들어오는 곳 - 센서, 웹사이트, 거래 내역, 로그
Data Storage - 저장소 - Azure Data Lake, Blob Storage
Batch Processing - 한꺼번에 처리 - 하루치 주문 데이터 한 번에 처리
Real-Time Ingestion - 실시간 수신 - Azure Event Hub, IoT Hub
Stream Processing - 실시간 분석 - Azure Stream Analytics
Analytical Data Store - 분석용 저장소 - Azure Synapse, SQL DW
Analytics & Reporting - 대시보드, 리포트 - Power BI, Excel 보고서
Orchestration - 전체 흐름 자동 조정 - Azure Data Factory, Logic Apps
"빅데이터 아키텍처는 많은 데이터를 수집, 처리, 분석하는 데 최적화된 구조
빅컴퓨팅은 복잡하고 무거운 계산을 수천개 서버가 동시에 하는 구조"
https://learn.microsoft.com/ko-kr/azure/architecture/guide/architecture-styles/
