금융상품 계약 직전에 서는 판매 게이트입니다.

판매자가 설명을 마치면 시스템이 상품설명서에서 뽑은 위험항목마다 고객에게 묻습니다. 고객이 자기 말로 답하고, 그 답이 이해로 인정되는지를 재고, 이해가 서지 않으면 계약으로 넘어가지 않습니다.

서명란에 이름을 받는 것과 고객이 이해했는지 확인하는 것은 다릅니다. 불완전판매 분쟁에서 지금 남는 증거는 대개 앞쪽입니다.

AI    이 발화가 항목을 이해한 것인가     →  측정값 (등급 · 근거 인용 · 신뢰도)
룰    이 측정값으로 계약을 열어도 되나    →  판정  (통과 · 보완 · 보류)

모델이 판정하지 않습니다. 게이트 판정은 선언적 룰 파일이 만들고, 모델 출력은 그 룰의 입력일 뿐입니다. 그래서 "왜 막혔는가" 에 발화한 룰 이름으로 답할 수 있고, 같은 발화가 어제와 오늘 다른 등급을 받으면 그건 고칠 버그입니다.

근거 없는 판정은 아예 만들어지지 않습니다. 발화 인용과 루브릭 조항이 비면 생성자가 예외를 던집니다.

왜 그렇게 했는지가 남습니다. 배선·계약 결정이 전수로 한 파일에, 원칙급 결정 8건이 ADR 로 있습니다. 자기 영역을 고치기 전에 그 절을 먼저 읽습니다. 결정이 바뀌면 기존 문서를 고치지 않고 새 기록을 얹습니다 — "그때 무엇을 정했나" 를 나중에도 읽을 수 있어야 합니다.

테스트가 구현과 비슷한 규모입니다. 코드 파일(.java·.py·.ts) 기준으로 구현 27,561줄, 테스트 31,356줄입니다. 선언적 룰 파일을 구현으로 세면 이 문장은 뒤집히므로 세는 규칙을 같이 적습니다.

주장에는 실측을 붙입니다. 리뷰에서 "그럴 것이다" 는 근거가 아닙니다. 고친 자리에 변이를 넣어 그물이 실제로 우는지 확인하고, 0건을 검사하고도 통과하는 그물을 따로 잡습니다. 검사가 눈을 감은 채 초록인 것이 검사가 없는 것보다 나쁩니다.

파일마다 소유자가 있습니다. 남의 영역은 건드리지 않고, 모듈 간 계약을 바꿀 때는 그 계약을 쓰는 사람을 전원 부릅니다.

집계된 이해도 데이터는 "설득하기 쉬운 고객" 목록이 될 수 있습니다. 그래서 그것을 소비할 수 있는 역할을 아예 만들지 않았습니다.

권한을 주지 않는 것과 줄 수 있는 대상이 없는 것은 운영 압박이 들어왔을 때 다르게 작동합니다. 역할이 없으면 부여하려면 코드를 고쳐야 하고, 그 변경은 PR 에 남습니다.

2026 금융 AI Challenge · 4인

정세현	윤지석	오준서	강희진
@gitIt-sehyeon	@yoonjiseok	@junseo2323	@hd0rable