IaaS, PaaS, SaaS를 직접 실습하며 책임 경계를 정리해본 기록

클라우드 수업 초반에 IaaS, PaaS, SaaS를 배웠다. 정의는 어렵지 않았다. 문제는 실제 설계할 때였다. “이 서비스는 내가 어디까지 책임지는 거지?” 멀티 AZ(가용영역 다중화) 웹 서비스를 직접 구성하면서 이 질문에 제대로 답하지 못해 몇 번 설계를 다시 했다. 이번 글은 개념 설명이 아니라, 직접 실습하면서 책임 경계를 정리한 기록이다.

 

1) IaaS 실습 — 내가 운영체제를 책임질 때

실습 환경(구체 설정값)

• VPC CIDR: 10.0.0.0/16
• Public Subnet: 10.0.1.0/24
• Private Subnet: 10.0.2.0/24
• EC2 AMI: Amazon Linux 2
• 인스턴스 타입: t3.micro
• 보안그룹(SG, Security Group=가상 방화벽)
  • 인바운드 80(HTTP): 0.0.0.0/0 허용
  • 인바운드 22(SSH): 내 IP만 허용

EC2를 생성하고 Apache/ PHP를 직접 설치했다. 이 순간부터 운영체제 패치(OS patch), 서비스 프로세스 상태, 로그 확인, 보안 설정까지 전부 내 책임이 된다.

sudo yum update -y
sudo yum install httpd php mysql -y
sudo systemctl enable httpd
sudo systemctl start httpd

ALB(Application Load Balancer=애플리케이션 로드밸런서)를 붙이고 브라우저로 접속했는데, 첫 화면이 기대와 달랐다.

실제 오류 메시지(원문)

502 Bad Gateway

당시에는 “네트워크가 문제인가?”부터 의심했는데, 정작 원인은 애플리케이션 파일이 없거나 웹서버가 정상 동작하지 않는 케이스였다. 결국 타겟 그룹 헬스체크 대상 경로가 기대하는 엔드포인트(예: / 또는 /health)에서 200을 못 내고 있었다.

확인해보니 /var/www/html/index.php가 존재하지 않거나 권한/서비스 상태가 맞지 않았다. 여기서 처음으로 “책임 경계”가 감각적으로 들어왔다.

내가 내린 판단

IaaS(인프라형)는 자유도 대신 책임이 크다. “접속이 안 된다”는 문제를 클라우드 탓으로 돌리기 전에, 내가 관리해야 할 레이어(OS/웹서버/파일/권한/로그)을 먼저 본다.

2) PaaS 실습 — Aurora를 붙이면서 경계가 달라졌다

같은 구조에서 DB를 EC2에 직접 설치하지 않고, Aurora MySQL(Multi-AZ=다중 가용영역)로 변경했다. 이 순간부터 DB 엔진 패치, 장애 조치(Failover=장애 시 자동 전환), 백업 일부가 관리형으로 넘어간다.

설정 값(구체 값)

• Engine: Aurora MySQL 8.0
• DB Subnet Group: Private Subnet 2개(서로 다른 AZ)
• Multi-AZ: 활성화
• DB 인스턴스 클래스: db.t3.medium
• Public access(퍼블릭 접근): 비활성화

EC2에서 DB 접속 테스트를 했는데 바로 터졌다.

mysql -h aurora-endpoint -u admin -p

실제 오류 메시지(원문)

ERROR 2003 (HY000): Can't connect to MySQL server

이 오류는 “DB가 죽었다”가 아니라, 네트워크/보안그룹/라우팅/DNS/엔드포인트 등 연결 경로가 막혔을 때도 동일하게 뜬다.

원인은 보안그룹이었다. Aurora 보안그룹 인바운드에서 EC2 보안그룹(또는 EC2의 프라이빗 IP 대역)을 MySQL 포트로 허용하지 않았다.

내가 내린 판단

PaaS(플랫폼형)는 “운영 부담”을 줄여주지만, “구조 설계 책임”까지 없애주진 않는다. 특히 멀티클라우드로 가면 이 연결 경로(네트워크/보안/인증/접근제어)가 복잡해지니, PaaS를 쓴다고 해서 네트워크 문제를 덜 보게 되는 건 아니었다.

참고로 이 단계에서 “DB 패치/백업/Failover”는 클라우드가 대부분 책임진다. 하지만 접근 통제(보안그룹/서브넷 배치), 계정/권한, 애플리케이션 연결 설정은 여전히 사용자 영역이다.

