단순함을 유지하는 소규모 팀용 경량 CRM 스키마

이 CRM 스키마가 해결해야 할 문제

소규모 팀은 매일 이런 질문에 빠르게 답할 수 있는 CRM이 필요합니다: 지금 누구와 대화하고 있나? 우리가 성사시키려는 거래는 무엇인가? 마지막으로 무슨 일이 있었나? 다음에 무엇을 해야 하나? 경량 CRM 스키마의 진짜 목적은 이런 질문에 답하는 것입니다. 그걸 지원하지 않는 항목은 대부분 잡음입니다.

소규모 팀은 깊은 계정 계층구조나 수십 개의 커스텀 객체, 복잡한 스코어링 모델이 거의 필요 없습니다. 대신 명확한 소유권, 접촉 기록의 간단한 이력, 모두가 같은 방식으로 이해하는 파이프라인이 필요합니다.

“단순함”은 자유 텍스트와 중복에 의존할 때 깨집니다. 한 사람이 거래 단계를 "Negotiation"으로 쓰고 다른 사람이 "negotiating"으로 쓰면 보고는 추측이 됩니다. 활동이 통화, 미팅, 노트용으로 따로 테이블에 분리돼 있으면 여러 날짜 필드가 생기고 신뢰할 수 있는 "마지막 접촉" 값이 사라집니다.

이 스키마는 복잡해지지 않고도 대부분의 소규모 팀 CRM을 커버하는 네 가지 핵심 객체에 집중합니다:

• Contacts(그리고 선택적으로 Organizations): 대화하는 사람들
• Deals: 파이프라인을 통해 추적하는 기회
• Activities: 작업, 미팅, 통화, 노트에 대한 통합 로그
• Permissions: 누가 무엇을 보고 수정할 수 있는지에 대한 실용적 규칙

깨끗한 보고는 이번 주 단계별 거래, 단계 간 전환율, 평균 단계 체류 시간, 거래별 마지막 활동, 그리고 각 담당자의 오늘 개방된 작업을 신뢰성 있게 보여줄 수 있어야 합니다. 이런 보고는 팀 인원이 3명에서 15명으로 늘어나도 여전히 의미가 있어야 합니다.

내부 CRM을 AppMaster 같은 노코드 도구에서 만든다면, 이 접근법은 데이터베이스를 작게 유지하면서 대시보드와 주간 리뷰에 안정적인 숫자를 제공합니다.

박스에 가둬두지 않으면서 경량을 유지하는 원칙

경량 CRM 스키마는 한 가지 질문에 명확히 답할 때 잘 작동합니다: 이 사실은 어디에 저장되나? 같은 “진실”을 두 곳에 저장할 수 있으면 저장됩니다. 그러면 보고가 흐트러집니다.

소수의 원천 객체를 선택하고 모든 것이 그것들을 가리키게 하세요. 대부분의 소규모 팀에는 Contacts, Organizations(선택적), Deals, Activities가 충분합니다. 더 많은 세부가 필요하면 하나의 텍스트 필드에 의미를 집어넣지 말고 새 테이블을 추가하세요. 그런 필드는 쓰레기 서랍이 됩니다.

모델을 단순하고 유연하게 유지하는 몇 가지 규칙:

• 사실 하나는 집 하나: 전화번호는 Contact에, 거래 금액은 Deal에.
• 과부하된 필드보다 명시적 테이블을 선호: 스테이지 이력은 쉼표로 구분된 문자열이 아님.
• ID는 안정적으로, 이름은 편집 가능하게: 사람은 회사 이름을 바꾸지만 기본 키는 바뀌지 않음.
• “상태”와 “유형”을 분리: 작업은 동시에 “open”이면서 “call”일 수 있음.
• 가져오기는 엉망일 것을 가정: 빈칸, 중복, 이상한 포맷은 정상.

초기부터 엉망인 데이터를 대비하려면 몇 가지 지루하지만 강력한 필드를 추가하세요: created_at, updated_at, 그리고 주요 테이블에 간단한 external_id(또는 import_source + import_key). 이렇게 하면 중복을 만들지 않고 다시 가져오기 할 수 있는 안전한 방법이 생깁니다.

