금융 시스템에 MSA를 도입하기 전에 반드시 짚어야 할 것들

마이크로서비스 아키텍처(MSA)는 이제 낯선 개념이 아닙니다. 서비스의 독립적인 배포, 장애 격리, 조직 단위의 자율성 등 MSA가 주는 이점은 분명하며, 금융권에서도 차세대 시스템이나 채널계 재구축 프로젝트에서 MSA 도입을 검토하는 사례가 꾸준히 늘고 있습니다.

그러나 MSA는 "모놀리식을 여러 개로 쪼개는 것"이 아닙니다. 특히 단일 트랜잭션으로 데이터 정합성을 보장해 오던 금융 시스템에서는, 도입 전 검토가 부족할 경우 프로젝트 일정 지연은 물론 데이터 정합성 훼손이라는 치명적인 문제로 이어질 수 있습니다. 계정계·수신·여신 등 다양한 업무와 원장 등이 얽혀 있는 금융 업무의 특성상, 아키텍처 결정 하나가 업무 설계 전체를 뒤흔들 수 있기 때문입니다.

이 글에서는 금융 시스템을 MSA로 구성할 때 반드시 고려해야 할 사항들을 서비스(업무) 관점, 인프라/아키텍처 관점, 운영 관점으로 나누어 정리하고, 이를 간과했을 때 실제로 어떤 문제가 발생하는지 살펴보겠습니다.

설명에는 간단한 예시를 함께 사용하겠습니다. 계좌·뱅킹·여신 세 업무로 구성된 시스템으로, 뱅킹(이체 등)과 여신(대출 실행 등)은 거래 과정에서 계좌 서비스를 참조하여 계좌 정보를 확인하고 잔액을 변경합니다. 모놀리식에서는 이 참조가 같은 애플리케이션 내부의 메서드 호출이자 하나의 트랜잭션이었지만, MSA에서는 서비스 경계를 넘는 네트워크 호출이 되고 트랜잭션도 분리됩니다.

그림 1. 동일한 업무 구성이라도 서비스 경계가 생기는 순간, 계좌 참조는 네트워크 호출이 되고 하나의 거래가 여러 트랜잭션으로 나뉩니다

1. 서비스(업무) 관점 — MSA의 성패는 업무 설계에서 갈린다

MSA 도입 검토에서 가장 먼저, 그리고 가장 깊게 들여다봐야 할 영역은 인프라가 아니라 업무 그 자체입니다.

1-1. 서비스 간 결합도: 정말 분리할 수 있는가?

현재 시스템의 업무들이 서로 얼마나 결합되어 있는지, 그리고 그 결합을 실제로 끊어낼 수 있는지를 먼저 판단해야 합니다. 단순히 "수신 따로, 여신 따로"처럼 조직도 기준으로 서비스를 나누는 것은 위험합니다. 하나의 거래가 여러 업무 테이블을 갱신하고 있다면, 그 거래는 서비스 경계를 넘는 순간 더 이상 단일 트랜잭션이 아니게 됩니다.

1-2. 분리된 서비스의 독립성 수준

서비스를 분리했다고 해서 끝이 아닙니다. 분리된 서비스가 어느 정도까지 독립적으로 동작할 수 있는지를 평가해야 합니다. 자체 데이터만으로 거래를 완결할 수 있는 서비스와, 매 거래마다 타 서비스를 호출해야 하는 서비스는 독립성의 수준이 전혀 다릅니다. 후자가 많다면 서비스 경계 설계를 다시 검토해야 한다는 신호입니다.

1-3. 서비스 간 연계 시 성능 저하의 용인 범위

피치 못하게 타 서비스와의 연계가 발생하는 경우, 기존 모놀리식 대비 처리 성능 저하가 불가피합니다. 같은 프로세스 내의 메서드 호출이 네트워크를 타는 원격 호출로 바뀌기 때문입니다. 예시의 이체 거래만 보더라도, 뱅킹 서비스는 계좌 서비스로 잔액 조회와 잔액 차감을 위해 최소 두 번의 네트워크 왕복을 수행하게 됩니다. 이 저하가 업무적으로 용인 가능한 수준인지 — 예를 들어 온라인 이체 거래의 응답시간 SLA를 여전히 만족할 수 있는지 — 를 사전에 측정하고 합의해야 합니다.

