객체 지향 프로그래밍을 이해하는 시작점

객체 지향 프로그래밍이 아주 중요한 주제라는 건,
프로그래밍을 해본 사람이라면 누구나 알고 있을 것이다.

그러나 객체 지향을 한 번 듣고 이해한 사람은,
아마 아무도 없을 거 같다.

그만큼 낯설고 추상적이고 어려운 개념이다.

객체 지향 프로그래밍을 처음 알게 되었을 때 내 반응은,

그 다음에 한번 더 들었을 땐,

아... 뭔가 흥미롭긴 한데... 여전히 모르겠다.

게다가 사람들마다 객체 지향을 설명하는 방식, 언어가
모두 다르다는 게 더 헷갈렸다.

객체 지향이란 굉장히 큰 코끼리다.
오랜 세월 동안 소프트웨어 공학에서 축적되고 진화해온 방법론이다.
언어별로 구현하는 방법도 다르고, 사람마다 중요하게 생각하는 부분도 다르다.

그만큼 한번에 모든 걸 소화하기 쉽지 않기 때문에,
각자 자기 관점과 지식을 시작점으로 삼아
객체 지향이라는 주제를 이해하다보니 그런 거 같다.

???: 음... 객체 지향은 부채 같은 거야.

객체 지향을 이해하는 시작점

우리에게도 스타팅 포인트가 필요하다.
우리에게도 객체 지향을 이해하는 좋은 시작점이 필요하다.

객체 지향이라는 커다란 주제에,
아무런 기준 없이 뛰어들었다가는...

클래스, 상속, 다형성. SOLID 원칙, 추상화. 타입...

같은 추상적인 개념에게
정신적 난타를 당한 뒤에

'객체 지향을 공부했지만 설명하긴 어려운'
어정쩡한 상태가 되고 말 것이다.

왜 아냐면 내가 바로 그런 상태였기 때문이다.

객체 지향에 관해서 알고 싶어서 많은 자료와 책을 봤고,
여러가지 비유도 봤고, SOLID 원칙이 무엇인지도 알았다.

여전히 머릿속에 OOP가 명확하게 조립되지 않는 느낌이랄까.
설명을 해보라고 하면 말이 잘 나오지 않았다.

그러다가 어느 시점에,
객체 지향이란 게 '아, 이런 거구나' 하고 끼워맞춰지는 느낌을 받았다.

그때 내가 던진 질문은

"객체란 무엇인가? 클래스란 무엇인가? 타입이란 무엇인가?"

같은 What 질문이 아니었다.

내가 객체 지향을 이해하게 만들어준 스타팅 포인트는

"왜 객체 지향을 써야 하는가?"

Why 질문이었다.

객체 지향은 '좋은 코드'를 짜기 위한 방법이다.

'좋은 코드를 쓰는 것'

소프트웨어 개발자의 가장 중요한 책임 중 하나다.

그런데 '좋은 코드'란 무엇일까?

이 질문에 대해선 내가 찾아본 모든 전문가들의 의견이 공통적이었다.
딱 2가지로 요약할 수 있다.

1. 변경하기 쉽고,
2. 이해하기 쉬운 코드.

좋은 코드는 쉽게 기능을 추가하거나 수정할 수 있고,
다른 개발자나 미래의 내가 봐도 쉽게 이해하고 버그를 찾아낼 수 있는 코드다.

좋은 코드를 쓰는 것은 쉽지 않다.

하지만 좋은 코드를 쓰는 것은
프로그램이 아주 조금만 복잡해져도 상당히 어려워진다.

공을 찾아 골대에 넣는 축구 로봇을 생각해보자.
우리는 이 로봇을 조종하는 프로그램을 코딩하고 있다.

단순하게 생각해봐도 굉장히 많은 것들을 지시해야 한다.

• 라이다로 주변 사물을 파악해라.
• 주변 사물의 정보를 저장해라.
• 주변 사물의 정보 중에서 공 모양을 찾아라.
• 자신의 위치를 구하라.
• 공과 자신 사이의 거리를 구하라.
• 공을 향해 방향을 틀어라.
• 주변 사물의 정보를 다시 불러와서 장애물이 없는지 확인하라.
• 공과 자신 사이의 거리가 멀면 전진 속도를 높여서 설정하라.

....

지금은 예시를 위해 생각나는대로 썼다.
아마 실제로는 이것보다도 훨씬 더 세세한 지시들을 해야할 거다.