구체적 예: 스프레드시트를 가져올 때 “Acme Inc.”가 절반 행에서는 “ACME”로 등장합니다. Organization.name은 편집 가능하고 Organization.id는 안정적이라면 나중에 레코드를 병합해도 기존 거래와 활동이 깨지지 않습니다.

Contacts와 Organizations: 실용적인 최소 구조

경량 CRM 스키마는 한 가지 결정에서 시작합니다: 사람만 추적할 것인가, 아니면 사람과 회사를 함께 추적할 것인가? 팀이 기업에 판매한다면 Contact(사람)과 Organization(회사)를 둘 다 두는 것이 거의 항상 좋습니다. 소비자 대상으로 판매한다면 Organizations를 완전히 생략하고 모든 기록을 Contact로 유지할 수 있습니다.

B2B 설정에서는 관계를 단순하게 유지하세요: 각 Contact는 하나의 기본 Organization에 속할 수 있고(nullable), 한 Organization은 여러 Contact를 가질 수 있습니다. 이는 대부분의 소규모 팀 워크플로를 복잡한 계정 계층 없이 커버합니다.

필수 필드는 최소로 유지

필수 필드를 너무 많이 만들면 데이터가 엉망이 되는 가장 빠른 방법입니다. 좋은 기준은:

• Contact: id, 이름(또는 first_name + last_name), created_at
• Organization: id, name, created_at

나머지(직책, 웹사이트, 주소, 업종, 출처)는 선택 항목으로 두세요. 나중에 규칙을 추가할 수 있지만 "N/A" 같은 플레이스홀더로 가득한 데이터베이스를 정리하기는 어렵습니다.

이메일과 전화: 고통 없는 유니크 처리

이메일을 유니크하게 만드는 것은 유혹적입니다. B2C나 로그인 시스템 역할을 하는 CRM에는 잘 맞습니다. 소규모 B2B에서는 공유 인박스(sales@, info@)와 재사용되는 전화번호가 흔합니다. 엄격한 유니크 규칙은 유효한 레코드를 막을 수 있습니다.

실용적인 절충안:

• 값이 존재할 때만 유니크를 강제(그리고 당신의 워크플로에 맞을 때만).
• 중복 허용하되 유사한 값이 발견되면 UI에서 소프트 경고를 보여줌.

여러 이메일이나 전화번호가 필요하면 email_2, phone_3 같은 컬럼을 추가하지 마세요. 대신 별도 테이블(예: ContactMethod에 type, value, is_primary)을 사용하세요. 보고는 깔끔하게 유지되고 모델은 자연스럽게 확장됩니다.

예: 분기 중간에 Pat이 이직한 경우 Contact가 Organization과 연결되어 있으면 Pat을 새 회사로 옮기고 과거 연락처 정보를 기록으로 남겨도 회사별 집계가 여전히 정확합니다.

Deals와 파이프라인: 읽기 쉬운 구조

거래(Deal)는 예측의 단위입니다: 명확한 다음 단계가 있는 잠재 구매. 거래 레코드는 작게 유지하고 다른 모든 것을 참조하세요.

누구에게나 설명할 수 있는 필드로 시작하세요:

• Deal name: 목록에서 의미 있는 짧은 라벨
• Stage: 파이프라인 단계 참조(수기 입력 금지)
• Value: 예상 금액(시스템 전체에서 하나의 통화 사용 권장)
• Owner: 진행을 책임지는 사람
• Close date: 현재의 최선 추정 마감일

관계는 거래에 하나의 주요 연락처를 선택하세요. 이렇게 하면 보고가 간단해집니다(예: 연락처별 수익, 세그먼트별 승률). 가끔 더 많은 사람이 참여해야 한다면 deal_contacts 테이블을 추가해 추가 연락처를 첨부하세요. 대부분 소규모 팀은 1명의 주요 연락처와 선택적 참여자면 충분합니다.

스테이지에서 CRM이 흔히 엉망이 됩니다. 스테이지를 자유 텍스트로 저장하지 마세요. 스테이지를 참조 데이터로 저장하면 나중에 단계 이름을 바꿔도 보고가 깨지지 않습니다. 최소 스테이지 테이블은 다음을 포함할 수 있습니다:

