비전공자의 AWS 도전기

개발일을 하면서 웹개발과 안드로이드 그리고 프론트의 javascript까지 거쳐오면서 나는 비전공자로 개발 일을 시작했지만, 끊임없이 공부하면서 달려온거 같다. 그런데 개발자가 유독 약한 인프라와 AWS 지식이 나역시 많이 부족해서 매번 배포나 장애 이슈가 나오면 겁부터 났다. 그래서 2026년 기준으로 AWS를 “기초→실습→자격증” 흐름으로 공부하면서, 내가 실제로 무엇을 이해했고 어디서 막혔는지까지 학습 기록 형태로 정리해보려 한다. 마침 회사에 AWS를 잘하는 직원까지 새로 들어와서 어느정도 환경이 만들어져서 희망이 보이기 시작했다.

AWS 기초: 비전공자인 내가 먼저 잡아야 했던 개념

처음 AWS를 켰을 때 가장 당황했던 건 서비스가 너무 많다는 점이었다. EC2, S3, VPC, IAM… 이름은 많이 들었는데, 막상 “이걸 왜 쓰는지”가 연결이 안 됐다. 그래서 나는 외우는 걸 멈추고, 가장 먼저 큰 그림부터 잡기로 했다. 결론부터 말하면, 내게 가장 도움이 됐던 기초는 리전/가용영역, 네트워크(VPC), 권한(IAM), 비용 구조 이 네 가지였다. 이 네 가지를 잡고 나니, 이후 서비스들이 조금씩 논리적으로 보이기 시작했다.
우선 리전(Region)과 가용영역(AZ)은 “장애를 어떻게 피하는가”를 설명하는 단어였다. 예전엔 그냥 AWS 지역 선택 정도로만 이해했는데, 공부하면서 깨달았다. 한 리전 안에도 여러 AZ가 있고, 같은 AZ에만 모든 걸 몰아넣으면 특정 장애에 같이 쓰러질 수 있다는 것. 그래서 실무에서 “멀티 AZ”라는 말이 괜히 나오는 게 아니었다. 나는 아직 설계를 깊게 하진 못하지만, 최소한 “하나만 만들지 말고 분산할 수 있나?”라는 질문을 스스로 던지게 됐다.
그다음은 VPC였다. 여기서부터 나는 자주 멘붕이 왔다. 퍼블릭 서브넷, 프라이빗 서브넷, 라우팅 테이블, 인터넷 게이트웨이 같은 말이 한꺼번에 튀어나오는데, 처음엔 다 같은 네트워크 설정처럼 느껴졌다. 그래서 나는 이렇게 정리했다. “인터넷에 공개될 공간과 내부 전용 공간을 분리한다.” 이 목적 하나만 붙잡고 시작하니, 조금씩 이해가 됐다. EC2가 외부에서 접속되려면 퍼블릭 서브넷에 있어야 하고, 인터넷 게이트웨이와 라우팅이 연결돼야 한다는 흐름이 생겼다. 반대로 데이터베이스 같은 건 프라이빗 서브넷에 두고 외부 노출을 막는 게 기본이라는 것도 같이 따라왔다.
IAM은 솔직히 공부하면서 가장 무서웠다. 권한을 잘못 주면 보안 사고가 날 수도 있고, 반대로 권한이 부족하면 아무 것도 안 된다. 나는 처음에 루트 계정으로 뭔가 막 만지려는 습관이 있었는데, 이게 진짜 위험한 습관이라는 걸 알게 됐다. 그래서 나는 루트 계정은 거의 잠궈두고, MFA를 켜고, 사용자와 역할(Role)을 구분하는 것부터 시작했다. “최소 권한 원칙”도 계속 입으로만 외웠는데, 실제로 정책 문서를 보면서 필요 권한만 주려고 하니 어렵긴 했다. 그래도 이 과정을 한 번 겪으니, 이후에 서비스 연결할 때 “권한이 막혔나?”를 먼저 의심하는 습관이 생겼다.
마지막은 비용이었다. 비전공자인 나는 AWS 공부를 포기하는 가장 큰 이유가 “갑자기 돈 나올까 봐” 공포라고 생각한다. 커뮤니티 글로도 '요금폭탄'을 맞았다는 글들이 심심치 않게 나왔고 '환불'을 받는 방법도 많이 공유되고 있었다. 학생들은 환불이 어느정도 되었지만 내 경우에는 그것도 쉽지않아보였기때문에 더 걱정이 앞섰던거 같다. 그래서 나는 예산 알림(Budget)부터 설정했고, 태그(Tag)를 붙여서 실습 리소스가 뭔지 표시하려고 했다. 무료 티어가 있다고 해도 조건이 있고, 특히 실습하면서 켜둔 리소스가 계속 돈을 먹을 수 있다는 사실이 부담이었다. 나는 “실습 끝나면 반드시 삭제”를 체크리스트로 만들었고, 이 루틴이 생각보다 내 학습 지속성에 큰 도움이 됐다. 기초는 화려하지 않지만, 이 네 가지를 잡는 순간 AWS가 ‘외계어’에서 ‘조립식 시스템’처럼 보이기 시작했다.

