사람이 기다리지 않는 담보심사시스템 설계

안녕하세요. 뱅킹코어개발팀 Jerome입니다. 저는 카카오뱅크에서 코어뱅킹 개발, 그중에서도 대출 상품의 신청·심사 영역을 담당하고 있습니다.

은행 업무에서 예금, 적금, 이체, 대출, 카드, 외환 등 실제 돈이 오가는 계정(통장·회계 처리) 업무를 담당하는 시스템을 코어뱅킹 시스템 또는 계정계 시스템이라고 부릅니다. 이 중에서 여신은 실제 돈을 빌려주는 대출 업무를 포함해, 은행이 고객에게 ‘신용을 빌려주는’ 모든 영역을 의미합니다.

이번 글에서는 개인사업자 부동산 담보 대출 상품을 개발하면서 복잡한 담보 심사 업무를 자동화하기 위해 마주한 문제와 해결 과정, 그리고 그 과정에서의 주요 설계 포인트를 공유하고자 합니다.

여기서 심사란 고객과 담보(부동산)에 대한 정보를 검토하여 대출 가능 여부와 한도·금리 등을 종합적으로 결정하는 과정입니다. 또한, 담보는 채무자의 채무 불이행을 대비하여 채권 확보를 위해 제공하는 보증 수단으로, 주로 부동산과 같은 자산이 해당합니다. 이때 담보가 되는 부동산을 목적물이라고 칭합니다.

일반적으로 신용 대출 심사는 차주의 신용도와 상환 능력을 중심으로 평가하며, 신용 점수, 연체 이력, 타행 대출 보유 현황과 같은 정보를 종합해 한도와 금리를 결정합니다. 카카오뱅크는 출시 초기부터 이러한 심사 과정이 사람의 개입 없이 실시간으로 이루어지도록 시스템을 설계했습니다.

하지만 담보 대출은 신용 대출과 다른 특성을 가집니다. 담보를 평가하고 취급하는 과정에서 서류 진위 여부 확인, 외부 기관 연동, 담보 감정, 설정 절차 등 사람의 확인이 필요한 단계가 불가피하게 존재합니다. 이러한 지점들은 전체 업무 흐름을 특정 담당자에게 의존하게 만들며, 이는 업무량 증가 시 처리 효율이 저하되고 더 많은 인력을 필요로 하는 구조적 한계로 이어집니다.

실제로 기존 주택 담보 대출과 전월세 보증금 대출처럼 서류와 목적물 심사가 필요한 프로세스에서 신청 건수가 늘어날수록 심사 인력의 부담이 빠르게 가중되는 것을 확인할 수 있었습니다. 이 경험을 계기로 ‘사람의 개입을 최소화하는 심사 구조를 만들 수 없을까?‘라는 고민을 시작했고, 그 결과물인 자동화 설계를 이번 개인사업자 부동산 담보 대출에 적용했습니다.

이 글에서는 담보 심사 자동화를 구현하는 과정에서 어떤 문제를 어떻게 해결했으며, 실제 운영에서 어떤 효과를 얻었는지 구체적으로 소개합니다.

들어가기에 앞서 “현업이 체감한 변화”

시장 상황과 상품 확산 초기 단계라는 특성상, 아직 ‘1인당 일일 처리 건수’와 같은 구체적인 수치로 효과를 제시하기는 이릅니다. 그럼에도 운영 과정에서 현업 담당자가 가장 크게 체감한 변화는 다음 두 가지입니다.

그렇다면 이러한 긍정적인 변화는 어떤 기술적 고민과 설계를 통해 구현되었을까요? 지금부터 그 과정을 상세히 설명 드리겠습니다.

개인사업자 부동산 담보대출의 심사 과정

이번에 출시한 개인사업자 부동산 담보 대출의 심사 과정은 다음과 같은 흐름으로 진행됩니다.

여기서 선순위 권리란 해당 부동산에 이미 설정된 담보권(근저당 등) 중, 당행보다 변제 순서가 앞서는 권리를 의미합니다. 선순위 권리 규모에 따라 은행이 확보할 수 있는 실질적인 담보 가치와 대출 가능 금액이 결정되므로, 이는 매우 중요한 분석 과정입니다.