• stage_id
• pipeline_id
• stage_name
• stage_order
• is_closed(또는 won/lost 플래그 분리)

팀이 작다면 “리드”와 “거래”를 분리하지 마세요(리드를 정말 다르게 관리하지 않는 한). 실용적인 규칙: 추적할 실질적 기회가 생기면 거래로 만드세요. 그 전에는 연락처에 "new"나 "nurture" 같은 상태를 두세요. 이렇게 하면 파이프라인이 읽기 쉬워지고 반쯤 생성된 거래가 숫자를 오염시키지 않습니다.

예: 두 명으로 구성된 영업팀이 "Acme Renewal"을 Sam이 소유한 거래로 기록하고, 단계는 "Proposal Sent", 금액은 12,000, 마감일은 다음 달입니다. 주요 연락처는 구매자이고 두 번째 연락처는 재무 승인자입니다. 단계 이름과 순서가 고정되어 있으므로 보고는 일관됩니다.

Activities: 작업, 미팅, 노트를 위한 하나의 모델

소규모 팀은 통화, 이메일, 미팅, 노트를 위해 별도의 테이블이 필요하지 않습니다. 하나의 Activity 모델이면 충분한 경우가 많고 CRM 사용과 보고를 더 쉽게 만듭니다.

단일 Activity 테이블

일어난(또는 일어나야 하는) 일마다 하나의 레코드를 사용하세요. type 필드는 작고 고정된 집합을 사용하세요(예: call, email, meeting, note, task). 목록을 짧게 유지해 사람들이 항상 같은 단어를 선택하도록 하세요.

활동을 혼동 없이 연결하려면 명확한 규칙을 사용하세요:

• 개인과 관련된 경우(후속 통화, 소개 이메일)는 contact에 연결.
• 매출과 관련된 경우(가격 협의, 협상 미팅)는 deal에 연결.
• 둘 다 관련되면 둘 다 연결하되 파이프라인 보고에는 deal을 기본으로 처리.

실무에서는 Activity에 contact_id(nullable), deal_id(nullable), 선택적 owner_id(책임자)를 두는 것이 일반적입니다.

보고에 친화적인 타임스탬프

due_at과 completed_at을 모두 유지하세요. 서로 다른 질문에 답합니다. due_at은 계획과 작업부하를 알려주고, completed_at은 실제 수행과 사이클 타임을 알려줍니다.

별도 상태 필드 없이도 파생 상태를 만들 수 있습니다: completed_at이 설정돼 있으면 완료로 간주하고, 아니면 열려 있는 것으로 간주하세요. 이렇게 하면 서로 동기화되지 않는 추가 상태 값이 생기는 것을 피할 수 있습니다.

활동 텍스트는 summary나 body 같은 하나의 검색 가능한 필드에 저장하세요. 초반에는 노트를 과도하게 구조화하지 마세요. 예: "Maya와의 통화: 예산 확인, 금요일 제안서 발송." 실제 불편함이 느껴질 때만 전문 필드를 추가하세요.

소유권과 가시성: 실용적으로 유지

소유권은 다음 행동을 책임지는 사람입니다. 경량 CRM 스키마에서는 일반적으로 거래에 owner_user_id 같은 한 필드가 있습니다(연락처에도 종종 포함).

"소유자"의 두 가지 의미가 종종 섞입니다: 사용자 할당(특정 개인)과 팀 할당(그룹). 처음부터 모든 것을 팀 소유로 만들면 오늘 누가 행동해야 하는지 명확성이 사라집니다.

대부분 소규모 팀에 작동하는 기본값은: 모든 것은 모두에게 보이지만, 각 거래에는 정확히 한 명의 소유자가 있습니다. 협업은 쉬워지고, 누군가 대신해야 할 때 권한 문제도 줄어듭니다.

더 엄격한 가시성이 필요할 때는 복잡한 매트릭스가 아닌 단일 스위치로 유지하세요. 예를 들어 거래와 활동에 visibility 필드를 추가하고 public과 private 값을 두면 private는 "소유자(및 관리자)만 볼 수 있음"을 의미하게 하세요.

