• nginx, apache는 무엇인가?

-일단 두 개념을 알기 전에 웹서버에 대해 다시 알아봅시다.

🍽️ 웹 서버란 무엇인가?
클라이언트가 웹 브라우저 주소창에 http://43.200.5.162을 입력하고 엔터를 치는 것은, 식당에 들어온 손님이 "웹 페이지라는 요리 좀 주세요!"라고 주문(HTTP 요청)을 하는 것과 같습니다.
이때 손님을 가장 먼저 맞이하여 주문을 받고, 주방(백엔드 서버)에서 요리를 가져오거나 샐러드 같은 완성된 음식(이미지, HTML 등 정적 파일)을 즉시 내어주는 최전선의 직원이 바로 웹 서버(Nginx, Apache)입니다.

🏛️ Apache (아파치): 전통의 베테랑 전담 직원

• 작동 방식 (Multi-Process): 손님이 1명 들어올 때마다 전담 직원(프로세스)을 1명씩 새로 배정하여 끝까지 서빙을 책임지게 하는 방식입니다.

• 장점: 역사가 깊어 매우 안정적이고, 직원이 손님의 다양한 요구를 들어줄 수 있는 풍부한 확장 기능(모듈)을 갖추고 있습니다.

• 단점: 평소엔 좋지만, 갑자기 손님이 1만 명씩 몰려들면 직원도 1만 명을 고용(메모리 대량 소모)해야 하므로 식당(서버)이 감당하지 못하고 다운되는 치명적인 문제(C10K 문제)가 있었습니다.

🚀 Nginx (엔진엑스): 현대적인 초고속 카운터 직원

• 작동 방식 (Event-Driven): 전담 직원을 두는 대신, 소수의 뛰어난 카운터 직원들이 주문(Event)만 비동기적으로 아주 빠르게 쳐내는 방식입니다. 주문 번호표만 주고 다음 손님을 바로 받는 식입니다.

• 장점: 방금 구축하신 AWS의 t3.micro 같은 작고 가벼운 자원에서도 엄청나게 많은 접속자를 동시에 감당할 수 있을 정도로 빠르고 가볍습니다. 현대 클라우드 인프라의 대세로 자리 잡았습니다.

• 단점: Apache만큼 복잡하고 다양한 동적 모듈을 즉각적으로 붙였다 떼기는 상대적으로 까다롭습니다.

방화벽 이슈가 생길것이다 - 방화벽이 무엇인지 ?

• 방화벽 이슈 - 보안그룹(Security Group)

- AI에게 물어본 상황 질답 -

1. "여기서 어떻게 규칙을 추가해?"

• 상황: 터미널에서 SSH 접속 시 Connection timed out 에러가 발생했을 때, AWS 인바운드 규칙 편집 창을 캡처해서 질문해 주셨습니다.

• 답변: 기존에 설정된 IP 주소가 현재 사용 중인 데스크톱의 IP와 달라서 방화벽이 차단하고 있다는 점을 짚어드렸습니다. '소스' 항목을 '내 IP (My IP)'로 클릭 한 번에 변경하여 현재 주소로 자동 갱신하고 통신 터널을 뚫는 방법을 안내해 드렸습니다.

2. "뭐가 문제일까?"

• 상황: 서버 재부팅 후 변경된 IP로 다시 접속을 시도했는데도, 계속해서 네트워크가 막히는 답답한 상황이었습니다.

• 답변: 올려주신 방화벽 설정 화면을 분석한 결과, 웹 통신을 위한 HTTP(80번) 포트만 남아있고 원격 접속을 위한 SSH(22번) 방화벽 규칙 자체가 통째로 삭제되어 있던 원인을 찾아냈습니다. 빈 줄을 추가해 다시 22번 포트 대문을 복구하는 해결책을 제시해 드렸습니다.

-깨달은 점 및 방화벽이란?-

• 🛡️ AWS의 가상 방화벽: 보안 그룹(Security Group)(방화벽)

• 이 보안 그룹은 내 클라우드 서버(인스턴스)를 마치 보이지 않는 캡슐처럼 둘러싸고 있는 '깐깐한 투명 경비원'과 같습니다. 이 경비원은 출입 명부(인바운드 규칙)를 들고 서서 딱 두 가지만 아주 엄격하게 검사합니다.

1. 어디서 왔는가? (Source IP 주소)

"네 신분증(IP 주소)이 내가 가진 출입 허가 명단에 적혀 있는가?"

• 어제 규칙에 0.0.0.0/0을 넣으셨던 것은 "전 세계 어느 IP 주소에서 오든 다 들여보내라"라는 뜻이었고, '내 IP'를 선택하셨던 것은 "오직 내 데스크톱 IP 주소만 들여보내라"라는 뜻이었습니다.

2. 어떤 문으로 들어갈 것인가? (Port 번호)

• "네가 지금 통과하려는 문이 관리자 전용 철문(SSH, 22번 포트)이냐, 아니면 일반 방문객용 유리 자동문(HTTP, 80번 포트)이냐?"

