1. 배경(Problem)
대규모 사용자와 장기적인 확장성을 고려한 클라우드 네이티브 금융 플랫폼을 구축하는 것을 목표
MVP 개발과 단계별 고도화
•
최소한의 은행 기능(예금, 인출, 송금 등)과 사용자 인증 기능을 갖춘 MVP 구축
•
수십만 사용자 확장 및 향후 기능 추가(대출 상품추천, 외부 은행 연동 등)을 대비한 아키텍처
설계 및 기반 마련
OPS 및 IaaS 구축 과정에서의 기반 인프라 및 배포 환경을 준비
•
Auto Scaling & Elastic Load Balancer를 활용한 동적 리소스 관리
•
AWS API Gateway를 이용한 API 트래픽 관리와 보완성 강화
지원 기능
회원가입(로그인,로그아웃), 예금, 인출, 송금
Mypage(계좌 잔액 조회)
회원탈퇴
2. 서비스 소개(Solution)
1차 시연영상
•
금융서비스
•
CRUD 기반 웹 애플리케이션 개발
•
MFA 도입으로 보안강화
2차 시연영상
•
취약점 시나리오 분석
•
CI/CD 분석 tool을 활용한 분석 자동화 배포 자동화
•
보안 테스트 / 인프라 성능 테스트(부하 테스트) / 접근 제어 테스트
3차 시연영상
•
마이크로서비스 및 컨테이너 관리 자동화
•
IaaS 클라우드 운영 자동화
•
CI/CD 파이프라인을 이용한 자동 코드 배포 및 업데이트 (IaC와 GitOps를 포함)
•
컴플라이언스 준수
3. 아키텍처 및 핵심 기능
1차 아키텍처
•
CRUD 기반 django + Postgresql 웹 애플리케이션 개발
•
Docker 기반 수동 배포
•
HTML + Tailwind CSS + JS 프론트엔트 개발
•
AWS 기반 고가용성 구조
2차 아키텍처
•
1차 웹 애플리케이션 기반 분석 자동화
•
Owasp zap + bandit ⇒ 동적분석
•
SonarQube + Semgrep ⇒ 정적분석
•
Safety + Trivy ⇒ 라이브러리 분석(패키지 취약점)
•
Drone CI tool을 도입하여 CI/CD 자동화
•
AWS WAF의 보안 룰셋으로 DDos, cross site scrriping , sql injection과 같은 악의적인 트래픽을 1차 차단합니다
◦
백엔드 서버는 ALB로 라우팅 처리하여 ECS Fargate 기반 서버리스 구조 실현,
데이터베이스는 RDS muti-az 와 PostgreSQL를 사용 해 고가용성을 높였습니다.
정적 파일은 S3 + CloudFront + Route 53으로 배포 → 배포 전략은 Rolling Update 구조로 무중단 배포 실현 Auto Scaling 기반으로 CPU 사용률에 따라 ECS 서비스 자동 확장됩니다.
이를 통해 장애 발생 시에도 빠르게 대응 가능한 구조를 갖췄습니다.
▪
ECS Fargate 내부에 main과 test 환경을 분리. 기존에는 운영 환경에서 직접 테스트를 병행했지만, 이제는 각 컨테이너가 분리되어 배포되고, 트래픽도 라우팅 단에서 구분 처리. main 서비스는 실제 사용자 대상 API를 담당하고, test 서비스는 자동화된 테스트용 시나리오를 실행하면서 운영 서비스와 완전 분리.
▪
그리고 main 컨테이너 내부에 설치된 OpenTelemetry Collector가 모든 트랜잭션 로그를 실시간으로 수집하여 AWS CloudWatch로 전송합니다. 예외 발생, API 지연, 트랜잭션 실패 여부가 감지되면 알림 시스템과 연동되어 운영자에게 알람메일이 가도록 구현하였습니다.
3차 아키텍처
1.
EKS 기반 MSA 애플리케이션 영역 입니다. 사용자 요청은 ALB를 통해 EKS Ingress로 전달되며,각 서비스는 Django 기반의 user-service, transaction-service와 React 기반의 front-service로 분리되어 있습니다. 각 서비스는 독립적인 PostgreSQL DB와 연결되어 있고, 내부 통신은 Service Mesh 없이 단순 라우팅으로 구성되었습니다.
또한 Prometheus에서 리소스 및 Velero 상태 지표를 수집하고, Grafana를 통해 시각화하여 모니터링 체계를 구성했습니다.
2.
CI/CD 및 배포 자동화 개발자가 GitHub에 코드를 Push하면, Jenkins 또는 ArgoCD가 Webhook을 통해 감지하여 Docker 빌드 후 AWS ECR에 푸시, 이후 ArgoCD가 Git과의 sink작업을 통해 EKS로 자동 배포를 수행합니다. 이 파이프라인은 Terraform으로 정의된 인프라 구성과 연동되며, Terraform은 EC2 위에서 실행되도록 설정되어 있습니다.
3.
백업 / 보안 / 감사 / 운영 컴플라이언스
Velero를 통해 Kubernetes 리소스를 S3로 백업하고, 해당 파일은 KMS로 암호화 합니다. 동시에 AWS Backup을 활용해 EBS 볼륨도 별도로 백업하고 있습니다. 보안 측면에서는 AWS Config, Security Hub, CloudTrail을 활용하여 보안 취약점 탐지, 리소스 변경 추적, 규정 준수 상태 모니터링을 수행했습니다.
또한 각 리소스에는 비용 라벨을 태깅해 서비스별 과금 구조를 시각화하고, 미사용 리소스를 수동 또는 자동으로 식별하여 삭제할 수 있도록 구성했습니다.
4. 활용 라이브러리 및 개발 환경
기술 스택 : Django, React, PostgreSQL, Docker , Github
•
생성형 AI : Chat GPT, v0 Vercel (Front 전용)
•
개발 도구 : Cursor
•
인프라 : AWS 서비스 (아키텍처 참고) , Terraform , Ansible
•
CI/CD : Jenkins , Argo CD , AWS ECR
•
백업 도구 : VELERO , AWS Backup
•
모니터링 : Prometheus , Grafana , AWS CloudTrail
5. 트러블 슈팅
1차 프로젝트
•
Git 관리 및 충돌 해결에 어려움이 있었으나, 팀원들과 원활하게 소통하며 브랜치를 역할에 따라 적절히 분리하고 기준을 마련하여 문제를 해결함.
•
트러블슈팅 발생 : Nginx (Reverse Proxy) → Gunicorn (WSGI 서버) → Django (Application Layer) 순으로 처리
기존 구조의 한계점 Nginx와 Gunicorn의 역할이 중복되거나 불명확해지는 상황이 많았고, 특히 외부 인증서(ACM)나 HTTPS 적용 경로가 EC2 내부로 집중되면서 보안 구성에 불필요한 복잡성 발생 또한 EC2 안에서 모든 로직이 처리되는 구조는 로드 밸런싱, 확장성, CI/CD 자동화에 부적합 WSGI 기반 구조는 상태 기반 요청 처리에 적합하긴 하지만, 비동기 요청 처리나 대규모 트래픽을 견디는 구조로는 적절하지 않다는 점도 확인
트러블 슈팅 해결 : Nginx 제외 ALB를 적용하므로 해당 문제를 해결함
2차 프로젝트
•
트러블슈팅 발생 : 클라우드 프론트 캐싱 문제로 EC2서버 배포시 업데이트 및 몇몇 코드오류가 발생하여 해당 문제 해결 필요
◦
현재 : 미해결 , 2차 아키텍처는 ECS와 Fargate 서버 사용하지만 cloudfront 지속사용으로 해당 문제 해결해야함
◦
오류 원인 분석 : 클라우드 프론트 캐싱
•
트러블 슈팅 발생 : ECR통해서 ECS 배포 중 배포 안됌 / 분석도구 외 자동화 테스트 하려던 코드 중 몇가지 오류발생
◦
트러블 슈팅 해결 : image 수정 후 해결됨 / 코드 수정 중
•
트러블 슈팅 발생
◦
Owasp zap 자동화 Tool 사용시 API 검사시에 /logout 로그아웃 되어버려 세션 삭제 → 검사 제외에 *./logout 추가
◦
트러블 슈팅 해결 : 세션 권한 인증문제 발생 해 모든 API가 404 forbidden으로 검사 불가 → ZAP 사용법 완벽 숙지 후 해결
3차 프로젝트
•
트러블슈팅 : MSA 인증/인가 부분 404 에러
◦
원인 : 기존 코드에서 세션,쿠키만 사용함 -> MSA 분기로 넘어가면서 JWT 토큰 기능을 추가함 해당 부분 api 설정시 nginx proxy를 사용해서 도커 컨테이너화를 시키는 중 계속해서 403 또는 404 에러가 발생했는데 미니프로젝트를 만든 후 로컬에서도 실행되는것을 확인한뒤, 방법을 동일하게 지금 프로젝트에 적용해보니 토큰적용과 200ok 되는것을 확인함
◦
결론 : 코드 리팩토링 후 배포시 APIGW 적용하여 진행할 예정
•
aws auth 권한 부여 어려움 → 테라폼에서 권한 자동 부여 OIDC + IRSA 권한)
•
helm 설치 시 파드 공간 부족 문제 → 노드 그룹의 할당량 증가로 해결
6. 팀 소개
•
김수진 / 팀 리더 / tow369@naver.com•
뛰어난 통솔력 ,모두를 휘어잡는 카리스마
•
PM, 최종배포, 운영 안정화, 인프라 아키텍처 설계, 비용 최적화
•
배재성 / 성장하는 개발자 / bajasung@gmail.com•
모두의 정신적 지주
•
백엔드 개발 , CI/CD ,인프라 관리
•
엄현진 / 똑순이 / ehj2203@naver.com•
팀 분위기 책임지는 귀여미
•
인프라 환경 설정(Terraform), 보안 검사, 시각화 및 내용 분석 , 풀스택 인프라
•
김은산 / 함께형 / wjdrudtns999@naver.com•
언제든지 달려가는 든든산과 은쪽이
•
MSA 소프트웨어 아키텍처 , 바이브 코딩 , 풀스택 개발