FISA-Agri-Pay

🌱 콩콩팥팥

농민을 위한 대안 신용평가 기반 BNPL 플랫폼

농업 데이터를 바탕으로 농민에게 맞춤형 구매 한도를 제공하고,
시계열 예측 기반 오토스케일링과 통합 관측성을 갖춘 하이브리드 클라우드 시스템입니다.

우리 FISA 클라우드 엔지니어링 6기 최종 프로젝트 - 데브식스

📑 목차

프로젝트 개요
대안 신용평가 모델
주요 서비스 기능
시스템 아키텍처
인프라 및 기술적 특징
트러블슈팅 & 성능 개선
테스트 및 품질
팀원 소개
리포지토리
기술 스택

📌 프로젝트 개요

💡 기획 배경 - 문제 상황

1. 고정 급여가 없어 기존 신용평가만으로 상환 능력을 증명하기 어려움

농민은 일반 근로자와 달리 매월 일정한 급여를 받지 않는 경우가 많아, 소득과 금융 거래 이력을 중심으로 평가하는 기존 신용평가만으로는 실제 상환 능력을 충분히 인정받기 어렵습니다.

2. 농업의 계절성과 영농 활동이 신용평가에 충분히 반영되지 않음

농업 소득은 작물의 재배·수확 시기에 따라 크게 달라지며, 경작 면적이나 농작물재해보험 가입 여부와 같은 실제 영농 정보도 기존 금융 데이터에 제대로 기록되지 않아 농민의 신용도를 정확히 평가하기 어렵습니다.

3. 농자재 구매 시점과 수확 소득 발생 시점의 차이로 자금 부담이 발생

농민은 종자, 비료, 농약 등 영농에 필요한 농자재를 수확 전에 구매해야 하지만 소득은 수확 이후에 발생합니다. 이로 인해 영농 초기에 자금 부담이 집중되고, 필요한 시점에 적절한 금융 지원을 받기 어렵습니다.

🎯 프로젝트 목표

농업 특화 대안 신용평가: 경작 면적, 농작물재해보험 가입 여부, 주 재배 품목과 상환 행동을 반영해 농민의 신용도를 평가합니다.
농민 전용 BNPL 서비스: 농자재 구매부터 월별 이자 납부, 원금 상환까지 하나의 흐름으로 제공합니다.
하이브리드 클라우드: 금융 원장과 민감 데이터는 온프레미스에, 확장성과 접근성이 필요한 서비스는 AWS에 배치합니다.
예측형 운영 자동화: 과거 트래픽을 학습한 GRU 모델과 KEDA를 결합해 트래픽 증가 전에 리소스를 확장합니다.
AIOps와 통합 관측성: 로그, 메트릭, 트레이스와 내부 토폴로지를 활용해 장애 원인과 조치 방향을 자동 분석합니다.

🗓️ 수행 기간 2026.04.23 ~ 2025.06.17 (9주)

🧮 대안 신용평가 모델

콩콩팥팥은 신규 가입자의 정적 농업 정보와 서비스 이용 이후의 행동 데이터를 단계적으로 결합합니다.

점수	평가 시점	주요 평가 데이터	역할
ASS	신규 가입	농업경영체 등록 기반 경작 면적, 농작물재해보험 가입 여부, 주 재배 품목	초기 신용 점수 산정
BSS	한도 승인 후	이자·원금 상환 이력, 연체 및 연체 해소 이력, 한도 사용률	월별 행동 점수 산정
CSS	최종 평가	신규 신청자는 ASS, 기존 이용자는 ASS와 BSS를 함께 반영	최종 신용 점수와 BNPL 한도 결정

결제 워크플로

최초 거래
ASS 및 CSS 산출
  -> BNPL 거래 및 월별 이자 납부
  -> 월별 이자 납부와 연체 현황을 반영해 BSS 산출
  -> 원금 상환 및 거래 종료

재거래
ASS와 기존 BSS를 합산해 CSS 갱신
  -> BNPL 거래 및 월별 이자 납부
  -> 행동 데이터를 반영해 BSS 갱신
  -> 원금 상환 및 거래 종료

