핀테크를 위한 생성형 AI PBL

카카오페이에서 진행한 핀테크 도메인 생성형 AI PBL입니다. 개발자·기획자 32명 · 만족도 평균 4.8/5 · 수료자 다수가 사내 AI Agent PoC로 직결되었습니다.

안녕하세요, 권앤컴퍼니의 권기현입니다. 이번에는 카카오페이에서 진행한 핀테크 생성형 AI PBL을 소개하려고 합니다. 결제·송금·자산 데이터라는 무거운 도메인 위에서 Agent를 어떻게 설계했고, PBL 형식으로 어떻게 PoC까지 끌고 갔는지에 대한 기록입니다.

기업의 LLM Agent 도입을 검색하다 이 페이지에 도착하셨다면, 비슷한 고민을 가지고 계실 가능성이 높습니다.

핀테크 데이터는 보안·규제 무게가 가장 무거운 영역이라 LLM에 붙이는 첫 단계부터 정책 협의가 막힙니다.

결제·송금 API와 LLM을 안전하게 잇는 function schema·인증 구조 표준이 사내에 없습니다.

Agent의 응답을 컴플라이언스 관점에서 무엇으로 검증해야 할지 기준이 잡혀 있지 않습니다.

이 강의는 위 세 가지 질문에 대한 개발자·실무 관점의 답을 16시간 안에 정리해 드리는 과정으로 설계되었습니다.

한 줄 요약

워크샵 직후부터 사내에서 바로 PoC 시작이 가능한 Agent 아키텍처·RAG·function calling·운용 패턴을 한 번에 다룹니다.

핀테크 도메인의 보안·컴플라이언스 환경을 전제로 두고, 개발자·기획자가 PBL 한 사이클 안에서 Agent를 PoC까지 끌고 가는 흐름으로 구성했습니다.

네 개 모듈로 나누어 진행했습니다

1. LLM Agent 아키텍처 — 토이 데모와 프로덕션 사이의 거리

핀테크는 사내 시스템·외부 결제망·KYC 데이터·컴플라이언스 룰이 한 질의 안에서 동시에 걸립니다. Agent 아키텍처가 명확하지 않으면 PoC 단계에서 정책 협의에 걸려 멈춥니다.

이 모듈에서는 다음 내용을 도메인 시나리오에 묶어 다룹니다.

• Router·Planner·Executor 분리와 핀테크 시나리오에서의 책임 범위
• 단일 LLM 호출과 Agent loop의 트레이드오프 — 응답 지연·비용·정확도
• KYC·결제·자산 시스템을 다단계로 묶는 패턴
• 컴플라이언스 검증 지점을 아키텍처에 미리 박는 방법

아키텍처 그림이 없는 Agent는 운영 단계에서 항상 무너집니다. 첫 모듈에서 그 그림을 손으로 그릴 수 있는 수준까지 끌어올립니다.

2. RAG 시스템 설계 — 검색 품질이 곧 답변 품질입니다

RAG는 벡터 DB 한 줄로 끝나지 않고, 청크·메타데이터·재랭킹·하이브리드 검색의 조합이 답변 품질의 절반 이상을 결정합니다. 핀테크 도메인은 특히 약관·정책 문서의 청크 단위가 까다롭습니다.

이 모듈에서는 다음 내용을 다룹니다.

• 약관·정책·내부 가이드 청크 단위 설계와 메타데이터(상품·일자·버전)
• 키워드·벡터를 묶는 하이브리드 검색 구성
• 재랭킹·컨텍스트 압축으로 비용과 지연을 잡는 패턴
• 검색 품질 평가 지표 (recall, MRR, hit rate) 적용

약관 한 줄이 잘못 잘리면 Agent의 모든 응답이 같은 방향으로 틀립니다. RAG 단계에서 그 단추를 묶습니다.

3. function calling · tool use — Agent와 사내 시스템을 안전하게 잇는 법

