LLM 시대의 개인용 소프트웨어: 구독형 SaaS vs 바이브 코딩

핵심 요약

LLM(대형 언어 모델) 덕분에 주말에 직접 "바이브 코딩"으로 나만의 앱을 만드는 것이, 많은 구독형 SaaS를 계속 결제하는 것보다 현실적인 선택지가 되어가고 있다.

다만 모든 소프트웨어가 이렇게 대체될 수 있는 것은 아니며, 시간·돈·품질·데이터·지속 가능성 사이의 균형을 어떻게 잡을지가 핵심 쟁점이다.

SaaS 구독 피로감과 '이 돈 값 하냐'는 질문

많은 사용자가 이제 "이걸 매달 돈 내고 쓸 가치가 정말 있나?"를 본능적으로 따진다.
이메일·패스워드 관리자·DNS 같은 핵심 서비스는 연 50~100달러 정도의 가격에도 납득하지만, 단순한 할 일 관리, 캡처, 메모, 작은 자동화 도구에까지 월 10달러씩 붙는 구조에는 피로감을 느낀다.

여기서 중요한 기준은 "매달 10달러의 가치를 실제로 돌려주는가"이다.
GPU 연산처럼 명확한 인프라 비용이 있거나, 전문 툴처럼 생산성을 크게 끌어올리는 경우는 수백 달러도 지불하지만, 단순 CRUD 앱이 편의성만으로 고가 구독을 요구하면 "차라리 내가 만든다"로 기울기 쉬워진다.

소비자는 예전보다 훨씬 더 가격 대비 가치를 비교한다.
1Password, Fastmail처럼 "내 디지털 생명줄" 급이 연 60달러라면, 그보다 덜 중요한 앱은 그 이하의 가치만 인정받게 되고, 많은 SaaS는 이 기준을 통과하지 못한다.

일회성 구매 vs 구독: 왜 이렇게까지 구독이 많아졌나

원칙적으로는 "계속 서버 비용·인프라·지원이 드는 서비스 → 구독, 한 번 만들면 끝나는 앱 → 일회성 구매"가 더 직관적이다.
하지만 개발자 입장에서는 구독이 가장 안정적인 수익 모델이기 때문에, "지속적인 개발"을 명분으로 사실상 모든 것을 구독으로 포장하는 경향이 생겼다.

문제는 대부분의 개인용 앱이 매달 새로운 기능을 필요로 하지 않는다는 점이다.
사용 목적이 크게 변하지 않는 캡처 도구, 텍스트 편집기, 간단한 업무 도구는, 사용자 관점에서 "한 번 사면 끝"이면 충분한 경우가 많다.

일부는 JetBrains처럼 "구독을 유지하면 최신 버전, 구독 종료 후에도 특정 버전은 영구 사용" 같은 혼합 모델을 제공하지만, 대다수 앱은 이런 타협조차 제시하지 않는다.
그 결과 사용자는 "왜 이 정도 기능에 계속 내야 하지?"라는 반감을 쌓고, LLM이 대안이 되면서 실제로 구독을 해지하는 방향으로 움직이고 있다.

플랫폼 체인지(플랫폼 churn)와 일회성 소프트웨어의 비극

일회성 구매 소프트웨어가 지속되기 어려운 이유 중 하나는 플랫폼의 잦은 변화다.
많은 사용자는 예전 버전의 워드, 포토샵, 운영체제를 더 선호하지만, OS·API·라이브러리의 변화 때문에 오래된 버전을 계속 쓰기 힘들어진다.

macOS처럼 매년 큰 업데이트를 하며 API를 자주 바꾸는 플랫폼에서는, 개발자가 구버전 유지만으로도 적지 않은 비용을 감수해야 한다.
Linux 데스크톱도 겉으로는 패키지 매니저 덕분에 매끄러워 보이지만, glibc 포함 각종 라이브러리의 호환성이 자주 깨지는 편이라, 사실상 배포판의 패키지 관리 시스템이 "끊임없는 맞춰주기"를 수행하고 있다.

