gemini-cli로 더미 데이터 바이브 생성한 후기

TL;DR

- gemini-cli로 로컬 DB에 더미 데이터를 넣었다

- 참 똑똑하고 시간도 많이 아낄 수 있다

- 근데 상의도 없이 기존 DB를 전부 날려버렸다

 

개요

소마 프로젝트를 개발하면서 테스트를 위해 더미 데이터가 필요해졌다.

근데 손으로 넣는 건 귀찮고, 랜덤으로 데이터를 넣기엔 형식이 까다로워서 고민이 됐다.

ex) Course 테이블은 코스의 경로를 저장한 `[{"lat": double, "lng": double}, ...]` 형태의 json list 칼럼을 가짐

 

그래서 AI의 힘을 빌려보기로 했다. 🤖

 

왜 Claude Code 말고 Gemini CLI를 썼나?
공짜라서 썼다 ㅎㅎ,,
구글이 AI 사용량 측면에선 대인배 포지션으로 전략을 잡은 것 같다.
몇 달 전에 대학생 대상으로 Google Pro 라이센스를 뿌린 적이 있었는데, 덕분에 Gemini를 많이 써서 익숙하기도 했다.

 

경과

MySQL 계정 생성

AI에게 넘겨줄 mysql 계정을 하나 만들었다. 어차피 로컬 DB니까 권한은 화끈하게 전부 줬다.

 

그리고 gemini한테 mysql을 접속해보라고 한다.

근데 mysql 클라이언트가 안깔려있더라.

mysql server 설치하면 클라이언트도 자동으로 같이 깔리는 줄 알았는데 아니었다

 

아무튼 mysql 클라이언트를 깔고, gemini한테 테이블을 둘러보고 각 칼럼이 어떤 걸 의미하는지 살펴보게 했다.

 

계획 수립

알아서 터미널에 이것저것 쳐보면서 잘 살펴본다.

테이블 관련해서도 먼저 설명해주지 않아도 대충 어떤 칼럼에 어떤 값이 저장되는지 잘 알고 있더라.

기존 데이터 select도 해보면서 데이터가 어떻게 저장되는지 궁리하는 게 신기했다.

잘못 이해한 부분 몇 개 교정해주고, 더미데이터 생성으로 넘어갔다.

 

더미 데이터 생성 계획

member와 course, running_record 테이블에 각각 데이터를 넣기로 했다.

우선 member에는 레코드를 1000개 삽입하기로 했다.

1000개 정도는 되어야 성능 측정의 의미가 있기도 하고, 실제 회원수도 그만큼은 있으면 좋겠다는 의미로 천 명으로 정했다.

course는 30,000개 삽입하기로 했다.

회원 당 평균 30개의 코스를 만든다고 가정했다.

running_record는 100,000개 삽입하기로 했다.

회원마다 평균적으로 100번 정도 달리고, 각 코스에는 평균 3~4개 사이의 러닝기록이 포함된다고 가정했다.

 

랜덤값 넣기 애매한 칼럼은 생성 전략도 같이 짜달라고 했다.

좋아보여서 그대로 고고씽했다.

 

더미데이터 삽입

데이터 삽입을 위해 스크립트를 짜기 시작했다.

더미데이터 삽입에는 Faker라는 라이브러리를 사용한다.  (대상혁)

가끔씩 한국어 대신 영어로 말하기도 하는데 아직 한국어가 서투른가보다

 

알아서 라이브러리도 설치한다.

설치가 끝나니까 스크립트 실행해도 되냐고 묻는다.

 

데이터 삽입

 

완료됐다고 한다.

테이블을 확인해보자.

잘 생성된 걸 볼 수 있다.

신통하네 싶으면서도 동시에 좀 싸함을 느꼈는데, 기존에 저장해놨던 데이터가 안보였다.

설마 싶어서 스크립트를 살펴봤는데

 

gemini가 데이터를 다 날려버리는 스크립트를 집어넣어놨다.

같이 계획 짤 때는 아무 말도 안해놓고 스크립트 첫줄에 슬쩍 truncate를 집어넣는 모습이 정말 모략꾼이 아닐 수가 없다.

심지어 당당하다.

 

"혹시 보존해야할 중요한 데이터가 로컬 DB에 있으셨나요? 그렇다면 정말 죄송합니다 " <- 이 대사가 심히 불편하다.

물론 중요한 데이터는 없긴 했는데 먼저 날려놓고 죄송하면 끝나나? 😠

저번에 replit에서 AI가 어떤 회사의 프로덕션 DB를 날려버렸다는 뉴스를 봤는데 그쪽도 나랑 비슷한 이유로 암살당한 게 아니었을까

 

평가

완벽하진 않지만 로컬 테스트용으로 빠르게 써먹기엔 편리하고 좋다는 게 내 한줄평이다.

 

단점

일단 나와의 상의도 없이 기존 데이터를 다 날려먹은 게 좀 마이너스다.

같이 계획 짤 때는 아무 말도 안해놓고 스크립트 첫줄에 슬쩍 truncate를 집어넣는 모습이 정말 모략꾼이 아닐 수가 없다.

 

그리고 스크립트 자체도 개선할 여지가 있었다.

gemini가 생성한 스크립트는 트랜잭션 없이 DB truncate 후 테이블 별로 데이터를 삽입한다.

런타임에 에러가 발생하면 거기서 스크립트가 멈춰버린다.

그러면 기존 데이터는 데이터대로 다 날려버리고 롤백되지 않는다.

truncate 대신 delete from으로 바꾸고 삽입 과정이랑 같이 트랜잭션에 넣어주면 더 안전할 것 같다.

굳이 여기까지 해야하나 싶을 수도 있는데, 트랜잭션 넣어주는 게 그렇게 힘든 건 아니니까,,

 

이런 상황을 방지하려면 스크립트 로직의 큰 틀은 직접 지시하는 게 더 나았겠다는 생각이 든다.

AI한테 모든 걸 맡기진 말자는 이야기이다.

 

장점

하지만 시간을 어마어마하게 절약했다는 게 모든 걸 상쇄하는 장점이라고 느껴졌다.

더미 데이터를 혼자 만들려했으면 각 테이블 각 칼럼마다 데이터 어떻게 만들지 고민하고..

스크립트 어떻게 짤지 고민하고.. 라이브러리 어떻게 쓰는지 찾아보고 하느라 못해도 4~5시간은 썼을 것 같다.

그러나 gemini로 데이터 만드는 데에는 30분도 안 걸린 것 같다.

참고로 gemini-cli 설치하는 시간 포함해서다.

블로그에 후기 쓰는 시간이 훨씬 더 오래 걸리고 있다.

그저 지시 몇 번 내렸을 뿐인데 데이터 생성 로직이나 라이브러리 문법에 대한 고민 없이 더미 데이터를 넣을 수 있다는 게 정말 좋았다.

 

공부하는 입장에서 AI Driven Development 같은 마수에 빠지면 학습에 악영향이 생긴다는 생각이 있다.

그래서 AI 자체는 많이 활용하더라도 커서 같은 바이브코딩 툴은 크게 활용을 안하고 있었다.

근데 써보니까 엄청 편하긴 하다.

앞으로 가끔씩 귀찮은 일이 생기면 AI한테 내 컴퓨터를 맡겨버릴지도..?