객체지향 설계의 진짜 매력은 무엇일까? 유연성과 재사용성을 중심으로 알아보기

객체지향 프로그래밍의 이야기: 어떻게 시작되었고 왜 중요한가

솔직히 말하면, 객체라는 개념은 90년대 전에도 있었어요. 하지만 사람들이 본격적으로 관심을 갖고 진지하게 쓰기 시작한 건 그때쯤이죠. 이번 글에서는 객체지향 프로그래밍(OOP)이 어떻게 세상의 주목을 받게 되었는지, 그리고 그것이 왜 오늘날의 소프트웨어 개발에 큰 영향을 미쳤는지를 제 경험을 곁들여 가볍게 풀어볼게요.

저는 어떤 개념이 왜 생겼는지를 이해하는 걸 참 좋아해요. 그래서 OOP가 태동하던 시기의 책들을 직접 찾아 읽어봤습니다. 마치 시간여행하는 기분이었죠. 그중에서도 베르트랑 메이어가 1988년에 쓴 『Object-Oriented Software Construction』이라는 책이 참 흥미로웠어요. 글을 읽는 내내, 왜 그가 새로운 방식이 필요하다고 느꼈는지 자연스럽게 공감하게 되더라고요.

 

90년대, 프로그래밍의 큰 전환점

 

90년대, 프로그래밍의 큰 전환점

• 객체지향은 구조적 프로그래밍의 연장선에서 자연스럽게 등장한 개념입니다.
• 구조적 방식은 초기 개발에는 유리하지만, 변화에 취약하다는 단점이 있습니다.
• 메이어는 구조적 설계 방식이 확장성과 유지보수 측면에서 한계를 가진다고 지적했습니다.

 

그때까지만 해도 대부분의 개발은 구조적 프로그래밍이라는 걸 사용했어요. 흐름을 딱딱 정해놓고 위에서 아래로 쭉쭉 내려가는 방식이었죠. 간단한 시스템에는 괜찮았는데, 뭐 하나만 바꾸려 해도 전체가 흔들리는 느낌이 들었어요. 저도 예전에 그렇게 코딩했었는데, 작은 기능 하나 바꾸려고 수십 줄을 들여다봐야 했던 기억이 아직도 생생하네요.

메이어도 비슷한 문제의식을 느꼈던 것 같아요. 처음엔 쉽지만, 나중엔 고치기가 정말 힘들다는 거죠. 그래서 새로운 방식이 필요했던 거예요.

 

 

과거 회고: 구조적 프로그래밍의 한계

• DeMarco와 Yourdon의 방식은 데이터 흐름 중심의 설계를 강조했습니다.
• 초기에 작업 순서를 고정함으로써 변화에 유연하게 대응하기 어려운 구조를 낳았습니다.
• 메이어는 이런 설계가 프로그램의 흐름을 지나치게 빨리 결정짓는 문제를 야기한다고 봤습니다.

 

그 시절 유명한 설계 방법 중 하나가 바로 DeMarco랑 Yourdon 방식이었는데요, 데이터가 어떻게 흐를지를 중심으로 시스템을 짰어요. 근데 이게 좀 문제였던 게, 모든 흐름을 너무 일찍 정해버리니까 나중에 방향을 바꾸기가 진짜 힘들었어요.

저도 예전에 그런 구조의 시스템을 맡았던 적이 있는데, 뭘 고치려고 하면 앞뒤 연결된 부분까지 다 건드려야 했거든요. 손대기가 무서웠죠. 메이어는 이런 문제를 정확히 짚어냈어요. "왜 이렇게 흐름을 미리 박아버리냐"는 거죠.

 

 

객체지향의 사고방식: 유연하고 모듈화된 구조

• 객체지향은 필요한 작업을 목록처럼 모아두고, 필요한 시점에 선택해 사용하는 유연한 구조입니다.
• 데이터와 관련 기능을 하나의 객체에 묶어 구성함으로써 흐름에 얽매이지 않는 설계를 가능하게 합니다.

 

OOP는 그런 고정된 흐름에서 벗어나자는 생각에서 출발했어요. 메이어는 이걸 '쇼핑리스트 방식'이라고 불렀는데, 듣자마자 무릎을 탁 쳤죠. 마치 마트 가서 장을 볼 때처럼, 필요한 걸 그때그때 선택해서 넣는 느낌이랄까요?

OOP에서는 데이터랑 그 데이터를 다루는 기능을 묶어서 하나의 객체로 만들어요. 그래서 미리 "이건 이렇게 흘러가야 해"라고 정하지 않아도 돼요. 상황에 따라, 필요한 기능만 뽑아 쓰면 되니까 훨씬 자유롭죠.

 

 

기본 개념 이해하기: 클래스와 객체란?

• 객체는 실행 중 메모리에 존재하며 실제로 동작하는 실체입니다.
• 클래스는 그러한 객체를 만들기 위한 설계도이며, 프로그램 실행 시 직접 사용되진 않습니다.
• 정적 언어와 동적 언어의 차이는 이 개념에서 기인하며, 객체는 클래스를 기반으로 실시간 생성됩니다.

 

클래스랑 객체, 처음에는 저도 헷갈렸어요. 수업 시간에 교수님이 설명해줘도 뭔가 딱 안 잡히는 느낌이었죠.

