서버는 어디에 살고,
코드는 어떻게 거기까지 가나

1 VPC — 울타리 친 우리 땅

Virtual Private Cloud

VPC는 클라우드 안에 울타리를 친 우리 전용 땅이에요.

클라우드는 아마존 같은 회사가 지은 거대한 건물을 여러 회사가 나눠 쓰는 곳이에요. 그냥 두면 내 서버와 옆 회사 서버가 같은 복도에 놓이죠. 그래서 울타리를 쳐요. 그 울타리 안이 VPC예요.

• 울타리 안 주소 범위도 내가 정해요. 예: 10.0.0.0/16 (우리 땅 안에서만 쓰는 주소 범위를 적는 방식)
• 옆 회사는 울타리 안을 들여다볼 수 없어요.
• 울타리 안을 다시 구역으로 나눈 게 서브넷이에요. 다음 장에서 봐요.

문 — 드나들려면 반드시 거치는 곳 인터넷과 통하는 구역 보호 구역

2 서브넷 — 길가 구역과 안쪽 구역

서브넷은 울타리 안을 나눈 구역이에요. 길가 구역(퍼블릭)과 안쪽 구역(프라이빗), 이 둘만 기억하면 돼요.

규칙은 하나예요. 중요한 건 전부 안쪽(프라이빗)에 둔다. 앱 서버도, DB도요. 그러면 바로 문제 두 개가 생겨요.

1. 개발자가 안쪽 서버에 들어갈 길이 없다 → 3장 배스천
2. 안쪽 서버도 밖에 나갈 일이 있다 → 4장 NAT

3 배스천 서버 — 사람이 들어오는 유일한 문

문제 ① 안쪽 서버에 개발자가 들어갈 길이 없다

배스천은 사람이 안쪽 서버로 들어가는 유일한 문이에요. 길가 구역에 세운 작은 경비실.

로그를 보거나 설정을 고치려면 서버에 직접 들어가야 해요. 그런데 안쪽 서버는 인터넷에서 들어갈 길이 없죠. 그래서 길가 구역에 작은 서버를 한 대 둬요. 그게 배스천(bastion, 요새)이에요.

1. 개발자는 인터넷에서 배스천에 먼저 접속해요.
2. 배스천에서 안쪽 서버로 다시 접속해요. 같은 울타리 안이라 통해요.

두 번 거치는 이유는 하나예요. 밖에 열린 문이 딱 하나가 되니까요. 문이 스무 개면 못 지키지만 하나면 지킬 수 있어요.

• 22번 포트(SSH)만 열어요.
• 회사 IP에서만 들어오게 해요.
• 누가 언제 들어왔는지 전부 기록해요.

4 NAT 게이트웨이 — 밖으로만 나가는 심부름꾼

문제 ② 안쪽 서버도 밖에 나갈 일이 있다

NAT 게이트웨이는 안쪽 서버 대신 밖에 나갔다 오는 심부름꾼이에요.

안쪽 서버도 프로그램을 설치하고, 보안 패치를 받고, 다른 회사 서비스를 호출해요. 그런데 공인 IP(바깥 세상에서 쓰는 주소)가 없어서 직접은 못 나가요.

그래서 심부름꾼을 둬요. 안쪽 서버가 "이거 받아 와" 하면 NAT 게이트웨이가 자기 공인 IP로 바꿔서 대신 요청하고, 답이 오면 원래 서버에 돌려줘요.

제일 중요한 특징은 한 방향이라는 것. 안에서 먼저 시켜야만 움직여요. 밖에서 NAT한테 "나 들여보내 줘"라고 두드리는 건 안 돼요.

5 배스천 vs NAT — 같은 자리, 반대 방향

6 실무에서 알아둘 것 — 요즘은 이렇게

7 전체 흐름 — push 한 번에 식당까지

CI/CD가 하는 일

코드를 push하면 자동으로 굽고(빌드), 서버에 갖다 놓고 켜요(배포). 이게 CI/CD예요.

요리로 비유하면 이래요.

빌드 쪽 — 일회용 서버 쪽 — 항상 켜짐

포인트 세 개.

• 러너는 매번 새로 생겼다 사라지는 일회용 컴퓨터예요. ./gradlew build 같은 명령으로 app.jar를 만들어요.
• EC2는 항상 켜져 있어요. 이 예시에서는 길가 구역(퍼블릭)에 두고 22번 포트를 열어요. 1부처럼 안쪽에 두는 구조라면 12장의 방법을 써요.
• 둘은 다른 컴퓨터예요. 그래서 인터넷으로 파일을 건네주는 단계가 꼭 필요해요.

가장 기본적인 건네주기 방법이 SSH예요. 택배 기사가 열쇠로 식당 뒷문을 열고, 음식을 놓고, 스위치를 켜는 것과 같아요.