핀테크 Agent의 핵심은 사내 API와 정확하게 잇는 일입니다. 그 단계에서 보안과 컴플라이언스가 가장 자주 깨집니다.

이 모듈에서는 다음 내용을 실제 사내 API 스타일로 다룹니다.

• read-only 조회 함수와 자금 이동·승인 함수의 분리
• 내부 API 인증을 Agent 컨텍스트에 노출하지 않는 호출 구조
• tool 결과 검증과 사용자 confirm 단계 삽입 시점
• 권한·감사 로그·민감 정보 마스킹을 미들웨어 한 줄로

핀테크에서는 Agent 호출 한 건이 그 자체로 금융 거래입니다. function 단위에서 감사 추적이 함께 박혀야 운영 가능한 Agent가 됩니다.

4. 평가·모니터링·운용 — 데모로 끝내지 않기 위한 마지막 모듈

PBL 형식으로 진행했기에, 마지막 모듈은 각 팀이 만든 Agent를 평가 셋·모니터링·운용 정책 위에 올려 보는 시간이었습니다.

이 모듈에서는 다음 내용을 다룹니다.

• 핀테크 시나리오 평가 셋 설계 — 컴플라이언스·정확도·안전성
• 추론 모델과 일반 LLM 혼용 시 비용·정확도 균형 측정
• 프로덕션 트레이싱과 이상 호출 알림 구성
• 점진 배포·롤백·rate limit 운영 정책

평가 셋이 없는 Agent는 컴플라이언스 검수 단계에서 항상 같은 질문을 받습니다. 마지막 모듈에서 그 답변을 자동화 영역으로 옮깁니다.

PBL 형식과 평점 4.8/5을 받은 이유

개발자·기획자 32명이 한 cohort 안에 함께 들어왔고, 4명 단위 팀으로 핀테크 도메인 과제를 잡아 한 사이클 안에서 Agent PoC를 만들어 발표하는 형식으로 진행했습니다. 강의 종료 시점 평균 만족도는 4.8/5을 기록했고, 수료자 다수가 사내 AI Agent PoC 프로젝트로 직접 연결되었습니다.

이 평점이 나온 이유를 정리해보면, 이론보다는 마지막 날 PoC를 끝까지 돌려본 경험이 결재 라인까지 가져갈 자료를 함께 만들었기 때문이라고 생각합니다. PBL이라는 형식이 핀테크 도메인에서 잘 맞은 이유는, 한 팀이 사내 어디 부서로 돌아가더라도 다음 주에 같은 흐름으로 한 번 더 돌릴 수 있는 결과물이 손에 남았기 때문입니다.

이런 분께 추천드립니다

• 사내 AI Agent 서비스를 처음부터 설계해야 하는 개발자·테크리드
• Agent PoC를 프로덕션까지 가져가야 하는 AX·DT 추진 임원
• 사내 데이터·API를 LLM과 안전하게 연결해야 하는 플랫폼·인프라 담당자

특히 카카오페이·핀테크 사처럼 보안과 활용도 균형이 가장 무겁게 걸리는 환경에서, PBL 결과물을 사내 PoC로 옮기는 다음 단계에서 가장 큰 시간 절약이 됩니다.

다음 단계

회사 상황에 맞춰 16시간 과정을 그대로 진행하실 수도 있고, 8시간 또는 4시간 압축본으로 시작하셔서 차수를 늘려가시는 것도 가능합니다.

가장 빠른 길은 현재 회사 상황과 가능한 일정을 메일로 보내주시는 것입니다. 24시간 안에 비슷한 사례 2~3건과 견적 초안을 함께 회신드리겠습니다.

→ 상담 문의 보내기 | 강의 카탈로그 PDF 받기

교육 담당자분께서 결재 라인에 공유해야 하시는 경우, 카탈로그 PDF를 먼저 받아두시는 편이 편리합니다.

Tags