클라우드, 왜 이렇게 배우기 어려울까

들어가며: "공부했는데 왜 아무것도 못 만들겠지?"

클라우드 공부를 시작한 사람이라면 한 번쯤 이런 경험을 해봤을 겁니다.

저는 공부량의 문제보단, 클라우드 아키텍처를 배우는 방식 자체에 구조적인 문제가 있기 이라고 생각합니다.

이 글에서는 클라우드 기술이 왜 배우기 어려운지, 철저하게 개인적인 경험과 생각을 기반으로 핵심 이유를 깊이 파고들어 분석합니다. 단순히 "어렵다"는 얘기를 하려는 게 아닙니다. 이 구조적 문제를 정확히 이해해야, 지금보다 훨씬 효율적인 학습 방법을 찾을 수 있을 것이라고 생각하기 때문입니다.

이유 1: 배우는 방법이 여전히 과거에 머물러 있다

소프트웨어 개발에는 있고, 클라우드 학습엔 없는 것

일반적인 소프트웨어 개발 학습과정을 떠올려 보겠습니다. Python으로 코드를 작성하면 어떤 일이 일어나나요?

1# 잘못된 코드 작성
2def add(a, b)
3    return a + b
Copy

1File "main.py", line 1
2    def add(a, b)
3                ^
4SyntaxError: expected ':'
Copy

에러가 즉각적으로 나타납니다. 코드가 컴파일되지 않거나 실행되자마자 어디가 틀렸는지 정확히 알려줍니다. 개발자는 이 피드백을 수십, 수백 번 반복하면서 실력이 늘어납니다. "틀리고 → 고치고 → 다시 시도"하는 사이클이 빠르고 명확합니다.

이제 클라우드 아키텍처 학습 상황을 보겠습니다.

1📋 내가 설계한 아키텍처:
2Internet → ALB → EC2 (Public Subnet) → RDS (Public Subnet)
3
4❓ 이 설계가 맞나요?
5- 보안 이슈가 있나요?
6- 오버스펙은 아닌가요?
7- 실무에서 실제로 이렇게 하나요?
Copy

아무런 피드백이 없습니다. 잘못 설계했더라도 틀렸다고 알려주는 도구가 없고, 맞는다는 확인도 받을 수 없습니다. 일단 배포해보고 문제가 생겨야 — 그것도 운영 중에 — 비로소 "아, 이게 잘못됐구나"를 알게 됩니다.

소프트웨어 개발에는 컴파일러, 린터(Linter: 코드 스타일 및 오류를 정적으로 분석하는 도구), 단위 테스트, IDE의 실시간 오류 표시가 있습니다. 클라우드 아키텍처에는 이에 해당하는 학습용 피드백 도구가 사실상 없습니다.

실습의 문턱이 너무 높다

프로그래밍을 배울 때는 로컬 컴퓨터에서 바로 실행해볼 수 있습니다. Python을 배우고 싶다면 python main.py 한 줄로 즉시 실행되고, 결과가 터미널에 나타납니다. Docker를 배우고 싶다면 컨테이너를 띄워보면 됩니다. 비용은 0원이고, 환경 설정도 튜토리얼을 따라하면 금방 끝납니다.

클라우드 실습은 다릅니다. 예를 들어 수영을 배우는데 수영장에 들어갈 때마다 입장료가 발생하고, 잘못 수영하면 벌금이 청구되며, 연습이 끝나면 수영장을 직접 청소해야 한다고 상상해보세요. 이 환경에서 수영을 편하게 배울 수 있을까요?
클라우드도 비슷하다고 생각합니다.

1VPC 설계 실습을 하려면:
21. AWS 계정 생성 (신용카드 필요)
32. VPC, Subnet, Internet Gateway, Route Table 생성
43. EC2 인스턴스 배포
54. 보안 그룹 설정
65. 로드밸런서 추가
76. ... 실습 끝나면 전부 삭제해야 비용 안 나감
87. 삭제를 빠뜨리면? 매달 요금이 청구됨
9
10예상 비용: 1~5만원 / 실습 세션
Copy

