이커머스 정산 플랫폼 Lemuel 은 자바 마이크로서비스 다섯 개(order·settlement·finance·external-data·operation)와 게이트웨이로 이루어져 있다. 그중 finance-service 에는 대출, 투자, 계정계(GL), 법인카드, 보험, 기업 평판까지 여섯 개 금융 도메인이 한 서비스 안에 들어 있다. 2026-10-27 커밋 기준으로 main 자바 파일이 960개, 테스트 파일이 373개다.

솔직히 이 모델들은 “정산 SaaS 가 이 정도 금융까지 다룰 수 있다” 는 걸 보여 주려고 만든 쪽에 가깝다. 정산 제품이 실제로 대출을 내주거나 보험을 인수할 일은 없다. 그래서 이 글은 기능 목록이 아니라 다음 질문으로 각 도메인을 다시 읽는다.

이 도메인은 본질적으로 무엇을 다루는가. 그리고 코드는 그 본질 중 어디를 잡았고 어디를 비워 두었나.

중간에 은행·ATM·돈이라는 세 개의 렌즈를 끼운다. 셋 다 코드에는 없다. 하지만 이 렌즈를 대 봐야 “우리가 만든 것이 금융의 어느 자리에 있는가” 가 보인다.

0. 출발점 — 이 서비스는 돈을 “취급” 하지 않고 “연계” 한다

설계 문서(ADR 0039)가 사업 전제를 명시한다. 이 프로젝트가 향하는 제품은 정산 SaaS 단독이다. 지급대행(전자금융업)과 신용평가(신용정보법)는 의도적으로 범위 밖에 두고, 고객 자금을 보유하지 않는다. 그래서 모든 금융 기능은 취급(originate)이 아니라 연계(refer)다.

같은 ADR 에 실측도 있다. 대출·투자·카드·보험·예치금 다섯 서비스는 서로 이벤트를 한 건도 주고받지 않았다. 공통 상류는 전부 정산과 주문이었다. 처음 여섯 개로 나눈 경계는 결합도가 아니라 “도메인 이름이 비슷해서” 그어져 있었다. 그래서 하나의 finance-service 로 합쳤고, 슬라이스 경계는 ArchUnit 테스트가 강제한다.

여기서 이 글의 첫 번째 관점이 나온다. 이 서비스가 다루는 모든 금융 상품의 재원은 결국 셀러의 정산금이다.

1. 돈의 관점 — 우리는 돈을 만들 수 없다

영란은행(Bank of England)의 2014년 해설 Money in the modern economy: an introduction 은 현대 경제의 돈을 세 형태로 나눈다. 현금(currency), 은행 예금(bank deposits), 중앙은행 지준(central bank reserves)이다. 짝을 이루는 글 Money creation in the modern economy 은 이렇게 요약한다.

현대 경제에서 돈의 대부분은 시중은행이 대출을 할 때 만들어진다. 은행은 예금자가 맡긴 돈을 그대로 빌려주는 단순 중개자가 아니다.

은행이 대출하면 차주의 계좌에 예금이 새로 생기고, 그 예금이 곧 돈이다. 이 렌즈를 대출 슬라이스의 전표에 대 보면 차이가 선명하다. 선지급(선정산 대출) 전표는 이렇게 기록된다.

선지급   : 차변 LOAN_RECEIVABLE / 대변 CASH
상환     : 차변 CASH            / 대변 LOAN_RECEIVABLE

대변이 CASH 다. 이미 가진 현금이 나가는 구조다. 은행이었다면 대변에는 “고객 예금(부채)” 이 찍히고, 그 순간 세상에 돈이 늘어난다. Lemuel 의 대출은 캐피탈사나 대부업처럼 있는 돈을 빌려주는 비은행 여신이다. 돈을 창조하지 못한다.

코드가 틀린 게 아니다. 오히려 사업 전제(“고객 자금을 보유하지 않는다”)를 정확히 반영한 전표다. 다만 “대출 도메인을 만들었다” 와 “은행을 만들었다” 는 전혀 다른 말이라는 걸 이 두 줄이 보여 준다.

돈의 관점에서 하나 더 볼 것이 있다. 금액 타입이다. 공통 모듈의 Money 는 소수 2자리, HALF_UP 으로 고정된 값 객체다. 반면 대출 상환표는 RoundingPolicy 라는 별도 값 객체를 주입받는다. 원화는 0자리, 달러는 2자리처럼 통화마다 절사 단위가 다르기 때문이다. “돈” 이 하나의 타입이 아니라 통화와 정책을 동반한 값이라는 걸 코드가 알고 있다.

2. 은행의 관점 — 은행이 하는 일 중 우리가 하는 건 무엇인가