• 어제 실수로 22번 규칙이 지워졌을 때 통신이 먹통이 된 이유는, 경비원이 "22번 문은 아예 폐쇄되었으니 돌아가라"며 매몰차게 막아섰기 때문입니다.

(22번포트로는 접속 불가능)

서브도메인은 무엇인가?

• 이해하기 쉽게 비유를 들어 설명하자면, 메인 도메인(Domain)이 커다란 '회사 본사 건물'이라면, 서브도메인(Subdomain)은 그 건물에 소속된 '부서별 별관'이나 '특정 층'이라고 생각하시면 아주 직관적입니다.

• 🌐 서브도메인의 구조와 예시

• 우리가 자주 방문하는 웹사이트를 떠올려 보면 그 구조를 금방 파악할 수 있습니다. 메인 도메인 이름의 맨 앞(좌측)에 점(.)을 찍고 특정 단어를 붙여서 만듭니다.

메인 도메인: google.com (본사)

서브도메인 1: mail.google.com (이메일 서비스 부서)

서브도메인 2: drive.google.com (클라우드 저장소 부서)

서브도메인 3: maps.google.com (지도 서비스 부서)

💡 서브도메인을 사용하는 핵심 이유

• 무한한 확장과 비용 절감
  새로운 웹 서비스(블로그, 쇼핑몰, 사내 그룹웨어 등)를 출시할 때마다 새로운 도메인(예: google-mail.com)을 매번 돈을 주고 구매할 필요가 없습니다. 메인 도메인 하나만 소유하고 있으면, 그 앞에 이름을 붙여서 서브도메인을 무료로 무한정 생성할 수 있습니다.

• 서버(컴퓨터)의 역할 분리와 트래픽 분산
  가장 중요한 인프라적 이유입니다. 서브도메인마다 목적지인 IP 주소를 완전히 다르게 설정할 수 있습니다.
  예를 들어 www.example.com으로 들어오는 손님은 웹 서버(Nginx)로 보내고, api.example.com으로 들어오는 손님은 뒤쪽에 숨겨진 데이터베이스 서버로 분산시켜 안내할 수 있습니다.

요약하자면, 서브도메인은 "하나의 큰 브랜드(도메인) 아래에서 다양한 서비스들을 체계적으로 분류하고, 각각 다른 서버로 통신 길을 열어주기 위해 사용하는 확장 주소"입니다.

🔒 SSL과 Let's Encrypt란 무엇인가?

1) SSL (Secure Sockets Layer) / TLS

• 기존의 HTTP(80번 포트) 통신은 투명한 유리 상자에 데이터를 담아 택배를 보내는 것과 같습니다. 중간에 해커가 가로채면 비밀번호든 개인정보든 내용물이 훤히 보이죠.
  여기에 SSL(현재는 더 발전된 TLS)이라는 기술을 적용하면, 유리 상자를 절대 부술 수 없는 '티타늄 금고(암호화)'로 바꿉니다. 해커가 금고를 훔쳐 가도 열쇠가 없으니 내용을 절대 볼 수 없게 만드는 현대 웹 보안의 필수 기술입니다.

2) Let's Encrypt (렛츠 인크립트)

• 내 서버가 가짜 피싱 사이트가 아니라 진짜 안전한 사이트임을 증명하려면 공인된 기관에서 발급한 '디지털 인증서(신분증)'가 필요합니다. 과거에는 이 인증서가 1년에 수십만 원씩 하는 고가의 장비였지만, 웹의 보안을 높이기 위해 전 세계 IT 기업들이 후원하여 만들어진 비영리 기관이 바로 Let's Encrypt입니다. 누구나 무료로, 명령어 몇 줄만으로 공인 보안 인증서를 발급받을 수 있게 해주는 아주 고마운 존재라고 생각하시면 됩니다.

참고

TLS 란?

• TLS(Transport Layer Security)는 방금 요약했던 SSL의 정식 후속작이자, 한층 더 강력하게 진화한 최신 암호화 통신 규약(프로토콜)입니다.

🛡️ TLS의 핵심 원리: '절대 뚫리지 않는 장갑차'

• HTTP 통신이 내용이 훤히 보이는 '투명한 엽서'를 쌩으로 우체통에 넣는 것이라면, TLS는 택배 차량 자체가 외부의 공격으로부터 완벽히 보호되는 '장갑차(보안 터널)'를 만들어 그 안에서 데이터를 주고받는 기술입니다.

• 이 장갑차를 출발시키기 전에, 클라이언트(브라우저)와 서버(Nginx)는 아주 치밀한 신원 확인 및 암호 설정 과정을 거치는데 이를 TLS Handshake(핸드셰이크)라고 부릅니다.

• 인사 및 암호화 방식 합의: "안녕? 난 크롬 브라우저야. 우리 통신할 때 어떤 자물쇠(암호화 알고리즘) 쓸까? 난 A, B, C를 할 줄 알아." / "안녕 난 Nginx 서버야. 그럼 우리가 공통으로 아는 가장 안전한 B 방식으로 암호화하자!"

