데이터브릭스(Databricks) 환경을 쓰는 팀이라면 로컬에서의 개발과 테스트가 늘 고민거리다. 실제 워크스페이스에 붙어 작업하면 비용과 격리 문제가 따르고, 그렇다고 목(mock) 서버로 대체하면 겉모습만 흉내 낼 뿐 실제 쿼리나 잡(job)이 돌지 않아 신뢰하기 어렵다. 최근 공개된 오픈소스 프로젝트 미니레이크(MiniLake)는 이 간극을 노린다. databricks-sdk, 테라폼(Terraform), 혹은 LLM 에이전트를 localhost로 향하게만 하면, 가짜 응답이 아니라 실제 SQL과 델타 레이크(Delta Lake), 실제 스파크(Spark) 잡이 동작하는 로컬 Databricks API 에뮬레이터라는 점이 핵심이다.
흉내가 아닌 실제 실행
미니레이크의 설계 철학은 '진짜로 실행한다'는 데 모여 있다. 카탈로그, 스키마, 테이블, 볼륨을 완전한 CRUD로 다루는데, 각 카탈로그는 저마다 하나의 DuckDB 데이터베이스 파일로 존재한다. 덕분에 catalog.schema.table 형태의 3단계 주소 지정이 정규식 치환 같은 눈속임이 아니라 네이티브로 동작한다. 문장 실행은 실제 DuckDB 위에서 이뤄지며, INLINE과 EXTERNAL_LINKS 디스포지션, JSON_ARRAY·ARROW_STREAM·CSV 포맷, 그리고 실제 컬럼 타입을 담은 결과 매니페스트를 지원한다.
델타 레이크 처리도 형식적이지 않다. EXTERNAL 델타 테이블은 진짜 파케이(Parquet) 파일과 _delta_log/ 디렉터리로 구성되며, INSERT·UPDATE·DELETE는 실제 스파크 잡을 거쳐 처리되고 읽기는 DuckDB의 delta_scan()을 탄다. spark_python_task는 이웃 컨테이너에서 spark-submit을 실제로 실행하고 진짜 표준출력을 돌려준다. DAG 스케줄링도 depends_on과 run_if를 존중해 독립적인 분기를 병렬로 돌린다. 나아가 spark.table("cat.sch.tbl") 호출은 공식 UCSingleCatalog 커넥터를 통해 미니레이크로 해석되는데, 이는 스파크가 실제 워크스페이스와 주고받는 바로 그 프로토콜이다.
도구 연동과 개발 편의
실무 흐름에 바로 꽂히는 부분은 도구 호환성이다. databricks 프로바이더를 localhost로 지정하고 terraform apply를 실행하면 실제 카탈로그가 생성된다. 이 과정은 매 테스트마다 apply·plan·destroy로 검증되고, 두 번째 plan은 반드시 비어 있어야 통과한다. databricks bundle deploy와 bundle run도 처음부터 끝까지 동작하며 잡이 실제로 실행된다. /mcp에서는 67개 도구, 8개 리소스, 4개 프롬프트가 제공되는데, 다섯 번의 호출을 하나로 묶는 컴포지트와 에이전트가 스파크 SQL을 잘못 작성하지 못하게 막는 SQL 방언 리소스가 포함된다.
개발·CI 환경을 위한 편의도 챙겼다. POST /_minilake/reset 한 번이면 컨테이너를 재시작하지 않고도 모든 테스트에 깨끗한 워크스페이스를 준다. /health, /ready, /services가 컨트롤 플레인을 보완한다. 노트북과 파일은 청크 업로드가 가능한 파일 기반 저장소를 쓰고, 시크릿은 실제 CRUD이되 그 값은 잡 환경 안에서만 해석된다. 이는 Databricks의 동작과 동일한 설계다. UI 측면에서는 /ui의 아테나(Athena) 스타일 에디터가 모나코(Monaco) 기반의 카탈로그 인식 자동완성, 가상화된 결과 그리드, 차트, CSV/JSON 내보내기, 저장 쿼리, 쿼리 히스토리에 더해 주피터랩(JupyterLab)까지 품고 있다.
재현성도 강조된다. DuckDB의 델타 확장과 델타/유니티 카탈로그 JAR이 빌드 시점에 이미지에 구워지기 때문에 런타임에는 아무것도 내려받지 않는다. docker run --network none으로도 증명 가능하다는 설명이다. 실패 응답은 {"error_code", "message"} 형태로 돌아와 SDK가 평소의 타입 예외를 그대로 던지고, 범위를 벗어난 호출은 그럴듯한 거짓 응답 대신 501 NOT_IMPLEMENTED로 분명하게 거절한다.
명확히 그어진 한계선
미니레이크는 자신이 '프로덕션 대체재가 아니다'라는 점을 숨기지 않는다. 인증은 어떤 토큰이든 받아들이고 사용자는 단 한 명뿐이므로 localhost 밖으로 노출해서는 안 된다. Permissions API는 실제 CRUD지만 모든 것을 항상 허용하므로, 여기서 테스트가 통과했다고 해서 실제 워크스페이스의 권한 부여에 대해 말해주는 바는 전혀 없다. 문장은 DuckDB 방언으로 돌아가기 때문에 MCP 서버가 방언 리소스를 제공하고 문서에 변환 표를 싣는다. 클러스터 생명주기는 상태 머신일 뿐이며, 실제 스파크는 이웃 컨테이너의 잡을 통해서만 일어난다.
동시성 한계도 분명하다. DuckDB는 단일 라이터 구조라 동시 부하가 락에서 직렬화된다. 개발과 CI에는 충분하지만 배포 대상은 아니다. 관리형(Managed) 테이블은 파일이 없는 DuckDB 테이블이므로, 스파크가 데이터를 봐야 한다면 EXTERNAL 델타를 써야 한다. 이 트레이드오프가 바로 SQL을 빠르게 유지하는 장치다. 정리하면 미니레이크는 로컬 반복 개발, 통합 테스트, 에이전트 기반 자동화 실험에서 실제 동작을 확인하려는 목적에 들어맞는 도구이며, 그 쓰임새의 경계를 스스로 또렷하게 선언한다는 점이 오히려 신뢰를 준다.