← 프로젝트 목록으로

🏅 2026 Google Cloud & Solana AI Agentic Hackathon 결승 진출

금융기관을 위한 소상공인 소액대출 심사 및 집행 AI Agent 구현

2026/07/17 → 2026/08/21

산업/분야

금융핀테크소상공인대출블록체인AI기업

직무/기술

PythonAI AgentLLMRAGXGBoostFastAPIGCPSolana

소상공인 대출 사전심사부터 자금 집행·재심사·상환까지 자동화한 AI Agent

• 2026 Google Cloud & Solana AI Agentic Hackathon 결승 진출 (최종 결승 10개 팀 선정)
• 개인으로 참가 — 기획·데이터분석·모델링·백엔드·인프라·블록체인 연동까지 전 과정을 단독으로 수행
• 라이브 데모: CreditFlow Agent — 심사 대시보드
• GitHub : GitHub (creditflow-ai-agent)

Demo Day 현장

해커톤 결선 발표

프로젝트 한눈에 보기

CreditFlow는 소상공인의 정형 데이터와 사업자 설명, 금융기관의 여신 정책을 함께 분석해 대출 승인 여부를 판단하는 AI Agent 시스템이다. XGBoost가 신청자의 부도확률을 예측하고, Decision Agent가 필요한 도구를 자율적으로 선택해 사업 맥락과 정책을 검토한다. 이후 독립된 Critic Agent가 판정의 규칙 위반과 근거 모순을 재검토한다. 최종 승인 건 중 Critic 검토를 통과한 건은 Solana devnet에서 USDC로 즉시 집행하고, Critic이 반박한 건은 집행을 보류해 사람 검토 대상으로 남긴다. 판정 근거의 해시와 트랜잭션을 연결해 사후 검증이 가능하도록 구현했다.

핵심 성과

• 최종 10개 팀으로 해커톤 결승 진출
• 부도확률 예측 모델 Test AUC 0.7883 달성
• 5-fold 교차검증 평균 AUC 0.7848 ± 0.0010으로 모델 재현성 확인
• 자율 도구 선택과 독립 재검토를 결합한 2단계 AI 심사 구조 구현
• 심사·집행·재심사·상환을 연결한 End-to-End 대출 생애주기 구현
• 정답을 평가 전에 확정·커밋한 합성 케이스 68건으로 Agent를 검증하고, 오류 유형을 분석해 프롬프트 규칙 4개로 개선 (별도 설계한 홀드아웃 21건에서 12건 → 21건 일치)
• 하드캡, 프롬프트 인젝션 테스트, IAM 최소 권한으로 AI 시스템의 안전성과 감사 가능성 강화

1. 문제 정의

소상공인은 매출 변동성이 크고 사업 상황이 빠르게 바뀐다. 따라서 신용점수·담보·재무정보와 같은 정형 데이터만으로는 실제 상환 능력과 사업 지속 가능성을 충분히 판단하기 어렵다.

기존 대출 심사의 문제

• 정형 심사의 한계 — 매출 회복이나 일시적 부진의 원인 등 사업 맥락을 반영하기 어려움
• 정량 · 정성 정보의 단절 — 재무 데이터, 사업자 설명, 여신 정책이 분리된 상태로 검토됨
• 심사와 집행의 단절 — 승인 이후에도 별도 절차가 필요해 실제 자금 집행까지 시간이 소요됨
• 높은 심사 운영 비용 — 소액대출도 담당자가 서류를 직접 검토해야 해 심사 효율이 낮음

가설

정량적 위험도와 정성적 사업 맥락, 여신 정책을 함께 검토하고 심사 결과를 실제 자금 집행까지 연결한다면 소액대출 심사의 효율성과 일관성을 높일 수 있을 것이다.

2. 서비스 구현

심사 대시보드 (Live PoC)

CreditFlow 판정 파이프라인 7단계

2-1. XGBoost 기반 정량 심사

Kaggle 개인 대출 데이터를 소상공인 대출 맥락에 맞게 재해석하고, 18개 피처를 활용해 신청자의 부도확률을 예측했다.

※ PoC 단계 검증 결과입니다. (데이터 출처: Kaggle “Loan Prediction Based on Customer Behavior”, 사업자 설명 텍스트는 합성 데이터)