• 신분증 검사 (인증서 검증): 서버가 아까 Let's Encrypt에서 받은 '디지털 신분증'을 브라우저에게 보여줍니다. "나 진짜 api.myfortfolio.xyz 서버 맞으니까 믿어도 돼."

• 임시 열쇠 교환 (Key Exchange): 서로 신분이 확실해지면, 오직 이번 단 한 번의 통신에서만 쓸 '일회용 마스터 열쇠(Session Key)'를 수학적으로 아주 복잡하게 교환합니다.

• 보안 터널 완성: 이제부터 주고받는 모든 데이터(비밀번호, 개인정보)는 이 일회용 열쇠로 잠겨서 전송됩니다. 해커가 중간에 데이터를 가로채도(Sniffing), 열쇠가 없으니 의미를 알 수 없는 쓰레기 문자열로만 보이게 됩니다.

정리

• 이번 클라우드 서버 구축 및 배포 실습을 진행하며 마주했던 핵심 기술과 이슈들을 비유와 함께 다시 한번 정리해 봅니다.

🍽️ 1. 웹 서버: Nginx vs Apache

웹 서버는 손님(클라이언트)이 브라우저 주소창에 도메인을 입력(HTTP 요청)했을 때, 가장 먼저 주문을 받고 주방(백엔드 서버)의 요리를 전달하거나 정적 파일(HTML 등)을 내어주는 '최전선 직원' 역할을 합니다.

🏛️ Apache (아파치) - '베테랑 직원'

• 방식 (Multi-Process): 손님이 1명 올 때마다 전담 직원을 1명씩 배정해 서빙을 책임지는 방식.

• 특징: 안정적이고 다양한 요구를 들어줄 수 있는 풍부한 확장 기능(모듈)을 갖춤.

• 한계: 손님이 만 명 단위로 몰리면 직원도 만 명이 필요하여 서버 메모리 고갈로 다운되는 문제(C10K 문제)가 발생할 수 있음.

🚀 Nginx (엔진엑스) - '초고속 카운터 직원'

• 방식 (Event-Driven): 전담 직원을 두지 않고, 소수의 뛰어난 직원이 주문(Event)만 비동기적으로 빠르게 처리하는 방식.

• 특징: AWS의 t3.micro 같은 가벼운 자원에서도 엄청난 동시 접속자를 감당할 수 있어 현대 클라우드 인프라의 대세로 자리 잡음. 이번 실습에서 리버스 프록시 역할로 훌륭하게 작동함.

🛡️ 2. AWS 보안 그룹 (Security Group): 클라우드의 투명 경비원

• 실습 중 마주했던 Connection timed out 등 접근 불가 이슈의 원인은 대부분 이 보안 그룹 설정이었습니다. 보안 그룹은 내 서버(인스턴스)를 감싸는 '깐깐한 방화벽'으로, 딱 두 가지만 엄격하게 검사합니다.

• 어디서 왔는가? (Source IP 주소): "방문자의 신분증(IP 주소)이 허가 명단에 있는가?"
  (예: 0.0.0.0/0은 전 세계 모두 개방, '내 IP'는 특정 데스크톱만 허용)

• 어떤 문으로 들어갈 것인가? (Port 번호): "지정된 통로를 이용하고 있는가?"
  (예: 22번 포트는 관리자용 SSH 철문, 80번 포트는 방문객용 HTTP 자동문. 규칙이 삭제되면 해당 문은 폐쇄됨)

🌐 3. 서브도메인 (Subdomain): 효율적인 트래픽 분산과 확장

메인 도메인이 커다란 '회사 본사 건물'이라면, 서브도메인은 건물에 소속된 '부서별 별관'입니다.

예시: example.com (본사) -> api.example.com (데이터 처리 부서), www.example.com (웹 서비스 부서)

핵심 목적: 도메인을 추가 구매할 필요 없이 무한 확장이 가능하며, 서브도메인마다 IP 목적지를 다르게 설정해 Nginx나 백엔드 서버로 트래픽을 체계적으로 분산시킬 수 있습니다. 이번 실습에서는 api 서브도메인을 파이썬 서버망으로 연결했습니다.

🔒 4. SSL & Let's Encrypt: 현대 웹 보안의 필수 요소

• SSL (Secure Sockets Layer) / TLS:
  기존 HTTP(80포트)는 투명한 유리 상자에 데이터를 담아 보내는 방식이라 해킹에 취약했습니다. SSL은 이 통신을 절대 부술 수 없는 '티타늄 금고(암호화)'로 만들어, 중간에 탈취되어도 내용을 볼 수 없게 보호합니다.

• Let's Encrypt:
  내 서버가 안전함을 증명하는 '디지털 신분증' 발급 기관입니다. 과거엔 매우 고가였으나, 현재는 비영리 기관인 Let's Encrypt를 통해 명령어 몇 줄 만으로 누구나 무료로 공인 HTTPS 보안 인증서를 발급받을 수 있습니다. 이번 실습에서 Certbot을 활용해 완벽하게 암호화 통로를 구축했습니다.

• 챗봇 링크: https://api.myfortfolio.xyz/