사이드 프로젝트 실패기: 발표까지 간 NPNS를 접은 진짜 이유

발표평가가 끝나고 나서 제일 먼저 든 생각은 “역시나 너무 마이너한 아이디어였다”였어요. 이 글은 광주 I-PLEX 입주스타트업 발표평가까지 들고 갔던 서비스 NPNS를 결국 접게 된, 제 사이드 프로젝트 실패 이야기입니다.

프로토타입까지 만들어둔 걸 내려놓는 건 생각보다 쉽지 않았어요. 처음엔 아이템이 마이너해서 안 먹혔다고 생각했습니다. 그런데 한 달쯤 지나 다시 뜯어보니 문제는 전혀 다른 곳에 있었어요. 아이디어가 마이너해서가 아니라, 제가 이미 알고 있던 실무 지식을 설계에 안 넣었던 게 진짜 원인이었습니다.

혼자 서비스 만들어보시는 분이라면, 특히 “내가 겪은 불편함”에서 출발한 아이템을 붙들고 계신 분이라면 이 글이 조금은 시간을 아껴줄 수 있을 것 같아요. 실패한 과정을 순서대로 적어볼게요.

NPNS는 어떤 사이드 프로젝트였나

NPNS는 No Pay, No Service의 약자예요. 프리랜서나 소규모 웹 에이전시가 납품하고 돈을 못 받는 상황을 막기 위한 B2B SaaS였습니다. 구조는 단순해요. 계약할 때 클라이언트 동의를 받아두고, DNS와 리버스 프록시 레이어에서 정산 완료 전까지 사이트 접근 범위를 단계적으로 제어하는 방식이었어요. 에스크로가 ‘돈’을 잡아둔다면 NPNS는 ‘결과물 접근권’을 잡아둔다는 게 제가 잡은 포지셔닝이었습니다.

계기는 에이전시 시절 경험이에요. 전 회사에서 사이트를 다 만들어주면 클라이언트들은 정상적으로 잘 쓰면서, 결제 얘기만 나오면 “사정이 안 좋다, 이번 달 안에 해준다”고 하고 몇 달을 미뤘어요. 결국 사장님은 많게는 몇천만 원까지 못 받았습니다. 인프라를 우리가 쥐고 있는데도 아무것도 못 하는 상황이 계속 마음에 걸렸어요.

서버, DNS, SSL은 에이전시에서 5년 가까이 만지던 영역이라 프로토타입까지는 만들 수 있었어요. 문제는 그다음이었죠.

I-PLEX 발표평가, 시장분석 질문에서 막히다

2026년 7월, 광주청년창업지원센터(I-PLEX 광주) 20기 입주스타트업 모집에 NPNS로 기획서를 냈어요. 20기 모집 공고를 보니 선발 규모는 4팀 내외였고, 발표평가에는 16팀이 왔어요. 경쟁률 4:1이었습니다. PPT 없이 발표 5분, 질문 10분 형식이었고 스크립트는 미리 다 짜서 들어갔어요.

처음엔 공고 이미지에 입주공간이 1층 14실, 2층 8실이라고 적혀 있어서 그만큼 뽑는 줄 알았어요. 건물도 5층까지 사무실이 다 있고요. 근데 그건 센터 전체 공간 설명이고, 실제 선발 인원은 기수마다 공고에 따로 나와요. 지원사업 처음 알아보시는 분들은 이거 헷갈리기 쉬우니 공고 원문의 모집 규모 항목부터 보세요.

발표에서 제일 아팠던 질문은 “시장 분석은 하셨냐”였어요. 했거든요. 기획서에 프리랜서의 30~40%가 정산 리스크를 경험한다고 적어놨고요. 그런데 끝나고 나서 그 숫자를 다시 보니 출처가 없었어요. 제 경험에서 나온 감이었지 공식 조사가 아니었던 거죠.

발표 끝나고 AI랑 같이 자료를 다시 찾아봤는데, 공개된 수치가 꽤 있었어요. 경향신문이 보도한 일하는시민연구소 조사에서는 프리랜서의 29.5%가 보수 지연 지급을, 11.3%가 계약된 보수 미지급을 경험했다고 나와요. 한국플랫폼프리랜서노동공제회 보도자료에 따르면 최근 1년간 보수 지연이나 미지급을 겪은 비중이 20.9%였고, 미수금은 평균 331.1만 원으로 월수입의 1.6배 수준이었어요. 그 돈을 실제로 받아낸 비중은 10% 정도에 그쳤고요.

