| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
- vue life cycle
- 빌드
- VUE
- aop
- java version
- Spring AOP
- Java
- 자바 버전
- github
- 개발자
- transaction
- 백엔드
- ETL
- 비동기통신
- RequestBody
- 프론트엔드
- axios
- RequestParam
- docker
- git push
- 도커
- fetch
- Vue.js
- GIT
- maven
- gradle
- PathVariable
- 트랜잭션
- Airflow
- Today
- Total
미소의 세상
루커대시보드 본문
시작하며
시각화 도구 Looker Studio. 백엔드 개발자 입장에서 "이게 왜 이렇게 동작하지?" 싶었던 것들 위주로 정리한다.
Looker Studio가 하는 일
Looker Studio는 구글에서 제공하는 무료 BI(비즈니스 인텔리전스) 도구다. BigQuery 같은 데이터 소스에 연결해서 표, 차트, 대시보드를 만들 수 있다.
백엔드 개발자 관점에서 제일 헷갈렸던 건, "데이터 소스"라는 개념이 두 가지 방식으로 존재한다는 점이었다.
- 테이블 직접 연결: BigQuery 테이블 하나를 그대로 연결하는 방식. Looker Studio가 알아서 SELECT * 비슷하게 긁어옴
- 커스텀 쿼리 연결: 직접 짠 SQL(주로 CTE로 여러 단계 가공한 쿼리)을 등록해서, 그 쿼리 실행 결과를 데이터소스로 쓰는 방식
실무에서는 후자를 훨씬 많이 쓰게 된다. 원본 테이블을 그대로 노출하기보다는, 미리 가공된 지표(전환율, 잔존율 등)를 커스텀 쿼리로 계산해서 넣어주는 게 대시보드 관점에서 훨씬 유용하기 때문이다.
계산된 필드 - 여기서 자주 하는 실수
Looker Studio는 SQL을 안 고쳐도 화면단에서 "계산된 필드(Calculated field)"를 만들 수 있다. 예를 들어 "A값 대비 B값의 비율"을 보여주고 싶을 때, SQL을 수정하는 대신 계산된 필드로 처리 가능하다.
비율 = SUM(B값) / SUM(A값)
여기서 진짜 자주 하는 실수가 있다. 비율을 백분율로 보여주고 싶어서 수식에서 * 100을 곱하고, 스타일 설정에서 "백분율" 서식까지 같이 적용하면 값이 100배로 부풀려진다.
수식: SUM(B값) / SUM(A값) * 100 → 결과값 예: 1.8
서식: 백분율(Percent) 적용 → 화면 표시: 180% (틀림!)
* 100을 곱하는 것과 "백분율 서식"을 적용하는 것 중 딱 하나만 해야 한다. 둘 다 하면 이중으로 곱해져서 엉뚱한 숫자가 나온다. 개인적으로는 수식에서 곱하기 없이 0~1 사이 값 그대로 두고, 서식만 백분율로 지정하는 방식을 선호하게 됐다 — 수식이 더 단순해서 나중에 봐도 헷갈리지 않는다.
서로 다른 데이터소스끼리는 직접 계산이 안 된다
계산된 필드는 같은 데이터소스 안 필드끼리만 연산이 가능하다. "데이터소스 A의 값 ÷ 데이터소스 B의 값" 같은 계산을 하려면 계산된 필드로는 불가능하고, 데이터 혼합(Blending)이라는 별도 기능을 써야 한다.
데이터 혼합은 두 개(또는 그 이상) 데이터소스를 공통 키(보통 날짜) 기준으로 조인해서 하나의 혼합 데이터소스로 만드는 기능이다. SQL의 JOIN이랑 개념은 같은데, UI로 조인 조건을 설정한다는 게 다르다.
여기서 주의할 점 하나: 조인 조건(병합 조건)에 실제 값(측정항목)까지 넣으면 안 된다. 조인 조건에는 오직 "이 두 표를 어떤 기준으로 매칭할지"를 정하는 키(예: 날짜)만 들어가야 한다. 비교하려는 값 자체를 조인 조건에 넣으면, 그 값이 정확히 같아야만 매칭되는 이상한 조인이 되어버린다 — 원래 서로 다른 값을 비교하려던 건데, 조인 조건에서부터 "값이 같아야 매칭"으로 걸어버리면 앞뒤가 안 맞는 상황이 된다.
❌ 잘못된 병합조건: 날짜 = 날짜 AND 측정값 = 측정값
✅ 올바른 병합조건: 날짜 = 날짜 (이것만)
필드 표시이름과 실제 컬럼명이 다를 수 있다
Looker Studio는 필드마다 "표시 이름(라벨)"과 "원본 SQL 컬럼명"을 따로 관리할 수 있다. 누군가 필드 이름을 한글로 예쁘게 바꿔놨거나, 여러 번 쿼리를 수정하면서 필드가 재생성되는 과정에서 예전 이름이 그대로 남아있는 경우가 있다.
이게 헷갈리는 이유는, 화면에는 똑같은 이름으로 두 개가 보이는데(예: 새로 추가한 필드와 예전 필드가 같은 라벨을 쓰는 경우) 실제로는 서로 다른 SQL 컬럼을 가리키고 있을 수 있기 때문이다. 이럴 땐 값 자체를 비교해보는 게 제일 확실하다. 예를 들어 특정 조건에서만 값이 0이어야 하는 필드라면, 실제로 그 조건에서 0이 나오는지 확인해보면 어느 게 진짜인지 구분할 수 있다.
"차트 구성 미완료" 에러가 뜰 때
측정기준, 측정항목 또는 필터가 잘못되었거나 누락되었습니다라는 에러는 정말 자주 만나게 되는데, 원인은 거의 항상 같다 — 차트나 필터 컨트롤이 참조하던 필드가 데이터소스 재연결 과정에서 사라지거나 다른 필드로 바뀌었다는 것.
디버깅 순서:
- 에러 난 요소를 정확히 클릭해서 선택
- 우측 설정 패널에서 측정기준/측정항목/필터 칸을 하나씩 확인
- 빨간색으로 표시되거나 "필드를 찾을 수 없음"이라고 뜨는 칸을 찾는다
- 그 칸을 유효한 필드로 재선택
- 재선택해도 안 바뀌면 새로고침을 한 번 해준다 (재선택 직후 화면 반영이 안 되는 경우가 있었다)
오늘의 결론
Looker Studio는 코드를 거의 안 짜도 되는 도구라서 쉬워 보이지만, 실제로는 "SQL로 처리할 부분"과 "화면(계산된 필드, 데이터 혼합)에서 처리할 부분"을 구분하는 감각이 필요했다.