IT 기술 정보 뉴스팩토리

책으로 공부하고 있는 내용에서는 VPC는 거의 언급되지 않았다. 그런데 회사 동료가 프로젝트용으로 구축한 AWS 인프라를 설명해줄때에는 VPC를 가장먼저 설명해주었고 꽤 오랜시간을 할애해서 이해시켜주었다. 그런데 왜 책에서는 크게 언급되지 않았을까? 나는 VPC를 처음 접했을때 Virtual PC의 약자로 생각했다. VPC가 네트워크라는 생각은 상상도 못했다.  회사 동료의 설명으로는 인프라를 구축할때 제일먼저 만드는게 VPC라고 했다. 그만큼 중요하다는건데 아무래도 네트워크 개념이다보니 일반 교재에서는 크게 다루지 않고 넘어간듯 하다. 하지만 실제 운영용 인프라에서는 네트워크는 보안과 직결되기때문에 꽤나 복잡하게 그리고 촘촘하게 구성하는거 같다. 어찌되었든 초보자인 내가 이해하기에는 다소 어려움이 있지만 쉽게 풀이하자면 “가상 네트워크”라고는 하는데, 네트워크 자체가 익숙하지 않으니까 여전히 어렵게 느껴지기는 했다. 그래서 내가 이해한 VPC를 내 말로 다시 정리하고, 서브넷/라우팅/보안까지 연결되는 흐름을 적어나가 보겠다. VPC 기본 개념: 내가 이해한 “AWS 안의 사내망(내 전용 네트워크)” AWS 제공. VPC VPC(Virtual Private Cloud)는 내가 이해하기로 “AWS 안에서 만드는 나만의 가상 사설 네트워크”다. 나는 처음엔 VPC를 VMWare의 가상PC정도로 그냥 설정 하나로 생각했는데, 실제로는 내 서버(EC2), DB(RDS), 로드밸런서(ALB) 같은 리소스들이 살아갈 ‘땅’이자 ‘사내망’이었다. 그래서 VPC를 한 번 제대로 잡아두면 이후 서비스들이 조금 덜 흩어져 보였다. 물리서버로 본다면 아마도 IDC에 서버를 장착하는 랙정도로 생각하면 될까? 맞는 비유인지는 모르겠지만 결국은 네트워크를 구성하는거라고 정리했다. VPC를 만들 때 가장 먼저 하는 건 IP 대역(CIDR)을 정하는 것이다. 예를 들어 10.0.0.0/16 같은 범위를 잡는다. 이 CIDR은 “내 사내망의 주소 체계” 같은 거라서, 나중에 확장...

AWS를 실제로 구성하고 연결하는 실습을 진행해 보았다. 전체적으로 개념이 약해서겠지만 실습을 진행하면서 AWS 네트워크가 어렵다고 느껴졌고, ALB를 “만든다”보다 “제대로 연결한다”가 더 어렵게 느껴졌다. 특히 ALB는 만들었는데 접속이 안 되면 보안그룹, 타겟그룹, 서브넷, 라우팅까지 다 의심해야 해서 머리가 하얘진다. 그래서 ALB 하나를 실제로 만들고, “ALB SG → EC2 SG” 연결 규칙을 어떻게 설정했는지 콘솔 화면 기준(캡처 순서)으로 학습 기록을 남긴다. 사전 준비: 내가 점검한 체크리스트 나는 실습 전에 “구조를 먼저 고정”하는 게 중요했다. ALB는 퍼블릭에서 요청을 받고, EC2는 프라이빗에 숨긴다는 기본 원칙을 세웠다. 그래서 내가 준비한 전제는 다음과 같다. 첫째, VPC는 이미 있고(없으면 새로 생성), Public Subnet 2개 + Private Subnet 2개로 AZ 2개에 걸쳐 준비되어 있어야 한다. ALB는 최소 2개 AZ에 걸쳐 서브넷을 선택하는 경우가 많고, 나도 고가용성 감각을 익히려고 2개를 기준으로 잡았다. Public Subnet 라우트 테이블에는 0.0.0.0/0 -> IGW가 있어야 한다. 여기서 나는 캡처를 하나 남겼다. “Public Subnet 선택 화면 + 해당 Subnet의 Route Table 화면”을 같이 찍어두면 나중에 ‘왜 퍼블릭이 아닌데?’를 바로 확인할 수 있다. 둘째, EC2는 Private Subnet에 배치해두고, 앱이 실제로 포트를 리슨하게 만들어둔다. 나는 여기서 실수를 자주 했는데, SG만 열어놓고 애플리케이션이 안 떠 있으면 헬스체크가 실패한다. 그래서 EC2에서 80이나 8080 중 하나를 정하고, 그 포트로 간단한 응답(예: /health에서 200)을 주도록 준비했다. 이 부분도 캡처 포인트다. “EC2 인스턴스 상세 화면(서브넷/보안그룹/프라이빗 IP) + 서버에서 리슨 포트 확인”을 같이 남겨두면 원인 추적이 쉬워진다. 셋째, NAT가 없으면 Pr...

