Hacker News 화제: 대규모 CI 로그 웨어하우스에서 SQL 기반 LLM 디버깅 접근 부상

Hacker News에서 주목된 내용

Mendral의 글 “LLMs Are Good at SQL. We Gave Ours Terabytes of CI Logs.”는 크롤링 시점에 191점, 댓글 97개를 기록했다. 핵심은 선언이 아니라 운영 사례다. 글에 따르면 내부 에이전트가 SQL을 직접 작성해 대규모 CI 데이터를 순차 탐색했고, 3주 전 dependency bump가 flaky test의 원인이라는 결론을 수초 내 도출했다.

아키텍처 선택의 의미

해당 글은 에이전트에 좁은 전용 API를 주기보다, 조직 범위로 제한된 SQL 인터페이스를 노출한 이유를 설명한다. 정해진 함수 집합보다 SQL이 예측하지 못한 질문까지 처리할 수 있어 root-cause 분석에 유리하다는 주장이다. 공개된 규모는 주당 약 15억 CI 로그 라인과 70만 잡이며, 데이터는 ClickHouse에 저장되고 압축 비율은 35:1로 제시됐다.

또한 8,534개 세션과 52,312개 쿼리 분석 결과를 함께 제시했다. 글에 따르면 에이전트는 먼저 job metadata 뷰로 범위를 좁히고, 이후 raw log line으로 내려가 증거를 확인하는 패턴을 보였다. 지연시간은 metadata 쿼리 중앙값 20ms, raw log 쿼리 중앙값 110ms로 보고됐으며, 수십억 행 스캔은 더 오래 걸리지만 완료 가능하다고 설명한다.

저장 구조와 트레이드오프

눈에 띄는 지점은 강한 비정규화다. 각 로그 라인에 48개 메타데이터 컬럼을 붙였고, 행 기반 저장소라면 비용이 크지만 컬럼형 압축에서는 반복 값 덕분에 효율이 나온다는 논리다. 문서 수치는 비압축 5.31 TiB를 디스크 154 GiB로 줄였다고 밝힌다. 정렬 키 설계, bloom/ngram 계열 인덱스, materialized view가 성능 핵심으로 제시됐다.

실무 관점 시사점

이 사례는 LLM 운영 자동화의 성패가 프롬프트보다 데이터 평면 설계에 더 크게 좌우된다는 점을 보여준다. 즉 SQL 같은 표현력 있는 도구를 제공하되 테넌트 범위를 강하게 제한하고, 탐색형 질의를 버틸 관측 데이터 저장소를 먼저 갖추는 전략이 중요하다는 메시지다.

Hacker News thread | Original article