V1 - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

목차 (펼치기/접기)

* 1. V1 목표 정의
* 2. 현재 아키텍처 요약(V1 진행상황 기준)
* 3. EC2 내부 서비스 구성(Prod / NonProd 공통)
* 4. 운영 접근 및 감사 로그(SSM 세션 로그 + 로그 그룹 분리)
* 5. 비속어 탐지·처리 및 보안 모니터링(CloudWatch → SNS/Lambda → Discord)
* 6. 배포 파이프라인 및 배포 이력 기록(GitHub Actions → S3 Artifact → CodeDeploy)
* 7. 운영(Prod) 수동 트리거 배포 흐름 추가
* 8. 스토리지 및 아티팩트 관리(S3)
* 9. V1 기준 달성 항목 정리(진행상황)
* 10. 다음 단계 제안(V2 전환 방향)

V1에서는 기능 개발 속도와 운영 단순성을 우선하여 **“배포 가능한 서비스 형태 + 운영 관찰 가능성(Observability)의 최소 기준”**을 달성하는 것을 목표로 함.
서비스는 개인 포트폴리오/이력서 기반 채용 비서 AI이며, 커뮤니티·채팅·챗봇·캘린더 기능을 제공함.
구성요소는 Next.js(프런트), Spring Boot(백엔드), FastAPI(vLLM 기반 AI)로 분리하여 운영함.

현재는 Prod_VPC / NonProd_VPC를 분리하여 환경 간 격리를 달성함.
각 VPC는 Public Subnet 1개 + EC2 1대로 구성되어 단일 노드에서 서비스 컴포넌트를 운영함.
외부 트래픽은 Route 53 → (각 VPC의 Internet Gateway) → EC2(Nginx) 흐름으로 유입됨.
운영 관점에서는 SSM 기반 접근 통제 + CloudWatch 중심 모니터링 + Discord 알림 + 배포 이력 기록을 통해 “사람이 직접 들어가서 확인하는 운영”을 줄이는 방향으로 구성함.

각 환경의 EC2에는 아래 구성요소가 배치됨.

• Nginx(80, 443): 외부 트래픽 단일 진입점 역할을 수행함.
  
• Next.js(3000): 사용자 웹 UI를 제공함.
  
• Spring Boot(8080): API 서버로서 인증/비즈니스 로직/커뮤니티·채팅·캘린더의 코어 기능을 처리함.
  
• Spring Boot Blue/Green(8080): 무중단 배포 전환을 위해 Blue/Green 구성을 적용함.
  
• FastAPI(8000): AI 기능(vLLM 기반 추론 포함) 및 챗봇 연동 기능을 처리함.
  
• PostgreSQL(5432): 서비스 데이터 저장소로 사용함(현재 동일 인스턴스 내 구성임).
  
• ChromaDB: AI 기능의 벡터 저장소로 사용하며 FastAPI와 연동됨.
  

도메인 라우팅은 Nginx 리버스 프록시로 분기하여 서비스 URL을 분리함.
(예: www.* → Next.js, api.* → Spring Boot, ai.* → FastAPI 형태로 구성함.)

운영 접근은 SSH 직접 접근보다 SSM(Session Manager) 중심으로 전환하여 접근 경로를 통제하고 기록이 남도록 설계함.
SSM 세션 로그는 CloudWatch Logs의 SSM 전용 Log Group에 저장되며, 이를 통해 “누가/언제/어떤 명령을 입력했는지”를 사후 추적 가능하게 함.
Dev/Prod 환경은 로그 그룹을 분리하거나, 하나의 로그 그룹에서 Stream Prefix로 환경/인스턴스를 구분하는 방식으로 조회성을 확보함.

SSM 세션 로그와 운영 로그는 단순 저장에서 끝내지 않고 위험 신호를 자동 탐지하도록 구성함.

• CloudWatch Logs에서 비속어/위험 명령 패턴/금칙어 등을 Metric Filter로 추출함.
  
• 특정 임계치 조건에서 CloudWatch Alarm을 발생시킴.
  
• 알람은 SNS로 전달되며, 필요 시 Lambda가 메시지를 가공함.
  
• 최종적으로 Discord 채널로 알림이 전송되어 운영자가 즉시 인지할 수 있도록 함.
  

