해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 60 - Migrating a monolith to Cloud-Native and the stumbling blocks that you don’t know about
1. 모놀리식에서 클라우드 네이티브로
기업들이 클라우드 네이티브 생태계로의 전환을 결정할 때, 흔히 범하는 착각이 있다.
"물리 서버에서 VM으로 옮기는 것과 VM에서 컨테이너로 옮기는 것이 똑같다"라는 생각이다.
하지만 이는 완전히 다른 기술 스택이며, 숙제를 제대로 하지 않으면 컨테이너화의 비용 절감, 효율성 같은 장점은 지켜지지 않는다.
전환을 시작하기 전, 혹은 이미 시작해서 늪에 빠졌다면 다음 질문들에 답해보아야 한다.
1) 누가 실제로 컨테이너화했는가?
-
현상: 운영팀이 개발팀과의 깊은 소통 없이 단순히 앱을 컨테이너에 넣고 돌리는 경우가 많다.
-
문제점: 운영팀은 앱의 내부 의존성이나 구조를 모른다. 개발팀이 주도하여 앱을 쪼개고 종속성을 파악하지 않으면, 인프라 요구사항이 완전히 어긋나게 된다.
2) 왜 컨테이너화했는가?
-
현상: "임원이 시켜서", "CIO가 잡지에서 본 최신 기술이라서" 진행한다.
-
조언: 이미 흑자를 내고 잘 돌아가는 소프트웨어를 리스크를 감수하며 옮길 비즈니스적 이유가 없다면, 멈춰야 한다.
3) 어디에 배포하는가? (선택인가 강요인가)
-
현상: 기술적 적합성보다 ELA(기업 라이선스 계약)에 딸려온 무료 크레딧 때문에 특정 클라우드를 강제로 선택한다.
-
위험성: 이는 첫해 무료를 외치는 마약상의 전략과 같다. 머신러닝 등 특정 하드웨어가 필요한 경우, 강요된 클라우드는 프로젝트 실패의 원인이 된다.
4) 무엇을 컨테이너화했는가?
-
현상: WAR/EAR 파일 통째로 도커에 넣고 "전환 완료"라고 착각한다.
-
현실: 기업용 앱의 복잡한 의존성을 무시한 포장갈이에 불과하다. 이는 클라우드 네이티브가 아니다.
2. 아키텍처의 변화: 리플랫폼을 넘어 리팩터링으로
단순 리플랫폼은 그저 첫 단계일 뿐이다.
기존 레거시 앱을 WebSphere Liberty 등에 넣어 쿠버네티스에 올리는 것 (Re-platform)은 그저 앱이 포트 8080에서 응답한다는 것을 증명한 수준이다.
이는 운영 준비가 된 상태가 아니며, 앞서 설명한 그저 포장갈이에 불과한 행위이다.
진정한 클라우드 네이티브를 위해서는 앱을 쪼개야 한다 (Refactoring)
해당 케이스에서는 IBM MQ나 RabbitMQ 같은 메시지 큐를 공유하며 통신하도록 분리해야 한다.
-
스트랭글러 패턴(Strangler Pattern): 거대 모놀리스를 한 번에 바꾸는 것이 아니라, 점층적으로 작은 마이크로서비스로 쪼개어 기능을 이관하는 방식을 사용해야 한다.
-
언어의 변화: 앱을 쪼개다 보면 모든 것이 Java일 필요가 없음을 깨닫게 된다. 숫자 계산은 Python, 백엔드 처리는 Node나 Go가 더 효율적일 수 있다. 결국 다양한 언어가 섞인 환경이 된다.
또한 속도와 확장성에 대한 쿠버네티스에 대한 오해에 대해서 짚고 넘어갈 필요가 있다.
-
작은 Pod의 중요성: 쿠버네티스에서 거대한 Pod 하나를 띄우는 것보다, 수평 확장이 가능한 작은 Pod 여러 개를 띄우는 것이 훨씬 효율적이다.
-
쿠버네티스는 단순 스케줄러다:
-
애즈가 랩스 (가상의 기업)는 Java 앱 내부에 Batch Job 스케줄러를 내장한 채로 쿠버네티스에 올림.
-
그 결과 배치 작업이 돌 때마다 특정 노드의 RAM을 95%씩 점유하며 과부하를 일으켰다.
-
배치 작업을 별도의 마이크로서비스로 분리해 쿠버네티스가 스케줄링하고 부하를 분산하도록 만들어야 한다.
-
플랫폼(K8s)의 기능을 활용하지 못하고 기존 방식을 고수하면 장애로 이어진다.
-
3. 기술 너머의 장벽들: 복잡성, 문화, 비용
3-1. 복잡성의 시각화와 '살인 미스터리' 추리극
클라우드 네이티브는 관리가 쉬워지는 것이 아니라, 관리의 형태가 바뀌는 것이다.
-
개(Dog) 비유
-
모놀리스: 거대한 불마스티프(대형견) 1마리. 밥 주고 산책시키는 노력이 든다.
-
마이크로서비스:
-
짖어대는 치와와 13마리.
-
총 노력(밥, 산책)은 비슷하지만, 이동이나 관리는 작은 개 여러 마리가 더 유연할 수 있다.
-
하지만 훨씬 정신없고 복잡하다.
-
-
-
살인 미스터리(Murder Mystery) 추리극
-
서비스가 격리되면서 로그도 파편화된다.
-
표준화된 로깅 시스템이 없다면, 장애 발생 시 각 서비스의 로그를 뒤지는 탐정 놀이를 해야 한다.
-
이는 곧 서비스 중단 시간의 증가로 이어진다.
-
3-2. 문화적 변화: 신뢰와 자동화
-
CCB(변경 제어 위원회)의 종말
-
매주 목요일 오후 임원들이 모여 배포를 승인하던 시대는 끝났다.
-
변화: 사람의 승인이 아닌, Bots과 테스트 결과를 신뢰해야 한다.
-
-
CI/CD와 코드 표준화
-
CI: 단순 빌드가 아니다. 다양한 언어(Python, Go 등)를 쓰더라도 Linting 도구를 강제하여 코드 스타일을 통일해야 운영팀이 새벽에 코드를 읽을 수 있다.
-
CD: 초심자에게 CD는 공포다. 머지 버튼을 누르자마자 배포되는 것을 임원들은 견디지 못한다. 이를 극복하려면 통합 테스트에 대한 절대적 신뢰가 필요하다.
-
-
협업 방식의 혁신:
-
방법: 매 스프린트(2주)마다 개발자를 다른 팀으로 강제 이동시킴.
-
효과: 초기엔 고통스럽지만, 몇 달 후 문서화(Getting Started)가 완벽해지고 팀 간 부족 지식(Tribal Knowledge)이 사라짐.
-
3-3. 운영의 현실: 모니터링과 경제성
-
경제적 충격 (CapEx vs OpEx)
-
감가상각 불가: 데이터센터(CapEx)와 달리 클라우드 비용(OpEx)은 감가상각이 불가능하다.
-
예측 불가능성:
-
실수로 API를 호출해 자원을 무한 생성하면 요금 폭탄을 맞는다. (이번 달 6천 불 -> 다음 달 10만 불).
-
CFO는 예측 불가능한 비용 구조를 매우 싫어하므로 이에 대한 설득이 필요하다.
-
-
-
지원 체계의 부재
-
클라우드 네이티브는 오픈소스 집합체다. 문제 발생 시 멱살 잡을 단일 벤더(Throat to choke)가 없다.
-
스택 오버플로우, KubeCon, SIG 커뮤니티에 직접 참여하여 해결책을 찾아야 한다.
-
4. 결론
-
잘 돌아가는 앱 건드리지 마라
-
이미 돈을 잘 벌고 있는 레거시 앱을 억지로 이전하지 마라.
-
엔지니어링 비용과 시행착오로 인해 흑자 프로젝트가 적자로 돌아설 위험이 매우 크다.
-
-
다음 프로젝트부터 시작하라
- 기존 앱을 뜯어고치는 것보다, 차세대 애플리케이션을 처음부터 클라우드 네이티브로 설계하는 것이 훨씬 이득이다.
-
도구의 적절성 (Saw vs Hammer)
-
망치가 필요한데 톱을 쓰거나, 톱이 필요한데 망치를 쓰지 마라.
-
두 도구 모두 나무를 다룰 순 있지만, 용도에 맞지 않으면 비효율적이고 우스꽝스러운 결과만 낳는다. 클라우드 네이티브가 만능열쇠는 아니다.
-
즉, 클라우드 네이티브는 만능열쇠가 아니며, 단순한 기술 도입을 넘어 조직과 아키텍처의 근본적 체질 개선을 요구한다.
따라서, 억지스러운 마이그레이션으로 기존의 흑자 프로젝트를 위협하기보다, 차세대 프로젝트부터 클라우드 네이티브를 적용해 온전한 가치를 창출하는 것이 가장 현명한 전략이다.
