CMS·CRM·주문 관리의 차이: 백오피스 네 영역의 데이터 설계

관리자 화면 왼쪽 메뉴에 「상품 관리」, 「고객 관리」, 「주문 관리」, 「운영 정책」이 나란히 있습니다. 넷 다 누르면 목록이 뜨고, 한 줄을 누르면 수정 폼이 열리고, 저장 버튼이 있습니다. 화면만 보면 같은 물건입니다.

그런데 상품 설명을 고치고 저장한 순간 쇼핑몰 방문자에게 반쯤 쓴 문장이 그대로 보입니다. 고객 메모를 고치면 지난달 통화 내용이 사라집니다. 주문 금액을 고치면 이미 끊은 영수증과 숫자가 어긋납니다. 환불 기준을 고치면 지난주에 처리한 환불이 어느 기준을 따랐는지 아무도 모르게 됩니다. 네 사고는 원인이 같습니다. 성격이 다른 네 영역을 같은 틀로 만들었습니다.

같은 목록과 수정 폼으로 묶이는 네 영역

CMS(Content Management System)는 콘텐츠를 관리합니다. 글, 페이지, 이미지, 상품 설명처럼 외부에 보여 줄 것을 만들고 내보냅니다. CRM(Customer Relationship Management)은 고객과의 관계를 관리합니다. 누가 고객이고, 언제 무슨 대화를 했고, 지금 어느 단계인지를 쌓아 둡니다. 주문·거래 관리는 돈과 물건의 흐름을, 운영 정책과 CS는 그 흐름에서 생기는 예외와 처리 기준을 다룹니다.

흔히 이들을 "관리 대상만 다른 관리 도구"로 이해합니다. 콘텐츠를 넣으면 CMS, 고객을 넣으면 CRM이라는 식입니다. 그렇게 보면 같은 목록과 수정 폼으로 전부 만들 수 있을 것 같습니다. 위의 네 사고가 모두 이 이해에서 나옵니다.

저는 넷을 가르는 더 중요한 차이가 데이터가 시간과 맺는 관계라고 봅니다. 수정 버튼 하나가 각 영역에서 전혀 다른 일을 저지르는 이유가 여기에 있습니다.

영역	관리 대상	지켜야 할 시간	덮어쓰면 생기는 일	주로 맡는 기획
CMS	보여 줄 것 (콘텐츠, 상품 정보)	공개되기 전	쓰다 만 내용이 공개된다	서비스 기획, 마케팅 기획
CRM	관계 (고객, 영업 이력)	지나간 과거	지난 대화가 사라진다	마케팅 기획, 영업
주문·거래 (OMS, ERP)	돈과 물건의 흐름	확정된 사실	장부와 실제가 어긋난다	서비스 기획, 운영 기획
운영 정책·CS	예외와 처리 절차	규칙이 적용된 시점	과거 처리의 근거가 사라진다	운영 기획

마지막 열은 회사마다 다릅니다. 앞의 네 열은 어느 회사에서도 잘 바뀌지 않습니다.

CMS가 지키는 것은 공개되기 전의 상태

CMS에서 가장 중요한 경계는 저장과 발행 사이에 있습니다. 편집자는 초안을 여러 번 저장하고, 미리보기로 확인하고, 검토를 받은 뒤에 발행합니다. 정해 둔 시각에 자동으로 공개되게 하는 예약도 흔합니다. 저장과 발행이 한 버튼으로 붙어 있으면 이 흐름이 통째로 사라집니다.

그래서 CMS의 데이터에는 초안, 검토 중, 발행됨, 내려감 같은 상태가 있습니다. 이미 발행된 글을 고칠 때는 공개된 판을 그대로 두고 새 초안을 따로 만든 뒤, 다시 발행할 때 바꿔 끼웁니다. 과거 버전도 남기지만 주로 되돌리기용입니다. 방문자가 보는 것은 언제나 최신 발행본 하나입니다.

Contentful이나 Strapi 같은 헤드리스 CMS는 콘텐츠를 저장해 API로 내주기만 하고, 화면은 웹사이트나 앱이 따로 그립니다. 형태가 달라도 초안과 발행을 나누는 구조는 같습니다.

CRM이 지키는 것은 지나간 시간

CRM에서 가치 있는 것은 최신 상태가 아니라 쌓인 이력입니다. 석 달 전 첫 통화, 지난달 견적 발송, 어제 걸려 온 항의 전화가 순서대로 남아 있어야 다음 담당자가 이 고객을 이해할 수 있습니다.

그래서 CRM의 기록은 고치기보다 더하는 쪽으로 설계합니다. 메모 칸 하나를 매번 덮어쓰면 지난 대화가 사라지니, 접촉 한 번을 기록 한 줄로 쌓습니다. 고객의 상태(잠재, 거래 중, 휴면)도 값 하나만 두지 않고, 언제 무엇에서 무엇으로 바뀌었는지를 남겨야 "왜 이 고객이 휴면이 됐는가"에 답할 수 있습니다.

아직 거래가 없는 상대의 이력까지 담는다는 점에서 CRM은 ERP의 거래처 관리와도 다릅니다. 이 차이는 거래처 관리와 CRM을 비교한 글에서 따로 다뤘습니다.

주문·거래가 지키는 것은 확정된 사실

주문은 결제가 끝난 순간 사실이 됩니다. 고객은 그 금액을 냈고, 영수증이 나갔고, 재고가 빠졌습니다. 이 기록을 고쳐 쓰면 시스템 밖에 이미 나간 숫자와 어긋납니다.

