여신금융 · 카드 · 사례
같은 가맹점에 수수료율이 두 개 살아 있는지, 계약을 한 장씩 펼치지 않고 확인한다
이걸로 되는 일한 가맹점에 겹겹이 쌓인 본계약·특약을 가맹점·계약·수수료 조건 엔티티로 잇고, 같은 거래에 살아 있는 상이한 수수료율이나 서로 어긋나는 정산 주기를 충돌 후보로 표시받는다.
새 계약서 한 장이 책상에 올라온다. 어느 가맹점의 프로모션 수수료율을 한 분기만 낮춰 주는 부속 합의다. 담당자는 멈칫한다. 이 가맹점이 작년에 정산 주기를 바꾸는 특약을 따로 맺지 않았던가. 그때 수수료 조건이 어떻게 정리됐는지 확신이 서지 않는다.
문서함에는 같은 가맹점 이름이 적힌 계약이 여러 건 흩어져 있다. 본계약, 업종 변경 합의, 규모에 따른 우대 조건, 프로모션 특약. 각각 다른 시점에, 다른 담당자가, 조금씩 다른 문구와 표 형식으로 작성했다. 새 조건 하나가 이 더미 어딘가와 부딪치는지 확인하려면 사람의 기억과 인내심에 기대야 한다.
먼저 분명히 해 둔다. 이 글은 실제 고객 사례가 아니다. 여신금융(개인·기업에 돈을 빌려주거나 결제를 대신 처리해 주는 금융업) 중에서도 카드사라면 이 문제를 이렇게 풀어 볼 수 있지 않을까 가정해 본 가설 시나리오다. 도입 결과도 수치도 아직 없다.
한 가맹점에 계약이 겹겹이 쌓인다
카드사는 수많은 가맹점과 계약을 맺는다. 그런데 한 가맹점이 단 하나의 계약만 가지는 경우는 의외로 드물다. 처음 가맹할 때 맺은 본계약 위로, 업종이 바뀌면 새 조건이 얹히고, 거래 규모가 커지면 우대 수수료가 붙고, 특정 시즌에는 프로모션 특약이 더해진다. 아래는 그 한 가맹점 앞에 쌓여 있는 자료다.
- 본계약. 처음 가맹할 때 맺은 것이고, 나머지 조건이 전부 이 위에 얹힌다
- 업종 변경 합의. 가맹점의 업종이 바뀌면서 새 조건이 추가됐다
- 규모에 따른 우대 조건. 거래 규모가 커지면서 우대 수수료가 붙었다
- 프로모션 특약. 특정 시즌마다 따로 더해진다. 이번 부속 합의도 여기에 속한다
- 각 계약 안의 조건들. 정산 주기, 수수료율, 적용 기간이 계약마다 조금씩 다른 얼굴로 적혀 있다
- 형식. 상당수가 스캔본이나 PDF로 잠들어 있고, 수수료율은 본문이 아니라 표 안에 들어 있다
- 작성 이력. 각각 다른 시점에, 다른 담당자가, 조금씩 다른 문구와 표 형식으로 썼다
문제는 이 조건들이 서로 무관하지 않다는 데 있다. 새 계약을 한 건 추가하거나 기존 조건을 손볼 때, 그것이 같은 가맹점의 다른 계약과 부딪치지 않는지 확인해야 한다. 같은 거래에 두 개의 수수료율이 살아 있거나, 한쪽에선 월 정산이라 적어 두고 다른 합의에선 주 단위로 정해 두었거나, 특약이 본계약과 정면으로 어긋나는 충돌이 나중에 정산 단계에서야 터지면 곤란하다.
결국 담당자의 기억에 기댄다
지금 절차는 단순하다. 새 건이 들어오면 담당자가 그 가맹점과 관련된 기존 계약을 머릿속으로 떠올리고, 문서함을 뒤져 한 장씩 펼쳐 대조한다. 계약이 몇 건 안 될 때는 이 방법이 통한다. 하지만 계약이 방대해지면 연관된 계약을 빠짐없이 떠올리는 일 자체가 사람의 한계에 부딪힌다.
검색으로 메우려 해도 벽이 있다. '이 계약과 충돌할 수 있는 계약이 무엇인가'라는 질문은 단순 키워드 검색으로는 잡히지 않는다. 충돌은 단어가 겹치는 곳이 아니라 가맹점과 계약과 수수료 조건 사이의 관계를 따라가야 보이기 때문이다. 게다가 같은 조건이라도 계약마다 문구가 다르고 표 형식이 제각각이라, 텍스트를 그대로 맞춰 보는 방식으로는 같은 개념인지조차 알아채기 어렵다.
계약 더미를 관계망으로 바꾼다
준비 단계에서 하는 일은 계약 더미를 서로 연결된 관계망으로 바꾸는 것이다. 온톨로지(개념과 그 사이 관계를 명시적으로 정의한 지식의 뼈대)로 핵심 대상을 정리한다고 보면 된다. 스캔본을 읽히고, 핵심 대상을 엔티티로 뽑고, 표기 변형을 하나로 접는 순서다.
가맹점 계약을 넣는 순서
"소스 추출하기"(⌘⇧I)에 계약서를 넣는다
스캔본이나 PDF로 잠들어 있는 계약서를 OCR(스캔 이미지를 컴퓨터가 읽을 수 있는 글자로 바꾸는 기술)로 읽어, 본문 텍스트뿐 아니라 수수료율이 담긴 표의 구조까지 보존한 채 옮긴다. 표가 무너지면 조건도 함께 무너지기 때문에, 표 구조를 살려 두는 일이 특히 중요하다.
"도메인 어휘"에 표준 표현과 변형을 선언한다
왼쪽 레일의 "도메인 어휘" 패널에서 표준 술어와 그 변형을 선언해 둔다. "월 정산"과 "매월 1회 정산"이 같은 뜻이라면, 추출 시점에 하나로 접혀 시스템 안에서 같은 점으로 합쳐진다. 계약마다 문구가 달라도 같은 개념이면 하나의 노드가 된다.
활동 센터의 "이 워크스페이스를 지식그래프로 만들까요?" → "만들기"
가맹점(Merchant), 계약(Contract), 수수료·조건(Fee·Term)이 각각 엔티티로 뽑히고, '가맹점은 다수의 계약을 가진다', '계약은 다수의 수수료 조건을 가진다' 같은 관계로 이어 붙는다. 이렇게 만들어진 지식그래프(개념들이 관계로 이어진 지도) 옆에 계약서 원본 파일은 그대로 남는다.
"엔티티 테이블"에서 뽑힌 결과를 훑는다
가맹점과 계약, 수수료 조건이 의도한 대로 정리됐는지 여기서 확인한다. 이 가맹점 하나에 계약이 몇 겹으로 쌓여 있었는지도 여기서 눈으로 본다.
충돌할 수 있는 계약을 묻는다
"@프로모션-수수료-부속합의 이 가맹점과 맺은 계약을 전부 보여 줘."
→ 가맹점 엔티티에서 출발해 관계의 선을 따라간 결과가 한 화면에 펼쳐진다.
본계약, 업종 변경 합의, 규모별 우대 조건, 프로모션 특약이 함께 딸려 나온다.
키워드를 던지는 게 아니라 관계를 따라가므로,
담당자가 미처 떠올리지 못한 계약도 같이 끌려 나온다.
"이 부속 합의의 수수료율과 충돌할 수 있는 조건이 있나?"
→ 같은 가맹점·같은 거래에 상이한 수수료율이 살아 있는 지점,
특약이 본계약과 어긋나는 지점이 규칙에 따라 충돌 후보로 표시된다.
각 줄에 그 조건이 적힌 문장과 출처 계약서가 함께 붙는다.
"이 가맹점의 정산 주기는 계약마다 어떻게 적혀 있나?"
→ "월 정산"과 "매월 1회 정산"은 같은 점으로 모여 있고,
한쪽이 월 단위, 다른 합의가 주 단위로 잡혀 있으면
서로 모순되는 정산 주기로 나란히 표시된다.이 답이 되는 이유는 계약이 텍스트가 아니라 엔티티와 관계로 저장돼 있기 때문이다. 가맹점 하나에서 출발해 '계약을 가진다', '수수료 조건을 가진다'는 선을 따라가면 그 가맹점에 연결된 모든 계약과 조건이 한 화면에 펼쳐진다. 사람이 관련 계약을 빠짐없이 떠올릴 필요가 없다.
모든 사실에는 어느 계약서가 말한 것인지가 함께 붙어 있다. 연결 칩에 마우스를 올리면 그 사실을 말한 원문 문장이 "{노트} · {n}번째 줄" 형식으로 인용되고, 엔티티 페이지의 "당신의 표현으로"는 계약서에 실제로 적힌 문구를 그대로 보여 준다. 표기가 정규화돼 하나로 합쳐져도, 원래 계약서가 뭐라고 썼는지는 그대로 남는다. 담당자는 처음부터 모든 계약을 전수 대조하는 대신, 시스템이 짚어 준 곳을 열어 확인하고 판단한다.
무엇이 달라질 수 있나
| 예전 | 지금 |
|---|---|
| 담당자가 관련 계약을 머릿속으로 떠올리고 문서함을 뒤져 한 장씩 펼쳐 대조한다 | 가맹점 하나에서 출발해 관계의 선을 따라가면 연결된 모든 계약과 조건이 한 화면에 펼쳐진다 |
| '충돌할 수 있는 계약이 무엇인가'는 키워드 검색으로 잡히지 않는다 | 관계를 따라가므로 사람이 미처 떠올리지 못한 계약까지 함께 끌려 나온다 |
| 계약마다 문구와 표 형식이 달라 같은 개념인지조차 알아채기 어렵다 | "도메인 어휘"에 변형을 선언해 두면 "월 정산"과 "매월 1회 정산"이 같은 점으로 합쳐진다 |
| 관련 계약을 빠뜨렸는지 확인할 방법이 없어 전수 대조부터 시작한다 | 시스템이 의심 지점을 먼저 좁혀 주고, 사람은 그 위에서 판단에 집중한다 |
그럼에도 이 시나리오를 실제 계약 데이터로 검증해 볼 만한 이유는 질문의 모양 때문이다. '이 계약과 충돌할 수 있는 계약이 무엇인가'는 가맹점에서 계약으로, 계약에서 수수료 조건으로 선을 따라가야 답이 나오는 질문이다. 계약을 엔티티와 관계로 저장해 두면 그 선을 그대로 따라갈 수 있다.