VPC, ALB, RDS, IAM. AWS는 약어가 많아 처음에는 진입 장벽이 높게 느껴집니다. 그럼에도 불구하고 현장에서는 기존 구성을 읽고 이해해야 하는 상황이 금방 찾아옵니다.
지식이 전무해도 괜찮습니다. AI를 가정교사 삼아 구성에 대해 '설명하게' 만드는 것부터 시작해 봅시다.
설명을 위해 흔히 볼 수 있는 웹 시스템의 구성 예시를 들겠습니다.
- 도메인 이름 해결은 Route 53을 사용합니다.
- 이미지는 CloudFront와 S3에서 전송됩니다.
- 애플리케이션으로의 요청은 ALB(로드 밸런서)가 받습니다.
- 애플리케이션은 ECS(Fargate)에서 컨테이너 2개를 구동하고 있습니다.
- 데이터베이스는 RDS(PostgreSQL)를 사용하며, 프라이빗 서브넷에 배치되어 있습니다.
이 모든 것을 이해한 후에 업무를 시작하는 것은 힘든 일입니다. 순서대로 AI에게 질문해 봅시다.
AI에게 학습시킬 자료는 다음 중 어떤 것이든 괜찮습니다.
- CloudFormation, Terraform, CDK와 같은 코드
- 구성도 이미지
- 위와 같은 목록 형태의 개조식 설명
가장 추천하는 것은 코드가 있는 경우입니다. 설정의 세부적인 부분까지 정확하게 전달받을 수 있습니다. 코드가 없다면, 구성도나 목록으로 충분합니다.
그 위에 다음과 같이 질문합니다.
'이 구성을 AWS 초보자 눈높이에 맞춰, 사용자 요청이 흐르는 순서대로 설명해 주세요. 전문 용어가 나오면 한마디 의미를 덧붙여 주세요.'
'흐름 순서로'라는 점을 추가하는 것이 핵심입니다. 서비스 목록으로 이해하는 것이 아니라, 연결 고리(연속성)로서 이해할 수 있습니다.
위 예시의 경우, AI는 대략 다음과 같은 흐름으로 설명해 줄 것입니다. 사용자가 URL을 열면, 먼저 Route 53이 주소를 알려줍니다. 이미지는 CloudFront가 가까운 서버에서 빠르게 반환합니다. 화면 처리는 ALB가 받아 여유 있는 컨테이너로 분배합니다. 컨테이너가 데이터베이스에 읽기/쓰기를 합니다. 이런 흐름으로 질문하면 각 서비스의 역할이 자연스럽게 머릿속에 들어옵니다.
설명을 들었다면, 다음은 이유를 파고듭니다. 사용할 수 있는 질문 유형은 다음 3가지입니다.
'왜' 유형
RDS를 프라이빗 서브넷에 배치한 이유는 무엇인가요?
'만약 없다면' 유형
만약 ALB가 없었다면, 어떤 어려움이 있나요?
'어디가 고장나면' 유형
컨테이너 1개가 중단되면 사용자에게는 어떻게 보이나요? 데이터베이스가 중단되면 어떨까요?
'만약 이것이 없다면'이라고 질문하면, 각 서비스의 역할이 한 번에 명확해집니다. '어디가 고장나면'이라고 질문하면, 해당 구성이 어떤 장애에 강한지, 약한지가 파악됩니다.
모르는 단어가 나오면 그 자리에서 다시 물어보면 됩니다.
이해가 진전되면, 다른 방식으로 비교하게 합니다.
'이 구성을 Lambda와 API Gateway로 조합하면 어떻게 달라질까요? 비용, 운영 노력, 확장 용이성 측면으로 비교하여 표로 만들어 주세요.'
비교를 반복하다 보면 '무엇을 기준으로 구성을 선택할지'라는 설계 판단 기준(판단축)이 몸에 배게 됩니다.
익숙해지면 AWS Well-Architected Framework 관점에서 리뷰를 요청하는 것도 추천합니다.
'이 구성을 AWS Well-Architected Framework의 관점에서 검토해 주세요. 개선점이 있다면, 영향도가 큰 순서대로 3가지를 제시해 주세요.'
마지막으로, 이해한 내용을 Markdown 메모로 정리하게 합니다.
'지금까지의 설명을 바탕으로 이 구성에 대한 해설 메모를 Markdown 형식으로 작성해 주세요. 제목은 '전체 흐름', '각 서비스의 역할', '장애 발생 시 동작', '자주 묻는 질문'으로 해주세요.'
이 메모를 리포지토리나 Wiki에 보관하면, 다음에 들어오는 사람들의 온보딩 자료가 됩니다. AI에게 학습시킬 자료로도 사용 가능하므로, 다음부터 질문할 때의 정확도도 높아집니다.
기밀 정보는 가립니다. 계정 ID, IP 주소, 사내 시스템명, 시크릿 등은 AI에게 전달하기 전에 삭제해야 합니다. 사내 AI 이용 규칙도 확인이 필요합니다. -
요금이나 사양은 공식 자료로 확인합니다. AWS의 요금이나 제한 사항은 자주 변경됩니다. AI의 설명은 어디까지나 이해를 위한 입구라고 생각하는 것이 좋습니다.
일반론과 자사 상황은 다릅니다. AI는 '일반적으로는 이렇게'라고 답변합니다. 왜 자사가 그 구성을 선택했는지에 대해서는 설계한 사람이나 자료를 확인하는 것이 확실합니다.
모든 것을 한 번에 물어보려 하기
'이 구성을 전부 설명해 주세요'라고 요청하면, 긴 설명이 돌아와 결국 머리에 남지 않습니다. 먼저 흐름을 묻고, 다음으로 궁금한 서비스 하나를 묻는 식으로 작게 나누어 질문합시다.
AI의 비용 견적을 그대로 사용하기
AI에게 비용을 추산하게 하면 그럴듯한 숫자가 나옵니다. 다만, 단가가 오래되었거나 조건을 잘못 이해하는 경우가 있을 수 있습니다. 견적은 AWS의 공식 요금 계산 도구로 확인합시다.
모든 용어를 외우려고 하지 마세요
처음부터 모든 서비스의 이름과 기능을 외울 필요는 없습니다. 눈앞의 구성도에 나오는 것만으로 충분합니다. 사용하다 보면 자연스럽게 기억하게 됩니다.
AWS 지식은 교과서를 처음부터 읽지 않아도 습득할 수 있습니다. 눈앞의 구성을 AI에게 설명하게 하고, 이유를 묻고, 다른 대안과 비교하며, 메모로 남기는 것. 이 4단계로 구성도는 '읽을 수 있는 것'으로 바뀝니다.
지식을 먼저 갖추려 하기보다, 손에 든 실제 사례(실물)부터 역산하며 배우세요. AI 시대의 학습 방법으로 꼭 시도해 보세요.
이 글은 Zenn에도 게시되어 있습니다.
