Project Detail
레거시 백엔드 프로덕션 준비도 감사 · 리팩터링 로드맵 설계
런칭을 앞둔 백엔드를 운영·보안·데이터·성능 전반에 걸쳐 전수 감사(14개 트랙·60+ 발견)하고, 이를 단계(Phase)×의존성×위험도로 묶은 단일 실행 로드맵(P0~P10)으로 설계한 프로덕션 준비도 문서(감사 42KB + 마스터 플랜).
Headline Result
트랙 · 60+ 발견 (심각도·file:line·수정안 매핑)
- 기간
- 2026.06 - 2026.07
- 역할
- 백엔드 기술자문 · SRE · 감사/리팩터링 설계 리드
- 참여 멤버
- 김남해
결과 지표
- 14개트랙 · 60+ 발견 (심각도·file:line·수정안 매핑)
- P0~P10 단일 실행 로드맵
- OOM 근본원인 구조적 규명 + 회귀 그물 게이트
Problem → Solution → Outcome
메모리 관리가 없는 이식 엔진에서 반복 OOM·데이터 손실 위험이 있었고, 발견들이 흩어져 '무엇부터 어떤 순서로'가 불명확했다. 리팩터링이 기존 동작을 깨뜨릴 리스크도 컸다.
- 1
OOM 근본원인을 'eviction/TTL 부재 → 세션 무한 누적 → OOM-killer SIGKILL'의 구조적 귀결로 규명(로컬 측정: 기억 배열 12분간 170→1554개)
- 2
14개 트랙(MEM·RES·AWS·SEC·PERF·CICD·DB·OBS·PRIV·API 등) 60+ 발견을 각 심각도·file:line·수정안으로 매핑
- 3
P0 안전망(코드 변경 0 골든 스냅샷 회귀 그물, 불변식 #0) → OOM 직격 → 데이터 손실 차단 → 관측성 → 런칭 게이트 → 배포 기반 → 스키마·DSL·성능 순의 P0~P10 로드맵 설계
- 4
엔진 AS-IS/TO-BE와 polyglot persistence(PG/Mongo/Redis) 데이터 아키텍처 재설계안을 behavior-preserving 게이트 위에서 증분 적용하도록 계획
- ✓
감사에서 지목한 OOM 근본원인(기억 배열 무한증가, 12분 170→1554개)을 RAM 워킹셋 + RDS append 영속화로 실제 구현·해소
- ✓
'첫 주에 할 것'(안전망·1줄짜리 큰 해소·세션 eviction)까지 우선순위화해 팀이 바로 착수 가능한 실행 계획 확보
- ✓
리팩터링을 회귀 없이 진행하기 위한 골든 스냅샷 머지 게이트(불변식 #0) 도입
기술 스택
Frontend
DB / Infra
Etc