21P by xguru 1일전 | ★ favorite | 댓글 1개
  • 데이터 작업에 특화된 VS Code 기반 AI 코드 에디터로, BigQuery/Snowflake/Postgres에 직접 연결되어 데이터 스키마에 맞는 코드 자동 생성품질 검사 기능을 제공
  • 기존 LLM 기반 툴이 데이터 스키마를 인식하지 못하고 SQL을 자동완성하는 반면, nao는 RAG 기반 AI 탭과 에이전트 도구정확한 SQL/Python/YAML 코드를 생성
  • SQL 파이프라인 작성, 실행, 시각화를 하나의 인터페이스에서 수행 가능함
  • Python 파이프라인도 같은 환경에서 지원하며, dbt 워크플로우도 지원됨
  • 코드 변경 전후의 결과 데이터 차이데이터 품질 문제를 한눈에 확인할 수 있어, 테스트 없이 빠르게 배포하거나 실수를 방지할 수 있음
  • 주요 작업 용도
    • 데이터 파이프라인 구축(SQL, dbt 등)에 활용
    • 누락/중복/이상치 탐지
    • 개발 vs 운영 데이터 비교
    • 사전 정의된 테스트 실행 및 요약
  • dbt, BI 툴, 데이터 웨어하우스와 통합되어 있어 데이터 엔지니어, 분석가, 데이터 과학자 모두에게 적합한 IDE 환경을 제공함
  • BigQuery, Snowflake, Postgres를 지원하며 곧 Databricks, Iceberg, Redshift 지원 예정
  • Looker, Power BI, Metabase, Tableau와도 통합 예정
  • 현재는 Mac 버전만 제공, 윈도우/리눅스도 제공 예정
  • Cursor 및 MCPs와의 차별점
    • Cursor는 데이터 컨텍스트를 얻기 위해 여러 MCP 호출 필요, Nao는 단일 RAG에서 항상 사용 가능함
    • MCPs는 Cursor 안에서 제한적으로만 작동하며, UI 적응성도 떨어짐
    • Nao는 사전 패키지화로, 설정, 확장 설치, 인증, CI/CD 구축 불필요, 비전문가도 개발 경험 향상이 가능한게 강점

FAQ

  • 누가 nao를 써야 하나요?
    • SQL 작성자, dbt 분석 엔지니어, 데이터 과학자, 데이터 엔지니어 등 모든 데이터 팀 구성원
  • Cursor와 다른 점은?
    • 데이터 스키마 인식 기반 코드 생성, 자동 데이터 품질 검사, 변경 영향 예측데이터 컨텍스트에 최적화된 IDE
  • 어떤 언어를 지원하나요?
    • 모든 언어를 지원하지만 특히 SQL에 최적화되어 있음
  • dbt 워크플로우엔 어떻게 도움이 되나요?
    • dbt 모델, 소스, 문서, 테스트, 열 단위 lineage를 이해하고 자동완성 및 시각화 제공함
  • 데이터 보안은?
    • 데이터는 로컬에서만 처리되며, LLM으로 전송되기 전 사용자 허용을 받음
    • 코드나 스키마는 저장되지 않음, 오직 임베딩만 활용함