이 구조는 “로그를 나중에 확인”이 아니라 “이상 징후가 운영자에게 먼저 도달”하는 운영을 가능하게 함.

V1에서는 배포 자동화를 최소 비용/최소 복잡도로 구성하되, 배포 이력의 추적 가능성을 함께 확보함.
현재 배포 흐름은 아래와 같음.

1. 개발자가 GitHub에 푸시함
   
2. GitHub Actions에서 빌드/패키징을 수행함
   
3. 산출물을 S3(Artifact_Prod/Dev)에 업로드함
   
4. CodeDeploy가 해당 아티팩트를 EC2로 배포함
   

이 과정은 아티팩트(버전) 단위로 저장·관리되며, S3 아티팩트 + CodeDeploy 기록을 통해 “언제 어떤 버전이 배포되었는지”를 추적 가능하게 함.

운영 환경(Prod)은 서비스 안정성이 최우선이므로, 단순히 푸시 이벤트로 자동 배포되지 않도록 수동 트리거 기반 배포 흐름을 추가함.
즉, NonProd는 개발 편의성을 위해 자동 배포 중심으로 운영하되, Prod는 “운영자 승인 후 배포”가 되도록 분기함.

• 운영 배포는 GitHub Actions에서 workflow_dispatch(수동 실행) 또는 승인 단계가 포함된 수동 트리거로 수행함.
  
• 수동 트리거 방식은 배포 타이밍을 운영자가 통제할 수 있어, 피크 타임 회피 및 점검 창 운영이 가능해짐.
  
• 장애 발생 시 “자동 배포로 인한 연쇄 영향”을 줄이고, 배포 전 최종 체크(헬스/로그/지표 확인)를 강제하는 효과가 있음.
  
• 수동 트리거로 실행된 배포 역시 S3 아티팩트 및 CodeDeploy 이력에 기록되어, 자동 배포와 동일한 수준의 추적성을 유지함.
  

결과적으로 V1 단계에서도 Prod는 “의도된 배포만 반영되는 운영 체계”로 정리함.

S3는 두 목적의 버킷 체계로 사용함.

• S3(Prod/Dev): 서비스 기능 관점에서 업로드 파일/정적 리소스 저장소 역할을 수행함.
  
• Artifact_Prod/Dev: 배포 관점에서 CodeDeploy가 참조하는 아티팩트 저장소로 사용함.
  

서비스 데이터와 배포 산출물을 분리하여 운영 리스크를 줄이는 구조임.

• Prod/NonProd VPC 분리 완료함.
  
• 각 환경에 EC2 기반 서비스 스택(Next.js/Spring Boot Blue/Green/FastAPI/PostgreSQL/ChromaDB/Nginx) 배치 완료함.
  
• Route 53 기반 도메인 진입 및 Nginx 리버스 프록시 분기 구성 완료함.
  
• GitHub Actions → S3 Artifact → CodeDeploy 배포 흐름 구성 완료함.
  
• Prod 배포는 수동 트리거 기반으로 통제 가능하도록 구성 완료함.
  
• SSM 기반 운영 접근 통제 및 세션 로그 기록 구조 구성 완료함.
  
• CloudWatch 기반 모니터링/경보 및 Discord 알림 연동 구성 완료함.
  
• SSM 로그 그룹 기반 비속어/위험 패턴 탐지(필터 → 알람 → 알림) 구성 완료함.
  

• 단일 EC2 내 DB 동거 구조로 장애 도메인이 큼.
  
• 단일 노드 구조이므로 오토스케일/자가복구가 제한적임.
  
• Public Subnet 기반이므로 외부 노출면 최소화 정책이 지속적으로 필요함.
  
• AI 워크로드(vLLM)의 리소스 변동이 커서 성능/비용 튜닝과 격리가 필요함.
  

V1은 “배포 가능한 서비스 + 최소 운영 자동화”를 확보하는 단계였음.
V2에서는 “서비스 중심 운영”을 위해 무중단 배포를 더 일반화하고, 장애 대응을 자동화하며, 확장성을 확보하는 방향이 필요함.
트래픽 증가와 기능 확장(채팅/AI/캘린더 동시 사용)이 본격화되면, 멀티 노드 기반 오케스트레이션(kubeadm 포함) 전환이 자연스러운 다음 단계가 됨.