준비물은 세 개예요.

1. EC2 만들 때 받은 SSH 개인키(.pem)를 GitHub 저장소 Secrets에 저장
2. EC2 보안 그룹(방화벽)에서 22번 포트 열기
3. 워크플로우 yml(자동화 순서를 적는 설정 파일)에 scp와 ssh 명령 적기

8 SSH — 암호로 잠근 무전기

Secure Shell

SSH는 멀리 있는 컴퓨터를 내 앞에 있는 것처럼 조종하는, 암호로 잠근 무전기예요.

지구 반대편 컴퓨터에 명령을 치고 파일을 보낼 수 있어요. 그 내용은 아무도 엿듣지 못하게 암호로 잠겨요.

핵심은 하나. 열쇠와 자물쇠는 한 쌍이에요.

• 자물쇠(공개키)는 서버 안 ~/.ssh/authorized_keys에 달려요.
• 열쇠(개인키, .pem 파일)는 나만 가져요.
• 열쇠 가진 사람만 열려요. 비밀번호 없이도 안전해요.
• 열쇠를 GitHub Secrets에 넣어 두면 러너도 그 문을 열 수 있어요.

SSH로 하는 일은 두 가지예요.

# EC2에 들어가서 명령 치기 (여기서 java -jar 실행)
ssh -i key.pem ec2-user@1.2.3.4

# 같은 터널로 파일 복사 (scp = SSH 위에서 파일 복사)
scp -i key.pem app.jar ec2-user@1.2.3.4:/home/ec2-user/

22번 포트는 이 무전기의 주파수 번호예요. 보안 그룹에서 22번을 열어야 두드릴 수 있고, 아무 IP에나 열면 위험하니 보통 정해진 IP만 허용해요.

9 pem 키 — 열쇠는 서버가 아니라 계정에

질문: pem 파일은 EC2마다 하나씩인가요? 아니면 한 EC2에 여러 개?

둘 다 아니에요. pem은 EC2가 아니라 AWS 계정에 있는 열쇠 쌍이에요. EC2를 만들 때 "이 열쇠 쓸게요" 하고 고르는 것뿐이에요.

아파트 마스터키 하나로 여러 집을 여는 것과 같아요.

그래서 개인키가 새면 그 열쇠로 만든 EC2 전부가 위험해요. 실무에서는 환경별·팀별로 열쇠 쌍을 나누되, EC2마다 만들진 않아요. 개발/운영 서버 열쇠를 분리하고, 배포용(GitHub Actions) 열쇠를 따로 두는 식이에요.

10 WAS와 jar — 도시락형과 식당형

질문: EC2에서 도는 WAS가 jar 파일들인 거죠?

절반만 맞아요. 두 가지 형태가 있고, 요즘은 첫 번째가 대세예요.

WAS는 자바 프로그램을 돌려 주는 서버 소프트웨어예요. Tomcat이 대표예요.

어느 쪽인지는 서버에서 한 줄이면 알아요.

ps -ef | grep java

# java -jar xxx.jar 가 보이면 → 내장
# org.apache.catalina.startup.Bootstrap 이 보이면 → 외장

내장형이라도 EC2 한 대에 jar가 여러 개 돌 수 있어요. 주문 서비스 8080, 재고 서비스 8081처럼 포트를 나눠요. "WAS가 돌고 있다"는 말이 실제로는 "jar 프로세스가 N개 떠 있다"인 경우가 많아요.

11 설정 바꾸는 데 재빌드가 필요할까

질문: Tomcat 설정을 바꾸려면 재빌드·재배포해야 한다면, 내장형인 거죠?

네, 내장형이라는 강한 신호예요. 설정이 jar 안에 같이 구워져 있거든요.

빌드 없이 바꾸는 방법이 있어요. Spring Boot는 바깥에 있는 설정을 먼저 봐요.

# 실행 인자
java -jar app.jar --server.port=9090

# 환경 변수
SERVER_TOMCAT_THREADS_MAX=400 java -jar app.jar

# jar 옆에 application.yml 을 두면 jar 안의 것보다 먼저 적용

12 배포 방식의 진화 — SSH에서 Docker까지

처음엔 SSH로 직접, 커지면 S3 경유 → CodeDeploy → Docker 순으로 넘어가요.

1부와 연결하면, SSH 직접 방식은 EC2에 22번 포트를 여는 거라 "문은 하나만" 원칙과 부딪혀요. S3 경유, CodeDeploy, Session Manager는 그 문을 안 열어도 되는 방법이에요.

13 한 장 요약

14 용어 한 줄 사전

구조도나 대화에서 튀어나올 때 찾아보세요