2주차에 접어든 에이블스쿨 Step 2.
지난주에 허리때문에 정신 없어서 이야기 못했지만,
Step 2는 AI 모델링 기술보다는 DX에 대한 비즈니스적 접근 위주로 배운다.
오늘부터 볼 것은 DX의 대표적인 기술인 클라우드이다.
DX 이해
- DX 정의
DX(DT)는 Digital eXchange(Transformation).
즉 디지털 전환을 통해 비즈니스에 혁신을 불러 오려는 시도들을 말한다.
DX의 세 가지 핵심 목표가 있는데,
뻔한 이야기라고는 해도 가장 중요한 요소로 받아들일 필요가 있다.
< DX의 목표 > ( = DX를 수행하는 이유)
고객/사용자 중심 체계 구축
변화에 민첩/유연한 대응
지속적인 차별화/혁신
- DX의 필수요건 : 클라우드
DX 성공 사례는 많다.
하지만 공부하는 입장에서 더 주의 기울여야 할 곳은 실패 사례겠지.
맥킨지&컴퍼니에 따르면, DX 추진 기업 중 성공사례는 고작 30%에 불과하다.
예를 들어 Ford는 DX에 많은 투자를 했지만,
그저 기술을 추가적으로 도입한 것에 지나지 않았다.
비즈니스가 제대로 통합되지 않아 협업이 마모된 결과,
막대한 투자 손실을 안고 새로이 DX를 시도중이다.
이처럼 DX는 단순한 기술 도입, 기술 혁신의 측면에서 바라볼 수 없다.
이미 10년간 지속된 DX 트렌드의 결과를 보면,
목표/조직/프로세스의 조정·변화가 있어야만 성공적인 DX가 가능함을 알 수 있다.
데이터센터를 기반으로 하는 기존의 On-Premise형 IT 환경은,
DX를 추구하기에 적합한 환경은 아니었다.
우선 각종 인프라, 개발 프로세스, IT 조직 등을 위해
많은 인적/물적 비용이 지속적으로 필요하기 때문이다.
또한 가변적인 비즈니스 요구에 대응하기 위해서는
물리적 인프라의 증설/감축이 필요한데 이는 현실적으로 매우 어렵다.
따라서, DX에 요구되는 핵심 기술은 이를 해결할 수 있는 클라우드 컴퓨팅 기술이다.
< 클라우드 컴퓨팅의 장점 >
1. 민첩성
- 인프라 자원(컴퓨팅, 스토리지, 데이터베이스 등)
- 서비스(머신 러닝, 데이터 레이크 등)
이런 것들을 빠르게 확보/활용할 수 있다.
예를 들어, 서버의 기능을 하는 VM에 대해 생각해 보자.
서버를 물리적으로 사서 들여오는 과정에 비해,
VM을 통한 환경 구축은 고작 수 분만에 가능하다.
모더나가 클라우드를 통해 코로나 백신 개발 시간을 극적으로 단축시킨 사례가 유명하다.
2. 탄력성
네이버는 2018년 월드컵 때 서버 인프라를 2배로 증설했음에도
순간적인 트래픽 변화에 따라가지 못했었다.
클라우드 기술은 필요에 따라 리소스를 활용하고, 그에 맞춘 비용을 지불한다.
따라서 비즈니스 변화에 탄력적으로 따라갈 수 있다.
코로나 시절 폭증한 ZOOM의 트래픽에 대비하여
서버 용량 확보를 한 사례가 유명하다.
3. 비용 최적화
사실 탄력성에 딸려 오는 장점이다.
KBS에서 클라우드 기반 서버 활용을 통해 비용을 절반으로 줄인 사례가 있다.
4. 전세계에 배포
클라우드 벤더는 전 세계에 인프라를 구축해 놓은 상태이다.
따라서 서비스 제공자로서는 극히 짧은 시간에 글로벌 확장/배포를 할 수 있다.
또한 글로벌 네트워크를 기반으로 고가용성 인프라를 쉽게 조성할 수 있다.
넷플릭스의 발빠른 글로벌 확장은 이로 인해 가능했다.
5. 애플리케이션에 집중
기존의 IT 인프라보다 비용도 시간도 절약 가능하기에,
비즈니스 자체에 더 집중할 수 있게 된다.
클라우드 개요
- 클라우드 서비스 모델의 종류
| IaaS (Infra) | 네트워크, 서버, 스토리지 등의 인프라 환경을 제공함 |
| PaaS (Platform) | IaaS + 소프트웨어 개발 환경을 제공함 |
| SaaS (Software) | 구독 형태로 바로 서비스 사용 (MS office 등) - 하위 인프라/플랫폼을 알 필요 없음 |
- 클라우드 배포 모델
인프라에서 배웠던 내용이다.
퍼블릭/프라이빗/하이브리드/멀티 클라우드를 배포 모델이라고 한다.
초기에는 보안상의 이슈로 인해
'능력이 되면 프라이빗'을 사용하는 경우가 많았다.
하지만 최근에는 대기업들도 퍼블릭 클라우드 서비스를 도입하면서
점점 하이브리드 클라우드의 시대가 되고 있다.
이는 데이터의 다원화와 양적 증가가 동반되면서 일어난 일이다.
프라이빗 클라우드 특성상 On-Premise 방식의 경직성에서
완전히 자유로울 수는 없다.
따라서 이제는 데이터를 나누어
'반드시 프라이빗일 필요는 없는' 것들은 퍼블릭 클라우드를 사용하기 시작한 것.
단, 하이브리드 클라우드는 유지가 어렵고 복잡하다는 점을 주의해야 한다.
클라우드 벤더
- 클라우드 벤더
클라우드 서비스 제공자를 클라우드 벤더라고 한다.
큰 기업에서는 Lock-in(종속) 문제로 인해 멀티 클라우드를 사용하는 일이 잦은데,
이때 각 클라우드 벤더의 장단점을 평가하는 경우가 있다.
여기서 알아야 될 보고서가 Magic Quadrant이다.
Magic Quadrant란 Gartner사의 보고서로,
특정 시장에서 각 벤더들의 역량이 어떤지를 평가하는 지표로 쓰인다.
이 Magic Quadrant와 시장 점유율 등을 바탕으로 도출한 주요 클라우드 벤더들을 보자.
- 글로벌 Big 3 클라우드 벤더
글로벌 클라우드 시장 점유율의 대부분은 아마존(AWS), MS(Azure), 구글(GCP)에 있다.
간단하게만 정리하자면,
AWS는 선발 주자로 많은 개발자들이 유입되어 있고,
이 생태계로 인해서 가장 많은 서비스 유형이 존재한다.
Azure는 기존 MS Office 및 Window 사용 고객을 보유한 만큼 마케팅적 강점이 있고,
Window와의 호환성 측면에서도 유리한 부분이 있다.
이것은 SaaS상의 강점을 IaaS, PaaS로 확장한 것이라고 볼 수 있다.
그런 면에서 하이브리드 클라우드에 유리한 모습(Azure Stack)으로 나타난다.
GCP는 오픈소스 생태계를 주도하는 구글 답게
클라우드의 관리형 서비스 및 데이터 분석 경쟁력을 갖추고 있다.
또한 AWS나 Azure에도 친화적인 멀티 클라우드 지원 CSP라고 할 수 있다.
- 국내의 클라우드 시장
국내 클라우드 시장 또한 글로벌 big3 벤더가 60% 이상 장악하고 있다.
다만, 가장 큰 시장인 금융권과 공공 영역에는 발을 들이지 못하고
이 영역에는 대신 국내 클라우드 기업들이 진출해 있는 상황이다.
< 금융 클라우드 시장과 공공 클라우드 시장 >
금융권은 기본적으로 보안상 프라이빗 클라우드 중심으로 인프라를 운용해 왔다.
하지만 앞서 말했듯 데이터가 늘어날수록 이는 한계가 있기 때문에,
차츰 하이브리드 클라우드의 모습으로 바뀌는 중이다.
그런데 보안 이슈 및 장애 조치(DR) 측면에서 보면,
데이터센터와 인력은 물론이고 결정 권한까지 국내에 있는 업체가
안정성과 신속성 측면에서 더 유리한 측면이 있다.
공공 분야에서 클라우드 도입은 정부의 주요 추진 사업 중 하나이다.
(행정안전부 공공 부문 클라우드 전환 사업)
이때 54 : 46의 비율로 공공 클라우드 센터와 민간 클라우드 센터로 나누는데,
규제로 인해 실제로는 민간 클라우드를 쓰기 어려워 협의가 필요한 부분이 있다.
한편 이때 클라우드 서비스 보안인증(CSAP)을 의무 취득하게 하는데,
이 기준은 외국계 클라우드 기업이 충족하기가 쉽지 않다.
이로 인해 국내 클라우드 기업이 공공 분야에서 강세를 보인다.
국내의 대표적인 CSP로는 KT, 네이버, NHN, 카카오 등이 있다.
| KT 클라우드 | 국내 최초 퍼블릭 클라우드 수도권 7개, 전국 13개 데이터 센터 보유 국내 8000건 이상의 구축 사례 |
| 네이버 클라우드 | 자회사만 쓰던 네이버 비즈니스 플랫폼(NBP)이 퍼블릭 클라우드까지 확장 최근 공공, 금융부문으로 확대 세계 10개국에 인프라 운영 중, 글로벌 확장 도모 |
| NHN 클라우드 | 공공, 금융 중심 레퍼런스 보유 판교. 평촌 외에도 김해, 광주, 순천 등에 데이터센터 구축 중 |
| 카카오 엔터프라이즈 | CSP 후발 주자 카카오가 가진 ICT 기반으로 퍼블릭 클라우드 구축 멀티 클라우드 전략을 병행하는 중 |
클라우드 관련 기술
| 가상화 (Virtualization) |
인프라 시간에 배운, 가상 머신과 관련된 것 필요한 리소스를 가상 환경에서 생성 및 관리하는 기술 |
| 분산 처리 (Distributed Processing) |
하나의 대용량 서버가 아닌, 여러 저용량 서버가 연산을 병렬 처리하는 기술 클러스터링, 오토스케일링 등의 기반 기술 |
| 오토 스케일링 (Auto Scaling) |
모니터링을 통해 리소스 개수를 자동으로 조절하는 기술 |
| 로드 밸런싱 (Load Balancing) |
트래픽 급증 시 여러 대의 서버에 분산시키는 기술 |
| 서버리스 (Serverless) |
인프라를 직접프로비저닝하지 않고, 요청이나 트리거가 발생했을 때만 인프라를 구동 |
| 데브옵스 (DevOps) |
기술이라기보다는 일련의 프로세스 또는 문화에 가깝다. 개발팀과 운영팀 간의 소통을 중심으로 하는 개발 환경. |
| 클라우드 AI | 클라우드와 AI의 결합 |
조금씩 더 디테일하게 보자.
- 가상화
서버 가상화, 네트워크 가상화, 데스크탑 가상화 등 다양한 방식이 존재한다.
서버 가상화를 통해 하나의 물리적 서버 위에 다수의 가상 서버를 쓸 수 있고,
이는 다시말해 서버 기기의 사용률을 최적화한다는 뜻이다.
따라서 물리적 서버의 개수를 최소화할 수 있다.
하이퍼바이저 등 자세한 사항은 지난 시간에 했으니까 패스.
네트워크 가상화는 물리적 네트워크에서 여러 가상 네트워크를 실행하는 것이다.
NFV, SDN 등의 기술이 있는데 이를 바탕으로 내부적 서브넷을 만든다.
라우팅, 방화벽, 로드밸런싱 등 물리적 네트워크와 똑같이 제어가능하다.
데스크톱 가상화는 데이터 센터 서버에서 가상의 컴퓨터 환경을 만드는 기술이다.
이 방식으로 작업하면 데이터가 로컬 PC가 아닌 데이터센터에 저장되므로
보안이나 관리 효율성 측면에서 좋다.
- 오토 스케일링
On-Premise 시스템에서 인프라를 확장하는 것을 스케일링이라고 한다.
이는 Scaling Up과 Scaling Out으로 나뉘는데,
전자는 서버의 사양을 수직적으로 늘리는 것,
후자는 서버의 개수를 수평적으로 늘리는 것이다.
둘 다 일장일단이 있으나 오토 스케일링은 이 둘의 단점을 완전히 극복한 방식이다.
리소스의 개수를 실시간으로 조절함으로써,
'딱 필요한 만큼'만 '딱 필요한 시간동안' 사용한다.
당연히 비용 측면에서 최적화, 운영 측면에서 안정화, 유연화가 가능하다.
- 서버리스
클라우드 컴퓨팅의 최신 형태라고 불리는 방식이다.
서버리스 시점부터 사용자는 IaaS니 PaaS니 신경쓸 필요가 전혀 없어진다.
인프라가 계속 구동되는 것이 아니기에 비용도 절감되고,
배포 및 관리 작업도 필요없으므로 개발 집중도가 높아진다.
- 데브옵스
데브옵스는 문화라고 했지? 이를 실현하기 위한 두 가지 기술이 바로
CI/CD와 자동화 툴이다.
CI(Continuous Intergration)는 여러 개발자의 소스 코드를 지속적으로 통합하고,
자동화된 테스트를 진행하여 문제를 신속하게 검출 및 해결하는 것이다.
CD(Continuous Delivery)는 테스트가 완료된 코드를 저장소에 자동으로 업로드하는 것이다.
컨설팅
고객이 업무상 겪는 비즈니스 문제를 해결할 수 있는 방안을 제시하는 행위이다.
컨설턴트의 업무는 크게 세 가지이다.
| Planning | 처한 상황에 맞는 사업 계획, 비용, 활동 제시 |
| Presales | 프로젝트 수주를 위한 제안서 작성 |
| PMO | 프로젝트 관리 & 어드바이스 |
특히 메인이 되는 것은 Planning 업무이고,
이 업무는 3단계로 나뉜다.
① As - Is 분석 : 업무 분석, 시스템(인프라, App 등)상 이슈 분석
② To - Be 설계 : 아키텍처 설계하여 개선방안 제시
③ 사업화 방안 제시 : 프로젝트 일정, 자원, 예산, 투자대비효과 제시
이를 원활히 수행하기 위해서는 폭넓은 분야에 대한 이해가 필요하다.
특히 비즈니스 / 트렌드 / 프로세스뿐만 아니라 기술 관점의 문제 인식과 해결이 가능해야 한다.
DX 컨설턴트 과정에서 우리가 IT를 배우는 이유겠지.
계정 관리(Access Control)
클라우드에 접근하는 사용자의 접근과 권한을 통제하는 것.
그렇다. 보안이다.
클라우드 서비스에서는 리소스나 서비스가 공유되는 경우가 많기에,
관리자를 제외한 사용자에게는 직무에 따라 제한된 접근만을 허용하는 것이 바람직하다.
이를 IAM(Identity & Access Management)이라고 한다.(AWS 기준)
모든 권한을 가진 root 사용자가 IAM 사용자를 생성하여,
최소한의 권한(Least Privilege)을 할당한다.
(이를 정의하는 문서를 정책(Policy)라고 한다.)
정책은 사용자에게 적용할 수도 있지만,
리소스에 적용할 수도 있다.
클라우드 내에서 유저가 접근할 수 있는 환경은 세 가지인데,
콘솔, CLI, SDK이다.
각각 일반 사용자(콘솔), 운영자(CLI), 개발자(SDK)가 접근하는 환경이라고 생각하면 편하다.
이 환경들에서 사용자가 진행하는 조작은 모두 API를 기반으로 통신하여
클라우드의 리소스에 접근한다.
그런데 우리는 종종, 사용자에게 임시 접근권한을 부여해야 할 상황이 있다.
물론 잠깐 권한을 풀어줘도 되지만, 줬다가 뺏었다가 하기 힘들잖어.
그래서 일정 시간이 지나면 자동으로 권한이 소멸하는 임시 접근권한을 준다.
그것을 IAM Role이라고 부른다.