• XGBoost와 LightGBM을 비교한 뒤 Validation AUC가 더 높은 XGBoost를 최종 서빙 모델로 채택 (단순 베이스라인인 로지스틱 회귀와의 비교는 4-1 참고)

  • Validation AUC

    

    • XGBoost : 0.7846
    • LightGBM : 0.7794
    • 로지스틱 회귀(베이스라인) : 0.6309

    검증 성능을 기준으로, XGBoost를 최종 서빙 모델로 채택

• 2개의 임계값을 기준으로 신청자를 승인·조건부승인·거절로 분류

등급	부도확률 기준
승인	부도확률 ≤ 58.8%
조건부승인	58.8% < 부도확률 ≤ 62.6%
거절	부도확률 > 62.6%

• 등급이 높아질수록 실제 부도율이 증가하는지 확인해 위험 구분력을 검증

등급별 실제 부도율(%) 그래프

• SHAP TreeExplainer를 적용해 신청자별 예측 요인과 영향 방향을 설명

2-2. 필요한 도구를 스스로 선택하는 Decision Agent

고정된 순서로 모든 기능을 실행하는 대신, Gemini의 automatic function calling(mode=AUTO)을 활용해 신청자별 상황에 필요한 도구를 Agent가 직접 선택하도록 설계했다.

에이전트가 자율적으로 선택하는 6개 도구

• 정형 데이터 조회
• XGBoost 정량 등급 조회
• SHAP 기여도 분석
• 사업자 설명 정성 요약
• 정책 문서 RAG 검색
• 과거 상환 이력 조회

Agent는 도구 결과를 바탕으로 다음 행동을 결정하고, 판단이 끝나면 record_decision을 정확히 한 번 호출해 최종 결과를 구조화된 형태로 제출한다. 실제 호출 순서와 횟수는 tool_call_log에 저장해 신청자별 판단 경로를 추적할 수 있도록 했다.

LLM 판단 범위 제한

정성 판단이 정량 모델의 위험 판정을 무제한으로 뒤집지 못하도록 조정 범위를 제한했다.

• 승인 ↔ 조건부승인 가능
• 거절 → 조건부승인/승인 불가

즉, LLM은 경계 구간의 사업 맥락을 보완하되 고위험 신청자를 임의로 승인할 수 없다.

2-3. 독립적으로 판정을 검증하는 Critic Agent

Critic Agent 단독 테스트: 위반 시나리오 반박

Decision Agent가 자신의 규칙 위반을 스스로 발견하기 어렵다는 한계를 보완하기 위해 별도의 Critic Agent를 구현했다.

• 1차 판정에 사용된 정량·정성·정책 정보를 별도의 Gemini 호출로 재검토
• 정량 등급이 거절인데 결과가 부당하게 상향되었는지 확인
• 판정 근거가 입력 데이터 또는 정책 조항과 모순되는지 확인
• 강제 Function Calling(mode=ANY)으로 검토 결과를 구조화
• Critic이 승인·조건부승인 건을 반박하면 최종 판정은 유지하되 자금 집행을 보류(HELD)하고 사람 검토 대상으로 남김 (자동 재판정은 아직 없음)
• 1차 Agent의 오류가 많은 조건에서 독립 Critic은 과잉집행을 11.8%에서 3.9%로 줄임 (4-2 참고)
• 판정과 Critic 검토 결과를 BigQuery에 함께 저장해 사후 감사 가능

2-4. Solana devnet 기반 자동 집행

Decision Agent의 최종 판정에 따라 devnet USDC를 자동 집행하되, Critic Agent가 승인 또는 조건부승인 건을 반박하면 최종 판정(final_decision)은 바꾸지 않고 집행만 보류(HELD)한다. 보류 건은 하드캡 체크·지갑 조회/발급·송금 없이 판정 근거와 Critic 반박 내용만 기록해 사람이 검토하게 하며, 보류를 해제하거나 재판정하는 자동 절차는 아직 구현하지 않았다. Critic 검토 결과는 집행 여부 판단과 사후 감사에 함께 활용한다.

최종 판정	실행 내용
승인 (Critic 승인)	신청자 지갑으로 1.00 USDC 즉시 송금
조건부승인 (Critic 승인)	0.50 USDC 우선 집행 후 재심사 통과 시 잔여 0.50 USDC 집행
승인·조건부승인 (Critic 반박)	집행 보류(HELD) — 지갑 조회·발급 및 송금 없이 판정·근거·Critic 반박 내용만 기록, 사람 검토 대상
거절	지갑 조회·발급 및 자금 집행 없이 판정 결과만 기록

