Skip to content
Back to Blog
DeskcommCRM 오픈소스 세일즈 OS, 한국 도입 전 반드시 확인할 라이선스와 채널 리스크
[TUTORIAL]

DeskcommCRM 오픈소스 세일즈 OS, 한국 도입 전 반드시 확인할 라이선스와 채널 리스크

퀀텀점프클럽 정상록퀀텀점프클럽 정상록6 min read6 views

Free Resource

PDF · Free

무료 오픈소스 영업 CRM, 한국에서 쓸까 — 비개발자를 위한 쉬운 가이드

Get the practical guide first, before diving into the full article.

DeskcommCRM 오픈소스 세일즈 OS, 한국 도입 전 반드시 확인할 라이선스와 채널 리스크

DeskcommCRM은 스타 1,950개를 모은 브라질발 오픈소스 CRM입니다. 라이선스는 단순하지만 성숙도와 WhatsApp 채널 리스크는 별도 확인이 필요합니다.

"하루에 스타 505개가 늘었다"는 숫자만 보고 이 글을 열었다면 먼저 정정할 게 있습니다. 그건 총 스타 수가 아니라 하루 증가분이거든요. "이거 우리 회사에도 바로 쓸 수 있나요?" 오픈소스 CRM 소식을 볼 때마다 따라붙는 질문이죠. 당연히 궁금하실 만해요. 오늘은 저장소 실측 데이터와 공식 문서로 라이선스, 성숙도, WhatsApp 채널 위험, 한국 실무 적용 가능성을 순서대로 짚어봅니다.

숫자로 다시 보는 DeskcommCRM

레이더에 뜬 "505 stars today"는 하루 증가분일 뿐 프로젝트 나이를 말해주지 않아요. 2026-04-28 생성돼 다섯 달이 채 안 되는 기간에 이 규모로 자란 셈이라 개발 속도는 빠른 편이에요. 2026-09-04~11 8일 사이 마이너 버전을 여섯 번 올렸을 정도입니다.

항목실측값
저장소 생성2026-04-28
최신 릴리스 / 최신 커밋v1.19.0(09-11) / 09-12
스타 / 포크1,950 / 565
기여자 / 열린 이슈45명 / 83건

저장소는 정식 버전 번호를 쓰면서도 자기 문서는 그 버전에 손을 들지 않습니다. 이유는 다음 절에 있어요.

MIT 라이선스는 단순하지만, 성숙도는 별개다

DeskcommCRM은 MIT 라이선스이고 예외가 없습니다.

MIT 라이선스는 강점이지만 문서와 이슈는 다른 말을 한다MIT 라이선스는 강점이지만 문서와 이슈는 다른 말을 한다

자료: 본문 데이터 · QJC 재구성

프로젝트스타라이선스포지션
Twenty56,666AGPLv3(일부 상용)CRM 데이터 모델 중심
Chatwoot36,749MIT(enterprise 별도)옴니채널 상담 중심
DeskcommCRM1,950MIT(예외 없음)영업+상담+AI 결합

Chatwoot는 고급 기능을 enterprise 폴더에 묶어 상용 라이선스를 붙이고, Twenty는 AGPLv3에 일부 파일만 상용 표기를 얹어요. 라이선스 단순함은 DeskcommCRM이 낫지만, 생태계 규모는 Twenty·Chatwoot이 훨씬 큽니다.

저장소 스스로도 위험을 인정해요. docs/current-state.md(2026-07-29)는 첫 문장부터 자신을 "유지되지 않는 스냅샷"이라 부르고, 2026-08-14 감사에서 그 안의 진술 40개가 이미 낡았다고 기록했습니다. docs/threat-model.md는 로그인·비밀번호 재설정 같은 인증 표면에 시도 제한이 없다는 위험을 최고 등급으로 올려뒀고요. 이후 lib/auth/rate-limit.ts로 네 지점을 막았다는 기록이 있지만, 문서는 "재감사 없이는 등급을 낮추지 않는다"고 못 박아뒀습니다.

DeskcommCRM 성숙도: 정식 버전 번호를 쓰지만, 자체 문서가 스스로를 "유지되지 않는 스냅샷"이라 선언한 상태입니다. 알파·베타 표기가 없다고 안심하기보다 "빠르게 움직이는 실사용 초기 단계"로 보는 편이 정확해요.

