여러 단계 진행한 일을 되돌리기

취소 그리고 데이터베이스(DB) 

개인적인 일로 인해 2~3주에 한편씩 쓰자가 한달을 넘겼다. 자기 반성을 하며 시작하겠다.

---

오늘의 주제. -취소-

이번 글의 주제는 취소를 기획할 때 고민 할 점이다. 먼저 취소란 진행한 일을 초기 상태로 되돌리는 것을 칭한다. 예를 들면 윈도우즈에 프로그램을 설치할때, '다음'(or 'next') 버튼을 누르며 진행하다, '취소' (or 'cancel') 버튼울 눌러, 설치를 하지 않던 상태로 되돌리는 것이다.

왜 취소하나?

취소라는 행동을 하는 이유를 알아보자. 사용자는 소프트웨어를 사용하여 많은 행동을 한다. 일을 하기도 하며, 온라인에서 물건을 구매하기도 하고, 지금 내가 하는 행동처럼 글을 작성하기도 한다. 일, 구매, 글 작성의 공통적인 특징은 행동이라는 것이며, 순서가 있다. 물론 정해져 있지 않은 일은 순서를 정해서 누가 하든 같은 순서로 수행하여 일을 하는 것에 어그러짐이 없게 만든다. 이를 프로세스, 또는 절차라고 부른다. 네이버 국어사전에서는 '프로세스'를 일이 처리되는 경로 나 공정. ‘경과’(經過), ‘과정(過程)’, ‘절차(節次)’로 칭한다.

어떤 행동을 하든 자신만의, 학교의, 회사의 절차가 있다. 이 절차를 따르면, 자의든, 타의든 절차를 잘못 수행한다. 그리고 그 행동을 되돌린다. 사용자는 취소 버튼을 눌러 언제 그랬냐는 듯이 자신이 원하는 상태로 되돌아가기를 바란다. 앞의 예시에서 사용자가 취소로 원하는 바는 프로그램 설치 전 상태이다. 제품 구매 후, 사용자가 취소로 원하는 목표는 제품을 배송 받지 않으며, 제품 값으로 지불한 금액을 환불 받는 상태이다.

취소 신청 <출처 : G마켓 고객 센터 - 저작권은 G마켓에게 있습니다.>

사용자가 바라는 취소는?

사용자가 바라는 취소는 자기가 한 일을 되돌리는 것이다. 단순한 일은 바로 이전 상태로 돌리는 것만으로도 취소를 완성한다. 앱 설치 취소를 예를 들면 사용자는 아이폰에서 앱의 설치를 취소하고 싶을때 설치 중인 앱을 꾹 눌러 x를 터치 후 나오는 팝업메시지에서 삭제를 선택하는 것으로 설치를 취소 할수 있다.

앱 설치 취소 (단순 취소), 출처 : iOS

하지만 복잡한 일이라면 조금 다르다. 복잡한 업무 프로세스에서는 사용자는 다양한 취소를 원한다. 하단에 보이는 프로세스는 창고 관리 시스템 (WMS - warehouse management system)에서 출고(outbound) 프로세스를 보여준다. 간단하게 설명하면 주문을 받으면(issue orders) 배송 요청(output order)을 한다. 그리고 물건이 적재된 곳에서 꺼내 상차하는 곳으로 이동한다(picking). 제품을 실어(load) 제품이 창고를 떠날때 시스템 상으로 asn을 만들어, 제품이 창고를 떠났다는 것을 표현한다. WMS 시스템 마다 출고 프로세스가 약간 다를수 있고, 보관하는 제품 종류(전자기기, 채소류)에 따라 다르다. 하지만 대략 이런 방식으로 창고를 관리한다. 

WMS-outbound 프로세스, 출처 : Microsoft Dynamics AX 2009

여기서 취소는 어떤식으로 일어날까? 가장 쉽게 생각할 수 있는것은 제품을 요청한 회사가 주문을 취소할 수 있다. 제품 취소가 어느 단계에 일어나느냐에 따라 해야하는 일이 다르다. 제품을 꺼내고 있는 단계이면, 제품을 되돌리라고 담당자에게 연락하고, 시스템 상으로 제품 전 상태로 되돌린다. 제품을 트럭에 실고 있는 단계에서 취소가 일어나면, 앞에서 언급한 취소절차에다가 실었던 제품을 내리는 작업을 해줘야한다.

이처럼 일을 하기 위한 목적의 시스템(B2B 시스템)의 취소는 앱 취소와 같은 단순한 절차가 아닌 매우 복잡한 절차로 진행한다. 복잡한 업무 프로세스에서 취소를 구분하면 크게 3가지로 볼수 있다.

 - 바로 직전으로 취소

 - 완전 초기로 취소

 - 사용자가 임의로 지정한 상태로 취소

