지급대행 시스템 설계 회고: 책임의 분리가 만든 안정성

1. 왜 이 문제를 해결해야 했는가

지급대행 서비스는 오픈마켓에서 발생한 거래를 기준으로 판매자별 매출을 집계하고, 정산을 거쳐 실제 송금까지 책임지는 시스템이에요.

이 과정에서 가장 중요한 전제는 단순해요.

"실수는 곧 금전 사고로 이어진다."

초기 시스템은 기능 단위로는 잘 동작하고 있었지만, 거래 처리 로직, 정산 규칙, 송금 처리 로직이 하나의 흐름 안에 섞여 있는 상태였어요.

거래 로직 수정이 정산 결과에 영향을 줄 수 있었고
정산 규칙 변경이 송금 로직까지 함께 건드리는 구조였으며
외부 고객사 연동이 늘어날수록 영향 범위를 예측하기 어려워졌어요

이 상태로 고객사가 늘어난다면, **"어디를 고쳐야 하는지보다, 어디까지 영향이 가는지 알 수 없는 시스템"**이 될 수 있다고 판단했어요.

2. 문제를 어떻게 정의했는가

표면적으로는 "로직이 복잡하다", "테이블이 많다"는 문제처럼 보였어요. 하지만 구조적으로 바라보면 문제의 핵심은 달랐어요.

하나의 변경이 여러 책임을 동시에 흔들고 있음
도메인 간 경계가 코드로 드러나지 않음
테스트 범위를 명확히 나누기 어려움

결국 거래·정산·송금이라는 서로 다른 책임이 하나의 도메인처럼 취급되고 있었어요.

그래서 문제를 다음과 같이 재정의했어요.

"금전 흐름의 각 단계를 독립적으로 이해하고, 독립적으로 변경할 수 없는가?"

3. 선택 가능한 대안들은 무엇이었는가

문제를 정의한 뒤, 몇 가지 선택지를 검토했죠.

① 기존 구조 유지 + 조건 분기 정리

단기적으로 가장 빠른 선택
코드 수정 범위 최소화
하지만 책임 분리는 여전히 불명확

→ 위험을 줄이는 것이 아니라, 관리하는 선택에 가깝다고 판단

② 기능 단위 서비스 분리

외형상 구조는 나뉘어 보임
하지만 도메인 개념 없이 나뉘면 책임은 여전히 섞임
서비스 간 호출 관계가 오히려 복잡해질 가능성

→ "분리했다"는 느낌만 있고, 본질적인 해결은 아니었어요

③ 도메인 중심으로 책임 재정의

거래, 정산, 송금의 역할을 명확히 분리
각 도메인이 자기 책임만 가지도록 설계
테스트와 변경 영향 범위를 명확히 할 수 있음

→ 금전 도메인에서는 가장 보수적이지만, 가장 안전한 선택

4. 그래서 어떤 선택을 했는가

결론적으로 거래·정산·송금 도메인을 명확히 분리하는 구조를 선택했죠.

핵심 결정은 다음과 같았죠.

거래 도메인: 구매자 결제 및 거래 사실의 기록
정산 도메인: 판매자별 매출 집계와 정산 규칙 적용
송금 도메인: 정산이 완료된 금액에 대해서만 송금 처리

도메인 간 통신은 명시적인 인터페이스를 통해서만 가능하도록 제한했어요.

이 선택의 목적은 분명했죠.

"하나의 도메인을 고칠 때, 나머지는 안심하고 믿을 수 있게 만들자."

5. 구현에서 가장 중요했던 포인트

① 도메인별 테이블 재설계

기존에는 거래·정산·송금 정보가 하나의 흐름으로 엮여 있었어요. 이를 도메인 기준으로 다시 나누며 약 30개 이상의 테이블을 재설계했어요.

테이블 구조 자체가 "이 데이터의 책임이 어디에 있는지"를 말해주도록 의도했어요.

② 객체 중심 ORM 설계

단순히 테이블을 나누는 것으로는 충분하지 않았어요.

도메인 엔티티가 자신의 규칙을 스스로 지키도록 설계
다른 도메인의 데이터에 직접 접근하지 않도록 제한
변경 시 컴파일 타임에 드러나도록 구조화

이를 통해 도메인 경계가 코드 레벨에서 자연스럽게 드러나는 구조를 만들고자 했죠.

③ 테스트를 설계의 일부로 포함

금전 도메인에서는 "테스트가 없다"는 것 자체가 리스크라고 판단했어요.

핵심 로직 중심으로 100개 이상의 테스트 코드 작성
도메인 단위 테스트로 변경 영향 범위 최소화
CI 환경에서 배포 전 자동 검증 수행

테스트는 품질 관리 수단이 아니라 안전하게 변경하기 위한 전제 조건이었어요.

6. 결과는 무엇이 달라졌는가

구조 분리 이후 변화는 명확했죠.

도메인별 변경 영향 범위가 명확해짐
외부 고객사 연동 초기 장애 0건
테스트 기반 개발로 배포 안정성 확보
팀 전체 개발 생산성 약 20% 개선

무엇보다 "이 로직을 고쳐도 되는지 고민하는 시간"이 크게 줄었어요.

7. 이 경험을 통해 얻은 판단 기준

이 프로젝트를 통해 확실해진 기준이 있죠.

금전 도메인은 복잡해서가 아니라, 섞이기 때문에 위험해져요
도메인 분리는 구조 미학이 아니라, 리스크 관리예요
테스트는 신뢰를 만드는 가장 현실적인 도구예요

지급대행 시스템에서의 안정성은 기술 스택이 아니라 구조에서 나온다는 것을 체감했죠.

8. 다음에 다시 한다면

초기에는 도메인 분리 기준을 팀원 모두가 같은 언어로 이해하는 데 시간이 필요했어요.

다음에는 코드에 들어가기 전에 도메인 이벤트와 책임을 더 명확히 합의하는 과정을 먼저 가져가고 싶어요.

금전이 오가는 시스템일수록 설계는 빠름보다 명확함이 우선이라는 점을 다시 느꼈죠.