객체지향을 배웠지만 여전히 헷갈린다면

객체지향을 설명할 때 가장 흔하게 나오는 말이 있습니다. “이 코드는 클래스로 잘 나뉘어 있다”라는 표현입니다. 하지만 실무 개발자에게 이 말은 크게 와닿지 않습니다. 우리가 실제로 고민하는 질문은 보통 이겁니다.

“이 코드, 뭐가 바뀌면 어디를 고쳐야 하지?”

객체지향의 핵심은 클래스 분리 자체가 아니라, 관심사의 분리입니다.

이 코드에서 분리된 것은 “역할”이 아니라 “관심사”입니다

이 구현에는 두 개의 핵심 클래스가 있습니다.

• Digit
• Clock

두 클래스는 함께 동작하지만, 같은 이유로 바뀌지는 않습니다.

Digit 클래스가 바뀌는 이유

Digit은 숫자 하나를 화면에 어떻게 표현할지를 책임집니다. 따라서 이 클래스는 다음과 같은 이유로 변경될 수 있습니다.

• 숫자 모양을 바꾸고 싶을 때
• 24칸 레이아웃을 다른 구조로 바꾸고 싶을 때
• 시계 바늘이 아닌 다른 표현으로 바꾸고 싶을 때

중요한 점은,
👉 이 모든 변경이 ‘시간 개념’과는 무관하다는 것입니다.

Clock 클래스가 바뀌는 이유

반대로 Clock은 시간 자체를 다룹니다.

• 12시간제 → 24시간제로 바뀔 때
• HH:MM → HH:MM:SS → 날짜까지 확장할 때
• 갱신 주기나 타이머 정책이 바뀔 때

👉 이 변경들은 숫자를 어떻게 그리는지와는 전혀 관계가 없습니다.

Digit의 책임

Digit은 다음 일을 합니다.

• 자신의 DOM 구조를 생성합니다
• 24개의 셀을 관리합니다
• 숫자를 받아 화면 상태로 변환합니다

이 책임은 다음 코드 한 줄로 압축됩니다.

digit.setNumber(3);

이 한 줄의 의미는 분명합니다.

“숫자 3을 어떻게 그릴것인가?”

Clock은 그 방법을 알 필요가 없습니다. 알아서도 안 됩니다.

Clock의 책임

Clock은 전혀 다른 일을 합니다.

• 현재 시간을 가져옵니다
• 시간을 숫자 단위로 분해합니다
• 각 Digit에게 숫자를 전달합니다
• 이 과정을 주기적으로 반복합니다

이 클래스의 관심사는 단 하나입니다.

“시계가 언제, 어떤 값으로 갱신되는가”

숫자가 어떻게 생겼는지는 전혀 중요하지 않습니다.

관심사의 분리는 결국 모르는 게 가능해지는 구조를 만듭니다.

clock.start();

이 코드를 호출하는 입장에서는 다음을 전혀 알 필요가 없습니다.

• Digit이 24칸인지
• angles 가 어떻게 생겼는지
• DOM 구조가 어떻게 구성되어 있는지

이 상태를 이렇게 표현할 수 있습니다.

“Clock은 Digit 내부 구조에 대해 모릅니다. 그리고 그 무지는 의도된 것입니다.”

정보 은닉은 데이터를 숨기는 기술이 아니라, 관심 없는 것을 몰라도 되게 만드는 설계 전략입니다.

재사용성보다 중요한 건 교체 가능성입니다

객체지향의 장점을 말할 때 흔히 “재사용성”이 언급됩니다. 하지만 실무에서는 이렇게 느끼는 경우가 많습니다.

“재사용보다, 갈아끼울 수 있느냐가 더 중요하다.”

이 코드에서 교체 가능한 지점은 명확합니다.

• Digit → 다양한 숫자 표현으로 교체 가능
• Clock → 날짜, 타이머, 스톱워치 기능으로 확장 가능

서로의 코드를 거의 건드리지 않고도 가능합니다. 이게 핵심입니다.

관심사의 분리는 재사용을 위한 게 아니라 변경을 국소화하기 위한 전략입니다.

마무리

객체지향이 등장한 이유는 단순합니다. 프로그램의 규모가 커질수록, 의도하지 않은 부수효과(side effect)가 발생할 가능성이 급격히 높아지기 때문입니다.

상태는 여기저기 흩어지고, 하나의 변경이 예상하지 못한 영역까지 전파됩니다. 절차지향 방식이 틀려서가 아니라, 변화하는 복잡성을 감당하기 어려워진 것입니다. 객체지향은 이 문제에 대한 대응으로 등장했습니다.

• 관심사를 분리하고
• 상태와 그 상태를 변경하는 책임을 묶고
• 필요하다면 구현을 교체할 수 있도록 만든 구조 (다형성 같은 개념들)

이 모든 장치는 결국 하나의 질문에 답하기 위해 존재합니다.

“이 변경은 어디까지 영향을 미칠까?”

객체지향의 목적은 이 질문에 대해 코드를 열어보지 않고도 예측 가능하게 만드는 것입니다. 그리고 그 출발점이 바로 관심사의 분리입니다.

객체지향은 더 많은 클래스를 만드는 기법이 아닙니다. 더 추상적인 구조를 만드는 것도 목적이 아닙니다. 변경의 파급 범위를 통제하기 위한, 아주 현실적인 설계 전략입니다.