핀테크를 위한 생성형 AI PBL

2025년 카카오페이 강의장의 첫 시간은 모델 기능 소개가 아니라 선 긋기로 시작했습니다. 개발자와 기획자 32명이 팀 단위로 앉은 자리에서 던진 첫 질문은 하나였습니다. 우리가 만들 Agent는 결제 데이터의 어디까지 읽어도 되고, 어디부터는 사람의 승인이 필요한가. 8시간 PBL의 모든 논의가 이 질문 위에서 출발했습니다.

카카오페이 개발자·기획자 32명 대상 8시간 생성형 AI PBL. 종료 시점 만족도 평균 4.8/5, 수료자 다수가 사내 AI 에이전트 파일럿 프로젝트로 직결되었습니다.

안녕하세요, 권앤컴퍼니의 권기현입니다. 이번에는 카카오페이에서 진행한 핀테크 도메인 생성형 AI PBL 과정을 소개하려고 합니다. 결제·송금·자산 데이터를 다루는 조직에서 Agent 교육을 어떻게 설계했고, 팀별 파일럿이 어떤 흐름으로 사내 프로젝트까지 이어졌는지에 대한 기록입니다.

핀테크 조직의 AI 에이전트 교육을 검색하다 이 페이지에 도착하셨다면, 아마 다음 세 가지 중 하나에 걸려 계실 가능성이 높습니다.

결제·송금 데이터에 LLM을 붙이려는 순간 보안 검토부터 막혀서, 기술 논의가 시작조차 되지 않습니다.

read-only 조회와 자금이 움직이는 실행을 Agent 안에서 어떻게 분리할지, 참고할 사내 표준이 없습니다.

Agent가 낸 답변을 컴플라이언스 관점에서 무엇으로 검증할지, 평가 기준이 문서로 잡혀 있지 않습니다.

이 과정은 위 세 가지 질문을 개발자와 기획자가 같은 테이블에서 함께 푸는 PBL로 설계되었습니다. PBL(Project Based Learning)이란 완성된 교안을 따라가는 대신, 팀이 실제 과제 하나를 잡아 설계부터 발표까지 한 사이클을 완주하며 배우는 형식을 말합니다.

기능 소개보다 경계 정의가 먼저였습니다

핀테크 Agent 교육은 모델 기능이 아니라 데이터 경계와 검증 기준을 먼저 합의해야, 파일럿이 정책 협의 단계에서 멈추지 않습니다. 이것이 이 과정 전체를 관통한 설계 전제입니다.

카카오페이처럼 결제·송금·자산 데이터를 다루는 조직에서 Agent 이야기를 꺼내면 질문은 곧바로 현실로 내려옵니다. 사내 API를 어디까지 연결할 수 있는지, 사용자의 금융 맥락을 어떤 형태로 모델에 넘길지, 컴플라이언스 검토를 통과하려면 어떤 로그와 승인 구조가 필요한지. 그래서 개발자만 모아 코드를 치게 하는 대신, 기획자가 같은 강의장에서 과제 범위와 검증 기준을 함께 잡도록 과정을 구성했습니다.

8시간 네 개 모듈: 결제 질의 한 건이 지나가는 길

네 개 모듈은 아키텍처, RAG, function calling, 평가·모니터링 순서로, 결제 질의 한 건이 Agent를 통과하는 경로를 그대로 따라가도록 배치했습니다. 다만 그보다 먼저 오는 것이 팀별 과제 선정 기준입니다. 핀테크의 Agent 과제는 전부 같은 무게가 아니어서, 잔액 조회처럼 읽기만 하는 일과 송금 실행처럼 자금이 움직이는 일은 규제 부담이 한 단계 다릅니다. 실습 첫 단계에서는 과제 후보를 자동화 이득과 규제 부담 두 축 위에 올려 보고 파일럿의 출발점을 정합니다.

1. Agent 아키텍처: 질의 한 건이 지나가는 길부터 그립니다

핀테크에서는 질의 한 건에 사내 시스템, 외부 결제망, KYC 데이터, 컴플라이언스 룰이 동시에 걸립니다. 이 경로가 그림으로 정리되어 있지 않으면 파일럿은 정책 협의 단계에서 멈춥니다.

이 모듈에서 팀 단위로 다루는 내용입니다.

• Router·Planner·Executor 분리와 결제 도메인에서 각 층이 지는 책임 범위
• 단일 LLM 호출과 Agent loop 사이의 선택 기준: 응답 지연·비용·정확도
• KYC·결제·자산 시스템을 한 과제 안에서 다단계로 엮는 패턴
• 컴플라이언스 검증 지점을 나중에 덧붙이지 않고 아키텍처에 미리 박는 방법