3가지 취소를 예를 들어 설명하겠다. 앞선 창고 관리 시스템 예시 같은 B2B에 익숙하지 않은 사람들을 위해 익숙한 온라인 쇼핑몰에서 구매 과정을 사용하겠다. 첫 글과 같은 회사를 예로 들면 이상하니, 이번에는 G마켓으로 생각해보겠다. 우리가 G마켓에서 물건을 구매하면 다음과 같은 프로세스로 배송한다.

G마켓 구매 프로세스, 출처 : G마켓 FAQ

각 단계마다 수행하는 업무가 명확히 일치하지 않겠지만, 글의 진행을 위해 어림짐작하겠다.

입금 대기 : G마켓에서 구매자가 제품 구매를 위해 주문 한 상태이다. 지불 수단을 무통장 입금 같은, 주문과 동시에 금액 지불하지 않는 방법을 선택하여, 구매자의 입금을 기다리는 상태이다

결제 대기 : 구매자가 판매자에게 대금을 지불하였으나, 판매자가 입금 내역을 확인하지 않은 상태이다.

결제 완료 : 주문 건에 대한 지불 금액을 판매자가 확인한 단계이다. 카드 결제 시 주문과 동시에 결제 완료 상태 단계로 이동할 것이며, 무통장 입금 시 구매자가 G마켓 대표 통장으로 제품 가격이 완납하고 판매자가 이를 확인한 상태이다.

배송준비중 : G마켓에서 판매자에게 제품 배송을 하라는 요청을 하며, 판매자는 물건을 준비하는 상태이다.

배송 시작 : 판매자가 제품을 구매자에게 배송하기 위해 택배사에 제품을 인계한 단계이다.

배송중 : 택배사가 물건을 구매자에게 배달중인 단계 이다.

배송완료 : 구매자가 제품을 수령한 단계이다.

바로 직전으로 취소

 - 판매자 입장에서 생각해보자. 배송시작 단계에서 고객이 배송 받을 주소를 수정해 달라는 요청을 받을 수 있다. 이때 G마켓 판매자 시스템이 배송 주소 변경은 배송 준비중 단계에서 가능하도록 만들었다고 가정하면. 이런 경우 판매자는 배송 시작 단계를 배송준비중으로 변경해야한다. 이럴때 판매자는 직전 상태로 변경하여.(상태를 "배송준비중"으로 바꾸고 확인을 누르거나, "이전 상태" 버튼을 누른다.) 업무를 처리한다

완전 초기로 취소

 - 제품을 구매한 사람이 결제를 완료하면 결제 완료 상태 이다. 주문취소를 하면 구매자는 제품을 구매하지 않은 것처럼(구매 이력은 남아있기때문에 이렇게 표현했음) 변한다. 

사용자가 임의로 지정한 상태로 취소

 - 판매자가 막 배송시작으로 변경을 하고, 제품을 택배사에게 넘기기 전에, 구매자에게 결제 방법을 현금에서 카드로 변경하고 싶다는 연락을 받았다고 가정하자. 이 때 판매자는 입금 대기 상태로 제품의 구매 과정을 바꿔야 한다.

단순한 업무 프로세스에서 즉 사용자가 바라는 취소는 간단하다. 바로 직전이 완전 초기이며, 사용자가 임의로 지정할 단계가 직전 단계이므로 기획 시 큰 고민 할 것이 없다.

제품 구매 같은 복잡한 프로세스에서, 주문 하나의 처리 시간이 길다보면(쇼핑몰에서 주문하고 하루 정도 보통 걸리면 배송중으로 바뀐다.), 무수히 많은 상황이 발생한다. 그에 대응하기 위해 업무 담당자는 여러 방식의 취소를 필요로 한다. 고로 기획자들은 업무 담당자들이 시스템을 쉽게 사용하도록 다양한 취소를 다 지원해주고 싶다.

제품을 구매하면 시스템에서는 무슨일이 일어나는가?

하단의 이미지는 온라인 쇼핑몰을 운영하기 위해 가져야하는 데이터베이스의 테이블 구조이다. 이런 것을 다 알필요는 없지만 알았으면 하는 부분만 설명하겠다. 

온라인 쇼핑 데이터베이스 설계 예시,  출처 : http://ssogarif.tistory.com/201