✨ 주요 서비스 기능

기능	설명
사용자·인증	회원가입, 로그인, 인증과 결제 PIN 검증을 제공합니다.
대안 신용평가	농업 정보와 상환 행동을 바탕으로 신용 점수, 산출 근거와 최종 결과를 제공합니다.
농민 프로필	기본 정보, 작물 종류, 경작 면적과 보험 가입 정보를 관리합니다.
한도 관리	신용평가 결과에 따라 BNPL 한도를 부여하고 사용·잔여 한도를 관리합니다.
상품 주문·조회	농자재 상품을 조회하고 BNPL 주문과 주문 상태를 관리합니다.
원장 관리	대출·이자·연체 원장을 생성하고 상환 내역을 기록합니다.
상환 및 연체	상환 기한에 따라 원금과 이자를 상환하고 연체 발생·해소 이력을 반영합니다.
관리자 대시보드	농민, 한도, 주문, 상환, 연체, 원장과 감사 로그를 통합 조회합니다.
AIOps	운영 데이터로 이상을 탐지하고 LLM 기반 장애 원인 분석과 조치 가이드를 제공합니다.

🎬 서비스 시연 플로우

각 GIF 미리보기를 클릭하면 전체 시연 영상을 확인할 수 있습니다.

👨‍🌾 사용자 측면

🧾 한도 신청	🛒 농자재 구매	💬 유저 챗봇

👩‍💼 관리자 측면

✅ 한도 승인	🚚 배송 관리	⚠️ 연체 현황	🤖 관리자 챗봇

🏗️ 시스템 아키텍처

AWS, 온프레미스 데이터센터와 VESSL AI를 연결한 하이브리드 아키텍처입니다. MSA 서비스는 역할과 데이터 민감도에 따라 AWS EKS와 온프레미스 Kubernetes에 분산하고, Site-to-Site VPN을 통해 사설 통신합니다.

영역별 구성

영역	구성	역할
AWS Cloud	Route 53, CloudFront, S3, ALB, EKS, ECR, RDS, DMS, SQS, CloudWatch	정적 웹 호스팅, 외부 진입점, 확장형 서비스, 비동기 메시지, DR과 클라우드 모니터링
온프레미스	pfSense, HAProxy, Kubernetes, PostgreSQL, Patroni, etcd, TrueNAS	금융 원장·거래 데이터, 내부 서비스, DB 고가용성과 영구 스토리지
VESSL AI	H100 GPU, vLLM, Qwen3	사내 LLM 추론과 AIOps 분석
Delivery	GitLab, Jenkins, Harbor, Trivy, Argo CD	빌드·검증·이미지 관리와 GitOps 배포
Observability	Prometheus, Grafana, Loki, Tempo, OpenTelemetry, Fluent Bit, Hubble	로그, 메트릭, 트레이스와 네트워크 흐름 통합 관측

주요 설계 결정

서비스와 데이터 분리: 외부 접근과 확장이 필요한 상품·프런트엔드 서비스는 AWS에, 금융 원장과 민감 데이터는 온프레미스에 배치했습니다.
네트워크 고가용성: pfSense를 이중화하고 허용된 IP와 포트만 통과시키며, 내부 VLAN은 HAProxy를 통해 라우팅합니다.
데이터 고가용성: 온프레미스 PostgreSQL은 Patroni와 etcd 기반 Primary-Replica 구조로 구성하고, 읽기·쓰기를 분리하는 CQRS를 적용했습니다.
클라우드 DR: RDS를 이중화하고 DMS Full Load와 CDC로 재해 복구 경로를 구성했습니다.
비동기 서비스 연계: 인증, 상품, 결제 서비스 간 이벤트를 AWS SQS로 전달해 결합도를 낮췄습니다.

☁️ 인프라 및 기술적 특징

1️⃣ GRU + KEDA 기반 Predictive Autoscaling

