Dolt: SQL을 Git처럼 다루게 해주는 도구

한국어العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語PortuguêsРусский中文
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00코드는 깃으로 관리하지만, 데이터는 어떤가요? 바로 그게 문제입니다. CSV 파일 하나나
00:00:07설정 행 하나, 스프레드시트 수정 한 번에 앱이 망가집니다. 깔끔한 diff도, 브랜치도, 풀 리퀘스트도,
00:00:13확실한 롤백 방법도 없죠. 이게 바로 Dolt입니다. 깃처럼 작동하는 SQL 데이터베이스죠. 테이블을 브랜치하고,
00:00:20행을 수정하고, 변경 사항을 diff로 확인하고, 커밋하고 다시 머지할 수 있습니다. 진짜 데이터를 위한 진짜 버전 관리죠.
00:00:26앞으로 몇 분 안에 어떻게 시작하고 활용하는지 보여드리겠습니다.
00:00:35우리는 데이터베이스가 데이터를 저장하고 SQL로 쿼리하는 데 아주 뛰어나다는 걸 알고 있습니다.
00:00:41하지만 매일 사용하는 워크플로우에는 별로 적합하지 않죠. 브랜치 생성, 리뷰, diff 확인, 머지,
00:00:47롤백, 누가 무엇을 변경했는지 정확히 확인하는 것 말이죠. 그래서 우리는 종종
00:00:54두 가지 나쁜 선택지 중 하나를 고릅니다. 첫 번째는 데이터를 실제 데이터베이스에 보관하는 것인데, SQL 인덱스와
00:01:00제약 조건, 구조는 얻지만, 데이터가 변경될 때의 리뷰 과정은 제대로 갖춰져 있지 않죠.
00:01:07두 번째는 데이터를 CSV, JSON, YAML로 저장해 깃으로 관리하는 것입니다. 그러면 이제
00:01:13커밋과 풀 리퀘스트를 사용할 수 있지만 데이터베이스가 잘하는 기능들을 잃게 됩니다. 진짜 SQL은 없고,
00:01:20스키마 강제나 깔끔한 diff와 머지도 어렵죠. 누군가 이 레코드를 왜 바꿨냐고 물으면 그 대답은
00:01:27결국 데이터베이스 접근 권한이 있는 누군가일 뿐입니다. 그런 건 진짜
00:01:32워크플로우라고 할 수 없죠. 하지만 대신 이렇게 상상해 보세요. “dolt branch fix-data” 같은 명령어를 실행하고,
00:01:39dolt diff, dolt commit, dolt merge를 쓰는 거죠. 이미 우리가 사용하는 명령어들이지만,
00:01:46이제는 실제 데이터베이스 테이블에 대고 사용하는 겁니다. 그게 바로 Dolt입니다. 데이터베이스를 위한 버전 관리죠.
00:01:52워크플로우를 개선하는 코딩 도구에 관심이 있다면 구독해 주세요. 새로운 영상이
00:01:57계속 올라올 겁니다. 말은 그만하고, 선택지는 많습니다. SQLite, Postgres 등 무엇이든 Dolt를 쓸 수 있죠. 빠르게
00:02:04한번 보여드리죠. 폴더로 이동해서 깃허브에서 Dolt 시작하기 레포지토리를 클론하겠습니다.
00:02:10폴더로 들어가서 공개 Dolt 데이터베이스를 클론하고, dolt sql을 실행하겠습니다. 이제
00:02:18SQL 환경에 들어왔으니 터미널에서 바로 SQL 명령어를 실행할 수 있습니다. 좋습니다, 작은 변경을 하나 해보죠.
00:02:27이제 dolt diff를 실행하면, 첫 번째로 '오, 이게 뭐지?' 싶은 순간을 경험하게 될 겁니다.
00:02:34Dolt는 단순히 어떤 파일이 바뀌었다고 하는 대신, 실제 테이블의 차이점을 보여줍니다. 어떤 행이 바뀌었고,
00:02:43어떤 열이 바뀌었는지, 이전 값과 새로운 값을 바로 확인할 수 있죠. 이제 dolt add로 추가하고,
00:02:50dolt commit -m으로 코멘트를 남길 수 있습니다. 브랜치를 새로 만들려면
00:02:56checkout을 사용해서 브랜치 이름을 지정하면 됩니다. 이 상태에서 또 변경을 하고
00:03:03다시 dolt diff로 확인하고, 커밋하고, 추가할 수 있습니다. 이제 다시 돌아가서
00:03:10main 브랜치로 체크아웃한 뒤 dolt merge를 실행합니다. 우리가 이미 잘 아는 명령어들로,
00:03:17이제 SQL 환경에서 하는 거죠. 마지막으로 dolt log를 실행하면, 데이터베이스에 단순 백업이나
00:03:24덤프 파일, 스프레드시트 수정 로그가 아닌, 실제 커밋 이력이 남습니다. 이게 바로 핵심 아이디어입니다.
00:03:31테이블을 위한 깃 워크플로우죠. 이제 다시 돌아가서 이게 어떻게 작동하는지 보겠습니다.
00:03:37처음부터 Dolt는 익숙하게 느껴지도록 설계되었습니다. status, diff, add, commit, branch,
00:03:44checkout 같은 명령어가 있으니까요. 깃을 알면 이미 이 워크플로우의 형태를 이해하신 겁니다.
00:03:48Dolt는 파일을 추적하는 게 아니라 관계형 테이블을 추적합니다. 커맨드 라인에서 쓰거나,
00:03:55dolt sql-server를 실행할 수 있습니다. 그러면 MySQL 호환
00:04:01클라이언트, ORM, BI 도구, 애플리케이션 코드를 연결할 수 있습니다. 앱은 Dolt를 일반 SQL 데이터베이스처럼 다루지만,
00:04:09데이터에 대한 버전 관리 기능까지 얻게 되는 거죠. 중요한 부분은 바로 이겁니다. 실제
00:04:14데이터베이스와 깃 워크플로우 중 하나를 선택할 필요가 없다는 겁니다. Dolt는 '크롤리 트리(noms/prolly-tree)'라는 기술을 사용하는데,
00:04:22쉽게 말해, 일반 데이터베이스는 읽기와 쓰기를 빠르게 하기 위해 트리 구조를 사용합니다.
00:04:29Dolt는 버전 관리에도 뛰어난 트리 구조를 사용하죠. 그래서 매번 커밋할 때마다 전체
00:04:36데이터베이스를 복사하는 대신, 변경되지 않은 부분은 공유하고 변경된 부분만
00:04:42추적할 수 있습니다. 이제 단순히 '현재 값이 뭐지?'라고 묻는 게 아니라,
00:04:47'무슨 일이 일어나기 전의 행 모습은 어땠지?'라고 물을 수 있습니다. 그게 큰 장점이죠.
00:04:52뭔가 망가졌을 때 짐작할 필요 없이 이력을 직접 확인할 수 있으니까요.
00:04:56diff를 리뷰하고, 변경 사항을 확인하고, 필요하면 롤백하세요. 이게 바로 정형 데이터를 위한
00:05:02버전 관리입니다. 행과 열에 대한 브랜치, 커밋, diff, 머지, 이력 관리가 가능하죠. 그럼 Dolt는
00:05:10실제 어떤 상황에 쓰일까요? 이 모든 게 좋아 보이지만, 여기서 헷갈릴 수 있습니다.
00:05:15'데이터를 위한 깃'이라고 하면, 이미 그런 도구들이 있지 않냐고 생각하실 겁니다.
00:05:21물론 어느 정도는 있죠. 하지만 해결하는 문제가 다릅니다. 깃에 CSV나
00:05:28JSON 파일을 넣을 수는 있습니다. 데이터가 아주 작고 단순할 때는 잘 작동하죠. 하지만 깃은 스키마를 이해하지
00:05:35못하고, 기본 키를 모르며, 제약 조건을 강제하지 않습니다. 도구를 더 추가하지 않으면 CSV 조인도 할 수 없죠.
00:05:41그러니 깃은 버전 관리는 해주지만, 데이터베이스용은 아닌 겁니다.
00:05:47그리고 DVC가 있습니다. DVC는 머신러닝 워크플로우나 대규모 데이터셋, 모델 아티팩트 관리에는 좋지만,
00:05:53살아있는 관계형 데이터베이스가 되려는 건 아닙니다. LakeFS도 있죠. 오브젝트 스토리지와 데이터 레이크에
00:06:00깃 같은 아이디어를 가져오는데, 아주 유용합니다. 하지만 그건 완전히 다른 계층의 이야기입니다.
00:06:07SQL 테이블을 브랜치하고, 행을 변경하고, diff를 실행해서 머지하는 것과는 전혀 다른 문제죠.
00:06:13전통적인 데이터베이스도 템포럴 테이블, 감사 로그, CDC 같은 이력 도구가 있지만, 대부분
00:06:20브랜치-변경-diff-머지-롤백 같은 깔끔한 워크플로우를 제공하지는 않습니다.
00:06:27모든 프로덕션 시스템에 무작정 Dolt를 도입하라는 게 아닙니다. 제 말은 이겁니다.
00:06:33시간에 따라 변하는 정형 데이터를 다루고 있고, 그 변화가 문제를 일으킬 수 있다면
00:06:40Dolt를 시도해 볼 가치가 있다고 생각합니다. 잘못된 데이터 변경으로부터 단 한 번만 구해져도,
00:06:46워크플로우가 훨씬 명확하게 느껴질 겁니다. 깃이 있는데 왜 데이터용은 없을까요? 이제는 있는 셈이죠.
00:06:52이런 도구들에 관심이 있다면 Better Stack 채널을 구독해 주세요. 다음 영상에서 뵙겠습니다.
00:06:57감사합니다.

