통신업에서 MSA란 무엇인가? AA가 알아야 할 마이크로서비스 아키텍처

통신업에서 MSA라는 용어는 문맥에 따라 서로 다른 의미로 사용됩니다. 시스템 구축이나 애플리케이션 아키텍처 컨설팅 문맥에서는 일반적으로 Microservices Architecture, 즉 마이크로서비스 아키텍처를 의미합니다.

반면 통신사와 기업 간 계약, 법무, 영업 문맥에서는 Master Service Agreement를 의미할 수도 있습니다. 이 글에서는 애플리케이션 아키텍처 관점의 MSA를 중심으로 설명하고, 마지막에 계약 문맥의 MSA도 구분해서 설명하겠습니다.

1. MSA란?

MSA는 하나의 대규모 애플리케이션을 업무 기능 또는 도메인별로 여러 개의 작은 서비스로 분리하고, 각 서비스를 독립적으로 개발·배포·확장할 수 있도록 구성하는 아키텍처 방식입니다.

각 서비스는 특정 업무에 대한 책임을 가지며, 다른 서비스와는 API, 메시지, 이벤트 등의 정의된 인터페이스를 통해 통신합니다.

기존 통합 애플리케이션 구조

[통합 통신 업무 시스템]

- 고객관리
- 상품관리
- 가입관리
- 개통관리
- 결제
- 과금
- 청구
- 장애관리
- 알림

기존 통합 애플리케이션 구조에서는 여러 업무 기능이 하나의 애플리케이션과 데이터베이스에 강하게 결합되어 있을 수 있습니다.

이 경우 특정 기능 하나를 변경하더라도 전체 애플리케이션을 수정하고, 전체 시스템을 테스트한 후 배포해야 하는 문제가 발생할 수 있습니다.

MSA 구조 예시

[고객 채널]
 ├─ 모바일 앱
 ├─ 홈페이지
 └─ 대리점 시스템
        │
        ▼
[API Gateway]
        │
 ├─ 고객관리 서비스
 ├─ 상품·요금제 서비스
 ├─ 가입·주문 서비스
 ├─ 개통 서비스
 ├─ 결제 서비스
 ├─ 과금 서비스
 ├─ 청구 서비스
 ├─ 장애관리 서비스
 └─ 알림 서비스

MSA에서는 각 서비스가 자신이 담당하는 업무를 중심으로 구성되며, 서비스 간에는 정해진 인터페이스를 통해서만 통신하는 것을 지향합니다.

2. 통신업에서 MSA가 주목받는 이유

통신업은 고객, 가입자, 회선, 상품, 요금제, 가입, 개통, 결제, 과금, 청구, 네트워크, 장애, 상담 등 다양한 업무가 서로 연결되어 있습니다.

기존 시스템이 장기간 운영되면서 기능이 계속 추가되면 다음과 같은 문제가 발생할 수 있습니다.

• 고객관리, 가입, 과금, 청구 기능이 하나의 애플리케이션에 혼재됨
• 요금제 하나를 변경해도 여러 시스템을 동시에 수정해야 함
• 특정 서비스의 장애가 전체 업무로 전파됨
• 온라인 가입이나 개통량이 증가해도 해당 기능만 독립적으로 확장하기 어려움
• 시스템 전체를 함께 배포해야 하므로 배포 주기가 길어짐
• 신규 5G, IoT, 기업회선, 부가서비스 출시 기간이 길어짐
• 레거시 시스템과 신규 시스템 간 연계가 복잡함
• 데이터의 기준 시스템과 관리 책임이 불명확함
• 장애 발생 시 원인 시스템을 찾기 어려움
• 운영자가 수동 SQL이나 수동 파일 재처리에 의존함

MSA는 이러한 문제를 해결하기 위한 하나의 아키텍처 선택지입니다. 업무 기능을 서비스 단위로 분리하면 기능별 독립 개발, 독립 배포, 독립 확장, 장애 격리 등을 목표로 할 수 있습니다.

다만 MSA를 도입한다고 해서 모든 문제가 자동으로 해결되는 것은 아닙니다. 서비스가 분리되면 서비스 간 통신, 분산 트랜잭션, 데이터 정합성, 장애 추적, 운영 자동화가 더 복잡해질 수 있습니다.