부동산 담보 대출 심사는 업무 특성상 일반적으로 한 명의 담당자가 중심이 되어 처리합니다. 다만, 인적 오류(Human Error)를 방지하기 위해 단계별로 담당자 간 교차 검증을 적용하기도 합니다.

또한, 등기부등본 및 건축물대장 발급, 외부 감정평가 의뢰, 전자등기 사전 검증 등 외부 기관과의 연동이 필수적이므로 각 단계에서 대기 시간이 발생할 수 있습니다. 여기에 개인사업자는 제출 서류가 다양하고 개별 상황에 따른 추가 확인이 필요한 경우가 많아, 전체 심사 과정은 여러 업무가 복합적으로 연계된 흐름을 가집니다.

설계포인트 1. 비동기(Asynchronous) 처리를 통한 대기 시간 제거

심사 자동화를 설계하며 가장 먼저 고려한 목표는 담당자의 불필요한 대기 시간을 최소화하는 것이었습니다. 한 작업을 끝낸 뒤 다음 단계가 완료될 때까지 화면 앞에서 기다리거나, 수 시간 혹은 수일 후 다시 돌아와 이전의 업무 맥락을 복기해야 하는 비효율을 제거하고자 했습니다.

대표적인 예시가 부동산 등기부등본 및 건축물대장 발급 업무였습니다. 기존 방식에서는 담당자가 직접 주소를 확인하여 발급을 요청하고, 완료될 때까지 대기해야 했습니다. 건당 소요 시간은 1분 내외로 짧지만 이 과정이 전체 업무 흐름의 연속성을 저해한다는 점에서 누적되는 비효율은 상당했습니다.

이에 따라, 이러한 외부 연동 작업은 사람이 직접 처리할 필요가 없다고 판단했습니다. 담당자가 개입하는 대신 시스템이 이를 대행하고, 완료되었을 때만 그 결과를 통지하는 구조가 더 합리적이라고 결론 내렸습니다.

이 구조를 더 구체적으로 설명하기 위해, 아래 등기부등본 발급 단계를 예시로 들어보겠습니다.

위 과정에서 건당 소요 시간이 5분 이내라 하더라도 해당 시간 동안 담당자는 다른 업무에 집중하기 어렵습니다. 문제가 발생하면 처음부터 다시 업무 맥락을 파악해야 하며, 여러 건을 동시에 처리하는 데에도 한계가 명확합니다.

이를 아래와 같이 개선했습니다.

이제 담당자는 발급 요청 버튼을 누르고 기다릴 필요가 없습니다. 시스템이 백그라운드에서 발급을 수행하고, 성공 및 실패 여부는 상태 값으로 기록됩니다. 담당자는 다른 심사 건을 처리하다가, 필요한 시점에 해당 건의 완료 상태를 확인하고 다음 의사결정을 내리면 됩니다. 이처럼 사람이 수행하던 대기 과정을 시스템이 대신 처리하는 비동기(Asynchronous) 작업으로 전환한 것이 이번 설계의 핵심적인 출발점이었습니다.

설계포인트 2. 사전 검토 최소화 및 프로세스 흐름 단순화

다음으로 주안점을 둔 부분은 심사 과정 전후에 존재하는 과도한 사전 검토 단계를 최소화하는 것이었습니다. 담보 심사는 예외 케이스가 많고 입력 오류나 특이 상황에 대한 우려 때문에, 담당자가 사전에 분기 조건이나 이상 여부를 확인하는 절차에 의존하는 경우가 많았습니다.

그러나 이러한 방식은 자동화 시스템을 도입하더라도 결국 사람의 지속적인 개입을 요구하게 됩니다. 따라서 표준화된 케이스의 처리 효율은 극대화하고, 복잡하거나 비정형적인 케이스는 담당자가 집중적으로 검토할 수 있도록 시스템을 설계했습니다. 운영 과정에서 발견되는 새로운 예외 케이스는 자동화 로직에 점진적으로 반영하여 시스템을 고도화할 수 있습니다.

이와 함께, 심사 건의 조건과 무관하게 전체 프로세스의 일관성을 유지하여 예측 가능성을 높이는 것을 중요한 설계 원칙으로 삼았습니다. 심사 건별로 필요한 작업이 다르더라도, 전체적인 처리 흐름은 항상 동일한 구조를 따르도록 구현했습니다.