AWS 실습: 내가 효과를 봤던 프로젝트형 학습 방식

책만 읽고 영상만 보면 “아는 것 같은데 손이 안 움직이는” 느낌이 계속 들었다. 그래서 나는 작은 결과물을 만드는 프로젝트형 실습으로 방향을 바꿨다. 목표는 거창하지 않아도 됐다. 대신 “완료하고, 기록하고, 지우기”까지 하나의 사이클로 돌리는 걸 목표로 했다.
내 첫 실습은 정적 웹사이트였다. S3로 정적 사이트를 올리고, 가능하면 CloudFront를 붙여 배포까지 경험해보는 구성이다. 여기서 내가 얻은 가장 큰 수확은 “권한과 공개 범위”였다. 버킷을 퍼블릭으로 열었다 닫았다 하면서, ‘퍼블릭 액세스 차단’이 왜 기본값으로 강조되는지 체감했다. 그리고 캐시라는 개념도 단순히 속도만이 아니라, 배포 시점에 변경이 바로 반영되지 않을 수 있다는 운영 포인트까지 연결됐다. 내가 만들었던 페이지는 단순한 소개 페이지였지만, “인터넷에 뭔가를 올려서 누구나 들어오게 만들었다”는 성취가 다음 단계로 가게 했다.
두 번째 실습은 EC2였다. 나는 리눅스가 익숙하지 않아서 여기서 많이 헤맸다. SSH 접속이 안 될 때마다 “내가 뭘 잘못했지?”를 찾아야 했는데, 대부분 원인은 보안 그룹(Security Group) 설정이었다. 어떤 포트를 열어야 하는지(22, 80, 443 등), 인바운드/아웃바운드가 뭐가 다른지, 퍼블릭 IP가 있는지 같은 기본 체크를 반복했다. 신기한 건 이 과정이 문제 해결 능력을 확 끌어올렸다는 점이다. 단순히 AWS 기능을 아는 게 아니라, “원인 후보를 좁혀가는 방식”을 배우게 됐다.
세 번째는 데이터 저장을 붙여보는 실습이다. 나는 부담을 줄이려고 먼저 RDS를 작은 규모로 붙여봤다. 여기서도 핵심은 연결이었다. 애플리케이션에서 DB로 붙으려면 네트워크 경로가 열려야 하고, DB 보안 그룹도 맞아야 하고, 같은 VPC 안에서 통신이 되는지 확인해야 했다. 한 번은 보안 그룹을 잘못 잡아서 계속 접속 실패가 났는데, 그때 “아, AWS는 결국 권한과 네트워크가 지배하는 세계구나”라는 걸 제대로 체감했다.
운영 관점 실습은 CloudWatch로 시작했다. 로그를 보고 지표를 보고, 알람을 걸어보니 “운영이란 관측 가능한 상태를 만드는 일”이라는 말이 조금 이해됐다. 그리고 나는 실습을 끝낼 때마다 내가 만든 리소스를 싹 지우는 루틴을 만들었다. 정리하자면, 내 실습 방식은 “S3로 배포 감각 → EC2로 서버 감각 → RDS로 연결 감각 → CloudWatch로 운영 감각” 순서로 진행했고, 이 정도만 해도 비전공자인 내 입장에서는 AWS가 확실히 덜 두렵게 느껴졌다.

