모놀리스로 시작해 마이크로서비스로 쪼개는 판단 순서

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

기능 배포가 느려질 때마다 “이제 마이크로서비스로 바꿔야 하나?”라는 질문이 나옵니다. 그러나 배포 지연의 원인이 코드 구조인지, 승인 절차인지, 테스트 부족인지 구분하지 않은 채 서비스를 쪼개면 장애 지점과 운영비만 늘어날 수 있습니다. 모놀리스 아키텍처와 마이크로서비스의 대결은 기술의 우열이 아니라 현재 조직이 감당할 복잡성을 고르는 문제입니다.

첫째, 느린 배포의 원인부터 둘로 가릅니다

모놀리스가 아니라 개발 절차가 병목일 수 있습니다

하나의 저장소와 배포 단위를 쓰는 모놀리스는 변경 영향 범위가 넓다는 약점이 있습니다. 그렇다고 배포가 느린 원인을 전부 모놀리스 탓으로 돌리면 안 됩니다. 수동 테스트, 한 명에게 몰린 코드 리뷰, 불명확한 승인 권한, 재현하기 어려운 개발 환경이 진짜 병목이라면 서비스를 열 개로 나눠도 속도는 개선되지 않습니다.

최근 한 달간 배포가 지연된 작업을 펼쳐 놓고 시간을 나눠 보세요. 코딩에 2일, 리뷰 대기에 3일, 통합 테스트에 2일이 걸렸다면 구조보다 업무 흐름을 먼저 고쳐야 합니다. 반대로 결제 모듈의 작은 변경 때문에 전체 애플리케이션을 다시 빌드하고 모든 기능을 회귀 테스트하느라 시간이 반복해서 소모된다면 서비스 경계 분리를 검토할 근거가 생깁니다.

• 모놀리스 유지 신호: 리뷰 대기와 수동 승인 시간이 전체 리드타임의 절반 이상입니다.
• 분리 검토 신호: 특정 기능의 변경이 무관한 기능의 테스트와 배포를 계속 막습니다.
• 공통 선행 작업: 빌드, 테스트, 배포 시간을 각각 기록하고 실패 원인을 분류합니다.

서비스를 나누기 전에 시간을 먼저 나누십시오. 측정되지 않은 병목은 아키텍처를 바꾼 뒤에도 그대로 남습니다.

디지털 시스템이 데이터를 표현하고 처리하는 기본 개념은 디지털 용어 설명에서도 확인할 수 있습니다. 중요한 것은 최신 유행어가 아니라 데이터와 변경이 실제로 흐르는 경로를 파악하는 일입니다.

둘째, 기능 목록보다 업무 경계를 그립니다

화면 메뉴대로 쪼개면 서비스 간 호출이 폭증합니다

마이크로서비스 전환에서 흔한 실수는 회원, 상품, 주문처럼 화면에 보이는 메뉴 이름만 보고 서비스를 나누는 것입니다. 실제 업무에서는 주문 생성 과정이 재고 확인, 할인 계산, 결제 승인, 알림 발송과 연결됩니다. 경계를 잘못 그으면 요청 한 번에 여러 서비스를 동기 호출하게 되고, 하나만 느려져도 전체 사용자 경험이 흔들립니다.

데이터를 누가 소유하고 어떤 규칙을 책임지는지를 기준으로 경계를 그려야 합니다. 예를 들어 주문 서비스가 주문 상태를 책임진다면 결제 서비스가 주문 테이블을 직접 수정해서는 안 됩니다. 결제 완료 이벤트를 전달하고 주문 서비스가 자신의 상태를 바꾸는 방식이 경계를 선명하게 만듭니다. 이 규칙을 지킬 수 없다면 독립 서비스가 아니라 네트워크로 연결된 분산 모놀리스가 됩니다.

1. 고객이 요청한 순간부터 완료될 때까지 업무 흐름을 한 줄로 적습니다.
2. 각 단계에서 생성하거나 변경하는 핵심 데이터를 표시합니다.
3. 같은 규칙과 데이터에 함께 변경되는 기능을 하나의 후보 경계로 묶습니다.
4. 후보 사이에 필요한 동기 호출과 비동기 이벤트 수를 세어 봅니다.