은행의 핵심 기능을 거칠게 셋으로 나누면 이렇다.

  1. 예금을 받는다 (부채를 진다)
  2. 대출을 한다 (자산을 만들고, 앞 절대로 돈을 만든다)
  3. 지급결제망에 참여한다 (돈을 옮긴다)

BIS 의 지급결제 시장 인프라 원칙(PFMI) 이 다루는 영역이 3번이다. Lemuel 은 이 셋 중 어느 것도 직접 하지 않는다. 예금은 받지 않고, 대출은 연계하며, 지급은 PG 와 은행에 맡긴다.

그런데 셋 모두와 닮은 구조는 들어 있다.

은행 기능 Lemuel 에서 닮은 자리 차이
예금 settlement 의 예치금(deposit) 슬라이스 — 정산금을 언제 얼마나 내줄지 관리하는 재원 원장 남의 돈을 맡는 게 아니라, 내줄 돈의 시점을 관리한다
대출 선정산 대출 — 셀러의 확정 정산금을 근거로 미리 당겨 준다 신용이 아니라 이미 생긴 채권이 담보다
원장 account 슬라이스의 전사 GL 은행 원장은 고객 잔액이 곧 부채지만, 여기서는 셀러 미지급금이 부채다

은행 관점에서 보면 finance-service 의 정체가 보인다. 은행이 아니라, 은행이 될 필요 없이 은행과 같은 장부를 쓰는 회사다. 그래서 이 서비스에서 가장 중요한 도메인은 대출도 카드도 아니고 장부(GL)다.

3. ATM 의 관점 — 승인과 지급은 다른 사건이다

ATM 은 사용자에게 가장 단순한 금융 기계다. 카드를 넣고, 금액을 누르면 현금이 나온다. 돈의 관점으로 보면 ATM 은 은행 예금(은행의 부채)을 현금으로 바꾸는 창구다. 영란은행이 구분한 세 형태 중 두 번째가 첫 번째로 바뀌는 지점이다.

ATM 에서 사용자가 겪는 순서는 “잔액 확인 → 출금 승인 → 현금 배출” 이다. 그리고 현금이 실제로 나오지 않았으면 승인을 되돌려야 한다. 승인했다 와 돈이 실제로 나갔다 가 서로 다른 사건이라는 것, 이게 ATM 이 주는 교훈이다.

법인카드 슬라이스가 이 구분을 정확히 모델링한다.

  • 승인 홀드(AuthorizationHold) — 한도를 잡아 둔다. 돈은 아직 안 움직였다. 카드사 승인번호가 자연키이자 멱등 키라서, 같은 승인이 다시 들어오면 기존 홀드를 그대로 돌려준다.
  • 매입(CardCapture) — 실제 청구가 확정된다. 승인 하나에 부분매입이 여러 번 올 수 있다.
  • 홀드 만료 스케줄러 — 매입이 끝내 오지 않은 승인은 풀어 준다. ATM 의 “현금 미배출 시 취소” 와 같은 자리다.

가용한도 계산도 이 구분 위에 서 있다.

availableMaster = masterLimit − Σ(ACTIVE 홀드, 계정 단위)
availableSub    = subLimit    − Σ(ACTIVE 홀드, 카드 단위)
available       = min(availableMaster, availableSub)

ATM 과 카드가 다른 점은 시간이다. ATM 은 승인과 현금 배출이 몇 초 안에 한 자리에서 끝난다. 카드는 승인과 매입 사이에 시간이 벌어지고, 그 사이를 홀드가 메운다. 도메인 모델링의 어려움은 늘 이 “사이” 에 있다.

4. 여섯 도메인의 본질

4-1. 계정계(GL) — 본질은 “균형” 과 “되돌릴 수 없음”

장부의 본질은 두 가지다. 차변과 대변이 항상 같다는 것, 그리고 한 번 쓴 기록은 고치지 않고 반대 기록으로만 정정한다는 것.

코드는 균형을 구성적으로 보장한다. 전표 하나가 차변 계정 1 + 대변 계정 1 + 금액 1 이다. 그래서 차대 불일치가 생길 수 있는 전표 자체를 만들 수 없다. 시산표(TrialBalance)의 balanced() 는 이 불변식을 다시 한 번 확인할 뿐이다. 여러 계정쌍이 움직이는 사건은 복합 분개 대신 전표 여러 장으로 쪼개고, 각 전표에 서로 다른 자연키를 준다.

수십 개의 정적 팩토리가 대출·투자·정산 이벤트를 계정과목 조합으로 매핑한다. 이 매핑표가 이 서비스에서 가장 중요한 도메인 규칙이다. 이벤트 출처(토픽)·참조 타입·참조 ID 가 전표의 자연키라서, 같은 이벤트가 두 번 와도 DB 의 UNIQUE 제약이 두 번째를 막는다.

