goodtek의 첫 번째 SaaS를 만들기 시작합니다

요즘 바이브코딩이라는 말을 정말 자주 봅니다.

예전에는 서비스를 하나 만들려면 기획하고, 디자인하고, 개발하고, 배포하고, 운영하는 과정이 꽤 멀게 느껴졌습니다.
아이디어가 있어도 “이걸 실제 서비스로 만들 수 있을까?”라는 질문 앞에서 오래 멈추는 일이 많았습니다.

그런데 이제는 조금 다릅니다.

아이디어만 있으면 AI와 함께 빠르게 화면을 만들고, 기능을 붙이고, 배포까지 해볼 수 있는 시대가 됐습니다. 저도 그 흐름 안에서 여러 실험을 하고 있습니다.

그런데 직접 만들어보니 금방 알게 됐습니다.

서비스는 만드는 것보다 계속 살아 있게 하는 것이 더 어렵습니다.

처음 배포했을 때는 분명 잘 돌아갔습니다.
빌드도 성공했고, 화면도 열렸고, “오, 됐다” 싶은 순간도 있었습니다.

그런데 문제는 그 다음부터였습니다.

어느 날 갑자기 서버가 죽을 수도 있습니다.
API가 응답하지 않을 수도 있습니다.
배포는 성공했다고 나오는데 실제 페이지는 안 열릴 수도 있습니다.
환경변수 하나가 빠져서 기능이 조용히 멈춰 있을 수도 있습니다.

그리고 제일 무서운 건 이겁니다.

사용자는 접속하지 못하고 있는데, 만든 사람만 모를 수 있다.

여기서 100짜리 고통이 시작됩니다.

만드는 속도는 빨라졌는데, 운영의 불안은 그대로 남아 있었습니다.

“내 서비스 아직 살아 있나?”
이 질문이 생각보다 자주 머릿속에 남았습니다.

밤에 잠들기 전에도 한 번 봅니다.

“페이지 잘 열리나?”

아침에 일어나서도 한 번 봅니다.

“어제 밤에 죽은 건 아니겠지?”

솔직히 이건 꽤 현실적인 문제라고 생각했습니다.
특히 혼자 서비스를 만드는 사람에게는 더 그렇습니다.

회사가 있다면 모니터링 팀이 있고, 인프라 담당자가 있고, 장애 대응 프로세스가 있을 수 있습니다.
하지만 사이드 프로젝트를 만드는 개발자, 1인 창업자, 바이브코더에게는 그런 구조가 없습니다.

그래서 ● goodtek의 공식 첫 번째 SaaS는 이 문제에서 시작해보려고 합니다.

내가 만든 앱이 살아 있는지 아는 일

만들려는 서비스는 아주 단순합니다.

내가 만든 웹사이트나 API가 잘 살아 있는지 확인하고,
문제가 생기면 바로 알려주는 서비스입니다.

복잡한 관측성 플랫폼을 만들려는 것은 아닙니다.
대기업용 모니터링 도구를 다시 만들려는 것도 아닙니다.

오히려 반대입니다.

바이브코더가 가장 고통스러워하는 한 가지 문제에만 집중하려고 합니다.

“내 서비스가 죽었는지 모르겠다.”

이 고통지수가 1부터 100까지 있다면, 저는 먼저 100짜리 문제 하나만 해결하고 싶습니다.

대시보드가 화려하지 않아도 됩니다.
설정 항목이 많지 않아도 됩니다.
처음부터 수십 개의 기능이 없어도 됩니다.

대신 이것 하나는 확실해야 합니다.

내 서비스가 죽으면, 내가 바로 알아야 합니다.

처음 생각한 구조는 이렇게 단순합니다.

내 서비스
  └─ 웹사이트 / API 상태 확인
      └─ 응답 없음 또는 오류 감지
          └─ goodtek으로 상태 전송
              └─ 사용자에게 알림

복잡한 구조를 처음부터 만들고 싶지는 않습니다.
처음부터 거대하게 시작하면, 오히려 가장 중요한 문제가 흐려질 수 있습니다.

지금은 살아 있는지 확인한다는 한 문장에 최대한 집중하려고 합니다.

너무 좋은데, 너무 큰 도구들

물론 이미 비슷한 서비스는 많습니다.

