점포 폐쇄로 인한 금융 소외 문제를 해결하기 위해 BaaS 통합 은행대리업 솔루션 개발
은행 지점의 지속적인 감소로 고령층과 지방 거주자 등 금융 취약계층의 오프라인 은행 접근성이 저하되고 있습니다.
정부는 이에 대한 포용 금융 대응책으로 은행대리업을 제시했으며, 2025년 12월 금융규제 샌드박스를 통해 혁신금융서비스로 지정되었습니다.
BankK는 이 환경에 선제적으로 대응하기 위해, 우체국·상호금융 등 대행기관이 BaaS API를 통해 여신 상품 판매·계좌 조회·출금 업무를 처리할 수 있도록 중계하는 플랫폼입니다.
| 구분 | 대상 |
|---|---|
| B2B (은행업 대리기관) | 우체국, 상호저축은행, 지역농업협동조합 등 상호금융기관 |
| B2C (금융 소외 계층) | 점포가 입점하지 않거나 철수한 지방 거주민, 비대면 서비스에 어려움을 느끼는 고령층 |
| 문제 | 내용 |
|---|---|
| 법적 책임 리스크 | 대리업 과정에서 발생한 문제의 책임이 소속은행에 귀속되어 관리 감독 의무 증명 수단 필요 |
| 서비스 구축 비용 | 은행과 대행기관 간 서비스 망을 1:1로 구축하면 과도한 개발 비용·시간 발생 |
| 금융 서비스 제공의 제약 | 여신 상품은 은행마다 세부 프로세스가 달라 금결원 Open API 방식으로 일괄 제공 불가 |
→ 해결: BaaS를 통한 코어뱅킹 서비스 제공 및 모니터링 환경 구축
BaaS를 통한 코어뱅킹 제공 → 모니터링을 통한 관리/감독 → 금융 사고에 대한 소명 자료 확보
- 금융서비스 일괄 제공 - 서비스 정상 제공 확인 - 모니터링 자료를 통한 소명
- 신규 대행기관 추가 개발 - 대행기관과의 통신 문제 파악 - 관리 감독 의무 수행 증명
비용 없이 연결 확장
대행기관 (우체국/상호금융)
│ 창구 직원용 Web Frontend
▼
중계 플랫폼 (BaaS Cloud) ── 모니터링 서버
│ 인증 / 암복호화 / BaaS API 변환 / AI 업무지원
▼
은행 Core Banking (온프레미스)
조회 / 이체 / 출금 / 원장 DB
| 모듈 | 역할 |
|---|---|
| platform/backend | BaaS 중계 플랫폼 서버 |
| platform/frontend | 창구 직원용 Web |
| bank/backend | 은행 코어 서버 |
| monitoring/backend | 로그 조회 API 제공 |
| monitoring/frontend | 관제 대시보드 |
전체 아키텍처 및 CI/CD 파이프라인 → docs/ARCHITECTURE.md
- 금결원 Open API의 한계 극복 — 은행마다 다른 여신 상품 프로세스를 각 은행 BaaS API에 직접 연결하여 제공
- 은행의 통제권 유지 — BaaS를 통해 서비스를 제공하므로 은행이 대행기관의 API 접근을 직접 통제·관리
- 확장 비용 Zero — 신규 대행기관 추가 시
application.yml설정만으로 연결 확장, 추가 개발 불필요
| 기능 | 설명 |
|---|---|
| 코어뱅킹 | 계좌 조회·이체·출금·대출 BaaS API 중계 |
| BaaS 모니터링 대시보드 | 로그 조회·메트릭 현황 실시간 관제 |
| 대리기관 직원 보조 AI | RAG 기반 금융 상품·약관 질의응답 지원 |
대출 프로세스: 심사 서류 제출 → NICE 신용점수 조회 → DSR 계산 → 상품 추천 → 계약 서류 동의 → 대출 실행 (단일 트랜잭션)
사고 발생 시 주의 의무를 다했음을 기술적으로 증명하기 위해 3중 보안을 적용했습니다.
| 레이어 | 기술 | 목적 |
|---|---|---|
| 통신 구간 | mTLS | 플랫폼 서버 ↔ 은행 코어 서버 간 양방향 인증서 검증 — 인가된 서버만 접근 허용 |
| 페이로드 | JWS | 요청 데이터 전자서명 — 금액·수취인 위변조 증명 |
| 종단간 | E2EE (디지털 봉투) | 1회용 AES 세션키로 민감정보 암호화 → AES 키를 은행 RSA 공개키로 암호화하여 전송 |
Zero-Knowledge 라우팅 — 중계 플랫폼은 디지털 봉투를 절대 복호화하지 않고 원본 암호문 그대로 은행으로 Pass-through. 플랫폼이 고객 원문을 취득할 수 없는 구조적 보안 원칙.
분쟁 발생 시 귀책사유를 명확히 소명하기 위해 전 구간 추적 가능한 로그 파이프라인을 구축했습니다.
- Trace-ID (traceId + epoch + nano + rand4hex) — 대행기관→플랫폼→은행 전 구간 단일 요청 추적
- TX_PAYLOAD_LOG — 위변조 증명용 암호문 원본을 별도 테이블에 적재
- 식별 컨텍스트 — 직원 ID, 기관 코드 기록
네트워크 타임아웃·재시도로 인한 이중 출금을 원천 차단하기 위해 멱등성 키 기반 중복 제어를 설계했습니다.
- Idempotency-Key (traceId 기반 UUID) — 클라이언트가 요청마다 고유 키를 생성하여 헤더에 포함
- Redis 원자적 SETNX — 키 최초 수신 시점에 SETNX + TTL로 잠금, 동일 키의 재요청은 DB 접근 없이 즉시 캐시 응답 반환
본 서비스는 아래 법령의 적용을 받으며, 각 항목을 개발 기준으로 반영했습니다.
| 법령 | 주요 적용 내용 | 기술적 구현 |
|---|---|---|
| 금융소비자보호법 (금소법) | 적합성 원칙, 설명 의무, 불완전판매 금지 | 고위험 상품 60일 재가입 차단, 약관 동의 타임스탬프 기록 |
| 전자금융거래법 | 전자적 금융거래의 안전성·신뢰성 확보 | mTLS + JWS 3중 보안, 거래 원장 위변조 방지 |
| 개인정보보호법 | 개인정보처리자로서 수집·저장·파기 정책 준수 | 로그 마스킹, 민감정보 AES-256 암호화 저장, 블라인드 인덱싱 |
| 신용정보법 | 신용정보 제공·이용 규제 (대리 업무 수행 시 취급) | 신용정보조회 동의서 징구, 신용점수 스냅샷 저장 |
팀의 AI 도구(Gemini CLI) 활용 일관성을 위해 prompt/ 디렉토리에 컨텍스트 파일을 관리합니다.
자세한 라우팅 규칙은 GEMINI.md를 참고하세요.
prompt/
├── docs/ # 전사 공통 코드 컨벤션 (FE/BE)
├── platform/ # 중계 플랫폼 도메인 규칙 + 스택
├── bank/ # 은행 코어 도메인 규칙 + 스택
└── monitoring/ # 모니터링 도메인 규칙 + 스택