모놀리스·서비스 분리·서버리스: 운영 조건으로 선택하기
배포 단위와 데이터 경계, 비용식을 먼저 정하고 구조를 고르는 의사결정 예제입니다.
작은 서비스를 시작할 때 모놀리스와 마이크로서비스 중 어느 쪽이 더 현대적인지보다 누가 배포하고 누가 장애를 복구할지 먼저 정하는 편이 좋습니다. 코드 경계, 배포 경계, 저장소 경계는 서로 다른 선택입니다. 이 글은 가상의 소규모 주문 서비스를 예로 그 차이를 설명합니다.
같은 저장소와 같은 서비스는 다르다
모노레포는 여러 구성요소를 한 저장소에서 관리하는 방식이지 반드시 하나의 프로세스로 실행한다는 뜻은 아닙니다. 공통 코드를 쉽게 바꾸는 대신 영향 범위 검사와 소유권 규칙이 필요합니다. 반대로 저장소를 나눈다고 데이터나 배포 의존성이 저절로 분리되지는 않습니다.
주문과 알림 코드가 한 저장소에 있어도 모듈 경계를 분리할 수 있습니다. 먼저 함수 호출과 데이터 접근 경계를 명확히 하고, 독립 배포가 실제로 필요한지 확인합니다.
분리할 이유를 증상으로 적기
| 관찰한 문제 | 먼저 시도할 작은 변경 | 서비스 분리를 검토할 조건 |
|---|---|---|
| 알림 작업이 응답을 늦춤 | 작업 큐와 처리량 제한 | 독립 확장과 운영 담당이 필요 |
| 배포 충돌이 잦음 | 모듈 소유권과 테스트 분리 | 서로 다른 배포 주기가 지속 |
| DB 변경이 모든 기능에 영향 | 데이터 접근 경계 정리 | 독립된 데이터 책임이 명확 |
서버를 나누면 네트워크 실패, 인증, 추적, 데이터 일관성 문제도 생깁니다. 기능 하나를 호출하던 코드를 원격 호출로 바꾸기 전에 타임아웃과 재시도 시나리오를 작성합니다.
서버리스 비용 비교표 만들기
서버리스와 상시 서버는 과금 구조가 다르므로 요청당 가격 하나만 비교하지 않습니다. 아래 항목에 실제 공급자의 현재 단가와 사용량을 넣습니다.
월 비용 추정 = 실행 비용 + 요청 비용 + 저장 비용
+ 네트워크 전송 + 로그/관측 비용 + 상시 리소스
이는 견적을 정리하는 틀이지 특정 서비스의 청구 공식이 아닙니다. 무료 구간, 최소 과금, 지역, 약정 여부가 다를 수 있습니다. 평균 트래픽뿐 아니라 피크 시간과 유휴 시간, 초기 실행 지연이 허용되는지도 기록합니다.
작은 결정 기록으로 끝내기
가상 주문 서비스라면 ‘현재는 한 배포 단위로 유지하되 알림 전송을 별도 작업으로 분리한다. 독립 배포 요구가 반복되면 재검토한다’처럼 조건과 재검토 시점을 남깁니다. 기술 이름만 결정문에 쓰지 않습니다.
팀이 복구할 수 없는 복잡도를 도입하면 장애 대응이 어려워집니다. 배포·복구 절차를 작성할 수 있는 구조인지 확인한 뒤 범위를 늘립니다.