객체지향 언어와 절차지향 언어와의 차이

Java를 하면서 가장 먼저 알아야 할 객체지향언어의 개념을 정리해봤습니다. 절차지향 언어의 대표주자인 C언어와, 객체지향 언어의 대표주자인 Java를 기준으로 설명했습니다.

 

---

 

먼저 절차지향언어와 객체지향언어는 대립점에 있는 개념이 아닙니다. 모든 컴퓨터 언어는 기본적으로 절차(순서)에 따라 실행됩니다. 기본적으로 객체지향언어도 절차대로 수행되는 컴퓨터 언어입니다. 그저 더 중요시하는 "사상"이 다를 뿐입니다. 어떤 프로그램이라도 절차지향언어로 만들 수도, 객체지향 언어로 만들 수 있습니다. 만드는 과정이 조금 다를 뿐입니다.

​

예를 들어 된장찌개를 끓인다고 가정해보겠습니다. 춘향이는 절차를 지향해서 아래와 같이 순서대로 요리를 합니다.

 

 

 

길동이는 객체를 지향해서 아래와 같이 미리 재료를 다 준비해두고 한번에 요리를 합니다.

 

 

 

둘 다 똑같은 된장찌개를 끓였습니다. 둘 다 본인의 사상에 맞는 과정으로 요리를 했습니다. 못해서 안한건 아닙니다. 그리고 객체를 지향하는 길동이라도 재료를 먼저 다 익히고 마지막에 물을 넣을 순 없습니다. 과정이 달랐을 뿐, 길동이도 물을 끓이고 재료를 넣는 절차대로 된장찌개를 완성했습니다.

​

옛날에는 춘향이 같이 순서대로 일을 하다보니 점점 불편한 점이 생겼습니다. 점점 더 복잡한 요리를 해야해서 혼자 하기도 어렵고, 여러 명이서 순서에 맞게 요리를 같이 하려다보니 분업의 효율성이 점점 떨어지게 됩니다. 이후 길동이가 등장해 미리 잘 정해놓은대로 각자 다른 재료부터 다 만들고 마지막에 한번에 요리를 해보니 효율적입니다. 그래서 객체를 지향하는 길동이의 방식이 점점 진화를 합니다.

 

 

 

이런 방식의 차이가 결국 지금의 절차지향 언어와 객체지향 언어를 만들어냈습니다. 즉, 서로의 사상에 맞게 그 방법론들을 발전시키다보니 구현 방식이 달라지게 된 것이죠. C언어에 상속의 개념 없는 이유는 못만들어서가 아니라, 절차를 중시하는 사상에서는 굳이 상속의 개념이 필요 없는데 객체를 중시하는 사상에서는 객체 중심으로 일을 하다 보니 상속이란 개념이 필요해져서 만들어졌다고 볼 수 있습니다. 그렇게 발전해오면서 서로에게 없는 개념과 기능들이 잔뜩 생겨난 것이죠.

​

즉, C언어에서도 Java와 비슷한 형태로 구조를 잡아서 사용할 수 있습니다. 실제로도 대부분 객체지향 언어처럼 기능별로 여러 가지 함수부터 만든 뒤에 main함수를 구성하게 됩니다. 구조체처럼 나름의 클래스 역할을 담당하는 개념도 있습니다. 다만, 절차지향이라는 사상에 따라 객체라는 개념에 대한 기능이 객체지향언어에 비해 약할 뿐이라고 볼 수 있습니다.

 

※ 요약
절차지향이건 객체지향이건 만들지 못할 프로그램은 없다. 다만 절차지향 언어는 보다 컴퓨터가 효율적으로 동작하는 것에 초점을 맞췄다면, 객체지향은 보다 우리가 편하게 만들고 효율적으로 협업할 수 있도록 하는 것에 더 초점을 맞췄기 때문에 상황에 따라 유리한 언어가 다르다.

Java로 만들 수 있는 것은 C로도 만들 수 있다. 만들어 나가는 과정과 방식도 비슷하게 할 수 있다. 하지만 예를 들어, Java의 특성을 이용한 특정한 방식의 협업 구조를 C언어로는 적용 할 수 없을 수 있다. 즉, 각자 특화된 방식들을 서로 모방하기 어려울 수는 있다.

 

---

 

직관적으로 이해가 어려울 수 있으니 간단한 예시를 하나 들어보겠습니다.

​

