나는 SQL을 싫어하지 않는다. 나는 메타데이터 마찰을 싫어한다.
Source: Dev.to
SQL 작성 자체는 어려워하지 않지만, 그 주변 모든 것이 어려워요. 여러분도 다 알죠:
- BigQuery 콘솔을 연다.
INFORMATION_SCHEMA위에 간단한 쿼리를 작성한다.- 파티션 컬럼을 빼먹은 것을 깨닫는다.
- 오래된 쿼리를 복사한다.
- 약간 수정한다.
- 또 다른 컬럼이 필요함을 깨닫는다.
- 문서를 연다.
- 답을 더 빨리 얻을 수 있는지 확인하려 Airflow로 전환한다.
- 다시 BigQuery 콘솔로 돌아간다.
- 무엇을 확인하려던 건지 잊어버린다.
이 중 어느 것도 어려운 일은 아니다. 단지 매일같이 반복되는 낮은 수준의 마찰일 뿐이다.
그래서 나는 그 마찰을 줄이기 위해 작은 무언가를 만들었다.
문제
- 최근에 스키마가 변경된 테이블은?
- 가장 많은 슬롯을 사용하고 있는 작업은?
- 어제 BigQuery가 느렸던 이유는?
- 왜 BigQuery 비용이 급증하고 있나요?
BigQuery는 INFORMATION_SCHEMA를 통해 많은 답을 제공하지만, 쿼리는 거의 사소하지 않습니다. 쿼리는 길고, 조인이 필요하며, 필드 이름을 기억해야 해서 작은 세부 사항을 확인하려고 문서를 계속 찾아보게 됩니다.
나는 메타데이터를 dbt로 모델링하기 시작했고, 다음과 같은 요약 테이블을 몇 개 만들었습니다:
- 작업
- 스토리지
- 스키마 변경
- 종속성
- 슬롯 사용
혁신적인 것은 아니고—내가 실제로 사용하는 방식대로 데이터를 구조화한 것뿐입니다. 도움이 되었지만, 여전히 같은 종류의 쿼리를 반복해서 작성하고 있었습니다.
LLM을 적용해 보았다
깨끗한 dbt 모델과 적절한 설명을 갖게 되자, 다음 단계가 명확해 보였다: SQL을 직접 작성하는 대신 질문만 하면 되지 않을까? 대부분의 BI 도구는 비즈니스 사용자를 위한 Text‑to‑SQL 솔루션을 내세우지만, 엔지니어에게도 적용되지 않을 이유가 있을까?
현재 설정
- dbt 모델은 BigQuery 메타데이터를 요약합니다.
- 데이터는 DuckDB에 동기화됩니다 (매번 BigQuery를 스캔하는 것을 피하고, 실시간 데이터에 LLM을 신뢰하지 않기 위해서입니다).
- 스키마 + 컬럼 설명을 LLM에 전달합니다.
- LLM이 SQL을 생성합니다.
- SQL이 DuckDB에서 실행됩니다.
- 결과는 작은 터미널 UI에 표시됩니다.
기본적으로 메타데이터와 “채팅”할 수 있는 TUI입니다.
실제 예시
한 주 동안 BigQuery가 매우 느리게 작동했습니다. 슬롯 경쟁이 있었을 가능성이 높았으며, 이는 아마도 그 주 초에 배포된 새로운 변환 때문에 발생했을 것입니다.
수동으로 조사하는 대신, 저는 다음과 같이 물었습니다:
why was bigquery slow this week?시스템은 슬롯 사용량과 장시간 실행되는 작업을 분석하여 6시간 후에 타임아웃되는 새로운 변환 모델을 찾아냈습니다. 담당 팀에 확인해 보니, 그들이 곧 수정하겠다고 했습니다.
몇 일 후 다시 물었습니다:
are the slot timeouts gone?그 결과 장시간 실행되는 작업이 사라졌음을 확인했습니다. 바로 그때 저는 이것이 초기 조사에 실제로 유용하다는 것을 깨달았습니다.
완벽하지는 않아요
즉시 몇 가지 문제가 발생했습니다.
- 긴 답변 – 간단한 질문조차도 과도하게 상세한 보고서를 생성했습니다. UI를 Fast와 Analytics 두 모드로 나누었습니다.
- 환각 – BigQuery 작업 ID가 UUID처럼 보입니다. 쿼리 결과가 정확했음에도 불구하고, LLM이 설명에 작업 ID를 만들어 내는 경우가 있었는데, 이는 받아들일 수 없습니다.
검증 단계를 추가해 보았지만, 토큰 비용이 급격히 증가했습니다. 현재는 원시 쿼리 결과와 요약만 반환하고 있습니다.
또한 LLM이 데이터를 조회하고, 해석한 뒤 다시 조회하는 식으로 무한 루프에 빠지는 상황도 겪었습니다. 다행히 크레딧이 $5밖에 없었기 때문에, 그 이후로 엄격한 사용 제한을 두었습니다.
왜 DuckDB인가?
주로 비용과 속도 때문입니다. 우연히 발생하는 비용이 많이 드는 스캔과 느린 반복 루프를 원하지 않았습니다. 그래서 관련 메타데이터를 DuckDB에 동기화하고 대신 그것을 쿼리합니다.
이 규모에서는 잘 작동하지만, 당연히 무한한 히스토리를 복제할 수는 없습니다.
이 도구가 실제로 무엇인지
이 도구는 BI나 관측 도구가 아닙니다. 반복적인 메타데이터 쿼리를 작성하지 않고도 운영 질문을 더 빠르게 할 수 있는 방법일 뿐입니다.
다음과 같은 경우에 사용할 수 있습니다:
- 1차 조사
- 정상성 검사
- 복사‑붙여넣기 SQL 방지
그게 전부입니다. 빠른 답변이 필요할 때 사용합니다.
replace proper analysis. But it lowers the activation energy. And that alone makes it useful.
오픈소싱?
저는 이것을 오픈소스화하는 것을 고려하고 있습니다. 현재는 BigQuery 메타데이터와 함께 작동하지만, 기술적으로는 적절한 테이블 정의만 있으면 어떤 BigQuery 데이터셋도 연결할 수 있습니다.
추가적인 데이터 엔지니어링 작업 메타데이터를 지원하기 위해 더 많은 시간을 투자하기 전에, 여러분의 의견을 듣고 싶습니다:
- 이런 것을 사용하시겠습니까?
- 이것이 여러분에게 실제로 불편함을 해소해 주나요?
- 무엇이 바로 사용 불가능하게 만들까요?
- 무엇이 이것을 필수품으로 만들까요?
관심이 있다면 레포지토리를 정리하고 오픈소스화하겠습니다.
제가 개인적인 관심사에 불과한지, 아니면 더 넓은 범위의 필요인지 검증하려고 합니다. 솔직하고 (혹독한) 피드백을 환영합니다.