대체재도 있었어요. 서울시는 2025년 4월부터 서울 프리랜서 안심결제를 운영하고 있어요. 의뢰인이 낸 작업 대금을 신한은행에 예치해두고 작업이 끝나면 프리랜서에게 지급하는 에스크로 방식이고, 별도 수수료가 없어요. 이용 대상은 서울에 거주하거나 작업장이 서울에 있는 프리랜서와 의뢰인입니다.

이걸 보고 나서야 “아, 심사위원들이 원했던 대답이 이거였겠다” 싶었어요. 숫자에 출처를 달고, 기존 대안과 비교하고, 그 빈자리에 내가 들어간다고 말했어야 했어요. 발표 결과와 별개로, 시장분석 질문에서 막히는 이유는 숫자가 없어서가 아니라 출처와 비교 대상이 비어 있어서라는 걸 이때 배웠습니다.

”이거 진짜 누가 쓸까?” 랜딩페이지 만들다 멈춘 질문

발표 직후엔 “다른 구미 당기는 걸로 할걸” 하는 후회가 컸어요. 전 회사에서 같이 하던 지역 체험 플랫폼 아이디어 같은 거요. 그런데 AI한테 그 얘길 했더니 바로 반박이 왔어요. 지역 체험 플랫폼은 이미 큰 플레이어들이 자리 잡은 B2C 시장이고, 호스트와 유저를 동시에 모아야 하는 콜드스타트 문제가 훨씬 크다는 거였어요. 대중적으로 보이는 아이템이 심사에서 더 유리했을 거란 보장은 없다는 거죠. 그래서 일단 NPNS를 더 밀어보기로 하고, 한 달쯤 뒤 랜딩페이지 작업을 시작했어요.

Claude Code에 디자인 스킬을 몇 개 깔고 랜딩페이지를 돌렸는데, 스킬이 로드에 실패하면서 그냥 기본 출력으로 만들고 있더라고요. 다시 세팅하고 프롬프트를 짜달라고 했더니, 프롬프트 안에 “합법적인가” 섹션과 “클라이언트 입장에서의 이점” 섹션이 들어가 있었어요. 카피가 “정산 안 하면 사이트 내린다”로 읽히면 클라이언트가 이 페이지를 보고 계약을 안 할 수 있다는 이유였어요.

그 문장을 보는데 질문이 하나 튀어나왔어요. “근데 진짜 이거 누가 쓸 것 같아? 사회적으로 가능한가?”

AI한테 물어보니 구조적인 문제를 세 개 짚었어요. 첫 번째는 동의를 해줘야 하는 쪽이 손해 보는 쪽이라는 거예요. 에스크로는 양쪽이 중립적인 제3자에게 통제권을 넘기는데, NPNS는 을에게 통제권을 몰아줘요. 갑 입장에서 “왜 내 사이트 스위치를 당신한테 줘야 하죠?”에 대한 답이 “제가 떼일까 봐요”면 서명할 이유가 없죠.

두 번째는 셀렉션 이펙트였어요. NPNS 조항에 흔쾌히 동의하는 클라이언트는 어차피 돈 줄 사람들이고, 떼먹을 사람은 정확히 그 조항을 거부해요. 필요 없는 곳에만 붙고 필요한 곳에선 계약 자체가 깨지는 구조예요.

세 번째는 과금이에요. 미지급 경험이 11.3%면 열 건 중 아홉은 아무 일도 없어요. 그런 사고에 대비해서 매달 구독료를 내라는 건, 안 그래도 지출에 민감한 프리랜서한테 잘 안 팔리는 모델이죠.

첫 번째 문제는 공공 서비스 숫자를 보면 더 실감이 나요. 수수료 0원에 은행이 대금을 맡아주는 서울시 안심결제조차, 서울신문 보도 기준으로 2025년 4월부터 12월 중순까지 거래액이 1억 1400만 원이었어요. 프리랜서 시장 규모를 생각하면 큰 숫자는 아니에요. 중립적인 은행이 돈을 맡아주는 구조도 의뢰인을 끌어들이기 쉽지 않은데, 을에게 스위치를 넘기는 구조는 말할 것도 없겠죠.

셋 다 기술로 풀 수 있는 문제가 아니었어요. 그런데도 저는 여기서 바로 접지 않았습니다. 돌이켜보면 이 사이드 프로젝트 실패의 신호는 이때 이미 다 나와 있었어요.