예를 들어, 담보 감정의 필요 여부와 관계없이 심사 프로세스는 정해진 단계를 순서대로 진행합니다. 시스템은 각 단계에서 해당 작업이 필요한 조건인지를 내부적으로 판단하여, 불필요한 경우 별도의 처리 없이 다음 단계로 즉시 전환합니다. 이러한 설계 덕분에 프로세스의 각 단계는 다음에 수행할 작업을 외부에서 결정할 필요가 없어졌으며, 전체 심사 흐름은 항상 일관된 순서와 구조를 유지할 수 있게 되었습니다.

설계포인트 3. 심사 현황 모니터링 대시보드 구축

자동화된 프로세스가 확대될수록 시스템 내부 상태를 담당자가 직관적으로 파악할 수 있는 가시성(Visibility) 확보가 중요해집니다. 가시성이 부족한 자동화 시스템은 블랙박스로 전락하기 쉬우며, 이는 결국 담당자의 신뢰도 저하와 불필요한 수동 검증으로 이어질 수 있습니다.

이에 따라, 전체 심사 건의 진행 현황을 통합적으로 조회할 수 있는 전용 대시보드를 함께 설계했습니다. 이 대시보드는 단순한 처리 건수나 성공 여부를 나열하는 것을 넘어, 각 심사 단계별 처리 상태를 실시간 통계로 시각화하여 제공합니다.

만약 특정 단계에서 오류나 병목 현상이 감지되면 담당자는 해당 통계 수치를 클릭하여 즉시 상세 목록으로 드릴다운할 수 있습니다. 이를 통해 어느 단계에서 흐름이 지연되는지, 원인이 시스템의 문제인지 혹은 담당자의 개입이 필요한 상황인지 신속하게 판단할 수 있습니다. 결과적으로 담당자는 반복적인 현황 확인 작업에서 벗어나 분석과 의사결정이 필요한 핵심 업무에 더욱 집중할 수 있게 되었습니다.

Deferred Batch를 활용한 담보 심사 컨베이어 벨트 모델링

코어뱅킹 개발 환경은 다른 환경에 비해 제약 사항이 많습니다. 고객의 계좌 및 대출 등 핵심적인 금융 거래를 처리하므로, 새로운 시스템을 통합하거나 기존 시스템을 변경하는 데 많은 제약이 따릅니다. 이러한 제한된 환경 내에서 구현 방안을 모색하며 다음과 같은 요구사항을 도출했습니다.

• • 확장성: 단계별 작업 추가 시 파생되는 개발 비용이 적고, 중간 삽입 및 순서 조정이 용이해야 함
• • 제어 가능성: 작업이 주기적으로 반복 실행되되, 필요시 작업 단위의 중지·재개·재시도가 가능해야 함
• • 안정성: 특정 작업에서 오류가 발생하더라도 전체 프로세스가 중단되지 않아야 하며, 해당 건만 분리하여 복구 및 재처리가 가능해야 함
• • 기존 프레임워크 활용: 별도의 외부 시스템 도입 없이 기존 계정계 프레임워크 내에서 구현이 가능해야 함

검토 결과, 새로운 시스템을 도입하기보다 이미 안정성이 검증된 내부 Deferred Batch 기능을 확장하여 사용하는 것이 리스크를 최소화할 수 있는 방안이라고 판단했습니다.

💡 Deferred Batch란?

Deferred Batch는 사전에 정의된 주기에 따라 특정 조건을 SQL로 조회하고, 조회된 대상에 대해 지정된 메서드를 호출하는 경량 배치 실행 기능입니다. 즉, 조건에 맞는 대기 작업을 주기적으로 처리해주는 워크플로우와 유사한 역할을 수행합니다. 실행 주기를 짧게 설정할 수 있다는 장점이 있지만, 반대로 작업 수행 현황 파악, 오류 추적, 운영 조치가 복잡해질 수 있는 단점도 존재합니다.

이번 개인사업자 부동산 담보 대출 심사 자동화에서는 이러한 장단점을 고려하여, 별도의 작업 상태 관리 테이블과 전용 대시보드를 함께 설계하는 방향을 채택했습니다. 덕분에 Deferred Batch의 장점은 그대로 유지하면서도 운영 관점에서 발생할 수 있는 관리의 복잡성을 상당 부분 보완할 수 있었습니다.