그림 2. 이체 거래 하나에도 뱅킹 → 계좌 서비스로의 네트워크 왕복이 여러 번 발생하며, 호출 횟수만큼 지연이 누적됩니다

1-4. 보상 트랜잭션이 필요한 케이스의 규모 파악

서비스가 분리되면 트랜잭션도 분리됩니다. 서비스 간 연계 거래에서 한쪽이 실패했을 때 이미 완료된 다른 쪽 처리를 되돌리는 **보상 트랜잭션(Compensating Transaction)**이 필요해집니다. 예시에서 뱅킹 서비스가 출금 내역을 등록·커밋한 뒤 계좌 서비스의 잔액 차감이 실패했다면, 이미 커밋된 출금 내역은 rollback할 수 없으므로 이를 취소하는 별도의 업무 거래로 되돌려야 합니다.

그림 3. 계좌 서비스의 잔액 차감이 실패하면, 이미 커밋된 뱅킹의 출금 내역을 '취소'하는 보상 거래가 필요합니다

도입 검토 단계에서 전체 거래 중 이러한 보상 트랜잭션이 필요한 케이스가 얼마나 되는지를 반드시 산정해야 합니다. 이 숫자가 곧 추가 설계·개발 공수의 규모입니다.

1-5. 보상 트랜잭션 구현이 가능한 업무 도메인인가?

더 근본적인 질문도 필요합니다. 해당 업무가 보상 처리 자체가 가능한 도메인인가? 하는 점입니다. 단순 취소로 원복이 가능한 업무가 있는 반면, 이자 계산이 개입되거나 대외기관으로 이미 전문이 나간 거래처럼 되돌리기가 어렵거나 별도의 정정 절차가 필요한 업무도 있습니다. 보상이 불가능한 업무를 서비스 경계에 걸쳐 놓으면 아키텍처로는 풀 수 없는 문제가 됩니다.

1-6. 거래 중복 방지(멱등성) 설계

네트워크 호출에는 모놀리식의 메서드 호출에 없던 불확실성이 있습니다. 타임아웃이 발생했을 때 그 요청이 실패한 것인지, 성공했지만 응답만 유실된 것인지 호출한 쪽에서는 알 수 없다는 점입니다. 이 상태에서 재시도하면 같은 이체의 잔액 차감이 두 번 실행될 수 있습니다. 따라서 서비스 간 갱신성 호출에는 거래고유번호 기반의 멱등(Idempotency) 처리 — 동일 거래번호의 요청이 다시 들어와도 한 번만 반영되도록 하는 설계 — 가 기본으로 들어가야 합니다. 보상 트랜잭션만큼이나 필수적인 요소이지만, 설계 표준으로 강제하지 않으면 서비스마다 처리가 제각각이 되기 쉬운 영역입니다.

1-7. 업무 재설계로 분산 트랜잭션 자체를 줄일 수 있는가?

가장 좋은 분산 트랜잭션 대응은 분산 트랜잭션이 발생하지 않도록 업무를 재설계하는 것입니다. 거래를 완결성 있는 단위로 재정의하거나, 즉시 반영이 필수가 아닌 처리를 이벤트 기반 비동기 처리로 전환하는 등의 방법으로 서비스 간 동기 결합을 줄일 수 있습니다. 도입 전, 이러한 재설계의 여지가 얼마나 있는지 검토해야 합니다.

1-8. 서비스 경계를 넘는 조회: Join이 사라진다

갱신(트랜잭션)만큼 자주, 그러나 더 늦게 발견되는 문제가 조회입니다. 모놀리식에서는 계좌·여신·고객 테이블을 SQL 조인 한 번으로 처리하던 통합조회 화면이, DB가 서비스별로 분리되는 순간 불가능해집니다. 남는 선택지는 각 서비스의 API를 호출해 애플리케이션에서 조합하거나, 조회 전용 데이터를 별도로 복제·적재(CQRS)하는 것입니다. API 조합은 성능과 페이징 처리에 한계가 있고, 복제 방식은 원본과의 **시차(최종 일관성)**를 업무가 용인할 수 있는지에 대한 검토가 필요합니다. 대고객 통합조회, 콜센터 화면, 경영정보 조회가 많은 금융 시스템에서는 이 조회 전략의 설계가 서비스 경계 설계만큼 중요합니다.

