Lexega — SQL을 정적 분석해서 위험 시그널을 잡아내는 가드레일 도구

뭘 하는 건지

• SQL PR 리뷰할 때 "diff가 화면보다 큰" 상황, 다들 겪어봤을 거임. 테스트는 통과하는데 위험한 구문 하나가 슬쩍 빠져나가는 그 실패 모드를 잡기 위한 도구가 Lexega임
• 핵심 컨셉은 SQL을 실행하기 전에 결정론적(deterministic)이고 실행 가능한 "시그널"로 변환한 뒤, 정책(policy)으로 판단하는 것. SQL 가드레일 레이어라고 보면 됨

파이프라인 구조

• SQL 텍스트 → 렉서/파서 → 시맨틱 추출 → 시그널(카테고리/표면/조건) → 룰 매칭 → 정책 평가 → decision.json (allow/warn/block)
• 파이프라인의 어떤 부분도 확률적이지 않음. 같은 입력이면 항상 같은 시그널이 나옴. AI 생성 SQL이 늘어나는 상황에서 이 결정론성이 핵심 셀링 포인트임

인상적인 예시: CTE 경계를 넘는 컬럼 리니지 분석

• 멀쩡해 보이는 쿼리에서 LEFT JOIN + CTE 조합의 흔한 버그를 잡아냄:
  • CTE 안에서 LEFT JOIN으로 customers를 붙이고
  • 바깥 쿼리에서 WHERE tier = 'enterprise' 필터를 걸면
  • tier가 nullable 컬럼(customers 측)이라 LEFT JOIN이 사실상 INNER JOIN으로 변환됨
• 이걸 잡으려면 CTE 안의 LEFT JOIN에서 nullable 사이드 파악 → SELECT 리스트의 컬럼 출처 추적 → CTE 경계를 넘어 외부 쿼리까지 리니지 추적이 필요함. 단순 패턴 매칭으로는 불가능한 수준

시맨틱 Diff

• 텍스트 diff로는 "한 줄 바뀜"인 변경이 실제로 뭘 의미하는지 알려줌
• 예: JOIN 조건에서 customer_id가 billing_customer_id로 바뀌면 → "ORDERS와 CUSTOMERS 간 조인 조건이 변경됨"이라는 시맨틱 시그널을 뱉음

Jinja/dbt 지원

• dbt 프로젝트 안에서 실행하면 자동으로 Jinja 템플릿을 렌더링해서 분석함. ref(), source(), config() 해석 포함
• 같은 템플릿이라도 변수에 따라 리스크가 완전히 달라지는 걸 잡아냄:
  • safe_mode=false → DELETE FROM production.users; (WHERE 없음) → CRITICAL 시그널
  • safe_mode=true → DELETE ... WHERE created_at < ... → 시그널 없음

커스텀 룰 & 정책

• 빌트인 룰 수백 개 + YAML로 커스텀 룰 정의 가능. 플러그인이나 코딩 필요 없음
• 예: ANALYTICS.ORDERS ↔ ANALYTICS.CUSTOMERS 간 JOIN 타입이 INNER에서 LEFT/CROSS로 바뀌면 prod에서 차단하는 룰을 YAML 한 줄로 정의
• 빌트인 룰도 오버라이드 가능 — 예를 들어 swap-and-drop 패턴 쓰는 팀이면 SCHEMA-DROP 룰을 Critical에서 Low로 낮출 수 있음
• 정책은 환경별로 다르게 적용 가능: prod는 block, staging은 warn, dev는 allow

CI/CD 통합

• lexega-sql analyze로 CI에 게이트로 연결 가능. 환경 컨텍스트 + 정책 파일로 decision.json 산출
• 시그널(감지) → 룰(심각도) → 정책(조치) → 예외(감사 가능한 시간 범위 오버라이드)로 계층이 깔끔하게 분리되어 있음