경계가 애매한 영역은 억지로 분리하지 않는 편이 낫습니다. 상품 가격과 프로모션 규칙이 매주 함께 바뀐다면 초기에는 같은 모듈에 두고, 변경 패턴이 갈라지는 시점에 떼어낼 수 있습니다. 독자 여러분의 조직에서도 두 기능을 서로 다른 팀이 맡고 있지만 매번 동시에 수정한다면, 조직도보다 업무 결합도가 더 정확한 답을 주고 있는 셈입니다.

셋째, 모놀리스와 마이크로서비스의 비용표를 만듭니다

서버 요금보다 사람의 운영 시간이 더 큰 비용입니다

작은 스타트업의 모놀리스는 애플리케이션 한 세트, 데이터베이스 한 개, 단순한 배포 파이프라인으로 운영할 수 있습니다. 마이크로서비스는 각 서비스의 실행 환경뿐 아니라 로그 수집, 분산 추적, 서비스 인증, 비밀정보 관리, 재시도 정책과 장애 경보가 필요합니다. 인스턴스 비용이 낮아 보여도 운영 구성요소와 담당자의 대응 시간을 더하면 계산이 달라집니다.

아래 비교는 특정 클라우드 상품의 고정 가격표가 아니라 팀 내부 견적을 만드는 틀입니다. 2026년에도 실제 비용은 리전, 트래픽, 약정, 관리형 서비스 선택에 따라 크게 달라지므로 공급자 계산기로 다시 산출해야 합니다. 핵심은 월 청구서와 함께 개발·운영 시간을 비용으로 환산하는 것입니다.

• 서비스별 월 인프라비와 공용 플랫폼 비용을 분리해 적습니다.
• 당직, 장애 조사, 배포 관리에 드는 월간 시간을 인건비로 환산합니다.
• 전환 기간의 이중 운영비와 기능 개발 지연 비용도 포함합니다.

예를 들어 엔지니어 5명인 팀에서 매주 10시간이 배포 조정과 장애 추적에 추가된다면, 저렴한 컨테이너 몇 개보다 이 시간이 훨씬 비쌀 수 있습니다. 반대로 특정 기능의 트래픽 때문에 전체 시스템을 세 배로 확장하고 있다면 독립 확장으로 절약되는 비용이 운영 부담을 상쇄할 가능성이 있습니다.

넷째, 한 번에 갈아엎지 말고 한 경계만 떼어냅니다

첫 후보는 중요도가 아니라 독립성과 학습 가치로 고릅니다

전환 첫 대상으로 결제처럼 가장 중요한 기능을 고르면 학습 과정의 실수가 곧 매출 손실로 이어질 수 있습니다. 반대로 아무 영향도 없는 내부 기능을 선택하면 분리 효과를 검증하기 어렵습니다. 변경 빈도가 높고 경계는 비교적 명확하며, 실패해도 복구 가능한 기능이 첫 후보로 적합합니다. 알림 발송, 파일 변환, 검색 색인 생성 같은 비동기 작업이 자주 선택되는 이유입니다.

기존 모놀리스의 코드를 즉시 삭제하지 말고 새 서비스 앞에 명확한 인터페이스를 둡니다. 일부 요청만 새 서비스로 보내 결과와 오류율을 비교한 뒤 비중을 늘리는 방식이 안전합니다. 데이터 이전이 필요하다면 처음부터 두 시스템이 같은 테이블을 공동 소유하게 하지 말고, 원본 소유자를 정한 다음 이벤트나 변경 데이터 캡처로 복제하는 기간을 둡니다.

1. 후보 기능의 입력, 출력, 데이터 소유권을 문서 한 장에 적습니다.
2. 모놀리스 내부 호출을 인터페이스로 감싸 교체 가능한 지점을 만듭니다.
3. 새 서비스를 구축하고 테스트 트래픽으로 응답과 상태 변화를 대조합니다.
4. 사용자 트래픽을 5%, 20%, 50%처럼 나눠 전환합니다.
5. 오류율과 지연 시간이 기준을 넘으면 즉시 기존 경로로 되돌립니다.

정보기술의 범위와 역할을 이해할 때는 IT 개념 자료도 참고할 만합니다. 아키텍처 전환 역시 코드를 옮기는 작업에 그치지 않고 사람, 절차, 데이터 처리 방식을 함께 바꾸는 IT 운영 과제입니다.

첫 분리의 목표는 완벽한 마이크로서비스가 아니라 우리 팀이 배포·관측·복구를 독립적으로 수행할 수 있는지 확인하는 것입니다.

다섯째, 장애와 데이터 불일치로 승부를 검증합니다

