정부24 클라우드 네이티브 전환: 마이크로서비스 아키텍처로 공공서비스 혁신하기
본 포스트에서는 유엔진솔루션즈가 수행한 정부24 포털 클라우드 네이티브 전환 1차 프로젝트의 설계 및 분석 과정을 살펴보고, 마이크로서비스 아키텍처(MSA) 도입을 통해 어떤 변화가 이루어졌는지 기술적 흐름을 깊이 있게 설명합니다.
특히 기존 모놀리식 민원시스템의 한계와 이를 극복한 AS-IS vs TO-BE 구조를 비교하고 민원 유형별 최적화 전략과 핵심 기술 패턴(Saga, 이벤트 드리븐, CQRS 등)의 실질적 적용 사례를 소개합니다.
이를 통해, 개발자 독자에게는 실제 현업 프로젝트의 MSA 적용 인사이트를, 일반 독자에게는 정부 민원서비스가 어떻게 혁신되고 있는지 맥락을 전달하고자 합니다.
공공 클라우드 전환 배경과 정부24의 도전
행정안전부는 2030년까지 모든 공공 시스템을 클라우드로 전환한다는 '공공 부문 정보자원 클라우드 전환 계획' 아래, 디지털 정부 혁신을 가속화하고 있습니다.
2026년까지 신규 시스템의 70% 이상에 클라우드 네이티브를 적용하겠다는 공격적인 목표 아래, 2025년 7개 기관의 9개 대표 시스템을 대상으로 한 대규모 1차 전환 사업이 시작되었습니다.
그 중심에 있는 것이 바로 정부24민원서비스 포털입니다. 국민 생활과 가장 밀접한 민원 포털인 정부24는 이용자가 몰리는 상황에서도 멈추지 않는 안정성이 필수적입니다. 이에 정부는 이번 전환을 통해 시스템 용량을 최대 7.6배까지 자동 확장하고, 서비스 중단 시간은 81.6% 줄이며, 처리 속도는 36.7% 단축하는 것을 목표로 삼았습니다. 이러한 기술적 도약은 궁극적으로 국민들에게 더 빠르고 쾌적한 디지털 행정 서비스를 제공하는 탄탄한 기반이 될 것입니다.
[정부24 클라우드 네이티브 전환 핵심]
정부24 클라우드 네이티브 전환 분석
기존 시스템의 문제점 (AS-IS 아키텍처 한계)
정부24의 클라우드 네이티브 전환은 2024년 수립된 정보화전략계획(ISP)을 토대로 본격화되었습니다. 이 로드맵에 따라 구체적인 전환 설계를 착수한 유엔진솔루션즈는 가장 먼저 기존 시스템에 대한 정밀 분석을 수행하였고, 그 과정에서 모놀리식 구조의 한계와 치명적인 단일 장애점(SPOF)을 발견하게 되었습니다.
1. 강한 결합(Tight Coupling)으로 인한 경직성
분석 결과, 기존 정부24 시스템은 전형적인 모놀리식 통합 구조이거나 거대 애플리케이션 간 강결합 구조를 띠고 있었습니다. 내부 모듈 간 높은 의존성으로 인해 유지보수와 기능 확장이 어려웠을 뿐 아니라, 작은 부분의 장애나 변경사항이 시스템 전체로 즉각 전파될 만큼 결합도가 높아 배포의 유연성을 크게 저해하고 있었습니다.
2. '민원안내' 서비스의 SPOF 리스크
더 큰 약점은 구조적인 단일 장애점(SPOF)이었습니다. 모든 민원 신청 절차가 '민원안내(검색/안내)' 모듈을 거쳐야만 시작되는 구조였기 때문에, 이 서비스 하나가 중단되면 정부24의 모든 민원 업무가 마비되는 상황이었습니다. 이는 단 한 곳의 장애로 전체 대국민 서비스가 중단되는 구조적 취약점으로, 클라우드 전환 시 반드시 해소해야 할 최우선 과제였습니다.
요약하자면, 기존 시스템은 모놀리식 특성으로 인해 유연성과 고가용성이 떨어졌고, 부분의 장애가 전체로 확산될 위험이 높았습니다. 또한 임계 부하 상황에서 탄력적 대응이 불가능해 성능 저하 우려가 컸습니다. 이러한 분석을 바탕으로 유엔진솔루션즈는 서비스 분리와 재설계를 통해 결합도를 낮추고 안정성을 확보하는 아키텍처 전략을 수립하게 되었습니다.
민원 유형별 아키텍처 전환 전략 (TO-BE 구조 설계)
정부24포털은 처리되는 민원 서비스의 성격에 따라 크게 3 가지 유형으로 구분할 수 있습니다.
민원 업무의 업무 처리 방식과 요구되는 성능/신뢰성 수준에 따라 동기 vs 비동기, 이벤트 중심 vs API 호출, 전용 도메인 분리 등 서로 다른 아키텍처 패턴을 적용함으로써 서비스별 특성에 맞는 유연하고 효율적인 MSA구조를 설계하였습니다.
아래는 ① 단순신청/즉시발급형 민원, ② 유기한/비연계 민원, ③ 주요 민원 유형에 맞춤화된 개선 전후 구조와 서비스 흐름을 설명합니다.
① 단순신청/즉시발급형 민원 – 동기식 REST 기반 MSA
단순신청/즉시발급 민원은 말 그대로 신청과 동시에 즉시 결과물을 발급할 수 있는 유형의 서비스들입니다. 예를 들면 주민등록등본 출력, 행복출산 원스톱 서비스와 같이 별도의 승인 절차가 없고, 단순 신청만으로 실시간으로 처리 가능한 민원들이 해당됩니다.
이러한 서비스들은 사용자 요청에 대한 응답 시간을 최소화하는 것이 최우선이므로, 전환된 아키텍처에서도 동기식 REST 호출 방식을 유지하여 처리 흐름을 간소화하였습니다.
과거 구조에서는 발급 모듈이 신청 상태정보를 갱신하기 위해 직접 신청 DB를 갱신하거나 여러 단계를 한 프로세스 안에서 처리하는 비효율이 존재했으나, 새로 설계된 구조에서는 민원발급 서비스가 민원신청 서비스를 REST API로 직접 호출하여 결과를 갱신하는 식으로 변경되었습니다. 이렇게 함으로써 서비스 간 인터페이스를 명확히 하고, 다른 경계 서비스의 데이터 저장소 직접 연동을 제거하여 결합도를 낮추었습니다.
즉 내부 연계는 최대한 단순 함수 호출이나 내부 API 호출로 처리하고, 불필요하게 메시지 브로커를 경유하지 않도록 하여 성능 오버헤드를 감소하였습니다.
② 유기한 민원 / 비연계 민원 – 이벤트스토어 기반 비동기 Pub/Sub 구조
유기한 민원은 신청 후 일정 기간 내에 결과를 제공하는, 즉 즉시 처리가 어려워 며칠에 걸쳐 처리되는 민원을 말하며, 비연계 민원은 처리 과정에서 타 기관 시스템과 실시간 연계가 필요하지 않은 민원을 일컫습니다.
이 두 유형은 성격상 즉각 처리보다는 신뢰성과 프로세스 완결성이 중요하며, 종종 백엔드에서 지연 처리가 발생한다는 공통점이 있습니다. 따라서 전환 아키텍처에서는 이들을 이벤트 중심의 비동기 구조로 설계하였습니다.
유기한/비연계 민원의 새로운 흐름에서는 우선 사용자가 민원신청을 하면 즉시 접수되었다는 응답을 돌려주고, 이후 실제 처리는 백그라운드에서 이벤트 기반으로 진행됩니다.
구체적으로, 민원신청 서비스(비동기 신청 MSA)는 접수 내용을 이벤트 스토어에 이벤트(Event)로 발행(Publish)하고, 이어서 민원발급 서비스(비동기 발급 MSA)가 해당 신청 이벤트를 구독(Subscribe)하여 처리 작업을 수행하고, 최종 산출물을 생성하면 결과 완료 이벤트를 다시 발행합니다. 사용자는 나중에 결과를 조회하거나 알림(국민비서)을 통해 완료 사실을 통보받게 됩니다.
이런 Pub/Sub 비동기 패턴을 도입한 가장 큰 장점은 시스템의 견고성 향상으로, 이벤트스토어가 메시지 큐로 기능함으로써 설령 백엔드 서비스 일시 장애가 발생해도 메시지가 유실되지 않고 대기하게 됩니다. 장애 복구 후 이어서 메시지를 처리함으로써 민원 처리의 연속성을 보장할 수 있습니다.
이벤트 스토어 기반 구조로 전환하면서 고려된 주요 사항은 트랜잭션 일관성과 오류 대응입니다. 분산 환경에서 여러 단계 처리를 이벤트로 연결할 때 Saga 패턴(분산 환경의 데이터 일관성을 유지하는 분산 트랜잭션 관리 방식)을 적용하여 프로세스 일관성을 유지했습니다. 소비자 서비스에서는 메시지 중복 처리 방지(멱등성)를 구현하여 동일 이벤트가 두 번 처리되는 경우 부작용이 없도록 로직을 강화했습니다.
또한 재시도 및 DLQ(Dead Letter Queue) 메커니즘을 마련하여, 일정 횟수 이상 처리에 실패한 이벤트는 별도 오류 큐로 보내 모니터링 및 보상 조치를 취하도록 하여, 비동기 처리의 안정성을 높이고 운영자가 문제 상황을 추적/관리하도록 설계하였습니다.
③ 주요 민원 – 독립 네임스페이스 기반 고가용성 구조
정부24 네이티브 전환에서 특별히 중요도가 높고 트래픽이 많은 핵심 민원들은 별도의 독립 설계가 적용되었습니다. 대표적으로 건축물대장 발급, 자동차등록 원부 조회 같은 서비스들이 이에 해당합니다.
이들은 호출 건수도 많고 대민 영향도가 커서 여타 민원과 동일한 환경에 몰아넣을 경우, 장애 전파 위험이나 성능 저하 우려가 고려되어 전환 프로젝트에서는 이러한 주요 민원들을 별도의 실행 환경에서 독립적으로 운영하도록 아키텍처를 설계하였습니다.
아키텍처 설계의 핵심은 독립 네임스페이스 전략입니다. Kubernetes 기반 클라우드 환경에서 주요 민원 전용으로 격리된 네임스페이스(별도 마이크로서비스 그룹)를 만들어, 해당 민원의 마이크로서비스들을 그 안에서만 동작시키는 것입니다.
예를 들어 건축물대장 관련 민원안내, 신청, 발급, 연계 등의 마이크로서비스는 다른 민원들과 분리된 별도 네임스페이스에 배포되고, 동일하게 자동차등록 민원도 전용 네임스페이스에서 운영됩니다. 이렇게 하면 특정 주요 민원 서비스에 문제가 발생해도 그 영향이 다른 민원 서비스로 전파되지 않으며, 해당 민원에 필요한 리소스 할당이나 스케일 전략도 독립적으로 최적화할 수 있다는 장점이 있습니다. 실제로 설계된 주요 민원 전용 네임스페이스에는 그 서비스에만 매핑되는 연계 채널, 마이크로서비스 복제 구성 등을 적용하여 고가용성(HA)을 극대화하였습니다.
이는 앞서 지적한 민원안내 서비스의 SPOF 문제를 주요 민원별로 자체적인 민원안내 채널을 마련하여 해소할 수 있게 되었습니다.
클라우드 네이티브 전환에 적용된 주요 설계 패턴
마이크로서비스 전환의 핵심 목표 중 하나는 서비스 간 결합도(coupling)를 낮추고 경계를 명확히 하는 것입니다. 정부24 전환 프로젝트에서도 기존 모놀리식 요소들을 제거하고 각 서비스의 자율성과 독립성을 극대화하는 방향으로 설계되었습니다.
특히 데이터베이스 직접 참조로 인한 강한 결합을 이벤트 기반으로 느슨하게 결합하고, 일반 민원과 주요 민원을 분리하여 일반 민원서비스 장애에도 주요 민원 서비스는 이의 영향없이 운영되도록 설계되었습니다.
이번 전환 프로젝트에서는 MSA의 기술적 완성도를 높이기 위해 다양한 디자인 패턴을 아키텍처 전반에 적용했습니다. 분산 트랜잭션의 데이터 정합성을 위한 Saga 패턴부터, 이벤트 처리의 신뢰성을 보장하는 멱등성(Idempotency) 및 트랜잭션 패턴, 그리고 대용량 조회 성능 최적화를 위한 CQRS 설계에 이르기까지, 시스템의 안정성과 유연성을 동시에 확보하기 위한 기술적 장치들을 촘촘하게 마련했습니다.
[주요 민원 이벤트스토밍 모델, MSA-Ez]
데이터 정합성을 위한 선택: Choreography Saga
정부24 네이티브 전환에서 민원 신청부터 발급까지 이어지는 분산 프로세스의 데이터 정합성을 보장하기 위해 Saga 패턴을 도입했으며, 설계를 위해 다음 두 가지 방식을 검토했습니다.
- Choreography Saga: 각 서비스가 이벤트를 주고받으며 자율적으로 다음 단계를 처리합니다. 서비스 간 결합도는 낮아지지만, 전체 흐름을 추적하거나 복잡한 예외를 처리하기 까다롭다는 단점이 있습니다.
- Orchestration Saga: 중앙 조정자(Orchestrator)가 프로세스를 통제합니다. 모니터링과 오류 제어가 용이한 반면, 조정자에 부하가 집중되고 서비스 간 의존성이 높아질 우려가 있습니다.
우리는 서비스 간 결합도를 낮추고 유연성을 확보하기 위해, 내부 프로세스(신청↔발급)에는 Choreography 방식을 채택했습니다. 단, 제어가 불가능한 외부 연계 구간은 Saga 트랜잭션 범위에서 제외하여 전체 시스템의 안정성을 도모했습니다.
구독에서 발행까지: 원자적 처리 단위와 멱등성
정부24 시스템의 신뢰성을 지탱하는 핵심은 이벤트를 처리하는 단위를 명확히 정의한 데 있습니다. 우리는 이벤트 스토어로부터 이벤트를 가져와(Subscribe) 비즈니스 로직을 수행하고(Transaction), 그 결과를 다시 이벤트로 발행(Publish)하는 전체 과정을 쪼갤 수 없는 하나의 원자적 단위로 설계했습니다.
하지만 분산 네트워크 환경에서는 장애 복구 과정에서 메시지가 재전송되거나 중복 유입되는 경우가 발생할 수 있습니다. 이에 대한 안전장치로 우리는 비즈니스 관점의 멱등성(Idempotency) 체계를 구축했습니다.
구체적으로는 DB의 Unique 제약조건을 활용하거나, 로직 수행 전 현재 민원의 처리 상태(Status)를 먼저 확인하는 방식을 적용했습니다. 즉, 이미 '발급 완료'된 신청 건에 대해 중복 요청이 들어오면 시스템이 이를 감지하고 추가 작업을 수행하지 않도록 만든 것입니다.
결과적으로, 카프카(Kafka)와 같은 메시징 시스템이 보장하는 '최소 1회 처리(At-least-once)' 방식의 안정성을 누리면서도, 데이터 중복 문제는 완벽하게 해소하여 데이터 무결성을 지켜냈습니다.
추적 가능한 이벤트 설계와 DLQ 전략
이벤트 설계 측면에서도 정부24 전환 프로젝트는 몇 가지 원칙과 전략을 수립하였습니다. 먼저 메시지 명명 및 구조에 일관성을 부여하여, 이벤트만 보고서도 그 의미를 파악하기 쉽게 했습니다.
모든 도메인 이벤트에는 가독성이 높은 명명 규칙을 적용했는데, 예를 들어 “민원신청 완료” 이벤트는 ApplicationSubmitted라는 식의 도메인 동사 형태로 정의되었습니다. 또한, 일반 민원과 자동차등록처럼 유형이 다른 경우, 이벤트 이름에 구분자를 넣어 (GeneralApplicationSubmitted, CarApplicationSubmitted 등) 한눈에 구별할 수 있게 했습니다. 이러한 도메인 기반 이벤트 네이밍은 운영 중 로그나 트레이싱에서도 도움이 되어, 어떤 이벤트가 어디서 유래한 것인지 명확히 식별할 수 있습니다.
메시지 내용에는 민원 ID, 처리 단계, 타임스탬프, 출처 서비스 등 필요한 메타데이터를 충분히 포함시켜 추적성(traceability)을 높였습니다. 다만, 이벤트에 지나치게 큰 데이터 덩어리를 담지 않도록 유의하여 파일이나 서식 정보등은 별도 저장소에 두고 이벤트에는 참조 링크만 포함하는 방식으로 메시지 크기를 관리하였습니다.
오류나 예외 상황에 대비한 Dead Letter Queue (DLQ) 전략도 중요하게 적용되었습니다. 메시지 Consumer가 메시지를 처리하다가 지속적으로 오류가 발생하는 경우 해당 메시지를 별도의 토픽으로 격리시켜 정상 흐름을 방해하지 않도록 한 것입니다.
정부24전환 프로젝트의 경우 도메인 이벤트 유형별로 DLQ 토픽을 별도로 생성하여, 예를 들어 ApplicationSubmitted 이벤트 처리가 계속 실패하면 ApplicationSubmitted.DLQ와 같이 사전에 정의된 오류 토픽에 해당 메시지를 보내도록 하였습니다.
Consumer 설정에서 일정 횟수(예: 3회) 재시도 후에도 실패하면 자동으로 DLQ로 Publish되게 했으며, DLQ에 쌓인 이벤트를 재처리하거나 대안 조치를 취하는 별도 Consumer를 두어, 보상 트랜잭션(Rollback in Saga) 처리를 수행하게 설계했습니다.
대규모 조회 트래픽 대응을 위한 CQRS 아키텍처
정부24포털처럼 읽기(민원처리 결과 조회) 트래픽이 많은 서비스에서 CQRS(Command Query Responsibility Segregation) 패턴은 클라우드 네티이브를 구축함에 있어 필수적입니다.
CQRS는 쓰기 작업과 읽기 작업을 분리하여 각각 최적화된 방식으로 처리하는 아키텍처 패턴으로, 주로 조회 성능 개선과 확장성 향상을 위해 도입됩니다. 정부24 전환 프로젝트에서도 신청 결과 조회 서비스에 CQRS 개념을 적용하는 방안이 논의되고 설계에 반영되었습니다.
기존 정부24에서는 하나의 통합 DB에 신청부터 발급, 조회까지 모든 데이터가 저장되고 사용되었습니다. 이러한 단일 데이터베이스 구조에서는 읽기 부하가 높아질 경우, 쓰기 트랜잭션에 영향을 주거나, 반대로 대량 입력/수정이 발생하면 조회 응답이 느려지는 문제가 생길 수 있습니다.
이를 개선하고자 새 아키텍처에서는 신청결과 조회를 전담하는 마이크로서비스를 분리하고, 필요 시 저장소까지 분리하는 CQRS 모델을 제안하였습니다. 예를 들어, 민원 신청/발급 서비스는 운영 DB에 쓰기 위주 작업을 하고, 신청결과 서비스는 별도의 읽기 전용 DB 또는 캐시를 두어 조회 쿼리를 실행하도록 하는 것입니다. 이렇게 하면 조회 성능을 높이면서도, 본 시스템의 트랜잭션 부하를 분산시킬 수 있습니다.
맺음말: 공공 플랫폼의 새로운 표준을 제시하다
정부24의 클라우드 네이티브 전환은 단순한 시스템 이전을 넘어, 공공 민원서비스의 체질을 개선하고 기술적 유연성을 확보한 의미 있는 사례입니다.
이번 프로젝트에서 유엔진솔루션즈는 도메인 주도 설계(DDD)를 기반으로 서비스 경계를 명확히 하고, Saga 패턴과 이벤트 스토어 기반의 비동기 통신 등 MSA 베스트 프랙티스를 전략적으로 적용했습니다. 이를 통해 정부24포털은 기술적으로 더 유연하고 탄력적인 플랫폼으로 진화할 수 있었습니다.
특히 이번 전환은 '마이크로서비스 아키텍처(MSA)가 대규모 공공서비스의 해법'임을 실증했다는 점에서 그 의의가 큽니다. 과거 단일 장애가 전체 서비스 마비로 이어지던 구조적 한계를 넘어, 이제는 서비스 격리(Isolation)를 통해 주요 업무의 연속성을 보장하게 되었습니다. 또한, 폭증하는 트래픽에도 자동 확장(Auto-scaling)과 분산 처리로 유연하게 대응할 수 있는 안정적인 기반을 갖추게 되었습니다.