AI로 직접 만든 CRM, 어디까지 만들고 어디부터 살까?

AI에게 고객 목록과 거래 화면을 만들어달라고 해보셨나요? 원하는 항목을 넣고, 거래 단계를 바꾸고, 미팅 메모를 붙일 수 있게 되면 이런 생각이 듭니다. “이 정도면 우리 팀이 직접 써도 되지 않을까?”

직접 만든 도구를 선택할 수도 있습니다. 다만 실제 업무에 쓰기 전에는 다음 질문에도 답해야 합니다. 중복 고객은 어떻게 정리할까요? 담당자가 옮기면 누가 접근 권한을 바꿀까요? 영업 단계가 달라지면 기존 기록과 자동화도 함께 고칠 수 있을까요?

CRM 자체 구축·구매·혼합 운영은 처음 만드는 비용뿐 아니라, 이후 변경과 운영을 어디까지 맡을 것인지로 비교해야 합니다. 고유한 업무가 중요하고 지속 운영을 맡을 수 있다면 직접 구축을, 제공되는 기능이 요구를 충족한다면 구매를 검토할 수 있습니다. 고객 기록의 기반과 고유 업무를 분리할 수 있다면 혼합도 대안입니다. 어느 방식이든 데이터 품질과 실제 업무 결과를 관리할 역할은 필요합니다.

제품 순위 대신, 같은 업무를 세 방식에 대입해 만들 일과 맡길 일을 결정해보겠습니다.

CRM 자체 구축과 구매, 비교 단위를 먼저 나눕니다

고객 기록의 기반과 우리만의 업무는 같은 대상이 아닙니다

고객 기록을 보관하는 일과 우리 회사만의 제안서 검토 방식을 구현하는 일은 따로 선택할 수 있습니다.

다음 구분은 이 글에서 제안하는 검토 방식이며 기술 표준은 아닙니다.

• 공식 기록: 고객·연락처·거래와 그 관계를 보관하고, 팀이 최종 상태로 인정하는 기록입니다.

• 업무 규칙과 화면: 담당자 배정, 거래 단계, 필수 입력 항목처럼 일하는 방식을 정하고 보여주는 부분입니다.

• AI 처리: 미팅 요약이나 다음 행동 후보처럼 AI가 자료를 읽고 결과를 만드는 부분입니다.

• 외부 도구 연결: 이메일·캘린더·다른 업무 시스템과 데이터를 주고받는 부분입니다.

고객·거래 관리는 제품으로 충분해도 내부 심사 자료의 검토는 별도 구현이 필요할 수 있습니다. 반대로 제품 설정으로 해결되는 업무라면 따로 만들 이유가 줄어듭니다.

기록 정비부터 고민된다면 AI가 활용할 CRM 데이터 기반을 참고하세요. 여기서는 그 기반을 누가 맡을지에 집중합니다.

세 방식은 무엇을 맡기는지가 다릅니다

직접 구축은 필요한 고객관리 기능을 자체 애플리케이션으로 구현하는 방식입니다. 데이터베이스나 로그인, 서버 운영까지 모두 처음부터 만들 필요는 없습니다. 관리형 서비스를 활용하되 우리 앱의 업무 규칙과 변경을 직접 관리할 수 있습니다.

상용 구매는 이미 제공되는 CRM을 선택하고 설정해 사용하는 방식입니다. 소프트웨어를 서비스로 이용하는 SaaS도 여기에 포함됩니다. 다만 구매가 곧 개발 없는 운영을 뜻하지는 않습니다. 요구에 따라 추가 연동이나 자체 코드가 필요할 수 있습니다.

혼합 운영은 구매한 기반과 직접 만든 부분을 함께 쓰는 방식입니다. 이 글에서는 상용 CRM을 공식 기록으로 두고 고유한 AI 처리 일부를 따로 만드는 구성을 예로 들겠습니다. 가능한 혼합 구조가 이것 하나뿐이라는 뜻은 아닙니다.

코드의 양보다 변경을 판단하고, 실행하고, 확인할 담당이 누구인지가 중요합니다.

구축은 직접 구현할 범위를, 구매는 제공 범위를, 혼합은 양쪽의 경계와 연결을 확인합니다. 어느 방식에도 내부 운영이 남습니다.