처음 근무를 했던 회사의 서버는 2개의 WEB서버, 2개의 WAS서버 그리고 1개의 DB로 구성되어 있었다. 비교적 큰 회사였기때문에 인프라팀이 따로 있었고 개발자는 개발만 할 수 있는 환경이었다. 여하튼 웹서버가 2대인데 서버1대가 죽었을때 나머지 한대가 서비스를 지속적으로 할 수 있는 구조였는데 평상시에는 부하 분산을 어떻게 할까 궁금해서 PM에게 질문을 한 적이 있었다. 그때 WEB서버 앞에 로드밸런서가 있어서 적절하게 분산시키고 있어요라고 대답을 들었다. 아마도 로드밸러서라는것에대해서 처음 알게 되었다. 이렇게 예전에는 “로드밸런서 = 트래픽 나눠주는 것” 정도로만 알고 있었다. 그런데 AWS에서 ELB를 보니 ALB, NLB, (그리고 예전의 CLB)까지 종류가 나뉘어 있어서 더 헷갈렸다. 그래서 이번 기회에 AWS 공부를 하면서 정리한 ELB 개념을 정리해보려 한다. 목표는 “언제 ALB를 쓰고, 언제 NLB를 쓰는지”를 내 말로 설명할 수 있게 되는 것이다. 소제목 1 - ELB 기본: 내가 이해한 “트래픽 입구를 하나로 만드는 역할” ELB(Elastic Load Balancing)는 내가 이해하기로 “서비스 앞단에서 트래픽을 받아서 뒤쪽 자원으로 분산해주는 입구”다. 사용자는 내 서비스의 실제 서버(EC2)가 몇 대인지, 어디에 있는지 몰라도 된다. 사용자는 ELB로 들어오고, ELB가 뒤에서 살아있는 서버로 요청을 넘겨준다. 그래서 나는 ELB를 “문지기 + 교통정리”라고 생각했다. 처음엔 로드밸런서를 굳이 왜 써야 하나 싶었는데, 공부하면서 가장 크게 와닿은 건 고가용성과 확장성이다. 서버 한 대가 죽어도 ELB가 다른 서버로 보내주면 서비스가 계속 살아있다. 트래픽이 늘면 서버를 더 붙이고(오토스케일링), ELB는 새로 붙은 서버로도 자동으로 분산한다. 또한 보안 측면에서도 장점이 있다. 외부에 직접 노출되는 건 ELB만 두고, 실제 앱 서버는 Private Subnet에 숨기는 구조가 가능해진다. 나는 “Public ALB + Pr...

