7월 14일 박재선 멘토님 정리본

문서 정보

  • 원본 메모: [[7월 14일 박재선 멘토님]]
  • 정리본 작성일: 2026-07-14
  • 멘토링 일자: 2026-07-14
  • 멘토: 박재선 멘토님
  • 참석자: 원본에 미기록
  • 관련 프로젝트/주제: AWS VPC·Subnet·EC2 실습, IGW와 Route Table, Security Group, Nginx reverse proxy, private API server
  • 관련 문서: [[6월 23일 박재선 멘토님 정리본]]
  • 상태: 초안

한 줄 결론

AWS에서 서버가 외부와 통신하려면 public IP만으로 충분하지 않으며, IGW 연결 → Route Table 경로 → Security Group 허용 → 서비스 listen이 모두 맞아야 한다. 서비스 구조는 외부에 노출되는 Nginx reverse proxy와 private subnet의 API server를 분리하되, SSH와 키 관리 방식은 실습 편의가 아니라 최소 권한 원칙으로 다시 설계해야 한다.

회의 맥락

  • 지난 AWS 네트워크 기초 멘토링에 이어 VPC, public/private subnet, EC2, Nginx를 실제로 구성하며 연결 실패 원인을 단계별로 확인했다.
  • 주요 실습 흐름은 public subnet에 Nginx를 두고 private subnet의 API server로 요청을 전달하는 구조였다.
  • 접속 실패를 단순히 애플리케이션 문제로 보지 않고, IGW, Route Table, Security Group, public IP, listen port를 차례로 점검하는 관점이 강조되었다.
  • 원본은 실습 중 빠르게 기록한 메모이므로, 특정 CIDR과 인스턴스 설정은 확정된 운영 아키텍처가 아니라 예시로 취급한다.

핵심 피드백

영역 멘토 피드백 해석 우선순위
VPC/Subnet VPC를 public subnet과 private subnet으로 나누고 역할을 구분한다. 외부 진입점과 내부 애플리케이션을 분리하면 노출 범위와 운영 책임이 명확해진다. High
네트워크 경로 VPC에 IGW를 연결하고, public subnet이 사용하는 Route Table에 인터넷 경로를 추가해야 외부 통신이 가능하다. public IP 또는 열린 포트 하나만 확인하지 말고 전체 네트워크 경로를 함께 점검해야 한다. High
Security Group 서비스가 listen 중이어도 해당 포트의 inbound 규칙이 없으면 외부에서 접근할 수 없다. SSH, HTTP, HTTPS, API 포트를 용도별로 최소 허용해야 한다. High
Nginx Nginx는 외부 요청을 내부 API server로 전달하는 reverse proxy 역할을 한다. public Nginx를 단일 진입점으로 두고 API server는 private 영역에 두는 구성을 검토할 수 있다. High
Private API API server는 private subnet에 두고 public 진입점을 통해 접근하도록 구성한다. API server에 public IP를 직접 부여하지 않는 구조가 기본 후보가 된다. High
CIDR VPC와 subnet의 IP 대역을 CIDR로 설계하며 /32는 단일 IP를 가리킨다. 향후 환경과 AZ를 늘릴 수 있도록 대역 중복과 주소 여유를 사전에 확인해야 한다. Medium
가용성 RDS와 subnet을 설계할 때 AZ 구성을 함께 고려해야 한다. 데이터베이스 고가용성이 필요해지면 다중 AZ와 subnet group을 별도로 설계한다. Medium
운영 분리 VPC 또는 네트워크 경계를 나누면 개발·운영 리소스를 혼동해 잘못 변경할 위험을 줄일 수 있다. 환경 분리는 보안뿐 아니라 운영 실수의 범위를 제한하는 수단이다. Medium
EC2 인스턴스 아키텍처로 x86과 Arm을 선택할 수 있고 Arm 계열이 비용 면에서 유리할 수 있다. 실제 선택은 이미지·라이브러리 호환성과 실측 비용을 함께 비교한 뒤 결정한다. Low
장애 진단 nmap 등을 이용해 포트가 filtered인지 open인지 확인할 수 있다. 네트워크 계층과 애플리케이션 계층을 분리해서 진단하는 체크리스트가 필요하다. Medium
설정 관리 Nginx 설정 파일을 변경하기 전에 백업한다. 운영 설정은 변경 전 원본 보존, 변경 이력, 검증, 롤백 절차를 갖춰야 한다. Medium

