문제 상황

• MOMO 프로젝트를 AWS ECS + EC2 환경에 배포하고 실제 운영하면서 개발 환경에서는 발견하지 못했던 다양한 인프라 관련 이슈들을 경험했습니다. 환경변수 관리, 연결 설정, 새로운 기술 도입의 복잡성 등에서 중요한 교훈을 얻었습니다.

핵심 교훈들

1. 환경변수 관리의 중요성

• 하드코딩된 연결 정보(localhost 등)로 인해 프로덕션 배포 시 Redis 연결 실패가 발생했습니다. 로컬 개발환경에서는 정상 동작했지만 운영환경에서는 localhost 연결 시도로 장애가 발생했습니다. 이를 해결하기 위해 모든 연결 정보를 환경변수로 분리하고 Spring의 @Value 어노테이션을 활용한 외부 설정 주입 방식으로 변경했습니다.

2. new 키워드 사용 시 주의사항

• new 키워드로 객체를 생성할 때 기본값이 localhost로 설정되어 프로덕션에서 연결 실패가 발생했습니다. Spring IoC 컨테이너를 통한 의존성 주입으로 변경하여 환경변수 기반 Bean 생성을 통해 안전한 설정 관리를 구현했습니다.

3. 모니터링 스택 도입의 인프라 복잡성

• Prometheus + Grafana + Loki + OpenTelemetry 모니터링 스택 도입 시 예상보다 훨씬 복잡한 인프라 관리가 필요했습니다. 설정 파일 관리의 복잡성, 리소스 사용량 증가, 다양한 설정 파일들(prometheus.yml, grafana dashboard JSON, loki 설정 등)의 관리 부담이 컸습니다. 모니터링 전용 EC2 인스턴스에서 CPU 60-70%, 메모리 2.5GB/3GB를 사용하며 상당한 리소스를 소모했습니다.

4. Elasticsearch 도입의 비용 부담

• 검색 기능을 위해 Elasticsearch를 도입했지만 실제 사용량 대비 리소스 소모가 과도했습니다. 최소 1GB 메모리가 필요하고 실제로 1.5GB/2GB(75%)를 사용했지만, 실제 검색 기능 활용도는 30% 정도에 불과했습니다. MySQL Full-text Search로 대체 시 추가 인프라 비용 없이 소규모 데이터셋에서는 충분한 성능을 얻을 수 있음을 확인했습니다.

5. 기존 기술 활용의 중요성

• 새로운 기술 도입보다는 기존 기술 스택 내에서 문제를 해결하는 것이 인프라 관리 관점에서 훨씬 효율적이었습니다. Spring Boot Actuator + 간단한 로깅, MySQL Full-text Search 활용 등 기존 기술로도 충분히 요구사항을 만족할 수 있었고, 인프라 단순성, 운영 부담 감소, 비용 효율성, 안정성 측면에서 더 나은 결과를 얻었습니다.

결과