그런데 요즘 들어 쓰면 쓸수록 작은 아쉬움들이 계속 쌓였습니다. 이를테면 루틴마다 제가 중요하게 생각하는 무게가 다른데, 이 앱은 모든 체크를 똑같이 취급한다는 점이 그랬습니다. 이를테면 운동 1시간과 물 마시기 한 번을 같은 체크로 두기 아쉬웠습니다. 또, 이번 달을 내가 어떤 흐름으로 보내고 있는지, 나아가 연 단위로 얼마나 꾸준히 해왔는지를, 제 방식대로 보고 싶다는 생각도 점점 커졌습니다.

예전 같았으면 그냥 아쉽다 하고 넘어갔을 것 같습니다. 그런데 요즘은 좀 다릅니다. AI 덕분에 무언가를 직접 만들어보는 진입장벽이 확실히 낮아졌으니까요. 예전에는 개인용 도구 하나 만들자고 해도 괜히 구조부터 고민해야 했습니다. 파일 구조는 어떻게 잡을지, 상태 관리는 어떻게 할지, 나중에 확장하려면 어떤 방식이 좋을지. 만들기도 전에 피곤해졌죠. 반면 지금은 필요한 기능만 머릿속에 있으면 일단 시작해볼 수 있습니다. 완벽한 설계보다 빠른 구현이 더 자연스러운 시대가 된 느낌이랄까요.

이번 작업도 그런 흐름으로 시작했습니다. 어느 날 오후에 문득 “이 정도면 직접 만들 수 있겠는데?”라는 생각이 들었고, 그 생각을 바로 테스트해보기로 한 겁니다. 거창하게 기획 문서를 쓰지도, 화면 설계를 하지도 않았습니다. 기획을 위해 정말 필요한 것만 적었습니다. 루틴 체크가 되어야 하고, 모바일과 데스크톱에서 둘 다 써야 하고, 월간 진행 현황과 연간 히트맵 정도는 보고 싶고, 메모도 붙일 수 있었으면 좋겠다. 딱 그 정도였습니다. 그리고 바로 Obsidian과 Claude를 붙여서 만들기 시작했습니다.

특히 재밌었던 건, 서비스를 개발한다기보다 “내가 쓰고 싶은 도구를 만든다”는 생각으로 시작했다는 점입니다. 직접 만들다 보니 이 차이가 생각보다 크게 다가왔습니다. 남들이 다 써야 하는 제품을 만들 때는 고려해야 할 게 정말 많지만, 개인용 도구는 기준이 명확하니까요. 제가 매일 쓰면 성공입니다. 제가 보기 편하면 잘 만든 겁니다. 그래서 오히려 더 빠르게 결정할 수 있었고, 훨씬 덜 부담스러웠습니다. 아마 이게 바이브 코딩의 가장 큰 매력 중 하나 아닐까 싶습니다. 완성도 높은 제품을 목표로 하기보다, 일단 내가 만족할 결과물을 빠르게 만드는 데 정말 잘 맞는 방식이니까요.

Obsidian + Claude Code로 구현한 핵심 기능

이번에 이걸 만들면서 제게 가장 중요했던 건 내가 매일 부담 없이 쓸 수 있는지였습니다. 개인용 도구는 이 기준이 정말 중요합니다. 남들에게 보여주기 위한 서비스가 아니라, 제가 아침에 열고 밤에 다시 보는 도구니까요. 그래서 처음부터 기술적인 화려함보다는, 익숙한 환경 안에서 빠르게 만들어 계속 손이 갈만한 쪽을 택했습니다.

Obasidian과 Claude Code를 선택한 이유

그 기준에서 Obsidian은 꽤 자연스러운 선택이었습니다. 원래도 자주 쓰던 작업 환경이었고, 무엇보다 텍스트 기반으로 데이터를 직접 관리할 수 있다는 점이 좋았습니다. 루틴 기록이라는 게 결국 매일 쌓이는 생활 데이터인데, 이걸 특정 서비스 안에만 가두기보다 제가 원하는 구조로 쌓아두고 싶다는 마음이 있었거든요. Obsidian은 노트, 메모, 템플릿, 데이터 조회가 한 공간 안에서 이뤄지니까 이런 용도에 잘 맞았습니다. 즉, 앱을 하나 새로 만든다기보다, 원래 쓰던 작업 공간을 제 생활 데이터에 맞게 확장한다는 느낌이 더 강했습니다.