Uptime 모니터링 서비스도 있고, 서버 상태 확인 도구도 있고, 로그 수집 도구도 있고, APM 서비스도 있습니다.
대부분 훌륭합니다. 실제로 이미 잘 쓰이는 제품도 많습니다.

문제는 대부분 너무 좋지만, 동시에 너무 큽니다.

처음 서비스를 만든 사람에게는 이런 질문부터 막힙니다.

• 무엇을 설치해야 하지?
• 어디에 코드를 넣어야 하지?
• 헬스체크 엔드포인트는 어떻게 만들어야 하지?
• 서버가 죽었을 때 원인은 어디서 봐야 하지?
• 알림은 어디로 받아야 하지?
• 이걸 내 프로젝트에 AI에게 어떻게 시켜야 하지?

여기서 저는 goodtek만의 한 스푼을 얹고 싶었습니다.

바이브코더가 AI에게 그대로 시킬 수 있는 모니터링 서비스.

그냥 이런 식으로 말할 수 있으면 좋겠습니다.

내 Next.js 프로젝트에 goodtek 상태 체크를 붙여줘.
웹사이트가 정상 응답하는지 확인하고,
문제가 생기면 goodtek으로 상태를 보내도록 설정해줘.

이 정도로 간단해야 합니다.

SDK 설치도 쉽게.
프롬프트도 쉽게.
설정도 쉽게.

목표는 개발자를 위한 복잡한 모니터링 도구가 아닙니다.
목표는 혼자 서비스를 운영할 때 느끼는 가장 큰 불안을 줄여주는 것입니다.

처음부터 거창하게 만들지 않기

이번 제품은 처음부터 많은 기능을 넣지 않으려고 합니다.

오히려 작게 시작합니다.

이 정도면 작아 보일 수 있습니다.

그런데 저는 이 작은 기능이 실제로는 꽤 중요하다고 생각합니다.

서비스를 만드는 사람에게 가장 무서운 건 에러가 나는 것 자체가 아닙니다.

에러가 났는데 모르는 것.

죽었는데 모르는 것.
사용자가 못 들어오는데 모르는 것.
배포 후 깨졌는데 모르는 것.

goodtek의 첫 번째 SaaS는 이 불안을 먼저 잡는 데서 시작합니다.

바이브코더에게 필요한 설치 경험

제가 특히 신경 쓰고 싶은 부분은 설치 경험입니다.

기존 모니터링 도구는 문서를 읽고, 설정을 이해하고, 코드를 붙이고, 알림을 연결해야 하는 경우가 많습니다.
개발자에게는 당연한 과정일 수 있지만, 바이브코딩으로 막 서비스를 만들기 시작한 사람에게는 이 과정이 꽤 부담스럽습니다.

그래서 이 제품은 기능만큼이나 프롬프트 경험이 중요합니다.

예를 들면 이런 식입니다.

goodtek 상태 체크를 이 프로젝트에 추가해줘.

조건:
- /api/health 엔드포인트를 만든다
- 서비스가 정상일 때는 ok 상태를 반환한다
- 오류가 발생하면 goodtek으로 상태를 전송한다
- 필요한 환경변수 이름도 함께 정리한다

이 프롬프트를 Cursor나 다른 AI 코딩 도구에 붙여 넣었을 때,
사용자가 긴 문서를 읽지 않아도 기본 설정이 들어가면 좋겠습니다.

물론 실제로 해보면 분명 예상과 다를 겁니다.

AI가 코드를 이상한 위치에 넣을 수도 있고,
프레임워크마다 구조가 달라질 수도 있고,
환경변수 설정에서 막힐 수도 있습니다.

그래도 이 방향은 분명히 실험해볼 가치가 있습니다.

모니터링 도구를 잘 만드는 것도 중요하지만,
AI에게 잘 시킬 수 있는 도구로 만드는 것도 이제는 중요해졌다고 느낍니다.

goodtek의 첫 번째 작품

● goodtek은 처음부터 거창한 회사를 만들겠다고 시작한 곳은 아닙니다.

AI 자동화, SaaS 개발, 블로그 운영, 커뮤니티 구축 과정을 직접 실험하고 기록하는 작은 테크 실험실에 가깝습니다.

