주차 정산 사례로 설명하는 느슨한 결합과 OCP 원칙

어떻게 하면 모델링을 잘할 수 있을까?

May 22. 2025

지난 글의 내용과 제목 <객체의 작명과 속성 부여 과정이 경계를 만드는 일입니다>을 통해 객체의 이름을 짓는 과정 그리고 속성을 부여하는 행위 자체가 경계를 만드는 일이라는 점을 드러냈습니다. 다만, 왜 그러한지에 대한 설명이 부족한 듯해서 이 글을 통해 설명을 보완합니다.

객체를 나누는 이유와 결합도의 개념

지난 글에서 작성한 클래스도를 기준으로 설명을 시도합니다. 아래 그림을 작성할 때 제가 머릿속으로(암묵적으로) 적용한 규칙과 기준을 (명시적으로) 꺼내 보겠습니다.

Parking Charge는 주차료를 객체화한 것입니다. 주차한 차량(Chargeable Vehicle)을 마주하여 부과하는 관계를 표현하기 위해 두 개의 객체로 나누고 선을 그어 관계를 표현한 것이죠. 이때 해당 차량은 몇 번이고 반복해서 주차를 할 수 있으니 주차료는 하나의 차량에 대해 다수가 될 수 있습니다. 그렇기 때문에 둘은 별도의 객체로 나눠야 필요에 맞게 따로따로 프로그래밍을 할 수 있습니다. 하나로 묶어 두면 다수의 주차료 중에서 어떤 것인지 찾아 수정할 때에도 하나로 묶인 내용 전체를 다뤄야 합니다. 소프트웨어 공학에서는 이러한 관계의 결합 강도를 결합도Coupling라고 부릅니다. 적절한 수준의 결합을 관리하는 일이 설계의 관건이라고 할 수 있습니다.

느슨한 결합(loosely-coupled)이 왜 필요한가?

Parking Charge에서 Parking Fee는 구분했습니다. 한국말로는 '요금표'라고 부르기로 하겠습니다. 요금표를 따로 구분한 결정은 앞서 말한 결합도와 관련해서 생각할 수도 있습니다. 하지만, 굳이 그런 개념을 꺼내지 않고 실제 쓸모 관점에서 설명할 수 있습니다. 과금표는 앞서 주차장 이용료에 대한 규칙, 요금표, 기준(Price Table, Rate 따위)을 개념적으로 나타낸 것입니다.

Parking Charge에서 Parking Fee를 관계를 두어 떼어 놓으면 요금표에 포함된 기준이 바뀌었을 때, Parking Charge 객체는 다른 고려 없이 이미 바뀐 Parking Fee를 활용하여 주차요금 계산(calculate)을 하면 됩니다. 이런 방식의 결합 형태를 느슨한 결합(loosely-coupled)이라고 합니다.

한편, 클래스도에 실선과 점선으로 경계를 긋고 Closed와 Open 표기를 했는데요.

OCP 원칙: 수정은 객체 단위로 하고 확장은 열어 두자

이는 OCP 원칙을 설명할 의도로 쓴 것입니다. Open은 확장에 대한 허용을 뜻하고, 바깥에서 수정하지 못하게 막자고 Closed라고 이름 붙인 것입니다.

주차 정산 사례로 설명을 해 보겠습니다. 계산 방식은 바뀌지 않고 요금표가 바뀔 수 있습니다. 물가가 오르면 기준이 바뀔 수 있죠. 이때, 계산 알고리듬 자체는 수정하지 않고, 요금표의 기준만 바뀔 수 있게 하는 일도 확장의 하나로 볼 수 있습니다. 이와 같이 객체의 경계와 관계를 도메인의 실질적인 변화에 대응할 수 있도록 만들어 가는 일이 객체 지향 설계라고 할 수 있습니다. 설계는 목표와 기능이고, 객체 지향은 그 방법(How to)이라고 할 수 있습니다.