사내 IaC 템플릿의 리소스가 하나의 main.tf에 집중되어 있어 변경 시 영향 범위를 파악하기 어렵다고 판단했습니다. 네트워크·애플리케이션·데이터베이스 등 역할별로 Terraform 구성을 분리하고 OpenTofu 기반으로 재정비해 인프라 변경과 유지보수가 쉬운 구조로 개선했습니다.

Secrets Manager로 관리하던 RDS 비밀번호가 GitHub Actions 배포 과정에서 `.env`에 기록되고 Artifact에 포함되는 것을 확인했습니다. 비밀값이 CI/CD 산출물에 남지 않도록 애플리케이션 실행 시 Secrets Manager에서 직접 조회하도록 변경했습니다.

개발 환경에 Elastic Beanstalk·EC2·IAM Role 전반의 권한이 부여되어 있어 하나의 자격증명이 침해될 경우 영향 범위가 커질 수 있다고 판단했습니다. 실제 배포와 운영에 필요한 권한을 기준으로 IAM 정책을 재정비하고, 외부 요청도 ALB → Application Server → RDS 경로에서 필요한 통신만 허용하도록 Security Group을 구성했습니다.

Elastic Beanstalk 첫 배포가 완료되지 않는 상황에서 AWS 리소스 생성 문제인지 컨테이너 실행 문제인지 구분하기 위해 CloudFormation 상태부터 EB·컨테이너 로그까지 계층별로 확인했습니다. 이를 통해 인프라 생성은 정상임을 확인하고 nginx 설정과 Rust 빌드 산출물로 원인을 좁혀 배포를 완료했습니다.

홈서버에서 메일 발송까지 직접 운영하려 했지만, 주거용 인터넷 환경의 SMTP 포트 제한과 메일 서버 운영에 필요한 네트워크 조건을 확인했습니다. 메일 인프라까지 직접 관리하는 것은 운영 비용이 크다고 판단해, 메일 발송은 외부 SMTP에 위임하는 구조로 변경했습니다.

홈서버의 공인 IP와 관리 포트를 외부에 직접 노출하지 않기 위해 Proxmox와 서버 관리 접근은 Tailscale VPN으로 제한했습니다. 배포한 웹 서비스는 서버 포트를 직접 개방하지 않고도 인터넷에서 접근할 수 있도록 Cloudflare Tunnel을 통해 공개했습니다.

초기에는 로그인 이후에만 서비스를 확인할 수 있도록 구성했지만 실제 사용자들이 가입 단계에서 이탈하는 것을 확인해, 인증보다 서비스의 핵심 기능을 먼저 경험할 수 있도록 진입 흐름을 변경했습니다.

나라장터 첨부파일은 원본 URL이 만료되거나 접근이 제한될 수 있어, 모든 상세 데이터를 미리 적재하는 방식으로는 안정적인 문서 제공이 어렵다고 판단했습니다. 공고 목록만 주기적으로 수집하고 상세 정보는 조회 시점에 가져오도록 분리했으며, 첨부문서는 서버에서 수집해 S3에 재호스팅하여 원본 URL 상태와 관계없이 확인할 수 있도록 구성했습니다.

기존에는 Uptime Kuma로 서비스의 정상 동작 여부만 확인할 수 있어, 장애가 발생했을 때 어떤 컨테이너와 구간에서 문제가 생겼는지 파악하기 어려웠습니다. 이를 개선하기 위해 cAdvisor·Prometheus로 컨테이너 메트릭을, Loki로 애플리케이션 로그를 수집하고 Grafana에서 함께 확인할 수 있도록 모니터링 환경을 고도화했습니다.

기존 Docker 배포 과정에서 배포 실패나 컨테이너 교체 시 502 Gateway 오류가 발생해 사용자 요청이 영향을 받는 경우가 있었습니다. 새 버전의 정상 동작을 확인한 뒤 트래픽을 전환할 수 있도록 Blue-Green 배포 구조를 적용해 배포 과정의 서비스 중단 위험을 줄였습니다.

하나의 비즈니스 기능을 여러 솔루션에서 각각 구현하면 기능이 늘어날수록 동일한 로직을 반복 개발하고 검증해야 하는 문제가 생길 수 있다고 판단했습니다. 비즈니스 로직은 원본 서비스의 API를 그대로 호출해 재사용하도록 설계하고, 외부 솔루션의 안전한 API 호출을 위해 서비스 키·요청 시각·본문 해시를 조합한 HMAC-SHA256 서명 검증을 적용했습니다.

메인 화면 진입 시 약 60건의 콘텐츠 요청이 한꺼번에 발생해, 반복 새로고침 시 WAF에 차단되는 문제를 확인했습니다. 콘텐츠를 스크롤 위치에 따라 필요한 시점에 불러오도록 렌더링 구조를 개선해 초기 요청을 20건 미만으로 줄이고, 안정적인 콘텐츠 탐색이 가능하도록 최적화했습니다.

프론트엔드에 정적 데이터로 관리되는 콘텐츠를 매 검색마다 전체 순회하지 않도록, Bi-gram 토큰화와 Bitset 역색인을 활용한 클라이언트 검색 엔진을 직접 구축했습니다.

프론트엔드, API, 데이터베이스의 변경 주기와 장애 영향 범위가 서로 다르다고 판단해 Kubernetes 워크로드를 역할별로 분리했습니다. 사용자·관리자 프론트엔드는 하나의 앱 워크로드로, API는 별도 Pod로 구성하고 PostgreSQL은 데이터 영속성을 고려한 상태 저장 영역으로 분리했습니다.

GitHub Actions·Argo CD 기반 GitOps 흐름에 맞춰 Kubernetes Manifest와 이미지 태그를 관리하며 배포 변경사항을 반영했습니다. 또한 해당 경험을 GitOps와 Kubernetes 배포 관점에서 정리해 사내 개발자 발표로 공유했습니다.