이렇게 컴퓨터에게 명령을 내리는 코드를 주우욱 써내려간다.
아무런 구조도, 체계도 없이.

어느샌가 우리의 프로그램은 걷잡을 수 없이 복잡해지고, 이해하기 어려워질 것이다.

물론 실제로 컴파일을 거쳐서 컴퓨터에게 명령을 내리는 01010101 들은
저런 식으로 죽 나열되어있겠지만,

사람이 쓰고 읽어야 하는 프로그래밍 언어에서
아무런 구조화 없이 저렇게 나열할 수는 없다.

마치 컴퓨터 바탕화면에 아무런 폴더 없이
모든 파일이 쌓여가고 넘쳐나는 느낌이랄까?

좋은 코드를 쓰려면 나누고 묶어야 한다.

이런 바탕화면이 되지 않으려면,
파일을 일정한 기준을 세워서 나누고 묶어서 정리해줘야 한다.

마찬가지로, 이해하기 쉽고 변경하기 쉬운, '좋은 코드'를 만들려면
복잡한 프로그램을 작은 단위로 나누고 묶어서 정리해야 한다.

이걸 구조화, 추상화라고 부른다!

무엇을 기준으로 어떻게 묶어주느냐, 그게 추상화고 구조화다.

내 정의가 지나치게 단순할 수도 있다. 하지만 그게 목적이다.
'이해하기 쉬운', '좋은 글'을 쓰려면, 복잡한 개념을 단순화해야하기 때문이다.

객체 지향은 코드를 정리하는 방법 중 하나다.

결국 객체 지향 프로그래밍, 아니 모든 프로그래밍 방법론이란 건
'이해하기 쉽고 고치기 쉬운 코드로 만들려면, 코드를 어떻게 정리해야 하느냐'하는 문제다.

객체 지향 프로그래밍은

어떻게 하면 코드를
더 이해하기 쉽고, 변경하기도 쉽게
정리할 수 있을까?

라는 질문에 대한 여러 답 중 하나다.

무엇보다 가장 널리 쓰이는 방법이라
수많은 개발자들이 자신의 코드를 객체 지향 방식으로 정리하고
구조화해놓았기 때문에 우리는 당연히 알아야 한다.

이게 바로 우리가 일상 생활에서는 전혀 쓰지 않는
객체, 타입, 인스턴스...
같은 골치 아픈 용어를 배워야 하는 이유이고,

우리가 객체 지향 프로그래밍을 써야 하는 이유다.

Why OOP?에서 시작하자

굉장히 뻔한 말처럼 들릴 수 있겠지만,
사실 나에게는 왜 객체지향이야? 라는 질문이
객체 지향 프로그래밍을 이해하는 데 가장 큰 도움이 되었다.

객체란 무엇일까요?
클래스란 무엇일까요?
객체 지향의 4대 원칙은 무엇일까요? 라는 질문으로 시작하면
내가 모르는, 어려운 개념들의 세계로 빠지게 되고,
개념들 간의 흐릿한 경계선을 그으려 애를 쓰다가 진이 빠지게 된다.

객체 지향을 이해하는 좋은 시작점은 이 질문이라고 생각한다.

도대체 왜 객체 지향을 써야하나요?

거기서부터 조금씩, 조금씩 다음 질문을 이어가다보니
내 머릿속에서 객체 지향이란 거대한 지식이 '구조화'되는 느낌이 들었다.

'Why OOP?'에 대해 요약하자면,

• 우리는 좋은 코드를 써야 한다.
• 좋은 코드란 이해하기 쉽고, 변경하기 쉬운 코드다.
• 좋은 코드로 만들려면 일정한 기준을 가지고 코드를 구조화하고 정리해야 한다.
• 객체 지향은 코드를 구조화하고 정리하는 방법 중 널리 쓰이는 효과적인 방법이다.

자, 그렇다면... 자연스러운 다음 질문은 이거다.

그러면 객체 지향은 어떻게 코드를 정리한다는 말이야?

개인적으로 이걸 이해하는데 가장 도움이 된건
바로 '앨런 케이'의 말이었다.

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”

-Alan Kay

다음 글에서는 '객체 지향의 선구자'이자 레전드 컴퓨터 공학자
앨런 케이가 말하는 객체 지향에 대해 알아보도록 하자.

관련 글

👉 창시자 앨런 케이가 말하는, 객체 지향 프로그래밍의 본질