팀이나 테리토리가 필요해지는 경우는 다음과 같을 때입니다:

• 서로의 거래를 보지 못해야 하는 별도 그룹이 있을 때
• 팀별 성과를 보고하고 사람이 팀 사이를 이동할 때
• 관리자는 자신의 그룹에 접근해야 하지만 전체 회사에는 접근하면 안 될 때
• 리드를 공유 큐에 할당하고 영업 담당자가 받아가는 방식이 필요할 때

소유권은 보고에 영향을 줍니다. "담당자별" 깨끗한 숫자를 원하면 거래의 현재 owner_user_id로 보고하세요. "팀별" 집계를 원하면 owner_team_id를 추가하거나 소유자의 프로필에서 유도하되 어떤 필드가 진실의 출처인지 명확히 하세요.

예: 두 명이 인박스를 공유하는 경우 새 거래는 owner_user_id = null, owner_team_id = Sales로 시작합니다. Alex가 가져가면 owner_user_id = Alex로 설정(팀은 Sales 유지)하세요. 파이프라인은 읽기 쉬우며 팀 합계도 작동합니다.

권한 설계: 복잡하지 않게 충분히 통제

간단한 RBAC로 시작

권한은 세 가지 아이디어를 분리할 때 가장 잘 작동합니다: 역할(누구), 자원(무엇), 액션(무엇을 할 수 있는가). 이것이 역할 기반 접근 제어(RBAC)이며 팀이 커져도 이해하기 쉽습니다.

자원은 핵심 객체와 가깝게 유지하세요: Contacts, Organizations, Deals, Activities, 필요하면 Pipelines(스테이지 편집 가능 시). 이들에 대해 view, create, edit, delete, export 같은 작고 일관된 액션 집합을 정의하세요.

Export는 분리할 가치가 있습니다. 많은 팀은 광범위한 조회 권한은 괜찮지만 대량 데이터 추출은 제한하고 싶어합니다.

객체 수준 권한이 시작하기 가장 쉬운 지점입니다: "이 역할이 거래를 편집할 수 있는가?" 대부분 소규모 팀에는 이것만으로 몇 달은 충분합니다. 레코드 수준 규칙(개별 연락처나 거래별)은 복잡성이 나타나는 곳이므로 진짜 필요할 때만 추가하세요.

실용적인 첫 단계는 단일 소유 규칙입니다: 각 레코드에 owner_user_id가 있고 비관리자는 자신이 소유한 것만 편집할 수 있게 하세요. 한 단계 더 필요하면 team_id를 추가해 팀 전체 보기 권한을 주고 편집은 소유자만 가능하게 하세요.

정말 필요할 때만 레코드 수준 규칙 추가

다음과 같은 경우 레코드 수준 권한을 추가하세요:

• 영업 담당자가 서로의 거래를 보지 못하게 해야 할 때
• 지원팀은 거래를 볼 수는 있지만 절대 편집하면 안 될 때
• 관리자는 모두 볼 수 있고 소유자 재할당 권한이 필요할 때

감사(audit)는 가볍지만 실용적으로 만드세요. 각 주요 테이블에 created_at, created_by, updated_at, updated_by를 추가하세요. 나중에 더 깊은 이력이 필요하면 작은 audit_log 테이블(object type, record id, action, who, when, short JSON of changed fields)을 추가하세요.

단계별: 주말에 스키마 구축하기

작게 제품처럼 다루면 가장 쉽게 맞출 수 있습니다: 먼저 데이터를 정의하고, 실제 항목으로 작동하는지 증명한 다음 화면을 만드세요.

1일차: 데이터 모델 확정

종이에 ERD를 빠르게 스케치하세요. 테이블 수는 작게 유지하되 링크는 분명히 하세요: contact는 선택적으로 organization에 속하고, deal은 파이프라인에 속하고 소유자가 있으며, activity는 contact와/또는 deal에 연결될 수 있습니다.

그다음 기본을 순서대로 하세요:

• 객체와 관계 정의: contacts, organizations, deals, activities, users/roles, 필요시 작은 조회 테이블
• 필수 필드와 기본값 정의: created_at, owner_id, 주요 이름들을 필수로; 금액을 쓰면 스테이지와 통화 기본값 설정
• 열거형 또는 조회 테이블 정의: 거래 단계와 활동 타입을 고정해 보고가 일관되게 유지되도록
• 일상적으로 필터할 외래키와 owner_id, stage, due_at, created_at 같은 컬럼에 인덱스 추가
• 실제 데이터 20건으로 테스트: 실제 이름, 날짜, 엉성한 노트를 넣어 무엇이 깨지는지 확인

2일차: 보고가 깔끔한지 증명

폼을 만들기 전에 팀이 매주 묻는 6~8개의 질문을 적어보세요. 예: "단계별로 Negotiation에 있는 거래(담당자별)", "연체 활동", "이번 달 신규 연락처", "월별 획득 수익" 등. 질문에 답하려면 복잡한 조인이 필요한지 확인하고 필요하면 스키마를 고치세요.

간단한 테스트 시나리오를 만들어 보세요: 한 회사에 3명의 연락처, 다른 단계에 있는 2개의 거래, 그리고 그들 사이에 걸쳐 6개의 활동(통화 1, 미팅 1, 작업 2, 노트 2)을 추가하세요. 그런 다음 소유자가 누구인지, 다음 할 일이 무엇인지, 지난주에 무엇이 변경됐는지 추측 없이 답할 수 있는지 확인하세요.

데이터가 안정되면 UI와 자동화를 마지막에 만드세요. 이렇게 하면 더 빠르게 진행하고 보고가 현실과 맞지 않아 역사(데이터)를 다시 쓰는 일을 피할 수 있습니다.

보고를 엉망으로 만드는 흔한 실수

보고가 엉망이 되는 원인은 보통 오늘은 빠른 해결처럼 보이지만 매주 비용을 발생시키는 "빠른 수정"에서 시작합니다. 경량 CRM 스키마는 데이터가 명확한 형태를 가지고 팀이 실제로 따르는 몇 가지 규칙이 있을 때 가장 잘 작동합니다.

흔한 함정 중 하나는 모든 것을 하나의 "customer" 테이블에 넣는 것입니다. 단순해 보이지만 "한 회사에 연결된 거래는 몇 개인가?" 또는 "어떤 사람이 이직했나?" 같은 기본 질문에 답하기 어렵습니다. 사람(contacts)과 회사(organizations)를 분리하고 연결하세요.

또 다른 보고 킬러는 거래 단계를 자유 텍스트로 두는 것입니다. 한 사람이 "Negotiation"이라하면 다른 사람은 "negotiating"이라고 쓰면 파이프라인 차트는 이미 틀립니다. 고정된 스테이지 리스트(또는 스테이지 테이블)를 사용해 모든 거래가 같은 값을 가리키도록 하세요.

하나의 필드에 여러 값을 넣는 것도 피하세요. 쉼표로 구분된 이메일이나 전화번호는 검색, 중복 제거, 내보내기를 고통스럽게 만듭니다. 여러 값이 정말 필요하면 자식 테이블(row per value)로 저장하세요.

활동은 날짜가 불분명할 때 엉망이 됩니다. 단일 "date" 필드는 그 날짜가 지난 금요일의 마감일인지 완료일인지 알려주지 않습니다. 연체된 작업과 완료된 작업을 올바르게 보고하려면 이 개념을 분리하세요.

미래의 당신을 구하는 빠른 체크리스트:

• Contacts와 Organizations를 분리하고 연결하세요
• 스테이지 이름 대신 스테이지 ID 사용
• 하나의 필드에는 하나의 값; 여러 값은 자식 테이블로
• due_at과 completed_at을 별도로 유지
• 단순한 역할로 시작; 실제 워크플로가 보일 때만 레코드 수준 규칙 추가

예: 팀이 통화를 노트로 기록하고 나중에 같은 필드를 편집해 "완료"로 표시하면 후속 조치가 얼마나 걸렸는지 보고할 수 없습니다. 별도 필드가 있으면 그 보고는 간단합니다.

스키마 확정 전에 빠르게 확인할 체크리스트

