경보가 없으면 사고가 없는 것이 아니라,
보이지 않을 뿐이다

1. 시작점: 조용한 시스템

합류했을 때 이 서비스의 알림은 서버가 죽었는지를 알리는 경보 하나가 전부였습니다. 애플리케이션 로그는 관측을 전제로 설계돼 있지 않았고, 대시보드는 없었습니다. 시스템은 조용했습니다. 문제는, 조용한 이유를 아무도 설명할 수 없었다는 것입니다.

2. 가시화: 들을 귀부터 만들기

기능 개발보다 로깅을 먼저 손봤습니다. 관측 가능한 로그를 심고, 그 위에 CloudWatch 메트릭 필터와 경보 39개, 대시보드 12개를 Terraform 코드로 구축했습니다. 체계가 서자마자 결과가 나왔습니다. 경보 없이 쌓여 있던 누적 에러 226,012건이 드러났고, 분류해 보니 단일 근본원인이 65%였습니다.

3. 발견: 동시 접속 다섯에 무너지는 서버

대시보드에 잡힌 가장 위험한 신호는 메모리였습니다. 동시 접속이 한 자릿수인데 메모리 점유율이 급등해 프로세스가 넘어지는 패턴이 보였습니다. 인메모리로만 들고 있던 캐릭터 기억 데이터가 eviction 없이 무한 증가하는 구조였고, 로컬 측정에서는 12분 만에 170개가 1,554개로 불어나며 메모리를 밀어냈습니다. 상태가 전부 프로세스 안에 있으니, 프로세스가 죽으면 사용자 데이터도 함께 사라질 수 있는 구조적 위험이 있었습니다.

4. 재현: 고치기 전에 증명하기

바로 고치지 않고 k6로 같은 붕괴를 재현했습니다. 20VU에서 p95 90ms로 버티다가 50VU에서 붕괴하는 지점을 실측으로 확정하고 나서야, 원인이 추정이 아니라 사실이 됐습니다. 이 숫자는 이후 인스턴스 사이징과 확장 설계의 근거가 됐습니다.

5. 재설계: 상태를 프로세스 밖으로

인메모리 상태를 RDS(PostgreSQL)와 DynamoDB로 영속화하고, RAM에는 상한이 있는 워킹셋만 남겼습니다. append 전용 쓰기와 recency 복합 인덱스, UPSERT 멱등 쓰기로 엔진의 읽기·쓰기 패턴을 감당하게 설계했고, 전환은 기능 플래그로 경로를 나눠 단계적으로 진행해 중단 없이 넘어갔습니다.

6. 시험대: 트래픽 10배

마케팅으로 트래픽이 일 최대 7만 요청까지 10배 급증했을 때, 서비스는 에러율 0.008~0.05%, 응답 p95 0.3초로 받아냈습니다. 개선 전 나쁜 날의 에러율이 최대 2.9%였으니 30배 이상의 차이입니다. 동시 활성 세션은 한 자릿수에서 세 자릿수 피크까지 무중단으로 올라갔습니다.

7. 배운 것