그림 4. 통합조회의 두 가지 접근 — API 조합은 지연과 조인·페이징의 한계가, 조회 전용 복제(CQRS)는 원본과의 시차가 각각 검토 대상이 됩니다

1-9. 대량 배치 처리 방안

이자 계산, 기산일 처리, 마감·결산처럼 금융 시스템의 근간인 대량 배치 역시 데이터 분산의 영향을 정면으로 받습니다. 기존에는 통합 DB에서 대량의 데이터를 직접 읽고 갱신하면 됐지만, MSA에서는 배치가 타 서비스의 DB에 직접 접근할 수 없습니다. 각 배치를 어느 서비스의 소관으로 둘지, 타 서비스 데이터는 API로 받을지 복제 데이터를 활용할지, 대량 갱신 시의 트랜잭션 단위는 어떻게 끊을지가 모두 새로운 설계 대상입니다. 온라인 거래만 보고 서비스를 나눈 뒤 배치 설계 단계에서 막히는 사례가 실제로 매우 많습니다.

1-10. 설계·개발 공수가 실제로 확보되어 있는가?

보상 트랜잭션과 멱등 처리 설계, 조회·배치의 재설계, 업무 재설계는 모두 추가 공수입니다. 문제는 많은 프로젝트가 이 공수를 계획에 반영하지 않는다는 점입니다. "아키텍처는 MSA로 하되, 업무 설계 일정은 기존과 동일하게" 잡는 순간 프로젝트는 이미 위험에 들어선 것입니다. MSA 도입 여부의 최종 판단에는 반드시 충분한 업무 설계·개발 기간과 인력 배정이 가능한지가 포함되어야 합니다.

2. 인프라/아키텍처 관점 — 분산 환경은 그에 맞는 기반을 요구한다

2-1. 분산 환경 솔루션 구성 (Kafka, Redis 등)

MSA에서는 서비스 간 이벤트 전달을 위한 Kafka와 같은 메시지 브로커, 분산된 서비스들이 공유해야 하는 세션·캐시 데이터를 위한 Redis와 같은 분산 캐시가 사실상 필수 구성요소가 됩니다. 이들 솔루션의 도입 자체뿐 아니라 고가용성(HA) 구성, 장애 시 동작 방식까지 아키텍처 설계에 포함되어야 합니다.

2-2. 이벤트 유실 방지: Transactional Outbox

Kafka 기반의 이벤트 연계나 Saga를 도입한다면 반드시 함께 검토해야 할 것이 "DB 커밋은 됐는데 이벤트 발행은 실패"하는 틈입니다. 뱅킹 서비스가 출금 내역을 커밋한 직후 장애가 발생해 이벤트를 발행하지 못하면, 계좌 서비스는 잔액을 차감할 기회조차 얻지 못한 채 정합성이 깨집니다. 업무 데이터와 발행할 이벤트를 하나의 로컬 트랜잭션으로 함께 저장해 두고 별도 프로세스가 이벤트를 발행하는 Transactional Outbox 패턴 등으로 이 틈을 구조적으로 막아야 합니다. 이벤트 발행의 신뢰성은 Saga 전체 신뢰성의 전제조건입니다.

그림 5. 업무 데이터와 발행할 이벤트를 하나의 트랜잭션으로 저장하고 릴레이가 발행 — commit과 발행 사이의 유실 구간이 구조적으로 사라집니다

2-3. 네트워크 성능과 인프라 구성

서비스 간 REST/gRPC 호출, Kafka·Redis 연계는 모두 네트워크를 경유합니다. 즉 MSA에서는 네트워크가 곧 성능입니다. 저지연 네트워크 구성, 서비스 간 통신 경로 최적화, 커넥션 풀 및 타임아웃 정책 등 인프라 수준의 준비가 되어 있지 않으면, 업무 설계를 아무리 잘해도 성능 목표를 달성할 수 없습니다.

2-4. 장애 격리와 전파 차단

