사내 AWS 인프라 개편기 - 개선 계획

왜 지금 인프라를 손보려는가

이전 포스팅에서 서버팀 1인 체제가 됐다는 이야기를 했다. 동료 2명이 퇴사하면서 서버 개발, DB 관리, AWS 인프라, 벤더 관리까지 전부 혼자 맡게 됐다.

퇴사자 처리를 하다 보니 자연스럽게 인프라 전반을 들여다보게 됐는데.. 생각보다 손볼 곳이 많았다. EC2 인스턴스가 58개인데 누가 만들었는지도 모르는 것들이 수두룩하고, 운영 DB가 EC2에 직접 깔려있고, 프론트 배포는 zip 파일을 받아서 직접 압축 풀어주는 방식이었다.

혼자 운영해야 하는 상황이니까 오히려 지금이 정리할 타이밍이라고 생각했다. 합의할 사람이 없으니 빠르게 결정하고 움직일 수 있다.

현재 상태 — 솔직히 좀 심각하다

현황을 정리해보니 이런 그림이었다.

• EC2가 58개. 실행중 34개, 중지 24개. 담당자 불명 인스턴스가 다수
• 프론트 배포는 개발자가 빌드 zip을 보내면 내가 수동으로 압축 해제 후 배치
• 운영서버 백엔드는 jar를 nohup으로 직접 실행. 로그는 nohup.out에 쌓임
• 로깅은 각 서버에 SSH로 들어가서 로그 파일을 직접 확인
• 퇴사자에게 배포했던 SSH 키가 그대로 남아있는 상태
• 운영 DB 일부가 EC2에 직접 설치되어 있고 백업이 없음

하나하나가 소화 가능한 문제지만, 한꺼번에 보니 좀 막막했다.

핵심 고민들 — 뭘 어떻게 바꿀 것인가

전체 계획을 세우면서 몇 가지 큰 고민이 있었다. 각각 어떤 선택지가 있었고 왜 그렇게 결정했는지 정리해본다.

EC2 유지 vs ECS 전환

개발서버는 EC2 xlarge 1대에 Docker Compose로 7~8개 컨테이너를 돌리고 있다. ECS Fargate로 전환하면 관리가 편해지지 않을까 싶어서 비용을 비교해봤다.

EC2 유지 시 월 $120~130, Fargate로 가면 월 $200 이상이었다. 컨테이너별로 과금되니까 7~8개 상시 운영하면 오히려 더 비싸다. 소규모 팀에서 오케스트레이션 도입은 운영 비용만 늘리는 셈이더라.

운영서버는 고객사에 Public IP를 직접 전달한 상태라 서비스 전환 자체가 리스크였다.

결론은 EC2 유지. 나중에 ALB를 앞에 두면 서버 교체 유연성은 확보할 수 있다.

프론트 배포 자동화 — 어떤 방식으로?

지금의 수동 배포(zip 전달 → 내가 압축 해제)를 없애고 싶었다. 세 가지를 검토했다.

GitHub Actions는 프론트 조직이 분리되어 있고 개발자가 Actions를 모르는 상황이라 내가 전부 세팅하고 유지보수해야 했다. S3 + CloudFront 정적 서빙은 nginx에서 정적 파일 서빙, API 리버스 프록시, SSL을 복합적으로 처리하고 있어서 분리하면 건드릴 게 너무 많았다.

결국 S3 업로드 → Lambda → SSM Run Command 방식을 선택했다. nginx 구조를 유지하면서 배포만 자동화하는 거다. 프론트 개발자는 AWS 콘솔에서 S3에 드래그앤드롭만 하면 된다.

다만 이건 1차 목표이고, 추후에는 GitHub Actions + CodeDeploy를 활용한 배포 파이프라인으로 통합할 예정이다. 지금 당장 그렇게 못 하는 이유는 GitHub Actions 워크플로우 스크립트 작성, CodeDeploy 서비스 구축 등 추가로 세팅해야 할 것들이 많은데 1인 체제에서 그걸 한꺼번에 하기엔 시간이 안 되기 때문이다. 일단 S3 + Lambda로 수동 배포부터 제거하고, 안정화되면 단계적으로 CI/CD 파이프라인을 붙여나갈 계획이다.