3. 통신업에서 분리할 수 있는 주요 서비스

위 서비스 구분은 일반적인 예시입니다. 실제 서비스 경계는 통신사의 조직 구조, 업무 프로세스, 데이터 소유권, 기존 애플리케이션 구조에 따라 달라질 수 있습니다.

4. 통신업 MSA 적용 예시: 신규 휴대폰 가입

고객이 통신사 온라인 채널에서 신규 휴대폰에 가입하는 과정을 예로 들어 보겠습니다.

4.1 신규 가입 처리 흐름

1. 고객이 홈페이지 또는 모바일 앱에서 가입 신청
2. 가입·주문 서비스가 가입 주문 생성
3. 고객관리 서비스에서 고객 정보 확인
4. 상품관리 서비스에서 요금제와 할인 조건 확인
5. 본인인증 서비스에서 본인확인 수행
6. 결제 서비스에서 가입비 또는 단말기 대금 결제
7. 자원관리 서비스에서 전화번호와 회선 자원 할당
8. 개통 서비스에서 회선 개통
9. 과금 서비스에 가입 상품과 과금 조건 등록
10. 알림 서비스에서 가입 완료 및 개통 완료 메시지 발송

4.2 MSA 기반 가입 구조 예시

[고객]
   │
   ▼
[홈페이지·모바일 앱·대리점 시스템]
   │
   ▼
[API Gateway]
   │
   ▼
[가입·주문 서비스]
   ├── 고객관리 서비스
   ├── 상품관리 서비스
   ├── 본인인증 서비스
   ├── 결제 서비스
      ├── 자원관리 서비스
   ├── 개통 서비스
   ├── 과금 서비스
   └── 알림 서비스

4.3 서비스 간 이벤트 연계 예시

개통이 완료되면 개통 서비스가 모든 시스템을 직접 호출하는 대신, 개통 완료 이벤트를 발행하고 필요한 서비스가 각자의 업무를 처리할 수 있습니다.

[개통 서비스]
      │
      │ ActivationCompleted 이벤트 발행
      ▼
[이벤트 브로커]
      ├── 과금 서비스
      ├── 가입자관리 서비스
      ├── 고객관리 서비스
      ├── 알림 서비스
      └── 데이터 분석 서비스

이 구조에서는 개통 서비스가 과금 서비스, 알림 서비스, 고객관리 서비스를 순서대로 직접 호출하지 않아도 됩니다. 각 서비스는 개통 완료 이벤트를 수신하여 자신의 책임에 맞는 후속 업무를 수행합니다.

5. 가입 처리 중 장애가 발생하면 어떻게 할까?

MSA에서는 하나의 업무가 여러 서비스에 걸쳐 처리되기 때문에 장애와 실패 상황을 반드시 고려해야 합니다.

예를 들어 다음과 같은 상황이 발생할 수 있습니다.

가입 주문 생성: 성공
결제 승인: 성공
전화번호 할당: 성공
회선 개통: 실패
과금 등록: 미처리

이 경우 단순히 오류 메시지만 표시하는 것으로는 부족합니다. 다음과 같은 업무 처리 정책이 필요합니다.

• 결제를 자동 취소할 것인가?
• 회선 개통을 자동 재시도할 것인가?
• 고객에게 가입 보류 상태를 안내할 것인가?
• 운영자가 수동으로 처리해야 하는가?
• 일정 시간 후 자동으로 보상 처리할 것인가?
• 개통 실패 상태를 고객과 운영자에게 어떻게 표시할 것인가?

5.1 장애 처리를 위해 필요한 설계 요소

• 거래 ID : 하나의 가입 거래를 모든 서비스에서 추적하기 위한 식별자
• 멱등성 처리 : 동일 요청이 여러 번 들어와도 중복 처리되지 않도록 하는 기능
• 서비스별 상태 관리 : 가입, 결제, 자원 할당, 개통, 과금의 진행 상태 관리
• 자동 재시도 : 일시적인 네트워크 오류나 시스템 오류에 대한 재처리
• 보상 트랜잭션 : 일부 업무가 성공한 뒤 실패했을 때 이전 업무를 보정하는 처리
• 재처리 큐 : 실패한 업무를 저장하고 운영자가 재처리할 수 있는 기능
• 장애 알림 : 담당자와 운영자에게 오류를 전달하는 기능
• 처리 이력 관리 : 각 서비스의 요청, 응답, 상태 변경 이력 저장
• 운영자 보정 기능 : SQL 직접 수정이 아닌 표준 화면을 통한 예외 처리