Claude Code를 사용한 이유도 비슷합니다. 이번 작업은 정교한 제품 설계보다, 필요한 기능을 빠르게 붙이고 바로 써보는 흐름이 훨씬 중요했습니다. 그럴 때는 코드 한 줄 한 줄을 처음부터 직접 치는 방식보다 제가 원하는 동작을 설명하고 결과를 보면서 바로 수정해나가는 방식이 훨씬 잘 맞았습니다. 특히 이번에는 단순히 텍스트를 정리하는 수준을 넘어 대시보드나 시각화처럼 손이 더 많이 가는 부분이 있었는데요. 그런 부분을 Claude Code가 JavaScript로 빠르게 구현해주니까 개발 속도가 확실히 빨랐습니다. 예전 같았으면 나중에 시간 나면 붙이자고 넘겼을 기능들을 이번엔 흐름이 끊기기 전에 바로 붙일 수 있었던 거죠.

활용한 Obasidian 플러그인 3가지

플러그인도 소수만 쓰기로 했습니다. 이번에 실제로 사용한 건 Git 플러그인, Templater, Dataview 정도였고, 나머지 핵심 인터랙션이나 대시보드 같은 부분은 Claude Code가 JavaScript로 구현해줬습니다. 그리고 이 방식이 꽤 마음에 들었습니다. Obsidian 플러그인을 이것저것 많이 얹어서 복잡하게 만드는 방식보다, 기본적인 데이터 흐름은 단순하게 가져가고, 진짜 필요한 부분만 직접 구현하는 쪽이 더 제 스타일에 맞았거든요.

역할도 명확했습니다. Git 플러그인은 여러 기기에서 데이터를 이어 관리하는 데 큰 도움이 됐습니다. 회사 PC, 개인 맥북, 모바일을 오가며 써야 했기 때문에, 기록이 한 군데에만 있으면 의미가 없었거든요. 저는 원래도 개인용 비공개 저장소를 관리하고 있었기에, 기기별 작업 환경은 분리하며 데이터는 자연스럽게 이어갈 수 있었습니다. 루틴 앱처럼 매일 쓰는 도구에 정말 중요한 접근성은 이처럼 Git 플러그인이 해소해줬습니다.

Templater는 반복 입력을 줄이는 데 유용했습니다. 루틴 기록은 하루 이틀 쓸 땐 괜찮은데, 며칠만 지나도 포맷이 흐트러지기 쉽습니다. 메모 형식이 조금씩 달라지고, 항목 순서가 바뀌고, 그러다 보면 나중에 조회할 때도 애매해지죠. 이를 마고자 Templater를 붙여두니 기본 구조를 일정하게 유지하기가 훨씬 쉬웠습니다. 매일 같은 틀 안에서 기록할 수 있으니 입력 부담도 줄고, 뒤에서 데이터를 다룰 때도 훨씬 편해졌습니다. 별거 아닌 것 같지만, 이런 반복 입력 자동화가 있어야 오래 쓸 것이라고 생각했습니다.

Dataview는 이 기록들을 다시 봐야할 때 쓰기 좋았습니다. 루틴 데이터는 쌓이는 것만으로 별 의미가 없습니다. 결국 중요한 건 내가 이걸 어떻게 다시 읽어낼까 하는 거죠. Dataview 덕분에 루틴별 기록을 조회하거나, 특정 기간의 흐름을 정리하거나, 메모를 모아서 다시 보는 작업이 꽤 수월해졌습니다. 기본적으로는 이 플러그인이 데이터 조회 레이어를 맡아준 셈이고, 그 위에서 필요한 시각화나 대시보드 성격의 기능은 Claude Code가 JavaScript로 붙여준 구조에 가깝습니다.

핵심 기능 개발하기

1. 가중치를 더한 루틴 체크

기능 측면에서는 가장 먼저 루틴 체크부터 만들었습니다. 다만 단순히 체크만 하는 구조로 끝내고 싶진 않았습니다. 기존 루틴 앱을 쓰면서 가장 아쉬웠던 게, 모든 루틴이 똑같은 1회 체크로 처리된다는 점이었거든요.

실제 삶에서는 루틴마다 무게가 다릅니다. 물 마시기 한 번과 1시간 운동을 같은 일로 취급할 수는 없죠. 그래서 루틴별로 가중치를 둘 수 있게 만들었고, 제가 생각하는 “충만한 하루”를 제 기준대로 다시 설계했습니다.

