2026년의 직접 구축(Build) vs 구매(Buy): 1인 개발자가 월 100달러 규모의 AI로 6개의 SaaS 도구를 대체한 방법

pheidi.training에서 교차 게시되었습니다. 이 글은 개발자 버전입니다 — 동일한 결정 사항을 담고 있지만, 더 많은 코드와 인증(auth) 상세 내용을 포함합니다.

대부분의 직접 구축(build) 대 구매(buy) 조언은 구식입니다. 제 경력의 대부분 동안 "직접 X를 만들지 마라"는 말은 사실이었습니다. 엔지니어링 시간이 병목 현상(bottleneck)이었기에, 핵심 제품이 아닌 것은 무엇이든 빌려 썼습니다. 하지만 2026년에는 병목 현상이 이동했습니다. 일주일 동안 타이핑해야 했던 집중적인 기능이 이제는 오후 한때의 프롬프팅(prompting)과 검토만으로 가능해졌습니다. 그래서 저는 다시 계산을 시작했고, 계속해서 _직접 구축(build)_이라는 결론에 도달하고 있습니다.

배경 설명: 저는 적응형 러닝 트레이닝 앱인 Pheidi의 유일한 운영자입니다. 기술 스택은 ASP.NET Core + Blazor, C#, Azure SQL입니다. 경주, 일정, 그리고 사용자의 기록을 입력하면, 앱이 실생활에 맞춰 생성하고 지속적으로 재계획을 세웁니다. 팀도, 계약직도 없습니다. 모든 아키텍처(architectural) 결정은 "한 사람이 이것을 영원히 책임질 수 있는가?"라는 필터를 거칩니다.

이 글 전체의 관점을 재설정하는 숫자부터 시작하겠습니다. 제가 사용하는 전체 AI 비용 — 페어 프로그래밍을 하는 어시스턴트와 제 에이전트(agents)가 사용하는 토큰(tokens)을 합쳐 — 은 대략 월 $100입니다. 이것이 대체한 SaaS 스택(피드백, 이메일 자동화, 분석, AI 기능 레이어, 그리고 몇몇 기타 도구들)은 각각 개별적으로 약 $100 정도의 비용이 들었을 것입니다. 이 6개를 묶으면 제 총 지출의 3~4배에 달하며, 갱신될 때마다 가격이 상승하여 무기한으로 비용이 늘어납니다.

모두가 빌려 쓰는 세 가지 카테고리가 있습니다. 그것들을 직접 구축하는 것이 어떠했는지 소개합니다.

피드백(Feedback): 월 $79 대신 300줄의 코드

기본적인 방법은 Canny, Intercom 또는 UserVoice를 붙이는 것입니다. 견고한 도구들이지만, 월 약 $79의 비용이 발생하고, 제 UI에 제3자 위젯(third-party widget)을 삽입하며, 제가 가진 가장 가치 있는 신호(러너들이 무엇을 요구하는가)를 제가 제어할 수 없는 인프라(infrastructure)에 저장하게 됩니다.

제가 만든 버전은 세 부분으로 구성됩니다:

내비게이션 바(navbar)에 슬라이드 아웃 방식의 피드백 패널 — Razor 컴포넌트 단 하나, 197줄로 구성. 유형(Type), 제목(title), 본문(body), 그리고 자동으로 수집된 원본 페이지 URL 포함.
FeedbackSubmissions 테이블에 데이터를 저장하는 44줄짜리 서비스로 뒷받침되는 POST /api/feedback.
쓰기 작업 후 내 개인 편지함으로 전송되는 백그라운드 알림.

총합: 약 300줄, 그리고 눈에 띄게 관리자 대시보드(admin dashboard)가 없음. 그 생략이야말로 핵심 기능입니다. 모든 제출 내용은 제가 하루 종일 분류(triage), 별표 표시, 답장을 보내는 이메일로 바로 전달됩니다. 만약 통합된 뷰(aggregate views)가 필요해지더라도, 그것은 타인이 노출하기로 결정한 보고서가 아니라 제가 소유한 데이터를 대상으로 한 SQL 쿼리 한 번이면 충분합니다.

주의 깊게 살펴볼 유일한 결정 사항은 순서입니다: 먼저 저장하고, 그다음에 알림을 보내며, 알림이 절대 프로세스를 차단(block)하게 두지 마십시오.

await _db.FeedbackSubmissions.AddAsync(submission);
await _db.SaveChangesAsync();        // 다른 무엇보다 먼저 영구 저장(durable) 보장
_ = _notifier.SendAsync(submission); // fire-and-forget; SMTP의 일시적 오류가 피드백을 삼키게 둘 순 없음

이메일을 놓친다? 짜증 나는 일입니다. 사용자의 메시지를 놓친다? 절대 안 될 일입니다.

이메일 자동화: 연락처당 비용을 지불하는 대신 약 1,200줄의 코드로 해결