결제 취소, 개통 재시도, 가입 보류와 같은 업무 정책은 기술팀이 임의로 결정해서는 안 됩니다. 재무, 고객센터, 상품, 영업, 운영 부서와의 협의가 필요합니다.

6. MSA와 SOA, 모놀리식 아키텍처의 차이

MSA는 단순히 애플리케이션을 여러 개로 나누는 기술이 아닙니다. 업무 책임, 데이터 소유권, 배포 단위, 장애 격리, 운영 체

9. AA가 수행해야 하는 MSA 아키텍처 업무

9.1 현행 시스템 분석

MSA 전환을 검토하기 전에 현재 애플리케이션과 시스템 간 연계 구조를 분석해야 합니다.

• 애플리케이션 목록과 담당 조직 확인
• 업무 기능과 애플리케이션 간 매핑
• 시스템 간 API, 파일, DB Link, 배치 연계 조사
• 공유 데이터베이스와 직접 접근 현황 확인
• 중복 기능과 중복 데이터 식별
• 장애 이력과 성능 이슈 분석
• 배포 방식과 운영 수작업 조사
• 레거시 시스템과 신규 시스템 간 의존성 분석

9.2 도메인 및 서비스 후보 도출

현행 업무와 시스템을 분석한 후 서비스 후보를 도출합니다. 이때 단순히 기존 애플리케이션을 잘게 나누는 방식으로 접근해서는 안 됩니다.

다음 기준을 종합적으로 검토해야 합니다.

• 업무 책임
• 조직 담당 범위
• 변경 주기
• 데이터 소유권
• 트랜잭션 범위
• 성능 및 확장 요구사항
• 장애 격리 필요성
• 보안 및 규제 요구사항
• 기존 시스템과의 전환 난이도

9.3 서비스별 책임 정의

9.4 서비스 간 인터페이스 정의

AA는 서비스 간 인터페이스를 정의할 때 단순히 API 목록만 작성해서는 안 됩니다. 각 인터페이스의 업무 목적, 호출 주체, 데이터, 오류 처리, 재처리 기준까지 정의해야 합니다.

9.5 데이터 소유권과 데이터 흐름 정의

AA는 서비스별 데이터 소유권을 정의하고, 데이터가 어떤 경로로 생성·변경·조회되는지 명확하게 작성해야 합니다.

[고객관리 서비스]
      │ 고객 기본정보
      ▼
[가입·주문 서비스]
      │ 가입 주문 생성
      ▼
[결제 서비스]
      │ 결제 완료 이벤트
      ▼
[개통 서비스]
      │ 개통 완료 이벤트
      ▼
[과금 서비스]
      │ 과금 등록
      ▼
[청구 서비스]
      │ 청구서 생성
      ▼
[알림 서비스]

이때 동일한 데이터가 여러 서비스에 저장되는 경우에는 단순 중복인지, 업무상 필요한 스냅샷인지 구분해야 합니다.

예를 들어 고객의 기본 연락처와 주문 당시 배송 연락처는 서로 다른 목적을 가질 수 있습니다. 따라서 동일한 전화번호가 여러 곳에 저장되어 있더라도, 각 데이터의 생성 시점과 변경 기준을 명확히 정의해야 합니다.

9.6 목표 아키텍처와 전환 로드맵 수립

AA는 목표 MSA 구조뿐만 아니라 기존 시스템에서 목표 구조로 전환하는 방법도 정의해야 합니다. 통신업 핵심 시스템은 업무 영향도가 높기 때문에 한 번에 전체를 전환하는 방식은 위험할 수 있습니다.

단계적 전환 예시

