[클라우드 엔지니어 97] 1장 클라우드란 무엇인가?

※ 책 내용을 바탕으로 제 관점에서 풀어쓴 글입니다. 일부 내용이 다를 수 있습니다.

 

“클라우드는 그저 남의 컴퓨터?”

한 마디로 정리하면 Nope.

1장 Nathen Harvey의 조언 “What Is the Cloud?” 는 클라우드를 다섯 가지 속성으로 정의한다.

• On-Demand Self-Service
  카드 한 장 등록 → 몇 분 만에 VM·DB·LB 완성.
• Broad Network Access
  노트북, 폰, CI/CD 파이프라인… API 한 번이면 OK.
• Resource Pooling
  수백·수천 대 서버를 하나의 거대 풀로 “물아일체”.
• Rapid Elasticity
  트래픽이 미쳐 날뛴다? 10초 만에 오토스케일링.
• Measured Service
  쓰는 만큼만 결제. 월말 고지서가 곧 사용 리포트.

 

"데이터센터를 하드웨어 이슈가 아닌 소프트웨어 문제로 바꿔 버린다."

 

 

개발자에게 왜 중요한가?

1장은 "클라우드를 알아야 개발 주도권이 생긴다"는 메시지를 던진다.

 

과거엔 인프라팀 티켓을 끊고 며칠을 기다려야 VM 한 대 받을 수 있었지만,

이제는 개발자가 직접 IaC(Terraform, CloudFormation 등) 스크립트로 인프라를 코드처럼 버전 관리하고,

PR 하나로 배포 승인을 받을 수 있다.

 

[ Terraform으로 S3 정적 웹 호스팅 생성 ]

resource "aws_s3_bucket" "blog" {
  bucket = "my-tech-blog"
  website {
    index_document = "index.html"
    error_document = "404.html"
  }
}

디렉터리를 GitHub에 푸시 → Action로 terrafrom plan/apply → 즉시 배포.

"아이디어 → 코드 → 가동"이 한 사이클 안에 들어온다.

 

 

흔한 오해 3가지 그리고 반박

오해	1장에서 던지는 반박
"클라우드는 싸다."	'맞춤형'으로 써야 싸다. 24/7 켜두는 대형 인스턴스는 온프렘보다 더 비쌀 수 있다.
"보안은 벤더 책임이지."	공유 책임 모델을 이해 못 하면 사고 남. 벤더는 '물리 및 하이퍼바이저'까지만, 그 위 OS 및 데이터는 우리 몫.
"마이그레이션 = 리프트-앤-시프트."	그대로 옮기면 VM 렌탈업체로 끝. 리호스트 → 리팩터 → 리플랫폼 단계별 전략이 필요.

 

 

실무 팁 5선 - '첫걸음' 체크 리스트

• 계정 거버넌스부터 잡자
  AWS OU, Azure MCA 같은 조직 구조 설계 → 프로젝트별 IAM 경계 명확화.
• 태그 정책을 코드로 관리
  tag:<Key>=<Value>가 비용·보안·모니터링 관통. 본격 리소스 폭증 전에 표준화할 것.
• 관리형 서비스 우선
  “먼저 Run, Don’t Build” – 책도 4번째 조언에서 ‘Use Managed Services—Please’라 강조한다.
• SLO/모니터링을 인프라와 함께 배포
  CloudWatch Alarm·Azure Monitor 템플릿을 IaC에 포함해 ‘알람 없는 배포’를 방지.
• 비용 가드레일 설정
  AWS Budgets·Azure Cost Alerts로 일일/월간 한도 초과 시 Slack 알림.

 

 

'전기 플러그'에서 배우는 교훈

1장은 클라우드를 전기 같은 유틸리티에 비유한다.

 

우리는 집을 지을 때 발전소부터 짓지 않는다.

플러그만 꽂으면 끝.

 

마찬가지로, 클라우드 시대 엔지니어는

서버를 조립하는 대신 비즈니스 로직에 집중해야 한다.

 

즉, 코드를 작성하고 고객 문제를 해결하는 데 시간을 써야 한다는 것이다.

 

 

마무리

프로그램이 잘 돌아가는 데서 멈추지 말고,

변화에 강한 설계를 고민해야 한다는 점은

객체지향이든 클라우드든 같다.

 

클라우드 역시

"자원(객체)이 스스로 탄력 확장 및 복구(행동)하도록 만든 인프라"라고 생각하면,

1장의 메시지가 훨씬 와닿을 것이다.