AWS 자격증: 비전공자인 내가 세운 순서와 공부 전략

자격증은 솔직히 처음엔 부담이었다. “나는 비전공자인데, 시험을 봐도 되나?”라는 생각이 계속 들었다. 그런데 공부를 하다 보니 자격증의 장점이 있었다. 범위를 정해주고, 내가 빈틈이 어디인지 드러나게 해준다. 그래서 나는 자격증을 ‘목표’라기보다 ‘학습 프레임’으로 활용하기로 했다.
내가 세운 순서는 CLF(Cloud Practitioner)로 전체 그림을 잡고, SAA(Solutions Architect - Associate)로 설계 사고를 익히는 흐름이다. CLF는 클라우드 개념, 과금, 기본 보안 같은 내용을 넓게 다루기 때문에 비전공자에게 워밍업으로 좋았다. 하지만 취업이나 전향을 생각하면 CLF만으로는 약하다는 이야기도 많아서, 나는 CLF를 너무 길게 끌지 않고 빠르게 넘어가 SAA 준비로 들어가려 했다.
SAA 준비에서 내가 바꾼 공부 습관은 “서비스를 외우는 방식”이었다. 예전엔 EC2, S3, RDS 이런 걸 각각 따로 외우려고 했는데, 문제를 풀어보니 핵심은 “상황 조건에 맞는 선택”이었다. 그래서 나는 문제를 볼 때마다 조건을 먼저 체크했다. 비용을 줄여야 하는지, 고가용성이 필요한지, 운영 부담을 줄여야 하는지, 보안이 중요한지 같은 키워드들이다. 그리고 그 조건이 붙으면 어떤 서비스 조합이 자연스럽게 나오는지 스스로 이유를 쓰는 방식으로 오답 노트를 만들었다. 예를 들어 정적 콘텐츠는 S3+CloudFront, 확장은 ALB+Auto Scaling, 권한은 IAM Role, 비밀값은 Secrets Manager 같은 식으로 “왜 그게 답인지”를 설명하려고 했다.
또 헷갈리는 서비스는 묶어서 비교했다. S3/EBS/EFS는 저장소지만 목적이 다르고, ALB/NLB는 트래픽 처리 방식이 다르고, RDS/DynamoDB는 데이터 모델과 운영 방식이 다르다. 나는 이걸 표로 만들어서 정리했고, 이게 기억에 오래 남았다. 무엇보다 실습이 없는 상태로 문제만 풀면 이해가 얕아졌기 때문에, 나는 문제에서 나온 서비스를 실습으로 한 번이라도 만져보려고 했다. 시험 공부와 실습이 서로 도는 구조를 만들었더니, 공부가 훨씬 덜 지루했다.
마지막으로, 비전공자인 내게 자격증은 “증명”이 아니라 “말할 거리”를 만드는 도구였다. 실습을 했고, 자격증을 준비했고, 그 과정에서 무엇을 막혔는지 기록해두면, 나중에 면접이나 포트폴리오에서 설명할 수 있다. 나는 앞으로 실습 결과를 블로그 글로 남기고, 구성도와 시행착오를 같이 적어두려고 한다. 결국 비전공자의 경쟁력은 “어려운 걸 쉽게 설명하는 과정”에서 나온다고 믿기 때문이다.

