코드가 아닌 개념 레이어링과 폴리몰피즘

지난 글에 이어서 또 두 명의 개발자와 함께한 설계 개선이야기다. 어쩌다 보니 시리즈물이 되고 있다. 우리 팀은 새로운 도전으로 SaaS를 릴리즈 한 후, 비즈니스 속도를 맞추느라 개발 품질이 낮아지는 부담을 안고 있다. 비즈니스 속도를 늦추지 않는 선에서 틈틈이 이를 복구하는 상황이다. SW 본토인 미국(?) 표현으로 바꾸면 Technical Debt이 쌓여 있고, 너무 커지기 전에 빚을 갚는 상황이다. 이렇다 보니 일상속에서 자연스럽게 글감이 쌓이는 행복(?)한 나날이다.

두 개발자 앞에 아래 그림을 그렸다. 흔히 '재고'라 불리는 말을 둘로 나눌 필요성이 있다 주장했다. 한 조로 일하는 두 명 개발자가 내 주장을 듣고 현재 맡은 코드가 바뀔 필요성에 대해 공감하면 소통은 성공이다. 일단 우리 시스템에서 재고는 어딘가에 쌓여 있는 상품 수량을 칭하는 말로 흔히 inventory 혹은 stock이라 부르는데, 그 단어나 약자 형태로 프로그램의 클래스/변수/함수 이름 그리고 데이터베이스 테이블/컬럼/Stored Procedure 변수명으로 쓰이고 있다.

개발자사이 개념 차이 좁히기

옴니채널 비즈니스 요구를 받으면서 온라인 재고와 오프라인 재고 사이 연결이 필요했다. 우리는 흔히 재고통합이라는 부르는 전략으로 재고를 하나로 합치는 대신에 교차 판매하는 물량을 별도로 관리하기로 했다. 이렇게 하면, 물건을 판매하는 시점에서 판매원이 확인한 재고를, 기존에 재고라 부르던 개념과 구분할 필요가 생긴다. 이를 대표하는 서비스(Micro Service) 이름을 Product Availability로 부르기로 했다. 이렇게 작명한 이유는 일단 Inventory나 Stock이라는 말을 피해 혼동을 막으려 했고, '지금 물건 있어요?'라는 물음에 답하는 인터페이스 이름을 취했다.

이를 설명한 후에 두 개발자에게 질문을 던졌다. 재고와 관련이 깊은 상품과 매장을 어떻게 인지하고 있는지 파악하기 위해서다. 첫번째 질문은:

재고와 상품 중에 무엇이 먼저냐?

둘 다 상품이 먼저라고 했다. 그래서 아래와 같이 재고와 상품을 상하로 쓰고 가운데 선을 그었다. 두 개념에 대해 층을 나눈 레이어링(layering) 행위다. 여기까지는 쉽다. 두 개발자 모두 이견이 없었다.

개념을 다루는 레이어링

다음 질문이 이어졌다:

그럼 매장이 먼저냐? 상품이 먼저냐?

두 개발자 의견이 달라 소통이 유익한 방향으로 나아갔다. 한 개발자는 매장이 존재해야 상품을 넣을 수 있다고 답했고, 다른 개발자는 상품이 있어야 매장이 의미가 있다고 답했다.

매장과 상품 관계에 대한 서로 다른 해석

둘 다 일리가 있다. 차이는 선후 관계에 대한 인식이다. 첫번째 개발자는 매장이 먼저라고 했는데 팔려는 준비가 되어 있어야 상품을 보낸다는 의미다. 여기서 말하는 상품은 실제 재고 할당을 포함하고 있다. 그런데 두번째 개발자는 상품이 먼저라고 했는데, 이는 팔려는 대상이 있어야 비로소 매장을 개설한다는 의미다. 여기서 상품은 재고 여부와 무관하게 취급 대상 지정을 의미한다. 여기서 상품의 의미도 둘로 나눌 수 있게 되었지만, 대화가 초점을 잃을까봐 매장에 대한 이야기로 초점을 좁혔다. (기회가 되면 시리즈로 이어가겠다.)

매장의 유사하지만 다른 의미

매장 의미를 둘로 나눴는데, 공통적 특성과 구체적 매장 형태별로 특화된 특성으로 나눴다. 객체지향설계 기법인 다형성(Poly-morphism)이라 부르는 행위인데, UML 상속관계로 아래와 같이 나타낼 수 있다.

개념을 대상으로 다형성 적용하기

위 클래스도를 풀어보면 다음과 같다.

• '상품을 팔 수 있는 곳' 정도의 추상적인 의미만 담아서 매장 대신 Sales Spot이라고 부른다.
• 구체적인 매장 특성에 따라 필요한 숫자대로 하위 개념을 나눠본다. 4가지를 정의한다.
  • e-매장: 인터넷 쇼핑몰 형태
  • 일반 매장, 백화점 매장: PoS를 사용하여 구매하는 오프라인 매장인데, 매출 처리 방식에 따라 둘로 구분한다.
  • Weixin 매장: SNS에서 거래되는 판매를 취급

이 정도로 대략 개념 정리를 하기로 하고, 두 개발자가 소화할 시간을 갖기 위해 대화를 마무리 하면서 이런 구분을 인지하는 나와 두 개발자 차이가 어쩌면 상품과 매장이 생성되고 소멸되는 주기가 다른 점을 인지하는지 여부에 달려 있을 수 있다는 말로 대화를 마무리했다.

서로 다른 개념의 생성주기

대화 당시에는 눈치채지 못했는데, 글을 쓰며 발견한 사실이 하나 있다. 매장이 먼저라고 말한 개발자는 상품 조회나 주문 처리를 담당하고 있어, 이미 매장은 존재하는 상황만 가정하고 개발하는 역할을 맡고 있었다. 그런데, 두번째 개발자는 매장이나 상품코드와 같이 흔히 말하는 마스터 정보를 다루는 역할을 한다. 이런 경우 상품코드가 없다면 매장코드가 무의미하게 느껴질 수 있다.

p.s. 이 상황을 보면 DDD의 Bounded Context가 머리속에 퍼뜩 떠오르는데 덕질이 되거나 쓰다 말까봐 생략한다.