파이썬을 몰라도 Claude Code로 4.7k 스타 오픈소스 도구를 만든 방법: '쓰레기'가 되지 않게 하는 워크플로우
I built a 4.7k-star open source tool with Claude Code without knowing Python. Here's the workflow that made it not slop
핵심 요약
파이썬 지식 없이 Claude Code를 활용해 SQL 데이터베이스용 TUI 도구 'sqlit'을 개발하고 성공적으로 런칭한 경험담입니다.
- 테스트 중심 개발 — 기능 구현보다 기능이 고장 났음을 증명하는 테스트 환경 구축을 우선함
- 의사결정 방식 — 코드 작성보다 아키텍처 대안들의 장단점을 비교 분석하는 데 시간을 투자함
- AI 활용 마케팅 — 코드베이스를 학습시킨 Claude에게 타겟 오디언스와 홍보 전략을 조언받음
- 사용성 중심 설계 — 기존 도구들의 불편함을 해결하고 사용성을 극대화하여 차별화에 성공함
코드를 한 줄도 직접 안 짜고 Claude Code를 써서 sqlit을 만들었다. SQL 데이터베이스용 lazygit 스타일 TUI인데, 파이썬 앱을 만들어본 적도 없는 상태에서 시작했음. 사용자들을 어떻게 모아야 할지 몰라서 Claude한테 코드베이스 읽게 하고 어디에 홍보하면 좋을지 물어봤는데, 일주일 만에 별 1k 찍고 지금은 기여자 33명에 별 4.7k까지 달성했다.
만든 것
작년에 리눅스로 갈아타면서 SSMS를 못 쓰게 됐다. 대안이라곤 VS Code의 SQL 확장 프로그램이나, 연결하기도 전에 단축키부터 공부해야 하는 터미널 툴들뿐이었음. 그래서 데이터베이스용 lazygit이 필요했고, 파이썬이랑 Textual로 sqlit을 직접 만들었다.
Claude를 활용한 개발 과정
테스트 우선주의. AI 기반 개발에서 내가 가장 중요하게 생각하는 건 테스트 가능성이다. 기능을 어떻게 구현할지보다, 기능이 고장 났다는 걸 어떻게 증명할지가 1순위임. 일단 증명만 할 수 있으면, 내가 개입 안 해도 AI가 알아서 무한 반복하며 수정하니까.
Textual 프레임워크를 고른 이유는 모든 컴포넌트를 헤드리스(headless)로 돌리고, 실제 키보드 입력을 시뮬레이션하고, 스크린샷까지 찍는 과정을 내가 손댈 필요 없이 자동화할 수 있어서였다.
실시간으로 기능 만들 때는 Claude Code를 썼고, 백그라운드에서 길게 리팩토링할 때는 Codex를 썼다. 내가 이걸 만들었던 작년 12월보다 양쪽 모델 다 성능이 훨씬 좋아졌지만, 여전히 이 조합이 최고라고 생각함.
내가 진짜 시간을 쏟은 건 코드가 아니라 장단점 분석이다. 리팩토링이나 아키텍처 결정할 때마다 무조건 선택지 3~5개씩 뽑아달라고 하고, 각각 장단점을 다 따져봤음. 왜냐면 대안이랑 비교해서 이해하기 전까진 내가 제대로 아는 게 아니라고 생각하거든. 무언가의 '정체'는 그게 아닌 것들과의 상대적인 관계에서 나오는 거니까. 의사결정 시간 대부분을 이 장단점 읽는 데 썼는데, AI랑 코딩할 때 이게 제일 좋은 방법인 것 같다. 애초에 '정답'이라는 게 없으니 AI가 고를 수도 없는 노릇이고. 모든 선택엔 트레이드오프가 따르는데, 그걸 저울질할 수 있는 건 프로젝트의 비전을 가진 사람뿐임.
물론 코드를 아예 안 읽은 건 아니다. 눈 감고 만들 순 없으니까. "코드 4만 줄 리팩토링해라, SOLID랑 DDD랑 디자인 패턴 써서 실수 없이 해라" 같은 주문엔 한계가 있음. 난 파이썬 앱을 만들어본 적이 없어서 누가 칼 들고 협박해도 메인 함수 하나 제대로 못 짰을 거다. 언더바가 몇 개 필요한지도 모르는데 뭘 알겠냐. 그래도 다른 언어들 굴러먹은 짬밥이 있어서 코드를 보면 이게 괜찮은지 아닌지는 안다. 앱 여기저기에 if provider == "mssql"이 널려있고 버그가 계속 터지는 걸 보면, 아 이건 전략 패턴(strategy pattern)으로 갈아엎어야겠구나 싶음. 나중에 기여자 한 명이 데이터베이스 추가할 때 파일 20개 건드릴 거 3개만 건드리면 되게 만드는 게 이득이라는 걸 직관적으로 아는 거지. AI는 이런 거 그냥 지나치거든.
아키텍처랑 테스트 스위트가 믿을만해진 다음부터는 구체적인 구현 코드는 아예 안 봤다. Postgres 프로바이더 내부가 어떻게 돌아가는지는 시스템 나머지 부분에 영향 안 주니까, 통합 테스트만 완벽하면 세부 사항까지 알 필요가 없음.
그래서 엔지니어로서 내 역할은 점점 오케스트레이션 쪽으로 바뀌었다. 최대한 많은 코드를 신경 안 써도 되게끔 판을 짜는 거임. '바이브 코딩(vibe coding)'이라고 하면 좀 낮잡아 보는 경향이 있는데, 사실 그게 목표가 돼야 한다. 아이러니하게도 바이브 코딩이 가능하게 만들려면 초반에 시간과 노력을 엄청나게 쏟아야 함. 대신 그 보상으로 이제는 비개발자 기여자들도 Claude Code로 PR을 한 번에 깔끔하게 날린다. 내가 이 레포에서 AI가 쓰레기 코드를 짜기 힘들게끔 환경을 잘 만들어놨거든.
제품 개발.
AI가 우리한테 뭐가 중요한지 근본적으로 알 수 있다고 생각하지 않는다. Claude가 제안한 기능 다 넣었으면 sqlit은 무겁고 흉측한 괴물이 됐을 거임. 이 제품이 성공한 이유는 내가 직접 쓰려고 만든 거라, 기존 툴 쓰면서 몇 년 동안 겪은 고통을 내가 정확히 알고 있었기 때문이다. 자기가 만든 제품을 직접 써보면서 그 결함 때문에 고통받는 과정을 거치지 않으면 답이 없다. 그건 AI가 절대 못 하는 영역임.