내가 느낀 비전공자 AWS 공부의 핵심은 넓게 훑기보다 기초(리전/AZ, VPC, IAM, 비용)를 잡고, 작은 프로젝트 실습으로 결과물을 만든 뒤, 그 흐름을 자격증(SAA 중심)으로 정리하는 것이다. 나는 오늘도 하나의 리소스를 만들고, 왜 이렇게 구성했는지 기록하고, 마지막에는 비용이 새지 않게 정리하는 루틴을 반복하려 한다. 이 글이 나의 학습 기록이자, 다음 단계로 가기 위한 체크포인트가 되길 바란다.
글로 남기는거는 누군가를 위한 가이드의 목적도 있지만 아마도 내 스스로에게 도전이 되는 기록이 될거 같아서이다. 앞으로 주제 하나하나에 발자취를 남기면서 가려고 한다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

JOIN 기초: users와 point_history를 합쳐 ‘회원별 요약(잔액/최근 활동)’ 만들기

포인트 원장(point_history)만으로도 잔액과 통계를 만들 수 있지만, 실제 화면이나 운영 도구에서는 거의 항상 “사용자 정보”가 함께 필요합니다. 예를 들어 이런 질문들은 point_history만으로는 답이 부족합니다. 이 uid가 누구인지(가입일, 상태 등) 함께 보고 싶다 회원 목록을 보면서 각 회원의 잔액/최근 활동을 한 줄로 요약하고 싶다 최근 7일 동안 사용이 많은 회원을 “회원 정보와 함께” 추려 보고 싶다 이때 필요한 것이 JOIN입니다. JOIN은 테이블을 “합치는” 기능이지만, 정확히는 두 테이블의 행을 연결 해 새로운 결과를 만드는 방식입니다. 이번 글에서는 포인트 시스템에서 가장 흔한 JOIN 패턴(회원 + 원장 요약)을 중심으로, INNER JOIN/LEFT JOIN의 차이와 실전에서 헷갈리는 포인트를 정리합니다. 이 단원의 목적: “회원 목록 + 포인트 요약”을 안정적으로 뽑아내기 JOIN은 문법을 외우는 것보다 “어떤 결과를 만들고 싶은지”를 먼저 그리는 것이 중요합니다. 이번 글의 목표는 아래 3가지입니다. INNER JOIN과 LEFT JOIN의 차이를 이해하고 상황에 맞게 선택한다 집계(GROUP BY)와 JOIN을 결합해 ‘회원별 잔액/통계’를 만든다 JOIN에서 자주 발생하는 오류(행 폭증, 중복 집계)를 피하는 패턴을 익힌다 준비: users에 최소한의 컬럼을 더해 “JOIN 결과가 읽히게” 만들기 이전 글에서는 users가 uid와 created_at만 있었지만, JOIN 결과를 보기 편하게 하려면 display_name 같은 컬럼이 하나 있으면 좋습니다. 실제 서비스라면 이메일/닉네임/상태값이 있을 텐데, 여기서는 학습 목적상 간단히 display_name을 추가합니다. -- 이미 있다면 생략 ALTER TABLE users ADD COLUMN display_name VARCHAR(50) NULL; -- 예시 값 입력(학습용) UPDATE users SET display_n...
자세한 내용 보기

점검 SQL: “원장 합계(SUM) vs balance” 불일치를 찾아내고 원인을 좁히는 방법