이런 환경에서는 "한 번 팔고 끝" 모델이 유지되기 어려워지고, 자연스럽게 구독으로 비용을 나눠 받는 방향으로 움직인다.
사용자 입장에서는, 구독 모델이 플랫폼의 '쓸데없는 진화'에 끌려가는 비용처럼 느껴지는 지점이다.

바이브 코딩: LLM으로 주말에 만드는 '나만의 SaaS 대체품'

바이브 코딩(vibe coding)은 LLM에게 "이런 느낌의 앱 만들어줘" 정도의 대화형 지시를 하면서, 점진적으로 기능을 다듬어가는 개발 방식이다.
여기서 중요한 점은 "수만 명이 써도 되는 완성도"가 아니라 "나 혼자 쓰기에 충분한 유용성"만 맞추면 된다는 것이다.

예를 들어, 화면 녹화 SaaS를 대신해, 로컬에서 카메라와 화면을 녹화하고, 끝난 뒤 간단히 자를 수 있는 도구를 주말에 만들어 쓴다.
또는, 자신에게 꼭 맞는 할 일 관리/습관 추적 툴을 직접 만들면, 기존 SaaS의 80% 수준 기능에 자신만의 맞춤 기능을 더한 도구를 비교적 짧은 시간에 얻을 수 있다.

이렇게 만든 도구는 인증·결제·팀 기능·다국어 지원·완벽한 에러 처리 같은 "제품급" 요건을 충족하지 못할 수 있다.
하지만 사용자가 한 명일 때, 이러한 부족함은 치명적이지 않으며 오히려 단순함과 통제가 장점이 될 수 있다.

시간 vs 돈: "내 시간은 비싸다" 논리의 숨은 함정

많은 사람이 "내 시급을 생각하면, 앱 만드는 시간보다 구독이 싸다"고 말한다.
하지만 실제 생활을 보면, 여유 시간 대부분을 뉴스·유튜브·SNS로 보내면서도, 정작 자기에게 필요한 도구를 만드는 데에는 "내 시간은 너무 가치 있다"고 말하는 모순이 생기기도 한다.

물론 모든 사람이 24시간 노동을 하는 것은 아니며, 휴식·여가도 중요한 시간이다.
그럼에도, 스스로 쓸 수 있는 도구를 LLM과 함께 만드는 시간은 단순 소비와는 다른 '투자'에 가깝다.
직접 만들며 기술을 익히고, 자신의 업무 흐름을 더 깊게 이해하게 되고, 이후 비슷한 문제를 더 빨리 해결할 수 있는 역량이 쌓인다.

반대로, 이미 자신의 핵심 업무에서 높은 시급과 경력 성장이라는 복리 효과를 얻고 있는 사람은, 그 역량을 키우는 쪽에 시간을 쓰고, 나머지는 기꺼이 구독으로 해결하는 편이 합리적일 수 있다.
결국 "무조건 구독이 낫다"도, "무조건 직접 만들어야 한다"도 아닌, 자신의 삶과 에너지, 성장 방향을 기준으로 선택해야 한다.

데이터 소유권과 프라이버시: 구독 vs 로컬 도구

직접 만든 도구의 큰 매력 중 하나는 데이터가 온전히 내 손 안에 있다는 점이다.
로컬 앱을 만들어 쓰면, 이메일·카드 정보·사용 데이터가 외부 서버로 나가지 않고, 계정 생성이나 약관 동의 없이도 필요한 기능을 쓸 수 있다.

반대로 SaaS를 이용하면, 로그인과 결제, 클라우드 저장이 기본값이 된다.
대부분의 서비스는 Stripe 같은 결제 대행사를 쓰고, 나름의 보안 관행을 지키지만, 근본적으로 "내 정보가 남의 서버 어딘가에 있다"는 사실은 변하지 않는다.

특히 개인적인 메모, 습관 기록, 민감한 업무 데이터 등은, LLM을 활용해 로컬 도구를 만들고, 파일 또는 자체 DB에 저장하는 방식으로 "클라우드를 통하지 않는 디지털 생활"을 구성할 수 있다.
이 지점에서 "토큰 비용"보다 데이터 통제감과 마음의 평온이 더 큰 가치가 되기도 한다.