DB 구조 정리

현재 구조가 좀 이상했다. 개발 DB가 RDS에, 운영 DB 일부가 EC2에 직접 설치되어 있었다. 이상적인 구조와 정반대다.

검토해보니 운영 RDS를 하나로 통합하는 건 오히려 비효율적이었다. db.t3.small 2개가 월 $50~60인데 xlarge 1개로 합치면 월 $140이다. 장애 반경도 커진다.

결론은 이렇게 정리했다.

• 개발 DB: RDS → EC2 Docker PostgreSQL로 전환 (월 $25~30 절감)
• 운영 DB(EC2): 즉시 백업 적용 → 분기 내 RDS로 순차 마이그레이션
• 운영 RDS: 프로젝트별 분리 유지

개발서버 접근 제어

개발서버에 도메인을 붙이되 사내 인원만 접근할 수 있어야 했다. 구글 워크스페이스를 쓰고 있으니 구글 인증을 연동하는 방향으로 검토했다.

ALB + Cognito가 세팅은 가장 쉽지만 ALB 비용이 월 $20~30 추가된다. oauth2-proxy는 직접 세팅이 번거롭다. 기존에 S3 + CloudFront 설정이 있어서 CloudFront + Lambda@Edge + Cognito 조합이 가장 자연스러웠다. 추가 비용도 거의 없다.

로깅 통합

서버마다 SSH로 들어가서 로그를 확인하는 건 1인 체제에서 지속 가능하지 않았다.

ELK는 1인 운영에 과하고, Datadog은 호스트당 과금이 부담이었다. CloudWatch Logs가 월 $15~75 수준으로 가장 합리적이었다. 운영서버에 Agent만 설치하면 된다. nohup.out은 logback으로 전환해서 로테이션도 적용하기로 했다.

실행 계획 — 5단계로 나눴다

한꺼번에 다 바꾸면 사고가 날 게 뻔하니까 단계별로 나눴다.

1주차: 보안 정비 + 비용 절감. 퇴사자 IAM 비활성화, SSH 키 폐기, 중지 EC2 24개 정리, 미사용 EIP/EBS/스냅샷 정리. 가장 급하고 리스크가 낮은 것부터.

2주차: 배포 자동화. S3 배포 버킷 생성, Lambda 트리거 구축, 배포 스크립트 작성. 개발서버에서 먼저 파일럿 후 점진적으로 확대.

3주차: 개발서버 정비. 도메인 연결, CloudFront + Lambda@Edge 인증, 개발 S3 버킷 통합.

4주차: 로깅 + DB 정리. CloudWatch Agent 설치, logback 전환, EC2 운영 DB 백업 적용, 개발 RDS → EC2 전환.

분기 내: 운영서버 안정화. Elastic IP 점검, ALB 도입 검토, Reserved Instance 적용, 운영 DB RDS 마이그레이션.

비용은 어떻게 될까

추가되는 비용은 CloudWatch Logs 월 $15~75, Lambda/Cognito는 무료 티어 범위. 반면 미사용 리소스 정리와 Reserved Instance 적용으로 상당한 절감이 예상된다. 개발 RDS 제거만으로도 연 $300 정도 줄어든다.

순수하게 보면 비용은 줄어들면서 인프라 품질은 올라가는 방향이다.

계획은 세웠고

솔직히 계획대로 될지는 모르겠다. 1인 체제다 보니 일상 업무 사이사이에 끼워넣어야 하고, 급한 장애가 터지면 일정이 밀릴 수도 있다.

그래도 방향은 잡았으니 1단계부터 하나씩 진행해보려고 한다. 다음 포스팅에서는 실제로 1단계를 실행하면서 겪은 일들을 정리할 예정이다.