텍스트에서 SQL로의 전환의 궁극적인 목표에 대한 고민이 있음, 데이터 분석가의 도우미를 만드는 것인지, 아니면 분석가를 거치지 않고 비즈니스 인사이트를 얻는 것인지가 목적임, 만약 두 번째라면 아무리 고도화되어도 비전문가가 SQL의 정확성과 충분함을 판단하는 것이 불가능한 문제임, "왜 어제 전자상거래 거래가 80%에 머물렀는가?", "고객 획득 비용이 왜 오르는가?", "뉴욕 캠페인이 샌프란과 비교해 왜 더 안 좋았는가?"와 같은 질문은 text2sql의 범주를 벗어나는 질문임
실제로는 두 번째 목적에 가깝다고 보지만, 결과물은 기대에 미치지 못함, 비즈니스에서는 보고서를 마지막에 변경하고 싶어하지만 분석가 부족으로 원하는 정보를 적시에 얻지 못함, "무한 속도"로 해결하려 하지만, 실제로 문제는 메트릭에 대해 충분히 고민하지 않는 데서 발생함, 데이터가 복잡하고 비즈니스 지식이 외부에 암묵적으로 저장되어 있으며 데이터 인프라가 부족해서 분석에 시간이 오래 걸림, 똑똑한 분석 리더들은 AI 열풍을 이용해 기본 인프라에 투자함
위의 질문들은 애초에 SQL로 풀 수 있는 문제가 아니라고 봄, SQL은 주로 "무엇(what)"에 대한 답변을 제공하는데, "왜(why)"에 답을 하지는 않음, 텍스트2SQL의 목표는 분석가가 "무엇"을 빠르게 해내도록 시간을 줄이고, 그렇게 해서 "왜"에 집중하도록 돕는 것임
맞는 말이지만, 내 생각에는 자연어 텍스트가 LLM 시스템의 보편적 입력이 될 수 있다고 생각함, text2sql은 더 복잡한 질문의 답을 구성하는 정보 검색의 기반 역할을 할 수 있음, 단기적으로는 업무 보조 기능이지만 장기적으로는 자동화, 결과 비교, 더 큰 워크플로우로 통합하는 기초를 쌓는 게 목표임, 이런 질문에 답하는 기반 마련이 핵심임, 아직 할 일이 많음
어떤 알고리즘도 사람이 할 수 있다면 만들고 테스트할 수 있음, 10명의 분석가가 있다면 데이터베이스와 비즈니스에 대한 이해도, 실력이 모두 다름, 자동화는 최소한의 실력과 지식을 보장하는 표준을 제공함, 새로운 분석가도 바로 더 나은 성과를 냄, 시스템을 전문가와 협력해 개발하면서 테스트하고, AI가 트레이드오프, 버그, 기대 결과와 비교해 해석하도록 하는 것이 유용한 목표임, 통찰력이나 ‘테이스트’는 자동화하기 어렵지만 도메인 전문가가 잘 설계된 자동화와 합리적 결과의 감각만 있다면 아주 멀리 갈 수 있음, 완벽하진 않지만 이런 것들이 내 목표임
OpenAI 4o 모델을 사용해 본 경험 공유, 비즈니스 지침, 업계 용어, 테이블과 외래키 설명을 함께 프롬프트에 전달함, 그러면 복잡한 조인 쿼리도 생성하고 결과를 반환함, SQL을 모르는 사용자를 위한 결과 제공이 목적이었지만 SQL 자체도 참고로 같이 보여줌
AI가 완벽한 SQL을 생성할 필요는 없음, 내 경우에는 출력물이 코드로 검증이 되더라도 미세한 의미 차이의 위험 때문에 복사해서 쓰진 않음, 대신 AI가 접근법을 제시해주면 그걸 참고해 직접 SQL을 처음부터 작성함
Google AI Studio의 최신 Gemini를 사용해 본 경험, 정말 놀랄 정도로 인상적이고 혁신적임, Claude와 ChatGPT의 코딩 결과는 마치 다른 세기에서 온 것처럼 느껴짐, 불과 한 달 전만 해도 Claude가 굉장하다고 생각했는데 지금은 Google Gemini 없이 어떻게 계속 코딩을 할 수 있을지 모르겠음, Gemini AI Studio는 프로그래밍에서 거대한 도약임
더 많은 사람들이 아직 이 변화를 인식하지 못해 놀라움, Claude도 작은 작업은 잘 처리하지만 복잡한 문제로 발전하면 Gemini가 월등히 앞서감, 컨텍스트 핸들링 능력이 특히 인상적임, 나는 코딩 에이전트로 사용할 뿐만 아니라 85,000단어짜리 원고에 대한 베타 리딩에도 Gemini를 쓰고 있고, 전문가 수준의 피드백 리포트를 거의 실시간으로 받음
이번 주에 무료 Gemini Pro에서 추론 모드를 비활성화한 것 같다는 느낌이 듦, 코드 작성 직전에 멈추거나 지나치게 일반화시키지 않도록 하면 상당히 유용함, 다만 Gemini는 코드를 과하게 작성하는 경향이 있음, 내가 주로 이용하는 방식은 코드 구현에 얽매이지 않고 Gemini를 통해 설계적 탐구에 활용하는 것임, Stripe로 구독 서비스를 만드는 사례처럼 내 기술 스택과 사례에 맞춘 기존 데이터를 맥락에 맞게 받아보면서 단 한 줄의 코드를 쓰기 전에도 설계 방향을 바꿀 수 있었음
답은 “시맨틱 레이어(semantic layer) 사용”임, 올바른 맥락 전달에 가장 효과적이고 사람이 직접 개입할 최적의 지점임, 사람이 모든 핵심 지표를 명확히 정의해두면 LLM이 그걸 언제든 활용할 수 있음, 예를 들어 MAU를 정의해두면 LLM이 그 정의를 기준으로 쿼리를 생성함, SQL 대신 JSON으로 쿼리를 쓰면 LLM이 훨씬 일관적으로 결과를 냄, 우리는 cube를 사용하는데, 최고의 오픈소스 시맨틱 레이어임, 네이버에 닫힌 소스 옵션들도 있음, 과거 내 회사가 관련 블로그도 썼었는데 지금은 소유 회사가 호스팅을 중단함
“쿼리를 SQL 대신 JSON으로 쓸 수 있다”가 장점이라는 주장에는 동의하기 어려움, 도저히 받아들일 수 없음
실제 업무에서 AI를 써서 SQL을 만들면 위험함, SQL을 모르는 사람이 잘못된 쿼리를 써서 서버에 심각한 영향을 줄 수 있음, 우리 팀에서 데이터베이스는 대다수 개발자 기준 크지만 정말 거대하지는 않음, 가끔 최적화된 쿼리를 더욱 개선해달라고 AI에 요청해도 AI가 더 나은 답을 준 적이 없음, 때론 AI가 헛소리를 하거나 실제로는 쓸모없는 제안을 함, 마치 멍청한 앵무새가 예전에 들은 이야기를 반복하는 느낌임
경험상 프로그래밍을 잘 모르는 사람은 AI가 아니더라도 일단 해보고 일이 망가지면 남 탓을 함, AI는 그저 이런 사고의 빈도를 늘려줄 뿐임
AI의 텍스트-정규표현식 변환 기능이 있으면 정말 편리할 거란 생각임
이 의견을 자주 보는데 솔직히 놀람, 사람들은 정규표현식을 정말 모르는 건지 궁금함, 정규표현식은 엄청나게 널리 쓰이고 학습 자료도 많고 진입 장벽도 낮음, 90%의 용도는 아주 간단하고 결과적으로 AI에 설명하느니 직접 쓰는 게 더 빠름
내가 써봤던 모든 AI 도구 중 가장 실망스러운 게 BigQuery에 내장된 Gemini임, 컬럼 명도 명확하고 설명도 잘 달았는데, 문제 해결에 전혀 근접하지 못함
내가 지금까지 쿼리를 가장 많이 작성한 언어가 SQL임, AI에게 쿼리를 써달라고 해도 내가 직접 작성했을 때보다 결과 다듬는 데 훨씬 더 시간이 오래 걸림, 부차적으로, SQL을 훨씬 더 빠르게 쓸 수 있게 해주는 기능 하나가 있다면 좋겠음, 우리 회사의 DSL에는 외래키 기준으로 자동 조인하는 연산자가 있어서 너무 편리함, SQL을 작성할 때 가장 귀찮은 것은 10개, 20개 넘는 조인문을 일일이 써야 하는 부분임, 다른 점은 그에 비해 그리 어렵지 않음
경험상 명확한 제약 조건, 외래키가 잘 잡혀 있으면 거의 모든 게 해결됨, 테이블마다 명확한 제약 조건이 있어야 AI가 모든 연결 구조를 정확하게 파악할 수 있음, SQL은 아주 정확한 명세가 있지만, 그만큼 제약과 외래키가 잘 정의되어 있지 않으면 AI가 답을 정확히 내줄 수 없음
모든 파운데이션 모델에서 꽤 간단해진 상태임, 테이블 스키마에 코멘트만 잘 달려 있으면 쿼리 생성 요청이 간단함
smolagents 라이브러리로 모델 주변 스캐폴딩 만들어주면 꽤 편리함, text2sql은 데모로는 단순해 보여도 실제로 복잡한 실제 케이스에서 이걸 적용하는 건 매우 어렵다는 글도 있음
Step 1: 스키마에 수천 개 테이블이 있고 주석이 거의 없음, Step 2...
정말 그렇다고 봄, 이제는 별로 마법이 없음, 테이블 생성 DDL은 테이블의 정확한 설명이라 거의 더 필요 없는 게 사실임, 필요한 쿼리만 자세히 설명하면 웬만한 LLM이 쉽게 쿼리를 생성함
"Show HN: We open sourced our entire text-to-SQL product" (2024) 글에서 언급된 자료로 awesome-Text2SQL과 Awesome-code-llm > Benchmarks > Text to SQL 등의 훌륭한 레퍼런스가 있음
Hacker News 의견
텍스트에서 SQL로의 전환의 궁극적인 목표에 대한 고민이 있음, 데이터 분석가의 도우미를 만드는 것인지, 아니면 분석가를 거치지 않고 비즈니스 인사이트를 얻는 것인지가 목적임, 만약 두 번째라면 아무리 고도화되어도 비전문가가 SQL의 정확성과 충분함을 판단하는 것이 불가능한 문제임, "왜 어제 전자상거래 거래가 80%에 머물렀는가?", "고객 획득 비용이 왜 오르는가?", "뉴욕 캠페인이 샌프란과 비교해 왜 더 안 좋았는가?"와 같은 질문은 text2sql의 범주를 벗어나는 질문임
실제로는 두 번째 목적에 가깝다고 보지만, 결과물은 기대에 미치지 못함, 비즈니스에서는 보고서를 마지막에 변경하고 싶어하지만 분석가 부족으로 원하는 정보를 적시에 얻지 못함, "무한 속도"로 해결하려 하지만, 실제로 문제는 메트릭에 대해 충분히 고민하지 않는 데서 발생함, 데이터가 복잡하고 비즈니스 지식이 외부에 암묵적으로 저장되어 있으며 데이터 인프라가 부족해서 분석에 시간이 오래 걸림, 똑똑한 분석 리더들은 AI 열풍을 이용해 기본 인프라에 투자함
위의 질문들은 애초에 SQL로 풀 수 있는 문제가 아니라고 봄, SQL은 주로 "무엇(what)"에 대한 답변을 제공하는데, "왜(why)"에 답을 하지는 않음, 텍스트2SQL의 목표는 분석가가 "무엇"을 빠르게 해내도록 시간을 줄이고, 그렇게 해서 "왜"에 집중하도록 돕는 것임
맞는 말이지만, 내 생각에는 자연어 텍스트가 LLM 시스템의 보편적 입력이 될 수 있다고 생각함, text2sql은 더 복잡한 질문의 답을 구성하는 정보 검색의 기반 역할을 할 수 있음, 단기적으로는 업무 보조 기능이지만 장기적으로는 자동화, 결과 비교, 더 큰 워크플로우로 통합하는 기초를 쌓는 게 목표임, 이런 질문에 답하는 기반 마련이 핵심임, 아직 할 일이 많음
어떤 알고리즘도 사람이 할 수 있다면 만들고 테스트할 수 있음, 10명의 분석가가 있다면 데이터베이스와 비즈니스에 대한 이해도, 실력이 모두 다름, 자동화는 최소한의 실력과 지식을 보장하는 표준을 제공함, 새로운 분석가도 바로 더 나은 성과를 냄, 시스템을 전문가와 협력해 개발하면서 테스트하고, AI가 트레이드오프, 버그, 기대 결과와 비교해 해석하도록 하는 것이 유용한 목표임, 통찰력이나 ‘테이스트’는 자동화하기 어렵지만 도메인 전문가가 잘 설계된 자동화와 합리적 결과의 감각만 있다면 아주 멀리 갈 수 있음, 완벽하진 않지만 이런 것들이 내 목표임
OpenAI 4o 모델을 사용해 본 경험 공유, 비즈니스 지침, 업계 용어, 테이블과 외래키 설명을 함께 프롬프트에 전달함, 그러면 복잡한 조인 쿼리도 생성하고 결과를 반환함, SQL을 모르는 사용자를 위한 결과 제공이 목적이었지만 SQL 자체도 참고로 같이 보여줌
AI가 완벽한 SQL을 생성할 필요는 없음, 내 경우에는 출력물이 코드로 검증이 되더라도 미세한 의미 차이의 위험 때문에 복사해서 쓰진 않음, 대신 AI가 접근법을 제시해주면 그걸 참고해 직접 SQL을 처음부터 작성함
Google AI Studio의 최신 Gemini를 사용해 본 경험, 정말 놀랄 정도로 인상적이고 혁신적임, Claude와 ChatGPT의 코딩 결과는 마치 다른 세기에서 온 것처럼 느껴짐, 불과 한 달 전만 해도 Claude가 굉장하다고 생각했는데 지금은 Google Gemini 없이 어떻게 계속 코딩을 할 수 있을지 모르겠음, Gemini AI Studio는 프로그래밍에서 거대한 도약임
더 많은 사람들이 아직 이 변화를 인식하지 못해 놀라움, Claude도 작은 작업은 잘 처리하지만 복잡한 문제로 발전하면 Gemini가 월등히 앞서감, 컨텍스트 핸들링 능력이 특히 인상적임, 나는 코딩 에이전트로 사용할 뿐만 아니라 85,000단어짜리 원고에 대한 베타 리딩에도 Gemini를 쓰고 있고, 전문가 수준의 피드백 리포트를 거의 실시간으로 받음
이번 주에 무료 Gemini Pro에서 추론 모드를 비활성화한 것 같다는 느낌이 듦, 코드 작성 직전에 멈추거나 지나치게 일반화시키지 않도록 하면 상당히 유용함, 다만 Gemini는 코드를 과하게 작성하는 경향이 있음, 내가 주로 이용하는 방식은 코드 구현에 얽매이지 않고 Gemini를 통해 설계적 탐구에 활용하는 것임, Stripe로 구독 서비스를 만드는 사례처럼 내 기술 스택과 사례에 맞춘 기존 데이터를 맥락에 맞게 받아보면서 단 한 줄의 코드를 쓰기 전에도 설계 방향을 바꿀 수 있었음
답은 “시맨틱 레이어(semantic layer) 사용”임, 올바른 맥락 전달에 가장 효과적이고 사람이 직접 개입할 최적의 지점임, 사람이 모든 핵심 지표를 명확히 정의해두면 LLM이 그걸 언제든 활용할 수 있음, 예를 들어 MAU를 정의해두면 LLM이 그 정의를 기준으로 쿼리를 생성함, SQL 대신 JSON으로 쿼리를 쓰면 LLM이 훨씬 일관적으로 결과를 냄, 우리는 cube를 사용하는데, 최고의 오픈소스 시맨틱 레이어임, 네이버에 닫힌 소스 옵션들도 있음, 과거 내 회사가 관련 블로그도 썼었는데 지금은 소유 회사가 호스팅을 중단함
실제 업무에서 AI를 써서 SQL을 만들면 위험함, SQL을 모르는 사람이 잘못된 쿼리를 써서 서버에 심각한 영향을 줄 수 있음, 우리 팀에서 데이터베이스는 대다수 개발자 기준 크지만 정말 거대하지는 않음, 가끔 최적화된 쿼리를 더욱 개선해달라고 AI에 요청해도 AI가 더 나은 답을 준 적이 없음, 때론 AI가 헛소리를 하거나 실제로는 쓸모없는 제안을 함, 마치 멍청한 앵무새가 예전에 들은 이야기를 반복하는 느낌임
AI의 텍스트-정규표현식 변환 기능이 있으면 정말 편리할 거란 생각임
내가 써봤던 모든 AI 도구 중 가장 실망스러운 게 BigQuery에 내장된 Gemini임, 컬럼 명도 명확하고 설명도 잘 달았는데, 문제 해결에 전혀 근접하지 못함
내가 지금까지 쿼리를 가장 많이 작성한 언어가 SQL임, AI에게 쿼리를 써달라고 해도 내가 직접 작성했을 때보다 결과 다듬는 데 훨씬 더 시간이 오래 걸림, 부차적으로, SQL을 훨씬 더 빠르게 쓸 수 있게 해주는 기능 하나가 있다면 좋겠음, 우리 회사의 DSL에는 외래키 기준으로 자동 조인하는 연산자가 있어서 너무 편리함, SQL을 작성할 때 가장 귀찮은 것은 10개, 20개 넘는 조인문을 일일이 써야 하는 부분임, 다른 점은 그에 비해 그리 어렵지 않음
경험상 명확한 제약 조건, 외래키가 잘 잡혀 있으면 거의 모든 게 해결됨, 테이블마다 명확한 제약 조건이 있어야 AI가 모든 연결 구조를 정확하게 파악할 수 있음, SQL은 아주 정확한 명세가 있지만, 그만큼 제약과 외래키가 잘 정의되어 있지 않으면 AI가 답을 정확히 내줄 수 없음
모든 파운데이션 모델에서 꽤 간단해진 상태임, 테이블 스키마에 코멘트만 잘 달려 있으면 쿼리 생성 요청이 간단함
smolagents 라이브러리로 모델 주변 스캐폴딩 만들어주면 꽤 편리함, text2sql은 데모로는 단순해 보여도 실제로 복잡한 실제 케이스에서 이걸 적용하는 건 매우 어렵다는 글도 있음
Step 1: 스키마에 수천 개 테이블이 있고 주석이 거의 없음, Step 2...
정말 그렇다고 봄, 이제는 별로 마법이 없음, 테이블 생성 DDL은 테이블의 정확한 설명이라 거의 더 필요 없는 게 사실임, 필요한 쿼리만 자세히 설명하면 웬만한 LLM이 쉽게 쿼리를 생성함
"Show HN: We open sourced our entire text-to-SQL product" (2024) 글에서 언급된 자료로 awesome-Text2SQL과 Awesome-code-llm > Benchmarks > Text to SQL 등의 훌륭한 레퍼런스가 있음