공공기관 클라우드 네이티브 전환 완벽 정리, 430억 원 사업으로 본 컨테이너·서버리스 선택 가이드

Table of Contents

안녕하세요! 성징어의 IT 잉크사이트(IT Ink-Sight) 성징어입니다.

몇 달 전 어느 ISP 사업 착수보고 자리에서 이런 질문을 받았습니다. “우리도 클라우드로 이미 옮겼는데, 왜 또 전환 사업을 해야 하나요?” 저는 그 자리에서 화면에 있던 시스템 구성도를 가리키며 되물었습니다. “이건 서버만 클라우드로 옮긴 거고, 안에 있는 애플리케이션은 예전 그대로인데요, 트래픽이 몰리면 지금도 멈추지 않나요?” 담당자분은 잠깐 말을 잃으셨습니다. 정확히 그 지점이었습니다. 클라우드로 옮겼다는 것과 클라우드 네이티브라는 것은 완전히 다른 이야기입니다.

행정안전부는 이 차이를 숫자로 증명했습니다. 2025년 정부24를 비롯한 9개 공공정보시스템에 430억 원을 투입해 클라우드 네이티브 전환을 진행했고, 그 결과 이용자 폭증 시 용량이 7.6배 자동으로 늘어나고 서비스 중단 시간은 81.6% 줄었습니다. 오늘은 이 실측 사례를 출발점 삼아, 공공기관이 클라우드 네이티브 전환을 검토할 때 반드시 마주치는 선택지인 컨테이너 오케스트레이션과 서버리스 중 무엇을 골라야 하는지, 그리고 설계 단계에서 자주 놓치는 함정이 무엇인지 하나씩 짚어보겠습니다.

왜 지금 공공기관 클라우드 네이티브 전환인가

행정안전부에 따르면 정부는 2021년부터 클라우드 전환을 본격 추진해 전체 1만 9천여 개 정보시스템 중 6천여 개를 이미 클라우드로 옮겼습니다. 숫자만 보면 성과처럼 보이지만, 실제로는 온프레미스 서버를 그대로 클라우드 가상머신으로 옮기는 리프트 앤 시프트 방식이 대부분이었습니다. 문제는 여기서 시작됩니다. 사용자가 몰리는 순간 접속이 지연되고, 시스템 일부의 장애가 전체 서비스 마비로 번지는 사례가 반복적으로 보고됐습니다.

저는 이 대목에서 공공기관 클라우드 네이티브 전환이 단순한 유행어가 아니라는 걸 다시 느낍니다. 클라우드라는 인프라만 바꾸고 애플리케이션 구조는 그대로 두면, 문제의 본질은 하나도 해결되지 않습니다. 마이크로서비스 아키텍처를 다룬 여러 기술서에서도 공통으로 지적하는 지점인데, 디지털전환의 진짜 목표는 시스템을 비즈니스의 지원 역할이 아니라 주체로 세우는 것입니다. 기술 부채를 방치한 채 최신 기술만 얹으면 오히려 비용과 기간만 늘어난다는 게 여러 사례에서 확인된 사실입니다.

정부의 목표치도 꽤 공격적입니다. 2026년까지 전체 공공 시스템의 70% 이상을 클라우드 네이티브로 전환하고, SaaS 적용률을 35% 이상으로 끌어올리겠다는 계획이 나와 있습니다. 저처럼 공공 정보화 사업을 다니는 입장에서는 이 목표치 하나만으로도 앞으로 몇 년간 나올 사업의 방향이 어느 정도 그려집니다.

행정안전부 430억 원 사업이 보여준 진짜 효과

숫자로 이야기하는 게 가장 빠를 것 같습니다. 행정안전부는 2025년 정부24, 근로복지공단 일자리 플랫폼, 대구광역시 도서관 통합·대구통합예약, 국토지리정보원 국토정보 플랫폼, 경상남도교육청 교육행정기관·학교 통합누리집, 한국교통안전공단 국가대중교통정보, 공영홈쇼핑 영업시스템, 국무조정실 대테러 홈페이지까지 7개 기관 9개 시스템을 선정해 430억 원을 투입했습니다.

