얼마 전 공공기관 시스템 담당자와 이야기할 일이 있었는데, 가장 많이 나온 말이 “클라우드로 옮기긴 해야 하는데 어디서부터 손대야 할지 모르겠다”였습니다. 사실 공공클라우드는 서버를 새로 사느냐 마느냐의 문제가 아니라, 민원 서비스가 갑자기 몰릴 때 버틸 수 있는지, 개인정보를 어떻게 지킬지, 예산을 얼마나 유연하게 쓸 수 있는지를 함께 보는 일에 가깝습니다.
공공클라우드는 일반 클라우드와 뭐가 다를까
클라우드는 쉽게 말해 서버, 저장공간, 소프트웨어를 직접 소유하지 않고 필요한 만큼 빌려 쓰는 방식입니다. 공공클라우드는 여기에 행정기관, 지자체, 공공기관 업무에 맞는 보안 기준과 계약 절차가 붙습니다. 민간 기업이 쓰는 클라우드와 기술 원리는 비슷하지만, 국민 정보와 행정 서비스가 걸려 있기 때문에 확인해야 할 문서와 책임 범위가 더 촘촘합니다.
예를 들어 민간 쇼핑몰은 이벤트 기간에 접속자가 평소보다 5배 늘면 서버를 잠시 늘렸다가 줄이는 식으로 운영합니다. 공공 서비스도 비슷합니다. 재난지원금 신청, 공공임대 접수, 세금 납부 기간처럼 특정 시점에 사람이 몰리는 서비스는 고정 서버만으로 대응하기가 점점 어렵습니다.
많이 헷갈리는 세 가지 형태
- IaaS: 서버와 저장공간 같은 기반 자원을 빌려 쓰는 형태입니다. 기존 시스템을 옮길 때 자주 검토됩니다.
- PaaS: 개발과 배포에 필요한 환경을 함께 쓰는 형태입니다. 새 서비스를 빠르게 만들 때 유리합니다.
- SaaS: 메일, 협업도구, 전자계약처럼 완성된 서비스를 구독하듯 쓰는 방식입니다.
처음 준비할 때는 시스템 목록부터 봐야 합니다
공공클라우드를 준비할 때 제일 먼저 할 일은 멋진 기술 이름을 고르는 게 아닙니다. 현재 운영 중인 시스템을 업무 중요도, 개인정보 포함 여부, 이용자 수, 장애 영향도 기준으로 나누는 작업이 먼저입니다. 행정안전부도 2026년 9월 모든 행정·공공기관 정보시스템을 대상으로 클라우드 이용 현황, 전환 계획, 클라우드 네이티브 적용 여부 등을 조사했습니다. 조사 항목이 5개 영역 25개 문항으로 나뉜 것도 결국 “무엇을 옮길 수 있고, 무엇은 더 봐야 하는지”를 가르기 위해서입니다.
작은 예를 들어보면, 기관 내부 직원 30명이 쓰는 교육 신청 관리 시스템과 국민 100만 명이 접속할 수 있는 민원 포털은 같은 방식으로 옮기기 어렵습니다. 전자는 SaaS로 바꾸는 편이 빠를 수 있고, 후자는 접속량 예측, 데이터 연계, 장애 대응 시간을 따져 IaaS나 PaaS 기반으로 단계 전환하는 편이 자연스럽습니다.
목록을 만들 때 넣으면 좋은 항목
- 월평균 이용자 수와 최대 접속 시간대
- 개인정보, 민감정보, 행정정보 포함 여부
- 다른 시스템과 연결된 인터페이스 개수
- 장애가 났을 때 업무가 멈추는 범위
- 현재 유지보수 비용과 장비 교체 예정 시점
보안과 계약은 초반에 같이 잡는 편이 편합니다
공공클라우드에서 빠지지 않는 단어가 CSAP입니다. 한국인터넷진흥원이 안내하는 클라우드 서비스 보안인증 제도이고, 공공 업무에 클라우드 서비스를 제공하려는 사업자가 보안 기준을 충족했는지 확인하는 장치입니다. 과학기술정보통신부와 한국인터넷진흥원 안내를 보면 교육 과정에서도 인증 대상, 신청 절차, 인증 기준 해설, 적합·부적합 사례를 다룹니다. 그만큼 실제 사업에서는 기술보다 서류와 증적 준비가 늦어져 일정이 밀리는 일이 흔합니다.
계약 방식도 같이 봐야 합니다. 디지털서비스 전문계약제도는 클라우드 등 민간 디지털서비스를 공공기관이 더 빠르게 이용할 수 있도록 만든 제도입니다. 한국지능정보사회진흥원 안내에 따르면 기존 입찰보다 계약 기간을 크게 줄이는 사례가 소개되어 있습니다. 다만 빠르게 살 수 있다는 말이 아무 서비스나 고르면 된다는 뜻은 아닙니다. 서비스 범위, 보안인증, 데이터 위치, 백업, 장애 통보 방식은 계약 전에 확인하는 편이 좋습니다.
- 보안: CSAP 여부, 접근권한 관리, 로그 보관, 암호화 방식을 확인합니다.
- 운영: 장애 대응 시간, 백업 주기, 복구 목표 시간을 숫자로 맞춥니다.
- 비용: 기본료뿐 아니라 트래픽, 저장공간, 기술지원 비용을 같이 봅니다.
- 계약: 서비스 변경, 해지, 데이터 반출 조건을 문서에 남깁니다.
전환 방식은 한 번에 다 옮기지 않아도 됩니다
공공클라우드 전환이라고 하면 기존 시스템을 통째로 들어 올리는 장면을 떠올리기 쉽습니다. 그런데 실제로는 단계별 접근이 더 안정적입니다. 행정안전부는 2030년까지 공공 정보시스템의 클라우드 전환 계획을 마련하겠다고 밝힌 바 있습니다. 이런 흐름을 보면 기관 입장에서도 올해 당장 모든 것을 바꾸기보다, 위험이 낮고 효과가 분명한 업무부터 옮기는 전략이 현실적입니다.
예를 들어 게시판, 예약 접수, 교육 신청처럼 업무 구조가 비교적 단순한 서비스는 먼저 옮기기 좋습니다. 반면 세입·세출, 복지급여, 인허가처럼 여러 기관 데이터가 얽힌 시스템은 사전 영향 분석이 더 필요합니다. 작은 시스템 하나를 3개월 정도 시범 운영해보면 비용 청구 방식, 장애 알림, 권한 관리, 담당자 업무량이 실제로 어떻게 바뀌는지 눈에 들어옵니다.
초보 기관이라면 이런 순서가 무난합니다
- 1단계: 전체 시스템 목록을 만들고 난이도를 낮음, 보통, 높음으로 나눕니다.
- 2단계: 이용자 불편이 적은 내부 업무나 단순 신청 서비스를 후보로 고릅니다.
- 3단계: 2~3개 사업자 견적을 같은 조건으로 비교합니다.
- 4단계: 백업, 장애 대응, 권한 설정을 포함해 시범 운영합니다.
- 5단계: 운영 결과를 보고 다음 시스템으로 넓힙니다.
비용은 싸지는가보다 예측 가능한가를 봐야 합니다
클라우드가 항상 더 저렴한 것은 아닙니다. 서버 구매비가 줄어도 운영관리, 보안관제, 데이터 전송, 백업 저장공간 비용이 붙을 수 있습니다. 그래서 예산을 볼 때는 “올해 얼마”만 보면 부족합니다. 최소 3년 기준으로 현재 방식과 클라우드 방식을 나란히 놓고 비교해야 감이 옵니다.
예를 들어 기존 서버 교체에 1억 원이 들고 매년 유지보수에 2천만 원이 든다면, 단순 계산으로 3년 비용은 1억 4천만 원입니다. 클라우드는 초기 장비 구매가 줄어도 월 350만 원씩 운영비가 나오면 3년 비용이 1억 2천6백만 원입니다. 여기에 보안관제나 이전 비용이 붙으면 차이가 줄어듭니다. 그래서 비용표에는 월 사용료만이 아니라 이전비, 교육비, 운영지원비, 트래픽 증가 비용까지 넣는 게 좋습니다.
공공클라우드는 유행어처럼 보일 때도 있지만, 제대로 쓰면 담당자에게 꽤 실용적인 선택지가 됩니다. 장비 교체 시점마다 큰돈을 한 번에 쓰는 부담을 줄이고, 서비스 이용량에 맞춰 운영 방식을 바꿀 수 있기 때문입니다. 다만 시작은 늘 작고 구체적일수록 좋습니다. 우리 기관에서 가장 단순하지만 이용자가 체감할 수 있는 서비스 하나를 고르는 것, 그게 공공클라우드를 부담이 아닌 도구로 느끼게 만드는 첫걸음이라고 생각합니다.