같은 질문으로 구축·구매·혼합을 비교합니다

다음 표는 제품 성능 순위가 아니라 검토 질문을 정리한 것입니다. 구체적인 기능과 공급자의 책임 범위는 제품·플랜·계약에 따라 확인해야 합니다.

Microsoft의 Azure 공동 책임 지침은 SaaS에서도 고객 데이터, 설정, 사용자 관리를 고객이 맡는 영역으로 설명합니다.[2] 이는 통제 책임에 관한 지침이지 모든 CRM의 계약상 책임표는 아닙니다. 구매 검토에서도 제품이 제공하는 기능과 내부에서 설정·관리할 일을 나눠 확인하세요.

GitHub의 AI 생성 코드 검토 지침은 자동 테스트와 정적 분석(코드를 실행하지 않고 문제를 찾는 검사), 프로젝트 목적과의 정합성 검토를 권고합니다.[1] 직접 구축할 때는 화면 동작뿐 아니라 실제 업무 규칙을 확인할 과정도 포함하세요.

직접 만드는 편이 나을 때, 구매하는 편이 나을 때

직접 구축: 고유한 요구와 맡을 수 있는 범위가 분명할 때

표준 CRM의 설정으로는 담기 어려운 업무가 있고, 그 차이가 사업 운영에 중요하다면 직접 구축을 검토할 이유가 있습니다. 필요한 기능이 작고 안정적으로 유지되는 업무라면, 광범위한 제품을 도입하는 것보다 좁은 도구를 만드는 편이 맞을 수도 있습니다.

업무 규칙 결정, 코드 검토·변경, 권한·복구 확인을 누가 맡을지도 정해야 합니다. 한 사람이 겸하더라도 시간과 예산은 필요합니다.

메모 도구에 견적·계약·청구를 계속 추가하면 처음과 다른 시스템을 운영하게 됩니다. 범위 확대를 다시 판단할 기준도 남겨두세요.

상용 구매: 제공 기능이 핵심 업무를 충족할 때

고객·연락처·거래 관리가 주된 요구이고, 제품을 실제로 시험했을 때 필요한 업무가 충족된다면 구매를 검토할 수 있습니다. 내부 개발 역량을 고객관리 기반보다 다른 핵심 업무에 쓰려는 선택도 가능합니다.

기능 목록만 보지 말고 실제 권한 조건에서 조회·설정·내보내기를 시험하세요. API(외부 프로그램과 데이터를 주고받는 접점)를 사용한다면 지원 범위와 이용 조건도 확인해야 합니다.

제품에 업무를 맞추느라 과도한 설정과 우회 연동이 쌓인다면 구매의 이점이 줄어들 수 있습니다. 구독료가 예측 가능하다는 것과 전체 운영 부담이 작다는 것은 다른 판단입니다.

혼합 운영: 경계를 나누는 이점이 연결 부담보다 클 때

고객·거래 기록은 상용 CRM에 맡기고, 회사 고유의 분석이나 화면만 직접 만드는 방식도 가능합니다. 기반을 다시 만들지 않으면서 고유한 부분에 개발 역량을 집중하려는 선택입니다.

하지만 별도 도구에 고객 목록과 담당자, 거래 단계가 다시 생기면 사실상 두 번째 CRM을 운영할 수 있습니다. 양쪽 중 어느 값이 맞는지 매번 사람이 판단한다면 경계를 다시 설계해야 합니다.

혼합을 고르기 전에는 별도 도구가 필요한 이유와, 그 도구가 멈춰도 업무를 이어갈 방법을 설명할 수 있어야 합니다.

같은 미팅 후속 업무를 세 방식에 대입해봅니다

아래는 대안을 비교하기 위한 가상 설계 예시입니다. 실제 고객 사례나 특정 제품의 제공 기능, 검증된 성과를 설명하는 것이 아닙니다.

대상 업무는 하나입니다. 미팅 메모를 읽고, 해당 고객과 거래를 식별한 뒤, 담당자가 검토한 다음 행동을 그 거래에 기록합니다.

