개발자
통계 화면마다 SQL과 차트 코드를 새로 짜지 않습니다.
제품이 아직 못 하는 일을 맡습니다. 새 원천 종류의 커넥터, 포털과의 연결(권한·감사·통지 어댑터)이 그 일입니다.
고객사 포털의 통계·대시보드·관제 화면을, 화면마다 SQL과 차트 코드를 새로 짜지 않고 한 번 정해 둔 데이터 정의 위에서 설정으로 만들고 운영하게 한다.
지금은 통계 화면 하나를 더하려면 개발자가 원천을 읽는 배치, 집계 SQL, 화면과 차트 코드를 매번 새로 만듭니다. 같은 이름의 숫자가 화면마다 다르게 계산되기 쉽고, 수집이 멈춰도 화면은 마지막 숫자를 그대로 보여 줍니다. Data Studio는 연결부터 대시보드까지를 다섯 단계로 나누고, 숫자의 정의를 데이터셋 한 곳에 둡니다.
새 통계를 화면에 띄우기까지 누가 무엇을 하는지, 기존 방식과 나란히 놓았습니다.
이미 조회할 수 있는 DB나 Prometheus는 2·3단계를 건너뛰고 바로 데이터셋을 만듭니다. 처음부터 다섯 단계를 다 채워야 화면을 볼 수 있는 구조는 아닙니다.
통계 화면마다 SQL과 차트 코드를 새로 짜지 않습니다.
제품이 아직 못 하는 일을 맡습니다. 새 원천 종류의 커넥터, 포털과의 연결(권한·감사·통지 어댑터)이 그 일입니다.
원천 필드를 화면마다 다시 해석하지 않습니다.
연결·수집·저장을 설정하고, 숫자의 뜻을 데이터셋으로 정의해 게시합니다. 바꾸기 전에 어떤 차트가 영향을 받는지 봅니다.
차트 하나 때문에 개발을 요청하지 않습니다.
게시된 데이터셋의 필드를 끌어 놓아 차트를 만들고 대시보드에 배치합니다. 고를 수 있는 것은 허용된 집계뿐입니다.
숫자가 맞는지를 문의로 확인하지 않습니다.
홈의 "지금 확인할 것"과 관제 화면에서 지연·실패·알림을 봅니다. 실패한 행은 허용된 범위에서 다시 처리합니다.
샘플은 화면 설계 v3.1의 설계 화면입니다. 아직 구현한 화면이 아니고, 화면 속 숫자는 설명용 가상 데이터입니다. 화면을 누르면 전체를 크게 볼 수 있습니다.
숫자가 지금 값입니다. 여기까지는 두 화면이 같습니다.
마지막 반영 시각이 붙어 있어 지금 값이라는 것을 압니다.
설명용 모형입니다. 문구는 관제 화면 설계(DSH-04)의 위젯 상태를 그대로 옮겼습니다.
비교 대상: Grafana·Metabase·Superset 같은 도구를 별도 서버로 설치하고, 포털에는 iframe이나 링크로 붙이는 방식
둘 다 DB를 연결해 차트와 대시보드를 빠르게 만들 수 있습니다. 차트 종류와 편집 기능의 폭은 오래 다듬어진 BI 도구가 더 넓고, 인프라 관제는 Grafana가 강합니다. Data Studio도 기능을 정할 때 이 제품들을 주 벤치마크로 삼고, 기능 목록을 대조표로 만들어 따라갑니다.
갈리는 곳은 차트를 그리는 기능보다 그 앞뒤입니다. 누가 로그인과 권한을 맡는지, 내부망에 무엇을 들이는지, 숫자의 정의를 어디에 두는지입니다.
| 질문 | BI · 관제 도구를 따로 설치 | 키위즈 DATA STUDIO |
|---|---|---|
| 로그인과 권한은? | 도구마다 계정과 권한을 따로 둡니다. 포털과 맞추려면 SSO나 권한 동기화를 따로 만듭니다. | 포털의 로그인과 메뉴 권한을 그대로 씁니다. 권한 매핑이 없는 행위는 거부합니다. |
| 내부망에 무엇을 들이나? | 별도 서버 제품과 그 의존성을 통째로 들입니다. | 포털에 의존성으로 추가합니다. 새 런타임 패키지는 백엔드 1개, 프런트 3개입니다. |
| Tibero를 쓰는 고객사라면? | 검토한 도구 중 Tibero를 공식 지원하는 것이 없습니다. | Oracle·Tibero·MariaDB용 SQL을 직접 만듭니다. Tibero 세부 구문은 M1에서 확인 |
| 납품물에 넣을 수 있나? | Grafana·Metabase는 AGPL, Airbyte 커넥터는 ELv2라 납품물에 넣기 어렵습니다. | 자체 구현이라 넣을 수 있습니다. 가져다 쓰는 것은 ECharts와 Caffeine 정도입니다. |
| 데이터를 모으는 일은? | 대개 이미 있는 DB를 조회만 합니다. 수집 배치는 따로 만듭니다. | 연결 → 수집 → 저장을 한 제품에서 하고, 실행 이력과 실패 행 재처리까지 같이 봅니다. |
| 숫자의 정의는 어디에? | 도구 안에 지표 기능이 있어도, 포털의 다른 화면과는 따로 관리됩니다. | 데이터셋 한 곳에 두고 게시 버전으로 관리합니다. 바꾸기 전에 영향받는 차트·알림을 봅니다. |
Data Studio는 아직 설계 단계입니다. 아래 "다음"은 모두 계획이며 아직 하지 않은 일입니다.
지금화면 설계 v3.1(화면 44장)과 개발 아키텍처까지 있고, 코드는 아직 없습니다.
다음첫 목표는 DB 연결 1개 → 데이터셋 1개 → 차트 1개를 포털 메뉴에서 여는 수직 연결(M1)입니다.
지금참조 포털의 프런트와 백엔드가 인증 방식과 응답 형식을 서로 다르게 쓰고 있습니다.
다음M0에서 한쪽으로 맞춥니다. Studio API는 두 형식을 모두 낼 수 있게 만듭니다.
지금수집 커넥터는 REST 페이지 수집 하나로 시작합니다(M4). 그 전 단계는 이미 조회할 수 있는 DB만 씁니다.
다음Prometheus 직접 조회와 실시간 전달은 M6, JDBC 증분은 M7에서 더합니다. 그 밖의 원천은 커넥터를 개발해 붙입니다.
지금성능 목표는 측정 전 후보값입니다. 실측한 것은 차트 엔진 번들 크기뿐입니다.
다음 확인할 것M7에서 벤치마크 시나리오로 재고, 목표를 통과해야 끝납니다.
설정으로 되는 범위등록된 데이터·집계·차트 유형 안에서의 조합입니다.
계속 개발이 필요한 것수집하지 않은 데이터, 새 프로토콜, 새 차트 문법은 설정만으로 해결되지 않습니다.
단계마다 완료 조건을 통과해야 다음 단계를 시작합니다. 기간은 팀 구성과 원천 접근이 정해진 뒤 산정합니다.
로그인 → 메뉴 → 보호 API까지 기존 화면에서 동작. 401은 세션 만료, 403은 권한 없음으로 구분.
DB 연결 1 → 데이터셋 1 → 막대 차트 1. 연결 풀을 새로 만들지 않고, 권한 범위가 다른 사용자의 결과·캐시를 나눔.
DAT-05 · DAT-02 · DAT-03데이터셋·차트 화면을 포털 메뉴에 연결. 직접 주소·새로고침·뒤로 가기가 동작.
필드를 지우면 게시 차단, 이름만 바꾸면 호환, 기존 대시보드는 v1을 계속 봄.
DAT-04 · DSH-02 · CMN-01같은 데이터를 두 번 수집해도 건수가 그대로, 실행 중 꺼졌다 다시 켜도 대사가 맞음.
SRC-02 · ING-02~05 · STO-05재처리는 실패한 행만, 성공한 행은 다시 더하지 않음. 보존 기간 축소는 승인을 거침.
OPS-01~03 · STO-03 · HOME-01유지시간·제외 구간·복구, 재전송 중복 억제. Prometheus 직접 조회와 관제 화면(TV).
ALT-01~04 · DSH-04 · SRC-05두 번째 원천과 두 번째 포털을 코드 수정 없이 설정·어댑터로 연결. 벤치마크 목표 통과.