기획자가 이해하는 객체지향 설계

 

개발자와 회의를 하다 보면 "그건 객체를 나눠서 봐야 해요" 같은 말을 자주 듣습니다.

처음에는 무슨 뜻인지 몰라서 고개만 끄덕였는데, 알고 보니 기획자가 정책을 정리하는 방식과 상당히 닮아 있더라고요.

이번 글은 객체지향 설계를 코드 없이, 서비스 정책에 빗대어 정리한 메모예요.

저는 개발자가 아니라서 정확한 정의보다 "기획자가 대화에 쓸 수 있는 수준"을 목표로 적었습니다.

 

객체지향에서 말하는 객체는 쉽게 말해 서비스 안에 등장하는 "것"이에요.

쇼핑몰이라면 회원, 상품, 주문, 쿠폰, 배송 같은 명사들이 객체가 됩니다.

기획서에서 용어 정의를 만들 때 이미 명사를 고르고 있었던 셈이에요.

각 객체는 두 가지를 갖습니다.

하나는 가진 정보로, 속성이라고 불러요.

주문이라면 주문 번호, 주문 날짜, 금액 같은 것들입니다.

다른 하나는 할 수 있는 행동이에요.

주문은 "취소된다", "결제 완료로 바뀐다", "배송이 시작된다" 같은 행동을 가집니다.

정보와 행동을 한 덩어리로 묶어서 생각하는 것이 객체지향의 출발점이라고 이해했어요.

 

제가 가장 도움을 받은 개념은 책임입니다.

각 객체가 "이 규칙은 내가 책임진다"고 정해져 있어야 규칙이 흩어지지 않아요.

기획자가 자주 겪는 문제를 예로 들어 볼게요.

가정해 보겠습니다.

쿠폰 정책이 상품 상세 화면 설명, 장바구니 설명, 결제 화면 설명에 각각 따로 적혀 있다고 해요.

"최소 주문 금액 1만 원 이상일 때 사용 가능"이라는 규칙이 세 군데에 흩어져 있다면, 나중에 조건을 바꿀 때 한 곳을 빼먹기 쉽습니다.

이 규칙의 주인을 "쿠폰"이라고 정해 두면 이야기가 간단해져요.

쿠폰이 "나는 이런 조건에서만 쓸 수 있다"를 스스로 책임지고, 다른 화면은 쿠폰에게 "이 주문에 쓸 수 있어?"라고 물어보기만 하면 됩니다.

기획서에서도 규칙을 한 곳에 적고 다른 곳에서는 그것을 가리키는 방식이 훨씬 관리하기 쉬웠어요.

 

객체 사이에는 관계가 있습니다.

기획자가 ERD를 그릴 때 선으로 이어 주던 바로 그 관계예요.

가장 흔한 것은 하나가 여러 개를 가지는 관계입니다.

한 명의 회원은 여러 개의 주문을 가질 수 있고, 하나의 주문은 여러 개의 상품을 담을 수 있어요.

반대로 여러 개가 여러 개와 이어지는 경우도 있습니다.

상품과 태그가 그렇고요, 한 상품에 여러 태그가 붙고 한 태그가 여러 상품에 붙습니다.

또 하나 자주 듣는 말이 "상속"인데, 기획자 입장에서는 공통점과 차이점을 정리하는 방식으로 이해했어요.

예를 들어 쿠폰에 "정액 할인"과 "정률 할인"이 있다면, 둘 다 쿠폰이라는 공통 틀을 가지고 할인 계산 방식만 다른 것으로 보는 겁니다.

이렇게 정리하면 새로운 종류의 쿠폰이 생겨도 "쿠폰의 한 종류로 추가한다"고 말할 수 있어서 논의가 짧아져요.

 

캡슐화는 어렵게 들리지만 개념은 간단해요.

객체의 안쪽 사정은 감추고, 바깥에는 약속된 방법으로만 접근하게 하는 것입니다.

자판기를 생각해 보면 돼요.

사용자는 돈을 넣고 버튼을 누를 뿐이고, 내부에서 어떻게 음료를 꺼내는지는 신경 쓰지 않아요.

내부 방식이 바뀌어도 버튼과 동작이 그대로라면 사용자는 영향을 받지 않습니다.

기획에서는 "결제 수단이 추가돼도 주문 화면은 바뀌지 않게 하자" 같은 요구가 이와 닮았어요.

화면은 "결제해 줘"라는 약속만 알고, 어떤 수단으로 어떻게 처리하는지는 결제 쪽에서 책임지게 하는 식입니다.

 

가정해 보겠습니다.

"신규 회원이 첫 주문에서 쓸 수 있는 5천 원 쿠폰"이라는 정책을 정리한다고 해요.

객체 관점으로 나누면 이렇게 적을 수 있습니다.

• 회원: 가입일, 주문 횟수를 알고 있고, "나는 신규 회원인가"에 답한다
• 쿠폰: 금액, 사용 조건, 유효 기간을 알고 있고, "이 주문에 쓸 수 있는가"에 답한다
• 주문: 상품 목록, 금액을 알고 있고, 쿠폰을 적용했을 때 최종 금액을 계산한다

"신규 회원"의 기준이 바뀌어서 가입 후 30일 이내로 바뀐다고 해도, 고쳐야 하는 곳은 회원 쪽 한 군데입니다.

쿠폰과 주문은 "신규 회원인가"를 물어볼 뿐이라 그대로 두면 돼요.

이렇게 책임을 나눠 놓으면 정책 변경이 있을 때 영향 범위를 개발자와 같은 언어로 이야기할 수 있습니다.

한 가지 주의할 점도 있어요.

기획자가 객체를 설계해서 개발자에게 전달하는 것은 역할을 넘어서는 일이라고 생각합니다.

실제 구조는 성능, 기존 시스템, 팀의 사정에 따라 달라지니까요.

기획자가 할 일은 "이 규칙의 주인이 누구인지"를 분명히 하고 용어를 일관되게 쓰는 것입니다.

개발자가 구조를 이야기할 때 대화를 따라가고, 정책이 흩어져 있을 때 한 곳으로 모아 달라고 요청할 수 있는 정도면 충분해요.

 

객체지향은 결국 "서비스를 명사와 책임으로 나눠서 이해하는 방식"이었어요.

기획서의 용어 정의, 정책 정리, ERD가 이미 같은 사고방식 위에 있다는 것을 알고 나니 개발자와의 대화가 훨씬 편해졌습니다.

남는 질문도 있습니다.

기획서에 객체와 책임을 어느 수준까지 적어야 개발팀에게 도움이 될까요.

그리고 정책이 자주 바뀌는 서비스에서 규칙의 주인을 어떻게 안정적으로 정해 둘 수 있을까요.

개발자분들과 이야기하면서 더 다듬어 보겠습니다.