타인의 소프트웨어를 통해 배우는 것 vs 스스로 만드는 것

상용 앱과 오픈소스 소프트웨어는 단순한 도구를 넘어, 수많은 개발자가 쌓아온 경험과 판단이 응축된 결과물이다.
우리가 사용하는 소프트웨어 대부분은, 누군가가 문제를 깊이 고민하고 수십·수백 번의 시행착오 끝에 정제한 인터페이스와 워크플로우의 집합이다.

오픈소스 코드를 읽고, 상용 앱의 설계를 관찰하면서, 개발자는 "좋은 구조와 UX란 무엇인가"를 배운다.
만약 LLM이 만들어 주는 결과물만 쓰고, 그 내부 원리나 기존 장인들이 쌓아온 패턴을 보지 않는다면, 장기적으로는 소프트웨어 공예(craft)에 대한 이해가 얕아질 수 있다.

한편으로는, LLM 자체가 이미 이 축적된 지식을 학습한 결과물이기도 하다.
지금 세대의 LLM은 인간 장인의 산물을 흡수한 상태이고, 앞으로는 LLM이 만든 코드 위에 다시 LLM이 학습하는 순환이 시작된다.
장기적으로 "이해된 코드"의 비율이 줄어들 위험을 인식하면서, 의식적으로 좋은 코드와 제품을 탐구하는 태도가 필요하다.

오픈소스, 복제, 그리고 '집에서 요리해 먹는 소프트웨어'

오픈소스는 오래전부터 "가져다 보고, 배워서, 나에게 맞게 고치는" 문화를 제공해 왔다.
LLM과 결합하면, 특정 기능이 구현된 오픈소스 프로젝트를 참고해 자신의 스택으로 포팅하거나, 일부만 떼어와 재조합하는 일이 훨씬 쉬워진다.

이 과정에서 "OSS를 그냥 베끼기만 하는 거 아니냐"는 윤리적 고민도 등장한다.
하지만 라이선스를 지키고, 배포 범위 내에서 요구되는 공개 의무를 준수한다면, 개인용 또는 사내용 도구를 만드는 것은 오픈소스 정신에 어긋나지 않는다.
다만, 가능하다면 버그 수정이나 개선 사항을 원 프로젝트에 돌려주는 것이 건강한 생태계를 위해 바람직하다.

한 가지 흥미로운 변화는, "모두가 쓰는 하나의 거대 오픈소스 앱"보다 "각자 필요에 맞게 포크해서 쓰는 작은 도구들"이 늘어날 수 있다는 점이다.
이는 마치 외식 산업이 존재하면서도, 각자가 집에서 요리를 해 먹는 문화가 공존하는 것과 비슷한 양상이다.

인사이트

LLM 덕분에 "작은 SaaS를 구독할까, 주말에 직접 만들어 쓸까"라는 선택지가 현실이 되었다.
할 일 관리, 캡처, 간단한 자동화, 개인용 대시보드처럼 나만 쓰는 도구는, 구독 비용·데이터 통제·맞춤화 관점에서 직접 만드는 쪽이 점점 더 매력적이다.

실천 관점에서, 다음과 같이 접근해 볼 수 있다.

먼저, 매달 돈 나가는 구독 목록을 쭉 적어 보고, "이건 내 데이터/습관/업무 흐름과 깊이 얽혀 있지만 기능은 단순하다" 싶은 것부터 후보로 삼는다.

그 다음, LLM에게 "이 앱의 어떤 기능을 꼭 유지하고 싶은지, 어떤 건 불필요한지"를 설명하고, 가장 핵심적인 80% 기능만 먼저 구현하는 것을 목표로 삼는다.

마지막으로, 이 도구가 안정적으로 돌아가며 자신에게 충분한 가치를 준다고 느껴지면, 그때 구독을 해지하고, 남은 시간·돈·집중력을 더 중요한 도구(정말 계산 능력·신뢰성·지원이 필요한 SaaS)에 재분배하면 된다.