1. 현행 시스템과 인터페이스 목록 정리
2. 신규 상품관리 또는 알림 서비스부터 분리
3. 온라인 가입 채널의 API를 신규 서비스와 연계
4. 가입·주문 기능을 단계적으로 분리
5. 결제 및 개통 기능을 신규 서비스로 전환
6. 과금·청구와 레거시 시스템 간 연계 정리
7. 기존 시스템의 사용 여부 확인 후 기능 폐기 또는 데이터 이관
8. 직접 DB 접근과 기존 파일 연계 제거

9.7 아키텍처 검토와 품질 관리

MSA 구축 과정에서 AA는 개발팀이 설계한 서비스가 전체 아키텍처 원칙을 준수하는지 검토해야 합니다.

• 서비스 책임이 중복되지 않는가?
• 서비스 간 직접 DB 접근이 존재하지 않는가?
• API 명세와 이벤트 명칭이 표준을 준수하는가?
• 재시도와 타임아웃 기준이 정의되어 있는가?
• 거래 ID로 전체 업무 흐름을 추적할 수 있는가?
• 중복 요청이 발생해도 업무가 중복 처리되지 않는가?
• 서비스 장애가 다른 서비스로 무제한 전파되지 않는가?
• 개인정보와 결제정보의 접근 권한이 적절한가?
• 서비스별 배포와 롤백이 가능한가?
• 운영자가 실패 거래를 재처리할 수 있는가?

10. AA가 작성해야 하는 주요 MSA 산출물

11. 통신업 MSA 도입 시 자주 발생하는 문제

11.1 기존 시스템을 단순히 잘게 나누는 경우

기존 애플리케이션을 기술적으로 여러 개의 서비스로만 나누면 서비스 간 업무 책임은 여전히 불명확할 수 있습니다.

또한 서비스들이 동일한 데이터베이스를 공유하면 배포 단위만 나뉘었을 뿐, 실질적인 결합도는 그대로 남을 수 있습니다.

11.2 서비스 간 호출이 과도하게 증가하는 경우

하나의 가입 업무를 처리하기 위해 수십 개의 서비스를 순차적으로 호출하면 네트워크 장애와 응답 지연 가능성이 커집니다.

따라서 AA는 서비스 분리와 함께 다음 사항을 검토해야 합니다.

• 하나의 업무 트랜잭션에서 호출되는 서비스 수
• 순차 호출과 병렬 호출 가능 여부
• 동기 호출을 비동기 이벤트로 전환할 수 있는지 여부
• 서비스 장애 시 대체 처리 가능 여부
• 호출 체인의 최대 응답시간

11.3 데이터베이스를 공유하는 경우

여러 서비스가 동일한 데이터베이스를 공동으로 사용하면 데이터 변경 주체가 불명확해지고 서비스별 독립성이 낮아질 수 있습니다.

다만 레거시 전환 초기에는 데이터베이스를 즉시 분리하기 어려울 수 있습니다. 이 경우 다음과 같은 단계적 접근이 가능합니다.

1. 서비스별 테이블 소유권 정의
2. 다른 서비스의 변경 권한 제거
3. 조회용 API 또는 읽기 모델 제공
4. 변경 이벤트 기반 데이터 동기화
5. 서비스별 데이터베이스로 단계적 분리

11.4 운영 체계가 준비되지 않은 경우

서비스 개수만 늘어나고 모니터링, 로그, 배포, 장애 대응 체계가 준비되지 않으면 운영 난이도가 크게 증가할 수 있습니다.

MSA 도입 전 다음 운영 역량을 확인해야 합니다.

• 자동화된 빌드와 배포 체계
• 서비스별 로그 수집 및 검색
• 분산 추적 체계
• 서비스별 모니터링 대시보드
• 장애 알림과 온콜 체계
• 실패 메시지 재처리 체계
• 배포 롤백 체계
• 서비스별 운영 담당자

12. MSA와 일반적인 시스템 분리의 차이

따라서 MSA의 핵심은 단순한 시스템 개수 증가가 아닙니다. 다음 요소가 함께 갖춰져야 합니다.

• 업무 책임 분리
• 서비스별 데이터 소유권
• 독립 배포
• 독립 확장
• 장애 격리
• 표준화된 API와 이벤트
• 자동화된 배포와 운영
• 분산 환경에서의 모니터링과 추적

