사례
다음과 같은 사양의 기능이 존재한다고 가정하자.
- 고객이 회원가입을 함.
- 고객이 10,000원짜리 상품 A를 결제함.
- A를 결제 완료한 고객 계정에 30일 이용권을 제공. 끝.
그런데 이런 기능을 운용하다 보면, 예컨대, 마케팅적 차원에서 거의 반드시라고 해도 좋을 정도로 이런 "기획"이 인입되곤 한다.
- 고객이 돈을 내지는 않고 가입만 함.
- 고객으로부터 이런저런 동의를 얻음.
- 그 고객 계정에 30일 이용권을 제공. 끝. (이하 "무료체험")
사업은 사업이므로 어쨌든 필요하다면 이런 기획도 사양으로 만들어서 구현하기는 해야 하는데, 그 구현 과정에서 이런 식으로 처리하고 싶다는 유혹에 빠질 수 있다.
- 사내전산툴에 '무료체험 제공하기' 기능 추가.
- 그 기능을 통하여 고객 계정 번호를 입력하면, 그 계정에 무조건 30일 이용권을 제공해 버림. 끝.
이러면 안 된다. 이게 도깨비방망이다.
이런 요건을 위해서는 이런 도깨비방망이를 만들면 안 되고, 이렇게 해야 한다.
- 고객이 회원가입을 함.
- 고객이 0원짜리 상품 K를 결제함.
- K를 결제 완료한 고객 계정에 30일 이용권을 제공. 끝.
이론
한국 구비문학에서 '도깨비방망이'란 돈이니 쌀이니 하는 것이 원하는 만큼 뚝딱뚝딱 튀어나오는 요술 도구이다. 그러나 냉정하게 공학적으로 고찰해 보자면, 결국 그 도깨비방망이라는 것은 돈도 쌀도 아닌 다른 뭔가를 둔갑시켜서 내놓는 장치에 불과할 것이다. 질량 보존의 법칙이라는 게 있잖은가. 정말로 돈과 쌀이 나오고 있는 것은 아닐 터이다.
컴퓨터 엔지니어링 실무에서 도깨비방망이란 말하자면 고객의 서비스 이용 권리, 게임 에코시스템 내의 유료 재화 등이 원하는 만큼 뚝딱뚝딱 나오는 요술 도구라고 할 수 있을 것이다. 더 정확히는, 필요한 절차와 비용을 투입하여 획득해야 하는 무언가를 그 절차 및 비용 없이 획득할 수 있게 처리하는 별도의 사양이라고 정의할 수 있을 것이다.
돈이나 쌀은 질량이 있는 실물이므로 도깨비방망이 제작이 원천 불가능하나, 컴퓨터 세계에서의 재화나 이용권리 등은 그렇지가 않아서 그냥 막 만들면 만들어지는 것처럼 생각될 수 있다. 말하자면 이런 쿼리 한번이면 다 되는 것 같다는 말이지. 그리고 서비스 자체가 아주아주 단세포적이라면, 그건 정말 그럴지도 모른다.
INSERT INTO COINS
(USER_ID, COIN) VALUES
(25578, 9999999999999999);하지만 설령 그런 조건들이 충족된다고 해도, 그래도 이런 도구를 만들거나 이런 걸 서비스 공식 사양으로 삼으면 안 된다. 구비문학 속 도깨비방망이가 냉정히 따지자면 그러하듯, 이런 식으로 만들어진 기능이 제공하는 것 역시 사실은 진짜 주어져야 하는 다른 것의 둔갑에 불과한 것이기 때문이다.
아주 형식적으로 0원을 받는 식의 절차를 태우는 한이 있더라도, 기존의 사양과 요건이 존재하는 서비스라면 그것의 변형조차도 그 요건의 어딘가를 함부로 건너뛰지 않도록 해야 한다. 그렇지 않으면 최종적으로는 혹 떼러 갔다가 혹 붙이고 오는 꼴이 난다. 그 건너뜀이 심하면 심할수록, 그것은 곧 기존의 정식 사양에 따라 비용과 절차를 투입하여 그걸 획득하던 이들에 대한 더 심하고 명백하며 "짜치는" 차별 대우 (비용) 로 이어지기 때문이다.
군말
이걸 내가 어떻게 아느냐면… 저도 알고 싶지 않았습니다.