이 부분은 만들고 나서도 꽤 만족스러웠습니다. 남이 정의한 하루가 아니라, 내가 납득하는 하루의 기준을 직접 만들었다는 느낌이 들었거든요.

2. 월/연간 대시보드

그다음은 대시보드였습니다. 사실 이 부분이 기존 서비스 대비 가장 차별점이 컸던 것 같습니다. 저는 단순히 오늘 루틴을 몇 개 완료했는지보다, 이번 달 전체 흐름이 어떤지, 연간으로 보면 어떤 패턴이 보이는지가 더 궁금한 사람이거든요. 그래서 월간 진행 현황과 연간 히트맵을 볼 수 있는 대시보드를 붙였습니다.

여기서 중요한 건, 이걸 Obsidian 플러그인만으로 해결하려고 하지 않았다는 점입니다. 조회는 Dataview로 하고, 진짜 보고 싶은 화면은 Claude Code가 JavaScript로 구현해주는 식으로 갔더니 훨씬 유연했습니다. 덕분에 원래 있는 기능에 나를 맞추는 게 아니라, 내가 보고 싶은 화면을 직접 만드는 쪽으로 갈 수 있었습니다.

3. 루틴 메모

루틴별 메모 기능도 넣었습니다. 이건 사소해 보여도 의외로 중요했습니다. 루틴은 결국 맥락의 영향을 많이 받는데요. 왜 오늘은 잘 됐는지, 왜 어제는 실패했는지, 이런 맥락은 단순 체크만으로는 잘 안 보입니다.

그럴 때는 짧게라도 메모를 남겨두는 것이 좋습니다. “회의가 길어져서 운동을 못 했다”, “아침 기상에 성공했더니 다른 루틴도 연쇄적으로 잘 됐다” 같은 기록을 쌓으면, 그때부터는 앱이 체크 로그가 아니라 생활 데이터가 됩니다. 나중에 돌아보면 오히려 체크 횟수보다 이런 메모가 더 많은 걸 알려줄 때도 있었습니다.

그리고 여기서 한 단계 더 갔습니다. 루틴 데이터와 메모가 이미 쌓이고 있으니, 이걸 기반으로 Claude에게 다시 내 생활 패턴을 물어볼 수 있게 만든 겁니다. 예를 들면 어떤 루틴이 다른 루틴과 같이 성공하는 경향이 있는지, 이번 달 흐름이 무너진 시점이 언제인지, 메모에서 반복적으로 등장하는 패턴이 뭔지 같은 걸 질문하는 식이었죠. 결과는 따로 insights 폴더에 모아두도록 했고요.

이 기능을 붙이고 나니까, 단순히 기록하는 앱을 만든 게 아니라 기록을 다시 읽고 해석하는 도구를 만든 느낌이 들었습니다.

결과적으로 이번 구성은 Obsidian 플러그인을 잘 조합해서 만든 루틴 앱이라기보다, Obsidian을 데이터 기반으로 삼고, Git·Templater·Dataview 같은 플러그인으로 뼈대를 세운 다음, 부족한 부분은 Claude Code가 JavaScript로 직접 메운 개인용 도구에 더 가까웠습니다.

이 방식이 꽤 마음에 들었습니다. 플러그인에 너무 많이 기대지 않으면서도, 필요한 건 빠르게 구현할 수 있었거든요. 만들수록 제가 원했던 건 그냥 루틴 체크 앱이 아니었구나 싶었습니다. 체크를 넘어서, 제 하루를 제가 원하는 구조로 기록하고 다시 해석할 수 있는 도구가 필요했던 거죠.

가장 큰 난관이었던 데이터 마이그레이션

물론 즐거운 일만 있었던 건 아니었습니다. 이번 작업에서 가장 어려웠던 건 의외로 구현이 아니었습니다. 루틴 체크 기능을 만들고, 대시보드를 붙이고, 메모 구조를 잡는 것까지는 생각보다 순조로웠으니까요. 진짜 문제는 그다음부터였습니다.

제가 기존에 쓰던 유료 루틴 앱에는 이미 아주 많은 데이터가 쌓여 있었습니다. 올해 기록만 해도 적지 않았고, 단순 체크만 있는 것도 아니었습니다. 날짜별 체크 이력에 메모들도 붙어 있었죠. 새로 만든 도구가 아무리 마음에 들어도, 이 데이터를 못 옮기면 결국 다시 원래 서비스로 돌아갈 가능성이 높았습니다. 시작은 재밌게 했는데, 정작 갈아타는 데 실패하는 가장 흔한 패턴이 딱 이런 경우니까요.

