쇼핑몰을 만드는 일은 문을 여는 날 끝납니다.
쇼핑몰을 운영하는 일은 그날부터 시작됩니다.

처음 정한 운영 방식이 계속 맞는 가게는 드뭅니다.
주문이 늘면 처리 단계를 나누게 되고, 새로운 배송 업체를 쓰면 출고 절차가 달라집니다.
고객 문의가 반복되면 알림을 하나 더 보내고 싶어지고,
구매확정 시점이나 포인트를 지급하는 기준도 바뀝니다.

문제는 이런 변화가 생길 때마다 개발자를 찾아야 하는 쇼핑몰입니다.

주문 처리 단계를 하나 추가하기 위해 코드를 고쳐야 하고,
배송이 시작됐다는 알림을 보내기 위해 다시 개발을 의뢰해야 합니다.
포인트 지급 시점을 바꾸는 일에도 수정과 배포가 필요합니다.

의뢰를 받는 쪽도 반갑지 않기는 마찬가지입니다.
단계 이름 하나 바꾸는 일이 코드 수정과 배포, 배포 후 확인까지 이어지는 구조라면,
운영자와 개발자 모두 그 구조의 값을 치르고 있는 것입니다.

하나하나는 작은 일입니다.
그러나 작은 변화가 생길 때마다 견적을 받고, 일정을 잡고,
수정된 코드가 배포되기를 기다려야 한다면 운영자는 자기 가게의 규칙을 직접 정할 수 없습니다.

운영의 변화는 개발이 아니라 설정이어야 합니다

첫 글에서 오픈소스 쇼핑몰의 질문은 결국 "감당을 얼마나 줄일 수 있는가"라고 적었습니다.
그 감당의 첫 항목이 이 반복되는 개발 의뢰입니다.

그래서 저희는 쇼핑몰을 만들면서 기능을 두 종류로 나누는 것을 첫 번째 설계 원칙으로 삼았습니다.

개발자가 만들어야 하는 기능과, 운영자가 정할 수 있어야 하는 규칙입니다.

새로운 결제 수단을 연결하거나 지금까지 없던 업무를 만드는 것은 개발의 영역입니다.
반면 주문을 어떤 순서로 처리할지,
어느 단계에서 고객에게 알릴지,
언제 재고를 차감하고 포인트를 지급할지는 가게의 운영 규칙입니다.

운영 규칙까지 코드 안에 들어가면 규칙을 바꿀 때마다 개발이 필요합니다.

그래서 머블로는 이런 규칙을 가능한 한 코드 밖으로 꺼내 관리자 화면에 두었습니다.
기능을 하나 만들 때마다 같은 질문을 던졌습니다 — 이 값은 코드의 것인가, 운영자의 것인가.

주문에는 가게마다 다른 순서가 있습니다

기본적인 주문은 주문접수에서 시작해 결제완료, 배송준비, 배송중, 배송완료, 구매확정으로 이어집니다.
취소나 반품은 그 흐름에서 갈라집니다.

하지만 실제 가게가 모두 같은 순서로 움직이지는 않습니다.

주문 제작 상품을 파는 가게에는 제작중이,
출고 전에 품질을 확인하는 가게에는 검수중이,
방문 수령을 받는 가게에는 수령준비와 수령완료가 필요할 수 있습니다.

이런 단계를 하나 추가하기 위해 쇼핑몰 코드를 고쳐야 한다면,
시스템이 운영을 돕는 것이 아니라 운영이 시스템에 맞춰져야 합니다.

머블로에서는 관리자가 주문 상태의 이름과 순서를 바꾸고, 필요한 상태를 추가할 수 있습니다.
각 상태에서 다음에 어디로 이동할 수 있는지도 정합니다.
검수중에서는 배송준비로만 갈 수 있게 하고,
주문취소에서는 더 이상 다른 상태로 이동하지 못하게 하는 식입니다.

배송 정보를 어느 단계에서 입력할 수 있는지,
어떤 상태를 주문 처리의 마지막으로 볼지도 관리자에서 정합니다.

운영자는 자기 가게의 절차를 화면에 옮기고, 시스템은 그 절차를 벗어난 처리를 막습니다.

상태가 바뀌면 해야 할 일도 함께 움직여야 합니다

주문 상태를 바꾸는 것만으로 운영이 끝나지는 않습니다.

결제가 확인되면 재고를 차감해야 합니다.
배송을 시작하면 고객에게 송장번호를 알려야 합니다.
구매가 확정되면 포인트를 지급하고,
주문이 취소되면 차감했던 재고와 지급했던 포인트를 되돌려야 할 수 있습니다.

이 일을 사람이 기억해서 하나씩 처리하게 하면 언젠가는 빠뜨립니다.
주문이 적을 때는 실수로 끝나지만, 주문이 많아지면 같은 실수가 반복되는 운영 방식이 됩니다.

