AWS가 어렵게 느껴지는 이유부터 잡기
얼마 전 지인이 작은 쇼핑몰 사이트를 만들다가 서버 비용 때문에 고민하는 걸 봤습니다. 개발자는 아니지만 상품 페이지 몇 개와 주문 문의 폼 정도는 직접 운영하고 싶어 했거든요. 그런데 AWS라는 이름을 듣자마자 “그거 전문가만 쓰는 거 아니야?”라고 묻더라고요.
사실 AWS는 처음 화면이 낯설어서 그렇지, 개념을 작게 나누면 훨씬 편하게 접근할 수 있습니다. AWS는 아마존이 제공하는 클라우드 서비스 묶음입니다. 쉽게 말하면 내 방에 서버 컴퓨터를 사서 두는 대신, 필요한 만큼 빌려 쓰는 방식에 가깝습니다. 접속자가 적을 때는 작게 쓰고, 사람이 몰릴 때는 더 크게 쓰는 식이죠.
문제는 서비스 이름이 너무 많다는 점입니다. EC2, S3, RDS, Lambda 같은 이름이 한꺼번에 보이면 누구나 부담스럽습니다. 그래서 처음부터 모든 기능을 외우려 하기보다, “웹사이트를 올릴 건지”, “파일을 보관할 건지”, “데이터베이스가 필요한지”처럼 목적별로 보는 게 좋습니다.
처음 알면 좋은 AWS 기본 서비스
AWS를 처음 만질 때 자주 마주치는 서비스는 생각보다 몇 가지로 좁혀집니다. 개인 블로그, 작은 서비스, 테스트 프로젝트 기준으로는 아래 정도만 알아도 출발선에 설 수 있습니다.
- EC2: 가상 서버를 빌려 쓰는 서비스입니다. 리눅스 서버 한 대를 만든다고 생각하면 이해가 쉽습니다.
- S3: 이미지, 문서, 백업 파일 같은 정적 파일을 저장하는 공간입니다. 용량 단위로 과금됩니다.
- RDS: MySQL, PostgreSQL 같은 데이터베이스를 관리형으로 쓰는 서비스입니다.
- CloudFront: 전 세계 사용자에게 파일이나 페이지를 더 빠르게 전달하는 CDN 서비스입니다.
- Lambda: 서버를 계속 켜두지 않고, 특정 코드만 실행할 때 쓰는 방식입니다.
예를 들어 개인 포트폴리오 사이트를 운영한다면 S3와 CloudFront만으로도 충분한 경우가 많습니다. 반대로 로그인, 게시판, 관리자 페이지가 있는 서비스라면 EC2나 RDS가 필요할 수 있습니다. 쇼핑몰처럼 주문 데이터가 쌓이는 구조라면 데이터베이스를 따로 보는 편이 안정적입니다.
초보자가 가장 많이 헷갈리는 부분은 EC2를 무조건 써야 한다고 생각하는 점입니다. 정적인 소개 페이지나 랜딩 페이지라면 서버를 직접 운영하지 않아도 됩니다. 서버 관리는 업데이트, 보안 설정, 장애 대응까지 따라오기 때문에 처음에는 필요한 경우에만 선택하는 게 부담이 적습니다.
비용 폭탄 피하면서 시작하는 방법
AWS 이야기를 하면 비용 걱정이 거의 항상 따라옵니다. 실제로 클라우드는 편하지만, 켜둔 자원과 전송량에 따라 비용이 붙습니다. 작은 테스트라고 생각하고 만든 서버를 몇 달 동안 켜두면 예상보다 큰 청구서를 볼 수도 있습니다.
처음 시작할 때는 예산 알림을 꼭 설정하는 게 좋습니다. 예를 들어 월 5달러, 10달러처럼 본인이 감당할 수 있는 금액을 정해두고 알림을 걸어두면 마음이 훨씬 편합니다. AWS Billing 쪽에서 예산을 만들 수 있고, 사용량이 기준에 가까워지면 이메일로 알려줍니다.
또 하나는 리전을 신중하게 고르는 겁니다. 한국 사용자가 대부분이라면 서울 리전을 선택하는 경우가 많습니다. 다만 서비스별 가격은 리전마다 다를 수 있으니, 단순 테스트라면 가격과 응답 속도를 같이 보는 게 현실적입니다. 체감 속도는 가까운 리전이 유리하지만, 무조건 가장 가까운 곳이 항상 가장 싼 것은 아닙니다.
EC2를 쓴다면 인스턴스 크기를 작게 시작하는 편이 낫습니다. 방문자가 거의 없는 테스트 단계에서 큰 서버를 먼저 고를 이유는 별로 없습니다. 그리고 테스트가 끝난 인스턴스, 안 쓰는 디스크 볼륨, 오래된 스냅샷은 직접 지워야 합니다. 서버를 종료해도 연결된 저장 공간은 비용이 남을 수 있어서 이 부분을 놓치기 쉽습니다.
작은 프로젝트로 감 잡는 순서
AWS를 공부할 때 가장 빠른 길은 작고 구체적인 목표를 하나 잡는 것입니다. “AWS 전체를 배워야지”라고 시작하면 범위가 너무 넓습니다. 대신 “내 소개 페이지 하나 올리기”처럼 결과물이 보이는 목표가 좋습니다.
1단계: 정적 웹사이트 올리기
HTML, CSS, 이미지 파일로만 된 페이지라면 S3에 파일을 올리고 CloudFront를 붙이는 흐름으로 연습할 수 있습니다. 이 과정에서 버킷, 권한, 배포, 캐시 같은 개념을 자연스럽게 만나게 됩니다. 처음에는 권한 설정이 조금 까다롭게 느껴질 수 있지만, 공개해도 되는 파일과 숨겨야 하는 파일을 구분하는 감각을 익히기에 좋습니다.
2단계: 서버 한 대 띄워보기
그다음에는 EC2로 작은 서버를 만들어보면 됩니다. 리눅스에 접속하고, 웹 서버를 설치하고, 간단한 페이지를 띄우는 정도면 충분합니다. 여기서 보안 그룹이라는 개념을 만나게 되는데, 쉽게 말해 어떤 포트를 누구에게 열어둘지 정하는 문이라고 보면 됩니다. 웹 접속은 보통 80번이나 443번 포트를 사용하고, 서버 접속은 22번 포트를 많이 씁니다.
3단계: 데이터베이스 붙이기
게시판이나 회원 기능을 만들고 싶다면 RDS를 붙여볼 수 있습니다. 직접 데이터베이스 서버를 설치하는 방법도 있지만, 운영 관점에서는 백업과 업데이트가 꽤 귀찮습니다. RDS는 비용이 더 들 수 있어도 관리 부담을 줄여주는 장점이 있습니다. 혼자 만드는 토이 프로젝트라면 로컬 데이터베이스로 시작하고, 배포 단계에서 RDS를 붙이는 식도 괜찮습니다.
초보자가 자주 놓치는 설정
AWS는 기능보다 설정 습관이 중요할 때가 많습니다. 특히 계정 보안은 처음부터 신경 쓰는 편이 낫습니다. 루트 계정은 일상 작업에 쓰지 않고, 별도 IAM 사용자를 만들어 필요한 권한만 주는 방식이 기본입니다. 로그인에는 다중 인증을 켜두는 게 좋습니다.
권한을 줄 때도 “일단 전체 권한”으로 시작하면 편하긴 합니다. 근데 나중에 프로젝트가 커지면 누가 무엇을 할 수 있는지 파악하기 어려워집니다. 처음부터 완벽할 필요는 없지만, 최소한 운영용 계정과 테스트용 계정의 역할을 나눠두면 사고 가능성이 줄어듭니다.
로그도 은근히 중요합니다. 서비스가 갑자기 느려지거나 접속이 안 될 때, 감으로 고치려 하면 시간이 오래 걸립니다. CloudWatch 같은 모니터링 도구를 연결해두면 CPU 사용량, 메모리 상황, 오류 로그를 확인하는 데 도움이 됩니다. 작은 프로젝트라도 로그를 보는 습관을 들이면 나중에 훨씬 편합니다.
백업 역시 빼놓기 어렵습니다. 파일은 S3에 버전 관리를 켤 수 있고, 데이터베이스는 자동 백업 설정을 확인할 수 있습니다. 실제 서비스라면 “문제가 생겼을 때 몇 시간 전 상태로 되돌릴 수 있는가”를 미리 생각해야 합니다. 장애는 대부분 바쁠 때 찾아오니까요.
AWS를 배울 때 현실적인 마음가짐
AWS는 한 번에 다 익히는 도구가 아닙니다. 실무자도 필요한 서비스만 깊게 쓰는 경우가 많습니다. 블로그 운영자는 S3와 CloudFront에 익숙하면 충분할 수 있고, 백엔드 개발자는 EC2, RDS, IAM을 더 자주 만집니다. 데이터 분석 쪽이라면 또 다른 서비스가 중심이 됩니다.
처음에는 무료 사용 범위와 예산 알림을 확인하고, 작은 페이지 하나를 올려보는 것만으로도 충분합니다. 그다음 접속 속도, 보안, 백업, 배포 자동화 같은 문제를 하나씩 붙이면 됩니다. 솔직히 처음부터 완벽한 구조를 만들려고 하면 금방 지칩니다.
저라면 AWS 입문 목표를 “서비스 이름 외우기”가 아니라 “내가 만든 것을 안정적으로 올리고 비용을 읽을 줄 알기”로 잡겠습니다. 클라우드는 멋진 기술이기도 하지만, 결국 필요한 만큼 빌려 쓰고 책임 있게 관리하는 도구에 가깝습니다. 그 감각만 생기면 AWS라는 이름이 예전만큼 크게 느껴지지 않습니다.