이것이 사람들이 실제로 체감하는 예산 항목입니다. Mailchimp / ConvertKit / Customer.io 같은 서비스는 환영 메일(welcome), 드립 캠페인(drip), 행동 트리거(behavioral triggers)를 원하는 순간부터 비용이 급격히 상승하며, 비용 측정 기준은 리스트 규모에 따라 올라갑니다.

Pheidi는 모두 직접 구현한 다섯 가지 유형의 메일을 보냅니다:

환영 메일 (Welcome): 가입 시 발송되며, Reply-To를 제 실제 편지함으로 설정하여 답장이 티켓이 아닌 대화가 되도록 합니다.
오전 5시 운동 알림: 각 러너의 시간대에 맞춰 발송 — 오늘의 세션, 목표 페이스, 그리고 실시간 예보를 바탕으로 계산된 열 조절(heat tweak) 정보 포함. 호스팅된 서비스(hosted service)가 10분마다 스캔하며, 러너당 하루 한 번으로 제한됩니다.
단계 전환 (Phase transitions): (기초→빌드→피크→테이퍼링), 매시간 스캔하며 플랜별로 중복을 제거합니다.
3일 차 체크인: 플랜을 이미 구축했는지 여부에 따라 분기됩니다.
14일 차 독려 (Nudge): 플랜은 있지만 기록된 러닝이 전혀 없는 경우 발송됩니다.

전체 스케줄러/템플릿/자격(eligibility) 레이어는 약 1,200줄의 C# 코드로 이루어져 있습니다. 제가 다른 개발자에게 실제로 보여주고 싶은 부분은 중복 제거(dedup) 로직입니다. 큐(queue)도 없고, 분산 잠금(distributed lock)도 없습니다. 그저 여러 앱 인스턴스에 걸쳐 안전한 원자적 조건부 UPDATE 문일 뿐입니다:

UPDATE Plans
SET PhaseEmailSentUtc = @now
WHERE Id = @planId AND PhaseEmailSentUtc IS NULL;  -- @@ROWCOUNT == "내가 레이스에서 이겼는가?"

제가 넘지 않는 경계선은 바로 실제 전송(delivery) 단계입니다. Azure Communication Services는 메일을 전송망에 올리고 메시지당 0.001센트 미만의 비용을 청구합니다. 이것이 제가 누구에게나 전달하는 원칙입니다 — 인프라는 빌려 쓰고, 워크플로우(workflow)는 직접 구축하라. 전송(Transport), DNS, 호스팅은 진정한 규모의 경제가 작동하는 범용 상품(commodities)입니다. 하지만 어떤 사람이 어떤 메시지를 언제 받을 것인가는 제품 로직(product logic)이며, 바로 이 지점이 SaaS가 마진을 붙이는 부분입니다. 이는 결코 어렵지 않았습니다. 그저 지루했을 뿐이며, 지루한 작업이야말로 AI 어시스턴트가 증발시켜 버리는 영역입니다.

로직을 한곳에 모아둠으로써 발생하는 부수 효과는 다음과 같습니다. 새벽 5시에 발송되는 제 이메일은 앱 내 플랜과 동일한 날씨 조정 코드를 호출합니다. 이들은 하나의 구현체이기 때문에 논리적으로 어긋날 수가 없습니다.

에이전트 도구(Agentic tools): AI 미들웨어 계층 대신 몇 달러의 토큰 비용

가장 최신 카테고리이자, 오늘날 제가 가장 강력하게 주장하고 싶은 부분입니다. 사람들의 본능적인 반응은 당신과 당신의 데이터 사이에 위치하는 레이어로서 "AI 기능"을 구매하는 것입니다. 이는 분석 대시보드(analytics-dashboard) 패턴의 재림입니다. 1인 개발자에게는 이 방식이 뒤집혀야 합니다. 몇 달러의 토큰 비용을 지불하고, 에이전트가 실제 데이터베이스와 실제 제품에 직접 접근하게 하세요. 미들웨어 계층도, 사용자당 과금(per-seat tax)도 필요 없습니다.

구축 사례 #1: 앱 내부의 MCP 서버. Model Context Protocol (MCP)을 통해 8개의 도구를 구현했습니다 — get_today_workout, list_upcoming_workouts, record_workout, report_injury, add_vacation, update_profile, submit_feedback, get_active_plan. Claude와 같은 MCP 클라이언트가 연결되면 사용자는 그저 말하기만 하면 됩니다: "오늘 러닝 중에 종아리가 팽팽하게 당기는 느낌이었어 — 기록해주고 이번 주는 강도를 좀 낮춰줘.". 그러면 이 요청은 report_injury + record_workout으로 확장되며, 플랜은 UI 경로를 거쳤을 때와 동일하게 재계획됩니다.

