1차 MVP 구축 제안 · 동작 데모 포함

채팅으로 만드는 CRM 빌더
1차 MVP 구축 제안서

가장 어려운 부분부터 만들어 보고 제안드립니다

신영진 | 백엔드 개발 · 시스템 운영 파트너

가장 어려운 부분을 먼저 만들어 봤습니다

이 제품에서 기술적으로 가장 불확실한 것은 배포도 마켓도 아니라, AI가 구조를 바꾸되 코어는 못 건드리게 하는 부분이라고 판단했습니다

요청 → 변경안 → 승인

"계약 단계를 추가해줘" 요청에 AI가 변경안을 만들고, 사용자가 미리보기로 확인한 뒤 승인해야 반영됩니다

코어 보호 검증이 작동하는 순간

"거래 금액 필드를 없애줘" 같은 요청은 코어 구조 변경으로 판단해 차단하고, 이유와 대안을 함께 안내합니다

왜 이 방식인가 — LLM은 확률적으로 답하는 도구라 "이건 되고 저건 안 된다"를 프롬프트로만 막을 수 없습니다. AI가 바꿀 수 있는 범위를 코드로 먼저 정의하고, AI가 만든 변경안이 그 범위 안에 있는지 검사해 벗어나면 거부하는 구조로 설계했습니다. 사용자 승인 단계가 한 번 더 있어 두 겹의 안전장치가 됩니다.

승인한 변경이 실제 화면에 반영됩니다

템플릿 선택 → AI 수정 → CRM 화면 → 배포 → 스킬 설치까지 이어지는 흐름을 확인하실 수 있습니다

CRM 화면

승인한 '계약' 단계가 보드에 추가되고, 추가한 커스텀 필드가 카드에 표시됩니다

배포

서브도메인은 즉시, 커스텀 도메인은 인증서 발급 단계를 그대로 보여줍니다

스킬 마켓

설치 전에 해당 스킬이 요청하는 권한 범위를 먼저 보여줍니다

기술 스택과 선택 이유

희망하신 구성이 이번 요구에 잘 맞습니다. 왜 그런지 쉬운 표현으로 말씀드립니다

데이터 격리PostgreSQL RLS

"이 계정은 자기 회사 자료만 본다"를 데이터베이스가 직접 강제합니다. 코드로 거르는 방식은 한 군데만 빠뜨려도 다른 회사 자료가 노출되는데, 이 방식은 그 실수가 원천적으로 막힙니다

앱Next.js + TypeScript

한 벌의 코드로 화면과 서버를 함께 다룹니다. 테넌트마다 앱을 따로 띄우지 않고 주소로 구분하는 구조에 적합합니다

도메인Cloudflare for SaaS

고객사 도메인마다 인증서를 발급·갱신해야 하는데, 이 서비스가 그 과정을 대신 처리합니다. 직접 만들면 상당한 작업입니다

결제Stripe

구독 결제와 개발자 정산을 한 곳에서 다룹니다. 정산은 직접 만들면 위험이 큰 영역이라 검증된 서비스에 맡기는 편이 안전합니다

배포 자동화에 대해 — 서브도메인은 앱을 테넌트마다 새로 띄우는 것이 아니라, 앱 하나를 두고 주소를 보고 어느 회사인지 판단하는 구조입니다. 와일드카드 DNS와 인증서 하나로 처리되어 테넌트가 늘어도 추가 작업이 없습니다. 손이 가는 쪽은 커스텀 도메인이며, 위 서비스로 해결합니다.

1차 범위 우선순위 제안

두 달 안에 시장에 내보내 반응을 확인하는 것이 목적이라면, 아래 기준으로 나누는 것을 제안드립니다

기능	1차	판단 근거
멀티테넌트 RLS 격리	필수	나중에 넣을 수 없는 구조. 처음부터 들어가야 합니다
CRM 코어 + 커스텀 필드	필수	제품의 본체
AI 빌더 + 코어 보호 검증	필수	이것이 없으면 다른 노코드 도구와 구분되지 않습니다
업종 프리셋	2~3종	5종을 다 만들 필요가 없습니다. 파일럿 10팀의 업종에 맞춰 2~3종만 먼저 만들고 반응을 보는 편이 낫습니다
서브도메인 배포	필수	"배포까지 스스로 끝낸다"는 경험의 핵심
커스텀 도메인 + SSL	후순위	파일럿 10팀이 자기 도메인을 연결할 가능성은 낮습니다. 서브도메인으로 충분히 검증되며, 유료 전환 시점에 붙이면 됩니다
권한 3종 + 이메일 초대	필수	팀 단위 사용 검증에 필요
디자인 테마	축소	로고·색상 정도만. 폰트까지 바꾸는 기능은 검증에 영향이 없습니다
구독 결제	후순위	파일럿 10팀은 무료로 쓰며 반응을 보는 단계입니다. 결제는 유료 전환을 결정한 뒤 붙여도 늦지 않습니다
스킬 마켓 + 개발자 정산	2차	가장 크게 덜어낼 부분입니다. 아래에서 따로 말씀드립니다
REST API + 웹훅	후순위	외부 연동은 쓸 고객이 생긴 뒤에 붙이는 것이 순서입니다
운영 백오피스	최소	테넌트 목록 조회 정도만. 심사 기능은 마켓과 함께 2차로