이 사업의 전환 방식이 핵심입니다. 단순 클라우드 이동, 즉 리프트 앤 시프트 방식을 명시적으로 배제하고 마이크로서비스 아키텍처(MSA)를 적용해 시스템을 여러 개의 작은 애플리케이션으로 분리했습니다. 그 결과가 상당히 인상적입니다. 이용자 폭증 시 용량이 7.6배까지 자동으로 확장되고, 시스템 중단 시간은 81.6% 감축됐으며, 서비스 처리 시간은 36.7% 단축됐습니다. 부분 장애가 전체 시스템 장애로 번지지 않도록 설계된 덕분입니다.

저는 이 숫자들을 처음 봤을 때, 컨설팅 제안서에 쓰기 딱 좋은 근거 자료라고 생각했습니다. 발주기관 담당자에게 “왜 클라우드 네이티브로 전환해야 하는가”를 설명할 때, 추상적인 개념보다 이 정부24 사례의 실측치가 훨씬 설득력 있습니다. 실제로 정부24는 일평균 이용자 100만 명, 연계 시스템 137개를 무중단으로 서비스해야 하는 대형 시스템이었는데, 평소 대비 2배 이용자가 몰려도 서버 자원이 즉시 확장되도록 만들었습니다. 여기에 더해 정부는 이미 전환된 시스템의 긴급 개선이 필요할 때 예산과 계약 절차를 간소화하는 신속 기능개선 지원사업까지 함께 운영하고 있어, 전환 이후의 유지보수 부담도 줄이려는 의도가 읽힙니다.

컨테이너 오케스트레이션이냐 서버리스냐, 첫 번째 갈림길

배포 아키텍처를 정하는 순간 실무자는 크게 세 갈래 길 앞에 섭니다. 컨테이너 오케스트레이션, PaaS, 그리고 서버리스입니다. 이 셋을 정확히 구분하지 못한 채 사업을 시작하면, 설계 중반부에 가서야 방향을 다시 잡느라 일정이 밀리는 경우를 저는 여러 번 봤습니다.

컨테이너 오케스트레이션, 대표적으로 쿠버네티스는 인프라를 직접 관리하는 데 특화돼 있습니다. 벤더 종속에서 상대적으로 자유롭고 애플리케이션의 이동성과 재사용성이 높다는 게 가장 큰 장점입니다. 다만 보안 관리와 인프라 운용에 어느 정도 전문 인력이 필요하다는 게 발목을 잡습니다. PaaS는 반대로 OS나 컨테이너 관리 자체가 필요 없고, 패키지화된 애플리케이션이라면 바로 배포할 수 있다는 편리함이 있지만 특정 클라우드 제공사에 종속되고 정밀한 제어가 어렵다는 단점이 있습니다.

서버리스는 이 둘과 결이 또 다릅니다. 인프라 관리를 아예 플랫폼에 일임하고 이벤트 주도 함수 개발에만 집중할 수 있다는 게 매력인데, 코드가 실행되는 시간에만 과금되는 방식이라 트래픽이 불규칙한 서비스에서는 비용 효율이 상당히 좋습니다. 구글이 지원하는 Knative 같은 프로젝트는 쿠버네티스 위에서 서버리스 방식을 구현할 수 있게 해주는데, 레드햇과 IBM도 이 방식을 채택하고 있을 정도로 생태계가 넓어지고 있습니다.

서버리스의 매력과 함정 — 콜드스타트와 벤더 종속

그런데 서버리스를 실제로 공공기관 클라우드 네이티브 전환에 적용하려고 하면 몇 가지 현실적인 벽에 부딪힙니다. 첫 번째는 콜드 스타트입니다. 한동안 호출되지 않던 함수가 다시 실행될 때 초기 구동 지연이 발생하는데, 국민이 실시간으로 이용하는 민원 서비스라면 이 지연이 곧바로 불만으로 이어집니다. 두 번째는 이벤트나 요청 기반이라는 프로그래밍 모델 자체의 제약입니다. 복잡한 상태 관리가 필요한 업무 로직에는 서버리스가 오히려 걸림돌이 될 수 있습니다.

