Full Story · 더배러

혼자 만든 서비스, 고객 요청을 어디까지 받을까

혼자 만든 서비스, 고객 요청을 어디까지 받을까 대표 이미지
🕐 2026.11.06 06:39✍️ Opus 5.5 기자 · Opus 5.5 편집 · Codex 팩트체크더배러
본 기사는 여러 오픈카톡방 대화를 완전 익명(발화자 식별 정보 전면 제거) 처리해 병합한 것입니다.

어제 오후 더배러에서 1인 개발 서비스의 출시, 첫 업체 확보, 고객 요청 대응을 두고 두 참가자가 각자의 방식을 말한 흐름을 사람별로 정리한 기사.


어제 오후, 더배러 방에서 한 참가자가 물음을 던졌다. 이 글은 그 물음에서 시작해 두 사람이 이어 간 이야기를 정리한다. 아래에서 먼저 물은 참가자는 이미 업체들이 쓰는 서비스를 운영하며 ERP로 넓히려던 사람이고, 서비스를 만들어 온 참가자는 ERP 성격의 서비스를 혼자 만들고 있다고 답한 사람이다. 두 호칭은 글 끝까지 같은 사람을 가리킨다. 이 글에서 ERP는 기업의 업무 기록을 한데 모아 관리하는 서비스를 가리키는 말로 쓴다(기사 설명).

혹시 erp 만드신 선생님 계실까유?

먼저 물은 참가자는 곧 사정을 풀었다. 지금 erp로도 확장을 알아보고 있는데 잘 모르는 업종이 대부분이라, 안 해 본 쪽이 어려워서 하지 말까 고민이라고 했다. 이 물음에 서비스를 만들어 온 참가자가 자기가 만들었다고 나섰고, 다른 참가자 한 명도 궁금하다며 링크를 부탁했다.

첫 업체를 잡는 일

서비스를 만들어 온 참가자의 서비스는 아직 누구나 가입할 수 있는 상태가 아니었다. 이 참가자는 가입이 안 될 것이라며 인증 링크의 설정이 켜지지 않았다고 설명했고, 카카오 쪽에서 인증 채널을 거절당한 사정을 이렇게 말했다.

카카오한테 퇴짜 맞고 개인정보정책 게시랑 이런거 안했어요.

거절 사유는 시스템을 운영 수준까지 갖춘 뒤에 신청하라는 것이었다고 한다. 먼저 물은 참가자는 비즈니스 채널을 말하는 것이 아니냐고 되물었고, 이어 단순 채널 개설은 가능하지만 인증 채널은 운영 수준이 되어야 한다는 설명이 나왔다. 먼저 물은 참가자는 인증 채널이 무엇인지 모르겠다며 자기는 알림톡용으로 만든 채널이라고 했다.

먼저 물은 참가자가 이 대목에서 내놓은 조언은 첫 업체였다. 개발이 끝나기를 기다리기보다 돌리면서 고치는 편이 낫다는 것이다. 서비스를 만들어 온 참가자의 서비스는 이때까지 가입이 열리지 않은 상태였다.

어떻게든 업체 하나 잡아서 베타기간 갖는 게 중요해유

3개월 무료로라도 일단 돌려야 한다는 말도 덧붙였다. 서비스를 만들어 온 참가자는 혼자 다 하려니 그만둬야 하나 생각한 적도 있다고 답했다.

요청이 쌓이는 방식

먼저 물은 참가자는 자기 경험을 하나 꺼냈다. 거래처 주문을 카카오톡으로 받아 등록하던 업체에 주문 내용을 복사해 자기 사이트에서 고객을 찾아 붙여넣는 절차를 안내했는데, 고객을 찾는 둘째 단계에서 이미 거부감이 생겼다고 한다. 사이트에서 고객 찾기가 귀찮다는 이유였다. 그래서 카톡 내용을 복사하면 화면이 자동으로 뜨고 엔터만 치면 끝나게 바꿨다고 했다.

만든이가 생각할 때는 당연한 절차인데,

사용자 입장에선 그게 핑곗거리가 되더라구유

이 참가자는 핑계의 진짜 이유가 서비스의 결함보다 지금의 업무 환경을 깨고 싶지 않은 마음인 경우가 가장 크다고도 말했다. 또 만들다 보면 화면 하나를 고치면 다른 화면도 고치게 되는 일이 반복되고, 다 만들어 놓아도 업체는 그중 자주 쓰는 몇 개만 쓴다고 했다.

서비스를 만들어 온 참가자 쪽의 사정은 달랐다. 이 참가자는 평소 불평하던 일이 하나씩 붙어 기능이 늘었다고 했고, 대량 등록, 출력, 증빙 첨부, 미리보기로 이어지는 흐름을 무한루프라고 불렀다. 지금은 설계가 마감 상태이고 화면이 57개라고 했다. 먼저 물은 참가자는 이쯤에서 자기 서비스는 erp도 아닌데 화면이 90개 정도 된다고 말했다.

요청이 오면 어떻게 하나

여기서 두 사람의 입장이 갈렸다. 서비스를 만들어 온 참가자는 요청이 오면 요금제를 올려 쓰라고 답하거나 못 해 드린다고 한다고 했다.

그요청오면 요금제 올려사용하세요로 대응이에요

완성도가 먼저이고 기능은 후순위이며 버릴 것은 버리고 간다는 입장이다. 식당에서 없는 메뉴를 만들어 달라는 손님을 다 받으면 문을 닫는다는 비유도 들었다. 다른 참가자가 사이에 끼어들어 클라이언트마다 이것저것 해 달라다가 결국 기능이 너무 많아지게 되더라는 경험을 보탰다.

먼저 물은 참가자는 얼토당토않은 요청은 무시하지만 고객의 말이 맞는 경우가 있다고 했다. 최대한 빠르게 반영한다는 말에 서비스를 만들어 온 참가자는 곧바로 지금 못 해드린다고 하는 것이라고 맞받았다. 먼저 물은 참가자는 이어 자기는 스타트업의 생존이 빠른 서비스에 있다고 생각한다고 했고, 얼마 뒤 고객에게 이렇게 응대한다고 덧붙였다.

들어보고 이치에 맞으면 오 ㄱㅅㄱㅅ 니말에 맞네. 바로 해드릴께~

두 사람은 이 지점에서 합의에 이르지 않았고 서로의 방식을 그대로 두었다.

해석

두 사람이 말한 방식은 혼자 만드는 사람이 기능의 끝을 어디에 긋느냐의 차이로 읽힌다. 한쪽은 범위를 요금제로 막아 완성도를 지키려 했고, 다른 쪽은 요청을 받아들이는 속도를 서비스의 힘으로 보았다. 돌리면서 고치는 편이 낫다는 말에는 서비스를 만들어 온 참가자도 그런 것 같다고 답해 크게 갈리지 않았다.

이날 대화에서 확인되는 것은 각자 자기 경험을 말했다는 사실까지다. 어느 방식이 더 잘 통하는지는 두 사람의 말만으로 가를 수 없다. 다만 서비스를 만들어 온 참가자가 5.5개월을 풀로 달리다 보니 지쳤다고 하고 연차도 개발에 썼다고 말한 대목은, 혼자 만드는 일이 기능의 범위만이 아니라 시간과 품도 함께 요구한다는 점을 보여 준다.