테이블 설계 방식

1. 작업 내역 테이블

작업의 상태, 스케줄(처리 예정 시각), 재처리 관련 정보를 관리하는 테이블입니다. 동일한 심사 건에 대해 같은 작업이 여러 번 수행될 수 있는 경우를 고려하여, 작업코드는 기본 키(Primary Key)에 포함하지 않고, 순차적으로 부여되는 작업일련번호를 기본 키의 일부로 설정합니다.

아래 DDL은 실제 운영 스키마가 아니며, 개념 설명을 위해 축약된 예시입니다. 컬럼 구성 및 제약 조건의 설계 방향을 참고하는 용도로만 활용해 주시기 바랍니다.

CREATE TABLE TASK_HISTORY (
    기준일자       DATE        NOT NULL,
    심사번호       VARCHAR2(20) NOT NULL,
    작업일련번호   NUMBER      NOT NULL,
    작업코드       VARCHAR2(30) NOT NULL,
    작업상태코드   VARCHAR2(10) NOT NULL,
    처리예정시각   TIMESTAMP   NOT NULL,
    등록시각       TIMESTAMP   NOT NULL,
    재처리횟수     NUMBER      DEFAULT 0,
    재처리가능횟수 NUMBER      DEFAULT N,
    CONSTRAINT PK_디퍼드작업내역T
        PRIMARY KEY (기준일자, 심사번호, 작업일련번호)
);

2. 작업 오류 내역 테이블

작업 수행 중 오류 발생 시, 관련 이력을 기록하는 테이블입니다. 하나의 작업(작업일련번호)에서도 여러 유형의 오류가 발생할 수 있으므로, 오류일련번호를 식별자로 추가합니다.

Deferred Batch의 실행 특성과 오류 처리

Deferred Batch는 일정 주기마다 조건에 맞는 데이터를 조회하여 처리 대상을 선정하고, 선정된 대상에 대해 지정된 작업을 수행하는 특성을 가집니다. 따라서 작업이 처리예정시각에 정확히 실행되기보다는, 해당 시각이 경과한 작업들이 정렬 순서(예: 처리 예정 시각, 등록 시각 순)에 따라 순차적으로 처리됩니다. 저희는 이 특성을 활용하여 전체 심사 업무를 작은 작업 단위로 분할하고, 작업 간의 선후 관계를 다음 작업의 등록으로만 연결하는 느슨하게 결합된 워크플로우 구조를 설계했습니다.

작업 조회 예시(SQL)

아래 SQL은 실제 운영 쿼리가 아니며, 개념 설명을 위해 축약된 예시입니다.

SELECT BASE_DATE, REVIEW_ID, TASK_SEQ, TASK_CODE
  FROM TASK_HISTORY
 WHERE STATUS_CODE = 'PENDING'
   AND SCHEDULED_AT <= SYSTIMESTAMP
 ORDER BY SCHEDULED_AT, CREATED_AT, TASK_SEQ
 FETCH FIRST N ROWS ONLY;

위 SQL과 같이, PENDING 상태이면서 처리예정시각이 경과한 작업을 조회하면, 시스템은 복합 키(BASE_DATE, REVIEW_ID, TASK_SEQ)를 통해 특정 작업을 식별한 뒤, 해당 작업의 TASK_CODE에 따라 적절한 처리 메서드를 분기하여 호출합니다.

각 단계가 독립적인 작업 단위로 분리되어 있으므로, 특정 단계에서 오류가 발생하더라도 전체 프로세스를 처음부터 재실행할 필요가 없습니다. 문제가 발생한 단계에서만 작업을 중지시키고 원인을 분석한 후, 해당 작업(또는 그 다음 작업)부터 프로세스를 재개할 수 있습니다.

또한, 자동화된 심사 흐름이라 하더라도 담당자의 업무 판단이나 외부 기관의 조치가 필요한 경우, 후속 작업이 무조건 진행되지 않도록 해당 심사 건의 이후 작업들을 SUSPENDED(중단) 상태로 보류할 수 있는 기능을 구현했습니다. 외부 조치가 완료되면, 중지된 지점부터 다시 PENDING(대기) 상태로 전환하여 단계별 흐름을 이어갈 수 있습니다.