모바일개발을 오래하다보니 생각보다 인프라 지식이 부족한편이다. 인프라 지식이 부족해서 AWS에 대해서 공부하면서 '보안그룹'에 대해서 읽어볼때 단순하게 '방화벽'이구나 하고 이해하고 넘어갔다. 예전에 회사서버가 해킹당해서 '코인'을 열씸히 채굴한적이 있었는데 해킹당한 사실을 발견하기 전에는 운영중인 서버가 항상 문제가 없다고 생각했다. 하지만 보안 컨설팅을 받고나서 하루에서 수백번 이상 해킹시도가 있었던 로그기록을 확인하고나서야 서버는 항상 외부의 침입에 노출되어 있다는걸 알게 되었다. 각설하고 '보안그룹'은 방화벽이 맞는것같다. 몇일전에 AWS 인프라를 담당하는 회사 직원에서 '보안그룹'에 대해서 질문을 했는데 '방화벽'이 맞다고 했다. 그리고 우리회사 인프라는 모두 private으로 구성되어 있고 모든 인바운드, 아웃바운드는 보안그룹에 의해서 관리되고 있다고 말했다. 조금 어렵기는 했지만 방화벽으로 모둔 입출력이 관리되고 있다고 이해했다. 그만큼 중요한 거겠지 생각했다.  중요한거니 조금더 힘을내고, 공부하면서 정리한 AWS 보안그룹 개념을 학습 기록 형태로 남긴다. 보안그룹 기본: 내가 이해한 “인스턴스 단위 상태기반 방화벽” 내가 처음 정리한 한 문장은 이거다. “보안그룹은 EC2(정확히는 ENI)에 붙는 상태 기반(Stateful) 방화벽이다.” 여기서 ‘상태 기반’이라는 말이 처음엔 어려웠는데, 나는 이렇게 이해했다. 인바운드로 들어오는 트래픽을 허용하면, 그 응답 트래픽은 자동으로 허용된다. 반대로 아웃바운드로 나가는 트래픽을 허용하면, 그 응답도 자동으로 돌아올 수 있다. 즉, 들어오고 나가는 왕복을 사람이 일일이 다 뚫어주지 않아도 되는 구조라서, 초보자인 내가 만지기엔 NACL보다 SG가 덜 무섭게 느껴졌다. 그리고 보안그룹은 ‘허용(Allow) 규칙만 있다’는 점도 중요했다. 나는 처음에 “막는 규칙(Deny)도 있겠지”라고 생각했는데, SG는 기본적...

예전에 일했던 회사의 서버구조가 2중화로 구성된 Web + WAS + DB구조였다. 우리 회사의 인프라 담당자에게 물어보니 연습하기에 좋은 구조로 “Public ALB + Private EC2 + RDS”를 추천해줬는데 예전에 담당했던 서비스의 구조와 비슷하다는걸 느꼈다. 그 전에는 잘 알지도 못하면서 AWS 아키텍처 그림을 보면 늘 “대충 이런 느낌이겠지”로 넘겨버리곤 했다. 그래서 2026년 기준으로 가장 흔한 형태이자 연습하기 좋다는 “Public ALB + Private EC2 + RDS” 기본 아키텍처를 머리속에서 정리하고, VPC/라우팅/보안 흐름이 머릿속에서 연결되도록 학습 기록으로 남긴다. 소제목 1 - VPC와 서브넷 설계: 내가 머릿속에 먼저 그린 지도 이 아키텍처를 이해하려면 “리소스를 어디에 둘 것인가”부터 결정해야 했다. 나는 항상 서비스부터 만들고 네트워크는 나중에 맞추려다가 더 헷갈렸는데, 이번엔 반대로 VPC 지도를 먼저 그렸다. 내가 잡은 기본은 VPC 하나(예: 10.0.0.0/16) 안에 서브넷을 최소 4개로 나누는 구성이다. 이유는 고가용성을 위해 AZ를 2개 쓰기 위해서다. 그래서 Public Subnet 2개(AZ A, AZ B), Private Subnet 2개(AZ A, AZ B)로 시작하는 그림을 머리에 넣었다. 퍼블릭/프라이빗은 ‘이름표’가 아니라 라우팅이 결정된다는 것도 이미 여러 번 헷갈려봤기 때문에, 서브넷을 만들고 나서 라우트 테이블을 꼭 같이 떠올리기로 했다. Public Subnet에는 인터넷과 맞닿아야 하는 리소스가 들어간다. 여기서는 ALB가 대표다. ALB는 외부 사용자의 요청을 받아야 하니까 퍼블릭에 있어야 하고, 보통 가용영역 2개에 걸쳐서 배치된다. 그리고 Private Subnet에는 EC2(앱 서버)와 RDS(DB)를 두는 게 기본이다. 특히 RDS는 인터넷에 노출되면 안 되기 때문에, 퍼블릭에 두지 않는다는 원칙을 내 머리에 박아두었다. 여기서 내가 한 번 더 정리한 포인트는 “...