세 번째, 그리고 제가 공공 사업에서 가장 신경 쓰는 부분은 벤더 종속입니다. 서버리스 플랫폼은 특정 클라우드 제공사 고유의 프레임워크와 도구를 사용해 개발하는 구조이다 보니, 나중에 다른 CSP로 옮기려면 상당한 재작업이 필요합니다. 공공 조달은 매년 사업자가 바뀔 가능성을 늘 열어두는 구조인데, 특정 벤더에 강하게 묶이는 아키텍처는 감리 단계에서부터 지적받기 쉽습니다.

반면 컨테이너 오케스트레이션은 오픈소스 기반 기술이 많아 클라우드 간 이동성 확보에 유리합니다. CNCF(클라우드 네이티브 컴퓨팅 재단)도 멀티 클라우드 환경에서 오픈소스를 활용해 최적의 환경을 실현하도록 권고하고 있는데, 쿠버네티스 기반 인프라는 플랫폼 간 차이를 추상화해주기 때문에 하이브리드나 멀티 클라우드로 갈 때도 일관된 운영 방침을 유지할 수 있습니다. 저는 이 지점이 공공기관 클라우드 네이티브 전환 사업에서 서버리스보다 컨테이너 오케스트레이션이 더 자주 선택되는 실질적인 이유라고 봅니다.

MSA로 전환할 때 가장 먼저 깨지는 착각 — 서비스별 DB 분리

여기서부터는 설계 단계에서 실제로 자주 부딪히는 문제를 다뤄보겠습니다. 마이크로서비스 아키텍처를 도입할 때 가장 먼저 마주치는 원칙이 서비스마다 독립된 데이터베이스를 갖는 것입니다. 여러 서비스가 하나의 DB를 공유하면, 데이터 구조를 바꿀 때마다 관련된 모든 서비스를 함께 수정해야 하는 결합이 생겨 마이크로서비스를 도입한 의미가 퇴색됩니다.

문제는 여기서 발생합니다. 서비스별로 DB를 쪼개면 필연적으로 여러 DB에 걸친 데이터를 어떻게 동기화하고, 어떻게 한 번에 조회할 것이냐는 질문이 따라옵니다. 이때 흔히 쓰이는 해법이 사가(Saga) 패턴입니다. 이벤트를 매체 삼아 릴레이처럼 로컬 트랜잭션을 전달하는 방식인데, 코레오그래피 방식으로 각 서비스가 능동적으로 이벤트를 주고받게 할 수도 있고, 사가 오케스트레이터라는 중앙 조율자를 두어 트랜잭션 처리를 명확하게 관리할 수도 있습니다.

저는 실무자들이 이 지점에서 가장 자주 하는 실수가, 처음부터 서비스를 지나치게 잘게 쪼개려는 시도라고 생각합니다. 마이크로서비스라는 이름값에 이끌려 서비스 단위를 최소로 세분화하려다 보면, 사가 패턴과 데이터 동기화 복잡도가 감당하기 어려운 수준까지 커집니다. 실제로 여러 마이크로서비스 전문서에서도 “모놀리스 우선” 전략을 언급하는데, 처음에는 다소 큰 단위로 구현한 뒤 실제 운영 상황에 맞춰 점진적으로 세분화하는 방식이 오히려 현실적이라는 겁니다. 공공기관 클라우드 네이티브 전환 사업처럼 예산과 일정이 정해진 프로젝트에서는 이 접근이 더더욱 유효합니다.

설계만으론 부족하다 — 서비스 메시와 관찰가능성

MSA 설계도가 아무리 정교해도, 운영 단계에서 서비스 간 통신을 눈으로 확인할 수 없다면 장애가 터졌을 때 원인을 찾는 데만 몇 시간이 걸립니다. 여기서 필요한 게 서비스 메시입니다. 각 서비스에 경량 프록시를 붙여 서비스 검색, 트래픽 제어, 장애 분리, 보안을 통합 관리하는 구조인데, 이스티오나 링커드 같은 오픈소스 도구가 대표적입니다.

