728x90

Tistory에서 제일 처음 쓰는 글이 이 글이다.

제일 처음 쓰는 글의 주제에 맞는지는 모르겠지만 이 포스팅에서는 코딩 패러다임에 대해서 짧게 이야기하려고한다.


코딩패러다임이 무엇인지 아는 사람은 요즘(이라기 보단 항상)엔 드문 편이다.

사실 코딩 패러다임이 그리 중요한가 싶기도 하다.

예를 들어서 자바를 한다고 치자. 아마 누가 시키지 않아도 자동으로 객체지향 프로그래밍을 하게 될것이며

GUI를 쓴다면 이벤트 기반 프로그래밍을 하게 될것이다. 사실 심도깊게 논하지 않아도 자동으로 알게 될 것이라 생각한다.


그럼에도 불구하고 여기서 프로그래밍 패러다임에 대해서 짧게 이야기를 하는 이유는

그 와중에 알고싶어 하는 사람이 있을것이고 또한 프로그래밍하다 지친 개발자나 예비 개발자들이

심심풀이로 읽는 포스팅이 되었으면 하는 바램에서이다.

그러니 읽는 여러분도 심도 깊게 읽을 필요는 없다. 그냥 이런게 있나보다 하고 가벼운 마음으로 읽으면된다.



1.순차적 프로그래밍(Sequential Programming), 비구조적 프로그래밍(Non-structured programming)

순차적 프로그래밍과 비구조적 프로그래밍은 개념적으로는 다르나 비슷하게 지칭하므로 함께 묶어서 설명하겠다.

순차적 프로그래밍은 말 그대로 순차적으로 흘러가는 프로그래밍 구조를 의미한다.

보통 코딩 패러다임을 설명할때 가장 초기에 등장한 코딩 패러다임이라고 부른다.

그도 그럴것이 모든 프로그램은(그 어떠한 프로그램이던 간에) 코드를 순서대로 읽는다.


그렇다고 모든 코딩 패러다임이 순차적 프로그래밍은 아니다.

여기서 말하는 순차적 프로그래밍이란것은 순차를 중점으로 본다는 이야기가 되겠다.

즉 코딩을 코드의 흐름,순서에 기반하는 프로그래밍이라는 것이다.


이 코딩패러다임에서는 구조라는 개념이 없다.

(사실 순차적 코딩패러다임은 구조의 존치여부는 상관없지만 보통 비구조적 프로그래밍과 묶어 설명하므로 같이 설명하겠다.)

그로인해서 코드는 goto문을 사용해서 코드를 짜게 된다.

문제는 여기서 벌어지는데 규모가 커지면 커질수록 goto문이 범람하게 된다면

이미 그건 프로그래밍 보단 거의 실뜨기에 가까워진다. a에서 b로 갔다가 다시 c로 갔다가 어쩌구 저쩌구...

코딩에 집중할 수 없고 흐름만 신경쓰다가 시간은 세월아 네월아 흘러가게된다.

따라서 사람들은 코드의 중복을 최대한 피하기 위해서 코드를 단위화할 방법을 모색하게 되었다.



2.절차적 프로그래밍(Procedural Programming), 구조적 프로그래밍(Structured Programming)

드디어 좀 사람들이 아는 프로그래밍이 등장했다. 바로 절차적 프로그래밍이다.

여기서 절차적 프로그래밍을 절차지향 프로그래밍이라고 말하는 사람이 있다.

그러나 알아둘건 절차지향 프로그래밍이란건 존재하지 않는 다는점이다.

왜냐하면 여기서 말하는 절차라는건 순수한의미의 절차가 아닌 Procedual인 프로시저, 즉 함 수를 의미한다.

함수라는 말은 낮설지 않을것인데 프로시저는 뭘 의미하는지모르는 사람이 있는것 같다.


쉽게 생각하면 프로시저도 함수라고 생각하면 된다. 다만 반환값이 없고(없다) 실행이 주가되는 함수를 의미한다.

예를 들어서 일반적인 C언어의 printf는 실제로는 반환값이 존재하지만 반환값이 중요한 함수는 아니다.

화면에 표시해주는게 주가된다. 따라서 printf는 int형을 반환하지만 프로시저에 가깝다고 할 수 있다.

이렇듯 프로시저와 함수의 정의는 칼로 자르듯 딱 잘라서 나눌 수 없다.

그래서 그런지 요즘 프로그래밍 언어는(VB 6.0은 아직도 프로시저가 있다.) 프로시저라는 개념을 함수와 통일했다.


여튼 절차적 프로그래밍의 절차는 함수를 의미한다고 했다.

따라서 절차적 프로그래밍의 중요한 점은 절차를 어쩌구 저쩌구가 아니라 반복될 가능성이 있는 모듈을

재사용 가능한 프로시저 단위(함수단위)로 나눈 프로그래밍이라고 할 수 있겠다.

goto문이 범람했던 순차적 프로그래밍과 달리 절차적 프로그래밍은 반복될 가능성이 있는 부분은 프로시저로 쪼개고

또한 각각의 프로시저 안에서 중복되는 부분은 for문과 같은 반복문으로 구성한다.


이게 조금 더 발전한 형식이 구조적 프로그래밍이다.