Hacker News 의견
  • 많은 LLM 기반 데이터 프로젝트들이 유연성과 도움을 주지만, 반복하기 어렵고 상호작용성이 부족하다는 점을 지적함, Nao가 이 개념을 잘 구현했다는 평가임, 내가 만든 Buckaroo 는 Jupyter와 Pandas/Polars용 데이터 테이블 UI로, 최신 테이블, 히스토그램 및 요약 통계로 바로 데이터를 볼 수 있음, 어제 Buckaroo에 오토 클리닝 기능을 출시했으며, 데이터에 대해 휴리스틱하게 클린 방법을 골라 확정된 코드를 제공함, 500ms 이내의 매우 빠른 속도를 자랑함, 여러 개의 클리닝 전략을 시도할 수 있고 가장 적합한 것을 고를 수 있음, 단순한 문제는 LLM을 거치지 않아도 됨, 오픈소스이며 확장 가능성이 뛰어남

    • 나도 정말 비슷한 걸 개발 중임, 아직 Buckaroo만큼 완성은 안 됐지만, 노트북 내 임베디드 앱이 꽤 유용하다고 생각함

    • 데이터 프로파일링을 시각화할 수 있는 가 참 마음에 듦, 데이터 이해에 중요한 핵심이라고 생각함

  • 정말 멋진 아이디어라고 생각됨, Tab 모델을 어떻게 학습시켰는지 궁금함, Fill in the middle 혹은 edit history 기반인지, 누가 이와 비슷한 Cursor 탭 자동완성 관련 블로그 글을 어제 공유해서 흥미롭게 읽어봄

    • 우리는 Fill in the middle 모델(Mistral과 Qwen 자체 트레이닝 모델)을 씀, 사용자의 데이터 컨텍스트를 함께 넣음, 커서 위치에 따라 적절한 데이터 스키마 컨텍스트를 제공하려고 자체 SQL 파서를 사용함
  • 몇 주 동안 계속 사용해보면서 워크플로우에 실제로 많은 개선이 있음을 느낌, VSCode와 확장 기능 대신 절반 넘게 선택하게 됨, 탐험적 데이터 분석을 위한 채팅, 워크시트, 칼럼 계보 추적 기능이 dbt 개발에서 정말 판도를 바꿈, 이런 기능들이 실제 내 작업 방식에 맞춰 치밀하게 설계된 느낌임, Claire와 Christophe는 피드백에도 즉각 반응해 기능도 빨리 추가 및 수정해 줌, 제품이 올바른 방향으로 빠르게 발전 중임

    • 좋은 말씀 감사함, 그리고 nao 개선에 도움 주셔서 고마움
  • 정말 매력적이라고 느낌, 유튜브 영상을 여러 번 봤고 피드백 사이클을 단축하는 모습이 매우 인상 깊었음, 정말 멋짐

    • 고마움, 바로 이 피드백 루프 단축이 우리의 목표임, 데이터 팀이 소프트웨어 엔지니어에 비해 더 긴 피드백 루프를 가지는 경향이 있어서, 그것을 줄여서 데이터를 개발 흐름에 더 가깝게 만들고자 하는 노력이 있음
  • 이거 raw SQL 쓸 때만 동작하는지 궁금함, 내 프로젝트는 Postgres + TypeScript에서 Kysely 같은 query builder로 쿼리를 씀, 지금 당장 쓸 수 있을지 궁금함

    • 현재로선 Tab이 raw SQL(순수 SQL 파일 또는 문자열)과 가장 잘 작동함, 하지만 chat/agent를 쓰면 Kysely 사용 중임을 말해주고 웨어하우스 컨텍스트를 전달하면 어느 정도 다룰 수 있음, Kysely는 처음 듣는데 프로젝트 소개 GIF를 보니 자동완성이 꽤 괜찮아 보임, 탭 방식과는 다르지만 흥미로움
  • 내 데이터/프롬프트가 모델에 얼마나 전달되는지 궁금함, 내 스키마 정도야 괜찮지만 웨어하우스 데이터는 대개 민감한 데이터임, 엔터프라이즈 플랜이 있을걸로 아는데, 실제 코드 외 데이터/결과가 서버로 전송되는지, 아니면 코드만 보내는지 미리 알고 싶음

    • 데이터 내용 자체는 사용자가 명시적으로 허용하지 않는 한 모델에 전달하지 않음, 서버에는 코드베이스와 데이터 스키마의 임베딩만 저장됨, 데이터 내용은 사용자의 컴퓨터에서 로컬로만 접근함, agent가 쿼리를 실행할 때는 웨어하우스에서 실행 후, 그 결과를 읽어도 되는지 승인 요청을 먼저 함, 허용하지 않으면 LLM으로 전송되지 않고 로컬에서 미리보기 가능함, 엔터프라이즈 버전 사용 시 프롬프트와 컨텍스트가 공용 LLM 엔드포인트를 거치지 않고 별도 보호받을 수 있음
  • 데이터 엔지니어링, 데이터 사이언스용 LLM 기반 도구 링크 추천받고 싶은 사람 있음

    • 내가 이런 LLM 도구 리스트 리포지토리를 정리 중임, 곧 완성할 계획임
  • 갖고 있는 기능들이 마음에 듦, 혹시 앞으로 SQLite 지원도 추가 예정인지 궁금함

    • 물론임, 별로 어렵지 않게 추가 가능할 것 같음, 다음 릴리즈에서 DuckDB도 들어갈 예정이며, SQLite도 추가할 수 있음, SQLite를 쓰는 이유가 로컬 개발 때문인지 궁금함
  • 여러 테이블에 FK/PK 없는 상태로 전이적 조인을 할 때 어떻게 처리하는지 궁금함, 이것 외에 이미 존재하는 비효율 쿼리에 대한 사용 분석/리라이팅도 킬러 기능이 될 것 같음

    • 조인의 경우, 각 테이블의 스키마와 리포지토리/쿼리 히스토리 상에서 이미 사용된 조인 방식을 모델에 제공해 관계 유추를 도와줌, 사용 분석도 확실히 개발 로드맵에 있음, 각 테이블의 실사용 측정을 위해 데이터 웨어하우스의 로그 접근을 계획 중임