되돌릴 수 없음도 지킨다. 회계 방식을 바꿀 때(ADR 0026) 기존 전표를 고치지 않았다. 남은 잔액을 0 으로 닫는 조정 전표를 새로 썼고, 그 계산은 몇 번을 돌려도 결과가 같다.

4-2. 대출 — 본질은 “시간의 가격” 과 “갚지 않을 가능성”

대출은 미래의 돈을 지금으로 당겨 오는 일이고, 그 값이 이자다. 진짜 어려운 건 이자가 아니라 안 갚을 가능성이다. 국제회계기준 IFRS 9 이 금융자산 손상을 “발생한 손실” 이 아니라 “예상 신용손실” 로 인식하도록 바꾼 것도 이 본질 때문이다.

코드가 잡은 것:

  • 상품 다섯 종류(선정산, 기업 신용, 담보, 개인신용, 리스·할부)를 애그리거트 넷으로 나눴다. 그런데 담보대출과 개인신용대출은 하나로 묶었다. 심사 근거만 다르고 실행·상환·연체 흐름은 같기 때문이다. 대신 “담보 없는 주택담보대출” 이나 “신용점수 없는 개인신용대출” 은 생성 시점에 만들 수 없게 막았다.
  • 신용점수와 등급은 신청 시점 값을 스냅샷으로 보존한다. 나중에 재무제표가 바뀌어도 “그때 왜 승인했나” 를 재현할 수 있다.
  • 마진콜은 대출 애그리거트 밖의 독립 엔티티다. 시가가 오르내리며 한 대출에 여러 번 생기고, 요구액은 발생 시점 값으로 고정된다. 강제 처분은 하지 않고 “이관했다” 는 사실만 남긴다. 처분은 대출 상태머신의 몫이다.
  • 리스 회차표는 계약 시점에 확정되고 바뀌지 않는다. 조건이 바뀌면 재계약이다. 이미 청구된 회차의 근거가 사라지면 안 되기 때문이다.

비어 있는 것: 예상 신용손실 충당금이 없다. 만기가 지나면 배치가 연체·상각 처리하지만, 그 전에 “이 포트폴리오에서 얼마를 잃을 것 같은가” 를 장부에 미리 올리는 단계가 없다. 연계 사업 전제에서는 손실을 지는 주체가 우리가 아니니 맞는 생략이다. 다만 대출의 본질 중 가장 무거운 절반이 빠져 있다는 건 알고 있어야 한다.

4-3. 법인카드 — 본질은 “남의 돈을 먼저 쓰게 해 주는 한도”

신용카드는 “나중에 갚을 것” 을 믿고 지금 쓰게 해 주는 약속이다. 그래서 카드의 본질은 결제가 아니라 한도다.

이 코드의 한도 공식은 이 플랫폼에서만 나올 수 있는 모양이다.

F = 셀러 미지급 정산금 + 홀드백 유보분
R = 인정비율 (기본 0.70)
H = 평판 haircut (A·B 1.00 / C 0.85 / D 0.70 / E 0.00)
masterLimit = floor(F × R × H)

카드 한도의 근거가 개인 신용이 아니라 곧 받을 정산금이다. 은행 관점으로 다시 보면, 매출채권 담보 한도대출에 결제 수단을 붙인 형태다.

R 이 1 이 아닌 이유가 주석에 적혀 있다. F 는 곧 셀러에게 지급될 돈이라, 카드 사용과 정산 지급이 같은 돈을 두 번 쓸 수 있다. 청구 사이클에서 상계를 구현하기 전까지는 R 이 그 위험을 흡수한다. 돈의 관점에서 정확한 걱정이다. 이 문단이 이 서비스에서 가장 “금융다운” 코드라고 생각한다.

임직원 카드는 법인 마스터 한도 안에서 서브한도를 받는다. 애그리거트의 핵심 불변식은 masterLimit ≥ Σ subLimit 하나다.

4-4. 보험 — 본질은 “불확실한 손실을 확정된 비용으로 바꾸는 것”

보험의 본질은 위험의 풀링이다. 많은 사람이 확정된 보험료를 내고, 그중 실제로 사고를 당한 사람이 보상받는다. 그래서 보험사의 핵심 역량은 위험을 가려 받는 인수(underwriting)와, 미래 보험금에 대비한 부채 측정이다. 후자가 IFRS 17 이 다루는 영역이다.