기존 HPA는 CPU·메모리 임계치를 넘은 뒤에야 확장을 시작해 트래픽 급증 시 500 오류와 긴 지연이 발생했습니다. 과거 트래픽으로 학습한 GRU 모델이 향후 RPS를 예측하고, 예측값을 KEDA 외부 메트릭으로 전달해 필요한 Pod를 미리 확보하도록 개선했습니다.

지표	HPA	GRU + KEDA	개선
P95 최고 지연	9.70s	389ms	96.0% 감소
P99 최고 지연	9.94s	1.55s	84.4% 감소
500 오류	발생	미발생	완전 제거

🎬 HPA vs GRU + KEDA 시연 영상

HPA — 반응형 오토스케일링

hpa-rev.mp4

GRU + KEDA — 예측형 오토스케일링

keda-rev.mp4

2️⃣ MCP 기반 AIOps

서버 CPU, 메모리, 디스크와 서비스 트래픽을 수집합니다.
시계열 예측 RPS와 실제 트래픽의 차이를 감지합니다.
예측값 초과 시 로그, 메트릭, 트레이스와 내부 토폴로지를 함께 수집합니다.
VESSL AI의 Qwen3-32B LLM이 MCP 도구를 통해 필요한 운영 데이터만 조회합니다.
서비스, 네트워크, DB 경로를 시각화하고 근본 원인 후보와 조치 방향을 Slack으로 전달합니다.
민감 정보는 마스킹하고, LLM과 인프라 사이에는 실행 범위를 제한하는 MCP 계층을 둡니다.

3️⃣ 통합 관측성과 알림

EKS: CloudWatch로 노드·Pod CPU 및 메모리, 네트워크 트래픽과 오류 지표를 관측합니다.
온프레미스 Kubernetes: Prometheus 기반 리소스 모니터링과 Hubble 기반 HTTP·TCP·UDP·ICMP 네트워크 흐름을 관측합니다.
PostgreSQL: 호스트 자원, 쿼리·트랜잭션 처리량, 복제 지연(Replication Lag), 연결 수와 오류 로그를 관측합니다.
pfSense: 이중화 상태, 자원 사용률, AWS 간 트래픽과 VLAN별 허용·차단 이벤트를 수집합니다.
분산 트레이싱: OpenTelemetry로 서비스 로그와 트레이스를 연결하고 Tempo·Grafana에서 BNPL 결제 흐름을 추적합니다.
알림: EKS Pod·Node 이상과 PostgreSQL CPU·메모리·디스크 임계치 초과를 Alertmanager와 Slack으로 전송합니다.

🎬 통합 모니터링 시연 영상

각 GIF 미리보기를 클릭하면 전체 시연 영상을 확인할 수 있습니다.

모니터링 영역	주요 관측 내용	화면 예시
☸️ 온프레미스 Kubernetes	Prometheus 기반 노드·Pod 자원 사용률과 Hubble 기반 네트워크 흐름을 관측합니다.
🔥 pfSense	이중화 상태, 자원 사용률, AWS 연결 트래픽과 VLAN별 허용·차단 이벤트를 확인합니다.
☁️ CloudWatch	EKS 노드·Pod의 CPU, 메모리, 네트워크 트래픽과 오류 지표를 모니터링합니다.
🚨 Alertmanager	인프라 임계치 초과와 서비스 이상을 탐지하고 관련 알림을 Slack으로 전달합니다.
🔭 Observability / Trace	OpenTelemetry와 Tempo를 활용해 서비스 요청 흐름과 BNPL 결제 트레이스를 추적합니다.
🤖 AIOps — 장애 분석	로그·메트릭·트레이스와 토폴로지를 바탕으로 장애 원인 후보를 분석합니다.
🧠 AIOps — 조치 가이드	LLM과 MCP를 활용해 운영 상태를 분석하고 장애 대응 및 조치 방향을 제공합니다.

4️⃣ GitOps 기반 배포와 공급망 보안

Developer
  -> GitLab
  -> Jenkins: Build / Test / Image Build
  -> Harbor + Trivy: Image Registry / Vulnerability Scan
  -> GitLab GitOps Repository
  -> Argo CD
  -> Kubernetes Services