둘은 현대와서 동의어로 쓰이는 경향이 있는데 사실 완전한 동의어는 아니다.

절차적 프로그래밍이 함수를 기준으로 나뉜다면 구조적 프로그램은 모듈을 기준으로 나뉜다.

여기서 말하는 모듈이라는 개념역시 조금 애매모호하다. 해석하기 나름이기 때문이다.

그러나 이를 조금 더 작은 단위에서 얘기는 할 수 있다.

일반적으로 모듈이라는 개념은 물리적인 소스파일을 이야기한다.

즉 절차적 프로그래밍이 프로시저로 쪼갰다면 그 프로시저를 비슷한 애들끼리 묶어서 소스파일로 묶은 것을 모듈이라고 보는것이다.

따라서 둘은 엄밀히 말하면 다른 포현인건 맞지만 실제로는 프로시저를 비슷한역활을 하는 애들끼리 묶을 수 밖에 없으므로

둘을 동의어라 생각하고 접근해도 큰 무리는 없다고 할 수 있을 것이다.


그러나 이런 절차적(구조적) 프로그래밍도 문제가 존재한다.

왜냐하면 프로시저라는 것은 추상적인 단위이기 때문이다.

그러나 프로그램에서는 추상적인것만 존재하지않는다. 왜냐하면 메모리(물리적 매체)라는 것에 저장을 하기 때문이고

그 메모리에 저장되는 것을 관리하는 논리적 단위가 프로시저이기 때문이다.

절차적 프로그래밍에서는 물리적인 요소(변수나 상수등의 값들)을 관리하는 방법에 대해서는 깊게 논하지 않기에

그것까지 관리하는데는 문제가 생기기 마련이다.


예를 들자면 도서관리 프로그램을 작성한다고 하면 책이라는 자료형이 필요하다.

그리고 그 책에 대한 함수역시 필요할 것이다. 구조적 프로그래밍에서는 이 둘을 따로 생각할 수 밖에 없다.

즉 책 자료형은 책 자료형이고 그것을 사용하는 함수는 함수대로 따로 있는것이다.

이를 소스파일에 묶어 두더라도 사용자 입장에서 코드가 길어진다면 그것을 알기는 굉장히 힘들다.

즉 책에 대한 자료형과 책에 대한 함수가 물리적으론(기록되는 곳)같이 있을 수(모듈) 있지만 논리적으로는(개념)

함께 할 수 없는 구조이기 때문이다. 이를 묶기 위한 새로운 패러다임이 필요했다.


3.객체 지향 프로그래밍(Object-Oriented Programming)


그럼 여기서 해결책은 생각보다 간단하다. 특정 개념의 함수와 자료형을 함께 묶어서 관리하면 되지 않나 하는 것이다.

그렇게 해서 탄생한것이 객체 지향 프로그래밍이다.

객체 지향 프로그래밍에서 중요한 점은 모든 객체는 그 내부에 자료형(Field)와 함수(Method)가 존재한다.

이로 인해서 책이라는 자료를 객체 모델로 만든다면 그 책의 쪽수나,이름과 같은 자료형 뿐만 아니라

책을 읽기, 책을 만들기 등의 함수들 역시 "책"이라는 객체로 묶어 놓는 것이다.


이렇게 객체 지향 프로그램은 가능한 모든 물리적, 논리적 요소들을 객체로 만드려고 한다.

일단 객체라는 한 개체로 완성되면 그 객체는 다른 객체로 부터 높은 수준의 독립성을 완성했다고 할 수 있다.

이렇게 하면 코딩할때 극 초반에만 조금 불편해진다.

그러나 시간이 지날수록 중복코딩이 굉장히 줄게되며 객체와 객체간에 독립성이 확립되므로 유지보수에 도움이된다.


여기까지가 객체 지향 프로그래밍의 간단한 기본 설명이라고 할 수 있다.

조금 더 나아가서 설명하자면 이 객체 지향 프로그래밍은 초창기 형태와 지금의 형태가 조금 다르다.

초창기에서는 정말로 변수와 함수를 묶는 선에서 끝났지만 독립성이 무기라는것을 알게됨으로써 그 독립성을 지키는데 발전해 왔다.

여기서 사용하는 기술이 은닉화와 캡슐화, 다형성, 상속이 추가됨으로써 객체는 초기보다 훨씬 강력한 형태로 탈바꿈 하였다.




어떤가 재미있게 읽었는가? 아니면 너무 다 아는 내용이였거나 조금 부실하다고 생각할 수도 있을것이다.

사실 패러다임에 대해서 깊게 이야기하면 끝도 없고 각각이 딱딱 나눠저있다고 보기도 힘들다.

그러므로 이렇게 쉬엄쉬엄 알아가는 정도로만 알아도 문제는 없을 것이다.

이제 객체 지향 프로그래밍의 전성기도 점점 저물어가고있다. 이미 파이썬 코드들은 객체 지향 프로그래밍이라고 보기 힘들고

반응형 프로그래밍, 함수형 프로그래밍등의 패러다임이 부상하기 때문이다.

그럼에도 객체 지향 프로그래밍은 매우 중요함에 틀림없다.

객체 지향 프로그래밍을 왜 하는지 알고 사용한다면 앞으로 더 프로그래밍을 해나가는데 윤택해 질것이다.

+ Recent posts