결제 확인과 도메인 명의, 사이드 프로젝트 실패를 확정한 두 질문

법적 제약을 정리해달라고 하고, 계약서에 넣을 조항 문구, 변호사한테 물어볼 질문지까지 뽑았어요. 단계적 인도, 유예기간, 데이터는 절대 안 건드리기 같은 안전장치를 넣으면 뭔가 될 것 같았거든요.

그러다 제가 먼저 막혔어요. 계약서 초안에 “대금이 지급되면 24시간 안에 조치를 해제한다”는 문장이 있었는데, 문득 이런 생각이 들었어요. 대금이 지급된 걸 내가 어떻게 알지? 결제가 NPNS를 거치는 게 아닌데?

이건 구현 디테일이 아니었어요. 확인 수단이 없으면 결국 개발자가 “받았음” 버튼을 수동으로 누르는 구조가 되고, 클라이언트는 “입금했다”, 개발자는 “확인 안 됐다” 하면 분쟁이 하나 더 생겨요. 정산 분쟁을 막으려고 만든 도구가 분쟁을 하나 더 만드는 구조였던 거죠. 결제를 NPNS 안으로 가져오는 방법도 있었지만, 1인 사업자가 감당하기엔 너무 무거운 선택지였어요. AI는 계좌 입금 내역을 자동으로 매칭하고, 예외는 개발자가 수동으로 확인하고, 클라이언트가 이체확인증을 올리면 조치가 자동으로 일시정지되는 3단 구조를 제안했어요. 설계로는 그럴듯했는데, 기능이 하나씩 붙을수록 원래 하려던 일보다 안전장치가 더 커지고 있었어요.

이쯤 되니 솔직히 이런 생각이 들었어요. 아무리 봐도 답이 없다. 사실상 에이전시 다닐 때 짜증났던 걸 감정적으로 풀어낸 프로그램 아니었나.

AI는 차단 기능을 다 빼고 “단계적 인도 관리 도구”로 축소하면 남는 게 있다고 했어요. 스테이징에서 프로덕션, 그다음 소유권 이전까지를 마일스톤으로 묶고 도메인·계정 명의 이전을 체크리스트로 관리하는 식이요.

근데 그 말을 듣자마자 실무에서 그런 일이 없다는 게 떠올랐어요. 도메인이나 서버를 나중에 ‘이전’하는 이벤트 자체가 거의 없어요. 관리 계약이 있으면 처음부터 제 계정으로 세팅하고, 없으면 그쪽 계정을 만들어서 거기에 세팅해주고 끝이에요. 명의가 어디로 갈지는 계약 시작할 때 이미 정해져요.

이 한 문장으로 남은 게 다 날아갔어요. AI도 바로 인정하더라고요. 자기가 살려보려던 방향은 실무를 몰라서 나온 거였다고요. 넘길 자산도 마일스톤도 없으니 단계적 인도 구조가 성립을 안 하고, 원래 NPNS도 클라이언트 계정에 세팅하는 경우엔 아예 붙을 수가 없어요. 붙을 수 있는 건 관리 계약이 있는 관계, 즉 매달 돈을 받고 있어서 대형 미납 사고가 잘 안 나는 쪽뿐이었어요.

그래서 접었습니다. 2026년 8월의 일이에요.

많은 사람이 오해하는 두 가지

NPNS를 파면서 저도 막연하게 생각하던 게 두 개 있었어요. 이번 사이드 프로젝트 실패에서 건진 것 중 실제로 남한테 써먹을 수 있는 정보가 이쪽이라, 비슷한 아이디어 가진 분들을 위해 정리해둘게요.

첫 번째 오해는 “계약서에 써두고 동의받으면 미납 시 사이트를 막아도 된다”는 거예요. 형법 제314조 제2항은 정보처리에 장애를 발생시켜 사람의 업무를 방해하면 5년 이하 징역 또는 1,500만 원 이하 벌금으로 처벌해요. 흔히 컴퓨터등장애 업무방해죄라고 부르는 조항이에요. 계약서 동의가 이 리스크를 어디까지 막아주는지는 저도 끝까지 확인하지 못했어요. 받을 돈이 있다는 사실만으로 안전하다고 생각하면 안 된다는 것, 그리고 비슷한 걸 만드실 분은 IT 계약 경험 있는 변호사에게 먼저 확인받아야 한다는 것까지만 말씀드릴 수 있어요.