Harbor에는 온프레미스 이미지를 저장하고 Trivy로 취약점을 검사합니다. AWS 서비스 이미지는 ECR에 저장해 EKS로 배포하며, Argo CD가 GitOps 저장소의 선언 상태와 클러스터 상태를 동기화합니다.

🔧 트러블슈팅 & 성능 개선

1️⃣ HPA의 사후 확장으로 발생한 500 오류 — 오류 완전 제거

문제

급격한 트래픽이 유입됐을 때 실제 트래픽 증가보다 Pod 확장이 늦게 시작됐습니다. 스케일 아웃이 완료될 때까지 요청이 기존 Pod에 집중되면서 500 오류와 높은 응답 지연이 발생했습니다.

원인

기존 HPA는 CPU·메모리 사용률이 임계치를 초과한 이후에 확장을 시작합니다. 이 때문에 갑작스러운 트래픽 변화에 선제적으로 대응하기 어려웠습니다.

해결

과거 트래픽을 학습한 GRU 모델로 향후 RPS를 예측하고, 예측값을 KEDA 외부 메트릭으로 전달했습니다.

KEDA가 실제 트래픽 유입 전에 필요한 Pod를 미리 확보하도록 Predictive Autoscaling 구조를 적용했습니다.

결과

지표	HPA	GRU + KEDA	개선
P95 최고 지연	9.70s	389ms	96.0% 감소
P99 최고 지연	9.94s	1.55s	84.4% 감소
500 오류	발생	미발생	완전 제거

2️⃣ PostgreSQL 읽기·쓰기 병목 — Dropped Iterations 93.1% 감소

문제

PostgreSQL의 읽기와 쓰기 요청이 동일한 경로로 처리되면서 트래픽 증가 시 Primary DB에 부하가 집중됐습니다.

이로 인해 응답 시간이 증가하고 일부 요청이 처리되지 못하는 문제가 발생했습니다.

원인

조회 요청과 데이터 변경 요청이 하나의 DB 인스턴스에 집중됐으며, 읽기 트래픽을 Replica로 분산하지 못했습니다.

해결

읽기와 쓰기 책임을 분리하는 CQRS를 적용하고 Patroni 기반 Primary-Replica 구조와 연계했습니다.

Primary: 데이터 생성·수정·삭제 처리
Replica: 조회 요청 분산 처리
검증 방법: k6로 100 RPS를 10분 동안 발생시켜 개선 전후 비교

결과

지표	적용 전	적용 후	개선
평균 응답 시간	50.48ms	35.60ms	29.5% 감소
P95 응답 시간	68.05ms	51.28ms	24.6% 감소
최대 응답 시간	4.01s	1.38s	65.6% 감소
Dropped Iterations	304건	21건	93.1% 감소

3️⃣ 컨테이너 이미지 비대화와 보안 취약점 — 취약점 100% 제거

문제

실행에 필요하지 않은 빌드 도구와 패키지가 최종 이미지에 포함되어 이미지 용량과 ECR 저장 비용이 증가했습니다.

Harbor 이미지에서는 최대 128개의 취약점이 발견됐으며, ECR 이미지에서도 Critical·High·Medium 취약점이 탐지됐습니다.

원인

빌드 도구와 실행 환경이 하나의 이미지에 포함됨
취약한 런타임 베이스 이미지 사용
실행 JAR 전체가 하나의 레이어로 복사됨
작은 코드 변경에도 큰 애플리케이션 레이어가 다시 생성됨
의존성과 애플리케이션 코드의 Docker 캐시가 분리되지 않음

해결

경량 런타임 베이스 이미지, Multi-stage Build와 Spring Boot Layered JAR를 적용했습니다.

빌드 환경과 실행 환경을 분리하고, 의존성 레이어와 애플리케이션 레이어를 나눠 Docker 캐시 재사용률을 높였습니다.

Harbor 취약점 분석 및 제거

Harbor에 저장된 service-payment 이미지를 Trivy로 스캔해 애플리케이션 의존성과 런타임 패키지의 취약점을 단계적으로 제거했습니다.

