PF 대출 스크리닝 에이전트

문제

부동산 PF 사모대출 딜을 검토할 때 판단의 절반은 계산입니다. LTV, LTC, 손익분기 분양률, 트랜치별 회수액, 기대손실 — 이런 숫자를 먼저 뽑아야 그다음 정성 판단이 가능합니다.

그런데 딜이 여러 건 쌓이면 이 계산을 매번 손으로 반복하게 됩니다. 그렇다고 LLM에게 계산을 시키면 안 됩니다. 언어 모델은 산술을 틀립니다. 그것도 그럴듯하게 틀려서 검산하지 않으면 발견하기 어렵습니다.

그래서 역할을 명확히 갈랐습니다.

설계 원칙 — 숫자는 코드, 판단은 LLM

LTV · LTC · 손익분기 분양률 · 트랜치 워터폴 회수액 · 기대손실은 전부 결정론적 함수가 계산합니다. LLM은 그 숫자를 해석하고 GO / HOLD / DROP 의견을 냅니다. 의견은 Enum으로 제한해 모델이 애매한 표현으로 빠져나갈 수 없게 했습니다.

단순 금리 순으로 정렬하면 위험한 딜이 위로 올라옵니다. 그래서 가중평균 대출금리에서 연환산 기대손실을 뺀 값으로 순위를 매깁니다. 같은 8% 딜이라도 담보와 트랜치 구조에 따라 실제 순위가 뒤집힙니다.

딜 목록을 넣으면 신용 지표가 계산된 표와 각 딜에 대한 언더라이팅 의견, 위험조정 순위가 담긴 HTML 리포트가 나오고 메일로 발송됩니다.

수치 부분은 테스트로 고정돼 있어, 모델을 바꾸거나 프롬프트를 고쳐도 숫자는 흔들리지 않습니다.

이 프로젝트에서 정리한 원칙이 이후 다른 에이전트의 기본형이 됐습니다. 데일리 브리프 에이전트에서는 수집·URL 매핑을 코드가 맡고 모델은 해석만 하고, SitePilot의 세금 엔진도 같은 이유로 전부 결정론적 코드입니다.

LLM을 쓰는 일이 늘어날수록 모델에게 시키지 않을 것의 목록이 더 중요해진다고 느낍니다.