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

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

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

사실 인프라 상태가 좋지 않다는 건 이전부터 어렴풋이 알고 있었다. 다만 당장 급한 업무가 늘 있었고, 돌아가고는 있으니까 치일피일 미뤄왔다. 전형적인 기술부채가 쌓이는 패턴이었다.

그러다 인수인계 과정에서 인프라 전반을 자세히 뜯어보게 됐는데.. 생각보다 심각했다. EC2 인스턴스가 58개인데 담당자나 용도가 문서화되어 있지 않은 것들이 수두룩했다. 팀 규모가 작다 보니 구두로 전달되는 게 대부분이었고, 시간이 지나면서 맥락이 유실된 것들이 꽤 있었다. 설명을 아예 전달받지 못한 인스턴스도 몇 개 있었다.

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

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

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

• EC2가 58개. 실행중 34개, 중지 24개. 팀원이 교체되는 과정에서 문서화 없이 구두로만 전달된 것들이 대부분이라 용도가 불분명한 것들이 다수
• 프론트 배포는 개발자가 빌드 zip을 보내면 내가 수동으로 압축 해제 후 배치. 작업 자체는 몇 분이면 끝나지만, 다른 업무에 집중하고 있을 때 배포 요청이 들어오면 흐름이 끊겼다
• 운영서버 백엔드는 jar를 nohup으로 직접 실행. 로그는 nohup.out 하나에 전부 쌓였다. 파일이 점점 커지다 보면 내가 직접 백업해놓고 파일을 정리해야 했다
• 로깅은 각 서버에 SSH로 들어가서 로그 파일을 직접 확인하는 방식. 장애가 나면 여러 서버를 하나씩 돌아다니면서 로그를 찾아봐야 했다. 1인 체제에서 이건 지속 가능하지 않았다
• 퇴사자에게 배포했던 SSH 키가 그대로 남아있는 상태
• 운영 DB 일부가 EC2에 직접 설치되어 있고 백업이 없음. 정작 안정성이 더 필요한 운영 DB가 EC2에, 개발 DB가 RDS에 있는 뒤집힌 구조

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

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

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

EC2 유지 vs ECS 전환

서버가 고객사/프로젝트별로 나뉘어 있다 보니 개발서버와 운영서버를 나눠서 검토했다.

개발서버는 EC2 xlarge 1대에 Docker Compose로 7~8개 컨테이너를 돌리고 있다. ECS Fargate로 전환하면 관리가 편해지지 않을까 싶어서 비용을 비교해봤다. EC2 유지 시 월 $120~130, Fargate로 가면 월 $200 이상이었다. 컨테이너별로 과금되니까 7~8개 상시 운영하면 오히려 더 비싸다. 소규모 팀에서 오케스트레이션 도입은 운영 비용만 늘리는 셈이더라.

운영서버는 상황이 달랐다. 일부 운영서버는 고객사에 Public IP를 직접 전달한 상태라 서버를 교체하는 것 자체가 리스크였다. IP가 바뀌면 고객사 쪽 설정도 같이 바꿔야 하니까. 나머지 운영서버도 고객사/프로젝트별로 분리되어 있어서 한꺼번에 전환하기엔 영향 범위가 너무 넓었다.

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

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

지금의 수동 배포를 없애고 싶었다. 집중하고 있을 때 배포 요청이 들어오면 흐름이 끊기는 게 가장 큰 문제였다. 세 가지를 검토했다.

GitHub Actions는 프론트 조직이 분리되어 있고, 개발자들이 Actions를 써본 적이 없어서 거부감이 있을 거라 판단했다. 거기에 레포가 20~30개 정도 되는데 이걸 일일이 워크플로우 설정하는 것도 만만치 않은 작업이었다. S3 + CloudFront 정적 서빙은 nginx에서 정적 파일 서빙, API 리버스 프록시, SSL을 복합적으로 처리하고 있어서 분리하면 건드릴 게 너무 많았다.

결국 S3 업로드 → Lambda → SSM Run Command 방식을 선택했다. nginx 구조를 유지하면서 배포만 자동화하는 거다. 프론트 개발자는 AWS 콘솔에서 S3에 드래그앤드롭만 하면 된다. 너무 배포가 잦은 테스트 서버는 배포용 폴더만 접근 가능한 계정을 따로 만들어서 직접 배포하게 유도하기도 했는데, 이런 임시방편을 계속 쓸 수는 없으니까. 이 방식은 진입점이 S3 버킷 하나라서 관리 포인트가 적다. 지금 상황에서는 이게 최선이라고 느꼈다.

다만 이건 1차 목표이고, 추후에는 GitHub Actions + CodeDeploy를 활용한 배포 파이프라인으로 통합할 예정이다. 일단 S3 + Lambda로 수동 배포부터 제거하고, 안정화되면 단계적으로 CI/CD 파이프라인을 붙여나갈 계획이다.

DB 구조 정리

팀 규모가 작고 빠르게 움직여야 하는 시기에는 EC2에 DB를 직접 설치하는 방식이 자연스러운 선택이다. 이후에도 같은 방식이 이어졌고, 내가 입사하면서 RDS를 도입하기 시작했다. 그런데 새 프로젝트에만 RDS를 적용하다 보니 결과적으로 안정성이 더 필요한 운영 DB가 EC2에, 개발 DB가 RDS에 있는 뒤집힌 구조가 됐다.

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

결론은 이렇게 정리했다.

• 개발 DB: RDS → EC2 Docker PostgreSQL로 전환 (월 $25~30 절감). 개발 DB는 데이터가 유실되어도 크게 문제되지 않는 환경이라 매니지드 서비스의 안정성이 굳이 필요하지 않았다. 관리 관점에서는 개발이든 운영이든 중요하지만, 비용을 줄일 수 있는 쪽은 개발 DB였다
• 운영 DB(EC2): 즉시 백업 적용 → 분기 내 RDS로 순차 마이그레이션. 백업 없이 운영 DB를 돌리고 있다는 게 가장 위험한 부분이라 여기부터 손댄다
• 운영 RDS: 프로젝트별 분리 유지

개발서버 접근 제어

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

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

로깅 통합

장애가 나면 서버 여러 대에 SSH로 들어가서 로그 파일을 하나씩 확인해야 했다. nohup.out에 모든 로그가 쌓이다 보니 파일이 거대해지면 내가 직접 백업하고 파일을 정리하는 수작업도 필요했다. 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단계를 실행하면서 겪은 일들을 정리할 예정이다.