그래서 주문·거래 영역에서는 되돌리기도 수정이 아니라 새 기록입니다. 취소는 원래 주문을 지우지 않고 취소 기록을 더하고, 부분 환불은 환불 거래를 따로 만듭니다. 회계에서 틀린 전표를 지우지 않고 반대 방향의 전표를 한 장 더 끊는 것과 같은 원리입니다. 원래 기록과 정정 기록이 나란히 있어야 합계가 맞고, 무엇이 왜 바뀌었는지 추적할 수 있습니다.

주문은 CMS와도 경계를 긋습니다. 주문 줄에는 상품 번호만이 아니라 주문 당시의 상품명과 가격을 복사해 둡니다. CMS에서 상품 설명과 가격을 나중에 바꿔도 지난 주문은 산 그때의 모습으로 남아야 하기 때문입니다. 흔히 OMS(주문 관리 시스템)가 주문의 흐름을, ERP가 그 뒤의 회계와 재고를 맡습니다. 규모가 작으면 한 시스템이 둘을 겸합니다.

운영 정책이 지키는 것은 규칙이 적용된 시점

운영 정책은 규칙 자체를 데이터로 다룹니다. 환불 가능 기간, 배송비 기준, 쿠폰 발급 조건, 부정 이용 판단 기준 같은 것입니다. 코드에 박아 두면 바꿀 때마다 배포가 필요하니 관리 화면에서 고칠 수 있게 빼는 경우가 많습니다.

여기서 덮어쓰기가 문제를 만듭니다. 환불 가능 기간을 7일에서 14일로 바꾸는 순간, 지난주에 "7일이 지나 환불 불가"로 처리한 건의 근거가 화면에서 사라집니다. 고객이 다시 항의하면 상담원은 그때 기준이 무엇이었는지 확인할 방법이 없습니다. 그래서 정책은 값 하나가 아니라 적용 시작일을 가진 이력으로 두고, 처리 기록에는 어느 정책을 적용했는지를 함께 남깁니다.

CS 기록도 같은 영역에 있습니다. 규칙이 다루지 못한 예외를 사람이 판단했다면, 누가 무엇을 근거로 승인했는지가 남아야 합니다. 같은 예외가 반복되면 그 기록이 다음 정책 개정의 근거가 됩니다.

권한이 갈리는 방향

네 영역은 권한을 거는 축도 다릅니다. CMS는 "누가 내보낼 수 있는가"를 묻습니다. 작성자는 초안을 쓰고, 검토자는 승인하고, 발행 권한은 소수에게만 줍니다.

CRM은 "누가 볼 수 있는가"를 묻습니다. 영업 담당자가 자기 고객만 보게 제한하는 경우가 많고, 무엇보다 이름, 연락처, 대화 내용 같은 개인정보가 들어갑니다. 한국에서는 개인정보 보호법의 적용을 받으니, 누가 언제 어떤 고객 정보를 열람했는지 남기는 접근 기록까지 설계에 넣는 편이 안전합니다.

주문·거래는 "누가 되돌릴 수 있는가"를 묻습니다. 취소와 환불은 곧 돈이 나가는 일이라, 금액 한도를 두고 한도를 넘으면 상급자 승인을 받게 하는 식입니다. 운영 정책은 "누가 규칙을 바꿀 수 있는가"를 묻습니다. 정책 하나를 바꾸면 이후의 처리 전부가 달라지니, 바꾼 사람과 시점이 반드시 남아야 합니다.

네 영역이 만나는 자리

실제 제품에서는 네 영역이 한 관리자 화면에 섞여 있습니다. 쇼핑몰 관리자에는 상품 등록과 회원 관리와 주문 처리가 한 메뉴에 있고, HubSpot처럼 CRM 위에 CMS를 얹어 파는 제품도 있습니다.

그래서 경계는 메뉴가 아니라 데이터가 넘어가는 자리에서 봐야 합니다. CMS가 만든 페이지의 문의 폼에 방문자가 연락처를 남기면, 그 제출은 콘텐츠가 아니라 CRM의 새 리드가 됩니다. CMS의 상품 정보는 주문 순간 복사되어 주문의 일부가 됩니다. 완료된 주문은 CRM에 구매 이력으로 쌓이고, 주문에서 생긴 예외는 운영 정책에 따라 처리됩니다.

이렇게 이어져 있어도 저장은 나눠 두는 편이 좋다고 봅니다. 폼 제출을 콘텐츠 테이블 옆에 쌓으면 공개용 데이터와 개인정보가 같은 권한 아래 놓입니다. 주문이 상품 테이블을 직접 참조만 하면 상품을 고칠 때 지난 주문이 같이 바뀝니다.

관리 화면을 만들기 전에 던질 질문 넷

메뉴 이름만으로는 어느 영역인지 헷갈릴 때가 있습니다. 상품 정보는 CMS에 가깝지만 거래처별 단가는 CRM이나 정책에 가깝고, 공지사항은 CMS지만 고객 문의 내역은 CRM과 CS에 걸칩니다.

저는 새 관리 화면을 설계할 때 네 가지를 먼저 물어보는 편이 가장 빠르다고 봅니다. 저장하는 순간 외부에 보이는가. 그렇다면 초안과 발행을 나눠야 합니다. 고치면 과거가 사라져도 되는가. 안 된다면 덮어쓰지 말고 쌓아야 합니다. 이미 돈이나 물건이 오간 기록인가. 그렇다면 수정 대신 정정 기록을 더해야 합니다. 바꾼 값이 언제부터 적용되는가. 그 답이 필요하다면 적용 시작일을 가진 이력으로 둬야 합니다.

네 질문 중 하나라도 "예"가 나오는 데이터라면, 목록과 수정 폼 하나로는 부족하다는 신호입니다.