<잇(IT)터뷰 전체 영상 보기>
잇(IT)터뷰 전체 내용은 ▼아래 영상▼에서 확인해 주세요!
◼ 게스트 : 우한규 부사장 / 투라인클라우드 (mkt@twolinecloud.com)
◼ 진행자 : 고우성 PD / 토크아이티 (talkit@talkit.tv, https://talkit.tv/)
<잇(IT)터뷰 – 핵심 내용 파악하기>
‘잇(IT)터뷰 – 핵심 내용 파악하기’는 영상의 핵심 내용을 정리한 글입니다.
|
이번 잇(IT)터뷰는 공공기관의 클라우드 전환이 왜 기대만큼 빠르게 진전되지 않는지, 그 원인이 기술 부족이 아니라 구조적 문제에 있다는 점을 짚습니다.
MSA와 클라우드 네이티브의 목적은 빠른 개선과 지속 배포인데, 공공 프로젝트의 분리발주와 순환보직 구조가 바로 그 운영 민첩성을 끊어버린다는 것이 핵심 메시지입니다.
1. MSA와 클라우드 네이티브의 본질은 ‘구축’이 아니라 ‘운영’이다
공공기관에서 MSA나 클라우드 네이티브 전환을 이야기할 때, 종종 쿠버네티스나 컨테이너를 도입했는지 여부에만 초점이 맞춰집니다. 하지만 이 영상은 진짜 기준이 기술 스택 도입 여부가 아니라, 서비스를 얼마나 빠르게 개선하고 얼마나 자연스럽게 운영할 수 있느냐에 있다고 설명합니다.
결국 클라우드 네이티브 전환의 목적은 고객 피드백을 빨리 반영하고, 장애를 최소화하면서 서비스를 민첩하게 운영하는 데 있습니다.
2. 공공 클라우드 전환의 가장 큰 장벽은 ‘분리발주 구조’다
영상은 공공기관 클라우드 전환의 가장 현실적인 장벽으로 설계, 구축, 운영이 각각 분리 발주되는 구조를 지목합니다.
설계 단계는 클라우드 네이티브 요소를 반영하려고 해도 레거시 시스템의 세부 의존성이나 숨겨진 결합 구조를 모두 파악하기 어렵습니다. 그 결과 설계 문서는 그럴듯하게 완성되더라도, 실제 전환 단계에 들어가면 빠진 요소가 드러나고 다시 설계를 손봐야 하는 상황이 반복됩니다.
3. 레거시 시스템의 숨은 결합 구조가 전환을 더 어렵게 만든다
공공 시스템은 오랜 기간 운영되면서 다양한 레거시 솔루션과 애플리케이션이 강하게 결합된 경우가 많습니다. 문제는 이런 구조가 겉으로 잘 드러나지 않는다는 점입니다. 설계 단계에서 이를 충분히 반영하지 못하면, 구축 단계에서 예상치 못한 수정이 발생하고 일정과 범위가 계속 흔들리게 됩니다.
즉, 공공 클라우드 전환이 어려운 이유는 단순히 새 기술을 적용하기 어렵기 때문이 아니라, 기존 시스템의 복잡한 맥락을 구조적으로 끌고 가야 하기 때문입니다.
4. 일정 압박이 커지면 애자일이 아니라 다시 워터폴로 돌아간다
전환 구축 사업은 원래 일정이 빠듯한데, 설계 검토와 누락 보완에 시간이 많이 들면 초기 의도와 달리 점점 일정 중심으로 흘러가게 됩니다. 영상에서는 이렇게 되면 결국 워터폴 방식으로 회귀하고, 오픈도 단계적 전환이 아니라 한 번에 여는 빅뱅 방식으로 진행되는 경우가 많다고 설명합니다.
즉, 공공기관이 클라우드 네이티브를 지향해도 실제 실행 구조가 이를 받쳐주지 못하면 결과는 다시 전통적인 대형 구축 방식으로 돌아가게 됩니다.
5. 구축이 끝나도 운영 단계에서 민첩성이 끊긴다
분리발주의 문제는 구축 단계에서 끝나지 않습니다.
구축 사업자가 빠지고 운영 사업자가 들어오면, 이미 확정된 설계를 바꾸기 어렵고 운영 쪽에서는 “일단 돌아가면 건드리지 말자”는 방식으로 움직이기 쉽습니다. 그 결과 사용자 요청이 들어와도 바로 수정·배포되는 DevOps 사이클이 작동하지 않고, 변경 요구사항이 몇 달씩 쌓였다가 한꺼번에 처리되는 식으로 운영됩니다. 이 구조에서는 MSA를 도입해도 민첩한 서비스 개선이라는 본래 목적을 달성하기 어렵습니다.
6. 공공기관의 순환보직은 책임과 맥락의 연속성을 끊는다
영상은 또 다른 핵심 문제로 공공기관의 순환보직을 꼽습니다.
순환보직은 원래 부정부패 방지 같은 긍정적 취지에서 도입된 제도이지만, IT처럼 전문성과 맥락 축적이 중요한 영역에서는 단점이 크게 나타납니다.
담당자가 2~3년 단위로 바뀌면 시스템에 대한 이해, 전환 과정의 배경, 의사결정의 이유가 축적되기 어렵고, 새 담당자가 이전 담당자와 관점이 다르면 이미 진행하던 방향이 뒤집히는 일도 생깁니다.
7. 담당자 변경은 코드보다 ‘문서 전체 수정’이라는 더 큰 비용을 만든다
담당자가 바뀌고 요구사항 방향이 달라지면, 시스템만 바꾸는 것으로 끝나지 않습니다. 공공 프로젝트는 문서와 산출물이 매우 많기 때문에, 작은 방향 수정도 문서 전반의 수정으로 이어집니다. 영상은 이런 구조가 과제 수행 업체 입장에서 큰 부담이 되며, 변화 비용을 키우는 원인이 된다고 설명합니다.
결국 순환보직은 단순한 인사제도가 아니라, 공공 클라우드 전환의 실행 속도와 안정성에 직접 영향을 주는 구조적 변수로 작동합니다.
8. 해법 중 하나는 협업 도구 기반의 ‘과정 기록’이다
이 문제를 줄이기 위한 현실적인 대안으로 영상은 협업 체계와 협업 도구의 활용을 제시합니다. 최종 산출물만 남기는 방식으로는 왜 그런 결정이 내려졌는지, 어떤 논의와 수정이 있었는지 보이지 않습니다.
반면, 협업 도구를 활용해 회의 내용, 변경 이력, 논의 과정, 판단 배경을 구조적으로 기록해 두면 다음 담당자에게 훨씬 자연스럽게 이관할 수 있습니다. 즉 문서 결과물만 남길 것이 아니라, 의사결정 과정 자체를 살아 있는 형태로 축적해야 한다는 뜻입니다.
9. MSA는 기술 다양성을 허용하지만, 운영 관점에서는 표준화가 더 중요하다
영상은 MSA의 지향점 중 하나로 폴리글랏(Polyglot), 즉 기술 다양성을 언급합니다. 서비스별로 가장 잘 맞는 오픈소스와 기술 스택을 쓰는 것이 이상적으로 보일 수 있습니다.
하지만 현실적으로 공공기관 운영 환경에서는 각 기술마다 전문가를 모두 확보하기 어렵고, 다양한 오픈소스를 무한정 섞으면 운영 복잡성이 급격히 커집니다. 따라서 최적의 기술을 서비스마다 따로 고르는 것보다, 운영 가능한 표준 기술 스택을 먼저 정하는 것이 더 현실적이라고 설명합니다.
10. ‘서비스별 최적 기술’보다 ‘운영 가능한 표준’이 더 중요하다
프론트엔드, 백엔드, 데이터베이스를 모두 자유롭게 조합하면 설계 단계에서는 유연해 보일 수 있습니다.
하지만 운영 단계에서는 기술별 전문가 확보, 장애 대응, 버전 관리, 교육, 인수인계가 모두 어려워집니다. 그래서 영상은 예를 들어 프론트엔드, 백엔드, 인프라 기술 스택을 일정 수준 표준화해 놓으면 운영 복잡성을 크게 낮출 수 있다고 설명합니다.
즉, 공공 MSA는 기술 실험의 자유보다 안정적 운영 체계를 먼저 설계해야 성공 가능성이 높아집니다.
11. 공공기관에는 설계부터 운영까지 잇는 플랫폼적 접근이 필요하다
영상 후반부에서는 이런 구조적 문제를 줄이기 위해 플랫폼 기반 접근이 필요하다고 강조합니다. 공공기관이 특히 요구하는 것은 설계부터 운영까지 일관된 산출물이 나오는 구조인데, 분리발주 환경에서는 각 단계 결과물이 서로 달라져 정합성을 맞추는 데 큰 비용이 듭니다.
반면 자동화된 플랫폼 위에서 표준화와 운영 체계를 같이 가져가면, 설계·구축·운영이 서로 다른 조직이더라도 동일한 기준 위에서 일할 수 있게 됩니다.
12. 플랫폼은 표준화, 자동화, 비용 최적화까지 연결된다
영상에서 말하는 플랫폼은 단순한 관리 화면이 아니라, 표준화된 산출물과 자동화된 운영 방식을 동시에 제공하는 기반입니다. 이런 플랫폼이 있으면 24시간 오토스케일링, 자동화된 FinOps, 운영 최적화 같은 기능을 통해 비용 관리도 쉬워집니다.
결국 플랫폼은 기술 도구가 아니라, 사람이 바뀌어도 운영 철학과 기준을 유지해 주는 공공 클라우드 전환의 공통 기반 역할을 하게 됩니다.
13. 사람보다 플랫폼에 철학을 남겨야 한다
이 영상의 메시지를 한 문장으로 정리하면, 공공 클라우드 전환은 사람 개인의 역량에만 의존해서는 안 되고 플랫폼 안에 운영 철학과 표준을 남겨야 한다는 것입니다. 담당자가 바뀌더라도 플랫폼에 축적된 기준과 자동화 체계, 협업 이력이 남아 있다면 인수인계와 운영 연속성이 훨씬 좋아집니다.
즉, 공공 클라우드 전환의 성공 조건은 최신 기술 도입 그 자체보다 구조적 단절을 메워 줄 공통 운영 기반을 어떻게 만들 것인가에 달려 있습니다.
14. 3줄 요약
– 공공기관 클라우드 전환이 어려운 진짜 이유는 기술 부족이 아니라 설계·구축·운영의 분리발주와 순환보직 같은 구조적 문제다.
– MSA와 클라우드 네이티브의 목적은 구축이 아니라 민첩한 운영인데, 현실에서는 워터폴·빅뱅 방식으로 회귀하며 DevOps 사이클이 끊기기 쉽다.
– 해법은 협업 이력 축적, 운영 가능한 표준화, 그리고 설계부터 운영까지 일관성을 유지하는 플랫폼 기반 접근에 있다.
◼ 전체 잇(IT)터뷰 내용은 ▶영상으로 바로 가기(클릭)◀에서 확인하실 수 있습니다. |
◼ 콘텐츠 & 웨비나 문의 : marketing@talkit.tv, 02-565-0012
Copyright ⓒ 토크아이티 All rights reserved. 무단 전재 및 재배포 금지.