실시간 대시보드보다 먼저 지켜야 할 것

한 내부 서비스의 현황판 요청은 처음에는 화면을 실서비스로 옮기는 일처럼 보였다. 그러나 목업 한 장에는 상담 상태, 근태, 영업 실적, 조직 매핑처럼 서로 다른 시스템의 값이 섞여 있었다. 화면을 만드는 것보다 누가 어떤 값을 책임지고, 그 조회가 핵심 업무에 어떤 부담을 주는지 정하는 일이 먼저였다.

특히 실시간이라는 요구가 문제를 키웠다. 최신 값을 보여주겠다고 상담과 계약을 처리하는 운영계를 계속 조회하면, 조회 기능이 본업의 지연 원인이 될 수 있다. 반대로 부하만 피하려고 복제된 데이터를 읽으면 갱신 시차와 정의 차이를 감수해야 한다. 이 선택은 단순한 연동 방식이 아니라 운영 책임의 경계를 정하는 일이었다.

문제를 다시 정의하기

핵심 문제는 대시보드 API를 어디에 만들지가 아니었다. 여러 부서가 같은 숫자를 보고 판단할 수 있으면서도 운영계의 안정성을 해치지 않는 읽기 구조가 필요했다. 상담 상태는 통화 시스템에, 근태는 인사 시스템에, 실적과 근무시간은 고객 관리 시스템에 있었다. 조직과 상담 대상을 잇는 매핑도 별도로 관리해야 했다. 어느 한 시스템을 진실의 원천으로 삼아 해결할 수 없는 구조였다.

지표 이름이 같아도 뜻은 달랐다. 기존 통계에서 유치로 보던 상태와 새 현황판이 유치로 삼으려는 상태가 달랐고, 취소율의 분모나 마진의 범위도 정해지지 않았다. 이 상태에서 구현을 서두르면 빠르게 만든 숫자가 조직마다 다른 해석을 굳힐 가능성이 컸다.

선택지를 나눈 기준

선택지는 운영계를 직접 조회하는 방식과 통계 저장소를 거치는 방식으로 나뉘었다. 판단 기준은 최신성 하나가 아니었다. 상담 업무에 미치는 부하, 장애가 번지는 범위, 여러 화면에서 정의를 재사용할 수 있는지, 그리고 누가 데이터 품질과 갱신 주기를 운영할지가 함께 고려 대상이었다.

운영계 직접 조회는 경로가 짧지만 대시보드 사용량이 본업의 처리량과 맞물린다. 통계 저장소를 쓰면 읽기 부하를 격리할 수 있는 대신 적재 주기와 누락을 관리해야 한다. 여기서는 초 단위 최신성보다 핵심 업무의 안정성과 지표 정의의 일관성을 우선하는 쪽이 맞았다.

내린 결정과 실행

결정 방향은 대시보드가 운영계를 직접 호출하지 않고 통계 저장소에서 읽도록 분리하는 것이었다. 필요하면 그 앞에 캐시를 두되, 고객 관리 시스템은 통계 저장소로 데이터를 보내는 역할까지만 맡는다. 아직 접근 권한이 제공되지 않아 실제 연동은 시작되지 않았다.

그전에 각 지표가 어떤 업무 상태와 시각, 담당자, 상품 분류를 기준으로 계산되는지 간접 매핑했다. 이는 확정된 설계가 아니라 관계 부서와 데이터 담당자가 답해야 할 질문을 구체화하는 작업이었다. 기존 화면이 이미 계산하는 통화 지표는 재사용 대상으로 남겨 중복 개발도 피하고자 했다.

결과와 남은 문제

현재 확인된 결과는 읽기 경로를 운영계에서 떼어낸다는 방향과, 통계 저장소에서 찾아야 할 데이터 후보가 정리됐다는 점이다. 서비스 제공이나 성과가 나온 단계는 아니다.

가장 큰 미결정 사항은 지표의 뜻이다. 유치로 인정할 업무 상태, 취소율의 기준 모수, 마진의 산식, 교차 판매의 귀속을 요청 부서와 데이터 담당자가 합의해야 한다. 센터별 열람 범위와 역할별 권한도 남아 있다. 통계 저장소의 갱신 주기와 누락 대응 주체까지 정해져야 운영 가능한 설계가 된다.

다음에 적용할 원칙

여러 시스템을 한 화면에 모을 때는 연결 방법보다 숫자의 계약을 먼저 적는다. 이름, 산식, 기준 시각, 귀속 주체, 예외 처리와 데이터 책임자를 합의해야 한다. 실시간성은 그 뒤에 필요한 수준을 정한다.

운영계를 보호하려고 읽기 경로를 분리했다면 복제 데이터의 시차와 품질도 누군가 맡아야 한다. 부하를 다른 곳으로 옮기는 것만으로 책임이 사라지지는 않는다. 되돌리기 어려운 것은 코드보다, 한 번 조직의 기준으로 굳어진 숫자다.