Context
서버 단위로 애플리케이션, DB, 스토리지가 결합된 레거시 시스템은 장애가 나도 원인과 영향 범위를 설명하기 어려웠다. 확장과 복구 제약도 컸지만, 무엇이 실제 병목인지 측정할 수 없는 상태에서는 구조 개선 우선순위를 정하기도 어려웠다.
Decision
전체 구조 개선에 앞서, 시스템 지표와 서비스 이벤트를 함께 볼 수 있는 Observability 체계를 먼저 구축한다.
Alternatives
전체 재작성을 먼저 진행한다
Pros
- 구조 문제를 근본적으로 정리할 수 있다
Cons
- 운영 리스크와 전환 비용이 크다
- 현재 병목을 충분히 이해하지 못한 채 설계할 가능성이 있다
문제가 보이는 구간만 국소적으로 수정한다
Pros
- 즉시 대응이 빠르다
Cons
- 시스템 전체 병목을 설명하지 못한다
- 근거 없는 최적화가 반복될 수 있다
Reasoning
관측할 수 없는 시스템은 안정적으로 개선하기 어렵다. 먼저 장애 시점, 원인, 영향 범위를 설명할 수 있는 상태를 만들면, 이후 구조 개선도 우선순위와 효과를 더 명확히 판단할 수 있다. 운영 중인 레거시 시스템에서는 특히 이 순서가 중요했다.
이 결정의 핵심은 레거시 개선을 “구조 변경 프로젝트”가 아니라 “문제를 측정 가능한 상태로 만드는 작업”에서 시작했다는 점이다.
- 시스템 지표와 서비스 이벤트를 함께 본다.
- 장애를 설명할 수 있는 상태를 먼저 만든다.
- 그 다음에야 구조 개선 우선순위를 정한다.