실시간 대시보드가 운영 시스템을 직접 보지 않게 한 이유

한 내부 고객 관리 시스템에 두 종류의 실시간 현황판 요청이 들어왔다. 운영 조직은 조직별 통합 현황을, 영업 조직은 실시간 실적을 보고 싶어 했다. 내가 해결해야 했던 문제는 화면을 만드는 일이 아니라, 필요한 지표를 어디서 읽어 어떤 형태로 제공할지 정하는 것이었다.

요청대로 운영 시스템을 계속 조회하면 현황판 사용량이 운영 부하로 이어질 수 있었다. 반대로 통계 DB를 사용하려면 각 지표가 어느 데이터와 상태값에 대응하는지 먼저 확인해야 했다. 지표의 뜻이 조직마다 다르게 쓰이는 문제도 남아 있었다.

실제로 맡은 문제

내가 맡은 범위는 두 현황판에 필요한 고객 관리 지표를 제공하는 쪽이었다. 통화 관련 지표는 기존 현황판 시스템이 담당하고 있었으므로, 고객 관리 시스템이 제공해야 할 데이터와 그렇지 않은 데이터를 구분해야 했다.

동시에 운영 시스템과 현황판을 격리해야 했다. 화면 조회가 늘어나더라도 고객 관리 업무를 처리하는 서버에는 직접 호출이 발생하지 않는 구성이 목표였다.

확인한 사실과 제약

먼저 전달받은 정적 목업과 기존 현황판 코드를 검토했다. 이어 고객 관리 시스템의 코드를 간접적으로 분석해 요청된 지표가 어떤 테이블과 상태값에서 나오는지 연결했다.

이 과정에서 같은 표현을 서로 다르게 해석할 여지가 확인됐다. 예를 들어 영업 실적의 한 항목은 접수 대기 상태를 뜻하는지, 청약 대기 상태를 뜻하는지 정해지지 않았다. 정의가 달라지면 집계 대상도 달라지므로 코드부터 작성할 수 없는 상태였다.

통계 DB 접근 권한도 아직 확보되지 않았다. 조직 단위와 사용자 연결, 관리 책임자와 일반 사용자의 조회 범위 역시 추가로 정해야 했다.

내가 한 선택

데이터는 운영 시스템이 아니라 통계 DB에서 읽어 제공하기로 방향을 정했다. 기준은 명확했다. 실시간 현황판의 조회량이 고객 관리 업무를 처리하는 서버에 영향을 주지 않아야 했다.

화면 표시와 여러 데이터의 결합은 별도 계층에서 맡기고, 고객 관리 쪽은 확인된 지표를 API로 제공하는 범위에 집중하도록 나눴다. 다만 아직 정의가 충돌하는 지표는 임의로 확정하지 않았다.

실제로 한 일

두 요청의 목업과 기존 코드에서 필요한 지표를 추렸다. 고객 관리 코드에서는 각 지표의 원천 테이블과 상태값을 찾아 대응 관계를 정리했다. 통화 지표처럼 기존 시스템이 이미 담당하는 영역도 분리했다.

또 지표 정의를 확정하기 위한 질문을 정리했다. 특히 해석이 엇갈린 영업 실적 항목은 어느 상태를 집계할지 관계 조직이 확인할 수 있도록 쟁점으로 남겼다.

확인된 결과와 남은 일

운영 시스템을 직접 호출하지 않고 통계 DB를 거쳐 지표를 제공한다는 방향은 정해졌다. 지표별 데이터 출처와 상태값도 코드 분석을 통해 연결했다.

아직 API 연동을 시작한 것은 아니다. 통계 DB 접근 권한을 확보한 뒤 연동 계획을 세워야 한다. 해석이 충돌하는 지표의 정의, 조직과 사용자 연결 방식, 조회 권한 구분도 남아 있다. 이 항목들이 확정돼야 실제 집계 결과가 요청한 현황과 일치하는지 검증할 수 있다.