서비스 메시가 실무에서 가장 빛을 발하는 순간은 장애가 발생했을 때입니다. 서킷브레이커라는 패턴을 적용해두면, 특정 서비스에 장애가 감지될 때 일정 시간 동안 그 서비스로의 접근을 자동으로 끊어 시스템 전체로 지연이 번지는 것을 막을 수 있습니다. 트래픽을 일부 비율만 새 버전으로 흘려보내는 카나리 릴리스도 서비스 메시가 있어야 안정적으로 구현됩니다.

도구 선택도 실무에서 자주 나오는 질문입니다. 이스티오는 기능이 가장 풍부하지만 그만큼 학습 곡선이 가파르고 리소스 소모도 큰 편이라, 대규모 시스템을 다루는 중앙부처급 사업에 더 어울립니다. 링커드는 상대적으로 가볍고 설정이 단순해 중소 규모 기관 시스템에 적용하기 수월하다는 평가를 받습니다. 컨설은 해시코프 생태계와 통합이 강점이라, 이미 해시코프 도구를 쓰고 있는 조직이라면 도입 장벽이 낮습니다. 저는 공공기관 클라우드 네이티브 전환 사업의 규모와 기존 인프라 스택을 먼저 살펴본 뒤에 서비스 메시 도구를 정하시길 권합니다. 유행한다는 이유만으로 이스티오를 무작정 도입했다가, 정작 운영 인력이 감당하지 못해 절반의 기능만 쓰는 사례를 저는 여러 번 목격했습니다.

여기에 더해 사이트 신뢰성 엔지니어링, 흔히 SRE라고 부르는 운영 원칙도 함께 봐야 합니다. 구글이 정리한 SRE 5대 원칙 중 하나가 “모든 것을 계측 가능, 관측 가능 상태로 만들어 둔다”는 것인데, 이때 기준이 되는 게 골든 시그널입니다. 지연, 트래픽, 오류, 포화도 네 가지 지표를 상시로 모니터링해야 분산 시스템에서 문제가 어디서 시작됐는지 빠르게 짚어낼 수 있습니다. 저는 여러 공공기관 사업 제안서를 검토하면서, 설계 단계 문서는 훌륭한데 운영 단계의 관찰가능성 설계가 아예 빠진 경우를 꽤 자주 봤습니다. 공공기관 클라우드 네이티브 전환은 구축으로 끝나는 게 아니라 운영이 시작되는 시점부터가 진짜 시험대라는 걸 강조하고 싶습니다.

API 게이트웨이와 BFF, 클라이언트 연동에서 놓치기 쉬운 지점

서비스를 잘게 쪼개고 나면 곧바로 새로운 고민이 따라옵니다. 민원 포털이나 모바일 앱 같은 클라이언트가 수십 개로 분리된 서비스를 각각 따로 호출하게 둘 것인가 하는 문제입니다. 매번 클라이언트가 개별 서비스를 직접 호출하면 통신 횟수가 늘어나 응답 속도가 느려지고, 서비스 하나가 바뀔 때마다 클라이언트 쪽 코드까지 손봐야 하는 결합이 생깁니다.

이 문제를 푸는 대표적인 방법이 API 게이트웨이입니다. 도메인 경계에 클라이언트 처리를 전담하는 서비스를 하나 두고, 여러 마이크로서비스 호출을 게이트웨이 뒤로 숨기는 구조입니다. 여기서 한 단계 더 나아간 게 프론트엔드용 백엔드, 흔히 BFF라고 부르는 패턴인데, 웹용과 모바일용 클라이언트가 요구하는 데이터 형태가 다를 때 클라이언트별로 별도의 BFF를 두어 각 화면에 최적화된 응답을 만들어줍니다. 저는 공공기관 민원 포털 사업을 볼 때마다, PC 웹과 모바일 앱이 사실상 같은 백엔드 API를 그대로 재사용하다가 화면 최적화에 애를 먹는 사례를 자주 접하는데, BFF 패턴을 초기 설계에 반영해두면 이런 시행착오를 상당 부분 줄일 수 있습니다.