실습에서는 결과 데모보다 구조 설명을 먼저 요구했습니다. 어느 단계에서 검색하고, 어디에서 도구를 부르고, 어디에서 사람이 승인하는지를 그림 한 장으로 말할 수 있어야 발표 이후의 사내 논의가 이어집니다.

2. RAG: 약관 문서를 자르는 방식이 답변의 방향을 정합니다

핀테크의 RAG는 벡터 DB를 고르는 문제가 아닙니다. 약관과 정책 문서는 조항 단위와 버전, 시행일이 얽혀 있어서 청크를 자르는 방식이 답변 품질의 절반 이상을 결정합니다.

RAG(검색 증강 생성)란 모델이 답을 만들기 전에 사내 문서를 먼저 검색해 근거로 붙이는 구성을 말합니다. 이 모듈에서 다루는 내용입니다.

• 약관·정책·내부 가이드의 청크 단위 설계와 상품·일자·버전 메타데이터
• 키워드 검색과 벡터 검색을 함께 쓰는 하이브리드 구성
• 재랭킹과 컨텍스트 압축으로 비용과 지연을 줄이는 패턴
• recall·MRR·hit rate로 검색 품질을 수치로 관리하는 평가 방법

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

3. function calling: 조회 함수와 자금이 움직이는 함수 사이에 선을 긋습니다

Agent 호출 한 건이 곧 금융 거래가 될 수 있는 환경에서는, 함수 하나를 여는 일이 단순한 API 연동이 아니라 권한 설계입니다.

이 모듈에서는 사내 API 스타일의 실습 환경에서 다음을 다룹니다.

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

function 단위에서 감사 추적이 함께 박혀야, 검수를 통과하고 운영까지 가는 Agent가 됩니다.

4. 평가와 모니터링: 검수가 물어볼 질문을 먼저 자동화합니다

PBL의 마지막 모듈은 각 팀이 만든 Agent를 평가 셋과 운용 정책 위에 올려 보는 시간이었습니다. 검수 단계에서 반드시 나올 질문을 미리 평가 항목으로 바꿔 두는 것이 목적입니다.

이 모듈에서 다루는 내용입니다.

• 금융 상담 시나리오별 평가 셋 설계와 통과 기준 정의
• 추론 모델과 일반 LLM을 섞어 쓸 때의 비용과 정확도 측정
• 운영 환경 트레이싱과 이상 호출 알림 구성
• 점진 배포·롤백·rate limit을 포함한 운용 정책

평가 셋이 없는 Agent는 검수 때마다 같은 질문을 새로 받습니다. 마지막 모듈은 그 답변을 문서가 아니라 자동화된 평가로 옮기는 시간입니다.

평점 4.8/5, 그리고 사내 파일럿으로 이어진 이유

개발자와 기획자 32명이 한 과정에 함께 들어와 4명 단위 팀으로 핀테크 도메인 과제를 잡았고, 한 사이클 안에서 Agent 파일럿을 만들어 발표까지 마쳤습니다. 종료 시점 평균 만족도는 4.8/5이었고, 수료자 다수가 사내 AI 에이전트 파일럿 프로젝트로 직접 이어졌습니다.

이 평점의 이유를 정리해 보면, 발표가 데모 시연으로 끝나지 않고 결재 라인까지 가져갈 수 있는 자료로 남았기 때문이라고 생각합니다. 아키텍처 그림, 함수 분리 기준, 평가 셋까지 손에 남으니, 팀이 어느 부서로 돌아가더라도 다음 주에 같은 흐름을 한 번 더 돌릴 수 있습니다. PBL 형식이 핀테크 도메인에 맞았던 지점이 바로 여기였습니다.

이 과정이 필요한 분들

• 결제·송금 도메인에서 Agent 서비스를 처음 설계해야 하는 개발자·테크리드
• Agent 파일럿을 데모에서 운영 검토 단계까지 끌고 가야 하는 AI 전환·DT 추진 리더
• 사내 데이터와 API를 LLM에 안전하게 연결해야 하는 플랫폼·인프라 담당자

특히 카카오페이처럼 금융 규제와 활용도 사이의 균형이 무겁게 걸리는 조직에서, PBL 결과물을 사내 검수 절차에 올리는 다음 단계에서 가장 큰 시간이 절약됩니다.

다음 단계

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

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

상담 문의 보내기 | 강의 카탈로그 요청하기

교육 담당자분께서 결재 라인에 공유할 자료가 필요하신 경우, 문의 폼에서 강의 카탈로그를 함께 요청해 주시면 빠르게 보내드립니다.

Tags