포인트 시스템은 “정상 처리”만 잘 만들면 끝나는 것처럼 보이지만, 실제로는 시간이 지날수록 다양한 이유로 데이터가 어긋날 수 있습니다. 예를 들어 이런 상황이 생깁니다. 중간 장애로 트랜잭션이 일부만 반영된 것처럼 보이는 케이스(재처리/수동 개입 포함) 운영 정정(ADJUST)이나 소프트 삭제(hide) 처리 기준이 흔들린 케이스 배치 작업(만료/정산)이 예상과 다른 시간에 들어간 케이스 코드 변경 이후 특정 action_type이 누락/중복 집계된 케이스 그래서 “점검 쿼리”는 기능 쿼리만큼 중요합니다. 특히 balance 테이블(잔액 캐시)을 함께 쓰는 구조라면, 주기적으로 원장 합계와 balance가 같은지 확인해야 합니다. 이 단원의 목적: 불일치를 “발견”하고 “원인”을 좁힐 수 있는 쿼리 세트 만들기 이번 글에서는 아래 3가지를 목표로 합니다. 원장 합계(SUM)와 balance를 비교해 불일치 UID를 뽑는다 불일치가 발견되면 어디서부터 어긋났는지 범위를 좁힌다 자주 발생하는 유형(숨김 처리, 중복 요청, 배치 만료)을 점검 항목으로 만든다 1) 1차 점검: uid별 “원장 잔액”과 “balance 잔액” 비교 가장 기본은 uid별로 두 값을 나란히 놓고 비교하는 것입니다. 여기서는 hide=0만 원장 합계에 포함한다고 가정합니다. SELECT b.uid, b.balance AS balance_cache, COALESCE(l.ledger_balance, 0) AS balance_ledger, b.balance - COALESCE(l.ledger_balance, 0) AS diff FROM point_balance b LEFT JOIN ( SELECT uid, SUM(amount) AS ledger_balance FROM point_history WHERE hide = 0 GROUP BY uid ) l ON l.uid = b.uid WHERE b.balance <> COALESCE(l.ledger_...
자세한 내용 보기

EXPLAIN 기초: 점검/리포트 쿼리가 느려질 때 “왜 느린지” 확인하는 방법

포인트 시스템을 만들어가면서 새삼 느끼는것은 생성형AI가 있어서 설계하고 구상하는게 너무 쉬워졌다는것입니다. 혼자서 했다면 아마도 어려움이 많았을거 같은데 AI와 대화를 하며 개선점을 찾아가는 방식으로 진행하다보니 생각보다 기능이 치밀하게 설계를 할 수 있었습니다. 지금까지 하나하나 학습범위를 늘려가며 왔는데 아직도 갈길이 먼거 같습니다.  포인트 원장(point_history)은 시간이 지날수록 커집니다. 데이터가 커지면, 기능 쿼리(내역/잔액)뿐 아니라 점검 쿼리(원장 vs balance 비교, 월별 집계, ref_id 그룹핑)도 점점 느려집니다. 이때 흔히 “인덱스를 더 만들면 되지 않을까?”라고 생각하지만, 인덱스는 무조건 늘린다고 좋아지지 않습니다. 어떤 쿼리가 어떤 방식으로 실행되는지 모르면 잘못된 인덱스를 만들거나, 효과 없는 튜닝을 반복할 가능성이 큽니다. 그래서 필요한 도구가 EXPLAIN 입니다. EXPLAIN은 “이 쿼리를 DB가 어떤 순서로 실행할지”를 보여주는 실행 계획입니다. 즉, 느린 이유를 추측하지 않고 눈으로 확인 할 수 있게 해줍니다. 이 단원의 목적: 실행 계획을 보고 “어디를 고칠지” 결정하기 이번 글의 목표는 아래 3가지입니다. EXPLAIN 결과에서 최소한의 핵심 항목을 읽을 수 있게 된다 포인트 시스템 쿼리에서 자주 나오는 느린 패턴(풀 스캔, filesort)을 구분한다 인덱스를 “조회 패턴에 맞게” 설계하는 감각을 만든다 1) EXPLAIN 사용법: SELECT 앞에 붙이면 된다 가장 기본은 SELECT 앞에 EXPLAIN을 붙이는 것입니다. EXPLAIN SELECT id, action_type, amount, created_at FROM point_history WHERE uid = '11111111-1111-1111-1111-111111111111' AND hide = 0 ORDER BY created_at DESC, id DESC LIMIT 50; 실행 결과는 ...
자세한 내용 보기