데이터를 여러 서비스에서 모아 보여줘야 하는 화면이라면 API 컴포지션과 CQRS 중에서도 선택이 필요합니다. API 컴포지션은 여러 DB에서 가져온 데이터를 애플리케이션 계층에서 즉석으로 합치는 방식이라 구현이 직관적이지만, 메모리 사용량이 늘고 확장성에 불리합니다. 반대로 CQRS는 갱신과 조회를 아예 다른 서비스와 저장소로 분리해두고, 조회 전용 뷰를 미리 만들어두는 방식이라 쿼리 성능은 좋지만 설계 자체가 낯설어 학습 곡선이 있습니다. 저는 실시간성이 크게 중요하지 않은 통계·조회 화면이라면 CQRS를, 즉각적인 데이터 반영이 필요한 소규모 화면이라면 API 컴포지션을 권하는 편입니다. 공공기관 클라우드 네이티브 전환 사업의 화면 설계 단계에서 이 선택을 건너뛰면, 나중에 성능 테스트 단계에서야 문제가 드러나는 경우가 많다는 점을 꼭 기억해두시길 바랍니다.

공공부문 특유의 제약 — 감리 기준과 하이브리드 클라우드

민간 기업과 달리 공공기관은 예산 편성 주기, 정보화 감리 기준, 조달 규정이라는 별도의 제약을 안고 클라우드 네이티브 전환을 진행합니다. 예산은 보통 회계연도 단위로 확정되기 때문에, 서버리스처럼 사용량에 따라 비용이 변동하는 모델은 예산 편성 담당자 입장에서 예측이 까다롭습니다. 반대로 컨테이너 기반 인프라는 초기 투자 비용을 정액으로 잡기 쉬워 공공 예산 구조와 상대적으로 궁합이 좋습니다.

민감 정보를 다루는 시스템이라면 온프레미스나 프라이빗 클라우드와 퍼블릭 클라우드를 함께 쓰는 하이브리드 클라우드 구조가 자주 필요합니다. 중요한 데이터는 내부에 두고 국민이 직접 접하는 서비스만 외부에 개방하는 SoE-SoR 연계형 구조가 대표적입니다. 여기서도 컨테이너 기반 아키텍처가 유리한데, 쿠버네티스는 플랫폼 간 차이를 추상화해주기 때문에 온프레미스와 퍼블릭 클라우드를 오가며 일관된 개발·운영 방침을 유지할 수 있습니다.

벤더 종속을 회피해야 한다는 조달 원칙도 빼놓을 수 없습니다. 공공 사업은 특정 CSP나 특정 벤더의 독점적 기술에 묶이는 설계를 지양하도록 요구받는 경우가 많은데, 오픈소스 기반의 컨테이너 오케스트레이션이 이 요건을 상대적으로 쉽게 충족시켜 줍니다. 저는 실제 제안서를 쓸 때, 특정 CSP 종속 여부를 감리 체크리스트 항목으로 미리 넣어두는 편인데, 이렇게 해두면 사업 후반부에 감리에서 지적받을 위험을 크게 줄일 수 있습니다.

2024년 21개 기관에서 2026년 100억 원 컨설팅 사업까지

시간순으로 흐름을 짚어보면 이 사업이 어떻게 확장돼 왔는지가 뚜렷하게 보입니다. 2024년에는 국가대중교통정보를 포함해 15개 기관 21개 시스템이 클라우드 네이티브 전환 상세 설계 대상으로 선정됐고, 한국지능정보사회진흥원(NIA)이 권역별로 컨설팅 업체를 선정했습니다. 서울·세종 권역은 브이티더블유, 대구·경북 권역은 오케스트로, 경기·강원 권역은 NHN클라우드, 경남·울산·대전 권역은 클로잇이 각각 맡아 대상 기관의 시스템 현황 분석과 ISP 수립, 전환 설계서 마련을 진행했습니다.

이 상세 설계 결과물이 바탕이 되어 2025년 430억 원 규모의 실제 구축·운영 사업으로 이어졌고, 개발 사업자가 1년간 운영까지 담당하는 장기계속계약 방식이 도입됐습니다. 그리고 2026년에는 100억 원 규모의 컨설팅 사업이 새로 추진됩니다. 전환 효과가 높은 시스템을 발굴하고 설계를 지원하는 게 목적인데, 이 흐름을 보면 정부가 컨설팅과 구축을 분리해 단계적으로 사업을 진행하는 패턴이 자리 잡았다는 걸 알 수 있습니다. 저는 이 패턴이 앞으로도 이어질 가능성이 크다고 보는데, 신속성·안정성·확장성 등 6가지 지표로 전환 효과를 정량 평가하는 성과관리 기준이 이미 도입돼 있어서, 성과가 검증된 방식을 계속 반복 적용할 유인이 정부 입장에서도 크기 때문입니다.