단계	이미지 태그	이미지 크기	크기 변화	취약점	제거율
최적화 전	`18a29dc`	138.36MiB	기준	122개	기준
1차 최적화	`aa587b4`	134.94MiB	3.42MiB 감소 (2.47%)	47개	61.48% 제거
최종 최적화	`9e51b49`	119.20MiB	19.16MiB 감소 (13.85%)	0개	100% 제거

분석 및 해결 과정

애플리케이션 의존성 분석
Tomcat Embed, Spring Security, Netty 등 Java 의존성의 취약 버전을 수정 버전으로 갱신했습니다.
런타임 패키지 분석
OpenSSL 등 기존 베이스 이미지에 포함된 OS 패키지 취약점을 분리해 확인했습니다.
이미지 구조 개선
Multi-stage Build와 Spring Boot Layered JAR를 적용해 빌드 도구를 최종 이미지에서 제외했습니다.
경량 런타임 적용
실행에 필요한 구성만 포함한 경량 베이스 이미지로 교체했습니다.
재스캔 검증
최종 태그 9e51b49를 다시 스캔해 취약점 없음 상태를 확인했습니다.

🔍 Trivy 주요 CVE 분석 화면 보기

발표자료의 전체 서비스 종합 지표에서는 이미지별로 최대 128개의 취약점이 탐지됐으며 최종 이미지에서는 모두 0개를 달성했습니다.

위 표의 122개는 첨부 화면에 표시된 service-payment 이미지의 개별 측정값입니다.

Harbor 전체 최적화 성과

지표	적용 전	적용 후	개선
Harbor 이미지 크기	842MB	694MB	17.6% 감소
Harbor 최대 탐지 취약점	128개	0개	100% 제거
이미지 레이어	48개	32개	33.3% 감소
이미지 빌드 시간	3분 41초	1분 21초	63% 단축

ECR 이미지 최적화 전후

최적화 전

최적화 후

비교 항목	최적화 전	최적화 후	분석
이미지 크기	97.11MB	49.01MB	48.10MB 감소 (49.53% 절감)
Critical 취약점	1개	0개	100% 제거
High 취약점	3개	0개	100% 제거
Medium 취약점	3개	0개	100% 제거
전체 취약점	7개	0개	완전 제거
이미지 상태	활성	활성	정상 배포 상태 유지

이미지 용량을 절반 가까이 줄여 ECR 저장 공간과 EKS 노드의 이미지 풀(Pull) 부담을 낮췄습니다. 동시에 Critical·High·Medium 취약점을 모두 제거해 배포 효율과 공급망 보안을 개선했습니다.

4️⃣ Jenkins와 Docker의 중복 빌드 — 전체 파이프라인 42% 단축

문제

Jenkins 빌드 이후 Docker 이미지 생성 과정에서 Gradle 빌드를 다시 수행해 동일한 애플리케이션이 중복 빌드됐습니다.

이로 인해 Docker Build와 전체 CI/CD 파이프라인 시간이 불필요하게 증가했습니다.

원인

Jenkins와 Docker가 각각 독립적으로 애플리케이션 빌드를 수행했으며, 의존성 레이어와 애플리케이션 레이어가 분리되지 않아 Docker 캐시를 효율적으로 활용하지 못했습니다.

해결

Jenkins가 생성한 JAR를 Docker가 패키징만 하도록 파이프라인을 변경했습니다.

Spring Boot Layered JAR 구조를 적용하고 변경 빈도가 낮은 의존성 레이어는 Harbor 캐시를 재사용하도록 구성했습니다.

결과

구간	적용 전	적용 후	개선
Build	32초	9초	71.9% 단축
Docker Build & Push	2분 5초	45초	64% 단축
전체 CI/CD 파이프라인	5분 27초	3분 10초	42% 단축

5️⃣ AIOps LLM의 입력 토큰 낭비 — 입력 토큰 10.17% 감소

문제

질문과 직접 관련이 없는 운영 데이터까지 프롬프트에 누적되면서 입력 토큰 사용량과 P95 응답 시간이 증가했습니다.

