🔥 이 101편을 어떻게 읽어야 할까
강의 목차
주말에 AWS 콘솔의 '서비스' 메뉴를 눌렀다가 270개가 넘는 목록을 봤다. 실제로 일할 때 자주 쓰는 건 열 개 남짓인데, 왜 이렇게 많은 거지 싶었다.
물론 저 서비스들이 다 쓸모없는 건 아니다. 게임 개발자, 머신러닝 엔지니어, IoT 팀, 미디어 스트리밍 팀. 각자가 "이 서비스 없으면 일 안 돼요"라고 주장하는 서비스가 하나씩 있을 거다. 하지만 웹 서비스나 데이터 파이프라인, 사내 도구 같은 평범한 맥락에서 처음 붙잡아야 할 서비스는 놀라울 정도로 좁다. 그래서 나는 먼저 16개만 골랐다.
나는 이 16개로 AWS 지도를 만든다.
왜 16개인가
입문 자료를 만들 때 가장 흔한 실수는 서비스 이름을 전부 한 줄씩 훑는 데 있다. 그러면 설명만 늘고 독자는 중심을 놓친다. 반대로 EC2만 깊게 파면 EC2 옆에 붙는 IAM, VPC, CloudWatch를 함께 못 본다.
내가 16개로 자른 기준은 이렇다.
- 거의 모든 AWS 프로젝트에서 최소 한 번은 손으로 만지게 되는 서비스
- 다른 서비스의 '전제'로 등장하는 서비스(IAM 없이는 무엇도 없다)
- 이웃 서비스와의 경계가 흐리면 사고가 나는 서비스
예를 들어 SageMaker나 QuickSight, AppSync 같은 건 훌륭하지만 이 목록에는 넣지 않았다. 앞의 16개를 먼저 익히고 나면 그런 서비스는 공식 문서만으로도 방향을 잡을 수 있어야 한다.
왜 실습 없이 개념으로
서울 리전(ap-northeast-2) 기준으로 실습을 돌리면 생각보다 돈이 나간다. NAT Gateway 하나가 한 달에 몇만 원이고, 깜빡 잊은 RDS 인스턴스는 조용히 계좌를 긁는다. 입문 단계에서 가장 자주 터지는 실수도 이거다.
그래서 먼저 개념으로 읽는다. 서비스가 무엇인지, 어디에 붙는지, 언제 피해야 하는지만 남긴다. 콘솔 클릭 스크린샷은 최소화한다. 실습은 나중에 이 지도 위에 얹으면 된다.
매 섹션에서 나는 네 가지 질문을 반복해서 묻는다.
- '관리형'이라는 단어가 어떤 비용을 감추고 있는가
- 이 서비스를 언제 쓰지 말아야 하는가
- 이웃 서비스와의 경계는 어디인가
- 서울 리전에서 이 서비스의 현실(가용영역·지연·가격)은 어떤가
읽는 순서: Foundation → Core → Messaging → Utility
섹션 번호가 1부터 16인 데는 이유가 있다. 네 개의 계층으로 묶어둔 순서다.
| 계층 | 섹션 | 내용 | 편수 |
|---|---|---|---|
| Foundation | 1~3 | IAM · VPC · CloudWatch | 30 |
| Core | 4~8 | EC2 · Lambda · S3 · RDS · DynamoDB | 38 |
| Messaging | 9~12 | SQS · SNS · Kinesis · EventBridge | 20 |
| Utility | 13~16 | Route53 · CloudFront · API Gateway · Secrets Manager | 12 |
Foundation 30편이 제일 길다. 일부러 그렇게 잡았다. IAM, VPC, 관측을 헷갈리면 뒤의 Core와 Messaging에서도 같은 혼선이 계속 나온다. IAM, VPC, 관측을 먼저 잡으면 Core는 그 위에 어떤 서비스가 올라가는지만 보면 된다. 그러면 읽는 속도도 바로 붙는다.
순서대로 읽는 편을 권하지만, 급하면 Foundation을 먼저 끝내고 필요한 Core와 Messaging만 골라 읽어도 된다. Utility 섹션은 Core 이후 언제 읽어도 상관없다.
서비스 지도: 누가 누구 위에 앉아 있는가
한 서비스는 절대 혼자 서지 않는다. 어느 서비스가 어느 서비스를 전제로 동작하는지 감만 잡으면 개별 문서도 한결 빠르게 읽는다.
| 서비스 | 기본적으로 기대는 서비스 |
|---|---|
| EC2 · Lambda · RDS · DynamoDB | IAM(실행 권한), CloudWatch(로그·메트릭) |
| EC2 · RDS · VPC 연결된 Lambda | VPC(네트워크 경계) |
| Lambda | S3 · SQS · SNS · EventBridge · API Gateway(트리거 경로) |
| API Gateway · CloudFront | Route53(도메인), IAM(인증) |
| S3 | IAM과 KMS(접근 제어와 암호화) |
| 전 서비스 | Secrets Manager(자격증명·API 키) |
이 표는 각 섹션 첫 글에서 다시 꺼낸다. 뒤로 갈수록 표에 적는 관계도 더 구체적으로 적는다. 지금은 IAM, VPC, CloudWatch가 다른 서비스의 바닥 역할을 한다는 점만 기억하면 된다.
한 편은 어떻게 생겼나
한 편마다 이런 조각들을 묶는다.
- 무엇인가: 한두 문단짜리 개념 정의. 공식 문서의 한 줄 정의를 내 말로 다시 쓴 버전이다.
- 언제 쓰는가 / 언제 쓰지 말아야 하는가: 이 짝은 매 섹션마다 반드시 등장한다.
- 이웃 서비스와의 경계: 이 서비스가 멈췄을 때 옆에서 무엇이 같이 멈추는가.
- 다이어그램: 관계·흐름·상태 전이 중 하나. 한 편에 최대 네 개까지.
- 관리형이 감추는 비용: 화면상 보이지 않는 돈이 어디서 나가는지.
일부러 코드 블록은 넣지 않았다. 필요한 순간이 오면 AWS 공식 Developer Guide에서 바로 가져다 쓰면 된다.
이걸 다 읽고 나면
주말에 눌렀던 그 '서비스' 메뉴를 다시 열면, 270개 중 절반쯤은 "아, 얘는 내가 지금 쓰는 저 서비스의 관리형 버전이구나" 혹은 "얘는 다른 클라우드에서 말하는 Y의 AWS 버전이구나"처럼 위치가 잡힐 거라고 생각한다. 나머지 절반은 여전히 낯설 수 있다.
그래도 지금은 16개만 먼저 잡으면 된다. 출발점은 IAM이다.
참고 자료
- AWS 공식 Documentation: 서비스별 Developer Guide를 1차 레퍼런스로 삼는다
- AWS Regional Services List: 서울 리전(ap-northeast-2)에서 무엇이 쓸 수 있는지 확인용
- AWS Well-Architected Framework: 서비스를 조합해 쓰는 관점을 처음 잡을 때 도움이 된다
YouTube 영상
