지난 글에서는 금융 이상거래 탐지에서 끝나지 않고 위험 대응, 사건 처리와 AI 운영까지 연결하는 FinGuardOps를 기획한 이유를 정리했습니다.
프로젝트의 주제와 범위를 정한 다음에는 각 구성요소가 무엇을 책임하고, 어떤 데이터의 원본을 어디에서 관리할지 결정해야 했습니다.
금융 업무 상태와 AI 계산을 하나의 애플리케이션에 모두 넣을지, 처음부터 전체 시스템을 마이크로서비스로 분리할지, PostgreSQL·Redis·Kafka는 각각 어떤 역할을 가져야 할지 고민했습니다.
이 과정에서 기술을 많이 사용하는 것보다 금융 업무 정합성, 계산 책임, 데이터 소유권과 장애 경계를 명확히 나누는 것 을 우선했습니다.
금융 업무 상태의 최종 책임은 Spring Boot가 가지고, FastAPI는 분석 결과 계산을 담당하며, PostgreSQL은 영속 업무 데이터의 원본이 되도록 전체 구조를 설계했습니다.
그림 1. 금융 업무, AI 분석, 데이터, 인프라와 Observability의 책임을 계층별로 구분한 FinGuardOps의 목표 시스템 구성
이 글은 특정 날짜의 구현 현황을 정리하는 글이 아니라, FinGuardOps를 기획하면서 정한 목표 아키텍처, 기술별 책임과 Cloud Application Modernization 전략을 소개하는 글입니다. 실제 운영 중인 레거시 시스템을 직접 이전했다고 주장하기보다, 금융 업무 애플리케이션을 컨테이너·CI/CD·Observability·Kubernetes·AWS 기반으로 단계적으로 현대화하는 기준을 설명합니다.
📚 목차
🧭 1. 전체 구조를 설계하며 세운 기준
FinGuardOps의 아키텍처는 사용하고 싶은 기술을 먼저 정한 뒤 기능을 끼워 맞추는 방식으로 설계하지 않았습니다.
먼저 금융 이상거래 탐지와 사건 처리 과정에서 반드시 지켜야 할 원칙을 정하고, 각 원칙을 실현하는 데 적합한 구성요소와 기술을 선택했습니다.
☁️ Modernization은 단순 Cloud 이전이 아니다
애플리케이션을 클라우드에 올리는 것만으로 Modernization이 완성된다고 보지 않았습니다. 실행 환경 표준화, 자동화된 검증과 배포, 관측 가능성, 장애 격리, 서비스별 확장, 데이터 소유권과 운영 비용까지 함께 바꾸는 것을 목표로 구조를 설계했습니다.
🔐 금융 업무 정합성
거래, 탐지 결과, 위험 대응, 사건과 감사 로그가 중복되거나 일부만 반영되어서는 안 됩니다.
- 중복 거래와 중복 사건 방지
- 허용된 상태 전이만 수행
- 연관 업무 데이터의 함께 Commit 또는 Rollback
- 최종 결과와 감사 이력의 일관성 유지
🧠 계산과 업무 결정의 분리
Rule·ML과 생성형 AI는 분석 결과를 계산하지만 금융 업무 상태를 직접 확정하지 않습니다.
- FastAPI는 위험 점수와 탐지 근거 계산
- Spring Boot는 분석 결과 계약 검증
- 승인된 위험 대응 정책 적용
- 거래·사건 상태의 최종 변경
🗄️ 명확한 데이터 소유권
각 저장 기술의 역할을 분리하고, 업무 데이터의 원본이 여러 곳에 흩어지지 않도록 설계했습니다.
- PostgreSQL은 영속 업무 데이터 원본
- Redis는 재생성 가능한 캐시와 집계
- Kafka는 비동기 이벤트 전달
- Observability는 기술 상태 관측
🚨 장애 범위의 분리
의존성마다 시스템에 미치는 영향이 다르므로 모든 장애를 하나의 실패로 처리하지 않습니다.
- DB 장애와 분석 서비스 장애 구분
- 캐시 장애와 업무 데이터 유실 구분
- LLM 실패와 Rule·ML 판단 실패 구분
- 관측 시스템 실패와 금융 업무 실패 구분
📈 핵심 업무부터 단계적으로 확장
Docker, Kafka, Kubernetes와 AWS를 사용하는 사실보다 각 기술이 어떤 문제를 해결하기 위해 필요한지를 설명할 수 있어야 한다고 판단했습니다.
핵심 거래·탐지·사건 흐름
→ PostgreSQL 기반 업무 정합성
→ Docker Compose 기반 통합 실행
→ Observability
→ Redis·Kafka 기반 확장
→ Kubernetes 운영
→ AWS 클라우드 배포
처음부터 모든 기술을 동시에 적용하면 금융 업무 로직보다 인프라 설정과 분산 시스템 문제가 프로젝트의 중심이 될 수 있습니다.
따라서 핵심 거래·탐지·사건 흐름을 먼저 설계하고, 그 위에 로컬 통합 환경, 관측, 비동기 처리, 컨테이너 오케스트레이션과 클라우드 운영을 단계적으로 확장하는 방향으로 구상했습니다.
🏗️ 2. FinGuardOps의 전체 시스템 흐름
FinGuardOps는 FDS 분석 담당자와 플랫폼·클라우드 운영자가 React 관리자 화면을 통해 금융 업무와 플랫폼 운영 정보를 확인하는 구조로 구상했습니다.
Spring Boot는 금융 업무 처리의 중심에서 PostgreSQL, External Risk와 FastAPI AI Service를 조정합니다.
FDS 분석 담당자 / 플랫폼·클라우드 운영자
↓
React + TypeScript
↓ REST API
Spring Boot Modular Monolith
├─ PostgreSQL
├─ External Risk Service
├─ Redis
├─ Kafka
└─ FastAPI AI Service
├─ Rule Engine
├─ ML Inference
└─ AI Report·Fallback
Spring Boot / FastAPI / Data / Messaging
↓
Metrics · Logs · Traces
↓
Prometheus · Grafana · Loki · OpenTelemetry
서비스 실행·배포 환경
→ Docker Compose · Kubernetes · AWS · GitHub Actions🔄 거래 요청의 기본 처리 흐름
핵심 거래 처리 흐름은 다음과 같이 설계했습니다.
- 거래 요청과 Idempotency-Key를 검증합니다.
- 동일 요청을 식별하기 위한 Request Fingerprint를 계산합니다.
- 동일 멱등 요청 중 하나만 실제 업무 처리를 수행하도록 제어합니다.
- 금융 거래를 PostgreSQL에 저장하고 초기 상태를 확정합니다.
- External Risk Service에서 외부 위험정보를 조회합니다.
- 거래·행동 이벤트·RuleVersion을 분석 Snapshot으로 구성합니다.
- FastAPI에 Rule·ML 분석을 요청합니다.
- Spring Boot가 분석 결과의 버전과 완전성을 검증합니다.
- 위험도별 대응을 적용하고 필요한 사건을 생성합니다.
- 최종 결과와 감사 이력을 저장하고 중복 요청에는 동일한 응답을 재생합니다.
External Risk와 FastAPI 호출은 긴 DB 트랜잭션 안에서 실행하지 않는 방향으로 설계했습니다.
외부 응답을 기다리는 동안 거래 잠금과 DB Connection을 계속 점유하지 않도록 짧은 영속화 트랜잭션과 외부 호출 경계를 분리합니다.
☕ 3. Backend — Spring Boot Modular Monolith
Spring Boot는 FinGuardOps에서 요청을 전달하기만 하는 단순 API Gateway가 아닙니다.
거래·탐지·위험 대응·사건·감사로 이어지는 금융 업무의 최종 책임 을 담당하도록 설계했습니다.
☕ Spring Boot가 담당할 책임
- 거래·행동 이벤트 요청 검증
- 거래 요청 멱등성 처리
- 거래와 탐지 결과 상태 전이
- External Risk 조회 오케스트레이션
- FastAPI 분석 요청과 Trace 전달
- 분석 응답의 요청 연결·버전·완전성 검증
- 위험 등급별 대응 정책 적용
- HIGH·CRITICAL 거래의 사건 생성과 연결
- 상태 변경과 의사결정의 감사 로그 기록
- 최종 응답 Snapshot 저장과 멱등 재생
- AI 리포트 상태와 사용량·토큰·비용 영속화
🧩 왜 Modular Monolith로 시작하는가
거래, 탐지 결과, 위험 대응, 사건과 감사 로그는 서로 완전히 독립적인 데이터가 아닙니다.
고위험 거래를 추가 인증 상태로 전환하면서 사건을 생성하고 감사 로그를 남겨야 한다면, 이러한 변경은 함께 성공하거나 함께 Rollback되어야 합니다.
이를 처음부터 여러 서비스로 분리하면 다음 문제를 핵심 업무 구현과 동시에 해결해야 합니다.
- 분산 트랜잭션과 최종 일관성
- 중복 이벤트와 Consumer 멱등성
- 서비스 간 네트워크 실패
- 부분 성공에 대한 보상 처리
- 독립 배포와 장애 대응 체계
- 서비스별 데이터 소유권 분리
초기 구조에서는 이 복잡성보다 금융 업무 흐름의 완성도를 우선하기 위해 하나의 Spring Boot 애플리케이션 안에서 논리적인 모듈 경계를 유지하는 Modular Monolith를 선택했습니다.
거래 접수·검증·멱등성
사용자 행동 이벤트
분석 요청과 결과 관리
위험도별 대응 정책
사건 생성·조사·판정
주요 변경 이력
Rule·정책 버전 관리
리포트·사용량·비용
Spring Boot는 FastAPI가 반환한 위험 점수를 그대로 거래 상태에 적용하지 않습니다. 거래 처리 상태, 분석 결과 버전, 탐지 근거와 승인된 대응 정책을 검증한 뒤 금융 업무 상태를 변경합니다.
🐍 4. AI Service — FastAPI
FastAPI AI Service는 금융 업무 상태를 직접 변경하는 서비스가 아니라 분석 결과를 계산하는 독립 서비스로 구성합니다.
Python의 데이터 처리와 AI 생태계를 활용하면서도 AI 코드 변경이 금융 업무 상태를 직접 변경하지 못하도록 Spring Boot와 별도 프로세스로 분리했습니다.
✅ FastAPI의 책임
- Feature 계산
- Rule 실행
- ML 추론
- 위험 점수와 위험 등급 계산
- Reason Code와 Evidence 생성
- 모델 라우팅
- AI 사건 리포트 생성
- Rule·ML 기반 템플릿 fallback
🚫 FastAPI가 하지 않는 일
- 거래 상태 직접 변경
- 사건 직접 생성
- 사건 상태 직접 변경
- 최종 이상거래 판정
- 거래 승인·보류·추가 인증 결정
- Spring Boot 업무 데이터 직접 영속화
- Rule 활성 상태와 버전 원본 변경
⚙️ 초기 Rule 분석 범위
- 고액 거래와 주요 행동 이벤트를 분석하는 초기 Rule 집합
- RuleVersion 기반 실행 계획
- 같은 입력에 같은 결과를 반환하는 결정적 Rule 평가
- 가중치와 그룹 상한을 이용한 위험 점수 계산
- Reason Code와 설명 가능한 Evidence 생성
- Spring Boot와 통신하기 위한 내부 분석 API
- Trace와 요청·응답 계약 검증
🧠 확장할 AI 분석 범위
- 복합 패턴을 보완하는 ML 모델 추론과 평가
- HIGH·CRITICAL 사건 중심 생성형 AI 리포트
- LLM Provider 연동
- 사건 복잡도 기반 모델 라우팅
- LLM 실패 시 Rule·ML 기반 템플릿 fallback
- 입력·출력 토큰과 호출 비용 측정
- 리포트 형식과 품질 검증
AI Service는 설명 가능하고 테스트하기 쉬운 Rule 분석을 첫 단계로 두고, 이후 ML과 생성형 AI 리포트를 추가하는 방향으로 구성합니다.
생성형 AI는 위험 판단을 대신하는 것이 아니라 고위험 사건을 검토하는 담당자의 이해를 돕는 보조 수단으로 사용합니다.
🖥️ 5. Frontend — React와 TypeScript
Frontend는 FinGuardOps의 두 사용자 역할에 맞춰 FDS 업무 화면과 플랫폼 운영 화면으로 구분합니다.
🕵️ FDS 분석 담당자 화면
- 거래 모니터링과 위험 거래 필터링
- 위험 점수와 위험 등급 확인
- Rule·ML 탐지 Evidence
- 사용자 행동 타임라인
- 사건 대기열과 사건 상세
- 조사 메모와 담당자 관리
- 정상·오탐·이상거래 판정
- 감사 이력과 AI 사건 리포트
🛠️ 플랫폼·클라우드 운영자 화면
- 서비스 Health와 배포 버전
- 오류율·처리량과 지연시간 요약
- External Risk·Rule·ML·LLM 상태
- AI 모델별 호출량과 비용
- 캐시 적중률과 fallback 비율
- 장애·대응·복구 이력
- 배포 이력과 업무 영향 요약
📊 React와 Grafana의 역할 구분
🖥️ React 관리자 화면
- 거래와 사건 업무 상태
- 조사 메모와 최종 판정
- Rule과 운영 정책
- AI 비용·장애·배포 이력 요약
📈 Grafana
- 서비스별 응답시간
- 오류율과 처리량
- DB Connection Pool
- Kafka Consumer Lag
- 런타임·인프라 시계열 지표
React는 금융 업무와 운영 이력을 처리하는 제품 화면을 담당하고, Grafana는 기술 지표를 시계열로 분석하는 관측 화면을 담당합니다. 동일한 대시보드를 두 영역에 중복 구현하지 않는 것이 원칙입니다.
🗄️ 6. Data와 External Service
FinGuardOps에서는 PostgreSQL, Redis와 Kafka를 모두 같은 종류의 데이터 저장소로 취급하지 않습니다.
영속 업무 데이터의 원본, 재생성 가능한 캐시, 비동기 이벤트 전달 책임을 명확하게 구분했습니다.
🐘 PostgreSQL — 영속 업무 데이터의 원본
PostgreSQL은 거래·탐지·사건과 감사 데이터를 보관하는 FinGuardOps의 정합성 기준으로 사용합니다.
- 금융 거래와 행동 이벤트
- 멱등성 Record와 응답 Snapshot
- 탐지 결과와 Evidence
- Rule 정의와 RuleVersion
- 사건과 거래 연결
- 조사 메모와 Append-only 감사 로그
- AI 리포트와 사용량·토큰·비용
🌐 External Risk — 외부 위험정보 경계
실제 금융권 위험정보 API와 데이터를 사용할 수 없는 제약을 보완하기 위해 위험계좌·위험 기기·위험 IP 등의 정보를 제공하는 외부 의존성을 별도 경계로 둡니다.
- 로컬·테스트용 결정적 Mock
- 실제 연동 구조를 재현하는 HTTP Provider
- Port와 Adapter 기반 외부 연동 분리
- Timeout·Unavailable·Invalid Response 시나리오
- 외부 위험정보 실패와 Rule 분석 실패의 분리
🔴 Redis — 재생성 가능한 캐시와 집계
Redis는 거래와 사건의 원본 저장소로 사용하지 않습니다. PostgreSQL의 원본에서 다시 계산하거나 조회할 수 있는 데이터만 보관합니다.
- 동일 사건·동일 분석 조건의 정확 일치 AI 리포트 캐시
- 재생성 가능한 운영 집계
- 필요성과 장애 정책이 확정되면 External Risk 캐시 검토
caseId
+ detectionResultVersion
+ promptVersion
+ modelVersionReason Code가 같거나 내용이 유사하다는 이유만으로 다른 사건의 AI 리포트를 재사용하지 않습니다.
⚫ Kafka — 비동기 이벤트 전달
Kafka는 핵심 동기 금융 판단을 대신하는 것이 아니라, 사용자 응답 경로에서 분리해야 하는 작업을 비동기로 전달하기 위해 사용합니다.
- AI 사건 리포트 생성 요청
- 사건 관련 도메인 이벤트
- 운영 통계 집계 이벤트
- 장애와 배포 관련 운영 이벤트
Kafka를 도입할 때는 Producer와 Consumer만 구현하는 데서 끝내지 않고 Consumer 멱등성, 중복 이벤트, 순서, Consumer Lag, 재처리와 DLQ를 함께 검증합니다.
PostgreSQL은 업무 데이터의 원본이고, Redis는 재생성 가능한 캐시이며, Kafka는 비동기 이벤트 전달 수단입니다. 세 기술은 서로 대체 관계가 아닙니다.
☁️ 7. Infra·DevOps·Cloud와 Observability
FinGuardOps에서 인프라는 애플리케이션을 마지막에 배포하기 위한 부가 요소가 아닙니다.
장애 복구, 반복 가능한 실행 환경, 배포 안정성, 서비스 확장과 운영 상태 관측을 검증하기 위한 프로젝트의 핵심 영역으로 포함했습니다.
애플리케이션 실행 → 컨테이너 통합 → 자동화된 검증 → 오케스트레이션 → 클라우드 운영 → 장애·성능·비용 검증
🐳 Docker Compose
Spring Boot, FastAPI, PostgreSQL, Redis, Kafka와 Observability 구성요소를 동일한 로컬 환경에서 반복 실행합니다.
- 개발·테스트 환경 재현
- 서비스 간 네트워크 구성
- 환경 변수와 Volume 관리
- Health Check와 시작 순서 검증
☸️ Kubernetes
컨테이너 기반 구성을 서비스 단위로 배포하고 복구·확장·Rolling Update를 검증합니다.
- Deployment와 Service 구성
- Replica와 장애 복구
- Rolling Update와 Rollback
- Config·Secret 분리
- Resource Request·Limit
☁️ AWS
로컬과 Kubernetes 환경에서 검증한 구조를 클라우드 운영 환경으로 확장합니다.
- 애플리케이션과 데이터 계층 배포
- 네트워크·보안·접근 경계
- 관리형 데이터베이스와 저장소 검토
- 클라우드 로그·메트릭 연계
- 배포 전후 운영 상태 검증
🔄 GitHub Actions
Issue와 Pull Request 흐름에 자동 테스트, 이미지 생성과 배포 검증을 연결합니다.
- Backend 단위·통합 테스트
- AI Service lint·format·pytest
- Container Image Build와 보안 검사
- Image Registry Push
- Kubernetes 배포와 이력 관리
- 승인된 Issue를 기준으로 한 AI Agent 작업
- 테스트·리뷰·사용자 승인 Human Gate
📊 Observability
거래 요청이 어느 단계에서 지연되거나 실패했는지 확인하기 위해 메트릭, 로그와 분산 추적을 서로 다른 관측 신호로 사용합니다.
API·Rule·ML·LLM 지연시간, 오류율, 처리량과 비용 메트릭 수집
기술 시계열 대시보드, 장애 분석과 배포 전후 비교
Spring Boot·FastAPI·인프라의 구조화 로그 수집과 검색
거래 요청이 여러 구성요소를 거치는 흐름과 지연 구간 추적
인프라와 Observability는 단순히 서비스가 실행된다는 사실을 보여주기 위한 것이 아닙니다.
Timeout, DB Pool 고갈, Kafka Consumer 중단, LLM 장애와 비용 급증 같은 시나리오를 주입하고, 어떤 지표로 탐지했는지와 어떻게 복구했는지를 검증하기 위해 사용합니다.
🔗 8. 시스템 사이의 책임과 장애 경계
FinGuardOps에서 가장 중요하게 정한 원칙은 계산, 업무 결정, 원본 저장, 캐시와 관측 책임을 섞지 않는 것입니다.
계산 책임 ≠ 업무 결정 책임 ≠ 데이터 원본 ≠ 캐시 ≠ 기술 관측
검증·상태 전이·위험 대응·사건·감사·영속화
Rule·ML·점수·Reason Code·Evidence·AI 리포트 계산
거래·탐지·사건·감사 업무 데이터 원본
정확 일치 캐시와 재생성 가능한 집계
비동기 사건·리포트·통계·운영 이벤트
분석 담당자와 운영자를 위한 업무 화면
지연시간·오류율·처리량·로그·Trace·비용 관측
실행·배포·복구·확장과 운영 환경 제공
🚨 장애를 정상 결과로 바꾸지 않는 원칙
External Risk 실패 ≠ 위험정보 없음
FastAPI 실패 ≠ 정상 거래
Redis 실패 ≠ 업무 데이터 유실
LLM 실패 ≠ Rule·ML 판단 실패
메트릭 기록 실패 ≠ 금융 업무 실패
External Risk와 FastAPI가 실패하면 이를 정상 또는 저위험 결과로 바꾸지 않습니다. 오류가 발생한 단계와 종류를 보존하고 해당 업무 경계에 맞는 실패 상태로 처리합니다.
반대로 Redis와 LLM은 핵심 금융 업무 데이터의 원본이 아닙니다. 캐시나 AI 리포트가 실패해도 이미 계산된 Rule·ML 판단과 확정된 거래·사건 결과를 변경하지 않습니다.
🧩 9. 처음부터 전체 MSA로 구성하지 않은 이유
프로젝트 초기부터 모든 기능을 마이크로서비스로 분리하면 기술적으로 더 복잡한 구조를 보여줄 수는 있습니다.
하지만 거래, 탐지 결과, 위험 대응, 사건과 감사 로그는 강한 업무 정합성을 요구합니다.
이를 여러 서비스와 데이터베이스로 분리하면 핵심 금융 업무를 구현하기 전에 분산 트랜잭션과 이벤트 일관성 문제부터 해결해야 합니다.
⚠️ 처음부터 전체 MSA일 때 생기는 문제
- 분산 트랜잭션
- 서비스 간 부분 실패
- 이벤트 중복과 순서
- 보상 트랜잭션
- 서비스별 배포·관측 환경
- 데이터 소유권 조정
✅ 초기 아키텍처
- Spring Boot Modular Monolith
- 독립 FastAPI AI Service
- PostgreSQL 업무 데이터 원본
- External Risk Mock·HTTP 경계
- 로컬 트랜잭션 기반 정합성 관리
- 명확하게 구분된 장애 경계
🔀 서비스를 분리할 기준
다음 조건이 실제로 발생했을 때 특정 논리 모듈을 별도 서비스로 분리합니다.
- 독립 배포 요구가 반복적으로 발생하는가
- 특정 모듈만 독립적으로 확장해야 하는가
- 서비스 분리로 얻는 장애 격리 효과가 명확한가
- 데이터 소유권을 독립적으로 분리할 수 있는가
- 독립 팀이 해당 영역을 운영하는가
- 분산 트랜잭션과 운영 비용을 감수할 근거가 있는가
MSA를 고려하지 않은 것이 아니라, 핵심 금융 업무 정합성을 먼저 검증한 뒤 분리가 필요한 영역만 단계적으로 확장하기로 한 것입니다.
🗺️ 10. Cloud Application Modernization 로드맵과 검증 방향
FinGuardOps는 전체 목표 구조를 한 번에 구현하거나 단순히 클라우드로 옮기는 방식보다, 각 단계에서 해결해야 할 애플리케이션과 운영 문제를 정의하고 검증한 뒤 다음 영역으로 확장하는 방식으로 진행합니다.
1단계. 금융 업무 기반
- 거래와 행동 이벤트
- 상태 전이와 멱등성
- Rule 기반 탐지
- 위험도별 대응
- 사건 생성과 감사 로그
- PostgreSQL 트랜잭션 검증
2단계. 서비스 연동
- Spring Boot와 FastAPI 연동
- External Risk Service
- RuleVersion과 Evidence
- Timeout과 오류 계약
- 서비스 간 Trace 전달
- 장애 전파와 복구 경계
3단계. 로컬 운영 환경
- Docker와 Docker Compose
- 서비스 Health Check
- Prometheus와 Grafana
- Loki와 OpenTelemetry
- React 관리자 화면
- CI 자동화
4단계. 비동기·AI 운영
- Redis 정확 일치 캐시
- Kafka 비동기 이벤트
- ML 복합 패턴 분석
- 생성형 AI 사건 리포트
- 모델 라우팅과 fallback
- AI 토큰·비용·품질 측정
5단계. Cloud Native 확장
- Container Image Pipeline
- Kubernetes 배포와 복구
- AWS 클라우드 환경
- Rolling Update와 Rollback
- Config·Secret·리소스 관리
- 클라우드 E2E 검증
6단계. 장애·비용 실험
- External Service Timeout
- Redis·Kafka·DB 장애
- Consumer Lag과 재처리
- LLM 오류와 fallback
- 배포 전후 성능 비교
- AI FinOps 실험과 회고
🤖 전 단계에 공통으로 적용하는 AI-assisted Delivery
Sprint Goal과 GitHub Issue
→ ADR·API·DB 계약 확인
→ AI Agent 구현·테스트·문서 초안
→ 자동 테스트와 정적 검사
→ 독립 Review
→ 사용자 승인
→ Pull Request merge
→ 배포와 운영 검증AI Agent는 승인된 작업 범위 안에서 초안을 만들고 반복 작업을 지원하지만, API·DB·아키텍처 변경, Secret 접근, Production 배포와 최종 Merge를 임의로 수행하지 못하도록 Human-in-the-loop Gate를 유지합니다.
🧪 각 단계에서 확인할 기준
- 정상 흐름뿐 아니라 경계값과 실패 흐름을 테스트했는가
- 중복 요청과 동시성 충돌을 검증했는가
- 외부 장애가 어느 업무까지 영향을 주는지 구분했는가
- 로그·메트릭·트레이스로 장애 위치를 확인할 수 있는가
- 배포 후 Health와 핵심 업무 흐름을 다시 검증했는가
- AI의 호출량·토큰·지연시간·비용을 실제로 측정했는가
- 측정하지 않은 향상이나 절감률을 성과로 표현하지 않았는가
이 로드맵의 핵심은 기술을 정해진 순서로 단순히 추가하는 것이 아닙니다.
앞 단계의 업무와 운영 문제를 충분히 검증한 뒤, 다음 기술이 해결해야 할 필요를 명확하게 만든 상태에서 확장하는 것입니다.
📘 11. 마치며: 다음은 상태 전이와 멱등성
FinGuardOps의 전체 구조는 다양한 기술을 많이 사용하는 것을 목표로 설계한 구조가 아닙니다.
금융 업무 정합성, 사용자 화면, 분석 계산, 데이터 원본, 캐시, 비동기 처리, 실행·배포 환경과 기술 관측의 책임을 나누고 각 책임에 적합한 기술을 배치한 구조입니다.
이를 통해 Java·Spring Boot와 React 기반의 업무 애플리케이션, FastAPI 기반 AI Service, Cloud Native 운영 환경, 그리고 생성형 AI·AI Agent를 통제 가능한 개발 프로세스에 적용하는 방식을 하나의 Modernization 흐름으로 연결하고자 했습니다.
FinGuardOps의 핵심 책임 분리
Spring Boot
→ 금융 업무 상태와 영속화
FastAPI
→ Rule·ML·AI 분석 계산
PostgreSQL
→ 영속 업무 데이터 원본
Redis
→ 재생성 가능한 캐시
Kafka
→ 비동기 이벤트 전달
Docker·Kubernetes·AWS
→ 실행·배포·복구·확장 환경
Observability
→ 장애·성능·비용 관측
전체 구성요소의 역할을 나눈 뒤에는 거래와 사건이 어떤 상태를 가지고, 어떤 조건에서 다음 상태로 이동할 수 있는지 정의해야 했습니다.
특히 동일한 요청이 반복되었을 때 중복 거래와 중복 사건을 방지하고, 처리 결과를 안전하게 재생하기 위한 멱등성 설계가 필요했습니다.
📘 다음 글
[FinGuardOps #3] 재시도와 장애에도 안전한 거래·사건 상태 전이와 멱등성 설계
거래와 사건의 상태를 어떻게 분리하고, Idempotency-Key·Request Fingerprint·Response Snapshot으로 중복 요청을 어떻게 통제할 것인지 정리합니다.
'FinGuardOps > Project' 카테고리의 다른 글
| [FinGuardOps #5] 중복과 잘못된 입력을 막는 거래·행동 이벤트 API와 Validation 설계 (0) | 2026.09.05 |
|---|---|
| [FinGuardOps #4] 금융 업무 정합성을 지키는 ERD·PostgreSQL·Flyway 설계 (0) | 2026.08.31 |
| [FinGuardOps #3] 재시도와 장애에도 안전한 거래·사건 상태 전이와 멱등성 설계 (0) | 2026.08.31 |
| [FinGuardOps #1] 금융 이상거래 탐지를 넘어 FraudOps 플랫폼을 기획한 이유 (0) | 2026.08.30 |