그런데 이 코드에서 가장 깊게 구현된 건 그쪽이 아니라 판매와 수수료다.

  • 보험료 산출: 보험나이 계산(만 나이 기준, 마지막 생일 뒤 6개월이 지나면 +1세)과 요율표 조회. 요율이 없으면 대체값 없이 거부한다.
  • 계약 상태머신: 허용 전이 7개. 2회 연속 납입 실패 → 실효, 부활 창구 안에서만 부활. 허용되지 않은 전이는 조용히 무시하지 않고 예외를 던진다.
  • 설계사 수수료: 초년도 수수료를 정확히 12회로 나눠 선지급한다(합계 1원 오차 없음). 계약이 일찍 끝나면 남은 기간 비율만큼 환수(clawback)한다.
  • 방카슈랑스 집중도: 은행별·생보/손보 부문별로 한 보험사 상품 비중이 25% 를 넘는지 감시한다. 은행 자산 정보가 없으면 적용 대상으로 본다(fail-closed). 위반을 놓치는 게 오탐보다 나쁘다는 판단이다.

정리하면 이 슬라이스는 보험사가 아니라 보험 대리점·판매 채널의 도메인이다. 연계 사업 전제와 정확히 맞는다. 위험을 지는 쪽이 아니라 상품을 파는 쪽의 정확성(수수료, 환수, 규제 비율)을 모델링했다.

4-5. 투자 — 본질은 “가격과 가치의 차이에 대한 판단”

투자는 지금 가격이 미래 가치보다 싸다고 판단해 돈을 넣는 일이다. 판단은 틀릴 수 있고, 그래서 어떤 근거로 판단했는지를 남기는 것이 본질의 절반이다.

  • 가치 평가: PER = 시가총액 ÷ 순이익, PBR = 시가총액 ÷ 자본총계. 적자나 자본잠식이면 숫자를 억지로 내지 않고 “산정 불가” 로 둔다.
  • 투자점수: 수익성 35 + 안정성 35 + 성장성 30 = 100점. 모든 구간 경계가 결정적이다. 값이 없는 지표는 0점으로 보수적으로 처리한다.
  • 주문 시점의 점수와 등급을 스냅샷으로 보존한다. 대출의 신용점수 스냅샷, 정산의 수수료율 스냅샷과 같은 철학이다.
  • 투자 재원은 확정 정산금 − 집행된 투자 합 이다. 여기서도 돈의 출처는 정산이다.

4-6. 평판 — 본질은 “신용의 원재료가 숫자가 아니라 이야기라는 것”

평판 슬라이스는 뉴스 감성을 모아 기업 점수를 만든다. 그 점수는 카드 한도의 H 와 기업 대출 심사에 곱해진다. 신용은 재무제표만으로 정해지지 않는다는 걸 모델로 인정한 셈이다.

이 도메인의 본질은 점수 공식보다 두 규칙에 있다.

  1. 스냅샷은 INSERT 만 한다. 산식이 바뀌어도 과거 점수는 그대로 남는다. 여신에 연계되는 순간 “그 시점에 왜 이 등급이었나” 가 감사 요건이 되기 때문이다.
  2. 셀러와 상장사의 자동 연결은 사업자등록번호 완전 일치일 때만 한다. 부분 일치나 상호 유사도는 쓰지 않는다. 틀린 연결은 남의 회사 평판이 내 카드 한도에 곱해지는 사고이기 때문이다. 후보가 여럿이면 잇지 않고, 운영자가 수동으로 이은 링크는 건드리지 않는다.

5. 여섯 도메인을 관통하는 것

다시 읽어 보면 여섯 슬라이스가 같은 원칙을 반복한다.

원칙 나타나는 곳
판단 근거는 그 시점 값으로 얼린다 신용점수, 투자점수, 평판 스냅샷, 마진콜 요구액, 리스 회차표, 정산 수수료율
사건의 자연키 = 멱등 키 GL 전표(토픽+참조), 카드 승인번호, 매입번호
허용되지 않은 전이는 예외로 드러낸다 대출·카드·청구서·보험 상태머신
모호하면 안전한 쪽으로 닫는다 방카 자산 미등록 → 적용, 평판 후보 복수 → 미연결, 카드↔GL 재원 조회 폴백 없음
모든 재원의 출발점은 정산금 선정산, 카드 한도 F, 투자 가용액

금융 도메인의 본질을 한 문장으로 줄이면 이렇다. 나중에 누가 “왜” 라고 물었을 때, 그 시점의 근거로 답할 수 있어야 한다. 이 코드가 가장 일관되게 지키는 건 이자 계산도 점수 공식도 아니라 이것이다.

은행·ATM·돈의 렌즈로 보면 한계도 분명하다. 이 서비스는 돈을 만들지 못하고(은행이 아니다), 예상 손실을 장부에 올리지 않으며(IFRS 9 의 절반이 없다), 보험의 위험 측정 대신 판매 쪽을 깊게 팠다. 모두 “취급이 아니라 연계” 라는 전제에서 나온 의도적인 비움이다. 전제가 바뀌어 직접 취급하게 되는 날, 가장 먼저 채워야 할 빈칸이 바로 이것들이다.

References