동일한 운영 데이터를 반복해서 조회해 LLM 요청마다 불필요한 처리 비용도 발생했습니다.

원인

질문의 목적과 관계없이 로그·메트릭·트레이스 등 많은 운영 데이터를 일괄적으로 프롬프트에 포함했습니다.

반복 조회되는 데이터에 캐시가 적용되지 않아 동일한 조회와 전처리가 계속 수행됐습니다.

해결

프롬프트를 응답 목적 중심으로 재구성하고 필요한 운영 데이터만 선택적으로 전달하도록 개선했습니다.

반복 조회되는 운영 데이터에는 30초 TTL 캐시를 적용했습니다.

결과

지표	최적화 전	최적화 후	개선
평균 응답 시간	3.17s	3.07s	3.15% 감소
요청당 평균 입력 토큰	1.18k	1.06k	10.17% 감소
P95 응답 시간	8.67s	8.17s	5.77% 감소

✅ 테스트 및 품질

Mockito와 JUnit으로 단위 테스트를 작성하고 JaCoCo로 Instruction 및 Branch Coverage를 측정했습니다. 모든 백엔드 모듈에서 두 지표 모두 90% 이상을 달성했습니다.

모듈	Instruction Coverage	Branch Coverage
`service-batch`	92.73%	90.25%
`service-core`	90.16%	90.45%
`service-admin`	90.57%	90.24%
`service-auth`	95.12%	100.00%
`service-catalog`	97.32%	93.75%
`service-payment`	93.79%	92.47%

👥 팀원 소개


류승환	이승준	이동욱	사재헌	양규리
@Federico-15	@HiLeeS	@cuterrabbit	@Zaixian5	@ygreee0320
PM (AIOps & BE)	PL (Observability)	AIOps & Test	모니터링 & 온프레미스	CI/CD & Cloud

팀원별 상세 담당 업무 보기

팀원	담당 업무
류승환	SRE Agent 개발 · SQS 비동기 처리 · 내부 LLM 구축
이승준	하이브리드 클라우드 설계 · 금융 원장·배치 시스템 구축 · Observability 구축
이동욱	AI 예측 모델 개발 · Predictive Autoscaling 구축 · MCP 기반 AIOps 백엔드 구축 · 백엔드 품질 및 배포 안정화
사재헌	관리자 대시보드 API 개발 · DB 이중화 및 HA 구축 · 온프레미스 자원 및 로그 모니터링 구축
양규리	GitOps 기반 CI/CD 파이프라인 구축 · AWS 연동 인프라 구축 · 사용자 서비스 개발

🔗 리포지토리

영역	설명	링크
🏢 Organization	• 콩콩팥팥 프로젝트의 전체 저장소 관리 • 서비스·인프라·GitOps 소스 통합 관리	FISA-Agri-Pay
🎨 Frontend	• React·TypeScript 기반 농민용 사용자 UI • 한도 신청, 농자재 구매, 상환 조회와 사용자 챗봇	front-end
🖥️ Admin Frontend	• React·TypeScript 기반 관리자 UI • 한도 승인, 배송·연체 현황 관리와 관리자 챗봇	front-end-admin
⚙️ Backend	• Spring Boot 기반 MSA 백엔드 • 인증, 상품, 결제, 원장, 상환, 연체와 배치 처리	back-end
📈 AI Prediction Model	• PyTorch·GRU 기반 시계열 트래픽 예측 모델 • 예측 RPS를 KEDA 외부 메트릭으로 제공해 선제적 오토스케일링 지원	ai-prediction-model
🤖 AIOps Backend	• FastAPI·FastMCP 기반 AIOps 서비스 • 운영 데이터 조회, 장애 원인 분석과 조치 가이드 생성	mcp-aiops-backend
🏗️ Infrastructure / IaC	• Terraform 기반 AWS 및 온프레미스 인프라 구성 • 하이브리드 네트워크, Kubernetes와 데이터 계층 관리	infra
🚀 GitOps	• Kubernetes 배포 매니페스트와 환경별 설정 관리 • Argo CD 기반 선언적 배포 및 클러스터 상태 동기화	git-ops