예전에 VMWare를 이용해서 3개의 서버를 구성하고 네트워크 실습을 한적이 있었다. 하지만 곧 흐지부지되고 공부를 마칠수밖에 없었는데 당시 모바일개발을하던 나에게 네트워크는 너무 먼 이야기였던거 같다. 지금도 마찬가지로 AWS를 공부할 때 제일 막막했던 파트가 네트워크였다. 그래서 2026년 기준으로 내가 이해한 범위 안에서 VPC부터 서브넷, 라우팅, 보안(SG/NACL)까지 핵심 용어를 내 말로 정리해 학습 기록으로 남긴다. 물론 회사 동료에게 속성으로 배우는 시간이 있었는데 솔직히 너무 어려운 인터페이스때문에 어느 메뉴가 어디인지도 지금은 기억이 나지 않는다. 그래서 천천히 나중에 헷갈릴 때 다시 읽을 수 있게 “한 줄 정의 + 실무 감각” 중심으로 적어보려고 한다. 소제목 1 - VPC: AWS 안에서 만드는 나만의 가상 사설 네트워크 VPC는 내가 AWS에서 처음 제대로 붙잡은 개념이다. 예전에는 “그냥 네트워크 설정 같은 거겠지”라고 생각했는데, 실습을 해보니 VPC는 거의 모든 리소스 배치의 시작점이었다. 내가 이해한 VPC는 “AWS 안에서 만드는 나만의 가상 사설 네트워크, 즉 데이터센터 한 칸”이다. 회사에서 사내망을 따로 운영하듯이, AWS에서도 내 서비스가 돌아갈 사내망을 하나 만든다고 보면 감이 잡혔다. VPC를 만들 때 제일 먼저 하는 건 IP 대역(CIDR)을 정하는 것이다. 예를 들어 10.0.0.0/16 같은 범위를 잡아두고, 그 안에 EC2(서버), RDS(DB), ALB(로드밸런서) 같은 자원을 배치한다. 여기서 중요한 건 “처음부터 너무 작게 잡지 말 것”과 “겹치지 않게 잡을 것”이라고 들었다. 나중에 다른 네트워크랑 연결(VPN/Peering/Transit Gateway 같은 것)을 할 수도 있는데, CIDR이 겹치면 골치가 아프다고 해서 나는 공부용이라도 신중하게 잡아두려고 했다. VPC를 ‘한 덩어리’로만 보면 좀 추상적인데, 내 머릿속에서는 “큰 땅”으로 생각하니 이해가 쉬웠다. 땅이 있으면 구역을 나눠야 하...