MSA의 대표적인 장점으로 장애 격리가 꼽히지만, 격리는 저절로 얻어지는 것이 아니라 설계해야 얻어지는 것입니다. 예시에서 계좌 서비스가 응답 지연에 빠졌을 때 아무 보호 장치가 없다면, 계좌를 호출하는 뱅킹·여신 서비스의 처리 스레드가 응답 대기 상태로 쌓이면서 결국 호출하는 쪽까지 함께 마비됩니다. 모놀리식이었다면 한 모듈의 장애로 끝났을 것이 MSA에서는 전 서비스로 전파되는 연쇄 장애가 될 수 있는 것입니다. 서비스 간 호출에는 타임아웃, Circuit Breaker, 격벽(Bulkhead)과 같은 전파 차단 장치가 표준으로 적용되어야 하며, 차단이 발동했을 때의 대체 동작(fallback)을 업무 관점에서 어떻게 처리할지도 함께 정의되어야 합니다.

그림 6. 차단 장치가 없으면 계좌 서비스의 지연이 뱅킹·여신의 스레드 고갈로 이어지지만, Circuit Breaker가 있으면 장애가 해당 서비스로 국소화됩니다

2-5. Saga 적용이 어려운 경우, 2PC 솔루션 검토

보상 트랜잭션 기반의 Saga 패턴은 MSA에서 분산 트랜잭션을 다루는 대표적인 방식입니다. 그러나 앞서 본 것처럼 보상 설계가 불가능한 업무 도메인이 존재합니다. 이 경우 원자적 커밋을 보장하는 2PC(Two-Phase Commit) 처리를 지원하는 솔루션 도입을 검토해야 합니다. 다만 2PC는 참여 서비스 전체를 묶는 잠금으로 인해 성능 비용이 크다는 점을 함께 인지하고, 적용 범위를 최소화하는 방향으로 설계해야 합니다.

세 가지 대응 방식의 특성을 비교하면 다음과 같습니다.

구분	업무 재설계 (분산 트랜잭션 회피)	Saga (보상 트랜잭션)	2PC 솔루션
정합성 보장 방식	분산 트랜잭션 자체를 제거	실패 시 보상 거래로 원복 (최종 일관성)	참여자 전체의 원자적 commit (강한 일관성)
성능 영향	최소	정상 흐름은 빠름, 실패 시 보상 비용 발생	잠금 유지로 가장 느림
업무 설계 부담	재설계 공수 큼	보상 업무의 설계·개발 필요	상대적으로 적음
적용 가능 조건	재설계의 여지가 있는 업무	보상 정의가 가능한 도메인	보상이 불가능하고 강한 정합성이 필수인 구간
권장 접근	1순위로 검토	기본 선택지	최소 범위로 한정 적용

표 1. 분산 트랜잭션 대응 방식 비교 — 재설계로 회피할 수 있으면 회피하고, Saga를 기본으로 하되, 2PC는 불가피한 구간에만 최소로 적용하는 것이 일반적인 우선순위입니다

2-6. 모니터링 환경 구성

수십 개의 서비스가 각자 배포되고 서로 호출하는 환경에서는, 장애 지점을 찾는 일 자체가 어려워집니다. 서버·서비스의 상태 모니터링, 분산 추적(Distributed Tracing), 중앙화된 로그 수집 체계를 아키텍처 초기 단계부터 함께 설계해야 합니다. 운영을 시작한 뒤에 모니터링을 붙이려 하면 이미 늦습니다.

2-7. Saga 상태 조회와 재처리 편의성

Saga를 도입한다면, 개발 관점뿐 아니라 운영 관점의 도구까지 고려해야 합니다. 지금 어떤 Saga가 어느 단계에서 멈춰 있는지 조회할 수 있어야 하고, 실패한 단계를 운영자가 안전하게 재처리할 수 있어야 합니다. 금융 시스템에서 "실패한 분산 거래가 어디까지 진행됐는지 알 수 없는 상태"는 그 자체로 사고입니다.

2-8. 인스턴스/Pod 구성과 설정 배포 설계

서비스 수가 늘어나면 인스턴스와 Pod의 수는 그 몇 배가 됩니다. 각 서비스의 인스턴스 구성 전략과 함께, 수많은 서비스의 설정을 일관되게 관리·배포하기 위한 Spring Cloud Config Server 등 중앙화된 설정 관리 체계의 설계가 필요합니다. 설정 변경이 각 서비스에 어떻게 전파되고 반영되는지까지 정의되어야 운영이 가능합니다.

3. 운영 관점 — 운영 방식 자체가 달라져야 한다

3-1. 모놀리식과는 다른 운영·관리 체계