Key Takeaway

Dolt는 Git의 워크플로우를 SQL 데이터베이스에 결합하여, 행과 열 단위의 브랜치와 머지를 가능하게 함으로써 정형 데이터 변경 이력을 완벽하게 관리한다.

Highlights

  • Dolt는 관계형 데이터베이스 테이블을 Git처럼 브랜치, 커밋, diff, 머지할 수 있는 버전 관리 기능을 제공한다.

  • 기존의 CSV나 JSON 기반 버전 관리는 스키마 제약이나 기본 키 추적이 어렵지만, Dolt는 SQL 기반으로 이를 해결한다.

  • 데이터베이스 내부적으로 '크롤리 트리(Prolly-tree)' 구조를 사용하여 전체 데이터를 복사하지 않고 변경된 부분만 효율적으로 추적한다.

  • dolt sql-server 명령어를 실행하면 MySQL 호환 클라이언트를 연결하여 일반 데이터베이스처럼 사용하면서 버전 관리 기능을 유지할 수 있다.

  • 데이터 변경 시 무엇이 바뀌었는지 행과 열 단위의 상세한 diff를 통해 정확히 확인할 수 있어 롤백이 명확해진다.

Timeline

데이터 관리의 문제점과 Dolt의 개념

  • 코드와 달리 데이터는 변경 시 깔끔한 diff나 롤백 방법이 부족하다.
  • 데이터베이스 사용 시 리뷰 과정이 부재하거나, CSV/JSON 파일로 깃 관리를 하면 SQL의 강력한 기능을 잃는다.
  • Dolt는 SQL 데이터베이스 자체에 깃과 같은 브랜치, diff, 커밋, 머지 워크플로우를 도입한다.