문제의 본질을 챙기기

처음엔 뭐, 조금씩 손으로 옮기면 되지 않을까 하는 생각도 해봤는데요, 바로 포기했습니다. 이런 종류의 수작업은 시작하는 순간 끝이 보입니다. 하루 이틀은 할 수 있겠죠. 하지만 월별로 쌓인 체크 기록과 메모를 계속 다시 입력하는 건, 프로젝트에 대한 애정을 증발시키기 아주 쉽습니다. 특히 루틴 데이터는 건수가 많기에, 얼핏 단순해 보여도 날짜 하나만 틀리면 흐름이 다 망가집니다. 저 역시 이걸 하다가 원래 앱으로 돌아갈 생각을 할 게 너무 뻔했습니다.

그래서 방향을 바꿨습니다. 입력 노동으로 문제를 두면 답이 없지만, 데이터 추출로 보면 얘기가 달라질 거라 생각했거든요. 그렇게 두고 보니 아주 단순한 해결책이 떠올랐습니다. “이거 스크린샷으로 읽히면 되는 거 아닌가?”

기존 앱에는 월별 통계 화면이 있었고, 여기에는 루틴 체크 달력과 메모가 함께 나타납니다. 사람 눈으로 봐도 이미 정보가 거의 다 정리돼 있는 화면이었던 거죠. 그런 데이터를 굳이 제가 하나씩 다시 입력할 이유가 없었습니다. 필요한 건 화면을 잘 정리해서 넘기는 일, 그 화면을 새 포맷으로 변환해주는 일뿐이었습니다.

방법은 꽤 단순했습니다. 먼저 기존 앱의 월별 통계 화면을 캡처했습니다. 이걸 월별로 Migration 폴더에 정리해두고, Claude에게 각 루틴이 어떤 기준으로 체크되는지 설명했습니다. 예를 들어 어떤 기호가 체크 완료인지, 메모는 어떤 식으로 읽어야 하는지, 결과를 어떤 형식으로 정리하면 되는지 같은 규칙을 먼저 잡아준 거죠. 그다음엔 그 스크린샷을 읽고, 제가 쓰는 Obsidian 구조에 맞게 마이그레이션해달라고 요청했습니다.

코드를 잘 짜기보다 지시를 잘 내리기

이 과정이 재밌었던 이유는 코드를 짜는 느낌보다 작업자에게 지시를 잘 내려 문제를 해결한 느낌에 가까웠단 점입니다. 예전에는 이런 작업을 하려면 OCR을 붙이거나, 데이터를 긁어오거나, 포맷 파서를 따로 짜는 쪽으로 생각했을 겁니다.

그런데 이번에는 공학적으로 접근하기보다, 쉬운 방식으로 접근했습니다. 화면을 보여주고, 규칙을 설명하고, 결과를 검수하는 방식을 쓴 거죠. 어떻게 보면 개발이라기보다 작업 파이프라인을 설계한 셈입니다. 바이브 코딩이 재밌는 이유도 이런 데 있는 것 같습니다. 예전 같으면 “기술적으로 어떻게 풀지?”부터 고민했을 일을 지금은 “가장 덜 귀찮고 빨리 끝나는 방식이 뭘까?”로 접근하게 되니까요.

결과는 솔직히 기대 이상이었습니다. 몇 분 안에 대부분의 데이터가 정리됐고, 정확도도 꽤 높았습니다. 저는 중간에 날짜가 꼬이거나, 메모가 엉뚱한 곳에 붙거나, 체크 기준을 잘못 읽는 일이 많이 생길 줄 알았습니다. 그런데 물론 100% 완벽하다고 하긴 어렵지만, 체감상으로는 충분히 쓸만한 수준으로 데이터가 옮겨졌습니다. 무엇보다 이 정도면 손으로 다시 입력하는 것보다 압도적으로 낫다는 확신이 빨리 들었습니다. 이 확신이 굉장히 중요했습니다. 이번 마이그레이션 작업은 완벽함보다도, 내가 이 일을 끝까지 밀고 갈 수 있을지가 더 중요하니까요.