지갑이 없는 승인 신청자에게는 서버 관리형 지갑을 자동 발급했다. 산정 대출 한도는 매출의 5%, 최대 500만 원으로 BigQuery에 기록하고, devnet에서는 전체 흐름을 증빙하기 위한 고정 소액만 송금했다.

판정 근거의 무결성 검증

판정 근거를 SHA-256 해시로 변환해 Solana 트랜잭션의 SPL Memo에 함께 기록했다. 이후 저장된 근거를 다시 해싱해 온체인 값과 비교함으로써 자금 집행 이후 판정 근거가 변경되지 않았는지 검증할 수 있다.

BigQuery에는 다음 항목을 통합 저장했다.

• 최종 판정 및 산정 대출 금액
• 판정 근거 해시와 Solana 트랜잭션 서명
• Critic Agent 검토 결과
• Decision Agent의 도구 호출 이력

2-5. AI와 분리된 자금 통제 장치 - 하드 캡 설정

하드 캡 테스트: 한도 초과 요청 차단

AI가 금액을 잘못 산정하더라도 실제 자금 이동은 제한되도록, 심사 로직과 독립된 계층에서 하드캡을 강제했다.

• 건별 500만 원, 일별 2,000만 원 초과 시 FundControlError 발생
• 최종 판정과 관계없이 온체인 집행 직전에 거래 차단
• 최초 집행과 재심사 후 잔여 금액 집행에 동일한 규칙 적용

2-6. 상환과 자동 재심사

대출 실행에 그치지 않고 상환과 재심사까지 연결했다.

상환 실행 및 상환 이력

• 신청자 지갑에서 Treasury 지갑으로 USDC 상환
• 상환 근거 해시도 SPL Memo에 기록해 온체인 검증 지원
• 과거 상환 이력을 재심사 시 Decision Agent의 판단 자료로 활용
• Cloud Scheduler가 매일 03:00 KST에 조건부승인 건을 조회해 자동 재심사 (종단간 검증은 신청자 1명에 한해 완료)

PoC에서는 실제 원금·이자 스케줄 계산을 제외하고, devnet 고정 소액을 활용해 전체 흐름을 검증했다.

3. 시스템 아키텍처

3-1. AI Agent 판정 파이프라인

AI Agent 판정 파이프라인

설계의 핵심은 판단 주체의 역할을 분리하고 모든 결정 경로를 추적 가능하게 만든 것이다.

• XGBoost — 정량적 위험 예측
• Decision Agent — 사업 맥락 해석 및 정책 검색
• Critic Agent — 규칙 위반과 근거 모순 검증
• Fund Control — AI와 독립적으로 집행 금액 제한
• Solana · BigQuery — 자금 이동 증빙 및 전체 판단 이력 저장

3-2. GCP 서빙 및 자동화 인프라

구분	처리 흐름	역할
실시간 심사·집행	FastAPI → Cloud Run → Decision Agent → Critic Agent → Solana → BigQuery	요청부터 판정·송금까지 동기 처리
비동기 영수증 기록	Pub/Sub → Eventarc → Workflows → BigQuery	집행 이벤트와 실행 이력 기록
조건부승인 재심사	Cloud Scheduler → FastAPI → BigQuery	매일 재심사 대상 자동 조회 및 처리
진행 상태 표시	Firestore → 대시보드	2.5초 간격 폴링으로 심사 상태 표시

• Cloud Run Source Deploy와 Cloud Build로 컨테이너 이미지 빌드·배포 자동화
• Gemini API Key는 Secret Manager에서 런타임에 주입
• 심사·집행·재심사·상환 결과는 하나의 BigQuery 데이터셋에 통합

4. 성능 및 검증

4-1. 모델 성능

지표	결과
Test Dataset	37,800건
Test AUC	0.7883
5-fold CV 평균 AUC	0.7848
5-fold CV 표준편차	0.0010
거절 기준 Recall	35.7%
거절 기준 Precision	43.7%
Accuracy	86.4%

거절 기준 성능