머블로에서는 주문이 특정 상태에 들어갔을 때 실행할 일을 함께 설정합니다.

연결해 둔 발송 수단으로 문자·알림톡·이메일 알림을 보내는 것.
재고를 차감하거나 복구하는 것.
정액 또는 주문금액의 비율로 포인트를 지급하고, 필요한 경우 환수하는 것.
외부 업무 시스템에 주문 상태를 전달하는 것까지 상태별로 연결할 수 있습니다.

예를 들어
배송중 상태에는 고객 알림과 외부 배송 시스템 연동을 붙이고,
구매확정 상태에는 포인트 지급을 붙일 수 있습니다.
주문취소 상태에는 재고 복구와 포인트 환수를 연결할 수 있습니다.

알림을 하나 더 보내거나 지급 시점을 바꾸기 위해 코드를 수정하지 않습니다.
어느 상태에서 어떤 일이 일어날지를 관리자가 바꾸면,
그다음 주문부터 바뀐 규칙으로 움직입니다.

자동화는 많이 하는 것보다 빠뜨리지 않는 것이 중요합니다

자동화라고 하면 먼저 사람의 일을 줄이는 모습을 떠올립니다.
물론 그것도 중요합니다.
그러나 작은 가게에서 자동화가 필요한 더 큰 이유는 정해진 일을 빠뜨리지 않게 하기 위해서입니다.

주문이 세 건일 때는 고객에게 알림을 보내고 포인트를 지급했는지 기억할 수 있습니다.
주문이 서른 건이 되면 기억은 운영 방식이 될 수 없습니다.
담당자가 바뀌거나 바쁜 날이 오면 같은 절차도 다르게 처리됩니다.

상태와 액션을 연결해 두면 누가 주문을 처리해도 같은 단계에서 같은 일이 실행됩니다.
운영자가 모든 주문의 후속 작업을 기억하지 않아도, 시스템이 가게의 규칙을 기억합니다.

그리고 주문 처리와 부가 작업은 서로 구분되어야 합니다.
고객 알림이나 외부 시스템 호출이 잠시 실패했다고 이미 완료된 주문 처리가 되돌아가서는 안 됩니다.
주문의 기록은 그대로 남고, 실패한 작업은 기록되어 자동으로 다시 시도됩니다.

편한 운영은 버튼의 수가 적은 화면만을 뜻하지 않습니다.
한 번 정한 규칙이 빠짐없이 실행되고, 실패가 조용히 사라지지 않고 기록되는 구조까지 포함합니다.

설정할 수 있다는 것과 무엇이든 바꿀 수 있다는 것은 다릅니다

운영자가 직접 정할 수 있어야 한다고 해서 모든 제한을 없애지는 않았습니다.

결제완료나 주문취소처럼 시스템이 주문의 의미를 판단하는 데 필요한 상태는 없앨 수 없습니다.
존재하지 않는 단계로 이동하게 만들거나,
마지막 상태에서 다시 다른 상태로 이동하게 하는 잘못된 규칙도 저장할 수 없습니다.
시작점에서 닿을 수 없는 상태나 끝나는 길이 없는 흐름은 저장할 때 경고로 알려줍니다.

설정은 자유로워야 하지만, 잘못된 설정 하나가 주문 전체를 망가뜨리게 두어서는 안 됩니다.

그래서 기본 흐름은 처음부터 준비해 두었습니다.
별다른 이유가 없다면 그대로 사용해도 됩니다.
가게에 다른 절차가 필요해졌을 때만 이름을 바꾸고 단계를 더하고,
자동으로 실행할 일을 연결하면 됩니다.

저희가 모든 일을 설정으로 해결할 수 있다고 말하려는 것은 아닙니다.
지금까지 없던 업무나 외부 서비스는 새 개발이 필요할 수 있습니다.
다만 그것이 여러 가게에서 반복해서 달라질 수 있는 운영 규칙이라면,
코어를 다시 고치는 대신 새로운 액션으로 확장할 수 있어야 합니다.

운영자가 정할 일과 개발자가 만들 일을 구분하는 것.
이 경계가 이 글에서 본 장치들을 전부 만들었습니다.

가게의 절차는 코드가 아니라 설정으로 옮길 수 있게.
무난한 기본값을 먼저 주고, 바꾸는 일은 필요해진 날로 미룰 수 있게.
자유로운 설정이 주문을 망가뜨리지 않게, 부가 작업의 실패가 확정된 주문을 흔들지 않게.

쇼핑몰의 규칙을 정하는 사람은 만든 사람이 아니라 운영하는 사람입니다.
가게의 주문처리 순서를 정하고, 고객에게 언제 무엇을 알릴지 결정하고, 일하는 방식을 바꾸는 일은 운영자의 것이어야 합니다.

운영의 규칙을 바꾸는 일이, 다시 개발 일정을 잡는 일이 되어서는 안 됩니다.