중간에 퍽 인상 깊은 일도 있었습니다. 제가 월별 데이터를 잘못 넣은 적이 있었는데, Claude가 그걸 읽다가 “이건 이전 달 데이터로 보인다”는 식으로 먼저 걸러낸 겁니다. 사람이 대충 넣은 걸 모델이 맥락으로 잡아내는 걸 보니 단순 추출을 넘어 꽤 실용적인 작업 보조라는 생각이 들었습니다. 보통은 제가 AI가 만든 결과물을 의심하면서 검수하는 그림을 생각하는데, 그 반대로 제가 대충 넘긴 걸 오히려 AI가 한 번 더 걸러준 거니까요.

결국 올해 제가 쌓아온 8개 루틴의 체크 데이터와 메모를 거의 다 옮길 수 있었습니다. 전체 작업 시간도 아주 길지 않았습니다. 솔직히 이 마이그레이션이 수작업이었으면, 아마 중간에 포기했을 가능성이 높습니다. 루틴 앱을 새로 만든 성취감과 데이터를 옮기는 지루함은 완전히 다른 문제니까요. 그런데 이번에는 귀찮고 반복적인 이전 작업을 꽤 현실적인 수준으로 줄일 수 있었고, 덕분에 “만든다”에서 끝나는 게 아니라 “갈아탄다”까지 갈 수 있었습니다.

생성형 AI를 반정형 데이터 마이그레이션에 쓰기

이번 경험으로 크게 느낀 게 하나 있습니다. 많이들 생성형 AI를 코드 작성 도구로 먼저 떠올리는데, 실제로는 이런 반정형 데이터 마이그레이션에서 더 큰 효율을 체감할 수도 있겠다는 점입니다.

이미 화면 형태로 정리된 정보, 사람이 보면 금방 이해할 수 있지만 손으로 옮기기 너무 귀찮은 정보, 규칙은 있지만 완전히 정형화돼 있지는 않은 정보들 말이죠. 이런 작업은 원래 애매하게 사람 시간을 많이 먹는 영역이었는데, 지금은 꽤 높은 수준으로 위임할 수 있게 된 것 같습니다.

마찬가지로 이번 마이그레이션은 단순히 데이터를 옮긴 작업을 넘어 제가 이 프로젝트를 진짜로 실사용 단계까지 밀고 갈 수 있게 만든 핵심 과정이었습니다. 새 도구를 만드는 건 재밌습니다. 하지만 기존 도구를 떠나는 건 완전히 다른 문제입니다. 적어도 이번 프로젝트에서 그 간극을 잡아준 건 스크린샷과 생성형 AI를 이용한 마이그레이션 방식이었습니다.

직접 유료 앱을 대체하고 얻은 결론

모든 작업이 끝나고, 기존에 쓰던 유료 루틴 앱의 구독을 해지했습니다. 물론 연 3만 원대 금액이 아주 부담이 큰 건 아니었습니다. 사실 그 정도면 잘 만든 서비스를 편하게 쓰는 비용으로 충분히 낼 수 있는 돈이죠. 그만큼 괜찮은 앱이라 처음엔 굳이 이걸 직접 만들어야 하나 싶은 마음도 있었습니다. 그런데 막상 만들어 며칠 써보니까 생각이 꽤 달라졌습니다. 단순히 돈을 아낀 것보다 이제야 진짜 제 방식에 맞는 도구를 가졌다는 만족감이 훨씬 컸거든요.

진짜 내 방식에 맞는 도구

제 입장에서 가장 큰 변화는 대시보드 활용입니다. 기존 서비스의 대시보드도 충분히 괜찮았지만, 어디까지나 그건 서비스가 정의한 방식으로 보여주는 정보였습니다. 반면 이번에는 제가 궁금한 흐름을, 제가 보고 싶은 방식으로 바로 볼 수 있었습니다. 어떤 루틴이 제 일상에서 더 중요한지, 이번 달에 루틴이 무너진 시점은 언제였는지, 연간 기준으로 보면 어떤 패턴이 반복되는지 같은 것들이 훨씬 더 직관적으로 보였습니다. 남이 잘 만들어준 도구를 쓰는 것과 내가 정말 보고 싶던 화면을 직접 구현한 도구를 쓰는 건 생각보다 차이가 컸습니다.

데이터를 제가 직접 관리하는 점도 만족스럽습니다. 이건 써보기 전에는 생각보다 덜 중요한 느낌인데, 막상 경험해보니 무시하기 어렵더라고요. 특정 서비스에 제 중요한 기록이 종속되지 않고, 제가 이해할 수 있는 구조로 쌓아, 필요하면 가공해 다시 읽고, Claude에게 질문까지 던질 수 있다는 점이 좋았습니다. 이 프로그램이 어느 순간부터는 기록 도구라기보다 생활 데이터 실험실 같은 느낌도 들기 시작했습니다.