핵심은 "모든 SaaS를 없애자"가 아니라, LLM 시대에 새로 생긴 선택지를 인식하고, 내 삶과 일에 맞는 조합을 스스로 설계하는 것이다.

출처 및 참고 : Your app subscription is now my weekend project | Hacker News

개인적인 생각: 만들기의 즐거움과 비용 사이

LLM으로 뚝딱 만드는 개인용 도구는 경제적으로 꼭 이득이라고 말하기 어렵다. 토큰 비용과 전기세, 클라우드·AI 구독료, 여기에 주말마다 조금씩 들어가는 개발·유지보수 시간을 모두 합치면, 그냥 기존 유료 서비스를 묵묵히 결제하는 편이 훨씬 싸게 먹힐 때도 많다. 이미 잘 만들어진 제품을 비슷하게 다시 만드는 건 어찌 보면 "바퀴의 재발명"이고, 순수 효율 관점에선 설명이 잘 안 된다.

그럼에도 LLM으로 직접 무언가를 만드는 경험은 건프라 조립이나 기계식 키보드 튜닝과 비슷한 쪽에 가깝다고 느낀다. 완성품을 사는 게 싸고 편한 걸 알면서도, 부품을 고르고 조립하고 미세하게 손보는 과정 자체에서 재미와 만족이 나온다. 내가 자주 쓰는 흐름을 알고, 그 흐름을 코드와 프롬프트로 한 줄씩 구현해 나가면서, "이건 진짜 내 손맛이 들어간 도구다"라는 감각을 얻는 것이 핵심 보상에 가깝다.

한편으로 "AI로 유료 서비스를 복제해낸 나"를 과시하는 분위기에는 약간의 어색함도 느낀다. 이미 존재하는 서비스를 비슷하게 따라 만든 것뿐인데, 그걸 대단한 성취처럼 떠들어야 하나 싶은 지식의 저주 같은 거리감이 있다.

그럼에도, 선택지가 거의 없는데도 몇 만 원씩 요구하는 자잘한 툴들에 대해 이제는 스스로 대체제를 "쉽게" 만들 수 있게 된 점만큼은 순수하게 좋다. 거창한 자랑거리가 아니라, 필요할 때마다 작은 도구를 직접 꺼내 쓸 수 있는 자급자족 능력이 생겼다는 사실이 마음을 편하게 해 준다.

SaaS를 만드는 쪽에서는, 단순히 "이 기능 우리도 만들 수 있다"는 식의 비교에서 벗어나야 한다. LLM과 바이브 코딩으로는 흉내 내기 어려운 운영 노하우, 안정적인 아키텍처, 정교한 온보딩 플로우와 UX 설계 같은 것들을 의도적으로 드러내고, 사용자가 직접 만들 때 간과하기 쉬운 리스크(보안, 장애 대응, 데이터 백업, 협업 워크플로우 등)를 대신 떠안아 준다는 점을 더 적극적으로 어필할 수 있다면, "이 돈을 왜 내야 하지?"라는 질문에 대한 답도 함께 제공하는 셈이 된다.

사용자 입장에서는 처음부터 모든 걸 직접 만드는 쪽으로 달려가기보다, 이미 잘 만들어진 서비스 위에 LLM을 얹어 효율을 끌어올리는 방향이 현실적인 출발점일 수 있다. 예를 들어 문서화를 위해 GitBook을 통째로 새로 만드는 대신, GitBook이라는 완성된 그릇은 그대로 쓰되, 여기에 들어갈 매뉴얼 초안과 구조를 AI로 빠르게 생성하고 다듬는 식이다. 즉, "서비스 자체를 대체하는 나만의 앱"보다는, "기존 SaaS를 더 잘 쓰게 해 주는 나만의 보조 도구"를 만드는 쪽이 비용·시간·리스크 측면에서 훨씬 좋은 초기 균형점이 될 수 있다.

요약하면, SaaS 제공자는 LLM으로 쉽게 복제할 수 없는 무형 자산과 운영 역량을 전면에 내세우고, 사용자는 완전한 대체제 만들기보다 기존 서비스의 활용도를 AI로 증폭하는 전략을 택하는 편이 서로에게 더 이득인 구도다.