2025.07.17
기술뿐 아니라 운영과 협업까지 포함한 구조적 전환 경험
기능이 아니라 흐름이 보이지 않는 구조가 문제였습니다
모놀리스 서비스 기능이 단일 흐름으로 묶여 장애가 전체로 확산
동일한 엣지 구성 모든 사이트에 같은 엣지를 배포해야 했고 네트워크·센서·운영정책의 차이를 반영할 수 없었음
REST API 기반 로그 엣지와 서버 간 연결이 끊기면 상태 기록 자체가 불가
방화벽·라우터에 의해 엣지 접근 불가 운영자가 엣지 상태를 직접 확인할 수 없음
연결 오류에 대한 복구 부재 요청 실패 시 자동 재시도도, 오류 알림도 없음
문제 발생 시 로그 탐색 요청 ID도, 흐름 단서도 없어 시간 역추적에 의존
이런 상황에서는 구조적으로 흐름을 다시 설계해야 했습니다
전환 전략:
기술의 장점보다, 운영이 쉬워진다는 메시지를 반복했습니다
기술보다 흐름을 설계하는 데 익숙한 경험이 도움이 됐습니다
→ 재처리 전략, 모니터링 지표 필요
→ timestamp 등 명시 필요
timestamp
→ trace ID, requester ID, 메시지 구조화 필요
trace ID
requester ID
메시지 구조는 설계 없이는 오히려 혼란을 만듭니다
action_duration_time
heartbeat
request_id
request_code
response_code
지표는 모니터링이 아닌 구조의 일부로 설계했습니다
기능 중심의 Topic 네이밍 구조:
device.
service_platform.
data_core.
3rd_party.
단순한 카테고리 분류가 아닌 서비스 해석 언어
팀 간 협업 기준을 통일하는 문법적 기반
구조를 읽는 언어가 생기자 협업도 쉬워졌습니다
기술 전환보다 운영 구조 재설계가 핵심이었습니다
설계란, 기술과 협업을 함께 설계하는 일입니다