[개발 실무] 객체지향은 왜 등장했는가 - 객체지향 프로그래밍은 단순한 '코드 정리' 기술이 아니다!

프로그래밍을 처음 배우는 많은 입문자가 객체지향 프로그래밍(OOP)에 대해 흔히 하는 오해가 있습니다. 바로 객체지향을 단순히 "관련된 변수와 함수를 보기 좋게 묶어두는 코드 정리 기술" 정도로 생각하는 것입니다.

물론 코드를 깔끔하게 유지하는 것도 맞지만, 객체지향이 등장한 근본적인 이유는 훨씬 더 깊은 곳에 있습니다. 비유하자면, 객체지향은 단순히 책상의 '서류를 정리하는 기술'이 아니라, 거대한 회사의 '조직 구조를 설계'하는 방식에 가깝습니다.

그렇다면 왜 기존의 프로그래밍 방식으로는 한계에 부딪혔으며, 객체지향은 복잡한 소프트웨어의 구원투수로 등장하게 된 것일까요?

 

--------------------------------------------------------------------------------

1. 과거의 방식: 데이터와 행동이 분리된 끔찍한 혼돈

초기의 프로그램들은 대부분 '기능(함수) 중심'의 구조를 가졌습니다. 이 방식의 가장 큰 특징이자 치명적인 단점은 바로 '데이터'와 '행동(함수)'이 철저히 분리되어 있었다는 점입니다.

하나의 데이터를 두고 시스템 곳곳에 흩어진 여러 함수가 동시다발적으로 접근하여 데이터를 수정했습니다. 작은 프로그램에서는 문제가 없었지만, 코드가 수백 줄에서 수십만 줄 규모로 커지면서 상황은 통제 불능 상태에 빠졌습니다.

회사에 비유해 볼까요? 회사의 핵심 자산인 '계좌 정보(데이터)'가 로비 한가운데 놓여 있고, 돈을 쓰는 권한(함수)을 모든 직원이 가지고 있는 상황과 같습니다. 계좌의 잔고가 갑자기 비어버렸을 때, 도대체 어떤 직원이 언제 돈을 빼갔는지(어떤 함수가 데이터를 수정했는지) 추적하는 것은 불가능에 가깝습니다. 결과적으로 프로그램의 코드 의존성이 겉잡을 수 없이 높아졌고 버그는 폭증했으며, 작은 수정조차 두려운 일이 되어버렸습니다.

 

--------------------------------------------------------------------------------

2. 객체지향의 핵심: 데이터와 행동을 하나의 단위로 묶다

이러한 문제를 해결하기 위해 등장한 객체지향의 핵심 아이디어는 매우 명쾌합니다. 바로 "데이터와 행동(함수)을 하나의 객체 단위로 묶는 것"입니다.

계좌 잔액(balance)이라는 데이터와, 입금(deposit()) 및 출금(withdraw())이라는 행동을 하나의 '계좌 객체(Account)'로 단단히 결합합니다. 이렇게 되면 데이터를 외부에서 직접 수정하는 함수는 사라지며, 객체 스스로가 자신의 데이터를 철저히 관리하게 됩니다. 이것이 바로 객체지향의 중요한 원칙 중 하나인 캡슐화(Encapsulation)입니다.

다시 은행에 비유해 보겠습니다. 이제 외부인은 은행 시스템의 계좌 데이터를 마음대로 조작할 수 없습니다. 내부의 상태가 외부로부터 어떻게 부패하거나 변질될지 걱정할 필요 없이, 오직 잘 정의된 행동(인터페이스)을 통해서만 안전하게 상호작용하게 됩니다.

 

--------------------------------------------------------------------------------

3. 객체지향의 진짜 목적: '복잡성'의 통제

객체지향 프로그래밍은 단순히 클래스라는 껍데기를 사용하는 것이 아닙니다. 객체지향이 등장한 진짜 목적은 현대 소프트웨어의 압도적인 '복잡성을 관리(Managing Complexity)'하기 위함입니다.

거대한 코드를 하나의 덩어리로 두는 대신, 책임과 역할을 가진 여러 개의 '객체 모듈'로 분해합니다. 주문 시스템, 결제 시스템, 배송 시스템 등 마치 거대한 회사를 여러 전문 부서로 분리하여 운영하는 것과 완벽히 동일한 이치입니다. 덕분에 변경이 필요한 경우 전체 시스템을 뒤엎을 필요 없이, 해당 책임을 가진 특정 클래스(부서) 하나만 수정하면 되므로 유지보수성과 확장성이 극대화됩니다.

 

--------------------------------------------------------------------------------

4. 코드 중심에서 '구조와 설계' 중심으로

이러한 객체지향의 본질을 이해하고 나면, 개발을 바라보는 시각 자체가 완전히 달라집니다.

• 기능이 아니라 구조를 본다 : 단순히 코드가 위에서 아래로 실행되는 흐름을 짜는 것이 아니라, 어떤 객체들이 모여서 어떻게 협력할지 '설계'를 먼저 고민하게 됩니다.
• 레고 블록 같은 조립 : 거대한 코드 덩어리가 여러 개의 작은 블록으로 나뉘어, 필요할 때마다 부품을 갈아 끼우듯 유연한 유지보수가 가능해집니다.

 

--------------------------------------------------------------------------------

✍️ 마무리하며

결론적으로 객체지향 프로그래밍은 코드를 보기 좋게 정리하기 위한 단순한 도구가 아닙니다. 끝없이 비대해지는 복잡한 시스템을 인간이 통제하고 관리할 수 있도록, 데이터와 행동을 하나의 단위로 묶어내는 위대한 '설계 방식'입니다. 오늘 작성한 코드가 내일의 변화에도 매끄럽게 대응할 수 있는 '좋은 설계'를 원한다면, 기능을 구현하기 전 반드시 객체들의 역할과 책임을 먼저 고민해 보시길 바랍니다.