클라우드 전환 제외 대상이란 사내 서버와 시스템을 클라우드로 옮기는 사업에서 이전 범위에 넣지 않기로 한 시스템을 말한다. 사내 서버를 클라우드로 옮길 때 드는 비용은 무엇을 옮기고 무엇을 남기느냐에 따라 크게 달라진다. 이 기사는 클라우드 전환의 장점과 방법론, 전략과 로드맵, 제안요청서까지 이어지는 흐름 속에서 제외 대상을 어떤 기준으로 가르는지 답한다.
제외 대상은 어떻게 정해지나
클라우드 전환의 좋은 점으로는 서버를 직접 사고 관리하는 부담이 줄고, 필요한 만큼 자원을 늘리고 줄일 수 있다는 점이 흔히 꼽힌다. 그러나 모든 시스템이 이 장점을 똑같이 누리지는 못한다. 그래서 전환 사업은 대개 전체 시스템 목록을 먼저 만들고, 항목마다 옮길지 말지를 따지는 진단 단계에서 시작한다. 이 진단에서 걸러진 항목이 제외 대상이다.
제외 사유는 크게 네 갈래로 나뉜다. 법령이나 계약, 내부 규정이 데이터의 보관 장소를 묶어 두는 경우가 있다. 장비나 소프트웨어가 오래되어 클라우드 환경에서 돌아가지 않는 경우도 있다. 지연 시간이 극히 짧아야 하는 설비 연동 시스템은 물리적으로 가까운 곳에 두어야 한다. 마지막으로 옮기는 비용이 옮겨서 얻는 이익보다 큰 경우다. 어느 갈래든 제외는 영구 결정이 아니라 지금의 조건에서 내린 판단이다.
공공 부문에는 클라우드를 우선 검토하도록 하는 정책 흐름과 함께 예외를 인정하는 절차가 따로 있는 경우가 있다. 다만 예외 사유의 범위와 서류, 승인 절차는 기관과 지침에 따라 다르다. 우리나라 지침을 확인하지 않고 다른 나라 사례를 그대로 가져와서는 안 된다. 미국처럼 클라우드 우선 정책을 두는 나라도 있지만, 인증 체계와 예외 구조가 우리나라와는 다르다.
실제로는 어디서 막히나
현장에서 가장 자주 어긋나는 곳은 시스템 사이의 연결이다. 개별 시스템만 보면 옮겨도 되는데, 그 시스템이 제외 대상과 매일 데이터를 주고받는다면 함께 남기거나 연결 방식을 새로 설계해야 한다. 이 연결 비용을 빼고 견적을 내면 나중에 예산이 어긋난다. 그래서 진단 단계에서는 시스템 목록과 함께 연결 관계도를 그려 보는 것이 기본이다.
클라우드 전환 거부는 부서나 담당자가 이전에 반대하는 형태로 나타난다. 이유는 대개 운영 방식이 바뀌는 데 대한 부담, 책임 소재의 불확실, 비용 구조가 달라지는 데 대한 불안이다. 이런 반대를 곧바로 제외 사유로 받아들이면 제외 목록이 불어나 사업의 취지가 흐려진다. 반대 의견은 기술적 제약인지, 절차상 걱정인지, 정보 부족인지를 나눠 기록하고 각각에 맞게 답하는 편이 낫다.
상황이 다르면 답도 달라진다
클라우드 전환 방법론에서는 시스템마다 처리 방식을 달리 정하는 것이 널리 쓰인다. 그대로 옮기는 방식, 일부만 손봐 옮기는 방식, 구조를 새로 짜는 방식, 기존 소프트웨어를 서비스형 제품으로 갈아타는 방식, 그대로 두는 방식이 대표적이다. 제외 대상은 이 가운데 그대로 두는 방식에 해당한다. 클라우드 전환 전략은 결국 시스템마다 어느 칸에 넣을지를 정하는 일이다.
클라우드 전환 로드맵은 이 분류를 시간 순서로 배열한 것이다. 부담이 적고 효과가 분명한 시스템을 먼저 옮기고, 연결이 복잡한 시스템은 뒤로 미룬다. 제외 대상도 로드맵에서 빠지는 것이 아니라 재검토 시점을 붙여 남겨 두는 것이 좋다. 클라우드 전환사업을 발주할 때 쓰는 제안요청서에도 이전 범위, 제외 범위, 제외 사유의 판단 기준, 남겨 둘 시스템과의 연동 방식을 적어 두어야 한다. 이 내용이 비어 있으면 사업자마다 견적의 전제가 달라져 비교가 어렵다.
| 구분 | 내용 |
|---|---|
| 법령·계약 제약 | 데이터 보관 장소가 정해져 있는지 먼저 확인하고, 허용 범위에 따라 이전 여부를 정한다 |
| 기술 호환성 | 운영체제와 소프트웨어가 클라우드에서 돌아가는지 시험으로 확인한다 |
| 지연 시간 요구 | 설비와 실시간으로 연동되는지 보고, 그렇다면 가까운 곳에 남기는 쪽을 검토한다 |
| 비용 대비 효과 | 이전·개조 비용과 운영 절감분을 견주어 이전 여부를 정한다 |
| 연결 관계 | 다른 시스템과 주고받는 데이터를 확인해 함께 옮길지 따로 남길지 정한다 |
흔한 오해와 확인 순서
제외 대상이 되면 클라우드 전환 사업에서 아예 빠진다고 생각하기 쉽지만, 그렇지 않다. 남겨 둔 시스템도 옮긴 시스템과 연결되고, 접속과 보안 관리 체계는 함께 손봐야 한다. 또 오래된 시스템이라고 해서 무조건 제외되는 것도 아니다. 구조를 새로 짜거나 서비스형 제품으로 바꾸는 길이 열려 있으면 제외가 아니라 이전 대상이 될 수 있다.
판단의 순서는 단순하게 잡을 수 있다. 먼저 시스템 목록과 연결 관계를 정리하고, 다음으로 법령과 계약상 제약이 있는지 확인한다. 그 뒤에 기술 호환성과 지연 시간을 점검하고, 마지막으로 이전 비용과 운영 비용을 견준다. 이 순서를 지키면 감으로 정한 제외 목록이 줄고 견적의 근거도 분명해진다. 독자는 먼저 자기 기관이나 회사의 내부 규정과 계약서에서 데이터 보관 조건을 확인하고, 공공 부문이라면 소관 부처의 클라우드 전환 지침과 공식 안내에서 예외 사유와 절차를 확인하면 된다.
· · · · · · · · · ·
스페셜타임스는 AI 기술의 도움을 받아 더 빠르고 다양한 뉴스를 독자에게 전달하기 위해 노력하고 있습니다.