조사를 바탕으로 한 개인적 의견입니다. 참고만 해주세요.!
클라우드 전환을 하는 이유
먼저 클라우드 전환이란 시스템이 돌아가는 인프라 환경을 바꾸는 것이다. 예를 들어 기존 기관 내부 서버나 IDC에서 운영하던 시스템을 AWS, Azure, GCP, 네이버클라우드, KT클라우드 같은 클라우드 환경으로 옮기는 것을 말한다.
전환 대상은 서버, 네트워크, 스토리지, 데이터베이스, 보안 설정, 운영 환경 등이 될 수 있다. 쉽게 말하면 온프레미스 서버에서 운영하던 시스템을 클라우드 VM, 컨테이너, Kubernetes, 관리형 데이터베이스 같은 환경으로 이전하는 것이다.
클라우드 전환의 목적은 확장성, 유연성, 운영 효율, 자원 관리에 있다. 기존 온프레미스 환경에서는 서버를 미리 구매하고, 용량을 예측하고, 장애 대응을 직접 준비해야 하는 경우가 많다. 반면 클라우드 환경에서는 필요한 시점에 자원을 늘리거나 줄일 수 있고, 서비스 사용량에 따라 인프라를 탄력적으로 운영할 수 있다.
공공기관 입장에서는 AI 전환이나 대규모 서비스 개선을 추진할 때 클라우드 전환이 기반이 되는 경우가 많다. AI 서비스는 대량의 데이터 처리, GPU 같은 연산 자원, 빠른 실험과 배포 환경이 필요하기 때문이다. 기존 온프레미스 환경만으로는 이런 요구사항을 빠르게 수용하기 어려울 수 있다.
MSA 적용을 검토하는 이유
MSA는 Microservice Architecture의 약자로, 하나의 큰 애플리케이션으로 묶여 있던 기능을 작은 서비스 단위로 나누는 방식이다. 따라서 전환 대상은 서버 자체가 아니라 서비스, API, 데이터 소유권, 배포 단위, 운영 책임이다.
클라우드 전환이 “어디에서 실행할 것인가”의 문제라면, MSA 전환은 “애플리케이션을 어떻게 나누고 운영할 것인가”의 문제다. 둘은 같은 개념이 아니지만, 함께 추진되는 경우가 많다.
MSA 적용의 주요 목적은 독립 배포, 장애 격리, 기능별 확장, 책임 분리다. 예를 들어 민원 접수, 알림, 통계, AI 분석 기능이 하나의 시스템에 모두 묶여 있다면 알림 기능 하나를 수정해도 전체 시스템을 다시 배포해야 할 수 있다. 반면 MSA 구조에서는 알림 서비스만 따로 수정하고 배포할 수 있다.
또한 모든 기능이 같은 트래픽을 받는 것은 아니다. 특정 신청 기간에는 민원 접수 기능의 트래픽이 급증할 수 있고, 평소에는 검색이나 챗봇 사용량이 많을 수 있다. MSA로 나누면 트래픽이 많은 서비스만 별도로 확장할 수 있다.
장애 격리 측면에서도 장점이 있다. 알림 서비스에 문제가 생겨도 민원 접수 자체는 계속 가능해야 한다. AI 추천 서비스가 느려지더라도 핵심 행정 처리 기능은 영향을 덜 받아야 한다. MSA는 이런 식으로 장애가 전체 시스템으로 전파되는 것을 줄이기 위한 구조이기도 하다.
클라우드 전환과 MSA 전환의 관계
AI 전환이나 대규모 서비스 개선을 위해 온프레미스 모놀리식 시스템을 클라우드 기반 MSA 시스템으로 전환하는 경우가 많다. 이때 클라우드는 MSA를 운영하기 좋은 환경을 제공한다. 컨테이너, Kubernetes, 오토스케일링, 관리형 데이터베이스, 메시지 큐, 모니터링 도구 등을 활용하면 여러 서비스를 더 유연하게 운영할 수 있다.
반대로 MSA는 클라우드의 장점을 더 잘 활용하게 해준다. 서비스별로 필요한 만큼 자원을 할당하고, 트래픽이 많은 서비스만 확장하며, 배포 자동화와 장애 격리를 적용하기 쉽기 때문이다.
다만 클라우드 전환과 MSA 전환은 같은 말이 아니다. 기존 모놀리식 시스템을 거의 그대로 클라우드로 옮길 수도 있고, 온프레미스 환경 안에서 MSA를 구성할 수도 있다. 중요한 것은 현재 시스템의 상황과 조직의 운영 역량에 맞는 전환 범위를 정하는 것이다.
처음부터 모든 시스템을 나누면 안 되는 이유
공공기관이 AI 전환을 추진한다고 해서 처음부터 모든 시스템을 MSA로 쪼개고 신기술을 적용하는 것은 적절하지 않다. 기존 시스템의 업무 구조, 데이터 흐름, 외부 연계, 운영 방식, 장애 이력, 보안 요구사항을 먼저 분석해야 한다. MSA 전환과 AI 적용은 단순한 기술 도입이 아니라 업무 구조와 데이터 흐름을 재설계하는 과정에 가깝다.
잘못 나눈 MSA는 오히려 복잡도만 높일 수 있다. 서비스 수가 늘어나면 API 호출, 로그 추적, 장애 대응, 배포 관리, 데이터 정합성 문제가 함께 증가한다. 따라서 “작게 나누는 것” 자체가 목적이 아니라, 독립적으로 운영할 가치가 있는 업무 단위를 찾는 것이 중요하다.
현재 시스템 분석
MSA 전환을 검토하기 전에는 현재 시스템을 먼저 분석해야 한다. 이 분석을 통해 어느 기능부터 분리할지 판단할 수 있다. 모든 기능을 같은 우선순위로 볼 것이 아니라, 변경이 잦거나 트래픽이 높거나 장애 격리가 필요한 기능부터 검토하는 것이 현실적이다.
- 어떤 기능들이 강하게 묶여 있는가
- 어떤 데이터베이스 테이블을 여러 기능이 함께 사용하는가
- 외부 기관 연계는 어디에서 발생하는가
- 트래픽이 많은 기능은 무엇인가
- 장애가 자주 발생하는 구간은 어디인가
- 변경 요청이 자주 발생하는 기능은 무엇인가
- 개인정보나 민감정보가 포함된 흐름은 어디인가
- AI를 적용했을 때 효과가 큰 업무는 무엇인가
서비스 분리 기준 수립
MSA에서 가장 중요한 것은 서비스를 어떻게 나눌지 정하는 것이다. 잘못 나누면 서비스는 많아지지만 복잡도만 증가한다.
일반적으로 다음 기준을 활용할 수 있다.
- 업무 책임이 명확한가
- 독립적으로 배포할 필요가 있는가
- 데이터 소유권을 분리할 수 있는가
- 변경 주기가 다른가
- 장애 격리가 필요한가
- 확장성이 별도로 필요한가
- 다른 시스템과 연계가 많은가
- 보안 등급이나 접근 권한이 다른가
예를 들어 민원 접수 서비스와 알림 서비스는 변경 주기와 책임이 다르기 때문에 분리하기 쉽다. 민원 접수는 핵심 업무 처리에 가깝고, 알림은 접수 결과를 사용자에게 전달하는 부가 기능에 가깝다. 따라서 알림 서비스가 장애가 나더라도 민원 접수 자체는 계속 가능하도록 분리할 수 있다. 반면 심사 서비스와 자격 검증 서비스가 같은 데이터를 강하게 공유한다면 무리하게 분리하기보다 경계를 더 분석해야 한다. 데이터를 억지로 나누면 정합성 문제가 커질 수 있기 때문이다.
Strangler Fig 방식 적용
기존 시스템을 한 번에 갈아엎는 방식은 위험하다. 특히 공공기관 시스템은 서비스 중단, 데이터 정합성, 외부 기관 연계, 감사 대응 문제가 있기 때문에 단계적 전환이 필요하다. 이때 사용할 수 있는 방식이 Strangler Fig Pattern이다. 기존 모놀리식 시스템 앞에 API Gateway나 라우팅 계층을 두고, 일부 기능부터 새 서비스로 분리한다. 이후 새 서비스가 안정화되면 해당 기능의 트래픽을 점진적으로 새 서비스로 전환한다.
기존 모놀리식 시스템 유지 → 앞단에 API Gateway 또는 라우팅 계층 배치 → 분리하기 쉬운 기능부터 새 서비스로 구현 → 일부 트래픽을 새 서비스로 전환 → 안정화 후 기존 기능 제거 → 다음 기능 반복 분리
처음 분리하기 좋은 대상은 알림, 파일 업로드, 통계, 검색, 챗봇, 외부 API 연계처럼 핵심 트랜잭션과 상대적으로 느슨한 기능이다. 이런 기능은 기존 핵심 업무 로직을 크게 흔들지 않으면서도 MSA 운영을 시도하기에 적합하다.
데이터 분리 전략
MSA에서 어려운 부분은 애플리케이션보다 데이터 분리다. 기존 모놀리식 시스템은 하나의 데이터베이스를 여러 기능이 함께 사용하는 경우가 많다. MSA에서는 원칙적으로 서비스가 자기 데이터를 소유해야 한다. 하지만 처음부터 모든 데이터베이스를 분리하면 리스크가 크다. 따라서 단계적으로 접근해야 한다.
- 초기에는 기존 DB를 읽기 중심으로 활용한다.
- 새 서비스 전용 테이블을 먼저 분리한다.
- 이벤트 기반으로 필요한 데이터를 복제한다.
- 읽기 모델과 쓰기 모델을 분리한다.
- 최종적으로 서비스별 DB 소유권을 정리한다.
예를 들어 AI 분석 서비스는 운영 원천 DB에 직접 접근하기보다 비식별 처리된 분석용 데이터 저장소를 별도로 두는 것이 안전하다. 이렇게 하면 운영 시스템의 안정성을 해치지 않으면서도 AI 분석에 필요한 데이터를 활용할 수 있다.
이벤트 기반 구조 도입
모든 서비스를 동기 API 호출로만 연결하면 장애 전파와 성능 문제가 발생할 수 있다.
예를 들어 민원이 접수된 뒤 알림 발송, 통계 반영, AI 분석 요청은 즉시 같은 트랜잭션 안에서 처리하지 않아도 된다. 이런 경우 메시지 큐나 이벤트 스트리밍을 사용할 수 있다.
민원 접수 완료 → ComplaintSubmitted 이벤트 발행 → 알림 서비스가 이벤트 수신 → 통계 서비스가 이벤트 수신 → AI 분석 서비스가 이벤트 수신
이렇게 하면 서비스 간 결합도를 낮출 수 있다. 알림 서비스에 일시적인 문제가 생겨도 민원 접수 기능은 정상적으로 처리될 수 있고, 알림은 나중에 재처리할 수 있다.
AI 서비스 분리 방식
AI 기능은 기존 업무 서비스 안에 직접 넣기보다 별도 AI 서비스로 분리하는 것이 좋다. AI 기능은 일반적인 업무 로직과 성격이 다르다. 모델 호출, 프롬프트 관리, 벡터 검색, 데이터 파이프라인, 품질 평가, 비용 관리 같은 별도 요소가 필요하기 때문이다. 예를 들어 민원 서비스가 직접 모델을 호출하는 것이 아니라 AI 분석 서비스나 AI Gateway를 통해 요청하도록 구성할 수 있다.
민원 서비스 → AI Gateway → 문서 분류 서비스 → 요약 서비스 → 유사 사례 검색 서비스 → 모델 서버 또는 외부 LLM API
이렇게 구성하면 모델 변경, 프롬프트 변경, 접근 통제, 로그 관리, 비용 관리, 품질 평가를 중앙에서 관리하기 쉽다. 또한 AI 기능에 문제가 생기더라도 핵심 업무 서비스와 분리해 대응할 수 있다.
RAG 방식 도입
공공기관의 AI 서비스에서는 모델을 새로 학습시키는 것보다 RAG 방식을 먼저 고려할 수 있다. RAG는 Retrieval-Augmented Generation의 약자로, 사용자의 질문이 들어오면 내부 문서나 지식베이스에서 관련 내용을 검색한 뒤 그 결과를 바탕으로 답변을 생성하는 방식이다. 예를 들어 정책 문서, 민원 처리 지침, FAQ, 법령 자료를 검색 인덱스로 만들고, 챗봇이 답변할 때 해당 자료를 참고하게 할 수 있다.
RAG 방식의 장점은 다음과 같다. 내부 문서를 기반으로 답변할 수 있다, 모델 재학습 없이 지식을 업데이트할 수 있다, 답변의 출처를 함께 제공할 수 있다, 일반 생성형 AI보다 환각을 줄일 수 있다, 업무 문서 기반의 질의응답에 적합하다.
다만 RAG 역시 만능은 아니다. 어떤 문서를 검색 대상으로 삼을지, 검색된 내용을 어느 정도까지 모델에 전달할지, 답변 품질을 어떻게 평가할지에 대한 설계가 필요하다. 데이터 보호와 외부 모델 사용에 관한 구체적인 내용은 별도의 보안 편에서 다룰 예정이다.
단계적 전환 로드맵
전체 흐름을 로드맵으로 정리하면 다음과 같다.
1단계: 현재 시스템 구조와 업무 흐름 분석
2단계: 클라우드 전환 대상과 방식 결정
3단계: 서비스 분리 후보 선정
4단계: API Gateway와 관측성 기반 마련
5단계: 알림·검색·통계 등 저위험 기능부터 분리
6단계: 데이터 분리 전략 수립
7단계: 이벤트 기반 구조 도입
8단계: AI 적용 후보 선정
9단계: AI Gateway와 RAG 기반 PoC 구축
10단계: 품질 평가 후 핵심 업무로 점진적 확대
이 로드맵의 핵심은 한 번에 바꾸지 않는 것이다. 먼저 클라우드 환경에서 운영 기반을 만들고, 분리 효과가 큰 기능부터 MSA로 전환한 뒤, AI 기능은 별도 서비스로 붙이는 방식이 더 현실적이다.
마무리
클라우드 전환과 MSA 전환은 같은 개념이 아니다. 클라우드 전환은 시스템이 실행되는 인프라 환경을 바꾸는 것이고, MSA 전환은 애플리케이션 구조를 업무 단위의 서비스로 분리하는 것이다. 다만 공공기관의 AI 전환 과정에서는 두 전환이 함께 논의되는 경우가 많다. 클라우드는 MSA를 운영하기 좋은 환경을 제공하고, MSA는 클라우드의 확장성, 자동화, 탄력성을 더 잘 활용하게 해준다. 또한 AI 분석, 검색, 챗봇 같은 기능을 기존 업무 시스템과 분리해 적용하기에도 유리하다. 러나 처음부터 모든 시스템을 MSA로 쪼개는 것은 위험하다. 현재 시스템의 업무 구조와 데이터 흐름을 분석하고, 변경이 잦거나 독립 운영의 효과가 큰 기능부터 단계적으로 분리해야 한다. 결국 중요한 것은 클라우드나 MSA 자체가 아니라, 공공기관의 업무 안정성, 데이터 흐름, 운영 가능성을 기준으로 전환 범위를 정하는 것이다.