완료 기준도 같습니다. 올바른 거래에 확정한 행동이 기록되고, 권한 있는 담당자가 확인할 수 있어야 완료입니다. 고객이나 거래가 불명확하면 임의로 반영하지 않습니다.

직접 구축한다면: 필요한 흐름을 앱 안에서 정합니다

자체 앱에 고객·거래 기록을 두고, 미팅 메모에서 나온 다음 행동 후보를 담당자가 검토한 후 저장하도록 설계할 수 있습니다. 어떤 정보를 보여주고 언제 확정할지 직접 정할 수 있다는 점이 이 방식의 이점입니다.

대신 같은 회사의 거래가 여러 개일 때 어떻게 구분할지, 담당자가 바뀌면 누구에게 검토 요청을 보여줄지, 저장 실패를 어떻게 확인할지도 구축 범위에 넣어야 합니다. 관리형 데이터베이스를 써도 이런 업무 규칙을 대신 결정해주지는 않습니다.

시험할 때는 정상적인 메모뿐 아니라 고객이 불명확한 메모, 이미 처리한 메모, 접근할 수 없는 거래도 넣어보세요. 모든 상황을 자동 처리하는 것보다, 처리할 수 없는 상태를 분명히 구분하는 쪽으로 범위를 줄일 수 있습니다.

구매한다면: 제공 기능과 남는 수작업을 함께 확인합니다

제품에서 제공하는 기록·작업 관리 기능으로 확정한 다음 행동을 남기는 흐름을 시험합니다. AI 요약이나 거래 연결이 필요하다면 실제 제공 여부와 동작 조건을 별도로 확인해야 합니다.

필요한 기능이 없더라도 구매가 바로 탈락하는 것은 아닙니다. 담당자가 미팅 메모를 확인하고 수동으로 행동을 등록하는 방식이 허용된다면, 그 검토·입력 시간을 포함해 비교하면 됩니다.

자동 반영이 필수인데 추가 개발이 필요하다면 개발·유지 담당과 비용을 포함해야 합니다. 수작업이 허용되는 대안과 자동 반영이 필수인 대안을 같은 조건인 것처럼 비교하지는 마세요.

혼합한다면: AI의 후보와 CRM의 확정 기록을 구분합니다

상용 CRM에는 고객·거래·확정된 다음 행동을 두고, 별도 AI 도구는 미팅 메모에서 후보를 만드는 역할만 맡기는 구성을 생각해볼 수 있습니다. 후보는 아직 팀이 실행하기로 결정한 공식 상태가 아닙니다. 담당자가 검토한 결과만 지정 경로를 통해 CRM에 반영합니다.

가상 설계 예시입니다. AI 후보와 공식 기록을 분리하고, 식별이 불명확한 건은 임의로 반영하지 않습니다.

이 구성을 선택한다면 연결 전에 다음을 문서로 정해보세요.

1. 고객·거래 연결 기준: 이름만으로 연결하지 않고 고유 식별자와 연결 기준을 정합니다. 식별이 불명확한 건은 수동 확인 대상으로 남깁니다.

2. 변경 경로: 최종 담당자·거래 단계·다음 행동은 어디에서 바꿀지 정합니다. 항목별 원본이 다르다면 각 항목의 원본과 변경 담당을 적습니다.

3. 실패 처리: 반영 실패, 중복 요청, 양쪽 값의 충돌을 누가 확인할지 정합니다. 자동 처리를 보류할 조건과 사람이 이어받는 경로를 둡니다.

4. 복제와 삭제: 별도 도구로 보낼 자료, 보관 기간, 접근 범위, 원본 삭제가 복제본에 반영되는 범위를 확인합니다.

5. 종료 조건: 별도 도구를 꺼도 확정한 고객·거래 기록이 남고, 담당자가 수동으로 후속 업무를 이어갈 수 있는지 시험합니다.

두 도구의 상태가 다를 때 무엇을 기준으로 일할지까지 정해야 혼합 운영의 경계가 생깁니다.

비용은 만드는 날부터 종료·이전하는 날까지 비교합니다