먼저 데이터베이스는 시스템이 데이터를 관리하는 프로그램이라고 생각하면 된다. 데이터베이스는 약어로 DB(디비)라고 부른다. 위 이미지에서 사각형 전체가 디비안에 존재한다. 테이블은 디비 안에서 데이터를 담는 그릇이라고 생각하면 된다. 위 이미지에서 사각형 하나하나가 테이블이며, 회원 테이블에는 여러 정보가 담겨있다. 쇼핑몰에서 회원 가입을 하면 회원 테이블에 정보가 하나 들어간다. 홍길동이라는 이름으로 가입하면 회원 테이블(가장 좌측에 있는 검정 사각형)에 홍길동이라는 정보가 하나 들어간다.

회원 테이블, 출처 : http://ssogarif.tistory.com/201

홍길동이 회원가입을 하면 사용자 ID도 넣고, 패스워드도 넣고, 우편번호도 넣고, 주소 등등도 넣는다. 이런 정보들이 홍길동이라는 이름으로 회원 테이블에 정보를 한세트로 구성하여 들어간다. 주문도 마찬가지이다. 주문을 하나하면 주문 테이블(회원 테이블의 오른쪽 사각형)에 주문 하나가 들어간다. 주문하나에는 여러 정보를 한세트로 구성한다. 사용자 ID, 배송번호, 주문번호 주문일자, 배송지 주소, 배송지 전화번호, 배송방법코드, 결제방법, 기타사항이다. 

G마켓으로 설명한 구매과정에서 시스템이 무슨 데이터를 관리하는지 생각해보자. 사용자가 주문을 하면 회원 가입 여부에 따라 관리하는 방법이 다르다. 간단한 설명을 위해서 회원 가입을 한 홍길동이 에어컨필터를 구매했다 가정하겠다. 앞에서 보여준 단계는 G마켓 입장에서 제품을 판매하기 위한 절차로 만든 단계이며, 우리가 간단하게 생각할 수 있는 단계는 다음과 같다.

1. 홍길동이 에어컨필터를 무통장 입금으로 주문한다.

2. 판매자는 주문을 확인하고, 에어컨 필터의 재고를 확인하여 에어컨 필터를 포장한다.

3. CJ택배에 연락을 한다.

4. 판매자는 에어컨 필터을 배송한다.

4 단계를 기본으로 하여 구매할때 시스템이 어떻게 데이터를 처리하는지 알아보자

1. 홍길동이 에어컨필터를 주문한다.

홍길동이 에어컨 필터를 주문하면 "주문" 테이블에 주문 정보 한 세트가 들어간다. 

한 세트의 정보가 들어갈때 주문한 홍길동정보도 함께 들어간다.

2. 판매자는 에어컨 필터의 재고를 확인하여, 에어컨 필터를 포장한다.

홍길동의 주문을 판매자는 확인하고, "제품"테이블에서 에어컨 필터의 제품 수량을 하나 줄인다.

3. CJ택배에 연락을 한다.

판매자는 에어컨 필터를 배송할 업체를 CJ로 선택한다. "배송"테이블에 새로운 배송 정보가 등록된다.

4. 판매자는 에어컨 필터을 배송한다.

판매자가 CJ택배에 에어컨 필터를 인계하면, "배송"테이블의 배송 일자 정보가 인계한 날로 바뀐다.

구매프로세스에서 하나의 단계를 거칠때마다 시스템은 테이블에정보를 추가하고 수정(업데이트)한다. 이런 정보를 기반으로 사용자는 현재 주문의 처리상태를 확인한다.

취소가 왜 어려워?

결론부터 말하면 개발측면에서 취소는 구현이 어렵다고 생각한다. 시스템에서 취소할때 해야하는 데이터 처리가 어렵다. 데이터를 처리하는 과정에서 하나의 실수라도 발생하면 취소에서 사용자가 기대하는 원상복귀는 어렵다. 또한 구매 프로세스는 각 단계마다 어느 정도 시간을 소요한다. 사용자가 주문 후 판매자가 확인하거나, 주문을 배송하기 제품을 포장하는 등 단계마다 물리적인 시간 간격이 있다. 하지만 취소를 누르면 데이터가 한순간에 변한다. 시스템이 한번에 데이터를 바꾸는 것은 항상 문제가 있다. 크게 2가지 이다.

하나는 데이터를 처리하다가 데이터베이스가 크래쉬가 나는 경우이며, 다른 하나는 데이터 처리에서 교착상태가 발생하는 경우이다. 