13. 통신업에서 MSA의 또 다른 의미

통신 계약이나 B2B 영업 문맥에서 MSA는 Master Service Agreement를 의미할 수 있습니다. 이는 통신사와 기업 고객 간에 체결하는 기본 서비스 계약입니다.

[기본 서비스 계약]
          │
          ├── 회선 서비스 주문서
          ├── IDC 서비스 주문서
          ├── 클라우드 서비스 주문서
          ├── 보안 서비스 주문서
          └── 유지보수 작업지시서

14. 결론

통신업에서 MSA는 고객관리, 상품관리, 가입, 개통, 결제, 과금, 청구, 장애관리 등 다양한 통신 업무를 독립적인 서비스 단위로 분리하고, 서비스 간 API와 이벤트를 통해 연계하는 아키텍처 방식입니다.

AA는 MSA 프로젝트에서 단순히 서비스 구성도를 그리는 역할만 수행하지 않습니다. 다음과 같은 내용을 종합적으로 정의하고 검토해야 합니다.

1. 업무 도메인과 서비스 경계
2. 서비스별 업무 책임
3. 데이터 소유권과 기준 시스템
4. 서비스 간 API와 이벤트 연계
5. 동기·비동기 통신 방식
6. 분산 트랜잭션과 데이터 정합성
7. 장애 격리와 재처리 방식
8. 성능, 가용성, 보안, 확장성
9. 로그, 모니터링, 분산 추적
10. 레거시 시스템 전환 전략
11. 서비스별 운영 책임과 배포 체계

결국 통신업에서 MSA의 핵심은 애플리케이션을 무조건 작게 나누는 것이 아닙니다. 비즈니스 변화에 빠르게 대응하고, 서비스별 책임을 명확히 하며, 장애와 변경의 영향을 줄일 수 있도록 애플리케이션 구조를 설계하는 것입니다.

또한 MSA 도입 대상과 전환 방식은 통신사별 현행 시스템, 업무 규정, 데이터 처리량, 규제 요건, 운영 역량에 따라 달라질 수 있으므로 실제 프로젝트에서는 사전 진단과 확인이 필요합니다.

참고자료

• Martin Fowler, Microservices

키워드: 통신업 MSA, 마이크로서비스 아키텍처, Application Architecture, AA, 통신사 시스템, BSS, OSS, 과금 시스템, 청구 시스템, 개통 시스템, 서비스 분리, 데이터 소유권, API 아키텍처

PPT를 통한 제안서, 보고서 등 문서 작업 시 입력값의 수정/변경/되돌리기를 위한 실행 취소(뒤로가기)는 필수 불가결한 요소이죠.

하지만 ctrl+z을 연타 하다보면 어느 순간 뒤로가기는 비활성화되고 내가 되돌리고 싶은 지점까지 가지 않아 난처해질 때가 간혹 있으실텐데요(특히 텍스트의 경우 입력시간에 따라 종종 음소 단위로 실행 취소가 되는지라 이런 경우를 더 많이 겪게 됩니다),

기본 20회 실행 취소 횟수 값을, 설정 변경을 통해 더 늘릴 수가 있습니다.

파일 > 옵션 > 고급 > 편집 옵션 > 실행 취소 최대 횟수 (최대 150회까지 가능)

불편을 느끼지만 의외로 많이들 모르시는 설정이라 공유드립니다.

가벼운 설정을 통해 작업 시 난처한 상황 겪지 않으시기 바랍니다.

import org.apache.poi.xssf.usermodel.*;
import org.apache.poi.ss.usermodel.*;
import org.apache.poi.ss.util.CellRangeAddressList;
import org.apache.poi.ss.usermodel.DataValidationConstraint;
import org.apache.poi.ss.usermodel.DataValidation;

import java.io.FileOutputStream;