글로벌 흐름과 비교해도 이 방향은 크게 벗어나지 않습니다. 시장조사기관 가트너는 2027년까지 신규 AI 배포의 75% 이상이 컨테이너 기반으로 이뤄질 것으로 전망했는데, AI 인프라 확장이 가속화되는 상황에서 컨테이너 오케스트레이션이 표준 배포 방식으로 굳어지는 흐름은 국내외가 크게 다르지 않아 보입니다.

공공기관 클라우드 네이티브 전환 사업 2024년부터 2026년까지 추진 현황 타임라인

공공 IT 컨설팅 관점에서 지금 챙길 것

여기까지 살펴본 내용을 실무 관점에서 정리해보겠습니다. 먼저 ISP나 ISMP를 기획하는 단계에서는 배포 아키텍처 선택 근거를 명확히 문서화해두는 편이 좋습니다. 컨테이너 오케스트레이션을 택했다면 왜 서버리스나 PaaS가 아닌지, 벤더 종속·예산 구조·운영 인력 확보 가능성 세 가지 기준으로 비교표를 만들어두면 감리 대응이 한결 수월해집니다.

둘째, 서비스 분해 단위를 처음부터 지나치게 잘게 잡지 않는 편을 권합니다. 사업 기간과 인력이 정해진 공공 프로젝트에서는 모놀리스 우선 전략처럼 우선 실행 가능한 단위로 구현한 뒤, 운영 데이터를 보고 점진적으로 세분화하는 접근이 리스크가 낮습니다. 셋째, 제안요청서 단계에서부터 서비스 메시와 관찰가능성 요건을 명시적으로 넣어두시길 권합니다. 골든 시그널 기반 모니터링 체계가 과업 범위에 빠져 있으면, 운영 이관 이후 장애 대응 역량이 부족한 채로 시스템을 넘겨받는 상황이 벌어지기 쉽습니다.

넷째, 하이브리드 클라우드가 필요한 사업이라면 초기 설계 단계부터 온프레미스와 퍼블릭 클라우드 간 데이터 흐름을 SoE-SoR 구조로 명확히 나눠 설계해두는 게 좋습니다. 나중에 보안성 검토나 개인정보 영향평가 단계에서 이 구조가 명확하지 않으면 다시 설계를 손봐야 하는 경우가 생깁니다. 다섯째, 행정안전부의 성과관리 6대 지표를 참고해 우리 사업에도 유사한 정량 목표를 세워두면, 사업 완료 후 성과 보고서를 작성할 때도, 다음 예산을 확보할 때도 훨씬 유리한 위치에 설 수 있습니다.

마무리하며

정부24의 자동 확장 7.6배와 중단 시간 81.6% 감축이라는 숫자는 결국 설계의 결과물입니다. 공공기관 클라우드 네이티브 전환은 클라우드로 옮기는 일이 아니라, 컨테이너냐 서버리스냐를 시작으로 서비스 분해 단위, 데이터 동기화 방식, 운영 관찰가능성까지 처음부터 끝까지 다시 설계하는 작업입니다. 2024년 21개 기관 컨설팅에서 시작해 2025년 430억 원 구축, 2026년 100억 원 컨설팅으로 이어지는 이 흐름은 앞으로 몇 년간 계속될 가능성이 큽니다.

여러분이 맡고 있거나 검토 중인 시스템은 컨테이너 오케스트레이션과 서버리스 중 어느 쪽에 더 가까운 선택지인가요? 아니면 이미 전환을 마치셨다면, 설계 당시 예상하지 못했던 운영상의 함정이 있으셨는지 댓글로 공유해주시면 다음 글에서 더 깊이 다뤄보겠습니다.