잘못 설정하면 돈이 나가고, 실습이 끝나면 직접 다 삭제해야 합니다. 삭제를 빠뜨리면 잊어버린 리소스 때문에 청구서가 날아옵니다. 이 심리적, 경제적 장벽이 "일단 해보자"는 학습 태도를 막습니다.

피드백 루프의 속도 차이

소프트웨어 개발과 클라우드 아키텍처 학습의 가장 근본적인 차이는 피드백 루프(Feedback Loop: 내 행동에 대한 결과가 돌아오는 속도와 명확성)의 속도라고 생각합니다.

1소프트웨어 개발 피드백 루프:
2코드 작성 → 즉시 에러 확인 (수 초)
3         → 단위 테스트 실행 (수 초~분)
4         → 코드 리뷰 (수 시간)
5
6클라우드 아키텍처 피드백 루프:
7설계 → 배포 (수십 분) → 장애 발생 (수 일~수 주 후)
8    → 비용 청구 (한 달 후)
9    → 보안 감사 (수 개월 후)
10    → 성능 문제 (트래픽 증가 후)
Copy

소프트웨어 디버깅은 수 초 안에 알 수 있지만, 클라우드 리소스들은 빠르면 몇 분, 늦으면 몇 주 혹은 몇 달 후에야 그 결과가 나타납니다. 심지어 이미 운영 중인 서비스인 경우엔 피해를 비즈니스에 피해를 입거나, 예상치 못한 요금이 청구된 후입니다.

이유 2: 알아야 할 지식의 범위가 너무 방대하다

"선택"이 아니라 "판단"이 필요하다

클라우드 아키텍처 학습의 두 번째 핵심 어려움은 기술 지식 자체의 방대함이 아닙니다. 수백 가지 선택지 중에서 컨텍스트(혹은 비즈니스 요구사항)에 맞는 올바른 것을 "판단"하는 능력이 필요하다는 것입니다.

예를 들어, EC2 인스턴스에 운영체제를 선택해야 한다고 가정해봅시다.

공식 문서를 찾아보면 각각의 특징이 나열되어 있습니다. 하지만 문서를 읽어도 "내 서비스에는 어떤 OS가 맞는가" 라는 질문에는 쉽게 답하기 어렵습니다.

실무에서 이 판단을 하려면 아래와 같은 지식이 필요합니다:

최종 판단을 위해서는 Linux 패키지 관리 체계, 각 배포판의 라이프사이클 정책, 기업별 지원 정책에 대한 이해가 필요합니다. 이것 하나만 해도 수십 시간의 학습이 필요한데, 클라우드 아키텍처를 설계할 때 이런 판단이 필요한 지점이 수십 군데가 있습니다.

내가 설계한 아키텍처가 맞는지 알기 어렵다

클라우드 학습의 가장 현실적인 어려움 중 하나입니다. 가상의 시나리오로 아키텍처를 직접 설계해봤다고 합시다.

1시나리오: "월 10만 명의 사용자가 사용하는 커머스 웹사이트"
2
3내가 설계한 아키텍처:
4Internet
5  ↓
6CloudFront (CDN)
7  ↓
8ALB (Application Load Balancer)
9  ↓
10EC2 Auto Scaling Group (Web/App, t3.large × 3~10대)
11  ↓
12RDS Aurora MySQL (Multi-AZ, db.r6g.2xlarge)
13  ↓
14ElastiCache Redis (캐싱)
Copy

이 설계에 대해 스스로 판단하기 어려운 것들은 다음과 같다고 생각합니다.

1. 오버스펙 여부: t3.large가 적절한가, t3.medium이면 충분한가? db.r6g.2xlarge가 맞는가? 월 10만 명 기준 예상 동시 접속자는 몇 명이고, 그게 인스턴스 스펙에 어떻게 연결되는가?

2. 보안 이슈: RDS가 Private Subnet에 있어야 하는데 그 부분을 명시하지 않았다. 보안 그룹 규칙은? NAT Gateway 설정은? WAF(Web Application Firewall)는 필요한가?

3. 비용 추정: 이 아키텍처를 한 달 운영하면 얼마가 나올까? AWS Pricing Calculator로 계산할 수 있지만, 어느 항목이 지배적인지, 어디서 최적화할 수 있는지는 경험 없이 알기 어렵습니다.