하나의 애플리케이션을 배포하고 감시하던 기존 방식은 MSA에 그대로 적용될 수 없습니다. 배포 단위, 장애 대응 절차, 변경 관리 프로세스 모두 다수의 독립 서비스를 전제로 재정립되어야 합니다. 아키텍처만 바꾸고 운영 체계를 그대로 두면, 운영 조직이 아키텍처를 감당하지 못하는 상황이 발생합니다.

3-2. 운영자에게 요구되는 역량의 확장

각 서비스가 독립적인 애플리케이션이 된다는 것은, 담당자가 자신의 업무 영역 지식만으로는 서비스를 관리할 수 없다는 뜻이기도 합니다. 서비스별 설정 구조, 빌드와 의존 라이브러리, 배포 파이프라인에 대한 이해가 운영 역량의 일부가 됩니다. 조직 차원의 교육과 표준화된 개발·운영 환경(프레임워크)의 뒷받침이 필요한 이유입니다.

3-3. 정합성 대사(Reconciliation) 체계

보상 트랜잭션과 멱등 처리를 아무리 잘 설계해도, 분산 환경에서는 불일치가 발생할 수 있다는 전제로 운영을 준비해야 합니다. 대외기관과 거래 내역을 대사하듯, 이제는 내부 서비스 간에도 데이터를 주기적으로 대사하고 불일치를 탐지·보정하는 체계가 필요합니다. 예시 시스템이라면 뱅킹 서비스의 출금 내역 합계와 계좌 서비스의 잔액 변동이 일치하는지를 정기적으로 검증하는 식입니다. 불일치를 얼마나 빨리 발견하고 얼마나 안전하게 보정할 수 있는지가, MSA로 구성된 금융 시스템의 실질적인 정합성 수준을 결정합니다.

3-4. 조직 구조: 시스템만 나누고 조직은 그대로인 경우

콘웨이(Conway)의 법칙이 말하듯 시스템 구조는 조직 구조를 닮아갑니다. 역으로, 시스템은 서비스 단위로 나눴는데 조직은 모놀리식 시절 그대로라면 MSA의 장점은 살아나지 못합니다. 서비스별로 책임지는 팀이 없으면 독립 배포는 결국 전체 조율 회의를 거치는 '함께 배포'로 회귀하고, 장애가 발생하면 서로 소관을 미루게 되며, 서비스 경계에 걸친 요건은 주인이 없어 표류합니다. 실제 프로젝트에서 아키텍처보다 조직이 먼저 한계에 부딪히는 경우가 드물지 않습니다. 서비스별 소유권(오너십), 팀 간 인터페이스 협의 방식, 공통 표준을 관장하는 조직의 역할까지, 아키텍처 전환과 함께 조직 운영 방식의 전환이 계획에 포함되어야 합니다.

4. 이런 고려 없이 도입하면 — 실제로 발생하는 문제들

위 항목들이 검토되지 않은 채 MSA를 도입하면 어떤 일이 벌어질까요. 아래는 실제 프로젝트에서 반복적으로 관찰되는 문제 유형입니다.

① 데이터 정합성 불일치. 분산 트랜잭션에 대한 고려 없이 서비스를 분리하면, 한쪽 서비스는 성공하고 다른 쪽은 실패한 상태가 그대로 남습니다. 금융 시스템에서 이는 단순 버그가 아니라 계정 잔액 불일치, 원장 훼손과 같은 사고로 직결됩니다.

② 보상 설계가 불가능한 환경에서의 뒤늦은 2PC 도입. 보상 업무의 설계·개발이 불가능한 도메인임을 뒤늦게 확인하면, 별도의 2PC 솔루션 도입 외에는 선택지가 없어집니다. 프로젝트 중반에 아키텍처의 핵심 축이 바뀌는 것입니다.

③ 기존 트랜잭션 격리 체계와 다르게 동작하는 데이터 가시성. 모놀리식 구조에서는 하나의 서비스 요청이 단일 트랜잭션으로 처리되므로, 그 트랜잭션이 종료(커밋)되기 전까지는 처리 중인 데이터가 다른 사용자의 요청에 노출되지 않습니다. 그러나 MSA에서는 하나의 서비스 요청이 여러 마이크로서비스로 쪼개지고, 각 마이크로서비스가 자신의 처리분을 커밋한 뒤 다음 서비스로 넘어갑니다. 그 결과 전체 거래는 아직 끝나지 않았는데도 앞 단계에서 커밋된 중간 상태의 데이터가 다른 사용자의 요청에서 조회되는, 기존에는 없던 상황이 발생합니다. "커밋된 데이터 = 완결된 거래의 데이터"라는 전제 위에서 만들어진 기존 조회·배치·연계 업무들이 미완결 거래의 데이터를 활용하게 되는 문제로 이어질 수 있습니다.