자체 구축의 초기 구현비와 제품의 월 구독료만 나란히 놓으면 범위가 달라집니다. 같은 기간, 같은 사용자·업무량, 같은 완료·권한·복구 기준을 적고 비용 항목을 채워보세요. 아래는 견적을 비교하기 위한 양식이며, 특정 가격이나 절감 효과를 계산한 결과는 아닙니다.

• 초기 비용: 요구 정리, 구현 또는 제품 설정, 데이터 정비와 이관, 사용자 교육, 도입 기준 충족 여부를 확인하는 수용 시험.

• 반복 비용: 구독·서버·저장·AI 사용료, 내부 운영과 결과 검수, 코드·설정·연결부 변경, 보안 대응.

• 예외 대응 비용: 장애 원인 확인, 잘못 반영된 기록 정정, 공급자나 AI 모델 변경에 따른 재검증.

• 종료·전환 비용: 데이터 내보내기, 항목과 관계 맞추기, 첨부·이력 대조, 업무 규칙 재구현, 병행 운영, 접근 권한 회수와 삭제 확인.

각 항목에 금액·시간과 근거·미확인 사항을 적으세요. 견적·내부 추정·시험 실측을 구분하고, 같은 담당자의 시간을 중복해서 넣지 않도록 확인합니다.

세 방식에서 똑같이 필요한 데이터 정비는 공통 비용으로, 대안에 따라 달라지는 작업은 추가 비용으로 구분할 수 있습니다. 내부 인력의 시간이 공짜는 아니지만, 줄어든 시간이 곧바로 현금 절감이 되는 것도 아닙니다. 그 시간을 다른 업무에 어떻게 사용할지까지 함께 판단해야 합니다.

CSV를 받는 것과 업무를 옮기는 것은 다릅니다

표 형식의 파일인 CSV를 내보낼 수 있어도, 고객과 거래의 연결 관계나 첨부·변경 이력까지 원하는 형태로 옮길 수 있는지는 별도 질문입니다. 데이터가 옮겨져도 거래 단계 규칙과 알림 설정을 다시 만들어야 할 수 있습니다.

구매라면 필요한 내보내기 범위와 계약 조건을 확인하고 대표 기록으로 이전 시험을 해보세요. 직접 구축이라면 데이터 구조 설명과 코드·운영 문서를 다른 담당자가 이해할 수 있는지 확인해야 합니다. 혼합이라면 공식 기록뿐 아니라 별도 도구의 미처리 후보와 연결 정보도 정리할 수 있어야 합니다.

옮길 수 있는 기록과 다시 만들어야 할 규칙을 구분해야 이전 비용도 비교할 수 있습니다.

파일 확보와 업무 이전은 다릅니다. 옮길 기록과 다시 만들 규칙을 나누고 대표 기록으로 이전을 시험하세요.

최종 선택은 한 장의 결정 메모로 남깁니다

미팅 후속 업무처럼 범위를 좁혀 아래 양식을 작성해보세요. 이 글의 제안이며 공인 진단표는 아닙니다. 영역별 선택과 함께 전체 구성에 책임 공백이 없는지 확인하는 양식입니다.

복사해서 쓰는 구축·구매·혼합 결정 메모

• 대상 업무 / 이번에 하지 않을 일:

• 완료 기준 / 필요한 품질·권한·복구 기준:

• 비교 기간 / 사용자·업무량 / 필수 기능 범위:

영역별 선택 — 아래 묶음을 영역마다 작성 - 영역: 공식 기록 / 업무 규칙·화면 / AI 처리 / 외부 도구 연결 - 맡길 방식: 직접 구축 / 구매 / 혼합 구성에서 맡길 위치 - 선택 이유: - 포기하는 기능 / 남는 제약 / 다른 영역과의 연결 조건: - 공식 기록의 위치 / 최종 변경 경로:

책임과 비용 - 업무 결과를 판단할 책임자: - 기술 변경·장애 대응 담당 / 부재 시 대체 담당: - 외부 공급자에게 맡기는 범위 / 내부에 남는 범위: - 초기·반복·예외·종료 비용 / 공통 비용과 추가 비용: - 견적·실측·추정의 구분 / 추정 근거와 불확실성: - 아직 확인하지 못한 사항 / 확인할 담당자:

시험과 재검토 - 정상 업무 시험 / 불명확한 입력·권한 부족·중복·실패 시험: - 복구·수동 업무 전환 / 내보내기·인수인계 시험: - 도입 또는 보류 판단 / 판단 근거: - 재검토 조건 / 다시 판단할 책임자:

재검토 조건도 구체적으로 정하세요. 구현 범위 확대, 연결부 유지 시간 초과, 내보내기·복구 시험 실패처럼 다시 판단할 상황을 남겨두면 됩니다.

책임자나 종료 방식이 비어 있다면 선택을 확정하기보다 미확인 사항부터 해결하세요. 제품을 더 시험하거나 직접 만들 범위를 줄여야 할 수 있습니다.

자주 묻는 질문

AI로 CRM을 만들면 상용 CRM이 필요 없나요?

직접 만든 범위로 필요한 업무를 충족하고 지속 운영도 맡을 수 있다면 자체 구축을 선택할 수 있습니다. 다만 화면 구현만으로 데이터·권한·변경·복구 요구까지 충족했다고 판단하지는 마세요. 상용 CRM이 필요한지는 우리 팀이 맡을 범위와 제품이 대신할 범위를 비교해 결정하면 됩니다.

자체 구축이 항상 더 저렴한가요?

항상 그렇다고 단정할 수 없습니다. 같은 기간과 업무 범위를 놓고 구현비뿐 아니라 기반 서비스, AI 사용, 변경·검수 인력, 종료·이전 비용을 함께 비교해야 합니다. 작은 업무를 좁게 만드는 선택과 CRM 전반을 구축하는 선택도 구분하세요.

상용 CRM을 사면 개발이 필요 없나요?

제공 기능과 설정으로 요구를 충족하면 별도 개발 없이 사용할 수 있습니다. 하지만 외부 시스템 연결이나 고유 규칙 때문에 개발이 필요할 수도 있으므로, 데모와 실제 업무 시험에서 남는 작업을 확인해야 합니다.

혼합 운영에서 고객 데이터의 원본은 어디에 두나요?

시스템 또는 항목별로 팀이 최종 상태로 인정하는 기록과 변경 경로를 정해야 합니다. 이 글의 예시는 고객·거래·확정 행동을 CRM에 두고 별도 도구의 결과를 후보로 구분했습니다. 모든 복제본을 동등한 원본으로 두고 충돌 때마다 임의로 고르는 상태는 피하는 편이 좋습니다.

나중에 다른 CRM으로 옮기기 쉽나요?

필요한 내보내기 범위와 데이터 구조, 새 시스템의 수용 범위에 따라 달라집니다. 고객 목록뿐 아니라 관계·첨부·이력과 업무 규칙 중 무엇을 이전하고 무엇을 재구현할지 시험해야 합니다. 자체 구축도 코드와 문서가 인계되지 않으면 전환이 어려울 수 있습니다.

마치며: 만들 수 있는 범위와 계속 맡을 범위를 함께 정하세요

직접 구축·구매·혼합 중 언제나 맞는 답은 없습니다. 고유 업무와 지속 운영 역량, 제공 기능의 적합성, 연결부 부담을 함께 보고 선택하세요.

다만 결론을 “만들 수 있다”나 “구매하면 해결된다”에서 끝내지는 마세요. 공식 기록이 어디에 남는지, 변경과 장애를 누가 맡는지, 그 구성을 그만둘 때 업무를 이어갈 수 있는지를 함께 확인해야 합니다.

다음 CRM 검토에서는 제품명보다 먼저, 대상 업무 하나와 맡길 범위를 적어보세요. 그 메모가 있으면 데모에서 물어볼 질문도, 직접 구현할 범위도 구체적으로 정할 수 있습니다.

트래킷을 검토하신다면 같은 메모를 기준으로 필요한 데이터 구조·권한·외부 시스템 연결의 현재 지원 범위와 도입 조건을 확인해보세요. 이 글의 가상 설계가 트래킷에서 그대로 제공된다는 뜻은 아닙니다.

트래킷 알아보기 →

Sources

[1] https://docs.github.com/en/copilot/tutorials/review-ai-generated-code — Review AI-generated code — GitHub Docs [2] https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility — Shared responsibility in the cloud — Microsoft Azure