정상 동작보다 실패했을 때의 행동을 시험합니다

모놀리스에서는 함수 호출이 실패하면 같은 프로세스 안에서 오류를 처리하고 데이터베이스 트랜잭션을 되돌릴 수 있습니다. 마이크로서비스에서는 네트워크 지연, 응답 유실, 중복 메시지, 부분 성공이 일상적인 조건이 됩니다. 결제는 완료됐지만 주문 상태가 갱신되지 않거나, 재시도로 쿠폰이 두 번 발급되는 문제가 대표적입니다.

따라서 성능 테스트만 통과했다고 전환을 완료해서는 안 됩니다. 호출 대상 서비스를 강제로 중단하고, 메시지를 중복 전달하고, 데이터베이스 응답을 늦춰 보세요. 이때 재시도 횟수, 타임아웃, 서킷 브레이커, 중복 방지 키가 예상대로 작동하는지 확인해야 합니다. 사용자가 같은 버튼을 두 번 눌러도 결과가 한 번만 반영되는 멱등성은 특히 주문과 결제 흐름에서 중요합니다.

• 복구 목표: 장애 감지부터 정상화까지 허용 시간을 서비스별로 정합니다.
• 데이터 목표: 서로 다른 저장소의 상태가 맞춰져야 하는 최대 시간을 명시합니다.
• 관측 목표: 하나의 요청 식별자로 여러 서비스의 로그와 추적 정보를 연결합니다.
• 운영 목표: 담당자가 문서만 보고 롤백하거나 우회 경로를 열 수 있게 합니다.

승패를 판단하는 지표도 바뀌어야 합니다. 배포 횟수가 늘었더라도 변경 실패율과 평균 복구 시간이 나빠졌다면 성공적인 분리가 아닙니다. 반대로 한 서비스의 장애가 다른 기능으로 전파되지 않고 담당 팀이 15분 안에 독립 복구했다면, 추가 운영비를 감수할 분명한 가치가 생긴 것입니다.

여섯째, 2주 실험과 월 40시간 한도로 결정합니다

숫자를 넘으면 더 쪼개지 않고 기반부터 보강합니다

최종 선택을 감에 맡기지 않으려면 짧은 실험에 현실적인 한도를 붙여야 합니다. 첫 후보 서비스에 개발 2주, 운영 준비 20시간, 월 추가 관리 40시간 같은 상한을 정해 보세요. 이 숫자는 모든 회사의 정답이 아니라 작은 스타트업이 비용 폭주를 조기에 발견하기 위한 기준선입니다. 팀 규모와 장애 위험에 맞게 조정하되 상한 자체는 반드시 문서로 남깁니다.

2주 동안 서비스 분리, 자동 배포, 대시보드, 롤백까지 만들 수 없다면 원인을 기록합니다. 플랫폼 기반이 부족한 것인지, 업무 경계가 틀린 것인지, 담당자가 분산 시스템 운영 경험이 없는 것인지에 따라 다음 투자가 달라집니다. 플랫폼 부족이라면 템플릿과 공통 관측 도구를 먼저 만들고, 경계가 틀렸다면 모듈형 모놀리스로 돌아가 내부 의존성을 줄이는 편이 경제적입니다.

1. 첫 주에는 경계 정의와 인터페이스 구축에 최대 20시간을 배정합니다.
2. 둘째 주에는 배포, 장애 주입, 롤백 검증에 최대 40시간을 배정합니다.
3. 전환 후 한 달 동안 추가 클라우드 비용과 운영 시간을 매주 기록합니다.
4. 배포 리드타임이 30% 이상 줄거나 장애 영향 범위가 명확히 감소했는지 확인합니다.
5. 월 추가 운영이 40시간을 넘으면 두 번째 분리를 멈추고 공통 기반을 보강합니다.

팀원이 4명인데 한 명이 매주 하루를 서비스 관리에 쓴다면 월 약 32시간이 소모됩니다. 여기에 당직과 장애 훈련 8시간을 더하면 월 40시간에 도달합니다. 이 비용으로 배포 시간이 줄지 않고 매출 기능의 안정성도 높아지지 않았다면 모놀리스 유지가 더 기술적인 선택입니다. 반대로 월 40시간 안에서 독립 배포가 주 1회에서 하루 1회로 늘고 장애 복구가 60분에서 15분으로 줄었다면, 다음 경계를 분리할 숫자상의 근거가 마련됩니다.