그림 7. 모놀리식에서는 거래 완결(commit) 시점에만 변경이 노출되지만, MSA에서는 전체 거래가 미완결인 상태에서 앞 단계의 커밋된 데이터가 타 사용자 요청에 조회될 수 있습니다

④ 공수 미반영으로 인한 일정 실패. 보상 업무 설계가 가능한 도메인이더라도, 그 설계·개발 공수가 프로젝트 계획에 반영되지 않았다면 기간 내 구현은 사실상 불가능합니다. 결국 보상 처리를 생략하거나 수작업 정정에 의존하는 형태로 오픈하게 되고, 이는 운영 리스크로 고스란히 이월됩니다.

⑤ 서비스 간 호출 폭증으로 인한 거래 복잡도 증가. 업무 재설계 없이 시스템만 쪼개면, 하나의 거래가 수많은 서비스 호출로 구성됩니다. 거래 흐름의 추적이 어려워지고 장애 지점 파악에 걸리는 시간이 길어지며, 운영 난이도가 아키텍처 도입 전보다 오히려 높아지는 역설적인 상황이 됩니다.

⑥ 성능 저하. 호출이 많아진 만큼 네트워크 왕복이 누적되어 거래 응답시간이 늘어납니다. 모놀리식에서는 문제없던 거래가 MSA 전환 후 SLA를 만족하지 못하는 사례가 여기서 발생합니다.

⑦ 2PC 솔루션 사용 시의 추가 성능 비용. 2PC로 우회하더라도 공짜는 아닙니다. Prepare/Commit 두 단계의 조율 과정과 그동안 유지되는 잠금으로 인해 성능은 한층 더 저하됩니다. 즉 2PC는 정합성 문제의 해결책일 수는 있어도 성능 문제의 해결책은 아니며, 오히려 성능 관점에서는 비용이 추가되는 선택입니다.

⑧ 통합 조회·배치의 뒤늦은 재설계. 온라인 거래 중심으로 서비스를 분리한 뒤, 설계 후반이나 개발 단계에 이르러서야 통합조회 화면과 대량 배치가 기존 방식으로는 불가능하다는 것을 발견하는 경우입니다. 급한 대로 타 서비스의 DB를 직접 참조하는 우회로를 뚫는 순간, 서비스 간 데이터 결합이 부활하며 애써 나눈 서비스 경계가 무의미해집니다.

⑨ 장애 격리 미설계로 인한 연쇄 장애. Circuit Breaker 등 전파 차단 장치 없이 서비스 간 동기 호출이 얽혀 있으면, 한 서비스의 지연이 호출하는 서비스들의 자원 고갈로 이어지며 전체 장애로 확산됩니다. 장애 격리라는 MSA의 기대 효과가 정반대로 나타나는 것입니다.

⑩ 조직과 운영 체계가 모놀리식 그대로인 경우. 시스템은 나뉘었지만 배포는 여전히 전체가 함께 움직이고, 각 서비스의 주인이 불명확해 장애 대응과 변경 요건이 표류합니다. 독립 배포와 자율성이라는 MSA의 장점은 사라지고, 분산 시스템의 복잡도라는 비용만 남는 최악의 조합이 됩니다.

5. 한눈에 보는 도입 전 점검 체크리스트

지금까지의 고려사항을 점검 질문 형태로 요약하면 다음과 같습니다. 도입 검토 회의에서 이 표의 질문에 답할 수 없는 항목이 있다면, 그 항목이 곧 프로젝트의 리스크입니다.