결정 사항

  • 이번 실습의 기본 구조는 public Nginx reverse proxy → private API server로 이해한다.

    • 근거: Nginx는 public subnet의 외부 진입점이고 API server는 private 영역에 두는 흐름으로 실습했다.
    • 영향: 실제 인프라 초안에서도 외부 노출 컴포넌트와 내부 애플리케이션 경계를 먼저 구분한다.

  • 연결 문제는 다음 순서로 점검한다.

    • 근거: IGW 미연결, Route Table 미설정, Security Group 포트 누락이 각각 실제 실패 원인으로 등장했다.
    • 영향: public IP → IGW → route → security group → process listen → reverse proxy upstream 순서의 진단 체크리스트를 사용한다.

  • 특정 CIDR, EC2 OS, 고정 IP 사용 여부는 아직 운영 결정으로 확정하지 않는다.

    • 근거: 원본의 10.1.0.0/16, 10.1.7.0/24, Amazon Linux/Ubuntu, public IP 설정은 실습 예시다.
    • 영향: 실제 요구사항과 비용을 확인한 뒤 별도 인프라 문서에서 결정한다.

보류 사항

  • Elastic IP 또는 다른 고정 진입점 사용 여부

    • 이유: 자동 할당 public IP는 인스턴스 재시작 시 바뀔 수 있지만, 고정 IP와 관련 리소스에는 비용 정책을 확인해야 한다.
    • 다시 판단할 조건: 운영 도메인, TLS, 배포 방식과 예상 가동 시간이 정해진 뒤.

  • Bastion host 사용 여부

    • 이유: private server 관리 경로가 필요하지만 Bastion 운영 비용과 키 관리 부담이 생긴다.
    • 다시 판단할 조건: AWS Systems Manager Session Manager, VPN/Tailscale, Bastion을 보안·운영성·비용으로 비교한 뒤.

  • 다중 AZ 및 RDS 도입 여부

    • 이유: 고가용성 필요 수준과 데이터베이스 요구사항이 확정되지 않았다.
    • 다시 판단할 조건: 서비스 가용성 목표와 데이터 저장 구조가 정해진 뒤.

  • x86과 Arm 인스턴스 선택

    • 이유: 원본에는 Arm의 비용 장점이 언급됐지만 실제 워크로드 호환성과 가격은 검증되지 않았다.
    • 다시 판단할 조건: 배포 이미지와 의존성을 두 아키텍처에서 검증하고 예상 비용을 비교한 뒤.

액션 아이템

작업 담당 산출물 기한 상태
AWS 요청 경로 구성도 작성 팀 Client, IGW, Route Table, Security Group, Nginx, private API 흐름도 미정 Todo
public/private subnet 라우팅 검증 인프라 담당 subnet별 Route Table 연결과 인터넷 경로 점검 기록 미정 Todo
Security Group 최소 권한화 인프라 담당 SSH 관리 대역, HTTP/HTTPS 진입, Nginx→API 허용 규칙표 운영 전 Todo
private API server 연결 완료 인프라 담당 Nginx upstream 설정과 end-to-end 요청 성공 기록 미정 Todo
Nginx 설정 변경 절차 작성 인프라 담당 백업, nginx -t, reload, rollback 명령을 포함한 체크리스트 미정 Todo
서버 접근 키 관리 방식 재검토 팀 Bastion, Session Manager, VPN/Tailscale 비교 및 선택안 운영 전 Todo
고정 진입점과 TLS 전략 검토 팀 Elastic IP·ALB·도메인·HTTPS 구성 및 비용 비교 운영 전 Todo