컴퓨터를 일체형으로 만들어보자면, 본체 껍데기를 하나 만들고 메인보드를 넣고 칩을 끼우고 모니터를 붙이고 키보드를 붙입니다. 일체형 컴퓨터의 목적은 최적화된 빠른 컴퓨터를 만드는 것이고, 각 부품들은 일련의 규격에 맞춰 절차대로 만들어져야 합니다.

 

 

 

아무리 설계를 잘 했어도 직접 만들다보면 시행착오가 있을 수 있습니다. 껍데기 규격에 맞춰서 각자 메인보드와 모니터와 키보드를 만들었는데 모니터를 만들던 사람이 뭔가 문제가 생겨서 조금 더 크게 만들었습니다. 그럼 그에 맞춰서 껍데기나 키보드 크기를 조절해서 다시 만들어줘야합니다. 그래서 제일 좋은 방법은 일단 메인보드와 모니터가 완성되고 난 후에 이에 맞춰서 껍데기와 키보드를 다시 만드는 것입니다. 절차대로 만들 때 더 효율이 커진다는 것이죠.

 

 

 

세월이 조금 지나 소비자들이 더 큰 모니터를 원하면 또 껍데기를 다시 만들어줘야 합니다. 껍데기 만드는 사람이 도저히 못하겠다고 하면 메인보드와 키보드를 새로 만들어줘야 하죠. 또 일체형이기 때문에 모니터에 뭔가 문제라도 생기면 전체를 분해해서 확인해봐야 합니다. 모니터에 문제가 있다면 규격대로 다시 만들어서 조립해줘야 하는데 이 과정에서 또 모니터 크기가 조금 바뀌게 되면 다른 부품들도 또 다시 조정해줘야 합니다. 유지보수도 어렵게 되는 거죠.

 

 

 

대신 내부에서 모두 칩셋으로 연결되어 있어서 데이터 전달 속도가 빠르고, 전체 구조를 최적화했기 때문에 성능이 아주 우수합니다. 즉, 절차지향이란 하나의 컴퓨터를 아주 최적화해서 만드는 것을 가장 큰 목표로 합니다. 만들기가 어렵고 유지보수가 어렵다는 문제점은 빠른 컴퓨터를 만드는 목표를 위해 감수해야 합니다.

 

---

 

하지만 너무 효율성이 떨어져서 이번에는 다른 방식으로 만들기로 합니다. 본체 따로, 모니터 따로, 키보드를 따로 만들어서 미리 약속한 규격(인터페이스)에 맞춰서 연결만 해주기로 합니다.

 

 

 

이것이 바로 객체의 개념입니다. 본체, 모니터, 키보드와 같이 각자의 기능을 가진 것들의 분류를 객체라고 합니다.

​

처음 이 방식이 나오니, 일체형보다 느립니다(실제 역사적인 것이 아닌 비유). 그래서 모니터와 키보드와 본체를 만드는 방식 못지 않게, 각기 다른 기기(객체)들을 연결하는 방법에 대해서 고민하게 됩니다. 즉, 객체 간 인터페이스 방식을 고민하고 연구해 발전시켜 나가게 됩니다.

 

 

 

객체를 따로 만들어서 잘 연결만 해주면 되기 때문에 서로 연결방식(인터페이스)만 맞춰주면 모니터 제작자나 키보드 제작자는 자기 맘대로 만들고 나서 연결만 해주면 되는 것이죠. 인터페이스 방법이 점점 발전하기 때문에 이제 일체형에 비해 속도차도 줄어들게 됩니다. 각 기능을 담당하는 객체를 먼저 만들고 나중에 연결해줄 때 더 효율적이 됩니다. 절차지향적인 기준에서는 굳이 저런 케이블들에 많은 시간을 들일 필요가 없어서 객체지향에 비해 그런 개념이 약해지는 것입니다.

 

---

 

어차피 Java도 메소드(함수)를 만드는 방식은 C와 동일합니다. 심지어 문법도 거의 비슷해서 C로 짤 때와 굳이 달라지는게 없습니다. 다만, 남이 짜둔 코드를 가져다 쓰는 것이 조금 더 (사실 많이..) 수월할 뿐입니다. 하지만 남이 짜둔 코드를 가져다 쓰는게 쉽다는 의미는 남이 짜두지 않은 코드는 가져다 쓸 수 없다는 말입니다. 절차지향적인 알고리즘 공부는 모든 코딩의 기본이 됩니다.