public class XlsxDropdownDirectList {
    public static void main(String[] args) throws Exception {
        XSSFWorkbook wb = new XSSFWorkbook();
        XSSFSheet sheet = wb.createSheet("입력");

        // 드롭다운을 적용할 영역 (행 1~20, 열 0 = A열)
        CellRangeAddressList addressList = new CellRangeAddressList(1, 20, 0, 0);

        // 문자열 목록을 직접 지정
        DataValidationHelper helper = sheet.getDataValidationHelper();
        DataValidationConstraint constraint =
                helper.createExplicitListConstraint(new String[]{"사과", "바나나", "체리"});

        DataValidation validation = helper.createValidation(constraint, addressList);
        validation.setSuppressDropDownArrow(false); // 드롭다운 화살표 표시
        validation.setShowErrorBox(true);

        sheet.addValidationData(validation);

        try (FileOutputStream fos = new FileOutputStream("dropdown_direct_list.xlsx")) {
            wb.write(fos);
        }
        wb.close();
    }

import org.apache.poi.xssf.usermodel.*;
import org.apache.poi.ss.usermodel.*;
import org.apache.poi.ss.util.CellRangeAddressList;
import org.apache.poi.ss.util.CellReference;
import org.apache.poi.ss.usermodel.DataValidationConstraint;
import org.apache.poi.ss.usermodel.DataValidation;

import java.io.FileOutputStream;

public class XlsxDropdownHiddenSheet {
    public static void main(String[] args) throws Exception {
        XSSFWorkbook wb = new XSSFWorkbook();

        // 1) 목록 데이터 시트 생성 및 값 입력
        XSSFSheet listSheet = wb.createSheet("목록");
        String[] fruits = {"사과", "바나나", "체리", "포도", "멜론"};
        for (int i = 0; i < fruits.length; i++) {
            Row r = listSheet.createRow(i);
            r.createCell(0).setCellValue(fruits[i]);
        }

        // 2) 이름 범위(Defined Name)로 리스트 범위를 지정 (동적 확장 필요시 테이블/함수 사용 가능)
        Name namedRange = wb.createName();
        namedRange.setNameName("Fruits");
        // A1:A5 을 범위로 지정
        String refersTo = "목록!$A$1:$A$" + fruits.length;
        namedRange.setRefersToFormula(refersTo);

        // 3) 입력 시트 생성 및 데이터 유효성 검사(목록) 적용
        XSSFSheet inputSheet = wb.createSheet("입력");
        CellRangeAddressList addressList = new CellRangeAddressList(1, 50, 0, 0); // A2:A51

        DataValidationHelper helper = inputSheet.getDataValidationHelper();
        // 목록을 이름 범위로 참조
        DataValidationConstraint constraint =
                helper.createFormulaListConstraint("Fruits");

        DataValidation validation = helper.createValidation(constraint, addressList);
        validation.setSuppressDropDownArrow(false);
        validation.setShowErrorBox(true);
        inputSheet.addValidationData(validation);

        // 4) 목록 시트 숨김
        int idx = wb.getSheetIndex(listSheet);
        wb.setSheetHidden(idx, true); // 혹은 wb.setSheetHidden(idx, Workbook.SHEET_STATE_VERY_HIDDEN);

        try (FileOutputStream fos = new FileOutputStream("dropdown_hidden_sheet.xlsx")) {
            wb.write(fos);
        }
        wb.close();
       }

import org.apache.poi.hssf.usermodel.HSSFWorkbook;
import org.apache.poi.ss.usermodel.*;
import org.apache.poi.ss.util.CellRangeAddressList;

import java.io.FileOutputStream;

public class XlsDropdown {
    public static void main(String[] args) throws Exception {
        HSSFWorkbook wb = new HSSFWorkbook();
        Sheet sheet = wb.createSheet("입력");

        CellRangeAddressList addressList = new CellRangeAddressList(1, 20, 0, 0);
        DataValidationHelper helper = sheet.getDataValidationHelper();

        DataValidationConstraint constraint =
                helper.createExplicitListConstraint(new String[]{"A", "B", "C"});

        DataValidation validation = helper.createValidation(constraint, addressList);
        validation.setSuppressDropDownArrow(false);
        validation.setShowErrorBox(true);
        sheet.addValidationData(validation);

        try (FileOutputStream fos = new FileOutputStream("dropdown_xls.xls")) {
            wb.write(fos);
        }
               wb.close();
    }​