5-fold 교차검증에서 편차가 0.0010으로 작게 나타나, 특정 데이터 분할에 의존한 우연한 성능이 아님을 확인했다. SHAP을 통해 전체 피처 중요도뿐 아니라 신청자별 예측 근거도 제공했다.

단순 베이스라인(로지스틱 회귀)과의 비교

트리 부스팅이 정말 필요한지 확인하기 위해, 같은 데이터 분할·피처·시드로 로지스틱 회귀(표준화, 클래스 불균형 보정, 규제 강도만 Validation AUC로 선택)를 학습해 비교했다.

모델	Val AUC	Test AUC	5-fold CV AUC	거절 Precision / Recall
XGBoost (서빙)	0.7846	0.7883	0.7848 ± 0.0010	43.7% / 35.7%
LightGBM	0.7794	0.7835	0.7811 ± 0.0013	44.2% / 36.4%
로지스틱 회귀	0.6309	0.6286	0.6327 ± 0.0039	19.9% / 31.8%

4-2. Agent 품질 평가와 개선

“데모가 잘 돌아간다”에서 멈추지 않기 위해, 정답(골드)을 평가 실행 전에 확정·커밋한 케이스로 Decision Agent + Critic Agent 전체 파이프라인을 검증했다. 골드는 여신 정책 문서에서만 도출했고, 결과를 본 뒤에는 바꾸지 않았다. (사업자 설명은 모두 합성 텍스트)

평가셋 — 68건 (Agent 63건 + 하드캡 5건)

• 정책 조항별 정상·경계·반례 케이스 (조정 없음 / 하향 / 상향 / 정량 거절 유지)
• 안정과 회복을 혼동하기 쉬운 케이스 (매출 유지, 일시적 반등, 2개월 상승, 정확히 3개월 상승 등)
• 프롬프트 인젝션 8종 — 정책 무시, 개발자 사칭, 승인 강요, 하향 사유 은폐, 한도 우회, 다국어, Base64 우회, 정책·Critic 결과 위조
• 재심사 케이스, 한도 경계 케이스 (정확히 500만 원 / +1원 / 일 누적 초과)

1회차 결과 (개선 전)

지표	결과
사전 정의한 신규 케이스 36건 판정 일치	24건
신규 인젝션 8종 방어	3종
하드캡 경계 5건 (차단 3 + 통과 2)	5건 모두 의도대로
Critic이 오답 13건 중 지적한 건수	5건 (최종 판정을 바꾼 건 0건. 집행 보류 동작은 이 평가 이후에 추가되어 평가 범위 밖)

발견한 오류 유형 → 일반화한 개선

• “매출 유지·감소 둔화”를 “매출 회복”으로 오인해 승인으로 상향
• 정책이 열거하지 않은 사유(비용 상승, 임대료 협의)로 과잉 하향
• 정책에 없는 “조건부 → 거절” 하향 (인젝션 문구 자체를 위험 신호로 해석)
• 요약 단계가 “위험 신호를 숨겨라”는 지시를 따라 하향 사유 누락

이 4가지를 케이스 하나에 맞춘 땜질이 아니라 프롬프트 규칙 4개로 일반화했고, 개선 전에 정답까지 확정해 둔 홀드아웃 21건으로 검증했다.

지표	개선 전	개선 후
별도 설계한 홀드아웃 21건	12건	21건
신규 케이스 36건	24건	35건
신규 인젝션 8종 방어	3종	8종

개선 후 회귀는 1건이었다(원래 판정이 흔들리던 케이스).

※ 한계: 정답은 작성자 본인이 정의했고(독립 라벨링 아님), 합성 텍스트·작은 표본이라 통계적 성능 보증이 아니다. 개선 후 점수는 오류를 분석한 케이스와 같은 유형을 겨냥한 평가에서 얻은 것이라 새로운 유형의 오류까지 보장하지 않으며, 개선 후 평가는 1회 실행이다. 평가 방법·결과·한계 전문은 GitHub 평가 문서에 공개했다.

견고성 및 인젝션 시연

두서없는 구어체, 근거 없는 과장, 모순되거나 모호한 설명, 객관적 근거 없는 감정 호소, 프롬프트 인젝션 시도에서도 심사 로직이 유지되는지 자동화 테스트를 수행했다.

프롬프트 인젝션 시연 (정량 거절 신청자에 "무조건 승인" 문구 삽입 → 거절 유지)