후속 질문

  • Nginx가 전달할 private API의 포트는 외부 전체가 아니라 Nginx Security Group에서만 접근하도록 제한할 수 있는가?
  • SSH 22 포트를 Anywhere에 열지 않고 팀원의 고정 IP, VPN 또는 Session Manager로 관리할 수 있는가?
  • private API server가 패키지 설치나 외부 API 호출을 위해 outbound internet이 필요하다면 NAT 비용을 감수할 것인가?
  • 현재 단계에서 Bastion이 필요한가, 아니면 Session Manager나 Tailscale로 관리 경로를 단순화할 수 있는가?
  • 운영 진입점은 EC2 public IP, Elastic IP, ALB와 도메인 중 무엇이 적합한가?
  • RDS를 도입한다면 어떤 가용성 목표 때문에 다중 AZ가 필요한가?

원문 근거

  • "subnet public, subnet private 으로 구성됨. public : 인터넷에서 직접 인바운드 가능 / private 영역 : 직접 접속 안댐"

    • 정리 해석: 외부 진입 리소스와 내부 리소스를 subnet 경계로 분리한다.
    • 확실성: 높음

  • "VPC를 만들면 반드시 IGW라는 것을 붙여주어야하는데 안한겁니다."

    • 정리 해석: public subnet의 외부 통신을 위해 VPC에 IGW를 연결해야 한다.
    • 확실성: 높음

  • "라우팅 테이블이라는게 있어요. vpc안에서 트래픽이 어떻게 도는지에 대한 세팅이에요."

    • 정리 해석: IGW 연결뿐 아니라 해당 subnet의 Route Table에 올바른 경로가 있어야 한다.
    • 확실성: 높음

  • "서버에떠있는 잘 listen하고있음에도 접속이 안되는이유... 보안그룹에서 허용을 해놨는지"

    • 정리 해석: 프로세스 listen 상태와 Security Group 허용 상태를 모두 확인해야 한다.
    • 확실성: 높음

  • "여기까지한건 리버스 프록시 띄운거고, api 서버도 띄워야죠."

    • 정리 해석: Nginx 진입점과 실제 API server는 별도 구성 요소다.
    • 확실성: 높음

  • "나는 설정 파일 바꿀때는 백업 한번 하고 해요."

    • 정리 해석: Nginx와 같은 운영 설정은 변경 전 백업과 롤백 가능성을 확보한다.
    • 확실성: 높음

정리에서 제외한 내용

  • "SSH 22번을 Anywhere로 열어도 된다"는 표현은 실습 편의를 위한 발언 또는 농담일 가능성이 있으며, 운영 보안 원칙과 충돌하므로 권고사항으로 채택하지 않았다.
  • pem 키를 scp로 다른 서버에 복사하는 방식은 키 유출 위험이 있으므로 확정된 접근 방식으로 옮기지 않았다.
  • "Amazon Linux, Ubuntu 모두 Red Hat 계열"이라는 원문은 기술적으로 재확인이 필요해 핵심 내용에서 제외했다.
  • Arm 인스턴스가 최대 60% 저렴하다는 수치는 인스턴스 종류와 시점에 따라 달라질 수 있어 정량 근거로 사용하지 않았다.
  • IPv6와 비용에 관한 파편은 문맥이 불완전해 결정 근거에서 제외했다.

최종 반영 위치

  • 기획 문서: 이번 멘토링에서 직접 결정된 변경 없음
  • 모델 레이어: 이번 멘토링에서 직접 결정된 변경 없음
  • 메모리 레이어: 서버 백업을 도입할 경우 private storage와 접근 경계 검토
  • 앱 레이어: API 호출의 public 진입점과 private backend 경계
  • 평가/실험: nmap, curl, end-to-end 요청을 통한 네트워크 검증 절차
  • Linear 이슈: 미등록

다음 업데이트

  • private API server와 Nginx upstream 연결이 완료되면 실제 Security Group 규칙과 요청 경로를 반영한다.
  • 운영용 접근 방식과 고정 진입점, TLS 구성이 결정되면 보류 사항을 갱신한다.
  • 다음 AWS 실습 메모가 생기면 [[6월 23일 박재선 멘토님 정리본]]과 함께 인프라 학습 흐름으로 연결한다.