관점	점검 질문	미검토 시 대표 리스크
서비스	서비스 간 결합을 실제로 끊을 수 있고, 분리 후 독립성이 충분합니까?	호출 폭증으로 거래 복잡도·운영 난이도 증가 (⑤)
서비스	서비스 간 연계로 인한 성능 저하를 SLA가 용인합니까?	응답시간 SLA 미달 (⑥)
서비스	보상 트랜잭션의 규모를 산정했고, 보상이 가능한 도메인입니까?	데이터 정합성 불일치, 뒤늦은 2PC 도입 (①, ②)
서비스	서비스 간 갱신 호출에 멱등 처리가 표준으로 설계됩니까?	재시도 시 중복 거래 발생
서비스	미완결 거래의 중간 커밋 데이터 노출을 업무가 감안하고 있습니까?	미완결 데이터의 잘못된 활용 (③)
서비스	통합조회·대량 배치의 처리 방안이 설계에 포함되어 있습니까?	뒤늦은 재설계, DB 직접 참조 우회 (⑧)
서비스	보상·재설계·조회·배치의 추가 공수가 계획에 반영되어 있습니까?	기간 내 구현 실패 (④)
인프라	Kafka/Redis 구성과 이벤트 유실 방지(Outbox)가 준비되어 있습니까?	이벤트 유실로 인한 정합성 훼손
인프라	타임아웃·Circuit Breaker 등 장애 전파 차단이 표준 적용됩니까?	한 서비스의 지연이 연쇄 장애로 확산 (⑨)
인프라	Saga 상태 조회·재처리와 서비스 간 거래 추적이 가능합니까?	장애 지점 파악 지연, 미완결 거래 방치
운영	서비스 간 정합성 대사(Reconciliation) 체계가 있습니까?	불일치의 장기 미발견
운영	운영 방식과 조직 구조가 서비스 단위로 함께 전환됩니까?	MSA 장점 상실, 복잡도 비용만 잔존 (⑩)

표 2. MSA 도입 전 점검 체크리스트 — 괄호의 번호는 4장에서 설명한 문제 유형과의 대응 관계

맺으며 — MSA는 아키텍처 결정이 아니라 업무 설계의 결정이다

정리하면, MSA 도입의 성패를 가르는 것은 Kafka를 쓰느냐 Kubernetes를 쓰느냐가 아닙니다. 업무를 트랜잭션 관점에서 얼마나 정교하게 재설계할 수 있는가, 그 재설계에 필요한 시간과 인력을 확보할 수 있는가, 그리고 분리된 구조를 감당할 수 있도록 조직과 운영 체계를 함께 바꿀 수 있는가입니다. 인프라와 운영 체계는 그 설계를 뒷받침하는 기반입니다.

특히 데이터 정합성이 곧 신뢰인 금융 시스템에서는, "일단 나누고 나중에 보완"이라는 접근이 통하지 않습니다. 도입 전 검토 단계에서 이 글의 항목들을 하나씩 점검해 보시길 권합니다. 검토 결과에 따라서는 전면적인 MSA가 아니라 일부 영역만 분리하는 단계적 전환이 더 나은 답일 수도 있습니다.

다행인 것은, 이 고려사항들 전부를 프로젝트가 맨바닥에서 직접 만들어야 하는 것은 아니라는 점입니다. 이 글에서 다룬 상당수는 업무 설계의 문제이지만, 그 설계를 받쳐줄 기술 기반은 프레임워크 차원에서 표준으로 제공될 수 있는 영역입니다. 예를 들어 오케스트레이션 방식의 Saga와 동기 HTTP 연계에 대한 자동 보상 호출 체계가 갖춰져 있다면 개발자는 보상 '업무'의 설계에만 집중할 수 있고, Outbox 패턴 기반의 이벤트 유실 방지, Saga 상태 조회·재처리를 위한 모니터링 화면, 거래 GUID 기반으로 서비스를 넘나드는 흐름을 추적하는 통합 모니터링이 기본으로 깔려 있다면 운영 관점의 부담도 크게 줄어듭니다. Kafka·Redis·멀티 데이터소스 연계, Circuit Breaker, 고성능 HTTP 처리 같은 기반 기능도 마찬가지입니다.

자사의 DevOn Boot 솔루션은 금융권 프로젝트에서의 이런 경험들을 바탕으로 위 기능들을 Spring Boot 기반에서 표준화된 형태로 담아가고 있습니다. 각 기능이 실제로 어떻게 동작하는지는 이어지는 글에서 하나씩 다루겠습니다. 중요한 것은 순서입니다 — 프레임워크와 솔루션은 고민을 덜어줄 수는 있어도, 이 글의 고려사항들을 검토하는 일 자체를 대신해 주지는 못합니다.