글을 쓰게 된 계기

최근 사이드 프로젝트로 만든 Grovr를 릴리즈했다. Git Worktree를 관리하는 macOS 데스크톱 앱인데, 만드는 과정에서 느낀 점들을 정리해보고 싶어서 글을 쓰게 됐다.

Grovr

왜 이 도구를 만들었나

나는 백엔드 개발자고, AI를 활용한 개발 생산성 향상에 관심이 많다. 최근엔 여러 작업을 동시에 할 일이 많아서, 병렬로 AI를 돌리고 Context Switching Cost를 최소화하는 것에 특히 관심이 많았다.

그래서 Claude Squad, Vibe Kanban 같은 바이브 코딩 도구들을 보자마자 써봤다.

근데 Production Ready 프로젝트를 관리하는 입장에서, 온전히 바이브 코딩만으로는 어려웠다. 때로는 IDE에서 코드를 직접 보기도 해야 하고, 이상한 부분은 드래그해서 “이거 이렇게 바꿔줘” 하고 피드백을 줘야 했다.

그러다 보니 IDE도 열어두고, 터미널도 열어두고, 여러 저장소를 왔다갔다 하면서 context switching이 엄청나게 늘어났다. 이때 Git Worktree가 빛을 발했다.

Worktree?

Git Worktree는 하나의 저장소에서 여러 브랜치를 각각 다른 디렉토리에 체크아웃할 수 있게 해주는 기능이다. 브랜치 전환할 때 stash 안 해도 되고, 각 작업을 독립된 폴더에서 할 수 있다. IDE도 각각 열어두면 된다.

CLI → Script → JetBrains Plugin → Desktop App

근데 Worktree를 많이 쓰다 보니 새로운 문제가 생겼다:

  • 어떤 작업을 어디서 하고 있는지 헷갈렸다
  • Jira 티켓 업데이트 했는지 기억이 안 났다
  • Merge 했는데 안 지운 Worktree가 좀비처럼 쌓였다

처음엔 alias나 커스텀 스크립트를 만들어서 자동화해보았다. 근데 나는 타자를 많이 쳐야 하는 CLI를 그렇게 선호하지는 않는다. 그래서 JetBrains Plugin도 만들어봤는데, 다른 IDE에서 못 쓰기도 하고, 자유도가 매우 낮았다.

결국 Native Desktop App을 만들기로 했다. 특정 IDE에 종속되지 않고, 자유도가 훨씬 높다고 생각해서.

만들면서 겪은 일들

기능 욕심의 늪

프로젝트를 세팅하고 만들다 보니 욕심이 생겼다.

  • “메모 기능 있으면 좋겠다”
  • “칸반 보드로 보면 좋겠다”
  • “GitHub PR 상태도 보여주면 좋겠다”
  • “Jira 연동도…”

그래서 릴리즈가 차일피일 미뤄졌다. 정말 작은 스타트업을 운영하는 느낌이었다.

제일 어려웠던 건 “하지 않을 일"을 고르는 것이었다. 기능을 추가하는 건 쉬운데, 애정을 가지고 만든 기능을 내 손으로 지우는 건 진짜 어려웠다. “이거 분명 누군가는 쓸 텐데…” 하면서.

릴리즈의 고통

개발만 하면 되는 줄 알았는데, 릴리즈하려니까 할 일이 산더미였다:

  • README 등 문서 작성 - 이건 뭐 예상했다
  • 스크린샷/GIF 촬영 - 생각보다 시간 많이 걸렸다
  • Apple Developer Program 가입 - $99/year…
  • Homebrew Cask 등록

이제 한 번 해봤으니, 다음엔 좀더 수월하지 않을까 싶다.

바이브 코딩, 실제로 해보니

이 앱은 Rust + Tauri로 만들었다. Rust는 알지만 Tauri는 처음이었다.

현업과는 다른 방식으로

재밌는 건, 위에서 “현업에서는 온전히 바이브 코딩이 어렵다"고 했는데, 이 사이드 프로젝트에서는 오히려 온전히 바이브 코딩을 했다. IDE를 열기보다는 터미널에서 worktree 6개 만들어두고, 각각 AI한테 작업 시키고, 결과물만 확인하는 식으로. 코드를 한 줄 한 줄 이해하기보다는 동작하는지만 봤다.

현업이 아니니까 가능한 방식이었다. 품질보다 속도가 중요했고, 어차피 내가 쓸 거니까 버그가 있어도 내가 고치면 됐다.

반복 작업도 최대한 자동화했다. 버전 올리고, 빌드하고, 서명하고, 릴리즈 노트 만들고, GitHub에 발행하는 과정을 skill로 만들어서 한 줄 명령어로 끝낼 수 있게 했다.

모델이 더 발전하면 현업에서도 이런 방식이 가능해지지 않을까 싶다. 코드를 일일이 확인하지 않아도 될 정도로 신뢰할 수 있게 되면. 아직은 아니지만, 그때가 오면 지금 이 경험이 도움이 될 것 같다.

테스트 환경 구축이 어려웠다

Tauri 앱을 여러 worktree에서 동시에 개발하다 보니 문제가 생겼다. 로컬 설정이 겹쳤다. worktree A에서 테스트하다가 worktree B로 넘어가면 설정이 꼬여있고.

각 worktree마다 격리된 테스트 환경을 만드는 게 생각보다 까다로웠다. 근데 일단 잘 설정해두니까 병렬로 작업할 수 있게 됐다. A에서 빌드 돌리는 동안 B에서 다른 기능 테스트하고. 생산성이 확실히 올라갔다.

TDD의 중요성을 다시 느꼈다. 테스트가 없었으면 이렇게 여러 작업을 동시에 진행하기 어려웠을 것이다.

마무리

원래 생각했던 거보다는 시간을 많이 썼다. 하지만 그만큼 배운 것도 많았다.

바이브 코딩도 현업과 사이드 프로젝트에서 다르게 쓸 수 있다는 걸 느꼈다. 현업에서는 코드를 직접 확인해야 할 때가 많았지만, 사이드 프로젝트에서는 결과물만 보고 넘어가도 됐다. 상황에 맞게 쓰면 된다.

아직 부족한 부분이 많다. 근데 일단 릴리즈하고 나니까 마음이 편하다. 부족한 건 다음 버전에서 고치면 된다.