이처럼 작업 간의 의존성을 이전 단계의 완료 → 다음 작업의 등록 이라는 단순한 관계로만 정의함으로써, 각 작업은 자신의 책임 범위 내에서만 독립적으로 수행되며 실패 역시 해당 범위 안에서 격리됩니다. 결과적으로 전체 심사 파이프라인은 하나의 거대한 트랜잭션으로 묶이지 않고, 운영 상황에 맞춰 유연하게 중지, 재시도, 재개할 수 있는 견고한 구조를 갖추게 됩니다.

오류 처리 및 재시도 로직(개요)

샘플코드

업무를 처리하는 주 트랜잭션은 오류 발생 시 과감히 throw를 통해 롤백시키되, 시스템의 안정적인 운영을 위해 오류 상태, 이력, 재시도 스케줄 등은 REQUIRES_NEW 같은 트랜잭션 전파 옵션을 활용하여 별도의 트랜잭션에서 안전하게 기록합니다.

💡 REQUIRES_NEW란?

REQUIRES_NEW는 기존 트랜잭션의 성공 여부와 관계없이, 항상 새로운 물리적 트랜잭션을 시작하여 커밋 또는 롤백을 독립적으로 관리하는 트랜잭션 속성입니다.

public void executeJob(JobKey key) {
    try {
        // (TX 시작: 주 업무 처리를 위한 메인 트랜잭션)
        // 1. 처리 대상 작업의 유효성 검증
        validateTask(key);

        // 2. 실제 업무 로직 수행 (외부 API 호출, 데이터 검증 및 저장 등)
        processBusinessLogic(key);

        // 3. 성공 처리
        markTaskAsCompleted(key);
        enqueueNextTaskIfNeeded(key);
        // (메인 트랜잭션 COMMIT)

    } catch (Exception e) {
        // 오류 상태 변경, 이력 기록, 재시도 스케줄링 등은
        // 메인 트랜잭션의 롤백에 영향을 받지 않도록 별도의 트랜잭션에서 수행한다.
        handleFailureInNewTransaction(key, e);

        // 메인 트랜잭션의 롤백을 확실히 보장하기 위해 예외를 다시 throw 한다.
        throw e;
    }
}

/**
 * 오류 처리를 위한 별도의 신규 트랜잭션을 시작하고 실행합니다.
 * 실제 구현에서는 Spring의 @Transactional(propagation = Propagation.REQUIRES_NEW)
 * 어노테이션이나 TransactionTemplate 등을 활용하여 보장할 수 있습니다.
 */
private void handleFailureInNewTransaction(JobKey key, Exception e) {
    transactionManager.runInNewTransaction(() -> {
        try {
            // 재처리가 가능한지 확인
            if (canRetry(key)) {
                // 1. 재시도 횟수 증가 및 다음 실행 시간 스케줄링
                scheduleNextRetry(key, calculateBackoff(key));
            } else {
                // 2. 재처리 불가 시, 담당자 확인을 위해 '중단' 상태로 변경
                markTaskAsSuspended(key);
            }
            // 3. 공통: 오류 이력 기록 (운영 및 분석용)
            logErrorHistory(key, e);

        } catch (Exception loggingException) {
            // 로깅 실패는 별도로 처리 (예: 심각한 오류 알림)
            log.error("Failed to handle failure for job: {}", key, loggingException);
        }
    });
}

컨베이어 벨트처럼 흐르는 심사: ‘긴 트랜잭션’이 아닌 ‘작업 체인’

이 설계를 심사 업무에 적용함으로써, 전체 프로세스는 하나의 거대한 처리 단위가 아닌, 작은 작업들이 연쇄적으로 연결되는 작업 체인 구조로 재구성되었습니다. 각 단계의 작업이 완료될 때마다 후속 작업을 시스템에 등록하여 다음 흐름을 이어갑니다.

그 결과, 특정 심사 건에서 문제가 발생하더라도 전체 파이프라인이 중단되지 않습니다. 문제가 발생한 심사 건만 해당 단계에서 ERROR(오류) 또는 SUSPENDED(중단) 상태로 전환되며, 이는 담당자에게 알림으로 전달되거나 대시보드에서 즉시 식별하여 조치할 수 있습니다. 나머지 정상적인 심사 건들은 기존 흐름에 따라 다음 단계로 계속 처리됩니다.

