[아키텍처] 이기종 데이터 통합 설계, 모니터링 통합에서 얻은 3가지 경계

문제 상황

• 멀티클라우드·컨테이너 확산으로 모니터링 소스가 늘어나고, 여러 이벤트를 한 곳에서 통합 처리해야 하는 요구 증가
• 새 소스를 붙일 때 수집은 쉽게 확장됐지만, 식별 키와 조회 화면이 코어에 직접 얽혀 영향 범위가 전역으로 번짐

원인 분석

• 수집은 추상 워커로 격리돼 있었지만 식별과 소비는 경계가 없어 변화가 쿼리와 화면 전반으로 전파
• IP 기반 식별에 의존하던 구조에 이름+리전 같은 다른 키가 들어오며 조회 로직 전체가 흔들림

해결 방법

• 수집·식별·소비를 각각 Source Adapter, Entity Resolver, Read Model 경계로 분리해 변화 흡수 지점 명확화
• 단조 증가 커서 기반 Pull, 공통 필드+JSONB 분리, 개별 UNION 같은 방식으로 공통화 범위를 의식적으로 조정

주의할 점

• 전면 공통화보다 자주 바뀌는 지점만 경계로 묶고, 컨텍스트가 다른 조회는 개별 대응으로 남겨두기
• 인터페이스 계약, 코드값 사전, 문서-구현 정합, 매칭 실패 데이터의 운영 가시화 필요

적용해볼 점

• 새 소스나 새 식별 키를 받을 때 변화가 어느 경계에서 흡수되는지 먼저 점검
• 기존 시스템은 가장 자주 바뀌는 지점부터 얇은 경계를 끼워 넣는 점진적 개선이 유효