첫째 주엔 이 블로그를 AWS EC2 인스턴스 위에 Docker로 구성해 직접 배포했다. 그리고 이번 주엔 AWS Lambda에 웹 크롤링 자동화 코드를 올려보며 서버리스 아키텍처도 직접 실습해봤다. Layer 설정부터 외부 API 호출, 배포, 실행 로그 확인까지 과정을 겪으며 구조를 이해하는 데 큰 도움이 됐다. 이왕 시작한 김에 클라우드 인프라를 전반적으로 이해해보고 싶었고 직접 구성하면서 얻은 인사이트도 적지 않았다.
자연스럽게 예전에 GCP를 간단히 다뤘던 경험도 떠올랐다. 그동안 GCP와 AWS를 둘 다 깊이 써본 건 아니지만 문득 궁금해졌다.
"두 플랫폼의 차이는 무엇일까? 실무에서 GCP가 편하다고 느꼈던 이유는 뭘까? 그런데 내가 들은 강의들은 왜 대부분 AWS를 기준으로 설명하지?"
이 질문들에 답을 찾아보고 싶어 이번엔 블로그 인프라 구축 경험을 정리하며 두 플랫폼을 비교해봤다.
탄탄한 구축 vs 심플한 인상
GCP의 Cloud Run은 Docker 이미지만 있으면 바로 서비스를 띄울 수 있었고 HTTPS 인증도 자동으로 적용됐다. 요청이 없으면 과금도 거의 없었다. 서버리스는 AWS Lambda로도 구현할 수 있지만 GCP는 전체 흐름이 상대적으로 심플했던 인상이 남아 있다.
AWS 환경은 강력하긴 하지만 내가 직접 손보고 설정해야 할 게 더러 있었다. 처음엔 공부가 되고 실전 연습하는 느낌이라 좋았는데 며칠 지나니 이런 질문이 떠올랐다.
"지금 이 구조, 내가 만들고 싶은 서비스의 본질과 얼마나 관련 있을까?"
도구를 다루는 손보다 방향을 결정하는 나침반이 더 중요하다는 생각이 들었다.
AWS와 GCP, 철학부터 다른 듯하다
단순한 기능 차이를 넘어, 두 플랫폼은 사용성과 방향성이 살짝 다른듯하다.
항목 | AWS | GCP |
---|---|---|
기조 철학 | 인프라 제어 중심, 엔터프라이즈 대응 | 데이터 중심, 실험과 통합 지향 |
설계 강점 | 서비스 조합 유연성, 글로벌 리전 | BigQuery, Vertex AI 등 데이터 제품군 |
콘솔 사용감 | 강력하지만 복잡 | 직관적이고 Google 서비스와 연동 쉬움 |
적합한 유형 | 대규모 시스템, 보안 중시 조직 | 빠른 반복 개발, AI/ML 활용 팀 |
요약하자면 AWS는 '큰 시스템을 설계하고 제어하려는' 쪽에 유리하고 GCP는 '빠르게 만들어보고 연결하고 싶은 사람'에게 더 적합하다는 평가가 많다. 내 경험상도 어느 정도 그런 경향이 느껴졌던 것 같다.
왜 강의는 AWS를 중심으로 구성되었을까?
최근 들었던 기술 강의는 대부분 AWS 기반이었다. 예를 들어 웹훅을 구현할 때도 Lambda와 API Gateway를 사용해 수신 구조를 만들었고 Python 패키지 의존성은 Lambda Layer로 구성했다. 전체적으로 체계적이고 명확한 구조 덕분에 서버리스 흐름을 익히기에 좋았다.
아래는 Lambda와 Cloud Functions, 스케줄링 및 배포 방식까지 어떤 경험 차이가 있는지 구조별로 정리한 표이다.
활용 목적 | AWS | GCP |
---|---|---|
서버리스 컴퓨팅 | Lambda + API Gateway | Cloud Functions / Cloud Run |
Webhook 수신 구조 | Lambda + Gateway 필요 | HTTP Trigger 지원 (간단) |
스케줄링 | CloudWatch + EventBridge | Cloud Scheduler (간단 명료) |
자동화 + 저장 | Lambda + S3 + Redshift | Cloud Functions + BigQuery |
구글 시트 연동 | 상대적으로 복잡 | Google API로 바로 연결 가능 |
배포 방식 | 권한 설정, 레이어 등 복잡 | gcloud submit 한 줄 배포 |
AWS는 전 세계 클라우드 시장 1위로 압도적인 점유율을 보이고 있고 특히 국내에서는 약 60%로 가장 많이 채택되는 플랫폼 중 하나다. 그만큼 학습 커뮤니티와 실무자 수가 많아서 다양한 경험이 공유되고, 자료와 튜토리얼이 많아 강의 설계도 수월할 것이다. 또한 콘솔 기반 인프라 구성 흐름이 명확해서 교육용 구조로도 적합해 보인다.
시니어였다면 달리 보였을 차이들
학습 흐름과 구조만 본다면 AWS가 입문자에게 유리한 면이 많다. 하지만 실무에서 더 많은 경험을 쌓은 사람이라면 이 두 플랫폼을 또 다르게 바라보지 않을까, 하는 생각도 들었다.
예를 들어 AWS의 인프라가 세세하게 통제할 수 있다는 점에서 강력하다는 얘기는 구체적으로 어떤 걸까.
- VPC, Security Group, IAM 설정을 통해 네트워크 단위 격리와 리소스 접근 제어까지 가능
- IAM 정책은 특정 시간, IP, 역할, 서비스 단위로 세세하게 권한 분리 가능
- 예: EC2 인스턴스는 특정 S3 버킷의 읽기만 허용, Lambda는 DynamoDB 접근 차단 등
무엇보다 특히 주목했을만한 부분은 조직 운영과 보안 정책 수립의 유연성. AWS의 IAM은 리소스 단위 접근 권한은 물론 시간 조건, 특정 IP 제한, 계정 그룹별 정책 분리까지 매우 세세하게 구성할 수 있다고 한다. 예를 들어 EC2 인스턴스는 특정 S3 버킷의 읽기만 가능하게 하거나 Lambda 함수는 DynamoDB는 못 보게 막는 식으로 말이다.
이처럼 AWS는 정교한 권한 설계, 역할 위임, 조직 전체 거버넌스 대응 측면에서 더 유연하고 강력하다. 시니어 엔지니어나 보안 담당자 입장에서는 이런 점이 실질적인 차이로 다가올 수 있다.
GCP의 IAM도 간편하고 Google 계정 기반의 연동에 분명 강점이 있다. 그러나 복잡한 조직 구조와 다양한 서비스 간 연동까지 통제하려면 AWS의 정책 시스템이 더 유리한 측면이 있다.
아래는 "이 기능은 GCP에선 뭐지?" "이건 AWS에선 뭐로 대응되지?" 헷갈릴 때 참고할 수 있는 핵심 기능 비교표이다.
기능 | AWS | GCP |
---|---|---|
가상 서버 실행 | EC2 | Compute Engine |
파일 저장 | S3 | Cloud Storage |
NoSQL DB | DynamoDB | Firestore / Datastore |
분석 DB | Redshift | BigQuery |
서버리스 함수 | Lambda | Cloud Functions |
컨테이너 서버리스 | Fargate / App Runner | Cloud Run |
도메인(DNS) | Route 53 | Cloud DNS |
권한 관리 | IAM (세분화 가능) | IAM (간편 연동) |
모니터링 / 로그 | CloudWatch | Cloud Logging / Monitoring |
예약 작업 | EventBridge Scheduler | Cloud Scheduler |
CDN | CloudFront | Cloud CDN |
시각화 도구 | QuickSight | Looker Studio |
API 게이트웨이 | API Gateway | API Gateway |
데이터 파이프라인 | Glue / Step Functions | Dataflow / Composer |
마무리하며
GCP와 AWS 모두를 짧게나마 써보고 이렇게 비교해 보면서 각 플랫폼이 어떤 고민에 더 잘 맞는지를 스스로 정리해보고 싶었다.
국내는 여전히 AWS가 주류인듯하고 나 역시 이번 블로그는 AWS 위에서 잘 운영 중이다. 로그, 인증서, 백업, 장애 대응까지 모두 직접 겪어보니 확실히 배운 게 많았다. 반면 빠르게 실험하고 싶은 사람에겐 GCP 쪽이 훨씬 생산적인 선택일 수 있다. 특히 지금 뜨는 서비스들은 하나같이 빠르고 가벼우며 연결 중심이다. 구글 워크스페이스와 친숙한 환경도 큰 장점이 된다.
공부와 실무 연습이 목적이라면 AWS는 훌륭한 실전 도구다. 하지만 반복적으로 실험하고 빠르게 결과를 만들고 싶은 사람에게 필요한 건 조금 다른 기준, 그리고 더 가벼운 흐름일지도 모른다.
내가 만들고 싶은 구조와 실험하고 싶은 방식에 따라 도구는 달라질 수 있다. 그러나 마지막에 방향을 결정하는 건 나 자신. 결국 중요한 건 '무엇을 만들고 싶은가'라는 점을 잊지 말아야겠다.