3) SaaS — 운영 책임이 거의 없을 때의 체감

협업 문서 관리를 위해 SaaS(소프트웨어형) 기반 협업 도구를 쓰기 시작했다. 서버 설치도 없고, OS 업데이트도 없고, 서비스 프로세스 확인도 없다. 관리자 화면에서 하는 일은 대부분 계정/권한/정책 설정이다.

• 사용자 계정 생성 및 역할(Role=역할) 부여
• 접근 권한(ACL=접근제어목록) 설정
• 데이터 다운로드/공유 정책 설정

내가 내린 판단

SaaS는 운영 책임이 거의 없는 대신, 통제권이 제한된다. 네트워크 레벨 튜닝이나 배포 구조를 내 마음대로 바꾸는 게 아니라, 제공자가 정한 범위 안에서 정책을 설계하는 쪽에 가깝다.

4) 멀티클라우드에서 3가지를 섞어보며 깨달은 것

실습 구조는 아래처럼 정리됐다(실습 기준으로 “조합”이 어떻게 생기는지 보이도록).

• Web: EC2 (IaaS)
• DB: Aurora (PaaS)
• 협업/관리 업무: SaaS
• 정적 장애 페이지: S3 Static Hosting(정적 웹 호스팅)

이 조합에서 제일 헷갈렸던 건 장애 대응 책임이었다. EC2는 ASG(Auto Scaling Group=오토스케일링 그룹)가 교체할 수 있지만, 내가 애플리케이션 상태를 보장하지 못하면 헬스체크에서 계속 떨어진다. Aurora는 장애 조치가 자동이지만, 연결 경로는 내가 설계해야 한다. SaaS는 장애가 나면 내가 할 수 있는 게 제한적이다(대신 운영 부담도 없다).

체감 정리

“책임 경계”는 책에서 외울 때보다, 장애가 났을 때 훨씬 선명해졌다. 같은 ‘접속 실패’라도, IaaS/PaaS/SaaS에서 내가 확인해야 하는 지점이 다르다.

5) 책임 경계 기준으로 다시 정리(표)

항목	IaaS(인프라형)	PaaS(플랫폼형)	SaaS(소프트웨어형)
OS 관리	사용자	클라우드	클라우드
DB 패치	사용자(직접 설치 시)	클라우드	클라우드
네트워크 설계	사용자	사용자(접근 경로/보안그룹 등)	제한적(정책 수준)
애플리케이션 배포	사용자	사용자(코드/설정 중심)	불가(사용만)
확장 자동화	직접 구성(ASG/스케일링 정책)	기본 제공/옵션 제공	제공(사용자는 정책만)

6) 내가 내린 설계 의사결정(실습 기준)

처음에는 “직접 구축 = 실력”이라고 생각했다. 그런데 운영 관점으로 내려오면 기준이 달라졌다.

1. 핵심 데이터 영역은 PaaS로
   DB를 IaaS로 직접 운영하면 패치/백업/장애조치까지 실수 여지가 너무 크다. 그래서 Aurora를 선택했다(운영 리스크 감소).
2. 통제력과 학습 목적이 필요한 영역은 IaaS 유지
   네트워크/보안/서버 레벨 트러블슈팅을 체득하려고 EC2를 유지했다.
3. 차별화가 필요 없는 영역은 SaaS로
   협업/문서/일정은 “내가 운영해서 얻는 이득”이 거의 없어서 SaaS로 처리했다.

한 줄 결론

멀티클라우드에서 설계 역량은 “무엇을 더 많이 아느냐”보다 “무엇을 내가 책임지고, 무엇을 넘길지”를 잘 결정하는 능력에 가까웠다.

7) 결론 — 암기가 아니라 설계 기준이 되어야 한다

IaaS, PaaS, SaaS는 시험용 정의가 아니다. 장애가 발생했을 때 누가 책임지는가를 구분하는 기준이다. 이번 실습에서 내가 겪은 오류 두 가지가 그 책임 경계를 가장 빠르게 보여줬다.

• 502 Bad Gateway → IaaS에서 내가 관리해야 할 레이어(웹서버/파일/권한/프로세스) 문제로 이어짐
• ERROR 2003 (HY000): Can't connect to MySQL server → PaaS라도 연결 경로(보안그룹/서브넷/라우팅)는 사용자 책임

클라우드를 배운다는 건 서비스를 외우는 게 아니라, 책임 구조를 설계하는 능력을 키우는 과정이라는 걸 이번 실습으로 정리했다.