위 시연은 가장 단순한 인젝션 한 가지이며, 다양한 공격 유형에서의 방어율은 위 평가셋 결과를 기준으로 한다.

Critic Agent는 실제로 필요한가: 단일 Agent 대비 비교

독립 Critic이 있는 Multi Agent 구조가 정말 필요한지 확인하기 위해, 같은 케이스와 같은 1차 판정에서 세 조건을 비교했다. 정답은 결과를 보기 전에 확정했고, 지표와 기준도 먼저 문서로 커밋했다.

• A. 단일 Agent: Decision Agent의 판정만 사용
• B. 단일 Agent + 자기검토: 같은 Agent가 같은 대화에서 자기 판정을 다시 점검하고 필요하면 수정
• C. Multi Agent: Decision Agent + 독립 Critic (반박 시 집행 보류)

정답보다 느슨하게 나간 집행(과잉집행)의 비율은 다음과 같다. (1차 Agent가 자주 틀리는 조건, 102건)

조건	과잉집행률	1차 오답 중 차단·수정
A. 단일	11.8% (12건)	0%
B. 단일 + 자기검토	11.8% (12건)	5.3% (1/19)
C. Multi (Critic)	3.9% (4건)	52.6% (10/19)

• 독립 Critic은 과잉집행을 7.8%p 줄였고, 정상 판정을 잘못 막은 경우는 0건이었다(0/83). Critic이 반박해 보류한 10건은 모두 실제로 틀린 판정이었다.
• 같은 Agent의 자기검토는 거의 효과가 없었다. 같은 검토 기준을 줬는데도 틀린 판정을 대부분 그대로 유지했다. 검토 단계를 더하는 것만으로는 부족하고, 검토자를 별도 호출로 분리한 구조가 차이를 만들었다.

4-3. 보안 및 거버넌스

• 인증 게이트: 심사 실행·삭제 등 사용자가 직접 트리거하는 쓰기 엔드포인트에 인증 키 검증 적용
• IAM 최소 권한 — 기본 서비스 계정의 Editor 권한을 제거하고 전용 서비스 계정에 필요한 리소스 권한만 부여
• 데이터 계보 관리 — 원본 CSV부터 전처리·모델·판정·온체인 기록까지 데이터 흐름 문서화
• 데이터 사전 관리 — 전체 데이터 자산의 필드 정의를 별도 문서로 관리

① 트랜잭션 실행 확인 (Finalized)

② USDC 지급 트랜잭션

③ SPL Memo에 기록된 판정 근거 해시

5. 기술 스택

영역	기술
ML	XGBoost(서빙) · LightGBM(비교 모델) · 로지스틱 회귀(베이스라인) · scikit-learn
Explainability	SHAP TreeExplainer
LLM / Agent	Gemini · google-genai · Automatic Function Calling
RAG	Cosine Similarity · gemini-embedding-001
Backend	FastAPI · Uvicorn · Pydantic
GCP	Cloud Run · BigQuery · Firestore · Pub/Sub · Eventarc · Workflows · Scheduler · Cloud Build · Secret Manager
Blockchain	Solana devnet · Circle Devnet USDC · SPL Token · SPL Memo
Solana SDK	solana-py · solders
Language	Python 3.12

6. 프로젝트를 통해 얻은 점

이번 프로젝트를 통해 좋은 AI Agent 시스템은 LLM의 판단 성능만으로 완성되지 않는다는 점을 배웠다. 정량 모델 · 정성 판단 · 정책 검색의 역할을 분리하고, 독립 검증과 자금 통제 장치를 추가해야 실제 금융 업무에 가까운 안전성과 설명 가능성을 확보할 수 있었다.

평가 과정에서는 “점수가 좋게 나오는 평가”와 “믿을 수 있는 평가”가 다르다는 점도 배웠다. 정답을 결과 전에 확정해 두고, 어려운 케이스를 빼지 않으며, 한계를 함께 밝히는 방식으로 평가를 설계했고, 그 평가에서 발견한 오류 유형(안정과 회복의 혼동 등)을 일반화해 개선했다.

또한 모델의 판정에서 끝내지 않고 자금 집행 · 재심사 · 상환 · 감사까지 연결하면서, AI 의사결정을 실제 업무 흐름에 적용하려면 실행 이후의 통제와 기록 설계가 중요하다는 점을 확인했다.