지금도 실운영 결함이 올라옵니다. 2026-09-12 하루에만 fn_decrypt_oauth 10~30% 실패(#754), 이벤트 8종 미소비 적체(#753), 연락처 삭제 시 트랜잭션 없는 데이터 파괴(#752)가 보고됐어요. 기여자 분포도 melgarafael이 3,494커밋으로 2위(88커밋)와 40배 격차인 1인 집중 구조예요. 커뮤니티 반응은 HN에서 0건, X에서도 유의미한 언급을 찾지 못했어요. Reddit은 접근이 막혀 확인하지 못했습니다(없다는 뜻은 아니에요). 결국 최근 30일 이슈 119건·PR 394건이라는 GitHub 활동이 실질 신호죠. README와 이슈 대부분이 포르투갈어라 영어권 확산은 아직이에요.

아키텍처: 멀티테넌시와 이벤트 큐로 신뢰를 설계하다

계층선택
프론트엔드 / DBNext.js 16, Supabase(Postgres+RLS)
인증 / 큐Supabase Auth / event_log+cron 워커
AIVercel AI SDK v7(OpenRouter·Anthropic·OpenAI·Google)
배포Docker 기반 VPS

눈에 띄는 설계 결정이 셋 있어요. 테넌트 인식 테이블마다 organization_id를 두고 RLS를 걸어 멀티테넌시를 DB 층에서 강제합니다. 트리거가 HTTP를 직접 부르지 않고 event_log에 이벤트를 쌓아 cron 워커가 소비하는 구조라 트랜잭션이 외부 장애에 묶이지 않고요. CI 필수 체크 5종 중 invariants는 A 조직이 B 조직 데이터를 0행 보는지 확인하는 RLS 격리 테스트를 매번 돌립니다. 인바운드 WhatsApp 메시지는 HMAC 검증과 멱등성 확인을 거쳐 워커가 RAG·MCP 툴로 응대를 생성하고, 발신 전 가드레일을 통과한 뒤에야 발송돼요.

"네이티브 AI 에이전트"가 실제로 하는 일

  • 테넌트별 RAG(pgvector)로 조직마다 지식 베이스 분리
  • ai-sentiment 워커의 감정 분석
  • AI를 담당자(assignee)로 취급하는 감사 로그형 핸드오프
  • 조직 단위 AI 비용 상한(폭주 방지 장치)
  • 해결된 대화를 지식으로 전환하는 자기 개선 루프(사람 승인 게이트 통과 후 반영)

리드 스코어링 하나가 아니라 "응대+자격 판정+퍼널 이동+자동화 실행+사람 호출"을 묶은 조작형 에이전트를 지향하는 셈입니다. 다만 이 서술의 1차 출처는 저장소 자체 문서라, 운영 품질은 도입 전 직접 검증이 필요해요.

메신저 채널의 진짜 위험: WhatsApp과 MCP

DeskcommCRM의 기본 WhatsApp 연결은 WAHA(WhatsApp HTTP API, Apache-2.0, 스타 7,383개)입니다. 2026.6.1 버전(2026-06-22)부터 유료 Plus 기능이 Core로 통합돼 다중 세션 포함 전 기능이 무료가 됐는데, DeskcommCRM 문서는 아직 "WAHA Plus"로 표기돼 있어 설치 전 공식 문서로 최신 버전을 확인하는 편이 안전해요.

핵심 위험은 따로 있어요. WAHA는 Meta 공식 WhatsApp 비즈니스(Business) API가 아니라 연결된 기기 세션을 흉내 내는 비공식 경로라, 상업적 자동 발송은 계정 정지로 이어질 수 있어요. WAHA 공식 문서도 "먼저 말 걸지 말 것·한 번에 많이 보내지 말 것·사람처럼 처리할 것"을 차단 회피 원칙으로 제시할 정도예요. 실무적으로는 WAHA를 인바운드 응대에만 쓰고, 아웃바운드 캠페인은 Meta Cloud API로 분리하는 편이 안전합니다.

MCP(CRM 기능을 AI가 호출하는 내부 서버)는 스펙 문서 상태가 "draft(pre-implementation)"이고 외부 클라이언트 연결은 "범위 밖"으로 명시돼 있어요. 지금은 내부 에이전트 전용 단계인 셈이죠.

한국에서는 왜 그대로 안 먹히나

카카오 2026년 2분기 실적발표(2026-08-06) 기준 카카오톡 국내 MAU는 4,963만 1천 명입니다. 한국 상담 트래픽이 몰려 있는 이 채널은 "채널 생성→비즈니스 채널 인증→발신프로필 등록→템플릿 검수(영업일 2~5일)"를 거치는 공식 카카오 알림톡·상담톡 경유가 원칙이라, WhatsApp 같은 QR 우회 경로 자체가 없어요. 그래서 한국 도입은 CRM·AI 에이전트·MCP만 쓰고 채널을 카카오 비즈메시지로 교체하는 쪽이 현실적이에요. 저장소가 채널을 lib/channels/ 어댑터 패턴으로 분리해둔 덕에 구조적으로는 가능하지만, 가벼운 설정이 아니라 별도 개발 과제예요.

"우리 서버에 둔다"가 국외이전 문제를 자동으로 해결해주지는 않습니다. 개인정보 보호법 제28조의8은 개인정보의 국외 제공·처리위탁·보관을 원칙적으로 제한하는데, DeskcommCRM 기본 구성은 Supabase·OpenRouter·Anthropic·OpenAI 같은 해외 서비스를 쓰므로 앱과 DB를 국내에 둬도 LLM 호출이 국외로 나가면 여전히 국외이전이에요. 경계를 닫으려면 DB 리전과 LLM 제공자를 함께 국내로 바꿔야 하고요. (법령 해석은 참고용이며, 실제 도입 전 법률 검토를 권합니다.)

비용 구조: 소프트웨어는 무료, 운영은 유상이다

서비스요금
DeskcommCRM라이선스 $0 + VPS·Supabase·LLM API 비용
Kommo$25~45/사용자·월(최소 6개월 계약)
Intercom$29~132/시트·월 + AI 해결 건당 $0.99
OctadeskR$2,499~4,399/월(온보딩 컨설팅 별도)

시트당 과금이 사라지는 대신 인프라 운영 책임이 생기는 교환이라, 팀이 크고 운영 인력이 있을수록 유리한 구조입니다.

도입 전에 확인할 것

  • 고객이 실제로 WhatsApp으로 문의하나요? 아니라면 채널 교체 비용부터 산정하세요.
  • 아웃바운드 발송 계획이 있다면 WAHA 대신 Meta Cloud API나 카카오 공식 비즈메시지를 전제로 설계하세요.
  • VPS·Supabase·LLM 키를 운영할 사람이 있나요? Supabase 무료 플랜은 자동 백업이 없어 backup.sh를 cron에 걸어야 합니다.
  • 대화 데이터의 국외이전 경로(앱·DB·LLM 각각의 물리 위치)를 그려보셨나요?
  • 8일 만에 마이너 버전 6개가 나오는 속도라, 자동 업데이트를 켤지 버전을 고정할지 먼저 정하세요.

마무리

DeskcommCRM은 라이선스가 단순하고 개발 속도가 빠른 오픈소스 CRM입니다. 다만 저장소 스스로 인정한 위험, 진행 중인 실운영 결함, WhatsApp 채널의 계정 정지 구조, 카카오톡 중심인 한국 채널 환경까지 겹쳐 보면 "그대로 설치"는 답이 아니에요. CRM과 AI 에이전트, MCP 부분을 가져오고 채널만 국내 사정에 맞게 바꾸는 쪽이 현실적이에요. 우리 팀 상황에 맞는지부터 따져보셔도 충분합니다. 판단에 필요한 기준은 위에 정리해 뒀어요.


자주 묻는 질문 (FAQ)

Q: 카카오톡에서도 WhatsApp처럼 QR로 바로 연결할 수 있나요?

안 됩니다. 카카오 알림톡·상담톡은 비즈니스 채널 인증과 템플릿 검수(영업일 2~5일)를 거치는 공식 경유만 허용해서, WhatsApp 같은 QR 우회 경로 자체가 없어요.

Q: 자체 호스팅하면 개인정보 국외이전 문제는 신경 안 써도 되나요?

아닙니다. 앱과 DB를 국내에 둬도 OpenRouter·Anthropic·OpenAI 같은 해외 LLM API를 호출하면 그 부분은 여전히 국외이전이에요. 경계를 닫으려면 DB 리전과 LLM 제공자를 함께 국내로 바꿔야 해요.

Q: 무료 오픈소스인데 실제로는 비용이 얼마나 드나요?

소프트웨어 라이선스는 MIT라 무료지만 VPS·Supabase·LLM API 사용량·운영 인건비가 따로 듭니다. 시트당 과금이 없는 대신 운영 인력이 필요한 구조라, 여력이 없는 팀에는 오히려 불리할 수 있어요.


참고 자료