스케줄러와 API에 흩어진 구독 로직의 상태 모호성과 예외를 방지하기 위해, 4개 상태와 8개 이벤트의 상태 머신으로 정형화해 복잡한 결제 규칙을 단순화했습니다.

결제·환불 판단 로직에서 데이터베이스와 결제 대행사(PG) 연동을 분리하여, 시간 대기 없이 156개의 예외 및 환불 케이스를 0.91초 만에 확인하는 자동 테스트를 구축했습니다.

상태 머신 기반 검증을 통해 좌석 증설 시 환불 계산 오류와 스케줄러 복구 시 발생할 수 있던 이중 청구 위험을 출시 전 조기에 발견하여 수정했습니다.

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

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

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

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

기존 데이터를 그대로 이전하는 것보다 이후 운영과 유지보수 비용을 줄이는 것이 중요하다고 판단해, 마이그레이션 과정에서 사용되지 않는 컬럼과 중복 데이터를 함께 정리했습니다.

신청 과정에서 인증·임시저장·제출·결제마다 필요한 데이터와 저장 시점이 다르다고 판단해, 인증 정보와 작성 중인 신청서, 제출이 완료된 신청서를 분리해 관리하도록 설계했습니다.

경연곡을 저장할 때 최대 20번의 개별 API 요청이 발생하는 구조는 일부 요청만 실패할 경우 데이터 정합성을 보장하기 어렵다고 판단했습니다. 이를 bulk-save API 한 번으로 통합하고 트랜잭션으로 전체 작업의 성공과 실패를 묶어, 중간 데이터가 남는 문제를 방지하고 저장 대기 시간도 줄였습니다.

DB 레코드와 S3 첨부 파일을 함께 삭제하는 과정에서 두 작업을 완벽하게 원자적으로 처리할 수 없기 때문에, 어떤 데이터를 우선적으로 보장할 것인지가 중요했습니다. 서비스의 기준 데이터인 DB 삭제를 먼저 확정하고 파일 정리는 후속 작업으로 분리해, 파일 삭제 실패가 핵심 데이터의 삭제까지 막지 않도록 설계했습니다.

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

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

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

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