또한, 외부 기관 연동과 같이 처리 시간이 오래 소요되는 작업이 시작되면, 담당자는 해당 심사 건의 대기 과정에서 자연스럽게 분리됩니다. 시스템이 백그라운드에서 작업을 비동기적으로 수행하는 동안 담당자는 다른 심사 건을 효율적으로 처리할 수 있으며, 다시 담당자의 개입이 필요한 시점에만 호출됩니다.

담보 심사 자동화: 작업 모델의 재정의와 개선 효과

Deferred Batch 구조를 효과적으로 활용하기 위해 가장 먼저 한 일은 기존의 심사 단계를 작업 중심으로 재정의하는 것이었습니다. 기존에도 진행 단계를 기록하는 상태 관리 구조가 있었고, 이는 담당자의 오작동을 방지하는 데 유용했습니다. 하지만 담당자가 직접 작업 순서를 숙지하고, 심사 유형에 따라 수행 대상을 판단해야 하는 본질적인 한계가 존재했습니다.

이번 개선에서는 새로운 단계를 무작정 추가하기보다 기존의 업무 단계를 심사 시스템이 이해할 수 있는 명확한 작업 모델로 재정의하는 데 집중했습니다. 각 작업은 심사 건별로 고유한 상태(PENDING, COMPLETED 등)를 가지며, 이 상태 값에 따라 다음 프로세스가 결정됩니다. 이 상태는 화면과 대시보드에 직접 연동되어 담당자는 작업 단계별 진행 건수, 개별 심사 건의 현재 위치, 병목 발생 지점 등을 직관적으로 파악할 수 있게 되었습니다.

담보 심사 자동화 개선이 적용된 상품 출시 후, 운영 기간이 아직 길지 않음에도 불구하고 몇 가지 명확한 긍정적 변화를 확인할 수 있었습니다.

첫째, 담당자의 불필요한 대기 시간이 크게 감소했습니다. 담당자가 다음 순서를 고민할 필요 없이 시스템이 후속 작업을 자동으로 처리합니다. 특히 외부 연동과 같이 응답 대기가 필요한 작업을 시스템이 대신 수행하므로, 담당자는 그 결과를 기다리지 않고 즉시 다음 심사 건을 처리할 수 있습니다.

둘째, 심사 지연 현상이 국지적으로 격리되었습니다. 문제가 발생한 심사 건만 해당 작업 단계에서 멈추고, 나머지 정상 건들은 흐름을 유지함에 따라 전체 처리 속도가 안정적으로 유지됩니다.

셋째, 심사 현황에 대한 신뢰도가 향상되었습니다. 대시보드를 통해 모든 작업의 상태를 실시간으로 확인할 수 있게 되면서, 담당자는 시스템의 동작을 의심하며 불필요한 검증을 하기보다, 실제 분석과 의사결정이 필요한 지점에 집중할 수 있게 되었습니다.

마지막으로, 지속적인 자동화 개선이 가능한 구조가 마련되었습니다. 운영 중에 발생하는 새로운 예외 케이스를 분석하여 자동화 로직에 점진적으로 반영할 수 있는 확장 가능한 기반이 구축되었습니다.

마치며

이번 담보 심사 자동화 프로젝트를 통해 얻은 가장 큰 교훈은, 자동화의 진정한 목적이 사람을 시스템에서 완전히 배제하는 것이 아니라는 점이었습니다. 오히려 사람이 비효율적인 흐름 속에서 멈추어 기다려야 하는 지점을 제거하고, 가장 중요한 ‘판단’의 순간에만 집중할 수 있도록 돕는 것이 핵심이라는 사실을 다시 한번 확인했습니다.

모든 업무의 흐름과 상태를 사람이 기억하고 추적하는 대신, 시스템이 그 역할을 대행하고 필요할 때만 사람을 호출하는 구조로 전환하고자 했습니다. 이번 설계는 그 방향으로 나아가기 위한 의미 있는 첫걸음이었습니다.

이 글이 저와 같이 복잡한 업무 흐름의 자동화를 고민하는 다른 개발자분들께 작은 참고가 되기를 바랍니다. 긴 글 읽어주셔서 감사합니다.