작고, 빠르고, 바로 쓸 수 있는 실험

물론 모두에게 이 방식을 그대로 추천하긴 어렵습니다. 비개발자 입장에서는 여전히 진입장벽이 있습니다. Obsidian을 다룰 줄 알아야 하고, Git으로 동기화하는 흐름도 이해해야 하고, 중간에 꼬이면 직접 고쳐야 하니까요. 누군가에게는 그냥 월 구독료나 연 구독료를 내고 검증된 서비스를 계속 쓰는 편이 훨씬 합리적일 수 있습니다. 실제로도 그 선택이 더 맞는 사람은 많을 겁니다.

그런데 이런 게 익숙한 개발자라면 또 다릅니다. 저는 이런 개인용 도구 제작이 개발자에게 꽤 좋은 실험이라고 생각합니다. 작고, 빠르고, 바로 쓸 수 있기 때문입니다. 거창한 사이드 프로젝트는 시작부터 부담이 큽니다. 기획도 해야 하고, 화면도 만들어야 하고, 중간에 지치기도 쉽죠. 반면 개인용 도구는 문제 정의가 명확합니다. 내가 불편하면 시작하고, 내가 만족하면 끝입니다. 게다가 완성 후 바로 실사용으로 이어지기 때문에, 작은 개선이 곧바로 체감됩니다. 이게 생각보다 중독성이 있습니다.

낮아진 진입장벽만큼 중요한 것

이번 일을 하면서 저는 요즘 제품 개발의 진입장벽이 정말 많이 낮아졌다는 걸 다시 느꼈습니다. 적어도 대규모 서비스가 아니라면, 이제 개발할 수 있는지 없는지 여부는 예전만큼 큰 문제가 아닐 수도 있겠다는 생각이 들었습니다. 물론 여전히 잘 만드는 건 어렵고, 안정적으로 운영하는 건 더 어렵습니다. 하지만 적어도 작게 만들어서 직접 써보는 단계까지 가는 건 훨씬 쉬워졌습니다. 예전에는 아이디어가 있어도 머릿속에만 남아 있던 것들이, 지금은 꽤 높은 확률로 실제로 작동하는 무언가가 됩니다.

그래서 오히려 더 중요해진 건 개발 자체보다 무엇을 만들지, 왜 그걸 만들어야 하는지, 계속 쓰게 만들려면 어떤 구조여야 하는지 같은 문제인 것 같습니다. 만드는 건 점점 쉬워지고 있습니다. 대신 아무거나 만들면 안 되고, 진짜 내 문제를 해결해 줄 영역을 골라야 합니다.

그와 함께 이제 제품 영역의 진짜 싸움은 아이디어와 활용 방식, 더 나아가 마케팅 쪽으로 넘어가고 있다는 생각도 들었습니다. 개인용 도구는 내가 쓰면 그만이지만, 그걸 제품으로 만들고 누군가에게 쓰게 만드는 건 또 완전히 다른 문제니까요. 대규모 서비스가 아니면 개발 자체는 예전보다 훨씬 덜 위협적인 장애물이 됐습니다. 대신 이제는 “무엇을 왜 만들 것인가”가 훨씬 더 중요합니다.

마치며

이제 저는 전보다 가볍게 무언가 만들어 볼 생각을 합니다. 꼭 앱을 새로 출시하겠다는 거창한 목표가 아니어도 괜찮습니다. 내가 매일 반복하는 귀찮은 일, 기존 도구를 쓰면서 계속 아쉬웠던 부분, 내 방식대로 하고 싶었던 지점들. 그런 것들이 전부 작은 프로젝트의 출발점이 될 수 있겠다고 느낍니다. 바이브 코딩의 진짜 재미도 거기에 있는 것 같습니다.

이번에 유료 루틴 앱 하나를 대체해본 건, 어쩌면 아주 작은 사례일 뿐입니다. 그런데 저는 오히려 그래서 더 의미가 있다고 느꼈습니다. 세상을 바꿀 서비스를 만든 것도 아니고, 대단한 SaaS를 출시한 것도 아닙니다. 그냥 제가 매일 쓰는 도구 하나를 제 손에 맞게 다시 만든 것뿐이죠. 그런데 그것 하나만으로도, 지금 개발자에게 열린 가능성이 전보다 훨씬 많다는 걸 분명히 느낄 수 있었으니까요.