프론트 기반 개발자라 겪었던 인프라에 대한 공포를 극복하기 위해서 그리고 인프라 지식이 부족한 편이고, 막막한 마음을 없애기 위해서 AWS 공부에 도전했다. 그런데 시작부터 AWS는 “잘못 만지면 비용 폭탄”이라는 얘기를 많이 들어서 가입부터 겁이 났다. 그래서 2026년 기준으로 AWS 프리티어 계정을 만들기 전에 내가 준비한 것(이메일, 결제, 보안)을 학습 기록처럼 정리해보았다.  1 - 이메일 준비: 계정 만들기 전에 내가 체크한 것들 AWS 프리티어를 시작하기로 마음먹고 제일 먼저 한 건, 로그인 이메일부터 분리하는 일이었다. 예전에는 어떤 서비스든 그냥 개인 메일 하나로 가입해버렸는데, AWS는 결제와 보안이 엮이니까 그렇게 하면 나중에 관리가 힘들 것 같았다. 특히 나는 실습하다가 계정 설정을 꼬일 가능성이 높다고 생각해서, “AWS 전용 이메일”을 새로 만드는 쪽으로 갔다. 내가 체크한 포인트는 단순했다. 첫째, 이 이메일은 비밀번호를 강하게 하고 2단계 인증까지 걸어둘 것. AWS 자체 보안도 중요하지만, 이메일이 뚫리면 계정 복구 과정이 흔들릴 수 있으니 결국 이메일이 핵심이었다. 둘째, 메일함에서 AWS 관련 메일이 묻히지 않게 라벨/필터를 만들었다. 가입 확인, 결제 알림, 보안 경고 같은 메일을 놓치면 이후에 “왜 과금됐지?” 같은 상황이 생길 수 있을거라 생각했다. 또 하나는 계정 이름(어카운트 네이밍)이다. 나는 나중에 포트폴리오나 실습 계정을 여러 개 운영할 수도 있을 것 같아서, 이메일과 별개로 계정의 용도를 이름에 남기는 습관을 들이기로 했다. 예를 들면 “study-free-tier” 같은 식으로 목적을 적어두면, 콘솔이나 청구서에서 볼 때도 헷갈리지 않을 것 같았다. 그리고 마지막으로 내가 미리 마음먹은 건, “가입 후 바로 루트 계정을 거의 안 쓸 것”이다. 이게 이메일 준비와 연결되는 이유가 있다. AWS 가입은 루트 계정으로 시작되지만, 이후에 IAM 사용자로 넘어가야 안전하다는 말을 많이 봤다. 그래서...

개발일을 하면서 웹개발과 안드로이드 그리고 프론트의 javascript까지 거쳐오면서 나는 비전공자로 개발 일을 시작했지만, 끊임없이 공부하면서 달려온거 같다. 그런데 개발자가 유독 약한 인프라와 AWS 지식이 나역시 많이 부족해서 매번 배포나 장애 이슈가 나오면 겁부터 났다. 그래서 2026년 기준으로 AWS를 “기초→실습→자격증” 흐름으로 공부하면서, 내가 실제로 무엇을 이해했고 어디서 막혔는지까지 학습 기록 형태로 정리해보려 한다. 마침 회사에 AWS를 잘하는 직원까지 새로 들어와서 어느정도 환경이 만들어져서 희망이 보이기 시작했다. AWS 기초: 비전공자인 내가 먼저 잡아야 했던 개념 처음 AWS를 켰을 때 가장 당황했던 건 서비스가 너무 많다는 점이었다. EC2, S3, VPC, IAM… 이름은 많이 들었는데, 막상 “이걸 왜 쓰는지”가 연결이 안 됐다. 그래서 나는 외우는 걸 멈추고, 가장 먼저 큰 그림부터 잡기로 했다. 결론부터 말하면, 내게 가장 도움이 됐던 기초는 리전/가용영역, 네트워크(VPC), 권한(IAM), 비용 구조 이 네 가지였다. 이 네 가지를 잡고 나니, 이후 서비스들이 조금씩 논리적으로 보이기 시작했다. 우선 리전(Region)과 가용영역(AZ)은 “장애를 어떻게 피하는가”를 설명하는 단어였다. 예전엔 그냥 AWS 지역 선택 정도로만 이해했는데, 공부하면서 깨달았다. 한 리전 안에도 여러 AZ가 있고, 같은 AZ에만 모든 걸 몰아넣으면 특정 장애에 같이 쓰러질 수 있다는 것. 그래서 실무에서 “멀티 AZ”라는 말이 괜히 나오는 게 아니었다. 나는 아직 설계를 깊게 하진 못하지만, 최소한 “하나만 만들지 말고 분산할 수 있나?”라는 질문을 스스로 던지게 됐다. 그다음은 VPC였다. 여기서부터 나는 자주 멘붕이 왔다. 퍼블릭 서브넷, 프라이빗 서브넷, 라우팅 테이블, 인터넷 게이트웨이 같은 말이 한꺼번에 튀어나오는데, 처음엔 다 같은 네트워크 설정처럼 느껴졌다. 그래서 나는 이렇게 정리했다. “인터넷에 공개될 공간과 내부 전...