실제 개발 환경에서 데이터 변경은 앱을 망가뜨릴 위험이 크지만, 이를 관리할 마땅한 버전 관리 도구가 부족한 상황이다. 데이터베이스를 사용하면 SQL의 구조적 이점은 얻지만 리뷰 체계가 없고, 파일을 깃으로 관리하면 데이터베이스의 기능을 포기해야 하는 모순이 발생한다. Dolt는 이러한 두 선택지 사이의 격차를 해소하고자 데이터베이스 내에서 깃 명령어를 사용하게 만든다.

Dolt 사용 방법 및 실습

  • 깃과 동일한 status, diff, add, commit, branch, checkout 명령어를 사용한다.
  • dolt diff는 파일 변경뿐만 아니라 테이블 내 특정 행과 열의 값 변화를 구체적으로 보여준다.
  • dolt log를 통해 단순 덤프가 아닌 실제 데이터 커밋 이력을 확인할 수 있다.

Dolt는 기존 깃 사용자에게 매우 익숙한 명령어 체계를 제공한다. 데이터베이스를 클론한 후 테이블 내 데이터를 수정하고 dolt diff를 실행하면, 변경 전후의 값을 시각적으로 확인 가능하다. 이후 add와 commit을 통해 이력을 저장하고, 브랜치를 생성해 작업한 뒤 main 브랜치로 머지하는 일련의 과정을 실제 SQL 환경에서 수행할 수 있다.

기술적 동작 원리와 타 도구와의 차이

  • 크롤리 트리 기술을 통해 매번 전체 데이터를 복사하지 않고 변경된 부분만 효율적으로 저장한다.
  • dolt sql-server를 사용하면 MySQL 호환 클라이언트와 ORM 등을 그대로 연결할 수 있다.
  • 깃은 스키마와 제약 조건을 이해하지 못하지만, Dolt는 데이터베이스 자체이므로 관계형 구조를 유지한다.

Dolt는 읽기와 쓰기 성능을 위한 트리 구조를 버전 관리에 맞게 확장한 크롤리 트리를 기반으로 한다. 이는 데이터 효율성을 높이면서도 행 단위의 세밀한 이력 확인을 가능하게 한다. CSV/JSON 기반 깃 관리, DVC, LakeFS 등과 달리 데이터베이스 계층에서 동작하므로 SQL 조인과 제약 조건 강제가 가능하다.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video