도구 자체는 사소했습니다 — 418줄에 불과했습니다. 진짜 작업은 인증(auth)이었습니다. 동적 클라이언트 등록(dynamic client registration)을 포함한 완전한 OAuth 2.1 + PKCE 흐름을 구현하여, 제가 수동으로 API 키를 발급하지 않아도 어시스턴트가 사용자 계정에 연결될 수 있도록 했습니다. 약 500줄의 코드와 일련의 RFC(Request for Comments) 문서들이 필요했다고 할 수 있지만, 이는 단 한 번의 비용만 발생합니다. 이제 모든 현재 및 미래의 MCP 클라이언트는 제 측면에서의 개별 벤더 통합 없이도 Pheidi와 연동됩니다.

두 번째 구축물: 동일한 아이디어를 내부를 향해 적용한 것. 피드백 대시보드는 없었습니다, 기억하시나요? 제품 신호(product signal)를 얻고 싶을 때, 저는 코딩 에이전트(coding agent)를 제 자체 DB로 향하게 합니다 — "지난달의 기능 요청들을 테마별로 클러스터링해줘" — 제가 소유한 데이터를 대상으로 단 몇 푼의 토큰 비용만 지불하면 됩니다. SaaS 대시보드는 누군가가 미리 짜놓은 쿼리(query)에 UI(chrome)를 씌워놓은 고정된 집합일 뿐입니다. 원시 읽기 권한(raw read access)을 가진 에이전트는 아무도 미리 구축할 생각을 하지 못한 쿼리를 포함하여 모든 쿼리를 수행할 수 있습니다.

솔직한 주의사항

"그냥 직접 만들어라"라는 조언은 과하게 교정될 위험이 있으므로, 경계선을 설정하는 것이 중요합니다:

이것은 규모를 키우는(scale up) 것이 아니라, 규모를 줄이는(scale down) 방식입니다. 팀 단위로 움직인다면, 도구의 RBAC(역할 기반 액세스 제어), 감사 로그(audit log), 온보딩(onboarding)은 그 비용만큼의 가치를 할 수 있습니다. 월 전송량이 백만 건에 달한다면, 도달률(deliverability)은 단순한 기능이 아니라 하나의 직업(job title)이 됩니다.
제가 절대 소유하지 않을 것들이 있습니다: 결제(payments), 원시 메일 전송(raw mail transport), 호스팅(hosting). 인프라는 빌려 쓰고, 워크플로우(workflow)를 구축하십시오 — 그리고 "인프라"는 보기보다 훨씬 더 넓은 범위를 포함합니다.
유지보수는 영구적으로 저의 몫입니다. 3일 차에 발송되는 이메일에 버그가 생기면 담당자는 정확히 한 명뿐입니다. 대시보드가 없는 약 300줄 규모의 시스템은 공격 표면(surface area)이 거의 없기 때문에 지금까지는 문제가 없었습니다. 저는 의도적으로 이들을 작게 유지합니다.

핵심 요약 (Takeaway)

모든 구독은 단순한 비용 지출 그 이상입니다. 그것은 또 다른 대시보드, 또 다른 로그인, 관리해야 할 또 다른 통합, 그리고 걱정해야 할 또 다른 내보내기(export)를 의미합니다. 20개의 구독을 사용한다면, 그것들이 제 값을 하기 전부터 이미 파트타임 운영 업무(ops job)가 되어버립니다. 그리고 이 비용들은 조용히 복리로 쌓입니다: $29 + $79 + ... 각각은 단독으로 방어 가능한 금액이지만, 서로 거의 연관성도 없는 기능들을 위해 매달 수백 달러를 영원히 지불하게 됩니다.

저의 월 약 100달러 지출은 정반대의 형태를 띱니다. 계속해서 오르기만 하는 임대료 대신, **제가 온전히 소유하는 코드 (code I own outright)**를 사는 것이죠. 이것이 지금 가능한 이유는 제가 뛰어난 엔지니어이기 때문이 아닙니다. 집중되어 있고, 지루하며, 이미 잘 알려진 코드(피드백 양식, 드립 엔진 (drip engine), OAuth 인증 과정 (OAuth dance))의 비용이 저렴해졌고, AI 어시스턴트들이 이러한 잘 알려진 문제들을 해결하는 데 매우 탁월하기 때문입니다. 비용은 언제나 타이핑(typing)에 있었습니다.

그래서 저는 이제 모든 구매를 하기 전에 다음과 같은 질문을 던집니다: 제품(product)인가, 아니면 배관(plumbing)인가? 배관이라면 → 임대하십시오. 제품이라면 → 데이터는 당신의 데이터베이스에 있고, 정확히 당신이 필요한 기능만을 수행하며, 그 이상의 군더더기도 없는 상태로 소유하는 데 단 몇 시간(an afternoon)이면 충분할 수도 있습니다.

이 모든 배관(plumbing)이 서비스하는 앱은 당신의 삶에 맞춰 적응하는 계획인 Pheidi입니다. 하지만 진심으로 말씀드리자면 — 우선 피드백 양식부터 만드세요.