Daily Compass: Azure 서버리스 데이터 파이프라인 설계

Daily Compass는 클라우드 엔지니어링 교육 과정에서 진행한 팀 프로젝트입니다. 사용자가 하루를 계획할 수 있도록 감정 기반 명언, TODO/Calendar, 실시간 뉴스를 한 화면에 제공하는 개인 데일리 대시보드를 목표로 했습니다.

저는 이 프로젝트에서 전체 아키텍처 설계, 데이터 흐름, DB 스키마, UI/UX 와이어프레임, 실시간 뉴스 크롤링, 발표 자료 제작, 최종 산출물 문서화를 담당했습니다.

왜 클라우드였나

이 프로젝트는 단순한 로컬 웹 앱이 아니라, 처음부터 클라우드 네이티브 애플리케이션으로 설계했습니다.

우리가 목표로 한 것은 다음과 같습니다.

• 서버 관리 부담이 적은 백엔드 실행 환경
• 사용자별 대시보드 데이터를 저장할 수 있는 유연한 NoSQL 구조
• Private Endpoint 기반의 안전한 DB/Storage 접근
• GitHub Actions 기반 CI/CD
• API 오류와 성능을 추적할 수 있는 모니터링
• 감정 기반 명언을 음성으로 들려주는 AI/Speech 연동 가능성

핵심 의사결정은 Azure 관리형 서비스를 활용해 운영 부담을 줄이면서도, 보안, 가용성, 관측 가능성 같은 운영 관점의 문제를 함께 연습하는 것이었습니다.

전체 아키텍처

요청 흐름은 다음과 같이 구성했습니다.

User
  -> Azure Static Web Apps
  -> Azure Functions
  -> Azure Cosmos DB for MongoDB
  -> Azure AI Speech
  -> Application Insights

프론트엔드는 Azure Functions API를 호출하고, 백엔드는 Cosmos DB에서 사용자 데이터를 읽고 씁니다. 감정 기반 명언은 필요에 따라 Azure AI Speech와 연결해 음성 출력으로 확장할 수 있게 설계했습니다. Application Insights는 오류와 성능 신호를 수집하는 역할을 맡습니다.

기능 범위

대시보드는 세 가지 모듈로 구성했습니다.

• 마음 우체통: 사용자가 기분을 선택하면 그에 맞는 명언을 반환합니다. 입력 텍스트는 저장하지 않습니다.
• My Diary: 사용자별 TODO와 Calendar 데이터를 저장하고 관리합니다.
• 실시간 뉴스: Node.js crawler가 최신 뉴스를 수집하고 백엔드 API를 통해 제공합니다.

중요한 점은 UI 자체보다, 이 기능들을 하나의 일관된 데이터 흐름 안에 넣고 보안 경계를 명확히 만드는 것이었습니다.

보안과 네트워크 설계

네트워크는 역할별로 분리했습니다.

• frontend subnet
• backend/database subnet
• API gateway subnet

데이터 보호를 위해 Cosmos DB와 Storage에는 Private Endpoint를 적용하는 구조로 설계했습니다. 이렇게 하면 DB와 스토리지가 단순히 public endpoint로 노출되지 않습니다.

이 프로젝트에서 가장 중요하게 가져간 보안 원칙은 단순했습니다.

애플리케이션이 외부에서 접근 가능하다고 해서, 데이터베이스까지 외부에서 접근 가능해야 하는 것은 아니다.

작은 교육 프로젝트에서는 쉽게 넘어갈 수 있는 부분이지만, 기업 클라우드 아키텍처에서는 매우 중요한 경계입니다.

데이터와 운영

Cosmos DB MongoDB API를 선택한 이유는 대시보드 데이터가 사용자별 document 형태에 가깝기 때문입니다.

• 사용자 프로필과 인증 데이터
• TODO 항목
• Calendar 기록
• 감정 기반 명언 컬렉션
• 뉴스 문서

운영 관점에서는 Application Insights로 다음 항목을 추적하는 것을 계획했습니다.

• 함수 실행 성공/실패율
• API 응답 시간
• 오류 로그
• Cosmos DB RU 사용량

교육용 아키텍처 기준 예상 비용은 월 $32-45 정도였고, 대부분은 Cosmos DB throughput에서 발생하는 구조였습니다.

배운 점

이 프로젝트에서 세 가지를 분명히 배웠습니다.

첫째, 데이터 파이프라인은 보안 설계이기도 합니다. 사용자 데이터, 크롤링 데이터, AI 출력이 같은 대시보드 안에서 만날 때는 무엇을 저장하고, 무엇을 일시적으로 처리하며, 무엇을 public으로 열어둘지 명확히 나눠야 합니다.

둘째, 서버리스가 아키텍처 고민을 없애주지는 않습니다. Azure Functions는 서버 관리 부담을 줄여주지만, API 형태, DB 접근, 네트워크 제한, 모니터링, 배포 방식은 여전히 설계해야 합니다.

셋째, 문서화도 엔지니어링의 일부입니다. 아키텍처 다이어그램, 데이터 흐름 설명, 운영 메모는 나중에 붙이는 장식이 아니라, 팀이 신뢰성/보안 목표와 구현 방향을 맞추는 수단입니다.

다음 개선 방향

지금 다시 발전시킨다면 다음을 우선할 것 같습니다.

• Azure AD B2C 또는 관리형 인증 서비스 도입
• 뉴스 수집과 명언 생성 흐름의 이벤트 기반 처리
• Terraform 기반 인프라 프로비저닝
• Private Endpoint 적용 범위 확대
• 운영용 observability dashboard 구성
• Azure AI Language 또는 Azure Machine Learning 기반 추천 파이프라인

Daily Compass는 교육 프로젝트로 시작했지만, 작은 서비스라도 실제 보안, 배포, 운영 관점으로 설계해야 한다는 좋은 아키텍처 연습이었습니다.