근데 메이어의 정의를 보고 좀 감이 왔어요. 클래스는 말 그대로 설계도고, 객체는 그 설계도로 만든 실제 제품 같은 거예요. 프로그램이 실행될 때 진짜 돌아다니는 건 객체고, 클래스는 뒤에서 조용히 설계를 담당하고 있는 셈이죠.

정적 언어에서는 타입을 코드에서 딱 정해야 하는데, 동적 언어는 실행 중에 알아서 판단해요. 예를 들어 Person이라는 클래스를 만들고 john이라는 객체를 만들면, 이 john이 바로 프로그램 속에서 움직이는 실체인 거예요.

 

객체가 변화에 강한 이유

 

객체가 변화에 강한 이유

• 소프트웨어는 변화가 잦은 영역이며, 이를 잘 수용하는 구조가 중요합니다.
• 객체지향은 기능을 독립된 단위로 분리해 수정이 전체에 영향을 주지 않게 합니다.
• 구조적 설계보다 유지보수성과 확장성이 뛰어납니다.

 

요즘처럼 기능이 수시로 바뀌는 시대에, 유연한 구조는 정말 필수죠. 저도 한 번은 고객 요청 때문에 특정 기능을 뜯어고쳐야 했는데, 객체지향 덕분에 필요한 부분만 손보고 마무리할 수 있었어요. 예전 방식이었다면 진짜 밤샘이었을 겁니다.

메이어도 이걸 강조해요. 구조적 설계는 처음엔 빠르지만, 나중엔 고치기 힘들다. 반면 OOP는 독립된 단위로 구성돼 있어서 고치기도 편하고, 다른 부분에 영향도 적어요.

 

 

OOP를 쉽게 이해할 수 있는 예시들

예를 들면, 웹사이트에서 사용자 정보를 다루는 User 객체가 있다고 해볼게요. 이 객체에는 이메일, 생년월일, 알림 여부 같은 정보가 담겨 있고, 알림을 보내거나 정보를 수정하는 기능도 같이 들어 있어요.

또 Stack 객체를 생각해볼까요? 데이터를 쌓고 빼는 기능이 있죠. push, pop, peek 같은 동작은 모두 이 객체 안에서 데이터랑 직접 연결되어 있어요.

Python 리스트를 쓸 때도 마찬가지예요. append나 remove, reverse 같은 메서드를 객체처럼 쓰는 거잖아요. 생각해보면 우리도 이미 일상에서 OOP를 쓰고 있었던 거예요.

 

 

클래스, 이렇게 쓰면 곤란해요

• 초보자들은 종종 클래스를 단순 기능 수행 용도로만 사용하는 실수를 범합니다.
• 클래스는 하나의 작업을 수행하는 게 아니라, 다양한 기능을 제공하는 모듈이어야 합니다.
• 잘 설계된 클래스는 실제 세계나 시스템 구성 요소를 모델링하며 재사용이 용이합니다.

 

저도 처음엔 클래스 하나에 메서드 딱 하나만 넣어서 썼어요. 지금 생각하면 웃기지만, 그땐 그게 맞는 줄 알았죠.

메이어는 말합니다. 클래스는 무언가 '하는 것'보다는 '여러 서비스를 제공하는 것'이어야 한다고요. 즉, 어떤 현실 세계의 대상을 잘 모델링해서 관련 기능들을 묶어야 해요.

클래스 안에 기능이 하나뿐이라면, 아마 다시 설계를 고민해보는 게 좋을지도 몰라요.

 

 

설계의 시작은 '무엇을 모델링할 것인가'

• 새로운 프로젝트를 시작할 때 가장 먼저 고려해야 할 것은 어떤 실체를 모델링할 것인가입니다.
• 재사용 가능한 객체를 설계하는 것이 장기적으로 좋은 구조를 만드는 핵심입니다.

 

새 프로젝트를 시작할 때 저는 항상 "어떤 대상을 모델링할까?"라는 질문부터 던져요. 예전엔 기능 중심으로 생각했는데, 지금은 대상 중심으로 접근하게 됐어요.

그 객체가 다른 프로젝트에서도 그대로 쓸 수 있다면, 정말 잘 만든 설계라고 할 수 있겠죠.

 

 

마무리하며: 고정된 흐름에서 유연한 구조로

• 객체지향 설계는 기능 중심이 아닌, 모듈 중심의 구조를 강조합니다.
• 객체 중심 시스템은 재사용성, 유연성, 확장성에서 뛰어난 성과를 보입니다.
• 프로그램의 본질은 무엇을 '하는가'가 아니라, 무엇으로 '이루어졌는가'에 있습니다.

 

글을 마치기 전에 메이어가 했던 말을 하나 소개할게요:

"객체지향 설계의 가장 중요한 원칙은 기능이 아닌 모듈 또는 객체 타입을 만드는 것이다."

 

이 말, 진짜 핵심이에요. OOP는 단순히 코드 짜는 기술이 아니라, 변화를 받아들이는 태도라고 생각해요.

지금은 단순히 무언가 '하는' 프로그램보다, 어떤 '구성 요소들로 이루어졌는가'가 더 중요한 시대예요. 그 중심에는 바로 객체가 있습니다.