서비스 기업만들때 매출 발생하는 PMF 찾는 것 다음으로 중요한게 운영 즉 인프라가 아닌가 생각한다.
심도한 이유가 있는데 그것은 바로... 돈이 나가기 때문. 비용 지출지점이기 때문.
IT 기업을 만들때 지출 구조는 결국 인건비 / 마케팅비 / 인프라비이고
내가 기획~개발~디자인~마케팅~데이터분석은 AI 에이드 받아서 어찌저찌한다해도 인프라는 어쩔수없는 고정비용이기때문에
인프라를 잘 이해하고 다룬다는건 사업리스크를 크게 줄일 수 있다는 것이 아닐까
여튼 AWS 쓰다가 GCP 가면서 자꾸 올려놓은 공개키가 사라져서 며칠 애를 먹었는데 썰을 풀어보겠다.
[ 1. AWS, GCP 그리고 Azure ]
2024 기준 AWS 33%, Azure 21%, GCP 11% 점유율 (출처 : Statista)
AWS가 2006년 가장 먼저 클라우드 사업을 시작함. 쇼핑몰 내부에서 쓰고 남는 인프라를 외부에 돌려야겠다는 모티베이션이 있었고 전반적으로 엔지니어보다는 서비스 운영자를 타겟고객으로 한다는 인식을 받음. 기능도 제일 많고, 싸고, 안정적임.
GCP는 태생이 구글인 것 답게 검색 기술을 기반으로 AI·ML·데이터 등에 강점이 있고 쿠버네티스의 표준을 만들어 이끌정도로 기술적으로 강점이 있으나 비지니스 적으로는 좀 약함. 엔지니어들을 대상으로 함.
Azure은 GCP와 같이 2010년 무렵 사업을 시작했고 개인이나 스타트업보다는 대기업·공공·금융 등 엔터프라이즈에 친화되어있으며 Visual Studio 등 MS 제품들과 통합된 것에 강점이 있음.
[ 2. SSH 키 설계로 보는 AWS vs GCP 전략 차이 ]
Azure 는 써본적없고 이번에 GCP 세팅하면서 SSH 키 세팅에서부터 설계 철학이 차이가 난다는 것을 체감.
SSH(Secure Shell) 키는 모두가 알다시피 서버와 클라이언트가 통신하게 해주는 키로 공개키(Public Key)/개인키(Private Key) 구조로 서버에는 공개키를 등록해두고 접속시 클라이언트의 개인키로 인증해 접속을 허용한다.
좀 더 정확히는 클라이언트가 접속요청을 하면 서버가 challenge 를 생성하고 클라이언트가 개인키로 서명하면 서버가 공개키로 검증해서 인증 성공 실패를 결정하는 구조.
AWS에서는 EC2 인스턴스 생성시 서버에 자동주입되고 비밀키는 다운받아서 SSH 접속하는 구조.
GCP에서는 사용자가 직접 공개키/비밀키를 만들고 Metadata 서버에 공개키를 넣어서 관리.
무슨차이가 있느냐.
AWS 는 '쉽고 빨리 쓰는것' 에 집중. 스타트업이나 개인개발자도 5분만에 사용방법만 알면 인스턴스 만들어서 쓸수있도록함. 하지만 이러면 팀 단위 키 관리가 어렵고 SSH 접속자 관리 추적도 어렵게 됨. AWS는 '만드는건 편하게 할테니 이후 관리는 니네가 알아서~' 마인드.
반면 GCP는 SSH 키를 VM(=인스턴스) 내부가 아니라 메타데이터에 저장하고 VM 내에 상주하는 Google Guest Agent 가 메타데이터 서버에 있던 데이터를 읽어와서 authorized_keys 를 주기적으로 생성하는 구조임.
😠 나는 AWS 사고방식대로 VM에 직접 authorized_keys 에 공개키를 넣어서 접근하려고 했는데 자꾸 일정시간 지나면 공개키가 사라지는 것임. 이게 몇 번이고 반복되니까 개빡쳐서 파고들다보니까 구조 철학 자체가 다르구나 깨닫게됨.
GCP 에서는 프로젝트 수준/ 인스턴스 수준/ 브라우저 수준 (웹에서 접근하는) SSH 키가 있는데 프로젝트는 모든 VM에, 인스턴스는 해당 VM에 Override, 브라우저 수준은 콘솔에서 SSH 클릭시 임시로 생성되며 expireOn 만료시간이 있음.
인간이 키 관리하면 실수 발생할 수 있고 VM이 만약 수백 수천대이거나 서버 관리자가 많은 경우를 대비해서 이를 중앙화/자동화하자는 마인드로 Guset Agent 를 VM 에 기본 탑재되어놨고 따라서 개발자가 인스턴스 들어가서 키관리할 수 없음.
결론적으로 개발자가 공개키를 관리하고자 하면 콘솔에서 임시로 들어가거나 혹은 메타데이터에 VM단위 혹은 프로젝트단위로 공개키를 심어놓고 에이전트가 가져가서 반영하는 구조였고 이걸 임의로 들어가서 하면 Agent 가 싹 없애버리는 것이었음.
한마디로 GCP 는 'OS까지 관리할 테니 확장되어도 보안/통제 걱정하지마~' 마인드
한편, GCP 에는 OS Login 이라는 개념도 있는데 로그인을 Google 계정 (IAM) 기준으로 관리한다는 것. 팀/조직 단위 접근 통제와 감사를 쉽게한다는 철학에 부합.
OS Login 을 활성화하면 Google 계정을 VM 사용자 계정으로 매핑해서 authorized_keys 기준이 아닌 Google 계정 기준으로 로그인할 수 있도록 한 것임.
정리하자면 다음과 같다.
┌─────────────────────────────┐
│ 메타데이터 서버 │
│ (프로젝트/인스턴스 설정) │
│ SSH 키, 환경변수, 정책 등 │
└───────────────┬─────────────┘
│
(주기적 pull / 반영)
▼
┌──────────────────────┐
│ Guest Agent │
│ (google-guest-agent) │
└─────────┬────────────┘
│
┌─────────┴───────────┐
▼ ▼
┌───────────────┐ ┌─────────────┐
│authorized_keys│ │ OS Login │
│ (VM 내부) │ │ IAM 기반 SSH │
└───────────────┘ └─────────────┘
│
▼
VM OS
│
(사용자/서비스 실행)
│
▼
애플리케이션
이때 Guest Agent 가 SSH 키나 계정/권한 중심으로 관리하는 주체라면 OS Config 는 VM 상태, 패치, 스크립트 실행, 정책 적용을 하게 되는 선택적 레이어. OS Login 과는 무관하게 항상 동작하나 OS Config 는 Guest Agent 에 의해 실행되거나 관리된다.
AWS 에서도 메타데이터 서버, Guest Agent(SSM Agent)는 존재하지만 필수는 아니며 OS Login 이나 OS Config 는 GCP 에만 있다는게 특징이다 - SSM Agentn 가 OS Conifig 역할을함
💡 한편, 직렬 포트(Serial Port)란 SSH 에 문제가 생겼을때 마지막으로 OS 에 접속할 수 있는 통로
(Azure 는 안써봐서 모르겠음)
'[개발일지] > CS 스터디 플랫폼' 카테고리의 다른 글
| 30장. 왜 요즘은 다 버셀 버셀 할까 (클라우드 인프라 정복기 3) (1) | 2026.01.25 |
|---|---|
| 29장. AWS에서 인스턴스 삭제 협박을 받다 (클라우드 인프라 정복기 2) (1) | 2026.01.23 |
| 27장. 목록 정렬 Sorting 을 어디서 해야하는고 (0) | 2026.01.22 |
| 26장. 스프링 시큐리티 그리고 권한 설계에 대한 고찰 (0) | 2025.10.17 |
| 25장. 이미지를 왜 inputStream 으로 받아요. 제발 formData 쓰게 해주세요 (MIME 타입의 역사) (2) | 2025.07.07 |