AWS 배포: 책만큼 서버도 잘 파네

♻️ AWS EC2, S3, RDS, 그리고 CORS 해결기

 

 

1. 기존 구조: http://localhost:8080/

 

초기 프로젝트에서는 따로 웹사이트를 배포하지 않고(사실 하는 법을 몰라서 못 했다는 게 맞다), 로컬에서만 구동되게 만들었다.

당연히 주소를 링크 걸어 보여줄 수 없었고, 부트캠프 졸업할 때나 파트타임 화상면접, 인턴십 면접 때 '어떤 프로젝트를 만들었는지 보여줄 수 있어요?' 질문 받으면 로컬 화면 녹화본을 쓰는 수밖에 없었다.

그래서 리팩토링 시에 웹 배포는 필수로 고려하고 있던 부분이었다.

국내외를 막론하고 아마존의 AWS가 웹 배포 시 많이 사용되고 있었고, 따라할 수 있는 자료도 많아서 AWS를 배포 툴로 선택했다.

• 접근성 부족 → 결과물을 보여주기 어려움
• 환경 차이로 인한 오류 → GitHub를 통해 프로젝트 자체를 배포할 수는 있으나 오류 발생 多
• 확장성 테스트 불가능 → 로컬머신 성능에 의존하므로 실제 트래픽, 부하 환경 테스트 불가능
• 백업 및 장애 대응 취약 → 자동 백업이나 로깅 미비 등

 

2. AWS란?

 

AWS(Amazon Web Services)는 Amazon에서 제공하는 클라우드 서비스 플랫폼으로, 서버부터 시작해서 데이터베이스, 스토리지, 네트워크, 보안, 이외에도 IT 전반에 걸친 다양한 서비스를 제공하고 있다.

실제로 리팩토링 작업 중 인턴십 업무에 들어가면서 보이스 AI를 사용할 일이 생겼는데, 나는 AWS가 AI 음성 생성기도 서비스하는지는 처음 아았다. 이쯤 되면 없는 게 없는 만물상 수준이라고 할까?

모든 서비스는 인터넷 기반이기 때문에, AWS를 이용하면 서버를 24시간 돌릴 컴퓨터를 사거나 직접 운영하지 않아도 웹 애플리케이션을 전 세계에 배포할 수 있다.

나는 이번에 AWS의 EC2(Ubuntu 서버), S3(온라인 스토리지), RDS(온라인 DB)를 사용해 내 프로젝트를 웹에 배포했다.

 

3. AWS 배포 과정

아래와 같은 과정을 거쳐 AWS로 배포 환경을 조성했다.

생각보다 초기에 이런저런 설정 과정이 오래 걸려서 시간을 많이 썼다. 이 과정에서 AWS 공식문서를 볼 일이 많았는데, 자동한글화가 잘 되어있지만 원문을 읽었을 때 직관적으로 이해되는 경우도 적지 않았다.

개발을 시작하면서 십몇 년 배운 영어가 쓸데없지 않구나 자주 느꼈는데, 특히 이런 외국 서비스들 이용할 때 보람차게 잘 써먹고 있다.

그런 문서들도 참고하고 천천히 AWS UI에 익숙해지면서 다루기가 편해졌고, 지금 다시 하라고 하면 시간이 훨씬 덜 걸릴 것 같다.

자세한 과정은 나보다 다른 사람들이 써준, 더 최근에 작성된 포스트들이 많으니 생략.

단계	설명
AWS EC2, S3, RDS 초기 설정	EC2 인스턴스 생성, S3 버킷 생성, RDS 인스턴스(MySQL 등) 생성
보안 설정	보안 그룹에서 포트(22, 80, 3306 등) 개방, IAM 권한 부여
RDS 연결	application.yml에서 DB 주소/포트를 RDS로 지정 DBeaver에서 RDS 접속 정보 입력하여 DB 연결
S3 파일 업로드/다운로드 구축	기존 파일 업로드 로직 수정하여 AWS SDK로 S3에 파일 저장 및 조회 기능 구현
EC2에 애플리케이션 배포	빌드된 .jar 파일을 EC2에 업로드 후 실행하여 서비스 구동

 