화면, 자동화, 대시보드를 만들기 전에 보고와 규칙을 빠르게 점검하세요. 경량 CRM 스키마는 일반 질문에 커스텀 해킹이나 일회성 필드 없이 답할 수 있을 때만 경량으로 유지됩니다.

실제 샘플 데이터(20명 연락처, 10건 거래 정도면 충분)를 사용해 다음 항목을 점검하세요. 막히면 보통 누락된 필드, 일관성 없는 선택 목록, 또는 너무 느슨한 관계 때문입니다.

대부분 문제를 잡아내는 5가지 체크

• 보고 기본: 단계, 소유자, 마감 월별로 거래를 그룹화할 수 있는가? 어떤 날짜 필드를 써야 할지 추측할 필요가 없는가?
• 업무 관리: "소유자별 연체 활동"을 하나의 보고로 뽑을 수 있는가(연체는 단일 due date와 명확한 완료 상태 기준)?
• 연락처와 조직: 연락처가 조직 없이 존재할 수 있고 나중에 연결해도(이메일, 노트, 거래 이력 유지) 문제가 없는가?
• 일관성: 스테이지와 활동 타입이 고정 리스트에서 오기 때문에 "Follow up", "Follow-up", "Followup"처럼 중복 값이 생기지 않는가?
• 안전성: 레코드 삭제나 리스트 내보내기를 누가 할 수 있는지 제한할 수 있으면서도 거래 단계를 이동시키는 정상 업데이트를 막지 않는가?

다섯 항목에 모두 "예"라면 좋은 출발점에 있습니다. 아니라면 스키마가 아직 작을 때 고치세요.

실용적 팁: 스테이지와 활동 타입을 한 번(테이블이나 enum으로) 정의하고 재사용해 모든 화면과 프로세스가 같은 값을 사용하게 하세요.

현실적인 소규모 팀 예시와 다음 단계

5인 에이전시가 경량 CRM 스키마 테스트로 좋습니다. 팀은 바쁘고, 리드는 여기저기서 들어오며, 아무도 데이터를 관리하기를 원치 않습니다. 예를 들어: 관리자 1명, 영업 2명, 운영 1명, 읽기 전용 동료(숫자만 확인하는 창업자) 1명.

새로운 인바운드 요청이 도착하면(웹 폼 또는 이메일): "웹사이트 리프레시 필요, 예산 $15k, 일정 6주." 규칙은 단순합니다: 회사면 하나의 Organization과 한 명의 Contact를 만들고 거래를 조직에 묶되 해당 거래의 주요 연락처로 설정하세요.

속도를 유지하려면 작은 인테이크 체크리스트를 사용하세요:

• 도메인이나 회사명이 기존 조직과 일치하면 재사용
• 사람의 이메일이 존재하면 해당 연락처 재사용
• 실질적인 구매 의사가 있으면 항상 거래 생성
• 원래 메시지는 거래 설명에 넣기
• 출처(referral, form, outbound)는 단일 필드로 저장

활동은 빠진 통화를 방지합니다. 모든 다음 단계가 날짜가 있는 항목으로 되어 있고 담당자가 지정되어 있기 때문입니다. 영업이 디스커버리 콜을 하면 회의로 활동 하나를 기록하고 다음 행동(예: 이틀 후 통화)을 즉시 추가합니다. 운영이 작업범위를 정해야 하면 같은 거래에 작업 활동을 추가해 한 곳에서 볼 수 있게 합니다.

역할은 실용적으로 유지하세요: Admin은 모든 것을 편집하고 설정을 관리, Sales는 연락처·거래·자신의 활동 생성 및 업데이트, Ops는 전달 관련 필드와 활동 업데이트, Read-only는 파이프라인과 보고 보기만 가능.

빠르게 내부용 도구로 만들고 싶다면 AppMaster(appmaster.io)은 직관적인 선택입니다: Data Designer에서 스키마를 모델링(PostgreSQL), Business Process 에디터에서 규칙을 추가하고, 간단한 리드 인박스와 거래 페이지를 만들어 AppMaster Cloud나 자체 클라우드로 배포할 수 있습니다.