두 번째 오해는 반대 방향이에요. “그럼 떼인 돈은 결국 방법이 없다”는 생각이요. 저도 “그런 양아치 같은 걸 진짜 어떻게 할 수가 없는 거야?” 하고 물었어요. 돌아온 답은 의외로 간단했어요. 절차가 있는데 다들 안 밟는다는 거였어요.

대표적인 게 지급명령이에요. 찾기쉬운 생활법령정보에 따르면 법원은 신청서가 접수되면 채무자를 심문하지 않고 지급명령을 결정하고, 채무자는 송달받은 날부터 2주 안에 이의신청을 할 수 있어요. 민사소송법 제474조상 이의신청이 없으면 지급명령은 확정판결과 같은 효력을 가져요. 공감신문 보도에 따르면 인지대도 같은 금액을 소송으로 청구할 때의 10분의 1 수준이에요. 다만 상대가 이의를 걸면 일반 소송으로 넘어가요.

돈이 없어서 미루는 거지 다툴 게 있어서 미루는 게 아닌 클라이언트라면, 이의 없이 확정될 가능성도 있는 거죠. 전 회사 사장님이 몇 달씩 “이번 달엔 준다”를 기다려준 게 오히려 회수 가능성을 깎아먹었을 수도 있겠다는 생각이 들었어요.

그럼 이 절차를 대신 해주는 서비스를 만들면 어떨까도 잠깐 생각했어요. “못 받은 돈 받아드립니다” 같은 거요. 근데 이건 선이 명확해요. 변호사법 제109조는 변호사가 아니면서 대가를 받고 법률사무를 취급하면 7년 이하 징역 또는 5천만 원 이하 벌금이에요. 대신 받아주는 모델은 1인 사업자가 할 수 있는 게 아니었어요.

NPNS를 접고 남은 것

정리하면 NPNS가 실패한 이유는 세 겹이에요. 사이드 프로젝트 실패라고 하면 보통 개발을 못 끝냈거나 유저가 안 왔거나를 떠올리는데, 제 경우는 둘 다 아니었어요. 동의해야 할 갑이 동의할 이유가 없었고, 해제 조건인 입금을 확인할 방법이 없었고, 도메인 명의가 계약 시작 시점에 이미 정해지는 실무 구조 때문에 붙을 자리가 거의 없었어요. 셋 중 어느 것도 기술 문제가 아니었어요.

제일 뼈아픈 건 마지막 이유예요. 도메인 명의가 계약 형태에 따라 갈린다는 건 제가 몇 년 동안 매일 하던 일이에요. 그 사실 하나만 기획 단계에서 꺼내봤어도 프로토타입 만들기 전에 결론이 났을 거예요. 그때 AI가 해준 말이 아직 남아 있어요. 다음 아이템을 잡을 땐 “내가 이 분야에서 아는 것 중에 이 아이디어를 죽이는 사실이 뭐지”를 프로토타입 전에 먼저 찾으라는 거였어요.

“짜증에서 출발한 아이디어라 철없었다”는 자책도 해봤는데, 그건 진짜 원인이 아니었어요. 불편함에서 출발하는 건 괜찮아요. 문제는 그 감정이 제품 형태까지 정해버리게 놔둔 거였어요. 막고 싶다는 마음이 먼저 있으니 “차단”이라는 기능이 당연하게 느껴졌고, 그 기능을 의심하는 데 한 달이 걸렸어요.

하나 더 조심하게 된 건 같은 우물을 계속 파는 거예요. NPNS를 접은 직후에 바로 “그럼 미수금 처리 서비스는?”으로 넘어갔거든요. 결국 계속 정산 문제였어요. 전 회사에서 본 장면이 강렬했던 만큼, 그 강렬함이 시장 크기를 대신 판단해주진 않는다는 걸 이번에 배웠습니다.

직접 겪은 문제로 서비스를 만들고 계신 분들은 한 번만 해보세요. 내가 그 업계에서 당연하게 하는 일 중에 내 아이디어와 부딪히는 게 없는지요. 저는 그 질문을 늦게 던진 탓에 사이드 프로젝트 실패를 하나 더 기록하게 됐어요. 그래도 왜 안 되는지 이제는 설명할 수 있으니, 그건 다음 아이템에 그대로 가져갑니다.