4. CORS란?

 

과거 개발 중 CORS 문제를 처음 맞닥뜨렸을 때의 당혹감, 일단 임시방편으로 해결한 모습

 

이전에 프로젝트 개발하며 CORS policy violation을 이미 경험했기에, 이게 뭔지, 왜 생기는지 대강 알고 있었다.

CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유)는 브라우저에서 다른 도메인(Origin)의 리소스에 접근하는 걸 허용할지 말지를 결정하는 보안 정책이다.

• 내 웹 앱이 http://seoulbara.com에서 실행되고 있는데,
• API는 https://api.s3.com에  있을 때
• 이 서로 다른 두 출처 간에 통신하려고 하면
• 브라우저가 CORS 정책에 따라 요청을 막을 수 있다.

도메인, 포트, 프로토콜 중 하나라도 다르면 출처가 다르다고 간주되므로 아래와 같은 정책 위반 메시지를 콘솔에서 마주하게 되는 것이다.

Access to XMLHttpRequest at 'https://api.s3.com/image' 
from origin 'http://seoulbara.com' has been blocked by CORS policy

 

프로젝트 개발 초기에 이 에러 때문에 CORS 정책에 대해 알아보고 어떻게 해야할지 고민하느라 골머리를 앓았던 기억이 생생하다.

이때는 외부 API 서버측에서 CORS 설정을 열어주지 않았던 게 문제 였어서 임시 방편으로 처리하고 넘어갔었지만, 이제는 내가 서버측이니 해결책이 간단했다.

 

5. CORS 문제 해결

 

서버에서 CORS를 허용해주면 된다.

한 번 겪어보고 배웠으니 이번에는 아예 개발 시부터 CORS 관련 설정을 먼저 찾아보고 사전에 바이얼레이션을 방지했다.

AWS S3는 버킷 정책에서 CORS 규칙을 추가할 수 있도록 해두어서 아주 편했다.

이런 친절한 서비스가 있을 수가, 정말 고맙다

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT",
            "POST"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [
            "ETag"
        ]
    }
]

 

덕분에 미리미리 설정해 두고 브라우저 콘솔에 정책 위반이나 403 또는 400 오류 뜨는 1시간짜리 지옥을 다시 안 만나도 되었다.

• 보안상 "AllowedOrigin"은 "*"이 아니라 내 앱 도메인으로 제한 필요
• 아직 부하 테스트가 남아서 개발의 편의성을 위해 열어두었다. (제한 예정)

 

∴  정리 요약

 

AWS라는 서비스가 있는지도 몰랐는데, 배포하면서 여러가지로 많이 배웠다.

단순히 배포하는 방법 뿐만 아니라 보안 정책을 구성하거나 RDS를 DBeaver에 연결해서 보는 법, Ubuntu 서버 다루는 법, 심지어 JSP 파일은 .jar로 배포하면 오류가 나니 .war로 배포해야 한다는 사실 등.

공식문서나 스택오버플로우를 돌아다니면서 몰랐던 지식을 다양하게 접할 수 있었다.

AWS 배포의 단점은 장점에 비해 적지만, 그래도 유료라는 점 정도는 명시해야 할 것 같다.

특히 VPC 사용 면에서 월에 몇천 원~1만 원 정도 꾸준히 지출이 발생하곤 한다.

항목	로컬 배포	AWS 배포
접근성	오직 본인 PC에서만 접근 가능	어디서나 접속 가능(IP) → 서비스 용이
DB 관리	로컬 DB 사용, 꺼지면 데이터 접근 불	RDS 사용, 항상 켜져 있고 백업 가능
파일 저장	로컬 디렉터리 저장	S3 저장(안정적, 확장 가능성)
보안	방화벽, 접근 제어 부재	보안 그룹, IAM 등 체계적 보안 설정
배포 과정	빌드 후 로컬에서 실행	EC2에 .jar 배포 후 운영환경에서 실행
테스트 환경	로컬에서만 테스트 가능	실제와 유사한 환경에서 테스트
확장성	로컬에서만 테스트 가능	필요 시 인스턴스/스토리지 확장 가능
유/무료	무료	(특정 경우에서) 유료