먼저 데이터베이스가 크래쉬 나는 경우이다. 데이터베이스 크래쉬는 말 그대로 데이터베이스가 죽는 것이다. 데이터베이스는 프로그램이다. 모바일 앱이 알수 없는 오류로 죽듯이 데이터베이스도 죽는다. 앞서 보여준 구매 프로세스의 데이터 처리 과정을 보면, 추가했던 내용, 수정했던 내용을 지우고,  재 수정하는 도중에 프로그램이 죽으면 삭제해야하는 데이터가 삭제가 안되거나, 바꿔야하는 데이터를 못바꾸는 상태, 또는 두개 테이블을 함께 변경해야하는데, 하나는 바뀌고 하나는 안바뀌어 데이터가 꼬여버리는 상황이 발생한다. 구매 프로세스에서 각 단계마다 테이블 3개씩 정보를 추가하거나, 수정을 한다면, 5단계를 취소하는 경우에는 한번에 15개 테이블을 바꿔야하는 상황이 생긴다. 그렇기에 데이터를 한번에 바꾸는 취소는 처리하는 데이터 양도 많고, 순서또한 프로세스 역순으로 데이터를 바꿔야 원래 데이터를 확인할 수 있다. 하지만 취소에서 15개 테이블을 바꾸던 중 7번째 테이블을 수정하다 크래쉬가 나면, 해당 데이터는 논리적으로 의미가 없어진다. 즉 주문정보가 데이터는 있지만 주문 데이터로 의미가 없어진다.

다른 하나는 데이터처리에서 교착상태가 발생하는 경우이다. 데이터베이스는 여러 사람들이 사용하는 프로그램이다. 데이터베이스는 사용자 한명이 데이터를 처리할때 다른 사용자들은 같은 데이터에 접근하지 못한다. 그래야 데이터 무결성이라는 데이터베이스 존재 원칙을 지킬수 있다. 이런 원칙으로 인해 발생하는 문제점이 교착상태이다. 다른 사용자가 잠근 자원이 해제되기를 기다리면서 자신이 잠근 자원을 해제하지 않는 상태로 영원히 다음 처리를 할 수 없는 무한 대기 상태를 교착 상태라 한다.(출처 : 데이터 전문가 지식포털). 사용자 한명이 데이터에 접근하기 위해 다른 사용자가 사용하지 못하게 하는 것을 Lock이라고 한다. 다른 사용자가 데이터를 기다리는 것을 wait for이다. 사용자가 사용하는 데이터는 자원이다. 

교착상태, 출처 : http://www.dbguide.net

교착상태가 어떻게 발생할까? 구매 프로세스에서 구매자가 주문을 취소하고 있을때 판매자가 배송 정보 수정하는 경우를 생각해보자. 구매자가 취소 할때 수정하는 정보는 주문 테이블, 배송 테이블이다. 판매자가 배송정보를 수정할때 입력하는 정보는 배송 테이블, 주문 테이블이다. 구매자는 주문 취소를 누르면 주문 테이블에서 주문 내역을 삭제하며 시스템은 동시에 배송 정보를 수정한다. 판매자는 배송 정보 수정을 누르면 배송 테이블에서 배송 정보를 수정하며, 시스템은 동시에 주문 정보를 수정한다. 아래 그림과 같은 상황이다.

구매자, 판매자가 주문, 배송 테이블을 같이 접근할때 문제가 생긴다.

이런 상황이 되면 구매자는 배송 테이블을 판매자가 풀어줄때까지, 판매자는 주문 테이블을 구매자가 풀어줄때까지 기다린다. 결국 서로 각자의 테이블을 손에 쥐고 상대가 놓아줄때까지 기다리는 것이다. 한 쌍의 구매자와 판매자라면 극히 드문 케이스라 생각이 들지만 엄청 많은 다수의 구매자와 엄청 많은 다수의 판매자가 함께 데이터베이스를 사용한다면 테이블 lock이 매우 빈번하게 발생하여 모두가 데이터베이스를 사용하지 못한다.

그럼 취소 기획은 어떻게?

직전 단계로만 이동하는 취소는 비효율적이다. 취소한번 하려면 업무 프로세스가 갖는 단계 만큼해야한다. 일괄 취소는 사용자에게는 매우 좋다. 하지만 개발시 데이터 관리에 많은 어려움이 있다. 따라서  의미 있는 덩어리로 모듈화하여 취소할 수 있게 해야한다. 취소시 데이터베이스에 부담가지 않는 범위의 정의가 필요하다. 결국 해야할 일은 DB 아키텍쳐, 개발자와 취소의 적정 수준을 찾는 커뮤니케이션이다. 그래도 이 글을 읽으시는 분들은 무작정 일괄 취소를 주장하지는 않을수 있을것 같다.