스킬 마켓을 2차로 제안드리는 이유

차별점이라고 하신 기능이라 신중하게 말씀드립니다

1공급자가 아직 없습니다마켓은 파는 사람과 사는 사람이 모두 있어야 돌아갑니다. 파일럿 10팀 단계에서 스킬을 만들어 올릴 개발자를 모으기는 어렵고, 빈 마켓은 제품 인상을 오히려 해칩니다

2규모가 별도 제품급입니다등록·심사·설치·권한 제어에 더해 개발자 정산까지 들어갑니다. 정산은 돈이 오가는 영역이라 잘못되면 되돌리기 어렵고, 그 자체로 상당한 공수가 필요합니다

3보안 난이도가 가장 높습니다남이 만든 코드가 다른 회사 고객 데이터에 접근하는 구조입니다. 권한 범위를 어떻게 제한하고 벗어난 호출을 어떻게 막을지는 충분한 설계 시간이 필요합니다

4대신 자리를 비워둡니다1차에서 스킬이 붙을 자리(설치 목록, 권한 구조)를 데이터 구조에 미리 두면, 2차에서 기존 기능을 고치지 않고 마켓을 얹을 수 있습니다

검증하려는 것이 무엇인지에 따라 판단이 달라집니다 — "채팅으로 CRM을 만들어 쓰는가"를 검증하시려는 것이라면 마켓 없이도 충분합니다. 반대로 "개발자 생태계가 형성되는가"가 이번에 확인하려는 가설이라면 마켓이 1차에 들어가야 하며, 그 경우 다른 기능을 크게 덜어내야 합니다. 어느 쪽인지 알려주시면 범위를 다시 잡아 제안드리겠습니다.

1차 검증의 성공 기준

기능이 동작하는 것과 가설이 검증되는 것은 다르다고 봅니다

1도움 없이 끝내는 것파일럿 10팀 중 다수가 안내 없이 템플릿 선택부터 배포까지 스스로 완료하는 것. 한 명이라도 막히는 지점이 같다면 그곳이 제품의 문제입니다

2AI 수정이 실제로 쓰이는 것배포 후에도 채팅으로 구조를 고치는 행동이 반복되는 것. 한 번 만들고 끝이라면 템플릿 서비스이지 빌더가 아닙니다

3차단이 납득되는 것코어 보호로 요청이 거부됐을 때 사용자가 이유를 이해하고 대안을 따라가는 것. 그냥 안 된다고만 하면 이탈합니다. 데모에서 차단 화면에 이유와 대안을 함께 넣은 이유입니다

4데이터가 섞이지 않는 것테넌트 격리가 한 번도 뚫리지 않는 것. 이것은 검증 항목이 아니라 전제이며, 그래서 테스트 코드를 산출물로 요구하신 것이 적절하다고 봅니다

1번을 가장 중요하게 봅니다. 파일럿에서 확인해야 할 것은 기능 목록이 아니라 어디서 막히는가입니다. 그래서 주차별 배포 버전을 산출물로 두신 것도 좋은 판단이라고 생각합니다 — 완성 후 한 번에 보는 것보다 중간에 계속 보는 편이 방향을 잡기 쉽습니다.

확인이 필요한 부분

범위와 일정을 확정하기 전에 여쭙고 싶은 사항입니다

?이번에 검증할 가설"채팅으로 CRM을 만들어 쓰는가"인지, "개발자 생태계가 형성되는가"인지 — 앞 장에서 말씀드린 대로 범위가 크게 달라집니다

?파일럿 10팀의 업종정해져 있다면 그 업종 프리셋부터 만듭니다. 5종을 균등하게 만드는 것보다 효과적입니다

?AI 수정의 허용 범위단계와 필드 추가까지인지, 화면 배치나 자동화 규칙까지인지 — 검증 로직의 범위가 여기서 정해집니다

?LLM 선택과 비용사용자가 채팅할 때마다 비용이 발생합니다. 무료 플랜의 호출 한도를 어떻게 둘지 미리 정하는 편이 좋습니다

?와이어프레임 상세도제공하신다는 역할별 화면 구성 초안이 어느 수준인지에 따라 기능 명세 확정에 걸리는 시간이 달라집니다

어려운 것부터
확인하고 시작하겠습니다

데모는 직접 눌러보실 수 있습니다. 차단되는 요청도 함께 넣어두었습니다.