2026년 4월 21일 기준 위노트는 학교 상담 업무를 로컬 데스크톱 앱으로 자동화하는 학교상담시스템이다.
유튜브 인터뷰에서 민상기 대표는 위노트가 무료 사용을 포함해 약 200개 학교에서 쓰이고, 정식 결제 학교는 100개에 조금 못 미친다고 설명했다.
3월 월매출은 약 2,000만 원 수준으로 언급됐다.
처음 보면 꽤 자극적인 성공담처럼 보인다.
혼자 만들었다.
AI로 만들었다.
학교 200곳이 쓴다.
월 2,000만 원이 나왔다.
이 네 문장만 보면, 사람 마음이 바로 흔들린다.
나도 Claude Code 켜고 SaaS 하나 만들어야 하나?
좋은 질문이다.
그런데 이 사례의 진짜 포인트는 거기가 아니다.
위노트가 흥미로운 이유는 AI로 빨리 만들었기 때문만이 아니다.
오히려 더 중요한 건, 처음 만든 버전이 현장에서 바로 먹히지 않았고, 그 이유가 기술 부족이 아니라 고객 맥락 오해였다는 점이다.
상담교사의 실제 문제.
클라우드 저장에 대한 거부감.
학교 예산과 결제 흐름.
나이스 업로드 같은 업무 동선.
24시간에 가까운 고객 응대.
전문 커뮤니티와 연수 생태계.
이 요소들이 합쳐져서 제품이 앞으로 나갔다.
그러니까 이 글은 AI로 SaaS 만드는 법 글이 아니다.
AI로 만든 제품이 실제 고객 돈을 받으려면, 기술보다 먼저 무엇을 봐야 하는지 정리하는 글이다.
기술은 빨라졌다.
고객은 여전히 어렵다.
이 문장이 오늘의 핵심이다.
이 글을 써먹을 상황
- Claude Code나 Cursor로 1인 SaaS를 만들고 싶다.
- 아이디어는 있는데 어떤 문제부터 잡아야 할지 모르겠다.
- AI로 기능은 빨리 만들 수 있는데 고객이 돈을 낼지 불안하다.
- B2B나 B2G처럼 구매자가 개인이 아닌 시장을 보고 있다.
- 학교, 병원, 공공기관처럼 보안 민감도가 높은 도메인에 관심이 있다.
- SaaS는 클라우드가 당연하다고 생각했는데 현장에서는 거부감이 있을 수 있다는 말을 처음 들었다.
- MVP를 만들었는데 첫 번째 고객은 좋아했지만 대중 반응은 애매했다.
- AI 기능을 넣었는데 고객은 오히려 AI라는 단어를 불편해했다.
- 제품 기능보다 고객 응대와 커뮤니티가 더 큰 해자가 될 수 있는지 궁금하다.
- 1인 개발자가 어디까지 우당탕탕 해도 되고, 어디서부터 운영 체계를 만들어야 하는지 고민 중이다.
기술에 매몰되지 말라는 말을 실전 사례로 보고 싶다.
이 중 두세 개만 걸려도, 위노트 사례는 꽤 쓸 만한 참고가 된다.
다만 그대로 따라 하면 안 된다.
학교상담이라는 도메인, 창업자의 교사 경험, 상담교사 커뮤니티, 로컬 저장 요구는 꽤 특수하다.
그래서 이 글에서는 기능을 복제하지 않고, 판단 구조만 가져오려고 한다.
무엇을 먼저 검증했는가.
어디서 틀렸는가.
왜 로컬 저장이 제품 방향을 바꿨는가.
AI 개발 속도는 어느 지점에서 도움이 됐고, 어느 지점에서는 별로 중요하지 않았는가.
이 네 가지를 보면 된다.
지금 판단
위노트 사례를 한 문장으로 줄이면 이렇다.
AI로 빠르게 만든 제품이 아니라, 고객이 싫어하는 기술 선택을 버린 제품이 팔렸다.
이게 중요하다.
첫 번째 버전은 얼리어답터 고객에게는 좋았다.
상담교사 한 명이 실제 문제를 제보했고, 개발자는 그 문제를 듣고 초기 프로토타입을 만들었다.
여기까지는 전형적인 좋은 시작이다.
문제는 그 고객이 대중이 아니었다는 점이다.
그 고객은 자기 돈을 들여 엑셀 업체에 맡겨 볼 정도로 문제 의식이 높았다.
개발자와 화상 미팅을 하고, 피드백을 적극적으로 주고, 고급 기능을 요구할 수 있는 상위 1% 사용자에 가까웠다.
그런 사용자를 만족시키는 제품은 훌륭해 보일 수 있다.
하지만 그 제품이 대다수 고객에게 맞는다는 보장은 없다.
실제 반응은 달랐다.
다른 상담교사들은 기능보다 먼저 물었다.
민감한 상담 일지가 클라우드에 저장돼도 괜찮은가.
그 순간 제품의 중심 질문이 바뀐다.
무슨 기능을 더 넣을까가 아니다.
이 고객이 안심하고 쓸 수 있는 구조인가다.
위노트는 여기서 로컬 데스크톱 앱 방향으로 틀었다.
공식 페이지에서도 위노트는 상담 데이터가 학교 컴퓨터에만 저장되고, 암호화 백업과 자동 업데이트를 제공한다고 설명한다.
이건 단순 기술 선택이 아니다.
구매 저항을 줄이는 제품 전략이다.
첫 번째 교훈: 첫 고객은 대중이 아닐 수 있다
AI로 프로토타입을 빨리 만들면 가장 먼저 기분 좋은 일이 생긴다.
누군가 좋아한다.
정말 편하다고 말한다.
기능을 더 달라고 한다.
이때 조심해야 한다.
그 사람이 시장 전체를 대표하지 않을 수 있다.
위노트 인터뷰에서 흥미로웠던 지점은 바로 이거다.
첫 고객은 매우 적극적인 문제 해결자였다.
엑셀로 직접 방법을 만들고, 외부 업체와도 소통해본 사람이었다.
이런 고객은 제품 초기에는 보물이다.
하지만 제품 방향을 전부 맡기면 위험하다.
왜냐하면 그 고객의 고급 요구사항이, 대다수 고객에게는 과할 수 있기 때문이다.
위노트도 초기에 그런 상황을 겪었다.
기능을 열심히 만들었지만, 다른 현장 사용자는 이거 굳이?에 가까운 반응을 보였다고 한다.
그 이유는 기능이 나빠서가 아니었다.
문제가 달랐다.
첫 고객은 고급 기능을 원했다.
대다수 고객은 쉽고 안전한 기본 업무 처리를 원했다.
이 차이를 못 보면, AI는 오히려 문제를 키운다.
AI는 기능을 빨리 늘려주기 때문이다.
빨리 늘어난 기능이 고객 문제와 어긋나면, 제품은 더 복잡해진다.
복잡한데 안 팔리는 제품이 된다.
이건 꽤 슬프다.
열심히 만들었는데, 열심히 빗나간 상태니까.
두 번째 교훈: 보안은 기능이 아니라 구매 조건이다
학교 상담 업무는 민감하다.
상담일지, 위기 학생 기록, 심리검사, 보고 자료가 얽힌다.
개발자 입장에서는 클라우드 저장도 충분히 안전하게 설계할 수 있다고 생각할 수 있다.
암호화하면 된다.
키를 클라이언트가 들고 있으면 된다.
서버에서는 복호화하지 못하게 하면 된다.
기술적으로는 맞는 설명일 수 있다.
하지만 고객은 그렇게만 보지 않는다.
인터뷰에서 말한 것처럼, 현장에서는 상담 기록이 네트워크를 타고 밖으로 나간다는 사실 자체에 거부감이 있었다.
이건 논리로만 설득하기 어렵다.
고객이 불안하다고 느끼면, 그 불안도 제품 요구사항이다.
위노트는 이 요구사항을 받아들여 로컬 저장으로 갔다.
이 선택은 기술적으로 더 어려웠다.
데스크톱 앱, SQLite, Electron, 로컬 마이그레이션, 백업, 자동 업데이트 같은 문제가 생긴다.
클라우드라면 서버에서 통제할 수 있는 일도, 로컬 앱에서는 사용자 환경마다 달라진다.
그런데 이 불편함을 감수할 만큼 고객의 보안 감각이 중요했다.
여기서 배울 점은 명확하다.
민감한 도메인에서 보안은 부가기능이 아니다.
구매 조건이다.
고객이 안심하지 못하면, 기능이 좋아도 결제로 이어지지 않는다.
특히 B2G나 학교 시장에서는 더 그렇다.
도입 담당자는 좋다보다 문제없다를 먼저 확인한다.
문제없다를 통과해야 그다음에 좋다가 나온다.
세 번째 교훈: SaaS라도 꼭 클라우드일 필요는 없다
요즘 SaaS라고 하면 자연스럽게 웹앱을 떠올린다.
로그인하고, 서버에 저장하고, 구독 결제하고, 관리자 페이지에서 모든 걸 본다.
그게 일반적이다.
하지만 모든 시장에서 정답은 아니다.
위노트는 학교 컴퓨터에 데이터가 저장되는 데스크톱 앱을 전면에 내세운다.
공식 페이지도 학교 컴퓨터에만 안전하게 저장을 핵심 메시지로 말한다.
이건 SaaS의 형태를 조금 다르게 생각하게 만든다.
수익 모델은 구독형일 수 있다.
업데이트와 라이선스도 제공할 수 있다.
고객지원과 커뮤니티도 운영할 수 있다.
그런데 데이터 저장은 로컬일 수 있다.
이 조합이 이상해 보일 수 있지만, 도메인에 따라서는 더 맞는다.
중요한 건 제품이 어떤 기술 철학을 따르느냐가 아니다.
고객의 불안을 어디서 줄이느냐다.
AI 시대에는 여기서 착각이 생기기 쉽다.
우리는 자꾸 최신 스택을 먼저 본다.
클라우드, MCP, agent, workflow, vector DB, local model, desktop wrapper.
다 좋다.
하지만 고객이 사는 건 스택이 아니다.
고객은 자기 일이 줄어드는지, 내 데이터가 안전한지, 문제가 생기면 누가 답해주는지를 산다.
이 순서를 잊으면 기술은 장식이 된다.
멋진 장식인데, 결제 버튼은 안 눌리는 장식.
그건 조금 아프다.
네 번째 교훈: 가격보다 예산 흐름이 더 중요할 때가 있다
위노트 요금제는 공식 가격표 기준으로 연 30만 원, 48만 원, 96만 원 구간을 둔다.
인터뷰에서도 베이직, 프로, 프리미엄 가격대가 언급됐다.
개인 SaaS 관점에서 보면 가격이 낮지 않다.
그런데 학교 예산 구조에서는 다른 문제가 생긴다.
학교의 회계 시점, 품의, 카드 결제, 견적서, 납품서, 교육청 문의 같은 흐름이다.
위노트 공식 페이지는 카드 결제, 견적서, 납품서, 학교운영위원회 심의 여부 같은 도입 절차를 강조한다.
이건 기능 소개와 다르다.
구매 friction을 줄이는 내용이다.
B2G나 학교 시장에서는 이게 굉장히 중요하다.
사용자는 좋다고 느껴도, 구매 절차가 복잡하면 멈춘다.
결제는 제품 안에서만 일어나지 않는다.
조직의 예산 흐름 안에서 일어난다.
그래서 이런 시장에 들어가려면, 가격표만 보면 안 된다.
누가 결제하는지 봐야 한다.
어떤 예산 항목으로 사는지 봐야 한다.
결제 전에 어떤 서류가 필요한지 봐야 한다.
문의가 교육청까지 올라갈 수 있는지도 봐야 한다.
이걸 안 보면, 제품은 쓸 만한데 도입이 안 되는 이상한 상황이 생긴다.
사용자는 좋아한다.
기관은 멈춘다.
이 간극을 줄이는 것도 제품이다.
다섯 번째 교훈: AI 기능이 항상 마케팅 포인트는 아니다
이 사례에서 가장 강한 장면은 AI 이름을 뺀 이야기다.
위노트는 처음에 위노트 AI에 가까운 메시지를 내세웠다고 한다.
온디바이스 AI가 상담일지 작성과 보고서 생성을 도울 수 있고, 데이터가 밖으로 나가지 않는다는 점을 자신 있게 말하고 싶었던 것이다.
개발자 입장에서는 충분히 자랑할 만하다.
그런데 유저 인터뷰에서 다른 신호가 나왔다.
상담 분야에서는 AI가 심리 상담에 개입한다는 인상 자체가 부정적으로 받아들여질 수 있었다.
기술적으로는 보조 기능이어도, 고객은 이름에서 먼저 판단했다.
제품 이름에 AI가 붙어 있어서 아예 안 쓰려는 사람도 있었다는 것이다.
이건 AI 제품 만드는 사람에게 꽤 중요한 경고다.
우리는 AI를 자랑하고 싶다.
모델을 말하고 싶다.
온디바이스라고 말하고 싶다.
자동화라고 말하고 싶다.
하지만 고객은 AI를 사는 게 아닐 수 있다.
고객은 불안을 줄이는 결과를 산다.
학교 상담교사에게 더 중요한 문장은 AI가 들어갔다가 아니라 상담 내용이 외부로 나가지 않는다일 수 있다.
AI 기능이 실제로 좋아도, 그 단어가 구매 저항을 키운다면 뒤로 빼야 한다.
기술을 숨기라는 말이 아니다.
고객 언어로 다시 번역하라는 말이다.
여섯 번째 교훈: 빠른 버그 대응은 해자가 될 수 있다
인터뷰에서 민상기 대표는 버그 리포트가 하루 4~5건씩 들어왔다고 말했다.
QA를 맡기고, 본인도 테스트를 많이 했지만, 실제 고객 사용 사례는 훨씬 다양했다.
이건 모든 초기 제품이 겪는 일이다.
특히 1인 개발, AI 코딩, 빠른 배포 루프에서는 더 그렇다.
여기서 중요한 건 버그가 없었다는 게 아니다.
버그가 들어왔을 때 빠르게 응답하고, 30분에서 1시간 안에 고치고, 고객에게 다시 설명했다는 점이다.
고객은 버그를 싫어한다.
하지만 초기 제품에서는 어떤 버그는 고객과 개발자의 관계를 강화하는 계기가 되기도 한다.
내가 제보한 문제가 바로 개선된다.
개발자가 직접 설명해준다.
업데이트 방법까지 알려준다.
그 경험은 고객을 팬으로 만들 수 있다.
물론 치명적인 버그는 다르다.
데이터가 날아가거나, 개인정보가 새거나, 결제가 잘못되면 빠른 응대만으로 해결되지 않는다.
그래서 초기 제품이라도 치명 영역은 반드시 막아야 한다.
하지만 일상적인 UX 버그, 작은 예외 케이스, 현장별 특수 흐름은 빠른 피드백 루프로 흡수할 수 있다.
AI 코딩 도구는 이 지점에서 강하다.
작은 수정, 빠른 배포, 고객 피드백 반영이 훨씬 쉬워진다.
AI의 진짜 장점은 첫 버전을 빨리 만드는 것만이 아니다.
고객 피드백을 계속 제품으로 바꾸는 속도에 있다.
일곱 번째 교훈: 기능은 복제돼도 커뮤니티는 쉽게 안 베껴진다
인터뷰에서 민상기 대표는 위노트의 해자를 커뮤니티와 네트워크로 봤다.
위노트 기능 자체는 복제될 수 있다고 인정했다.
CRUD 서비스는 AI 시대에 더 빨리 만들어질 수 있다.
더 세련된 화면, 더 저렴한 가격, 비슷한 기능이 나올 수 있다.
그렇다면 무엇이 남는가.
커뮤니티다.
위노트는 상담 선생님들이 활동하는 커뮤니티와, 멘토 선생님, 연수 콘텐츠, 전문성 강화 흐름을 함께 만든다.
공식 페이지에도 연수원, 커뮤니티, 학교 상담 업무 전문성을 강화하는 구조가 보인다.
이건 제품 기능만으로는 만들기 어렵다.
고객이 같은 문제를 가진 사람들과 연결되고, 자료를 얻고, 전문성을 키우고, 제품 사용이 직무 성장과 연결되면 해자가 생긴다.
이건 AI가 바로 복제하기 어려운 부분이다.
기능은 복제된다.
고객 관계는 시간이 걸린다.
도메인 신뢰는 더 오래 걸린다.
초기 SaaS를 만들 때 이 차이를 봐야 한다.
AI로 기능을 만드는 것은 시작이다.
고객이 계속 남을 이유를 만드는 것은 또 다른 일이다.
AI 1인 SaaS 검증표
| 검증 항목 | 위노트 사례에서 보인 신호 | 내 제품에 던질 질문 |
|---|---|---|
| 현장 문제 | 상담일지, 통계, 나이스 업로드 반복 업무 | 고객이 지금 엑셀이나 한글로 버티는 일은 뭔가 |
| 첫 고객 편향 | 상위 1% 얼리어답터 요구가 초기에 반영됨 | 첫 고객이 대중을 대표하는가 |
| 보안 저항 | 클라우드 저장에 강한 거부감 | 고객이 논리보다 감정적으로 불안해하는 지점은 뭔가 |
| 도입 절차 | 학교 예산, 카드 결제, 교육청 문의 | 구매자는 누구이고 어떤 서류가 필요한가 |
| 빠른 대응 | 버그를 바로 받고 고쳐 고객과 관계 강화 | 내가 24시간은 아니어도 빠르게 응답할 수 있는가 |
| 기술 메시지 | AI 단어가 일부 고객에게 허들이 됨 | 고객은 AI를 원하는가, 결과를 원하는가 |
| 해자 | 커뮤니티, 연수, 멘토 네트워크 | 기능 말고 고객이 남을 이유는 뭔가 |
이 표에서 중요한 건 마지막 줄이다.
AI 시대에는 기능 해자가 약해진다.
정확히 말하면 기능만으로는 해자를 만들기 어려워진다.
코드를 더 빨리 만들 수 있기 때문이다.
그러면 도메인 이해, 신뢰, 데이터 흐름, 커뮤니티, 고객 응대가 더 중요해진다.
개발자는 여전히 중요하다.
하지만 개발만으로는 부족하다.
1인 SaaS 창업자는 개발자이면서, PM이면서, 고객지원 담당자이면서, 도메인 인터뷰어가 된다.
AI가 코드를 줄여줄수록, 나머지 역할이 더 선명해진다.
Claude Code가 도움 되는 지점
위노트 인터뷰에서 개발 이야기도 흥미롭다.
초기에는 Replit으로 프로토타입을 만들었고, 나중에는 Claude Code를 본격적으로 썼다고 한다.
기술 스택은 SQLite, Electron, 파일 기반 데이터베이스 같은 방향으로 고민됐다.
인간 개발자들에게는 부정적 피드백도 들었다.
그럼에도 Claude Code와 계속 토론하면서 선택을 밀고 갔다고 한다.
여기서 배울 점은 AI가 정답을 줬다는 게 아니다.
AI가 혼자 창업하는 사람의 토론 상대가 됐다는 점이다.
1인 개발자는 의사결정이 외롭다.
기술 선택, 데이터 구조, 배포, 버그, 고객 요구, 다음 기능을 혼자 판단해야 한다.
Claude Code 같은 도구는 이때 생각을 밀어주는 파트너가 될 수 있다.
하지만 AI가 괜찮다고 했다고 무조건 맞는 건 아니다.
위노트 사례에서도 결국 답은 고객이 줬다.
AI는 개발 속도와 토론을 도와줬다.
제품 방향은 고객 인터뷰와 결제가 결정했다.
이 순서가 중요하다.
AI에게 물어본다.
프로토타입을 만든다.
고객에게 보여준다.
결제와 사용 데이터를 본다.
다시 고친다.
이 루프가 1인 SaaS의 핵심이다.
AI는 루프를 빠르게 만들 수 있다.
루프를 대신 돌려주지는 않는다.
혼자 만들 때 버려야 할 것
인터뷰에는 Conductor, OpenSpec, 브랜치, PR, 테스트 코드에 대한 이야기도 나온다.
이 부분이 꽤 현실적이다.
1인 개발 초기에는 좋은 운영 도구가 오히려 과할 수 있다.
팀 작업에서는 필요한 PR 프로세스가, 혼자 빠르게 검증하는 제품에서는 속도를 늦출 수 있다.
스펙 기반 개발도 좋지만, 제품 방향이 매주 바뀌는 극초기에는 관리 비용이 더 클 수 있다.
이건 무질서가 좋다는 말이 아니다.
단계에 맞는 질서가 필요하다는 말이다.
초기에는 고객 문제와 빠른 학습이 먼저다.
제품이 커지면 테스트, 스펙, 브랜치, PR, 배포 체계를 강화해야 한다.
시점을 헷갈리면 둘 다 망가진다.
너무 일찍 체계를 만들면 느려진다.
너무 늦게 체계를 만들면 무너진다.
이 균형이 어렵다.
그래서 작은 팀은 이렇게 보면 좋다.
초기에는 변경 속도가 해자다.
성장기에는 안정성이 해자다.
운영기에는 신뢰가 해자다.
지금 내 제품이 어느 단계인지 먼저 봐야 한다.
도구는 그다음이다.
위험한 해석
이 사례를 잘못 읽으면 위험하다.
테스트 코드 안 짜도 월 2,000만 원 가능하다
이런 식으로 읽으면 안 된다.
그건 핵심이 아니다.
위노트 사례의 포인트는 테스트를 안 해도 된다는 말이 아니다.
초기 시장 검증 단계에서는 고객 피드백과 빠른 대응이 매우 강력했다는 말이다.
그리고 도메인 특성상 치명적인 데이터 손실과 보안 문제는 절대 가볍게 볼 수 없다.
공식 페이지도 암호화 백업, 로컬 저장, 자동 업데이트, 데이터 보안을 계속 강조한다.
이건 안전장치를 버린 제품이 아니다.
고객이 가장 불안해하는 지점에 안전장치를 맞춘 제품이다.
또 하나의 위험한 해석은 이거다.
AI라고 말하면 잘 팔린다
이 사례는 오히려 반대다.
고객에 따라 AI라는 말이 방해가 될 수 있다.
상담처럼 사람의 신뢰가 중요한 영역에서는 특히 그렇다.
AI 기능이 있어도, 고객 언어는 업무 시간 단축, 데이터가 내 컴퓨터에만 저장, 나이스 업로드 자동화, 상담 기록 정리가 될 수 있다.
AI를 앞세울지 뒤에 둘지는 도메인이 정한다.
개발자의 자부심이 정하면 안 된다.
이 말이 조금 아프다.
그래도 맞다.
실수 TOP 7
1. AI로 만든 속도만 보고 고객 문제를 얕게 보는 실수
기능은 빨리 만들 수 있다.
하지만 고객이 돈을 내는 문제를 찾는 건 여전히 어렵다.
엑셀로 버티는 반복 업무, 매월 보고, 도입 절차 같은 지저분한 현실을 봐야 한다.
2. 첫 고객 요구를 시장 전체로 착각하는 실수
첫 고객은 소중하다.
하지만 첫 고객이 대중은 아닐 수 있다.
얼리어답터 요구와 대중 요구를 분리해서 봐야 한다.
3. 클라우드가 항상 정답이라고 믿는 실수
보안 민감 도메인에서는 로컬 저장이 더 강한 메시지가 될 수 있다.
고객이 불안해하는 지점이 저장 위치라면, 기술 철학보다 신뢰 설계가 먼저다.
4. AI 기능을 무조건 전면에 세우는 실수
AI는 강력한 기능일 수 있다.
하지만 고객이 AI를 불안하게 느끼면 이름부터 허들이 된다.
고객이 사고 싶은 결과 언어로 바꿔야 한다.
5. 구매 절차를 제품 밖의 일로 보는 실수
B2B와 B2G에서는 결제, 견적서, 품의, 예산 시점, 기관 문의가 모두 제품 경험이다.
구매 절차가 막히면 기능이 좋아도 도입이 멈춘다.
6. 커뮤니티를 마케팅 채널로만 보는 실수
커뮤니티는 홍보용 게시판이 아니다.
고객의 전문성, 자료, 멘토, 연수, 동료 신뢰가 모이면 제품 해자가 된다.
7. 초기 우당탕탕을 영구 운영 방식으로 착각하는 실수
초기에는 빠른 수정이 강점일 수 있다.
하지만 고객과 데이터가 늘면 운영 체계가 필요해진다.
테스트, 백업, 릴리즈, 장애 대응 기준은 성장에 맞춰 강화해야 한다.
AI 1인 SaaS 시작 체크리스트
- 고객이 지금 엑셀이나 한글로 억지로 하고 있는 업무를 찾았나.
- 그 업무가 매일, 매주, 매월 반복되는가.
- 첫 고객이 상위 1% 얼리어답터인지 확인했나.
- 대중 고객 10명 이상에게 같은 문제를 물어봤나.
- 고객이 싫어하는 기술 선택을 파악했나.
- 보안과 저장 위치에 대한 감정적 저항을 확인했나.
- 고객이 실제로 돈을 낼 구매 절차를 알고 있나.
- 가격표보다 예산 흐름을 먼저 봤나.
- AI 기능을 전면에 세워도 되는 도메인인지 확인했나.
- 버그 리포트가 들어왔을 때 몇 시간 안에 응답할 수 있나.
- 치명적인 버그와 일상적인 버그를 구분했나.
- 기능 복제 이후에도 남을 커뮤니티나 콘텐츠 해자가 있나.
- 제품 이름과 메시지가 고객 언어로 되어 있나.
- 1인 개발 초기 단계에서 과한 프로세스를 얹고 있지는 않나.
- 성장하면 언제 테스트와 배포 체계를 강화할지 기준이 있나.
이 체크리스트는 화려하지 않다.
하지만 돈을 내는 고객은 보통 화려한 데서 나오지 않는다.
고객은 자기 일이 줄어드는 곳에서 나온다.
그리고 자기 위험이 줄어드는 곳에서 나온다.
AI는 이 둘을 빠르게 실험하게 해준다.
하지만 무엇을 줄여야 하는지는 사람이 찾아야 한다.
TECHTAEK식 결론
위노트 사례는 AI로 혼자 SaaS 만들면 돈 번다는 단순한 이야기가 아니다.
그렇게 읽으면 중요한 걸 놓친다.
진짜 이야기는 이거다.
AI는 제품을 빠르게 만들게 해준다.
하지만 PMF는 고객의 불편과 불안을 정확히 맞췄을 때 온다.
첫 번째 버전이 틀릴 수 있다.
첫 고객이 대중이 아닐 수 있다.
클라우드가 거부당할 수 있다.
AI라는 단어가 오히려 방해가 될 수 있다.
버그가 있어도 빠른 응대가 관계를 만들 수 있다.
기능은 복제돼도 커뮤니티는 쉽게 복제되지 않는다.
이 모든 게 기술보다 앞에 있다.
그래서 1인 AI SaaS를 만들고 싶다면, Claude Code를 켜기 전에 먼저 물어야 한다.
고객이 지금 무엇을 손으로 하고 있나.
그 일을 왜 아직도 엑셀과 한글로 하고 있나.
그들이 어떤 기술을 무서워하나.
누가 결제하고, 누가 반대하고, 누가 문의하나.
이 질문이 없으면 AI는 빠르게 엉뚱한 걸 만든다.
반대로 이 질문이 있으면 AI는 무서운 속도를 낸다.
빠른 개발보다 중요한 건 빠른 학습이다.
위노트 사례가 보여주는 건 바로 그 지점이다.
AI 창업의 주인공은 모델이 아니다.
고객 문제를 끝까지 본 사람이다.
FAQ
Q1. 위노트는 정확히 어떤 서비스인가
학교 위클래스와 상담 업무에서 상담일지, 통계, 나이스 업로드, 일정, 보고서 작성 같은 반복 업무를 줄이는 학교상담시스템이다.
공식 페이지는 데이터가 학교 컴퓨터에 저장되는 로컬 기반 구조와 암호화 백업을 강조한다.
Q2. 정말 200개 학교가 쓰고 있나
인터뷰에서는 무료 사용을 포함해 약 200개 학교가 꾸준히 쓰고 있고, 정식 결제 학교는 100개에 조금 못 미친다고 설명했다.
공식 페이지는 정식 계약 도입 기관과 누적 사용 이력 기관을 별도로 보여준다.
그래서 숫자를 말할 때는 무료 포함 사용과 정식 계약을 구분해서 봐야 한다.
Q3. 월 2,000만 원 매출은 확정 수치인가
인터뷰에서 3월 기준 약 2,000만 원 수준으로 언급됐다.
다만 외부 감사 자료가 아니라 인터뷰 발언이므로, 정확한 재무 검증 수치라기보다 사례 이해를 위한 참고값으로 봐야 한다.
Q4. AI로 만든 SaaS는 테스트 없이 빨리 배포해도 되나
아니다.
초기에는 빠른 고객 피드백이 중요하지만, 데이터 손실, 보안, 결제, 개인정보 같은 치명 영역은 반드시 안전장치가 필요하다.
고객이 늘수록 테스트와 배포 체계도 강화해야 한다.
Q5. 1인 개발자가 지금 바로 따라 할 수 있는 건 무엇인가
기능을 따라 만들기보다 고객 문제 찾는 방식을 따라 하는 게 낫다.
엑셀이나 한글로 억지로 처리하는 반복 업무를 찾고, 첫 고객이 대중을 대표하는지 확인하고, 고객이 불안해하는 기술 선택을 먼저 검증하는 것이다.
관련 글
- AI 시대 시니어 개발자는 왜 코드 에디터가 됐을까 2026 – context engineering 검증표
- 프로덕션 바이브 코딩은 어디까지 안전할까 2026 – leaf node와 검증 설계 기준
- Claude Code 운영 허브 리프레시 2026 – Routines·Opus 4.7·MCP·MarkItDown 글을 색인용으로 묶기
출처
발행 전 점검
- 서두 100자 안에 2026년 4월 21일, 위노트, 학교 상담 업무, 로컬 데스크톱 앱을 넣었다.
- 최근 사용 도입부 TYPE 6, TYPE 11, TYPE 2를 피하고 TYPE 8 반전 구조로 작성했다.
- 제목 금지어를 쓰지 않았다.
Quick Answer,이 글이 필요한 사람,다음에 읽을 글헤더를 쓰지 않았다.- 유튜브 자막에서 월매출, 학교 수, 로컬 저장, 버그 대응, 커뮤니티 해자 관련 발언을 확인했다.
- 위노트 공식 사이트와 요금제 페이지로 제품 설명, 로컬 저장, 가격 정보를 교차 확인했다.