4. 표준 준수: AWS Well-Architected Framework의 6가지 원칙을 이 설계가 충족하는가? 보안 원칙, 신뢰성 원칙에 비춰봤을 때 어떤 항목이 빠져 있는가?

소프트웨어 코드라면 코드 리뷰, 린터, 테스트로 즉각 피드백을 받을 수 있습니다. 하지만 아키텍처 다이어그램을 누군가에게 보여주지 않으면 이 중 어떤 것도 알 수 없습니다. 그리고 함께 리뷰해줄 경험 있는 동료나 멘토가 없다면, 학습자는 그냥 "이게 맞겠지"라고 가정한 채 넘어가게 됩니다.

이유 3: 추상화 레이어의 역설 — 쉬워졌는데 더 어렵다

클라우드는 물리 인프라의 복잡성을 추상화한 기술입니다. 서버 하드웨어를 직접 구매하거나, 네트워크 케이블을 직접 연결할 필요가 없습니다. 클릭 몇 번으로 글로벌 인프라를 배포할 수 있습니다.

그런데 이 편리함이 역설적으로 학습을 어렵게 만드는 면이 있다고 생각합니다.

"보이지 않으면 이해하기 어렵다"

온프레미스 환경에서는 네트워크 스위치를 직접 만지고, 서버를 직접 랙에 꽂으면서 인프라를 몸으로 배웁니다. VPC가 왜 필요한지, Subnet이 왜 나뉘는지, 라우팅 테이블이 왜 있는지를 "보면서" 이해하게 됩니다.

클라우드에서는 이 모든 것이 소프트웨어로 추상화되어 있습니다. VPC를 만들어도 물리적으로 보이는 게 없습니다. Subnet을 나눠도 뭔가 바뀐 느낌이 없습니다. 눈에 보이지 않는 개념을 배워야 하는데, 눈에 보이지 않으니까 더 어렵습니다.

AWS 서비스가 300개가 넘는다

AWS 서비스만 해도 현재 300개가 넘습니다. 각 서비스에는 수십 개의 설정 옵션이 있습니다. 모든 것을 알 필요는 없지만, 최소한의 판단을 위해 알아야 하는 서비스가 이미 수십 개에 달합니다.

각각을 독립적으로 공부할 수 있지만, 이것들이 어떻게 서로 연결되어야 하는가는 공부만으로 배우기 어렵습니다. 서비스 간의 관계, 제약사항, 비용 구조를 통합적으로 이해하는 것은 결국 실무 경험에서만 얻어집니다.

마무리: 어렵다는 걸 인정하되, 왜 어려운지 알아야 한다

클라우드 아키텍처 학습이 어려운 이유를 정리합니다:

피드백 부재: 소프트웨어 개발과 달리, 설계 단계에서 즉각적인 오류 피드백을 주는 도구가 없다. AWS Well-Architected Tool 같은 도구가 존재하지만 이는 사후 검토 도구이며, 설계 과정의 실시간 피드백 서비스는 아직 없다.

높은 실습 문턱: 비용과 환경 복잡성으로 인해 "일단 해보는" 실습이 소프트웨어 대비 훨씬 어렵다. LocalStack 같은 에뮬레이터가 대안이 될 수 있다.

판단 지식의 방대함: ALB/NLB 선택처럼, 단순 암기가 아닌 OSI 모델 같은 기반 지식에서 출발한 "판단력"이 필요하다. 이 판단력은 레퍼런스 아키텍처 분석과 장애 사례 공부로 체계적으로 기를 수 있다.

추상화의 역설: 클라우드는 인프라를 추상화해서 편하게 만들었지만, 그 추상화 덕분에 물리적으로 보이지 않는 개념들을 이해하기 더 어려워졌다.

클라우드 아키텍처가 어렵다는 건 지식 부족보다는 구조적으로 배우기 어렵게 되어 있는 영역인 것 같습니다. 다만 그 이유를 정확히 알고 있다면, 지금보다 훨씬 효율적인 학습 경로를 설계할 수 있을 것이라고 생각합니다.