2주차WEEK 03 · 컴퓨팅 기초와 클라우드
서버 소유 없이
세계로 확장
- 빠르고 싼 컴퓨팅이 만든 사업의 변화
- 가상화·오픈소스·클라우드의 연결
- Netflix와 한국 데이터센터의 실제 선택
컴퓨팅은 사라지지 않음보이지 않는 곳으로 이동
오늘의 중심 질문
기업은 왜 서버를 직접 소유하지 않는가
- 소유 비용보다 중요한 것은 변화 속도
- 클라우드는 컴퓨터가 아니라 운영 방식
- 통제·비용·속도 가운데 무엇을 남길지 선택
속도필요할 때 바로 확보
수개월의 구매·설치 대신 몇 분 안에 시작
탄력성수요에 맞춰 증감
평소와 행사일의 용량을 다르게 운영
집중차별화 업무에 역량 투입
서버 관리보다 고객·제품·데이터에 집중
01무어의 법칙
기술의 가격·성능 변화가 시장을 여는 과정
02병렬처리
하나를 빠르게 만드는 것과 여러 개를 함께 쓰는 차이
03가상화
물리 자원과 논리 환경을 분리하는 원리
04서비스 모델
IaaS·PaaS·SaaS의 책임 경계
05클라우드 경제성
고정비·변동비·숨은 비용 비교
06관리자 선택
보안·주권·복원력·환경까지 포함한 판단
1부성능
무어의 법칙·병렬처리
2부구조
가상화·컨테이너·오픈소스
3부서비스
IaaS·PaaS·SaaS
4부사례
Netflix·네이버·카카오
5부책임
비용·보안·전력·폐기
첫 판단
온라인몰 행사일, 접속자가 평소의 20배
- 오늘 밤까지 대응해야 함
- 내일 이후 수요는 다시 줄어들 수 있음
핵심 · 정답 하나보다 비용·시간·위험의 조건을 먼저 밝히기
1부 · 빠르고 싼 컴퓨팅
같은 돈으로 더 많은 계산
- 성능 상승과 가격 하락이 동시에 진행
- 기존 제품 개선보다 새로운 시장의 탄생이 더 중요
성능더 복잡한 문제 처리
가격더 많은 사람에게 보급
크기제품 안으로 내장
전력효율과 냉각이 새 병목
무어의 법칙
집적회로의 복잡성은 일정한 주기로 증가
- 1965년 고든 무어의 관찰에서 출발
- 흔히 약 18∼24개월마다 트랜지스터 수가 두 배로 설명
- 자연법칙이 아니라 산업의 투자·설계·제조가 만든 자기실현적 목표
정확한 뜻트랜지스터 집적도의 장기 경향
컴퓨터 속도가 무조건 2배라는 문장과 같지 않음
관리자의 뜻오늘 비싼 기능이 내일 대중화
기술 가격 하락이 새 고객·새 제품·새 업무를 엶
지수적 변화 읽기
처음에는 작아 보여도 뒤에서 급격히 벌어짐
2천1971
120만1989
2억2006
수백억2020
칩렛·가속기현재
직선이 아니라 배수
- 초기 변화는 과소평가하기 쉬움
- 후반에는 시장 구조까지 바꿈
- 과거 추세를 미래 보증으로 오해하면 안 됨
무어 이후
한 칩의 속도 경쟁 → 전체 시스템 설계
다중 코어
여러 계산 단위를 한 칩에 배치
병렬처리
작업을 나눠 동시에 계산
전용 가속기
GPU·TPU·NPU로 특정 연산 최적화
칩렛·패키징
여러 기능 블록을 묶어 성능·수율 개선
속도 향상 방식의 변화 · 더 높은 주파수보다 병렬성·전용화·효율
병렬처리
사람을 늘려도 일이 무한히 빨라지지 않음
- 나눌 수 있는 계산은 여러 장치에 배분
- 순차 작업·통신·동기화가 전체 속도의 한계
- GPU와 클러스터가 강해도 문제 구조가 맞아야 효과
01문제 분할
서로 독립적인 작업 찾기
02동시 계산
CPU·GPU·서버에 배분
03데이터 이동
메모리·네트워크 병목
04결과 결합
부분 결과를 모아 검증
05관리 비용
오류·대기·동기화 처리
암달의 법칙 · 병렬화할 수 없는 부분이 최대 속도 향상을 제한
Chapter 6.3 · 병렬처리·클러스터·클라우드가격 탄력성
싸지면 덜 쓰는 것이 아니라 새 용도가 생김
값싼 칩이 전화기를 카메라·지도·결제·영상 기기로 바꿈01기존 수요 확대
더 많은 저장·더 높은 화질·더 잦은 분석
02새 고객 진입
대기업 전용 기술이 중소기업·개인에게 확산
03새 시장 탄생
스마트폰·스트리밍·생성형 AI·IoT 서비스
관리자의 질문 · “더 싸졌다”가 아니라 “이제 무엇이 가능해졌나”
컴퓨팅의 파도
희소한 중앙 장비에서 생활 속 기반으로
1940s · 방 전체가 한 대의 컴퓨터
2000s · 손 안의 연결된 컴퓨터
현재 · 보이지 않는 대규모 계산 기반중앙정부·대기업의 희소 자원
부서미니컴퓨터와 업무 전산화
개인PC·모바일의 대중화
어디서나클라우드·AI·엣지
IoT
컴퓨터가 제품 안으로 들어감
- 센서가 상태를 측정
- 네트워크가 데이터를 전송
- 소프트웨어가 판단·제어
- 클라우드가 여러 장치의 기록을 결합
현장 장치가 만드는 신호를 서비스와 의사결정으로 연결01장치
온도·위치·진동을 측정
02연결
Wi‑Fi·5G·LPWAN으로 전송
03데이터
실시간·이력·이상 패턴 저장
04행동
알림·예측·자동 제어
제품 판매 → 상태를 계속 파악하는 서비스로 수익 구조 변화
Samsung Newsroom · 동아플레이팅 스마트공장한국 사례 · 제조
설비의 진동을 고장 전에 읽기
2부 · 클라우드
컴퓨팅 자원을 인터넷을 통해 서비스로 사용
- 서버를 없애는 기술이 아님
- 누군가의 데이터센터에서 계산·저장·연결
- 핵심은 소유보다 필요할 때 쓰고 측정해 지불하는 방식
필요할 때
자원을 빠르게 요청
쓴 만큼
사용량을 측정해 과금
어디서나
표준 네트워크로 접근
NIST · 다섯 특징
웹에 있으면 모두 클라우드는 아님
01셀프서비스
사람의 수작업 승인 없이 자원 요청
02광범위한 접속
표준 네트워크로 여러 기기에서 접근
03자원 공동사용
여러 이용자에게 자원을 동적으로 배분
04빠른 탄력성
수요에 따라 빠르게 늘리고 줄임
05측정 서비스
사용량을 계량·통제·보고
가상화 전업무 하나 = 서버 한 대
앱 A
낮은 이용률앱 B
낮은 이용률앱 C
낮은 이용률
가상화 후물리 자원을 논리적으로 분리
VM A
격리 환경VM B
격리 환경VM C
격리 환경
물리 현실가상 서버도 실제 장비·전력·냉각·네트워크를 공유함. 가상화는 물리 자원을 없애지 않고 이용률과 배치를 바꿈.
효과 · 통합률 향상, 빠른 복제, 장애 격리 / 과제 · 관리 계층의 복잡성
Chapter 16.11 · Virtualization컨테이너
운영체제 전체보다 애플리케이션 단위를 가볍게
01가상머신
각 환경에 운영체제 포함
강한 격리·상대적으로 무거움
02컨테이너
호스트 커널을 공유
빠른 시작·높은 밀도
03오케스트레이션
다수 컨테이너를 자동 배치
확장·복구·업데이트 관리
Kubernetes의 역할 · 컨테이너 자체가 아니라 많은 컨테이너의 운영
오픈소스
무료 소프트웨어가 아니라 공개된 협업 방식
- 소스코드를 검토·수정·재배포할 수 있는 라이선스
- 개발 속도·표준 확산·공급자 선택의 폭 확대
- 유지보수·보안·인력 비용은 사라지지 않음
ECOSYSTEMLinux
클라우드 서버의 핵심 운영체제
ECOSYSTEMKubernetes
컨테이너 운영의 사실상 표준
ECOSYSTEMPostgreSQL
기업용 오픈소스 데이터베이스
ECOSYSTEMPyTorch
AI 연구·개발 생태계
선택 기준 · 라이선스 + 커뮤니티 + 공급망 보안 + 내부 운영 역량
Chapter 16.2 · Open Source서비스 모델
무엇을 빌리고, 무엇을 직접 책임질까
IaaS서버·저장·네트워크
- 운영체제부터 직접 관리
- 예: EC2·Compute Engine
PaaS실행 환경·DB·배포 도구
- 애플리케이션과 데이터에 집중
- 예: App Service·Cloud Run
SaaS완성된 소프트웨어
- 설정·사용자·데이터 활용 중심
- 예: Google Workspace·Salesforce
책임 경계
위로 갈수록 편해지고, 통제 범위는 줄어듦
계층직접 구축IaaSPaaSSaaS
애플리케이션고객고객고객공급자
데이터고객고객고객공동
실행환경고객고객공급자공급자
운영체제고객고객공급자공급자
가상화고객공급자공급자공급자
서버·저장고객공급자공급자공급자
네트워크고객공급자공급자공급자
편의성의 대가 · 세밀한 통제·이식성·공급자 의존
Chapter 16.9 · 책임 경계와 서비스 모델공용공급자의 공동 인프라
속도·규모·서비스 폭
사설한 조직 전용 환경
통제·규제 대응
하이브리드사내와 공용을 연결
기존 자산·민감 데이터
멀티클라우드둘 이상의 공급자 활용
협상력·복원력 / 복잡성
멀티클라우드는 자동 보험이 아님 · 운영 복잡성과 데이터 이동 비용도 증가
PaaS서비스 개발에 집중
- 애플리케이션은 직접 설계
- 운영체제·DB 관리는 줄임
- 빠른 실험과 배포가 중요
적합한 예 · 예약·추천·민원 서비스
클라우드 경제성
큰 선투자 대신 사용량 기반 비용
직접 구축 · CAPEX 중심먼저 사고, 오래 사용
- 서버·공간·전력·냉각 선투자
- 남는 용량과 부족한 용량 위험
- 감가상각과 교체 주기
클라우드 · OPEX 중심쓰고, 측정해 지불
- 초기 비용과 조달 시간 감소
- 수요 변동에 맞춘 증감
- 지속 사용 시 누적 비용 관리 필요
요금표 밖의 비용서버 가격만이 아니라 공간·전력·냉각·교체·당직·장애 복구까지 총소유비용으로 비교.
클라우드가 항상 더 싼 것이 아니라 불확실성을 다루기 쉬움
01데이터 이동
클라우드 밖으로 내보낼 때 발생하는 비용
02유휴 자원
꺼지지 않은 개발 서버·과도한 저장
03운영 복잡성
모니터링·보안·권한·장애 대응 인력
04잠금 비용
특정 서비스에 깊게 의존한 뒤 이전 비용
총소유비용(TCO) · 구매비 + 운영비 + 사람 + 위험 + 전환비용
직접 구축
최대 수요 기준 고정
클라우드
현재 수요에 맞춤
주의 · 자동 확장에도 상한·비용 알림·장애 정책이 필요
서버리스
서버가 없는 것이 아니라 서버 관리가 감춰짐
01사건 발생
업로드·결제·요청
02함수 실행
필요한 코드만 시작
03자동 확장
요청 수에 맞춰 복제
04측정 과금
실행 시간·호출량
05자동 종료
유휴 서버 최소화
적합 · 짧고 변동이 큰 작업 / 주의 · 지연·관찰성·공급자 종속
복원력
장애를 없애기보다 견디고 회복하도록 설계
01중복
여러 장치·가용영역에 복제
02자동 전환
고장 난 경로를 다른 자원으로 대체
03격리
한 장애가 전체로 번지지 않게 분리
04연습
백업 복구·장애 주입을 실제로 시험
운영은 사람과 절차까지중복 장비가 있어도 전환 절차를 시험하지 않으면 복구되지 않음. 기술·조직·훈련을 함께 설계.
가용성 목표가 높을수록 비용 증가 · 업무 손실과 투자비를 함께 비교
공동 책임
공급자가 안전해도 설정이 틀리면 사고
공급자 책임클라우드의 보안
시설·물리 장비·기본 서비스
고객 책임클라우드 안의 보안
계정·권한·데이터·설정
서비스 모델마다 경계 변화함께 확인
로그·암호화·패치·사고 대응
가장 흔한 질문 · “누가 할까”가 아니라 “누가 확인할까”
잠금과 데이터 주권
나갈 수 있는지까지 보고 들어가기
데이터 위치
어느 국가·지역에 저장되는가
이동 가능성
표준 형식으로 내보낼 수 있는가
서비스 대체
독점 API 없이도 다시 만들 수 있는가
계약 종료
삭제·보관·지원 조건이 명확한가
주권은 ‘국산 여부’ 한 단어가 아니라 통제권·관할권·이동권
3부 · Netflix
2008년 데이터베이스 장애가 전환을 재촉
문제단일 데이터센터의 한계
장애와 급증 수요가 한곳에 집중
선택클라우드 우선 전환
컴퓨팅·저장·데이터 플랫폼을 단계적으로 이동
결과글로벌 확장 기반
국가별 수요 변화에 빠르게 대응
전환의 본질 · 데이터센터를 옮긴 것이 아니라 시스템을 다시 설계
CASE · NETFLIX × AWS
글로벌 서비스의 계산·저장·제작을 클라우드로
AWS 공식 사례속도·규모·세계 접근
- 컴퓨팅·저장·인프라를 빠르게 확장
- 여러 지역에서 서비스 용량 운영
- 가상 제작 스튜디오로 세계 인력 연결
- 콘텐츠 전송 자체는 CDN과 별도 최적화
Netflix on AWS 현재 사례
클라우드 전환은 끝나는 프로젝트가 아님
100+Aurora 이전 대상 클러스터
75%최대 성능 개선 · AWS 사례
28%비용 절감 · AWS 사례
지속EKS·인스턴스 구성·데이터 처리 최적화
읽을 점 · 클라우드 채택 뒤에도 데이터베이스·컨테이너·비용을 계속 재설계
AWS 공식 사례 모음 · 공개 수치의 범위와 조건 확인한국 사례 · NAVER
‘각 세종’은 클라우드의 물리적 얼굴
HYPERSCALE DATA CENTER서버·전력·냉각·로봇
- 대규모 서버와 저장 공간을 단계적으로 확장
- 자연 공기 냉각과 폐열 활용 등 효율 설계
- 로봇을 활용한 서버 운반·운영 자동화
- 클라우드·AI 서비스는 거대한 물리 인프라 위에서 작동
NAVER Cloud 소개서 · 2025 한국 사례 · KAKAO
2022년 장애 뒤, 복원력을 건물부터 다시 설계
KAKAO DATA CENTER ANSAN중복과 격리의 물리 설계
- 전력·냉각·통신의 다중화
- 화재·침수·지진을 고려한 복구 구조
- 재생에너지·물·폐열 회수 설비
- 핵심 질문 · 자체 보유가 곧 복원력을 보장하는가?
카카오 공식 미디어 자료 한국형 선택
공공·금융·의료는 하이브리드 조건이 큼
규제개인정보·전자금융·공공 보안 기준
지연공장·병원·실시간 서비스의 응답 시간
기존 시스템오래된 업무·데이터를 한 번에 옮기기 어려움
AI 인프라GPU 수급·전력·냉각·데이터 주권
현실의 답 · 전부 공용 / 전부 자체가 아니라 업무별 배치
데이터로 읽기
효율 개선과 총수요 증가를 함께 봐야 함
+27%Google 데이터센터 전력 사용 증가 · 2024
−12%데이터센터 에너지 배출 감소 · 2024
1.09Google 공개 평균 PUE
3×5년 전 대비 에너지당 컴퓨팅 성능 · 2025
효율과 공급을 함께칩과 냉각의 효율 개선만으로 충분하지 않음. 재생에너지 조달·전력망 시간대·총사용량까지 같이 봐야 함.
효율이 좋아져도 사용량이 더 빨리 늘면 총전력은 증가
Google Environmental Report 202501발생
수명이 짧은 기기·서버·배터리 증가
02손실
희소 금속과 내재 에너지의 폐기
03위험
비공식 처리 과정의 오염·노동 문제
그린 IT는 전기요금 절감만이 아니라 조달·수명·재사용·폐기 전체
01덜 사기
가상화·공동사용으로 유휴 자원 감소
02오래 쓰기
수리·부품 교체·소프트웨어 지원
03다시 쓰기
업무 등급을 낮춰 재배치
04회수하기
공급자 반납·인증 재활용
05증명하기
자산·데이터 삭제·처리 기록
01업무 중단 1시간의 손실은?
02평균과 최대 수요의 차이는?
03누가 계정과 권한을 승인하는가?
04데이터는 어느 지역에 저장되는가?
05밖으로 옮길 때 비용은?
06공급자 장애 때 우회 경로는?
07비용 급증을 누가 감지하는가?
08계약 종료 뒤 삭제를 어떻게 증명하는가?
업무주말 행사 예약·상점 소개·알림
수요평소 낮음 / 행사 직전 급증
데이터상점 연락처·예약·고객 전화번호
팀 역량개발자 2명 / 서버 운영 전담 없음
산출물 · 서비스 모델 1개 + 배포 방식 1개 + 선택 근거 3개
1. 무어의 법칙은 자연법칙이다.
2. 가상화는 한 물리 서버를 여러 논리 환경처럼 사용하게 한다.
3. SaaS는 이용자가 운영체제 패치를 직접 책임진다.
4. 클라우드 비용은 사용량이 늘면 언제나 자동으로 줄어든다.
5. 복원력은 장애를 막는 일뿐 아니라 빠르게 회복하는 능력도 포함한다.
WEEK 03 · 정리
컴퓨팅은 빨라지고 클라우드는 선택을 바꿈
01빠르고 싼 계산
새 제품·새 시장
02가상화와 오픈소스
자원 공유·표준 생태계
03서비스 모델
편의와 통제의 교환
04관리자 책임
비용·복원력·주권·환경
다음 주
좋은 기업이 신기술에 밀리는 이유
- 파괴적 혁신과 존속적 혁신 구분
- ARM·NVIDIA와 AI 반도체 가치사슬
- 블록체인·가상자산의 실제 쓰임과 한계
WEEK 04파괴적 혁신과 신기술
기술 성능이 아니라 고객·가치망·사업모형이 바뀌는 순간을 분석
15주 흐름 보기 