그동안은 인프라를 만들고, 블로그를 세팅하고, 커뮤니티를 고민하고, 배포 구조를 다듬고, 환경변수를 정리하고, 무중단 배포를 붙이는 과정을 기록해왔습니다.

이제는 그 위에 진짜 제품을 하나 올려보려고 합니다.

● goodtek의 공식 첫 번째 SaaS.

바이브코더를 위한 초간단 서비스 생존 확인 도구.

이 제품을 만들면서 기획, 설계, 개발, 배포, 운영, 실패, 수정 과정을 모두 공개적으로 기록해보려고 합니다.

잘 되는 부분만 보여주지는 않겠습니다.

막히는 부분도 기록하겠습니다.
이상한 선택을 했다가 되돌리는 과정도 기록하겠습니다.
처음에는 그럴듯했지만 실제로 만들어보니 별로였던 기능도 기록하겠습니다.

이게 제가 하고 싶은 빌드인 퍼블릭입니다.

완성된 성공담이 아니라,
지금부터 직접 만드는 기록입니다.

먼저 정리한 MVP 기준

현재 머릿속에 있는 MVP 기준은 이렇습니다.

• 웹사이트가 정상적으로 열리는지 확인하기
• API가 일정 시간 안에 응답하는지 확인하기
• 응답 실패 또는 타임아웃이 발생하면 장애로 판단하기
• 장애 발생 시 알림 보내기
• 간단한 상태 페이지 제공하기
• Node.js, Next.js 환경에 붙일 수 있는 초간단 SDK 만들기
• 바이브코딩 도구에 붙여 넣을 수 있는 설치 프롬프트 제공하기

이 리스트를 보면 별것 아닌 것처럼 보일 수도 있습니다.

그런데 저는 일부러 이렇게 작게 잡았습니다.

처음부터 모든 걸 다 하려고 하면, 결국 아무것도 제대로 검증하지 못할 가능성이 큽니다.
지금 검증하고 싶은 건 하나입니다.

혼자 서비스를 만드는 사람이 이걸 보고 “아, 이건 바로 써보고 싶다”고 느낄 수 있는가.

그게 첫 번째 기준입니다.

앞으로 기록할 것들

앞으로 ● goodtek 블로그에는 이 제품을 만드는 과정이 계속 올라올 예정입니다.

처음 문제를 어떻게 정의했는지.
MVP 범위를 어디까지 자를지.
기존 서비스와 어떻게 차별화할지.
SDK를 어떻게 설계할지.
바이브코더가 복사해서 쓸 수 있는 설치 프롬프트를 어떻게 만들지.
알림은 Discord, Slack, Telegram, Email 중 무엇부터 붙일지.
실제 장애 감지는 어떻게 할지.
유료화는 어디서부터 가능할지.
정말 누군가 쓸 만한 제품이 될 수 있을지.

이 모든 과정을 하나씩 기록하려고 합니다.

여기서 중요한 건 “정답을 알고 시작한다”가 아닙니다.
오히려 반대에 가깝습니다.

모르니까 만들고, 만들면서 기준을 바꿔보고, 바뀐 기준까지 기록하는 것.

그게 이번 빌드의 핵심입니다.

작지만 진짜 필요한 문제부터

요즘은 누구나 앱을 만들 수 있는 시대가 되고 있습니다.

하지만 누구나 안정적으로 운영할 수 있는 시대가 된 것은 아닙니다.

저는 그 사이에 기회가 있다고 생각합니다.

만드는 속도는 점점 빨라지고 있습니다.
하지만 운영의 불안은 여전히 남아 있습니다.

● goodtek의 첫 번째 SaaS는 그 불안에서 출발합니다.

내가 만든 서비스가 지금도 잘 살아 있는지 알고 싶다.

아주 단순하지만,
혼자 서비스를 만드는 사람에게는 꽤 절실한 문제입니다.

이제 이 문제를 직접 풀어보겠습니다.

작게 시작하겠습니다.
많이 틀릴 수도 있습니다.
중간에 방향을 바꿀 수도 있습니다.

그래도 이번에는 머릿속에만 두지 않고, 실제 제품으로 꺼내보려고 합니다.

● goodtek의 첫 번째 제품을 빌드인 퍼블릭으로 시작합니다.